GNU bug report logs -
#13524
Improving user experience for non-recursive builds
Previous Next
Reported by: Miles Bader <miles <at> gnu.org>
Date: Tue, 22 Jan 2013 09:20:02 UTC
Severity: wishlist
Tags: patch
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Tue, 05 Mar 2013 17:32:49 +0100
with message-id <51361E31.4090608 <at> gmail.com>
and subject line Re: bug#13524: [PATCH 0/2] Improving user experience for non-recursive builds
has caused the debbugs.gnu.org bug report #13524,
regarding Improving user experience for non-recursive builds
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
13524: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13524
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[+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 <stefano.lattarini <at> gmail.com> 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
[Message part 3 (message/rfc822, inline)]
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
This bug report was last modified 12 years and 131 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.