Re: Detecting FreeBSD's make

[Harlan Stenn]

Hey folks,

I found the code I was using to detect broken vpath support.

The culprits seemed to be:

 *-*-irix6.2 (and later. ie, *-*-irix6.1* was OK)
 solaris2.5.1
 *-*-unicosmp

And just to reaffirm, I agree with Ralf that the particular issue has to
do with the way FreeBSD avoids (as I understand it) using VPATH searches
for built files.

Thomas Dickey says his latest byacc includes fixes that are not in the
stock FreeBSD byacc and he does not get the problem I do with his code.

I expect this particular situation (like so many others) is a 'wart'
that will only be seen for a certain period of time.

H

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 +, 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 +, 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

or the chapter around it, then we'd like to learn about them.

Cheers,
Ralf 

Re: Detecting FreeBSD's make

[Paul Smith]

On Wed, 2007-11-07 at 01:00 +, 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.

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.

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

There may have been other problems with VPATH as well.


This is from my increasingly dodgy memory so I could be wrong on
particulars.

Cheers!

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.us
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

Re: Detecting FreeBSD's make

[Harlan Stenn]

Paul,

Thanks for your response.

> On Tue, 2007-11-06 at 19:46 +, 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.

> 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.

> 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.

And I had code in configure.ac to see if 'make' was gmake or not and I
removed that code when ancient SGI (if that's what it was) went away.  I
can always "recover" that old code.

H

Re: Detecting FreeBSD's make

[Paul Smith]

On Tue, 2007-11-06 at 19:46 +, 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).

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.

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.

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.us
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

Detecting FreeBSD's make

[Harlan Stenn]

I'm getting bitten by the VPATH-handling differences between FreeBSD's
make and gmake.

I have a .y file and I currently distribute the bison-generated .[ch]
files in the distribution.

On a stock FreeBSD machine (at least) when doing a build outside of the
source tree, FreeBSD's make doesn't see the corresponding .y->.[ch]
files from its vantage point in the builddir, so it fires up byacc to
generate the files.

The byacc-generated parser code is different from what bison produced,
and we get a "syntax error" parsing the target file.  Yes, we want to
find and fix this discrepancy.  We also want to improve the parsing
error messages.

And as a work-around (at least), if I can detect that the build
environment is using a 'make' that has this VPATH difference, I can go
ahead and copy/link the generated .[ch] files from the srcdir into the
builddir and also "solve" the problem that way.

Thoughts/suggestions?

H