Hacker News Reader

Comment by Joker_vD | Hacker News Reader

> "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.

View on HN

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.

> 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

Heh. It's pilot error all the way up at the beginning. GCC releases did ship these files, and they did it by using maintainer mode, which was generally a pain for those not maintainers. Which also explains why I was confused about the build. I definitely built it with the source on read-only file systems back in the day.

https://www.gnu-pascal.de/standards.html (from 2000.)

"Naturally, all the source files must be in the distribution. It is okay to include non-source files in the distribution, provided they are up-to-date and machine-independent, so that building the distribution normally will never modify them. We commonly include non-source files produced by Bison, lex, TeX, and makeinfo; this helps avoid unnecessary dependencies between our distributions, so that users can install whichever packages they want to install."

Reply on news.ycombinator.com