magic variables for included fragments (was: Feature request)

[Ralf Wildenhues]

* Akim Demaille wrote on Wed, Sep 24, 2008 at 10:01:01AM CEST:
> Le 23 sept. 08 à 23:08, Ralf Wildenhues a écrit :
>> * Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST:
>>>
>>> I'm slowly getting rid of my recursive Makefiles.  Instead I have one
>>> local.mk per directory, and a few Makefile.ams that include them.  Of
>>> course I have to prefix all my file names with the name of the
>>> directory, and I find that this explicit name is actually clutter.  I
>>> don't think automake can be educated to guess by itself where to  
>>> prepend the directory name,
>>
>> I agree that that would be too much magic, and probably too fragile.
>
> Yet that would be wonderful to have a means to tell Automake to make a  
> single large Makefile instead of several ones.  It can't do it all by  
> itself, but if the Makefile.ams are sufficiently complete, it might be  
> doable.  Then the magic from Automake would be mostly to give a local  
> and magic value to $(srcdir) $(builddir) etc.  Which is basically what  
> I'm suggesting here.

Hmm.  I don't see how that would be feasible in practice.  Maybe I would
need a more concrete set of hints.

For example, how can you know whether
  -I$(srcdir)

is relative to the fragment source dir, or the included Makefile.am one?
Likewise '-I..'.

>> Probably you want a set of these:
>>
>> - one for the full relative path to the Makefile.am  (%AMSUB%=foo/bar)
>>  (this one would be '.' if in the same directory)
>> - likewise, including final slash (%AMPREFIX%=foo/bar/)
>>  (needed if the prefix can also be empty, to avoid './')
>> - likewise, but flattened (%AMFLAT%=foo_bar_)
>> - reverse of the full relative path (%AMREV%=../..)
>> - maybe a set of these for only the path to the next included snippet?
>> - would that be enough for all use cases?
>
> Yes, I think it would.
>
> Another option would be to provide local variables, scoped to the  
> current local.mk and the one it includes, with traditional scoping.   
> Automake itself could rely on this to define these magic variables.

How would that be different from my approach?  Maybe I just haven't
understood it yet.

>>  # Yes, it is very ugly and IMNSHO an automake misfeature that
>>  # the next line requires an %AMPREFIX%.  Unfortunately, fixing
>>  # it would break user's scripts.
>>  include %AMPREFIX%bar/local2.mk
>
> Bummer :(

Well.  I'm a bit undecided here myself.

On the one hand, the current documentation explicitly only mentions
the cases
  include $(top_srcdir)/file
  include $(srcdir)/file

and nothing else.  So we /could/ in theory blame it on the user, the
non-prefixed case being undefined before (*and* most users expecting
different anyway).

On the other hand, allowing relative paths in `include' statements but
not in other statements is a bit inconsistent, isn't it?

(What we could do anyway would be to warn if the choice is ambiguous.)

>>  --- foo/bar/local2.mk ---
>>  FOO_FLAGS = -I%AMREV%/include
>
> I would not promote too much AMREV.  In my experience it's always  
> clearer and safer to start from top_src/builddir rather than trying to  
> play these tricks.

Hmm.  Still thinking about cases where you cannot avoid it.  Can you
think of one?  Otherwise, maybe we shouldn't even define it?

>>  bin_PROGRAMS = %AMPREFIX%bar
>>  %AMFLAT%bar_SOURCES = %AMPREFIX%bar.c %AMPREFIX%baz.c
>>
>> Yuck.  That's already quite ugly, nothing I'd want to edit regularly.
>> We could use even shorter abbreviations.  Suggestions?
>
> For a start, if you really do not want to use the $() syntax, maybe we  
> can move to something like %()?  Or $[]?  Provided we give a means to  
> the user to write '$[' when she means it, I'm not sure that would be  
> really such a problem to infringe on the Make "name space".
>
> %FOO% is hard to read when there are many, braces are much easier to  
> read.

Agreed.

> Also, we can stick to $(), but within Automake's "namespace".  Say $ 
> (AMPREFIX) instead of %AMPREFIX%.

I'll follow up on automake-patches with a patch to test.  I didn't get
AM_INC_{SUBDIR,PREFIX,CANON,REVERSE} to work yet, only
AM_{SUBDIR,PREFIX,CANON,REVERSE}.  And I have no documentation yet.  Is
there a volunteer for it?  I fear documentation is the hardest part of
this, by far.  And I still hate the naming, better suggestions dearly
appreciated.

Thanks,
Ralf