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

Previous Next

Full log

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Miles Bader <miles <at> gnu.org>
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 13:27:43 +0100

Hello Miles, thanks for the feedback.

On 01/23/2013 07:54 AM, Miles Bader wrote:
> 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,
>
Yes, that is annoying and somewhat fragile.

> 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,
>
Which is a step forward at least; and since it appears it might be very
easy to implement and fit in the existing automake processing scheme, I'm
willing to give it a try.  Further improvements and refinement might go
on the top of that.

> 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.
>
It might be nice to do so as a second step, but I'd rather not have
the best be the enemy of the good; we can make the Makefiles less
fragile *today*, and make them less "boilerplatish" tomorrow.

> 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 could be "syntactic sugar" that we might add after the improvement
suggested above; in fact, the two things could eventually compound to
allow usages like:

  libfoo_SOURCES[%CURDIR%] = a.c 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...
> 
I'm not opposed to the idea, but I see it as a second step, after the
improvement we are discussing.  A second step for which patches are,
as usual, welcome :-)

> Thanks,
> 
> -miles
> 

Thanks, and best regards,
  Stefano

Previous Next

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