3 ms·

This part brought back memories from an even older time: "Worst, it required two more programs: Flex and Bison." In the early 80s I had the idea to port a C c

This part brought back memories from an even older time: "Worst, it required two more programs: Flex and Bison." In the early 80s I had the idea to port a C compiler to a new machine (I forget if this was K&R or pcc, but those were the only two C compilers you could get the source for at the time, legal issues aside...). At some point I had that same realization: uhh...this thing needs two other pretty big things: yacc and lex. The "first catch your fish" of compilers: "first port the parser-generators".

Joker_vD 2mo ago
"Can't you just ship the generated .h/.c files with the source distribution?!" "Those take less space than lex/yacc so of course not".
- compiler-guy 2mo ago
  GCC at the time was under GPL v2, which includes. "The source code for a work means the preferred form of the work for making modifications to it." For lex and yacc, that means the original .y and .l files. You don't have a choice if you want to be compliant with the terms. Also, shipping the .h and .c files in addition also ends up confusing the build systems of the time.
  - Joker_vD 2mo ago
    > "The source code for a work means the preferred form of the work for making modifications to it." > For lex and yacc, that means the original .y and .l files. You don't have a choice if you want to be compliant with the terms. Okay? I don't say "drop .y and .l files", I say "throw in the .h and .c produced from them as well into the tarball distribution". > Also, shipping the .h and .c files in addition also ends up confusing the build systems of the time. How?! If it were true, then merely having them in the source directory after running "make" for the first time would also break the build which obviously is not something that ever happened.
    - compiler-guy 2mo ago
      The output is stored in the build directory, not the source directory. So now you have to either detect that lex and yacc aren’t available and do something clever or let the user do it. And then wonder why their modifications don’t stick. You also have to ensure that every time you update the .y file, you update another file in the source tree, when it’s really part of the build. It’s annoying and would be similar to the maintainer mode builds that used to happen and confuse people. It can be done, but the benefits are low. Most systems back in the day had lex and yacc available. Systems that didn’t, but also that needed a compiler were rare, and the vast majority of the time you just cross compiled in those situations.
      - Joker_vD 2mo ago
        > The output is stored in the build directory, not the source directory. No, it's not. c-parse.o : $(srcdir)/c-parse.c $(CONFIG_H) $(TREE_H) c-lex.h $(GGC_H) intl.h \ $(C_TREE_H) input.h flags.h system.h toplev.h output.h cpplib.h $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c $(srcdir)/c-parse.c $(srcdir)/c-parse.c: $(srcdir)/c-parse.y (cd $(srcdir) && $(BISON) $(BISONFLAGS) -o c-p$$$$.c c-parse.y && \ mv -f c-p$$$$.c c-parse.c) $(srcdir)/c-parse.y: c-parse.in echo '/*WARNING: This file is automatically generated!*/' >tmp-c-parse.y sed -e "/^ifobjc$$/,/^end ifobjc$$/d" \ -e "/^ifc$$/d" -e "/^end ifc$$/d" \ $(srcdir)/c-parse.in >>tmp-c-parse.y $(SHELL) $(srcdir)/move-if-change tmp-c-parse.y $(srcdir)/c-parse.y $(srcdir)/tradcif.c: $(srcdir)/tradcif.y (cd $(srcdir) && $(BISON) $(BISONFLAGS) -o tr$$$$.c tradcif.y && \ mv -f tr$$$$.c tradcif.c) It's all dumped into the same srcdir where the rest of the .c files live. That's how it's always been. Also, PCC does it about the same way: srcdir=. top_srcdir=../.. cgram.c: $(srcdir)/cgram.y $(YACC) $(YFLAGS) -d $(srcdir)/cgram.y mv -f y.tab.c cgram.c mv -f y.tab.h cgram.h scan.c: $(srcdir)/scan.l $(LEX) $(LFLAGS) $(srcdir)/scan.l mv -f $(LEX_OUTPUT_ROOT).c scan.c $(OBJS): $(HDRS) external.c cgram.c cgram.o: cgram.c $(CC) $(CF0) $(CFLAGS) $(CPPFLAGS) -c -o $@ cgram.c scan.o: scan.c $(CC) $(CF0) $(CFLAGS) $(CPPFLAGS) -c -o $@ scan.c
        2mo ago

