Re: [RFA:] SUN make VPATH breakage at libsupc++ header installation

[Tom Tromey]

>>>>> ">" == Hans-Peter Nilsson <address@hidden> writes:

Tom> Automake has always adopted the rule that VPATH builds are
Tom> supported only with GNU make.

>> Why doesn't the automake documentation say so explicitly?

The automake documentation sucks.  Fixing it is (nearly) the only
thing holding back the 1.5 release.  Any and all constructive
criticism is welcome.  I've been doing a bit of work on the manual
every day lately.

>> Grepping for VPATH, I can only find this passage from INSTALL
>> (about srcdir != objdir): "To do this, you must use a version of
>> `make' that supports the `VPATH' variable, such as GNU `make'".

While automake distributes the INSTALL file, the text in it actually
doesn't come from automake.  I'm not sure whether I could edit this
text without asking RMS.

Tom> Vendor makes, including Sun, don't handle VPATH well enough to
Tom> use them.  I think if you look you'll discover that supporting
Tom> Sun make's VPATH would require adding little hacks all over
Tom> automake.

>> Again: there *are* little hacks.  For instance, lib/am/check.am,
>> check-TESTS.  Besides, I though automake was *supposed* to handle
>> such little hacks...

Both very good points!

In the past I've sometimes let SunOS make hacks enter automake.
That's true.

I looked up the old discussions again.  They are suprisingly vague.

You can see one here (adjacent to, guess what, a long thread about
maintainer mode :-):

    http://mail.gnu.org/pipermail/automake/1998-April/003421.html


I do agree that if it is reasonably possible, automake should handle
the details of working around Solaris make lossage.  We work around
plenty of bugs in other make variants.


I also did some testing on a Solaris box here.  Here is something to
show how losing that make really is:

    ferrule. cat Makefile 
    VPATH = ../src
    foo = foo.h
    joe = $(foo)
    fred = $(foo)

    out: $(joe)
            @echo $(fred)

    .PHONY: out
    ferrule. /usr/ccs/bin/make
    ../src/foo.h

I'm not sure how I could work around this.  I had thought I could
introduce a shadow variable for every install variable, and just use
the shadow in the rule.  The above shows that this won't work unless
the shadow fully copies the value of the other variable.  That seems
like a bad idea though.

Your suggestion (of using `p0' in the loop) won't really work in
automake 1.5, due to the introduction of the `nobase' feature.  You
can have, say, a header file like `sys/types.h' in the source tree and
ask for it to be installed as `$(includedir)/sys/types.h' -- that is,
automake will optionally not strip the directory part.  But with
Solaris make this gets much harder.

Maybe I could use `sed s/^.....//', where we compute the number of `.'
based on the string length of srcdir.  That seems like a lot of work.


Oh, wait, I found another example which I think makes it even less
likely that this can be made to work.  Try this:

    mkdir -p build S/include S/src
    echo x > S/include/x.h
    echo y > S/src/foo.c

    cat > build/Makefile << 'END'
    VPATH = ../S/src
    foo = foo.h
    joe = $(foo)
    fred = $(foo)

    out: $(joe) ../include/x.h
            @echo $(fred)

    .PHONY: out
    END

    cd build
    /usr/ccs/bin/make

I get this:

    make: Fatal error: Don't know how to make target `../include/x.h'

Now, automake's dependency tracking code probably won't generate a
dependency like `../include/x.h'.  It will generate something using
srcdir.  And, of course, we could change automake so that any
dependency it generates internally will have $(srcdir) prepended.  But
I don't think this is reasonable to expect users to do in their
Makefile.am.  That's particularly true because a line like:

    foo_SOURCES = ../generic/hash.c

Will be turned directly into a dependency (for dist, TAGS, and even
all in the case of `BUILT_SOURCES').  Requiring users to write
`$(srcdir)/../generic/hash.c' would be a hard sell.  Rewriting this
automatically is not really an option, since automake doesn't actually
know which files in a list might be found in srcdir or builddir.


So, I am skeptical that this can be done in a way that won't hurt
automake users.  If it can be done in a way that requires changes to
automake, but no changes to typical Makefile.ams, then I am happy to
listen.  Adding complexity to automake itself is not a problem, it is
when it affects Makefile.am that the problems occur.

Tom