Hacker News Reader

Comment by compiler-guy | Hacker News Reader

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.

View on HN

> 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