[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS gettext: many test failures

From: Ralf Wildenhues
Subject: Re: CVS gettext: many test failures
Date: Wed, 20 Dec 2006 15:06:24 +0100
User-agent: Mutt/1.5.13 (2006-11-01)

* 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]