Joker_vD 2mo ago

"Can't you just ship the generated .h/.c files with the source distribution?!" "Those take less space than lex/yacc so of course not".

compiler-guy 2mo ago
GCC at the time was under GPL v2, which includes. "The source code for a work means the preferred form of the work for making modifications to it." For lex and yacc, that means the original .y and .l files. You don't have a choice if you want to be compliant with the terms. Also, shipping the .h and .c files in addition also ends up confusing the build systems of the time.
- Joker_vD 2mo ago
  > "The source code for a work means the preferred form of the work for making modifications to it." > For lex and yacc, that means the original .y and .l files. You don't have a choice if you want to be compliant with the terms. Okay? I don't say "drop .y and .l files", I say "throw in the .h and .c produced from them as well into the tarball distribution". > Also, shipping the .h and .c files in addition also ends up confusing the build systems of the time. How?! If it were true, then merely having them in the source directory after running "make" for the first time would also break the build which obviously is not something that ever happened.
  - compiler-guy 2mo ago
    The output is stored in the build directory, not the source directory. So now you have to either detect that lex and yacc aren’t available and do something clever or let the user do it. And then wonder why their modifications don’t stick. You also have to ensure that every time you update the .y file, you update another file in the source tree, when it’s really part of the build. It’s annoying and would be similar to the maintainer mode builds that used to happen and confuse people. It can be done, but the benefits are low. Most systems back in the day had lex and yacc available. Systems that didn’t, but also that needed a compiler were rare, and the vast majority of the time you just cross compiled in those situations.
    - Joker_vD 2mo ago
      > The output is stored in the build directory, not the source directory. No, it's not. c-parse.o : $(srcdir)/c-parse.c $(CONFIG_H) $(TREE_H) c-lex.h $(GGC_H) intl.h \ $(C_TREE_H) input.h flags.h system.h toplev.h output.h cpplib.h $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c $(srcdir)/c-parse.c $(srcdir)/c-parse.c: $(srcdir)/c-parse.y (cd $(srcdir) && $(BISON) $(BISONFLAGS) -o c-p$$$$.c c-parse.y && \ mv -f c-p$$$$.c c-parse.c) $(srcdir)/c-parse.y: c-parse.in echo '/*WARNING: This file is automatically generated!*/' >tmp-c-parse.y sed -e "/^ifobjc$$/,/^end ifobjc$$/d" \ -e "/^ifc$$/d" -e "/^end ifc$$/d" \ $(srcdir)/c-parse.in >>tmp-c-parse.y $(SHELL) $(srcdir)/move-if-change tmp-c-parse.y $(srcdir)/c-parse.y $(srcdir)/tradcif.c: $(srcdir)/tradcif.y (cd $(srcdir) && $(BISON) $(BISONFLAGS) -o tr$$$$.c tradcif.y && \ mv -f tr$$$$.c tradcif.c) It's all dumped into the same srcdir where the rest of the .c files live. That's how it's always been. Also, PCC does it about the same way: srcdir=. top_srcdir=../.. cgram.c: $(srcdir)/cgram.y $(YACC) $(YFLAGS) -d $(srcdir)/cgram.y mv -f y.tab.c cgram.c mv -f y.tab.h cgram.h scan.c: $(srcdir)/scan.l $(LEX) $(LFLAGS) $(srcdir)/scan.l mv -f $(LEX_OUTPUT_ROOT).c scan.c $(OBJS): $(HDRS) external.c cgram.c cgram.o: cgram.c $(CC) $(CF0) $(CFLAGS) $(CPPFLAGS) -c -o $@ cgram.c scan.o: scan.c $(CC) $(CF0) $(CFLAGS) $(CPPFLAGS) -c -o $@ scan.c
      - 2mo ago