[Top][All Lists]
[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
- Re: Patch for autoconf/145, Akim Demaille, 2001/02/23
- Re: Patch for autoconf/145, Akim Demaille, 2001/02/23
- Re: Patch for autoconf/145, Pavel Roskin, 2001/02/23
- Re: Patch for autoconf/145, Akim Demaille, 2001/02/23
- Re: Patch for autoconf/145, Pavel Roskin, 2001/02/23
- Re: Patch for autoconf/145, Derek R. Price, 2001/02/23
- Re: Patch for autoconf/145,
Pavel Roskin <=
- Re: Patch for autoconf/145, Derek R. Price, 2001/02/25
- Re: Patch for autoconf/145, Pavel Roskin, 2001/02/25
- Re: Patch for autoconf/145, Derek R. Price, 2001/02/26
- Re: Patch for autoconf/145, Derek R. Price, 2001/02/26
- Re: Patch for autoconf/145, Ralf Corsepius, 2001/02/25
- Re: Patch for autoconf/145, Pavel Roskin, 2001/02/25