autoconf-patches
[Top][All Lists]
Advanced

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

Re: Patch for autoconf/145


From: Pavel Roskin
Subject: Re: Patch for autoconf/145
Date: Sun, 25 Feb 2001 01:15:33 -0500 (EST)

Hello, Derek!

> > Two possible solutions:
> >
> > 1) VPATH = ${srcdir}
> >
> > 2) VPATH = @srcdir@

I'm now strongly for the later. Minor implementation problems in Autoconf
cannot justify a possible behavior change for the users.

Unfortunately, a trivial AC_SUBST([SET_VPATH], [VPATH = @address@hidden) doesn't
work - Autoconf actually makes a great effort to protect the second
argument from expanding.

> I remember reading in an obscure comment in some code somewhere that @srcdir@
> was preferable to $(srcdir) for optimization reasons.  i.e. Make would
> otherwise try and consult $(srcdir) every time it needed to know the value of
> VPATH (possibly several times per target) and _we_ know it's not going to
> change.

Ok, that just confirms my previous statement.

> Unfortunately, ignoring this still leaves us with the original reason for the
> magic.  That reason is that the user may want to add paths to VPATH and this
> doesn't necessarily mean shooting herself in the foot.  As long as she leaves
> @srcdir@ in there, everything Automake & Autoconf depended on for building out
> of tree should still work, but Autoconf doesn't know in advance whether the
> user did this or not.  So the Autoconf magic is just making sure that we only
> strip our (or anybody's irrelevant) @srcdir@ from the definition when it is 
> not
> needed ('.') and then removes the line completely for portability/optimization
> reasons if this leaves it empty.

This magic will be left for some time until everybody who cares about
protability switches to SET_VPATH. At this point, Autoconf will stop doing
anything with VPATH, which will only affect projects not following GNU
standards for VPATH.

> Incidentally, the magic I wrote was actually to _allow_ the user to shoot
> themselves in the foot (leave @srcdir@ or its variants out of VPATH), because
> the original version of the code was assuming that no ':' meant the line could
> be dropped, so if the user defined, for example, "VPATH = SomePathILike" in a
> Makefile.am or Makefile.in (hence breaking the Autoconf/Automake style out of
> tree builds), Autoconf was still blissfully deleting the line entirely.

Your magic is better than the old behaviour, that's why I applied your
patch. However, no magic is better than any magic, that's why SET_VPATH
should be gradually introduced.

> Simpler magic, such as removing something more straightforward like "^VPATH *=
> address@hidden@$", would work.  I think something like this was what Pavel 
> originally
> proposed.  The extra fluff is really only an optimization.

Exactly. Your solution was a bit more robust. But ideally, everybody who
wants portability should move to SET_VPATH, and the remaining developers
should care about VPATH themselves.

Regards,
Pavel Roskin





reply via email to

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