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: Fri, 23 Feb 2001 14:15:58 -0500 (EST)

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




reply via email to

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