Re: Detecting FreeBSD's make

[Ralf Wildenhues]

Hello Harlan, Paul,

* Harlan Stenn wrote on Wed, Nov 07, 2007 at 02:00:15AM CET:
> > On Tue, 2007-11-06 at 19:46 +0000, Harlan Stenn wrote:
> > > I'm getting bitten by the VPATH-handling differences between FreeBSD's
> > > make and gmake.
> > 
> > The automake manual says (somewhere) that the only version of make that
> > correctly supports out-of-the-tree builds is GNU make.  The VPATH
> > capability in every other version of make that I'm aware of, including
> > BSD make and SysV make, is just plain borked (IMNSHO).
> 
> IME, that position is excessive.  It was true, as far as I can recall,
> for SGI's make, but this is the first time this particular issue has
> bitten me (or any of the users of the package) in a *long* time.

Solaris 2.6 make is terminally borked as well for VPATH searches
including a subdir (foo_SOURCES = src/foo.c for example), but they
fixed that in 2.7.  However, even 2.10 has the VPATH rewriting
"feature" that's so much fun.

FreeBSD make has specific issues that the other BSDs' make
implementations do not have.  (It's been a release or two since I
checked FreeBSD's though, I use gmake there out of reflex.)

That said, the recommendation to only use GNU make for VPATH builds
(which is in recent INSTALL files) _is_ kind of a safeguard against
too many bug reports.

> > My personal suggestion would be to follow that advice and simply
> > document that out-of-the-tree builds are not supported by your project
> > unless the user uses GNU make.
> 
> That probably won't happen in this case - we'll either figure out the
> compatibility issue between bison and byacc or I'll figure out how to
> get the 2 files I need into the right build directory.

With the next (yet unreleased) Autoconf version, I think you should be
able to
  AC_CONFIG_LINKS([src/foo.y:src/foo.y])

which will create a link in the build tree if possible (and if VPATH).
I haven't tested this much yet for different make implementations, maybe
you want to limit doing that for non-GNU make.  And then there may be
one or the other odd bug in Automake where 'dist' will pick up the wrong
generated file.

> > It's very difficult for autotools to detect and work around make issues,
> > because there's absolutely no guarantee that the "make" program that
> > autoconf/etc. finds and uses will be the one the user actually invokes
> > to build the project.  Users are not accustomed to saying "./configure
> > MAKE=gmake" or similar.
> 
> As far as I'm concerned, the version of 'make' that is found by
> configure will be the same 'make' that the user invokes.  If that is not
> the case and I hear about it I will lart the user.

Good strategy!  :-)

* Paul Smith wrote on Wed, Nov 07, 2007 at 02:48:57AM CET:
> On Wed, 2007-11-07 at 01:00 +0000, Harlan Stenn wrote:
> > IME, that position is excessive.  It was true, as far as I can recall,
> > for SGI's make, but this is the first time this particular issue has
> > bitten me (or any of the users of the package) in a *long* time.
> 
> Hm.  Maybe automake works around it better than it used to.

It tries hard to get around Solaris VPATH rewriting at least.

> IIRC, the problem is that in SysV make (and perhaps in BSD make although
> I confess I've not played with it much), a number of the normal
> automatic variables are not defined for explicit rules; they're only
> defined for suffix rules.  And if the automatic variables are not
> defined, then you can't find out what the VPATH'd pathname is for those
> files.

Well, automake knows that VPATH contains $(srcdir), so that's what the
rules compare with.

> So, the upshot is VPATH just doesn't work with explicit rules, which is
> not good.

Are you saying that as conclusion of the preceding paragraph, or is
there another reason?

> There may have been other problems with VPATH as well.

OK, well, if there are any that are not listed in
<http://www.gnu.org/software/autoconf/manual/html_node/VPATH-and-Make.html>
or the chapter around it, then we'd like to learn about them.

Cheers,
Ralf