[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: parse-datetime.c generated in the source (instead of build) director
Re: parse-datetime.c generated in the source (instead of build) directory
Fri, 16 Mar 2018 19:54:17 +0100
Sorry, I have just checked and automake does not distribute the
generated source by default, thus the modified .y.c rule is required.
Le vendredi 16 mars 2018 à 19:09 +0100, Vivien Kraus a écrit :
> Distributing the generated sources is the default behaviour to expect
> from automake; I don't really understand why it is needed to override
> the .y.c rule... This behaviour permits you to configure, build,
> install, check... the package without having bison installed. Since
> the generated .c is distributed and does not depend on the
> configuration (this is the definition of a source file for
> automake),it will never change if the source directory is read-
> You can check that this is actually the case by running "make
> distcheck" in an automake project: it will make a source
> extract it in a read-only directory, and build it. If bison needs to
> write in the read-only directory, then it means the source
> is broken.
> Sorry for my english, I hope it can help.
> Le vendredi 16 mars 2018 à 18:19 +0100, Kamil Dudka a écrit :
> > 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=6c6
> > 80
> > 191
> > Neither the comment, nor the change log entry explains why it is
> > desired.
> > As far as I know, the build should work even if the source
> > directory
> > is
> > on a read-only file system.
> > Moreover, this oddity seems to cause problems to the debug info
> > extractor
> > used by rpmbuild in Fedora:
> > https://bugzilla.redhat.com/1555079
> > Kamil