Re: autoconf/145

[Pavel Roskin]

Hello, Robert!

> My understanding of the way Autoconf and Automake are supposed to work
> was that anything that Autoconf did not recognize would be placed into
> the Makefile.in without changes.  I have been using VPATH with the

Right, but Autoconf does recognize VPATH. Recognizing VPATH is an
exception. Normally Autoconf would substitute words, but in case with
VPATH the whole line needs to be removed (BTW, why don't we rename VPATH
to HIDDEN_VPATH to avoid interfering with backslashed newlines?).

The reason for that is that some "make" programs would work incorrectly if
VPATH is defined.

The idea is to remove VPATH so that those who have really bad makes will
still be able to compile in the source directory. In other words, VPATH is
removed when it just triggers bugs but is not essential.

When a progect is built outside the source tree, VPATH is a must. In this
case Autoconf does not remove it. You need a decent make to compile
out-of-tree.

Not removing VPATH is an exception from an exception. It allows you to use
your specific VPATH at the expence of portability to the systems with bad
makes.

It is that "exception from an exception" that should not be relied upon,
because Autoconf does a poor job of determining whether VPATH should be
removed or not. It just looks at colons.

Ideally, Autoconf should rename VPATH to HIDDEN_VPATH if the original line
is exactly "address@hidden@" modulo spaces.

However, I'm concerned about backward compatibility with the projects like
yours.

> assumption that Automake would not touch my VPATH definition, and it
> currently works. Perhaps I don't understand the point of this thread,
> but if VPATH is destroyed by Automake, what is gained?  If Automake
> ignores VPATH, then everything works just fine.  So what was the
> problem? Currently I'm depending on VPATH not being molested by
> Autoconf, and it would be quite a hassle to undo that.

I understand that the layout of your project is very different from that
of standard-compliant GNU programs. You have a lot of options as long as
you are only concerned about one project, its development team and its
area of applicability. For example, you can define a variable to "VPATH"
and AC_SUBST it, you can require GNU make etc.

It's all luxury that Autoconf and Automake cannot afford.

Regards,
Pavel Roskin