Re: parse-datetime.c generated in the source (instead of build) directory

[Bruno Haible]

Kamil Dudka wrote:
> parse-datetime.c generated out of parse-datetime.y ends up in the source 
> directory, instead of the build directory as one would expect.  This was 
> introduced by the following commit:
> 
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6c680191
> 
> Neither the comment, nor the change log entry explains why it is desired.

For gnulib, you sometimes need to look up in the mailing list archive to get
the complete discussion. In this case, the essential mail was
https://lists.gnu.org/archive/html/bug-gnulib/2010-04/msg00488.html
which referenced
https://lists.gnu.org/archive/html/bug-gnulib/2009-05/msg00061.html

> As far as I know, the build should work even if the source directory is
> on a read-only file system.

... *only* if the source directory contains a complete, unmodified tarballs
contents. But when a .y.c rule needs to be run, you must have modified the
.y file, or the timestamps are wrong. You can't build off a read-only source
directory in this case.

The most important use-case of Makefiles are the developer's working directory.
The use-case with a read-only source directory is only a corner case; in case
of conflict with the important use-case, it's the important use-case which wins.

> Moreover, this oddity seems to cause problems to the debug info extractor
> used by rpmbuild in Fedora:
> 
> https://bugzilla.redhat.com/1555079

I don't know how the debug info extractor works, but you make it sound like
it would ignore source files in $srcdir - which would not be right.

Bruno