Re: Feature request

[Akim Demaille]

Le 23 sept. 08 à 23:08, Ralf Wildenhues a écrit :

> Hi Akim,

Hi Ralf!

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


> > yet it would be quite easier to have some variable
> > that would expand to the prefix of the included file.
>
> Sounds like a reasonable wish.  Let's look at an example.
> 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.

> Example:
>
>  --- Makefile.am ---
>  include foo/local1.mk
>
>  --- foo/local1.mk ---
>  # 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 :(

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

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

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

> And yes, if the resulting snippets are to be usable also from the same
> directory, then most usages need AMPREFIX and not AMSUB, if non-GNU  
> make
> should work well, too.  This is probably not easy on users.

Agreed.

> > Thanks for the good work!
>
> Thanks for the feedback, and the suggestion.
>
> > [1] whatever the name, but not too long.  Maybe a symbol, $/ for
> > instance.
>
> I'd really hate to invade make's namespace.  They may come up with  
> this
> really cool new makefile variable, and we can't use it then.  :-/

Unless we can spell it (read "escape") differently.