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.
