Re: Patch for autoconf/145

[Derek R. Price]

Pavel Roskin wrote:

> > > I believe that Automake can switch to @SET_VPATH@, but I'm in doubt what
> > > package should AC_DEFINE it - Autoconf or Automake or both?
> >
> > Who cares.  AC_SUBSTing twice is fine.
>
> Of course I meant AC_SUBST.
>
> > The only question is *what* is supposed to be in there.  Sorry for
> > being so naive, but I really never paid attention to VPATH.
>
> Two possible solutions:
>
> 1) VPATH = ${srcdir}
>
> 2) VPATH = @srcdir@

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.

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.

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.

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.

And I really don't think the regex as it stands is all that opaque, but we're
all entitled to our opinions.  :)

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden     OpenAvenue ( http://OpenAvenue.com )
--
I am not authorized to fire substitute teachers.
I am not authorized to fire substitute teachers.
I am not authorized to fire substitute teachers...

          - Bart Simpson on chalkboard, _The Simpsons_