Re: CVS gettext: many test failures

[Ralf Wildenhues]

* Bruno Haible wrote on Wed, Dec 20, 2006 at 02:51:01PM CET:
> Ralf Wildenhues wrote:
> > > it creates the new files in the build
> > > directory. I know the reason why: if a source distribution is installed 
> > > in a
> > > read-only location, the build in a VPATH should not touch any file in the
> > > source directory.
> > 
> > That's not what I'd say.  You can only expect compiling from a read-only
> > location to work right if that read-only location happens to contain up
> > to date files.  If a bison input file is updated there, then one can
> > rightly expect other files to need updated there as well.
> 
> Good! So please, can you fix automake to behave like this?
[...]

> The fix should be that in the cited circumstances po-gram-gen.c and
> po-gram-gen.h should be updated in $(srcdir).

Currently Automake seems not to place a restriction on whether the
package author wants bison output updated in the source tree or in the
build tree.

I mean, you can make it work with updates in the build tree by
- adjusting cpp include path to mention the build tree path first
  (in your case already done by DEFAULT_INCLUDES).
- adjusting all other references to the generated files inside rules
  to _prefer_ the file in the build tree location over one in the source
  tree location.  E.g.:
        test -f $$input || input=$(srcdir)/$$input; \
        [...]

I don't see a convincing argument that Automake need to restrict package
authors to only use one or the other possibility.

> > How about this patch to force updates in srcdir?
> > (Some BSD make cannot infer that file and $(srcdir)/file are
> > the same target with VPATH = $(srcdir).)
> 
> This misses the point,

Bzzt.  I was explaining here why my patch did not just add the minimal
amount of changes needed to fix the above issue.  Read it again.

> because
>   - we are not discussing BSD make here, but GNU make on a glibc system, and

What?  Can you not build gettext with a BSD make any more?
Can you not build gettext on a non-glibc system?
If yes to both, then of course my patch could be made smaller, without
breakage (but as it is it wouldn't harm either).

>   - a patch to gettext's Makefile.am will not affect the instantiations of
>     automake's .y.c rule in other packages than gettext.

Certainly.

Cheers,
Ralf