GNU bug report logs - #13524
Improving user experience for non-recursive builds

Previous Next

Full log

Message #15 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Miles Bader <miles <at> gnu.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: Improving user experience for non-recursive builds
Date: Wed, 23 Jan 2013 15:54:04 +0900

Stefano Lattarini <stefano.lattarini <at> gmail.com> writes:
>> E.g., if I have a directory "foo" that has sources etc, and builds
>> some specific targets, then I can isolate the automake stuff for foo
>> by using an include file "foo/Makefile.am.inc" or something, and then
>> putting an appropriate include in the top-level Makefile.am.
>> 
>> But it's a bit annoying, in that AFAICT, all filenames, etc, in foo's
>> Makefile fragment must explicitly include the directory name.
>>
> Yes, and this issue has come up several times already.  Nobody has
> been bothered enough to attempt a patch, though, at least so far.
>
>> E.g., if it builds a library, "foo/Makefile.am.inc" might look like:
>> 
>>    libfoo_a_SOURCES = foo/oink.c foo/barf.c foo/barf.h ...
>> 
>> For longish directory names, this can really bloat things up...
>>
> Someone (probably Eric Blake, but I'm not 100% sure) once noted that this
> issue could be mitigated with simple indirections with usual make macros:
>
>   d1 = wow/a/very/very/insanely/long/directory/name
>
>   wow_a_very_very_insanely_long_directory_name_prog_SOURCES = \
>    $(d1)/a.c $(d1)/b.c ... $(d1)/z.c

Yes, that's the method I currently use, but it's pretty ugly, and kind
of fiddly -- you need to use a unique macro name for every subdir, and
practicality means probably using some variant of the directory name
for that... meaning you probably have longish variable names in
practice.

Ugliness is better than "broken" but frankly I don't want it; one of
automake's big attractions for me is that it allows one to write
highly readable makefiles that are more easily maintainable because of
their relative simplicity and lack of boilerplate (which hinders
readability by obscuring significant content).  Stuff like this feels
very similar to typical Makefile boilerplate, and I think makes for
more fragile, less maintainable Makefiles.

> This is probably too automatic; but Bob Friesenhahn suggested Automake
> could recognize special substitutions, like %CURDIR% and %XCURDIR%, so
> that you could simply use in
>
>     %XCURDIR%_prog_SOURCES = %CURDIR%/a.c %CURDIR%/b.c ... %CURDIR%/z.c

This is less fragile, but still pretty grotty, that's going to result
in makefile[-fragment]s that feel like they're full of boilerplate.

Really, I'm thinking about something _more_ magic.

I want to write filenames as I think about them:

  ..something...:  a.c b.c ... z.c

If something that does automagic munging of all filenames in a
makefile fragment is too magic, at least maybe this could be done with
some sort of simple rewrite mechanism to at least automake the common
factor.

E.g.:

  libfoo_SOURCES[libfoo/]: a.b b.c ... z.c

This sort of thing would have the advantage of being relatively
"stupid" (a simple explicit string rewrite), while still being able to
eliminate much of the redundancy...

Thanks,

-miles

-- 
「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.