Re: Enhancing nobase_

[Ralf Wildenhues]

Hi Akim,

* Akim Demaille wrote on Thu, Mar 19, 2009 at 10:53:11AM CET:
> nobase_ is really a nice feature to cope with a structured hierarchy of 
> files.  But it does not work well with packages that avoid recursive 
> Makefiles.

It is normally not a good thing to avoid recursive makefiles at all
costs.  Use them when they help, avoid them otherwise.  You can go
partly nonrecursive in your tree.  (Of course you knew all that ... ;-)

> It would be nice if there were a means to use nobase_, but to be able to 
> declare the base.  Maybe

> include_BASE = include/
>
> or something like that.  Actually, it would leave less clutter in the  
> Makefile if the include_BASE was *added* where needed, rather than  
> removed for install.  Instead of
>
> include_HEADERS = include/foo.hh include/bar.hh
>
> it would read
>
> base_include_HEADERS = include/
> nobase_include_HEADERS = foo.hh bar.hh
>
> and automake would generate include_HEADERS as include/foo.hh include/ 
> bar.hh.

And I assume that the files in the source tree were include/foo.hh and
include/bar.hh, and what you're really after is abbreviating source tree
subdirectories, not install tree subdirectories.  Right?

Well, we keep coming back to this issue, and related ones, remember the
$(AM_PREFIX) idea?  I haven't forgotten about it completely, but I think
I would like to postpone it to after 1.11.

Back to this particular idea.  Here's why I don't think it's a good one:

It is another instance where automake rewrites the variables provided by
the user.  Even if nobase_include_HEADERS and base_include_HEADERS were
munged to produce an include_HEADERS variable: it's in fact a rewriting
that happens.  And every rewriting is fundamentally bad: it precludes
@substitutions@, it disallows using variables as prerequisites or
targets in plain `make' rules, and otherwise causes all kinds of
headaches.  For your example above: $(nobase_include_HEADERS) could not
be used as a prerequisite anywhere, the files do not exist at this
location.

So, as convenient as it may seem, this just isn't going to cut it IMVHO.
The bad experience that $(EXEEXT) rewriting has been, makes me want to
refrain from adding more than necessary.

You'd probably live quite easily with
  sub1includedir = $(includedir)/sub1
  sub1include_HEADERS = include/foo.hh include/bar.hh ...
  sub2includedir = $(includedir)/sub2/subsub
  sub2includedir_HEADERS = ...

and for a more general solution of not having to provide too long path
names on the right hand side of the *_HEADERS settings, I like the
postponed $(AM_PREFIX) idea better than this above.  With $(AM_PREFIX)
at least, it is crystal clear which part of a variable will be rewritten,
it can appear as prerequisite or target, and @substitutions@ are easier
spotted as outsiders.

Cheers, and sorry,
Ralf