Subject: bug#13524: closed (Re: bug#13524: [PATCH 0/2] Improving user experience for non-recursive builds)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 05 Mar 2013 16:34:02 +0000

Your bug report

#13524: Improving user experience for non-recursive builds

which was filed against the automake package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
13524: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13524
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#13524: [PATCH 0/2] Improving user experience for non-recursive builds
From: Stefano Lattarini <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 05 Mar 2013 17:32:49 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

On 02/23/2013 06:47 PM, Stefano Lattarini wrote:
> On 02/14/2013 11:26 AM, Stefano Lattarini wrote:
>>
>> OK, done.  If there are no further objections, I will soon proceed to
>> re-write the experimental/preproc branch once again with the latest
>> version of these patches;
>>
> This has been done already.
> 
>> then we can think when and how to merge it
>> into 'master' or 'next' (the merge will be delayed until the discussion
>> about the new branching/versioning scheme for automake has been sorted
>> out; see <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>).
>>
> That discussion has been sorted out;
>
Well, not really, we are stuck with the old branch naming scheme (I messed
up causing non-fast-forward pushes, but that is fixed now; refer to the
report linked above for more details).  So ...

> I propose to merge this patches,
> which are mostly safe an unobtrusive, in the 'master' branch, so that
> they will appear in the next minor Automake version (1.14).
>
... these patches should now be merged in the *maint* branch, since that
is the one from where the Automake 1.14 release will be cut.  I've done
that already.

I'm thus closing this report.

Regards,
  Stefano

Subject: Improving user experience for non-recursive builds
From: Stefano Lattarini <[email-masked]>
To: Miles Bader <[email-masked]>
Cc: Bob Friesenhahn <[email-masked]>, [email-masked], Karl Berry <[email-masked]>
Date: Tue, 22 Jan 2013 10:18:29 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

[+cc bug-automake, so that we won't forget about the issue]
[future replies should drop the automake list]

On 01/22/2013 02:22 AM, Miles Bader wrote:
> Stefano Lattarini <[email-masked]> writes:
>> The best solution is on the user-side IMHO: fix the build system to
>> use less (ideally none) make recursion.  Both the parallel and serial
>> testsuite harness should support that setup OOTB.
> 
> It would be nice if automake had some more features for that...
>
Indeed (albeit the present situation is already mostly good enough
for most medium-sized packages).

> 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

> It would be really cool if there was some way of telling automake
> "hey, for every filename mentioned in this file, try to use a prefix
> of ..."
>
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

in 'wow/a/very/very/insanely/long/directory/name/local,.mk', include this
'.mk' fragment from the top-level Makefile.am, and have DTRT.  I think
that could be implemented in a simple pre-processing step, before
Automake even parses the Makefile contents (this too was Bob's suggestion,
IIRC); in which case, the change would probably be unobtrusive and mostly
safe.  Patches (even WIP) are welcome.

> I dunno whether that would be associated with the include
> directive, with the makefile fragment, or what, but... anyway.
> 
> Does automake have some feature like this that I've missed?
>
Unfortunately no.

> Or has anybody thought about it?
>
They did (see above :-)

Thanks,
  Stefano