Re: gettext-0.12.1 msgfmt (built with bison 1.875) cannot read .po files

[Alexander Dupuy]

> > I suppose that changing line 49 of po-lex.c to use <> instead of "" for
> > the po-gram-gen2.h include would fix this problem

Bruno Haible wrote:
> Yes it would, but I won't apply this fix because it is a custom idiom
> to use #include <> for system headers and #include "" for headers provided
> by the package. Breaking this idiom would confuse many people.

What about the fix to copy po-lex.c into the build directory if not 
already present?  This seems unlikely to confuse many people, and would 
be a no-op for non-VPATH builds.  There's already a dependency line for 
po-lex.o po-lex.lo; adding a variant rule that copies the po-lex.c file 
into the current directory would not be that difficult.

> The real problem is the existence of two copies of the generated file,
> and this comes from the use of a VPATH build on a source tree that was
> not generated with "make dist". This is generally unwise; besides the
> problem you noticed it can also lead to the following symptoms:
>
>   - If you remove the info files from the doc/ directory of the source,
>     then do "make" in a VPATH build, then it will generate the .info
>     file in the build directory's doc/ subdir, and "make distclean"
>     will not remove it.
>
>   - "make distcheck" can fail if the source package is on a read-only
>     filesystem.
>
> In summary: Use VPATH only for distributed tarballs that were made with
> "make dist".

While those are minor annoyances (that don't affect the functionality of 
the compiled software), the problem I ran into resulted in a successully 
compiled msgfmt that didn't work at all (and was rather tricky to 
debug).  Most people will never remove info files, nor run make 
distcheck, since they simply use VPATH builds to allow multiple 
architecture builds without duplicating the source trees, and for all 
other GNU software, VPATH builds of that sort work quite well.

I suppose it's possible that we're the only ones who will ever run into 
the problem, because everybody else regenerates the source tree using 
make dist, or doesn't use VPATH builds, but somehow I doubt it.  I 
suspect it's just that most people aren't using bison-1.875 (yet).

If the configure script generated warnings on (implicit or explicit) use 
of --srcdir in the presence of generated source files (like top-level 
Makefile.in) and recommended "make maintainer-clean" or regeneration 
using "make dist", then it would be a different story, but I've never 
seen anything (for any GNU package) that would alert the naive user that 
they should not use a VPATH build on a source tree that was not 
generated with "make dist".  There's certainly no mention of this in the 
"Compiling For Multiple Architectures" section of the INSTALL file in 
the distribution.

@alex
--
mailto:address@hidden