Re: VPATH rebuilding of gawk

[Ralf Wildenhues]

Hello Andrew,

* Andrew J. Schorr wrote on Sun, Jan 21, 2007 at 03:43:04PM CET:
> On Sat, Jan 20, 2007 at 07:42:30PM -0500, Andrew J. Schorr wrote:
> > On Sat, Jan 13, 2007 at 09:18:50PM +0200, Aharon Robbins wrote:
> > > > awklib/ChangeLog:
> > > > 2006-12-03  Ralf Wildenhues  <address@hidden>
> > > >
> > > >         * Makefile.am (stamp-eg): Allow rebuilding from a VPATH build.
> > > OK, I've applied these. They'll be showing up soon in the CVS.
> > 
> > Hmmm, sorry to pipe in so late, but I'm confused about this.  In the
> > awklib/Makefile.am patch, the stamp-eg file is now being created in 
> > $(srcdir).
> > But I thought the idea when using VPATH was that the source tree should not 
> > be
> > touched (i.e. it should be read-only).

Well.  If the `eg' directory is distributed in a tarball, there is no
contradiction here: you unpack the tarball, build it.  `eg' should be
up to date at this point, because all its prerequisites are up to date.
So no changes should happen; you must however make sure that it does
not depend upon any files which are created in the build tree.

Of course it will be updated if the source changes.  But then the source
tree wasn't read-only either: how could you have changed it otherwise?

> > So why are we creating the "eg"
> > directory inside $(srcdir) instead of inside the build directory?

Because you're also distributing it.

> > And what
> > happens if two different builds on two different architectures (with 
> > different
> > build directories but the same srcdir) are occurring at the same time?
> > Couldn't this confuse make and leave a garbled result?

If somebody actually happens to both change the sources and do several
rebuilds at once, I'm bound to say many packages will leave you out in
the cold: for example all texi files treated by Automake's rules.  Only
if the shipped sources plus .info files are up to date will a read-only
source tree work.

> Furthermore, it is not necessary to include the eg tree in the distro,
> since it is generated by the build process, so both eg and stamp-eg
> can be removed from EXTRA_DIST.

That's another alternative.  I don't see why it is needed though.
Also note that it will fail in the cross-compiling case if you're
out to use the just-built `gawk'.  (Disclaimer: I don't know whether
that is the case, or whether gawk otherwise deals well with cross
compilation.)

A note to the patch:

> -pwcat$(EXEEXT): $(srcdir)/eg/lib/pwcat.c
> -     $(COMPILE) $(srcdir)/eg/lib/pwcat.c $(LDFLAGS) -o $@
> +pwcat$(EXEEXT): stamp-eg
> +     $(COMPILE) `dirname $<`/eg/lib/pwcat.c $(LDFLAGS) -o $@

The `$<' macro is portable in inference rules (like .c.o) only.
Solaris `make' will barf otherwise.  Several instances in the patch.
Didn't you in this case mean to write either `$(srcdir)' or `.' anyway?

Further, are awklib/eg/lib/groupawk.in and awklib/eg/lib/passwdawk.in
also generated files (I currently don't see how)?  If not you'd need to
put them in EXTRA_DIST as well.

Cheers,
Ralf