Re: Patch for autoconf/145

[Pavel Roskin]

Hello, Akim!

> Why not, I have no strong opinion.
>
> I have one desire though: avoid any kind of magic.  Why do we have to
> do all this, I have still not understood.  If the user wants to shoot
> in its foot, then Autoconf should not prevent it.

Good point, but it doesn't invalidate the patch.

> Now, Automake issues that VPATH.  Why?  Why don't we have the same
> approach as for any other variable: AC_SUBST?  Yep, OK, there is the
> problem of *completely* getting rid of VPATH.  Then how about the
> approach used with SET_MAKE?  Or with AMDEP?
>
> @address@hidden = @VPATH
>
> or
>
> @SET_VPATH@

That's a good idea. However, some old makefiles (or makefiles generated by
Automake we introduce it) rely on Autoconf removing VPATH.

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?

It should be in Automake (e.g. in AM_INIT_AUTOMAKE) to eliminate
compatibility issues, but non-Automake users may want to use @SET_VPATH@
as well, especially if setting VPATH will be deprecated.

> Really, I have not understood why we needed something particular about
> VPATH :(  I dislike very much black magic as above.  Which is not a
> `no', just a `yuck'.

I don't like that magic either. I believe there are historic reasons -
Autoconf promoted VPATH use to enable out-of-tree builds, but then it was
found that some makes have problems with it. It was too late to switch
everybody to a better scheme, so Autoconf just started removing VPATH.

Regards,
Pavel Roskin