* 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
