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

[Hans-Peter Nilsson]

> From: Tom Tromey <address@hidden>
> Date: 02 Jun 2001 12:07:26 -0600

Tom, thank you for your well-written reply.  Though I'm a little
more optimistic about the feasibility of (restricted) SUN make
compatibility, perhaps because I'm not planning to do the actual
work in automake. :-]

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

Besides, that won't work either.  What you showed follows from
the SUN make manpage I quoted previously; it's the *expansion*
of the rule that matters.  A bit scary is that when there's a
VPATH and srcdir != objdir, "compatible" dependencies must not
have a name that is something you would find in a rule, like
"cc", "test", "sed", "true", "case", "if", not to mention
options.  Thankfully, most dependencies aren't so, and perhaps
automake could even do some limited checking if it looks like
things would otherwise be compatible.

>  Requiring users to write
> `$(srcdir)/../generic/hash.c' would be a hard sell.

Right, but then those users not willing to pay will not get SUN
make (and perhaps others) compatibility; it's no worse than
that.  Perhaps some warning with --verbose would be in order if
automake can't make sure about its unique location when it sees
a "../foo" dependency.

> I am skeptical that this can be done in a way that won't hurt
> automake users.

Arguably not in the general case, but perhaps with some
restrictions on using automake features that hopefully will not
hurt too many too much.  If documented, people using automake
would know that if they want universal make compatibility, they
would have to give up, for example (briefly, based on what you
wrote):

- Using non-GNU make for anything else than a
  "make all && make install".

- Having ../foo/bar dependencies; maybe only in some cases.
  Perhaps it is enough if people add $(srcdir) or $(objdir) to
  the rules they write themselves.

- Having nobase_include_HEADERS.

Perhaps it would do good to mention that these restrictions are
the ones *known*, suggesting that people send fixes or reports
if they find other problems or restrictions.

For the header installation issue I'm trying to patch up, there
seems to be low-hanging fruit compatibilitywise in tweaking the
rule for the non-nobase case.

brgds, H-P