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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13524 in the body.
You can then email your comments to 13524 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Tue, 22 Jan 2013 09:20:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefano Lattarini <stefano.lattarini <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org.
(Tue, 22 Jan 2013 09:20:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[+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
Changed bug submitter to 'Miles Bader <miles <at> gnu.org>' from 'Stefano Lattarini <stefano.lattarini <at> gmail.com>'
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Tue, 22 Jan 2013 09:31:01 GMT)
Full text and
rfc822 format available.
Severity set to 'wishlist' from 'normal'
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Tue, 22 Jan 2013 09:31:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Tue, 22 Jan 2013 10:24:01 GMT)
Full text and
rfc822 format available.
Message #12 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2013-01-22 10:18, Stefano Lattarini wrote:
> [+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.
This is proof of concept, and I'm not a perl hacker etc, but it seems to
work ok. Feel free to improve or toss or add documentation or whatever :-)
Patch is based on the maint branch, but being a new feature it perhaps
belongs on master instead. But as I said, do what you want with it...
Cheers,
Peter
[0001-reldir-Add-support-for-relative-names-in-included-fr.patch (text/x-patch, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Wed, 23 Jan 2013 06:56:02 GMT)
Full text and
rfc822 format available.
Message #15 received at submit <at> debbugs.gnu.org (full text, mbox):
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
--
「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Wed, 23 Jan 2013 12:30:02 GMT)
Full text and
rfc822 format available.
Message #18 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Wed, 23 Jan 2013 12:47:02 GMT)
Full text and
rfc822 format available.
Message #21 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Peter, thanks for the patch.
Not sure if you are in the mood (or have the time) to engage in a
discussion about it, but here my review anyway. Even if you are not
going to work on this patch anymore, a review will still be useful
as a reference to me or other developers in the future.
On 01/22/2013 11:22 AM, Peter Rosin wrote:
> From 5cc9c775dbe46343b651a7e6ac378f71e6a3b6c1 Mon Sep 17 00:00:00 2001
> From: Peter Rosin <peda <at> lysator.liu.se>
> Date: Tue, 22 Jan 2013 11:17:11 +0100
> Subject: [PATCH] reldir: Add support for relative names in included fragments
>
A nice explanation of the ratioanle for this change is a must I think.
Also, we should add reference to this discussion (and related bug number),
as well give credit where's its due (this idea was Bob's brainchild).
> automake.in (read_am_file): Add third argument specifying the
> relative directory of this makefile fragment compared to the
> main level makefile. Replace @am_reldir@ in the fragment with
> this relative directory.
>
Using @acsubst@ style substitutions for something that is not substituted
by config.status has proven a bad idea in the patch. We should use a new
syntax, like '%subst%', ot even '&{subst}&'; personally, I like this latter
best, since it help distinguish between Automake internal %TRASFORMS% from
this new kind of special user-reserved substitution.
> (read_main_am_file): Adjust.
> t/reldir.sh: New test.
> t/list-of-tests.mk: Augment.
> ---
> automake.in | 28 +++++++++++++++++----
> t/list-of-tests.mk | 1 +
> t/reldir.sh | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 92 insertions(+), 5 deletions(-)
> create mode 100755 t/reldir.sh
>
> diff --git a/automake.in b/automake.in
> index 0e3b882..4e52aca 100644
> --- a/automake.in
> +++ b/automake.in
> @@ -6330,15 +6330,15 @@ sub check_trailing_slash ($\$)
> }
>
>
> -# &read_am_file ($AMFILE, $WHERE)
> -# -------------------------------
> +# &read_am_file ($AMFILE, $WHERE, $RELDIR)
> +# ----------------------------------------
> # Read Makefile.am and set up %contents. Simultaneously copy lines
> # from Makefile.am into $output_trailer, or define variables as
> # appropriate. NOTE we put rules in the trailer section. We want
> # user rules to come after our generated stuff.
> sub read_am_file ($$)
> {
> - my ($amfile, $where) = @_;
> + my ($amfile, $where, $reldir) = @_;
>
> my $am_file = new Automake::XFile ("< $amfile");
> verb "reading $amfile";
> @@ -6423,6 +6423,18 @@ sub read_am_file ($$)
>
> my $new_saw_bk = check_trailing_slash ($where, $_);
>
> + if ($reldir ne '.')
> + {
> + my $rel_dir = &canonicalize ($reldir);
> + $_ =~ s/\@am_reldir\@\//${reldir}\//g;
> + $_ =~ s/\@am_reldir\@_/${rel_dir}_/g;
> + }
> + else
> + {
> + $_ =~ s/\@am_reldir\@\///g;
> + $_ =~ s/\@am_reldir\@_//g;
> + }
> +
Too much automagic here IMO. We'd better have two distinct subst, one for
the "real" directory name, and one for the directory name "canonicalized"
for use in Automake primaries. I.e., from:
# In sub/sub2/local.mk
bin_PROGRAMS = sub/sub2/my-prog
sub_sub2_my_prog_SOURCES = sub/sub2/main.c sub/sub2/compat.c
to:
# In sub/sub2/local.mk
bin_PROGRAMS = &{CURDIR}&/my-prog
&{CANON_CURDIR}&_my_prog_SOURCES = &{CURDIR}&/main.c &{CURDIR}&/compat.c
Aa for what should be the actual names of this substitutions (I realize
the names above kinda suck), suggestions are welcome.
> if (/$IGNORE_PATTERN/o)
> {
> # Merely delete comments beginning with two hashes.
> @@ -6584,8 +6596,14 @@ sub read_am_file ($$)
> push_dist_common ("\$\(srcdir\)/$path");
> $path = $relative_dir . "/" . $path if $relative_dir ne '.';
> }
> + my $new_reldir = $path;
> + # $new_reldir =~ s/\$\($reldir\)\///;
> + if ($new_reldir =~ s/\/[^\/]*$// == 0)
>
This is probably better written as:
if ($new_reldir !~ s,/[^/]*$,,)
> + {
> + $new_reldir = '.';
> + }
> $where->push_context ("'$path' included from here");
> - &read_am_file ($path, $where);
> + &read_am_file ($path, $where, $new_reldir);
> $where->pop_context;
> }
> else
> @@ -6658,7 +6676,7 @@ sub read_main_am_file ($$)
> &define_standard_variables;
>
> # Read user file, which might override some of our values.
> - &read_am_file ($amfile, new Automake::Location);
> + &read_am_file ($amfile, new Automake::Location, '.');
> }
>
> [SNIP good testsuite addition]
>
I really like how simple and unobtrusive this patch is!
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Wed, 23 Jan 2013 14:37:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 13524 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2013-01-23 13:45, Stefano Lattarini wrote:
> Hi Peter, thanks for the patch.
>
> Not sure if you are in the mood (or have the time) to engage in a
> discussion about it, but here my review anyway. Even if you are not
> going to work on this patch anymore, a review will still be useful
> as a reference to me or other developers in the future.
Well, apparently I was in the mood and found some more time :-)
> On 01/22/2013 11:22 AM, Peter Rosin wrote:
>> From 5cc9c775dbe46343b651a7e6ac378f71e6a3b6c1 Mon Sep 17 00:00:00 2001
>> From: Peter Rosin <peda <at> lysator.liu.se>
>> Date: Tue, 22 Jan 2013 11:17:11 +0100
>> Subject: [PATCH] reldir: Add support for relative names in included fragments
>>
> A nice explanation of the ratioanle for this change is a must I think.
>
> Also, we should add reference to this discussion (and related bug number),
> as well give credit where's its due (this idea was Bob's brainchild).
And a NEWS entry, and docs. That part is less fun.
>> automake.in (read_am_file): Add third argument specifying the
>> relative directory of this makefile fragment compared to the
>> main level makefile. Replace @am_reldir@ in the fragment with
>> this relative directory.
>>
> Using @acsubst@ style substitutions for something that is not substituted
> by config.status has proven a bad idea in the patch. We should use a new
> syntax, like '%subst%', ot even '&{subst}&'; personally, I like this latter
> best, since it help distinguish between Automake internal %TRASFORMS% from
> this new kind of special user-reserved substitution.
>
>> (read_main_am_file): Adjust.
>> t/reldir.sh: New test.
>> t/list-of-tests.mk: Augment.
>> ---
>> automake.in | 28 +++++++++++++++++----
>> t/list-of-tests.mk | 1 +
>> t/reldir.sh | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 92 insertions(+), 5 deletions(-)
>> create mode 100755 t/reldir.sh
>>
>> diff --git a/automake.in b/automake.in
>> index 0e3b882..4e52aca 100644
>> --- a/automake.in
>> +++ b/automake.in
>> @@ -6330,15 +6330,15 @@ sub check_trailing_slash ($\$)
>> }
>>
>>
>> -# &read_am_file ($AMFILE, $WHERE)
>> -# -------------------------------
>> +# &read_am_file ($AMFILE, $WHERE, $RELDIR)
>> +# ----------------------------------------
>> # Read Makefile.am and set up %contents. Simultaneously copy lines
>> # from Makefile.am into $output_trailer, or define variables as
>> # appropriate. NOTE we put rules in the trailer section. We want
>> # user rules to come after our generated stuff.
>> sub read_am_file ($$)
>> {
>> - my ($amfile, $where) = @_;
>> + my ($amfile, $where, $reldir) = @_;
>>
>> my $am_file = new Automake::XFile ("< $amfile");
>> verb "reading $amfile";
>> @@ -6423,6 +6423,18 @@ sub read_am_file ($$)
>>
>> my $new_saw_bk = check_trailing_slash ($where, $_);
>>
>> + if ($reldir ne '.')
>> + {
>> + my $rel_dir = &canonicalize ($reldir);
>> + $_ =~ s/\@am_reldir\@\//${reldir}\//g;
>> + $_ =~ s/\@am_reldir\@_/${rel_dir}_/g;
>> + }
>> + else
>> + {
>> + $_ =~ s/\@am_reldir\@\///g;
>> + $_ =~ s/\@am_reldir\@_//g;
>> + }
>> +
> Too much automagic here IMO. We'd better have two distinct subst, one for
> the "real" directory name, and one for the directory name "canonicalized"
> for use in Automake primaries. I.e., from:
The gain was that the '.' case needs to peak at, and perhaps eat, the
trailing separator anyway (or it will look bad, I mean, who wants __foo
after writing &{CANON_CURDIR}&_foo and curdir happens to be '.'?)
> # In sub/sub2/local.mk
> bin_PROGRAMS = sub/sub2/my-prog
> sub_sub2_my_prog_SOURCES = sub/sub2/main.c sub/sub2/compat.c
>
> to:
>
> # In sub/sub2/local.mk
> bin_PROGRAMS = &{CURDIR}&/my-prog
> &{CANON_CURDIR}&_my_prog_SOURCES = &{CURDIR}&/main.c &{CURDIR}&/compat.c
>
> Aa for what should be the actual names of this substitutions (I realize
> the names above kinda suck), suggestions are welcome.
After a short brainstorm, I went with &{CUR/DIR}& and &{CUR_DIR}&, but
I'm not totally satisfied with the / version as it doesn't look "natural".
But it is self explanatory, kind of. I'm not attached to the naming in
any way, but &{CANON_CURDIR}& is too long IMHO.
>> if (/$IGNORE_PATTERN/o)
>> {
>> # Merely delete comments beginning with two hashes.
>> @@ -6584,8 +6596,14 @@ sub read_am_file ($$)
>> push_dist_common ("\$\(srcdir\)/$path");
>> $path = $relative_dir . "/" . $path if $relative_dir ne '.';
>> }
>> + my $new_reldir = $path;
>> + # $new_reldir =~ s/\$\($reldir\)\///;
>> + if ($new_reldir =~ s/\/[^\/]*$// == 0)
>>
> This is probably better written as:
>
> if ($new_reldir !~ s,/[^/]*$,,)
Yes, looks better. I haven't bothered to look up the perl doc that
spells out exactly why it is equivalent, but I'll trust you on
that.
>> + {
>> + $new_reldir = '.';
>> + }
>> $where->push_context ("'$path' included from here");
>> - &read_am_file ($path, $where);
>> + &read_am_file ($path, $where, $new_reldir);
>> $where->pop_context;
>> }
>> else
>> @@ -6658,7 +6676,7 @@ sub read_main_am_file ($$)
>> &define_standard_variables;
>>
>> # Read user file, which might override some of our values.
>> - &read_am_file ($amfile, new Automake::Location);
>> + &read_am_file ($amfile, new Automake::Location, '.');
>> }
>>
>> [SNIP good testsuite addition]
>>
>
> I really like how simple and unobtrusive this patch is!
Yes, it was simpler than I anticipated. After posting I noticed that
some project (was it coreutils?) used "include $(srcdir)/foo/local.mk"
and figured my changes wouldn't support that. But that works too, I
don't know why though. (not that I'm complaining)
Updated patch attached, I renamed it to curdir instead of reldir (and
sorry for not dropping the automake list last time around).
Cheers,
Peter
[0001-curdir-add-support-for-relative-names-in-included-fr.patch (text/x-patch, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Wed, 23 Jan 2013 15:11:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 01/23/2013 03:34 PM, Peter Rosin wrote:
> On 2013-01-23 13:45, Stefano Lattarini wrote:
>> Hi Peter, thanks for the patch.
>>
>> Not sure if you are in the mood (or have the time) to engage in a
>> discussion about it, but here my review anyway. Even if you are not
>> going to work on this patch anymore, a review will still be useful
>> as a reference to me or other developers in the future.
>
> Well, apparently I was in the mood and found some more time :-)
>
>> On 01/22/2013 11:22 AM, Peter Rosin wrote:
>>> From 5cc9c775dbe46343b651a7e6ac378f71e6a3b6c1 Mon Sep 17 00:00:00 2001
>>> From: Peter Rosin <peda <at> lysator.liu.se>
>>> Date: Tue, 22 Jan 2013 11:17:11 +0100
>>> Subject: [PATCH] reldir: Add support for relative names in included fragments
>>>
>> A nice explanation of the ratioanle for this change is a must I think.
>>
>> Also, we should add reference to this discussion (and related bug number),
>> as well give credit where's its due (this idea was Bob's brainchild).
>
> And a NEWS entry, and docs.
>
Yes, but I've found out those can often be written in follow-up patches
without too much churn or "history confusion"; OTOH, writing a clear and
complete commit message is essential, especially for a new feature.
> That part is less fun.
>
As for myself, I've actually reached a point where I find writing commit
messages quite interesting. And I'm mostly neutral on NEWS entries.
But of course, writing documentation sucks ;-)
>>> automake.in (read_am_file): Add third argument specifying the
>>> relative directory of this makefile fragment compared to the
>>> main level makefile. Replace @am_reldir@ in the fragment with
>>> this relative directory.
>>>
>> Using @acsubst@ style substitutions for something that is not substituted
>> by config.status has proven a bad idea in the patch. We should use a new
>> syntax, like '%subst%', ot even '&{subst}&'; personally, I like this latter
>> best, since it help distinguish between Automake internal %TRASFORMS% from
>> this new kind of special user-reserved substitution.
>>
>>> (read_main_am_file): Adjust.
>>> t/reldir.sh: New test.
>>> t/list-of-tests.mk: Augment.
>>> ---
>>> automake.in | 28 +++++++++++++++++----
>>> t/list-of-tests.mk | 1 +
>>> t/reldir.sh | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 92 insertions(+), 5 deletions(-)
>>> create mode 100755 t/reldir.sh
>>>
>>> diff --git a/automake.in b/automake.in
>>> index 0e3b882..4e52aca 100644
>>> --- a/automake.in
>>> +++ b/automake.in
>>> @@ -6330,15 +6330,15 @@ sub check_trailing_slash ($\$)
>>> }
>>>
>>>
>>> -# &read_am_file ($AMFILE, $WHERE)
>>> -# -------------------------------
>>> +# &read_am_file ($AMFILE, $WHERE, $RELDIR)
>>> +# ----------------------------------------
>>> # Read Makefile.am and set up %contents. Simultaneously copy lines
>>> # from Makefile.am into $output_trailer, or define variables as
>>> # appropriate. NOTE we put rules in the trailer section. We want
>>> # user rules to come after our generated stuff.
>>> sub read_am_file ($$)
>>> {
>>> - my ($amfile, $where) = @_;
>>> + my ($amfile, $where, $reldir) = @_;
>>>
>>> my $am_file = new Automake::XFile ("< $amfile");
>>> verb "reading $amfile";
>>> @@ -6423,6 +6423,18 @@ sub read_am_file ($$)
>>>
>>> my $new_saw_bk = check_trailing_slash ($where, $_);
>>>
>>> + if ($reldir ne '.')
>>> + {
>>> + my $rel_dir = &canonicalize ($reldir);
>>> + $_ =~ s/\@am_reldir\@\//${reldir}\//g;
>>> + $_ =~ s/\@am_reldir\@_/${rel_dir}_/g;
>>> + }
>>> + else
>>> + {
>>> + $_ =~ s/\@am_reldir\@\///g;
>>> + $_ =~ s/\@am_reldir\@_//g;
>>> + }
>>> +
>> Too much automagic here IMO. We'd better have two distinct subst, one for
>> the "real" directory name, and one for the directory name "canonicalized"
>> for use in Automake primaries. I.e., from:
>
> The gain was that the '.' case needs to peak at, and perhaps eat, the
> trailing separator anyway (or it will look bad, I mean, who wants __foo
> after writing &{CANON_CURDIR}&_foo and curdir happens to be '.'?)
>
Good point. We should allow the user to write something like
"&{CANON_CURDIR}&foo_SOURCES" instead, so that it can work for the
current directory too; not much important for human-written makefiles,
but might be for autogenerated ones (I'm thinking ahead about a Gnulib
integration here; the current support for non-recursive projects
there is quite hacky, and could benefit from this new feature).
>> # In sub/sub2/local.mk
>> bin_PROGRAMS = sub/sub2/my-prog
>> sub_sub2_my_prog_SOURCES = sub/sub2/main.c sub/sub2/compat.c
>>
>> to:
>>
>> # In sub/sub2/local.mk
>> bin_PROGRAMS = &{CURDIR}&/my-prog
>> &{CANON_CURDIR}&_my_prog_SOURCES = &{CURDIR}&/main.c &{CURDIR}&/compat.c
>>
>> Aa for what should be the actual names of this substitutions (I realize
>> the names above kinda suck), suggestions are welcome.
>
> After a short brainstorm, I went with &{CUR/DIR}& and &{CUR_DIR}&, but
> I'm not totally satisfied with the / version as it doesn't look "natural".
> But it is self explanatory, kind of. I'm not attached to the naming in
> any way, but &{CANON_CURDIR}& is too long IMHO.
>
I agree we shouldn't overthink this; the naming is something that could be
changed easily in a follow-up patch, before this feature branch is integrated
back in master.
I'm also thinking we could introduce shorthands for often-used &{subst}&;
e.g., &{C}& for &{CANON_CURDIR}& and &{D}& for &{CURDIR}&. Again, this is
material for a follow-up.
>>> if (/$IGNORE_PATTERN/o)
>>> {
>>> # Merely delete comments beginning with two hashes.
>>> @@ -6584,8 +6596,14 @@ sub read_am_file ($$)
>>> push_dist_common ("\$\(srcdir\)/$path");
>>> $path = $relative_dir . "/" . $path if $relative_dir ne '.';
>>> }
>>> + my $new_reldir = $path;
>>> + # $new_reldir =~ s/\$\($reldir\)\///;
>>> + if ($new_reldir =~ s/\/[^\/]*$// == 0)
>>>
>> This is probably better written as:
>>
>> if ($new_reldir !~ s,/[^/]*$,,)
>
> Yes, looks better. I haven't bothered to look up the perl doc that
> spells out exactly why it is equivalent, but I'll trust you on
> that.
>
>>> + {
>>> + $new_reldir = '.';
>>> + }
>>> $where->push_context ("'$path' included from here");
>>> - &read_am_file ($path, $where);
>>> + &read_am_file ($path, $where, $new_reldir);
>>> $where->pop_context;
>>> }
>>> else
>>> @@ -6658,7 +6676,7 @@ sub read_main_am_file ($$)
>>> &define_standard_variables;
>>>
>>> # Read user file, which might override some of our values.
>>> - &read_am_file ($amfile, new Automake::Location);
>>> + &read_am_file ($amfile, new Automake::Location, '.');
>>> }
>>>
>>> [SNIP good testsuite addition]
>>>
>>
>> I really like how simple and unobtrusive this patch is!
>
> Yes, it was simpler than I anticipated. After posting I noticed that
> some project (was it coreutils?) used "include $(srcdir)/foo/local.mk"
>
That usage is advised by our own manual, so we should definitely
support it ... As well as "include $(top_srcdir)/foo/local.mk"
(this latter might be trickier though).
> and figured my changes wouldn't support that. But that works too, I
> don't know why though. (not that I'm complaining)
>
We should definitely add a test for that too; yes, I'm volunteering to
do so -- you know I like writing tests :-)
> Updated patch attached, I renamed it to curdir instead of reldir (and
> sorry for not dropping the automake list last time around).
>
Thanks, I'll take a look at it tomorrow.
Regards,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 24 Jan 2013 12:23:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 13524 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2013-01-23 16:08, Stefano Lattarini wrote:
> On 01/23/2013 03:34 PM, Peter Rosin wrote:
>> On 2013-01-23 13:45, Stefano Lattarini wrote:
*snip*
>>> Too much automagic here IMO. We'd better have two distinct subst, one for
>>> the "real" directory name, and one for the directory name "canonicalized"
>>> for use in Automake primaries. I.e., from:
>>
>> The gain was that the '.' case needs to peak at, and perhaps eat, the
>> trailing separator anyway (or it will look bad, I mean, who wants __foo
>> after writing &{CANON_CURDIR}&_foo and curdir happens to be '.'?)
>>
> Good point. We should allow the user to write something like
> "&{CANON_CURDIR}&foo_SOURCES" instead, so that it can work for the
> current directory too; not much important for human-written makefiles,
> but might be for autogenerated ones (I'm thinking ahead about a Gnulib
> integration here; the current support for non-recursive projects
> there is quite hacky, and could benefit from this new feature).
Are you saying that &{CURDIR}& should be replaced with the empty
string when the current relative directory is "." and the current
relative directory followed by a slash otherwise? (And similar, but
with a trailing underscore for &{CANON_CURDIR}&) I don't fancy
that, as I think &{CURDIR}&gazonk.c is that much harder to read than
&{CURDIR}&/gazonk.c.
So, I'd rather have the magic extend beyond the }& even if that is
ugly indeed. Maybe I'm just deluded to want that...
Or, do you mean that &{CURDIR}& should peak ahead and only add a
trailing "/" if it is not followed by a slash (or whitespace?)
already, making "&{CURDIR}&foo.c" and "&{CURDIR}&/foo.c" equivalent
except when &{CURDIR}& is "." (which would come out as "foo.c" and
"./foo.c" respectively)?
*snip*
> Thanks, I'll take a look at it tomorrow.
Another day, another version. I hope you didn't wast too much time
on v2...
I changed to &{CANON_CURDIR}& and &{CURDIR}&, added support for
$(top_srcdir) and improved the test. There's more code due to the
$(top_srcdir) support, and maybe there are some preexisting
functionality that strips common leading directory components that
could have been reused, but I'm ignorant. Besides, what's wrong
with NIH? :-)
Cheers,
Peter
[0001-curdir-add-support-for-relative-names-in-included-fr.patch (text/x-patch, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Fri, 25 Jan 2013 16:05:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 13524 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2013-01-24 13:22, Peter Rosin wrote:
> On 2013-01-23 16:08, Stefano Lattarini wrote:
>> On 01/23/2013 03:34 PM, Peter Rosin wrote:
>>> On 2013-01-23 13:45, Stefano Lattarini wrote:
> *snip*
>>>> Too much automagic here IMO. We'd better have two distinct subst, one for
>>>> the "real" directory name, and one for the directory name "canonicalized"
>>>> for use in Automake primaries. I.e., from:
>>>
>>> The gain was that the '.' case needs to peak at, and perhaps eat, the
>>> trailing separator anyway (or it will look bad, I mean, who wants __foo
>>> after writing &{CANON_CURDIR}&_foo and curdir happens to be '.'?)
>>>
>> Good point. We should allow the user to write something like
>> "&{CANON_CURDIR}&foo_SOURCES" instead, so that it can work for the
>> current directory too; not much important for human-written makefiles,
>> but might be for autogenerated ones (I'm thinking ahead about a Gnulib
>> integration here; the current support for non-recursive projects
>> there is quite hacky, and could benefit from this new feature).
>
> Are you saying that &{CURDIR}& should be replaced with the empty
> string when the current relative directory is "." and the current
> relative directory followed by a slash otherwise? (And similar, but
> with a trailing underscore for &{CANON_CURDIR}&) I don't fancy
> that, as I think &{CURDIR}&gazonk.c is that much harder to read than
> &{CURDIR}&/gazonk.c.
>
> So, I'd rather have the magic extend beyond the }& even if that is
> ugly indeed. Maybe I'm just deluded to want that...
>
> Or, do you mean that &{CURDIR}& should peak ahead and only add a
> trailing "/" if it is not followed by a slash (or whitespace?)
> already, making "&{CURDIR}&foo.c" and "&{CURDIR}&/foo.c" equivalent
> except when &{CURDIR}& is "." (which would come out as "foo.c" and
> "./foo.c" respectively)?
>
> *snip*
>> Thanks, I'll take a look at it tomorrow.
>
> Another day, another version. I hope you didn't wast too much time
> on v2...
>
> I changed to &{CANON_CURDIR}& and &{CURDIR}&, added support for
> $(top_srcdir) and improved the test. There's more code due to the
> $(top_srcdir) support, and maybe there are some preexisting
> functionality that strips common leading directory components that
> could have been reused, but I'm ignorant. Besides, what's wrong
> with NIH? :-)
Zapping the NIH part reduced the code size significantly (the patch
is now short, sweet and unintrusive again) so I'm posting a new version.
After all, it's a new day, right?
I hope it's ok to use File::Spec->abs2rel () in Automake?
BTW, let me know if I should trim the CC list.
Cheers,
Peter
[0001-curdir-add-support-for-relative-names-in-included-fr.patch (text/x-patch, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Sun, 27 Jan 2013 00:55:01 GMT)
Full text and
rfc822 format available.
Message #36 received at 13524 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2013-01-25 17:03, Peter Rosin wrote:
> On 2013-01-24 13:22, Peter Rosin wrote:
>> On 2013-01-23 16:08, Stefano Lattarini wrote:
>>> On 01/23/2013 03:34 PM, Peter Rosin wrote:
>>>> On 2013-01-23 13:45, Stefano Lattarini wrote:
>> *snip*
>>>>> Too much automagic here IMO. We'd better have two distinct subst, one for
>>>>> the "real" directory name, and one for the directory name "canonicalized"
>>>>> for use in Automake primaries. I.e., from:
>>>>
>>>> The gain was that the '.' case needs to peak at, and perhaps eat, the
>>>> trailing separator anyway (or it will look bad, I mean, who wants __foo
>>>> after writing &{CANON_CURDIR}&_foo and curdir happens to be '.'?)
>>>>
>>> Good point. We should allow the user to write something like
>>> "&{CANON_CURDIR}&foo_SOURCES" instead, so that it can work for the
>>> current directory too; not much important for human-written makefiles,
>>> but might be for autogenerated ones (I'm thinking ahead about a Gnulib
>>> integration here; the current support for non-recursive projects
>>> there is quite hacky, and could benefit from this new feature).
>>
>> Are you saying that &{CURDIR}& should be replaced with the empty
>> string when the current relative directory is "." and the current
>> relative directory followed by a slash otherwise? (And similar, but
>> with a trailing underscore for &{CANON_CURDIR}&) I don't fancy
>> that, as I think &{CURDIR}&gazonk.c is that much harder to read than
>> &{CURDIR}&/gazonk.c.
>>
>> So, I'd rather have the magic extend beyond the }& even if that is
>> ugly indeed. Maybe I'm just deluded to want that...
>>
>> Or, do you mean that &{CURDIR}& should peak ahead and only add a
>> trailing "/" if it is not followed by a slash (or whitespace?)
>> already, making "&{CURDIR}&foo.c" and "&{CURDIR}&/foo.c" equivalent
>> except when &{CURDIR}& is "." (which would come out as "foo.c" and
>> "./foo.c" respectively)?
>>
>> *snip*
>>> Thanks, I'll take a look at it tomorrow.
>>
>> Another day, another version. I hope you didn't wast too much time
>> on v2...
>>
>> I changed to &{CANON_CURDIR}& and &{CURDIR}&, added support for
>> $(top_srcdir) and improved the test. There's more code due to the
>> $(top_srcdir) support, and maybe there are some preexisting
>> functionality that strips common leading directory components that
>> could have been reused, but I'm ignorant. Besides, what's wrong
>> with NIH? :-)
>
> Zapping the NIH part reduced the code size significantly (the patch
> is now short, sweet and unintrusive again) so I'm posting a new version.
> After all, it's a new day, right?
>
> I hope it's ok to use File::Spec->abs2rel () in Automake?
This time with documentation and a NEWS entry. I also fixed the case
of including something above the current base Makefile.am with a
relative path, e.g.:
include ../top.mk
That change shaved a couple of more lines. Neat.
I also rebased it, so now it is against master.
Cheers,
Peter
[0001-curdir-add-support-for-relative-names-in-included-fr.patch (text/x-patch, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Sun, 27 Jan 2013 19:23:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 13524 <at> debbugs.gnu.org (full text, mbox):
Hi Peter.
On 01/27/2013 01:54 AM, Peter Rosin wrote:
>
> [SNIP]
>
>> Zapping the NIH part reduced the code size significantly (the patch
>> is now short, sweet and unintrusive again) so I'm posting a new version.
>> After all, it's a new day, right?
>>
>> I hope it's ok to use File::Spec->abs2rel () in Automake?
>
Yes, File::Spec is a core perl module.
>
> This time with documentation and a NEWS entry. I also fixed the case
> of including something above the current base Makefile.am with a
> relative path, e.g.:
>
> include ../top.mk
>
> That change shaved a couple of more lines. Neat.
>
> I also rebased it, so now it is against master.
>
Thanks, it seems nice and good. I'm doing some testsuite enhancements,
and then I have some proposals for further tweaks, but all of those
should be for follow-up patches. Will you allow me some days to prepare
a follow-up patch series for further discussion?
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Sun, 27 Jan 2013 23:40:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 13524 <at> debbugs.gnu.org (full text, mbox):
Hi Stefano,
On 2013-01-27 20:21, Stefano Lattarini wrote:
>> This time with documentation and a NEWS entry. I also fixed the case
>> of including something above the current base Makefile.am with a
>> relative path, e.g.:
>>
>> include ../top.mk
>>
>> That change shaved a couple of more lines. Neat.
>>
>> I also rebased it, so now it is against master.
>>
> Thanks, it seems nice and good. I'm doing some testsuite enhancements,
> and then I have some proposals for further tweaks, but all of those
> should be for follow-up patches. Will you allow me some days to prepare
> a follow-up patch series for further discussion?
Sure, take your time, I feel like I'm done. For about the fifth
time :-) or something like that. Besides, the patch will not be of
all that much use to me until it lands in a released version anyway.
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Fri, 01 Feb 2013 16:21:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/01/2013 04:18 PM, Bert Wesarg wrote:
> Hi all,
>
> On Mon, Jan 28, 2013 at 12:38 AM, Peter Rosin <peda <at> lysator.liu.se> wrote:
>> Hi Stefano,
>>
>> On 2013-01-27 20:21, Stefano Lattarini wrote:
>>>> This time with documentation and a NEWS entry. I also fixed the case
>>>> of including something above the current base Makefile.am with a
>>>> relative path, e.g.:
>>>>
>>>> include ../top.mk
>>>>
>>>> That change shaved a couple of more lines. Neat.
>>>>
>>>> I also rebased it, so now it is against master.
>>>>
>>> Thanks, it seems nice and good. I'm doing some testsuite enhancements,
>>> and then I have some proposals for further tweaks, but all of those
>>> should be for follow-up patches. Will you allow me some days to prepare
>>> a follow-up patch series for further discussion?
>>
>> Sure, take your time, I feel like I'm done. For about the fifth
>> time :-) or something like that. Besides, the patch will not be of
>> all that much use to me until it lands in a released version anyway.
>
> while I didn't try the current patch out. I would like to describe in
> short the situation where one of our projects build system is in:
> Sure, we use a non-recursive build. But we use the same sources in one
> package by two sub-configures to build different targets.
>
> Our makefiles which we include in the top-level Makefile.am look like
> this (we name them 'Makefile.inc.am):
>
> src/Makefile.inc.am:
>
> bin_PROGRAM = foo
> foo_SOURCES = ../src/foo.c
>
> and in the top-level Makefile.am:
>
> build-1/Makefile.am:
>
> include ../src/Makefile.inc.am
>
> So, using this patch, we would change the src/Makefile.inc.am to:
>
> bin_PROGRAM = foo
> foo_SOURCES = &{D}&/foo.c
>
> Right?
>
Yes, that should work.
Best regards,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Fri, 01 Feb 2013 16:57:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 13524 <at> debbugs.gnu.org (full text, mbox):
Hi all,
On Mon, Jan 28, 2013 at 12:38 AM, Peter Rosin <peda <at> lysator.liu.se> wrote:
> Hi Stefano,
>
> On 2013-01-27 20:21, Stefano Lattarini wrote:
>>> This time with documentation and a NEWS entry. I also fixed the case
>>> of including something above the current base Makefile.am with a
>>> relative path, e.g.:
>>>
>>> include ../top.mk
>>>
>>> That change shaved a couple of more lines. Neat.
>>>
>>> I also rebased it, so now it is against master.
>>>
>> Thanks, it seems nice and good. I'm doing some testsuite enhancements,
>> and then I have some proposals for further tweaks, but all of those
>> should be for follow-up patches. Will you allow me some days to prepare
>> a follow-up patch series for further discussion?
>
> Sure, take your time, I feel like I'm done. For about the fifth
> time :-) or something like that. Besides, the patch will not be of
> all that much use to me until it lands in a released version anyway.
while I didn't try the current patch out. I would like to describe in
short the situation where one of our projects build system is in:
Sure, we use a non-recursive build. But we use the same sources in one
package by two sub-configures to build different targets.
Our makefiles which we include in the top-level Makefile.am look like
this (we name them 'Makefile.inc.am):
src/Makefile.inc.am:
bin_PROGRAM = foo
foo_SOURCES = ../src/foo.c
and in the top-level Makefile.am:
build-1/Makefile.am:
include ../src/Makefile.inc.am
So, using this patch, we would change the src/Makefile.inc.am to:
bin_PROGRAM = foo
foo_SOURCES = &{D}&/foo.c
Right?
Thanks.
Bert
>
> Cheers,
> Peter
>
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Sun, 03 Feb 2013 20:44:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 13524 <at> debbugs.gnu.org (full text, mbox):
tags 13524 + patch
thanks
[+cc automake-patches]
Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13524>
On 01/28/2013 12:38 AM, Peter Rosin wrote:
> Hi Stefano,
>
> On 2013-01-27 20:21, Stefano Lattarini wrote:
>>> This time with documentation and a NEWS entry. I also fixed the case
>>> of including something above the current base Makefile.am with a
>>> relative path, e.g.:
>>>
>>> include ../top.mk
>>>
>>> That change shaved a couple of more lines. Neat.
>>>
>>> I also rebased it, so now it is against master.
>>>
>> Thanks, it seems nice and good. I'm doing some testsuite enhancements,
>> and then I have some proposals for further tweaks, but all of those
>> should be for follow-up patches. Will you allow me some days to prepare
>> a follow-up patch series for further discussion?
>
> Sure, take your time, I feel like I'm done. For about the fifth
> time :-) or something like that. Besides, the patch will not be of
> all that much use to me until it lands in a released version anyway.
>
I've pushed the promised patches to the rewindable branch
'experimental/preproc' (based off of maint). I'll also soon
send them to the list to simplify review (I will drop the
bug tracker from CC:, to avoid cluttering up the report).
As usual, reviews are welcome.
Thanks,
Stefano
Added tag(s) patch.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 03 Feb 2013 20:44:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Sun, 03 Feb 2013 23:12:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 2013-02-03 21:42, Stefano Lattarini wrote:
> I've pushed the promised patches to the rewindable branch
> 'experimental/preproc' (based off of maint). I'll also soon
> send them to the list to simplify review (I will drop the
> bug tracker from CC:, to avoid cluttering up the report).
>
> As usual, reviews are welcome.
I like the end result of this series, I especially like that I don't have
to type &{this}& anymore. But I have some doubts whether the longish
way to get there is really all that interesting? The argument that you
should keep the history to show how you get from A to B is just not worth
it when it's just about bike-shedding the naming... Why not merge 1 with
the nobrainer renames of 3-6? The only "real changes" in the later patches
are the $$ -> $$$ thing and the NEWS entry as far as I can tell, and if
something should be in its own patch, that $$$ change is it. Oh right,
there's the re-computing change as well. But I don't think it's worth it,
just collapse it. The only sane way to look at this series is to diff
from 6/6 to the branch-point, which should tell you something. But I
don't feel strongly about it, it's just what I would have done. If 2/6
is a separate patch is not important to me either, so I would be ok with
you collapsing the whole series into a single co-authored patch. But then
again, I don't really care, and if you get tired from just thinking about
rewriting the commit message I can fully understand that position.
Another thing is that your new NEWS item is a bit awkward, and its
single sentence is simply too long and winding IMHO. The * heading
also needs an update.
From your 5/6:
* Current directory in makefile fragments:
- The special Automake-time substitutions '{RELDIR}' and '{CANON_RELDIR}'
(and their abbreviated versions, '{D}' and '{C}' respectively) can now
be used in an included Makefile fragment to indicate respectively the
relative directory of that fragment and its canonicalized version,
relative to the including Makefile:
My suggestion:
* Relative directory in Makefile fragments:
- The special Automake-time substitutions '{RELDIR}' and '{CANON_RELDIR}'
(and their abbreviated versions, '{D}' and '{C}' respectively) can now
be used in an included Makefile fragment. They are substituted with
the relative directory of the included fragment, or its canonicalized
version, compared to the top level including Makefile:
Cheers,
Peter
PS. You introduced the curdir naming, I had reldir in my original patch. :-)
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 09:37:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 2013-02-04 00:10, Peter Rosin wrote:
> On 2013-02-03 21:42, Stefano Lattarini wrote:
>> I've pushed the promised patches to the rewindable branch
>> 'experimental/preproc' (based off of maint). I'll also soon
>> send them to the list to simplify review (I will drop the
>> bug tracker from CC:, to avoid cluttering up the report).
>>
>> As usual, reviews are welcome.
>
> I like the end result of this series, I especially like that I don't have
> to type &{this}& anymore.
*snip*
Oops, a couple more things. The new naming will clobber
anyone using a Makefile variable named RELDIR with brace
syntax. E.g., this previously working code is broken by
the series.
RELDIR = src
foobar_CPPFLAGS = $(AM_CPPFLAGS) -DRELDIR=${RELDIR}
It will be preprocessed into
RELDIR = src
foobar_CPPFLAGS = $(AM_CPPFLAGS) -DRELDIR=$src
and quasi-expanded into (assuming $s is empty)
foobar_CPPFLAGS = $(AM_CPPFLAGS) -DRELDIR=rc
Not sure what to do about it, or if it matters...
Further, the use of /dev/full in the demo test is not
portable. If I create /dev on Windows (i.e. C:\dev, or have
it previously, I didn't, but not unlikely), and am allowed
to write there (likely, on Windows), and /dev/full isn't
supported (where is it supported, except Linux?), then the
test falls apart. The MinGW program happily writes "dummy"
to /dev/full (i.e. C:\dev\full from its view of the file
system) but the MSYS script does not think /dev/full is a
character device and it is not be allowed to write to
/dev/full either, because typically /dev doesn't exist as
a real directory. Typically /dev is virtual in MSYS (if it
existed, it would be C:\MinGW\msys\1.0\dev from the MSYS
view of the file system) so it assumes the MinGW program
skipped, but it didn't.
Why use special features like /dev/full in the testsuite of
Automake? Surely there are better things one can do to check if
a Makefile works. Mixing in stuff like that is just a recipe
for strange bug reports and hardship for those on weird
platforms. The gain for Automake is zero.
Also, creating the file /dev/full with content "dummy" is
bad manors, even if someone runs the testsuite as root (on a
system not supporting /dev/full) and arguably deserves it.
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 11:26:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/04/2013 12:10 AM, Peter Rosin wrote:
> On 2013-02-03 21:42, Stefano Lattarini wrote:
>> I've pushed the promised patches to the rewindable branch
>> 'experimental/preproc' (based off of maint). I'll also soon
>> send them to the list to simplify review (I will drop the
>> bug tracker from CC:, to avoid cluttering up the report).
>>
>> As usual, reviews are welcome.
>
> I like the end result of this series, I especially like that I don't have
> to type &{this}& anymore. But I have some doubts whether the longish
> way to get there is really all that interesting?
>
No, not really; the different approaches and names we tried can just be
reported in the commit message, rather than littering up the Git history.
So I'll squash all the patches, excluding only the second one, which I
still wish to keep separate.
> [SNIP] rest of rationle
> Another thing is that your new NEWS item is a bit awkward, and its
> single sentence is simply too long and winding IMHO. The * heading
> also needs an update.
>
> From your 5/6:
>
> * Current directory in makefile fragments:
>
Oops, I had indeed forgotten to update this!
> - The special Automake-time substitutions '{RELDIR}' and '{CANON_RELDIR}'
> (and their abbreviated versions, '{D}' and '{C}' respectively) can now
> be used in an included Makefile fragment to indicate respectively the
> relative directory of that fragment and its canonicalized version,
> relative to the including Makefile:
>
> My suggestion:
>
> * Relative directory in Makefile fragments:
>
> - The special Automake-time substitutions '{RELDIR}' and '{CANON_RELDIR}'
> (and their abbreviated versions, '{D}' and '{C}' respectively) can now
> be used in an included Makefile fragment. They are substituted with
> the relative directory of the included fragment, or its canonicalized
> version, compared to the top level including Makefile:
>
Yes, better. But I find the following even better (marginally):
The special Automake-time substitutions '{RELDIR}' and '{CANON_RELDIR}'
(and their abbreviated versions, '{D}' and '{C}' respectively) can now
be used in an included Makefile fragment. They are substituted,
respectively, with the relative directory of the included fragment and
its canonicalized version, compared to the top level including Makefile:
OK?
> PS. You introduced the curdir naming, I had reldir in my original patch. :-)
>
Yikes, sorry.
Regards,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 11:35:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/04/2013 10:35 AM, Peter Rosin wrote:
> On 2013-02-04 00:10, Peter Rosin wrote:
>> On 2013-02-03 21:42, Stefano Lattarini wrote:
>>> I've pushed the promised patches to the rewindable branch
>>> 'experimental/preproc' (based off of maint). I'll also soon
>>> send them to the list to simplify review (I will drop the
>>> bug tracker from CC:, to avoid cluttering up the report).
>>>
>>> As usual, reviews are welcome.
>>
>> I like the end result of this series, I especially like that I don't have
>> to type &{this}& anymore.
>
> *snip*
>
> Oops, a couple more things. The new naming will clobber
> anyone using a Makefile variable named RELDIR with brace
> syntax.
Yikes, I didn't think of that. *blush*
> E.g., this previously working code is broken by
> the series.
>
> RELDIR = src
> foobar_CPPFLAGS = $(AM_CPPFLAGS) -DRELDIR=${RELDIR}
>
> It will be preprocessed into
>
> RELDIR = src
> foobar_CPPFLAGS = $(AM_CPPFLAGS) -DRELDIR=$src
>
Ouch.
> and quasi-expanded into (assuming $s is empty)
>
> foobar_CPPFLAGS = $(AM_CPPFLAGS) -DRELDIR=rc
>
> Not sure what to do about it, or if it matters...
>
It does IMHO, since the failure you pointed out, albeit easy to
work around, wouldn't be very obvious to diagnose, from the point
of view of a non-particularly-expert user.
What about doubling the curly braces? As in '{{RELDIR}}'.
Would that be tolerable? Other possibilities (none particularly
pleasant either, IMHO):
{+RELDIR+}
{:RELDIR:}
{.RELDIR.}
{-RELDIR-}
Other proposals?
>
> Further, the use of /dev/full in the demo test is not
> portable. If I create /dev on Windows (i.e. C:\dev, or have
> it previously, I didn't, but not unlikely), and am allowed
> to write there (likely, on Windows), and /dev/full isn't
> supported (where is it supported, except Linux?), then the
> test falls apart. The MinGW program happily writes "dummy"
> to /dev/full (i.e. C:\dev\full from its view of the file
> system) but the MSYS script does not think /dev/full is a
> character device and it is not be allowed to write to
> /dev/full either, because typically /dev doesn't exist as
> a real directory. Typically /dev is virtual in MSYS (if it
> existed, it would be C:\MinGW\msys\1.0\dev from the MSYS
> view of the file system) so it assumes the MinGW program
> skipped, but it didn't.
>
> Why use special features like /dev/full in the testsuite of
> Automake? Surely there are better things one can do to check if
> a Makefile works. Mixing in stuff like that is just a recipe
> for strange bug reports and hardship for those on weird
> platforms. The gain for Automake is zero.
>
> Also, creating the file /dev/full with content "dummy" is
> bad manors, even if someone runs the testsuite as root (on a
> system not supporting /dev/full) and arguably deserves it.
>
Mostly agreed; I tried to create the test as a reasonable
demo mimicking real-world packages, but I've probably gotten
carried too far, for no real advantage (but with potential
lurking issues down the road). I will simplify the test.
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 11:50:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 2013-02-04 12:23, Stefano Lattarini wrote:
> On 02/04/2013 12:10 AM, Peter Rosin wrote:
>> On 2013-02-03 21:42, Stefano Lattarini wrote:
>>> I've pushed the promised patches to the rewindable branch
>>> 'experimental/preproc' (based off of maint). I'll also soon
>>> send them to the list to simplify review (I will drop the
>>> bug tracker from CC:, to avoid cluttering up the report).
>>>
>>> As usual, reviews are welcome.
>>
>> I like the end result of this series, I especially like that I don't have
>> to type &{this}& anymore. But I have some doubts whether the longish
>> way to get there is really all that interesting?
>>
> No, not really; the different approaches and names we tried can just be
> reported in the commit message, rather than littering up the Git history.
>
> So I'll squash all the patches, excluding only the second one, which I
> still wish to keep separate.
Good.
>> [SNIP] rest of rationle
>
>> Another thing is that your new NEWS item is a bit awkward, and its
>> single sentence is simply too long and winding IMHO. The * heading
>> also needs an update.
>>
>> From your 5/6:
>>
>> * Current directory in makefile fragments:
>>
> Oops, I had indeed forgotten to update this!
>
>> - The special Automake-time substitutions '{RELDIR}' and '{CANON_RELDIR}'
>> (and their abbreviated versions, '{D}' and '{C}' respectively) can now
>> be used in an included Makefile fragment to indicate respectively the
>> relative directory of that fragment and its canonicalized version,
>> relative to the including Makefile:
>>
>> My suggestion:
>>
>> * Relative directory in Makefile fragments:
>>
>> - The special Automake-time substitutions '{RELDIR}' and '{CANON_RELDIR}'
>> (and their abbreviated versions, '{D}' and '{C}' respectively) can now
>> be used in an included Makefile fragment. They are substituted with
>> the relative directory of the included fragment, or its canonicalized
>> version, compared to the top level including Makefile:
>>
> Yes, better. But I find the following even better (marginally):
>
> The special Automake-time substitutions '{RELDIR}' and '{CANON_RELDIR}'
> (and their abbreviated versions, '{D}' and '{C}' respectively) can now
> be used in an included Makefile fragment. They are substituted,
> respectively, with the relative directory of the included fragment and
> its canonicalized version, compared to the top level including Makefile:
>
> OK?
I still like my version better, I think that the slight ambiguity you aim
to kill with the extra "respectively" is not going to fool anyone, and I
find that the twist it adds just makes it harder to read the dang thing.
But I'm not a native speaker, so what do I know?
New (and final, from me) attempt:
* Relative directory in Makefile fragments:
- The special Automake-time substitutions '{RELDIR}' and '{CANON_RELDIR}'
(and their abbreviated versions, '{D}' and '{C}' respectively) can now
be used in an included Makefile fragment. The former is substituted
with the relative directory of the included fragment (compared to the
top level including Makefile), and the latter with the canonicalized
version of the same relative directory:
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 12:06:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 2013-02-04 12:33, Stefano Lattarini wrote:
> On 02/04/2013 10:35 AM, Peter Rosin wrote:
>> Not sure what to do about it, or if it matters...
>>
> It does IMHO, since the failure you pointed out, albeit easy to
> work around, wouldn't be very obvious to diagnose, from the point
> of view of a non-particularly-expert user.
>
> What about doubling the curly braces? As in '{{RELDIR}}'.
> Would that be tolerable? Other possibilities (none particularly
> pleasant either, IMHO):
>
> {+RELDIR+}
> {:RELDIR:}
> {.RELDIR.}
> {-RELDIR-}
>
> Other proposals?
':' is a shifted symbol on my keyboard, as is &, and {} are
on a separate modifier (AltGr) making the old style (which I
refuse to replicate here) a bitch to type (which is why I
refuse). So, on the grounds of that, I'd vote against
{:RELDIR:}.
I {{think}} this one will be the easiest on us of all.
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 12:46:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 2/4/13 9:33 PM, Stefano Lattarini wrote:
> What about doubling the curly braces? As in '{{RELDIR}}'.
> Would that be tolerable? Other possibilities (none particularly
> pleasant either, IMHO):
>
> {+RELDIR+}
> {:RELDIR:}
> {.RELDIR.}
> {-RELDIR-}
>
> Other proposals?
Using Automake's namespace, 'AM_', comes to mind: {AM_RELDIR}.
cheers,
--
Peter Johansson
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 13:43:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/04/2013 01:44 PM, Peter Johansson wrote:
> On 2/4/13 9:33 PM, Stefano Lattarini wrote:
>> What about doubling the curly braces? As in '{{RELDIR}}'.
>> Would that be tolerable? Other possibilities (none particularly
>> pleasant either, IMHO):
>>
>> {+RELDIR+}
>> {:RELDIR:}
>> {.RELDIR.}
>> {-RELDIR-}
>>
>> Other proposals?
> Using Automake's namespace, 'AM_', comes to mind: {AM_RELDIR}.
>
I'm not sure about this; being namespace-clean even here sounds nice
in theory, but {AM_RELDIR} actually seems quite ugly to me, and less
clear than the simpler (albeit namespace-polluting) {{RELDIR}}.
But I'd like to read other opinions before making up my mind.
Anyone has further feedback?
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 13:45:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/04/2013 01:04 PM, Peter Rosin wrote:
> On 2013-02-04 12:33, Stefano Lattarini wrote:
>> On 02/04/2013 10:35 AM, Peter Rosin wrote:
>>> Not sure what to do about it, or if it matters...
>>>
>> It does IMHO, since the failure you pointed out, albeit easy to
>> work around, wouldn't be very obvious to diagnose, from the point
>> of view of a non-particularly-expert user.
>>
>> What about doubling the curly braces? As in '{{RELDIR}}'.
>> Would that be tolerable? Other possibilities (none particularly
>> pleasant either, IMHO):
>>
>> {+RELDIR+}
>> {:RELDIR:}
>> {.RELDIR.}
>> {-RELDIR-}
>>
>> Other proposals?
>
> ':' is a shifted symbol on my keyboard, as is &, and {} are
> on a separate modifier (AltGr)
>
Same on my keyboard, actually. So ...
> making the old style (which I
> refuse to replicate here) a bitch to type (which is why I
> refuse). So, on the grounds of that, I'd vote against
> {:RELDIR:}.
>
... I agree with you (and should probably lart myself with
my own keyboard for not having thought of your rationale
myself).
> I {{think}} this one will be the easiest on us of all.
>
I tend to agree (but see Peter Johansson's proposal to use
{AM_RELDIR} instead; what do you think about it?)
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 14:08:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 2013-02-04 14:43, Stefano Lattarini wrote:
> On 02/04/2013 01:04 PM, Peter Rosin wrote:
>> I {{think}} this one will be the easiest on us of all.
BTW, that was a mix of "on us all" and "on all of us", if
anyone didn't notice...
>>
> I tend to agree (but see Peter Johansson's proposal to use
> {AM_RELDIR} instead; what do you think about it?)
Well, I had @am_reldir@ in my original patch, so obviously I'm
not totally against the am_ prefix, but I did think it was too
long. You didn't really say in what way using @ was bad? This
might be the time to revisit that, so that we can come full
circle on this issue? :-) But seriously, why would it be bad
to use @ for something that is not going to be seen by
config.status anyway? Because grepping the source becomes
'difficult'? Trouble documenting? Users expecting to be able
to AC_SUBST? What?
You also suggested %percent% way back when but didn't like it.
How bad was that? What about §reldir§ (not ascii, so I guess
not) or [reldir]? Are square brackets legit in a Makefile for
anything?
If we do go with the prefix, do we really want to advertice
so obviously? I mean, {AM_D}, come on... :-)
I don't really care, just pick something that works. And stick
to it.
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 17:22:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/04/2013 03:06 PM, Peter Rosin wrote:
> On 2013-02-04 14:43, Stefano Lattarini wrote:
>> On 02/04/2013 01:04 PM, Peter Rosin wrote:
>>> I {{think}} this one will be the easiest on us all.
>>>
>> I tend to agree (but see Peter Johansson's proposal to use
>> {AM_RELDIR} instead; what do you think about it?)
>
> Well, I had @am_reldir@ in my original patch, so obviously I'm
> not totally against the am_ prefix, but I did think it was too
> long. You didn't really say in what way using @ was bad?
>
Yes, and I stand by that. The proposal here was to use {AM_RELDIR},
not @AM_RELDIR@.
> This might be the time to revisit that, so that we can come full
> circle on this issue? :-)
>
Not really.
> But seriously, why would it be bad
> to use @ for something that is not going to be seen by
> config.status anyway?
>
Because it would mix up very different concepts: a '@...@' substitution
is meant for something that depends on configure-time check (or at
least from code in configure), and is substituted the same in *every*
Makefile and makefile fragment; while the proposed '{...}' would depend
merely on the relative position of the included fragment, and have
nothing to do with configure code or configure-time checks.
> Because grepping the source becomes
> 'difficult'? Trouble documenting? Users expecting to be able
> to AC_SUBST? What?
>
To summarize: conceptual confusion.
> You also suggested %percent% way back when but didn't like it.
>
Again, it would cause confusion between automake-time substitutions
in the private makefile fragments 'lib/am/*.am' (invisible and
transparent to the user) and substitutions meant to be visible and
actively employed by the user; albeit in this case only automake
developers would be exposed to this source of confusion, so the
situation wouldn't be nearly as bad.
> How bad was that?
>
Honestly, something like:
%RELDIR_CANON%_foo_SOURCES = ...
seems quite ugly to me; albeit
%RELDIR-CANON%_foo_SOURCES = ...
seems a little better. But I still prefer the "substitution starts",
"substitution ends" hinted at by the symmetric '{' and '}' characters
> What about §reldir§ (not ascii, so I guess
> not) or [reldir]? Are square brackets legit in a Makefile for
> anything?
>
Anyone using '[FOO]' in a make variable name probably deserve to suffer,
and uses of the'[C]' or '[D]' literal strings in recipes or variables'
expansions should be rare enough not to cause real problems (and such
problem could be easily worked around anyway). I still marginally prefer
'{{...}}', but happily I'll go with '[...]' instead if its proponents
rewrite the patch series for me (hint hint, nudge nudge). Anyone
actually painting the shed gets to choose its color :-)
> If we do go with the prefix, do we really want to advertice
> so obviously? I mean, {AM_D}, come on... :-)
>
Ah, LOL. And the use of namespace in the shorthands would destroy their
beauty and handiness ...
> I don't really care, just pick something that works. And stick
> to it.
>
> Cheers,
> Peter
>
Regards,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 17:45:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 13524 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 02/04/2013 10:19 AM, Stefano Lattarini wrote:
> Because it would mix up very different concepts: a '@...@' substitution
> is meant for something that depends on configure-time check (or at
> least from code in configure), and is substituted the same in *every*
> Makefile and makefile fragment;
Not so - in the section on preset output variables, autoconf documents
that several @...@ substitutions are dependent on where in the hierarchy
they are replaced (generally, the variables with all lower-case names).
https://www.gnu.org/software/autoconf/manual/autoconf.html#Preset-Output-Variables
> while the proposed '{...}' would depend
> merely on the relative position of the included fragment, and have
> nothing to do with configure code or configure-time checks.
So they aren't quite affected by configure, but they are dependent on
relative location, just like existing substitutions like @top_srcdir@
are dependent on relative location.
That said, the idea of using some syntax other than @...@ for automake
substitutions, to make it clear that they are different than
config.status substitutions, works for me. I just don't know that I
have any better ideas for what syntax to prefer.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 18:14:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/04/2013 06:33 PM, Eric Blake wrote:
> On 02/04/2013 10:19 AM, Stefano Lattarini wrote:
>> Because it would mix up very different concepts: a '@...@' substitution
>> is meant for something that depends on configure-time check (or at
>> least from code in configure), and is substituted the same in *every*
>> Makefile and makefile fragment;
>
> Not so - in the section on preset output variables, autoconf documents
> that several @...@ substitutions are dependent on where in the hierarchy
> they are replaced (generally, the variables with all lower-case names).
>
> https://www.gnu.org/software/autoconf/manual/autoconf.html#Preset-Output-Variables
>
OK, I stand corrected. And while stuff like '@top_srcdir@' still depends
on the details of how configure is run, other stuff like '@top_builddir@'
actually depends *only* on the relative position of the file it is
being instantiated. However, see below.
>> while the proposed '{...}' would depend
>> merely on the relative position of the included fragment, and have
>> nothing to do with configure code or configure-time checks.
>
> So they aren't quite affected by configure, but they are dependent on
> relative location, just like existing substitutions like @top_srcdir@
> are dependent on relative location.
>
Yes, but they are dependent on the relative position of an 'include'd
file w.r.t. the currently-processed Makefile.am, not the "top-level"
directory of the project. Not a big deal, but still, another minor
possible source of confusion, as in "all the same @subst@ in a Makefile.in
are substituted with the same text, even if they come from an automake-time
included fragment ... except for the @am_reldir@ etc. substs"; not a big
deal, but not a great example of cleanliness and consistency either IMVHO).
> That said, the idea of using some syntax other than @...@ for automake
> substitutions, to make it clear that they are different than
> config.status substitutions, works for me.
>
I still marginally prefer to keep this distinction, so, since you seem
to have no fundamental objection, I'll stick to it.
> I just don't know that I
> have any better ideas for what syntax to prefer.
>
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 04 Feb 2013 23:05:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 2013-02-04 19:11, Stefano Lattarini wrote:
> On 02/04/2013 06:33 PM, Eric Blake wrote:
>> So they aren't quite affected by configure, but they are dependent on
>> relative location, just like existing substitutions like @top_srcdir@
>> are dependent on relative location.
>>
> Yes, but they are dependent on the relative position of an 'include'd
> file w.r.t. the currently-processed Makefile.am, not the "top-level"
> directory of the project. Not a big deal, but still, another minor
> possible source of confusion, as in "all the same @subst@ in a Makefile.in
> are substituted with the same text, even if they come from an automake-time
> included fragment ... except for the @am_reldir@ etc. substs"; not a big
To me, you are splitting hairs. However, I do see one strongish argument
against @am_reldir@. The short forms (@D@ and @C@) will potentially
break any project already doing AC_SUBST([C]) (or D). And @am_D@, @AM_D@
or whatever isn't all that pretty. So, we can't really use @am_reldir@,
because then we'll have to find some other notation for the short form.
And that would be confusing. Or drop the short form, but we all want
the short form, right?
> deal, but not a great example of cleanliness and consistency either IMVHO).
Having umpteen different replacement operators isn't all that minimal
and neat either IMVHO.
Anyway, summing up.
0. &{reldir}& is a pest to type.
1. {reldir} doesn't work, it conflicts with ${reldir}.
2. @am_reldir@ doesn't work, short form @D@ conflicts with AC_SUBST([D]).
3. {am_reldir} doesn't work, short form {D} conflicts with ${D}.
It is clear that we have to invent a new notation, much as I hate it.
Whatever notation we try to overload is likely have a conflict when
we mix in the short form.
So, %reldir% is best so far IMHO, but if Automake developers are
too easily confused or if we don't control that namespace, I'd go
with {{reldir}}.
Oh, while I'm at it I have a wish, {reldir}/@am_reldir@/whatever is so
much easier on the eyes compared to {RELDIR}/@AM_RELDIR@/WHATEVER. Can we
please skip the capital letters in the naming that is finally decided?
(using capital letter for the short form is fine though)
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Tue, 05 Feb 2013 01:04:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 13524 <at> debbugs.gnu.org (full text, mbox):
%...% seems nice to me.
I don't think "typability" should be a prime factor in deciding,
especially such trivial issues such as shifted-characters (like 75% of
punctuation in Makefiles is shifted on most keyboards); readability is
_much_ more important (and readability in many cases means not too
long, especially for something which is likely to appear multiple
times in file lists etc...). I don't like the AM_ variants: automake
input files are obviously in the automake language, so it seems silly
and redundant to include "AM_".
Incidentally, given the name, I assume the name "reldir" always refers
to a relative path? What is it relative to again? If I want to refer
to a source file, do I write "$(srcdir)/%reldir%/filename" (as opposed
to e.g. "$(top_srcdir)/%reldir%/filename")?
... and "canon_reldir" means the same thing, except canonicalized?
[In other words, still always relative, e.g. by converting to an
absolute canonical name using some sort of truename function, and
then removing the source-directory prefix.]
Thanks,
-miles
--
Cat is power. Cat is peace.
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 07 Feb 2013 09:28:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/05/2013 12:03 AM, Peter Rosin wrote:
> On 2013-02-04 19:11, Stefano Lattarini wrote:
>> On 02/04/2013 06:33 PM, Eric Blake wrote:
>>> So they aren't quite affected by configure, but they are dependent on
>>> relative location, just like existing substitutions like @top_srcdir@
>>> are dependent on relative location.
>>>
>> Yes, but they are dependent on the relative position of an 'include'd
>> file w.r.t. the currently-processed Makefile.am, not the "top-level"
>> directory of the project. Not a big deal, but still, another minor
>> possible source of confusion, as in "all the same @subst@ in a Makefile.in
>> are substituted with the same text, even if they come from an automake-time
>> included fragment ... except for the @am_reldir@ etc. substs"; not a big
>
> To me, you are splitting hairs. However, I do see one strongish argument
> against @am_reldir@. The short forms (@D@ and @C@) will potentially
> break any project already doing AC_SUBST([C]) (or D). And @am_D@, @AM_D@
> or whatever isn't all that pretty. So, we can't really use @am_reldir@,
> because then we'll have to find some other notation for the short form.
> And that would be confusing. Or drop the short form, but we all want
> the short form, right?
>
>> deal, but not a great example of cleanliness and consistency either IMVHO).
>
> Having umpteen different replacement operators isn't all that minimal
> and neat either IMVHO.
>
Fine (see below for more).
> Anyway, summing up.
>
> 0. &{reldir}& is a pest to type.
> 1. {reldir} doesn't work, it conflicts with ${reldir}.
> 2. @am_reldir@ doesn't work, short form @D@ conflicts with AC_SUBST([D]).
>
Plus is conceptually confusing/misleading, IMVHO.
> 3. {am_reldir} doesn't work, short form {D} conflicts with ${D}.
>
> It is clear that we have to invent a new notation, much as I hate it.
> Whatever notation we try to overload is likely have a conflict when
> we mix in the short form.
>
> So, %reldir% is best so far IMHO, but if Automake developers are
> too easily confused
>
(in hindsight, I probably overemphasized the risk of confusion here)
> or if we don't control that namespace, I'd go
> with {{reldir}}.
>
I don't have a strong opinion about '{{...}}' vs '%...%' [1]; I marginally
prefer the former, but if people prefer the latter (as your and Miles'
messages suggest), I'm *perfectly* fine to use it as well.
So, shall we go for '%...%' in the end?
[1] OTOH, I'd have strongly preferred '{...}' over '%...%'; but alas,
as we've seen, this shorter and sweeter syntax remains unusable
if we want to avoid collisions and confusions with the ${FOO}
form for make and shell variable expansions.
> Oh, while I'm at it I have a wish, {reldir}/@am_reldir@/whatever is so
> much easier on the eyes compared to {RELDIR}/@AM_RELDIR@/WHATEVER. Can we
> please skip the capital letters in the naming that is finally decided?
> (using capital letter for the short form is fine though)
>
Fine as well. And of curse, if you want to speed thing up and have more
control on the final result, feel free to shepherd the pending patches to
the agreed form ;-) -- which if I'm not mistaken is:
- make the series consist of only two patches, one introducing the
feature (complete with documentation and NEWS additions, plus your
original test case), and one follow-up patch implementing my
testsuite enhancement;
- use the '%...%' form, and prefer lower-case for long names (so,
'%reldir%' a.k.a. '%D%' and '%canon-reldir%' a.k.a. '%C%').
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 07 Feb 2013 09:36:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/05/2013 02:01 AM, Miles Bader wrote:
> %...% seems nice to me.
>
I'm fine to settle for that (see my reply to last mail from Peter for
more details).
> Incidentally, given the name, I assume the name "reldir" always refers
> to a relative path? What is it relative to again?
>
The path of the Makefile.am currently being processed.
> If I want to refer
> to a source file, do I write "$(srcdir)/%reldir%/filename" (as opposed
> to e.g. "$(top_srcdir)/%reldir%/filename")?
>
Yes; and I think we should add a test for this, since it might be a very
important use case (thanks for bringing it up, BTW).
> ... and "canon_reldir" means the same thing, except canonicalized?
>
Yes, "canonicalized" in a sense quite specific to Automake:
<http://www.gnu.org/software/automake/manual/automake.html#Canonicalization>
So, for example, if %reldir% expands to 'foo/bar-baz.d', '%canon-reldir%'
will expand to 'foo_bar_baz_d'.
> [In other words, still always relative, e.g. by converting to an
> absolute canonical name using some sort of truename function, and
> then removing the source-directory prefix.]
>
Not at all; see above.
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 07 Feb 2013 09:55:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 13524 <at> debbugs.gnu.org (full text, mbox):
>> ... and "canon_reldir" means the same thing, except canonicalized?
>>
> Yes, "canonicalized" in a sense quite specific to Automake:
>
> <http://www.gnu.org/software/automake/manual/automake.html#Canonicalization>
>
> So, for example, if %reldir% expands to 'foo/bar-baz.d', '%canon-reldir%'
> will expand to 'foo_bar_baz_d'.
Hmm, if that's the case, then I think "canon" is the wrong term to
use, as it typically implies that the result is still in the same
domain as the input. This operation seems to be more what one might
call "sanitizing"...
[Even if automake uses this term internally, I still think it would be
confusing to expose such unusual usage to the user.]
-miles
--
Cat is power. Cat is peace.
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 07 Feb 2013 12:56:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/07/2013 10:52 AM, Miles Bader wrote:
>>> ... and "canon_reldir" means the same thing, except canonicalized?
>>>
>> Yes, "canonicalized" in a sense quite specific to Automake:
>>
>> <http://www.gnu.org/software/automake/manual/automake.html#Canonicalization>
>>
>> So, for example, if %reldir% expands to 'foo/bar-baz.d', '%canon-reldir%'
>> will expand to 'foo_bar_baz_d'.
>
> Hmm, if that's the case, then I think "canon" is the wrong term to
> use, as it typically implies that the result is still in the same
> domain as the input.
>
Suggestions for a better name then?
> This operation seems to be more what one might
> call "sanitizing"...
>
> [Even if automake uses this term internally, I still think it would be
> confusing to expose such unusual usage to the user.]
>
Actually, automake uses the term in the manual as well, repeatedly.
Regards,
Stefano
> -miles
>
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Fri, 08 Feb 2013 04:15:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 13524 <at> debbugs.gnu.org (full text, mbox):
>> Hmm, if that's the case, then I think "canon" is the wrong term to
>> use, as it typically implies that the result is still in the same
>> domain as the input.
>>
> Suggestions for a better name then?
Dunno... something like "RELDIR_SYM" would make sense ... it's a
symbol corresponding to RELDIR...
-miles
--
Cat is power. Cat is peace.
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Fri, 08 Feb 2013 08:46:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 13524 <at> debbugs.gnu.org (full text, mbox):
Stefano Lattarini wrote:
> Fine as well. And of curse, if you want to speed thing up and have more
> control on the final result, feel free to shepherd the pending patches to
> the agreed form ;-) -- which if I'm not mistaken is:
>
> - make the series consist of only two patches, one introducing the
> feature (complete with documentation and NEWS additions, plus your
> original test case), and one follow-up patch implementing my
> testsuite enhancement;
>
> - use the '%...%' form, and prefer lower-case for long names (so,
> '%reldir%' a.k.a. '%D%' and '%canon-reldir%' a.k.a. '%C%').
Done. I didn't address the canonicalization concern raised by Miles. That
seems like a bigger issue than this patch series. However, If that naming
is changing, it must be done before this series lands in a released
version, or we'll end up with bad comptibility hacks...
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Fri, 08 Feb 2013 08:46:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 13524 <at> debbugs.gnu.org (full text, mbox):
The rationale for this change is that it is annoying to have
to repeat the directory name when including a Makefile fragment.
For deep directory structures these repeats can generate a lot
of bloat. It also hinders reuse and easy directory restructuring
if all Makefile fragments have to know exactly where they live.
Suggested by Bob Friesenhahn, and later discussed in bug#13524.
In the course of discussion, the following notations were rejected:
&{reldir}& - to hard to type, {reldir} - interferes with ${reldir},
{am_reldir} - short form {D} interferes with ${D}, @am_reldir@ - short
form @D@ interferes with AC_SUBST([D]) as well as invading the
config.status turf. Other notations were also suggested...
* automake.in (read_am_file): Add third argument specifying the
relative directory of this Makefile fragment compared to the
main Makefile. Replace %reldir% and %canon_reldir% in the
fragment with this relative directory (with slashes etc, or
canonicalized).
(read_main_am_file): Adjust.
* t/preproc-reldir.sh: New test.
* t/list-of-tests.mk: Augment.
* doc/automake.texi (Include): Document the new feature.
NEWS: Add new feature.
Co-authored-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Signed-off-by: Peter Rosin <peda <at> lysator.liu.se>
---
NEWS | 12 +++++
automake.in | 26 ++++++++--
doc/automake.texi | 20 ++++++++
t/list-of-tests.mk | 1 +
t/preproc-reldir.sh | 129 +++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 182 insertions(+), 6 deletions(-)
create mode 100755 t/preproc-reldir.sh
diff --git a/NEWS b/NEWS
index 6dcce72..e27e0cf 100644
--- a/NEWS
+++ b/NEWS
@@ -100,6 +100,18 @@ New in 1.13.2:
be longer necessary, so we deprecate it with runtime warnings. It will
likely be removed altogether in Automake 1.14.
+* Relative directory in Makefile fragments:
+
+ - The special Automake-time substitutions '%reldir%' and '%canon_reldir%'
+ (and their short versions, '%D%' and '%C%' respectively) can now be used
+ in an included Makefile fragment. The former is substituted with the
+ relative directory of the included fragment (compared to the top level
+ including Makefile), and the latter with the canonicalized version of
+ the same relative directory:
+
+ bin_PROGRAMS += %reldir%/foo
+ %canon_reldir%_foo_SOURCES = {reldir}/bar.c
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13.2:
diff --git a/automake.in b/automake.in
index d6ed599..80e54ff 100644
--- a/automake.in
+++ b/automake.in
@@ -6330,15 +6330,16 @@ sub check_trailing_slash ($\$)
}
-# &read_am_file ($AMFILE, $WHERE)
-# -------------------------------
+# &read_am_file ($AMFILE, $WHERE, $RELDIR)
+# ----------------------------------------
# Read Makefile.am and set up %contents. Simultaneously copy lines
# from Makefile.am into $output_trailer, or define variables as
# appropriate. NOTE we put rules in the trailer section. We want
# user rules to come after our generated stuff.
-sub read_am_file ($$)
+sub read_am_file ($$$)
{
- my ($amfile, $where) = @_;
+ my ($amfile, $where, $reldir) = @_;
+ my $canon_reldir = &canonicalize ($reldir);
my $am_file = new Automake::XFile ("< $amfile");
verb "reading $amfile";
@@ -6423,6 +6424,17 @@ sub read_am_file ($$)
my $new_saw_bk = check_trailing_slash ($where, $_);
+ if ($reldir eq '.')
+ {
+ # If present, eat the following '_' or '/', converting
+ # "%reldir%/foo" and "%canon_reldir%_foo" into plain "foo"
+ # when $reldir is '.'.
+ $_ =~ s,%(D|reldir)%/,,g;
+ $_ =~ s,%(C|canon_reldir)%_,,g;
+ }
+ $_ =~ s/%(D|reldir)%/${reldir}/g;
+ $_ =~ s/%(C|canon_reldir)%/${canon_reldir}/g;
+
if (/$IGNORE_PATTERN/o)
{
# Merely delete comments beginning with two hashes.
@@ -6584,8 +6596,10 @@ sub read_am_file ($$)
push_dist_common ("\$\(srcdir\)/$path");
$path = $relative_dir . "/" . $path if $relative_dir ne '.';
}
+ my $new_reldir = File::Spec->abs2rel ($path, $relative_dir);
+ $new_reldir = '.' if $new_reldir !~ s,/[^/]*$,,;
$where->push_context ("'$path' included from here");
- &read_am_file ($path, $where);
+ &read_am_file ($path, $where, $new_reldir);
$where->pop_context;
}
else
@@ -6658,7 +6672,7 @@ sub read_main_am_file ($$)
&define_standard_variables;
# Read user file, which might override some of our values.
- &read_am_file ($amfile, new Automake::Location);
+ &read_am_file ($amfile, new Automake::Location, '.');
}
diff --git a/doc/automake.texi b/doc/automake.texi
index feae3ac..d420d28 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -10519,6 +10519,26 @@ condition applies to the entire contents of that fragment.
Makefile fragments included this way are always distributed because
they are needed to rebuild @file{Makefile.in}.
+Inside a fragment, the construct @code{%reldir%} is replaced with the
+directory of the fragment relative to the base @file{Makefile.am}.
+Similarly, @code{%canon_reldir%} is replaced with the canonicalized
+(@pxref{Canonicalization}) form of @code{%reldir%}. As a convenience,
+@code{%D%} is a synonym for @code{%reldir%}, and @code{%C%}
+is a synonym for @code{%canon_reldir%}.
+
+A special feature is that if the fragment is in the same directory as
+the base @file{Makefile.am} (i.e., @code{%reldir%} is @code{.}), then
+@code{%reldir%} and @code{%canon_reldir%} will expand to the empty
+string as well as eat, if present, a following slash or underscore
+respectively.
+
+Thus, a makefile fragment might look like this:
+
+@example
+bin_PROGRAMS += %reldir%/mumble
+%canon_reldir%_mumble_SOURCES = %reldir%/one.c
+@end example
+
@node Conditionals
@chapter Conditionals
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 0acbdcf..72c99ee 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -865,6 +865,7 @@ t/pr401.sh \
t/pr401b.sh \
t/pr401c.sh \
t/prefix.sh \
+t/preproc-reldir.sh \
t/primary.sh \
t/primary2.sh \
t/primary3.sh \
diff --git a/t/preproc-reldir.sh b/t/preproc-reldir.sh
new file mode 100755
index 0000000..ab443df
--- /dev/null
+++ b/t/preproc-reldir.sh
@@ -0,0 +1,129 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Test %reldir% and %canon_reldir%.
+
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_PROG_CC
+AM_PROG_CC_C_O
+AC_CONFIG_FILES([zot/Makefile])
+AC_OUTPUT
+END
+
+mkdir foo
+mkdir foo/bar
+mkdir foo/foobar
+mkdir zot
+
+cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
+bin_PROGRAMS =
+include $(top_srcdir)/foo/local.mk
+include $(srcdir)/foo/foobar/local.mk
+include local.mk
+END
+
+cat > zot/Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
+bin_PROGRAMS =
+include $(top_srcdir)/zot/local.mk
+include $(top_srcdir)/top.mk
+include ../reltop.mk
+END
+
+cat > local.mk << 'END'
+%canon_reldir%_whoami:
+ @echo "I am %reldir%/local.mk"
+
+bin_PROGRAMS += %reldir%/mumble
+%canon_reldir%_mumble_SOURCES = %reldir%/one.c
+END
+
+cat > top.mk << 'END'
+%canon_reldir%_top_whoami:
+ @echo "I am %reldir%/top.mk"
+
+bin_PROGRAMS += %D%/scream
+%C%_scream_SOURCES = %D%/two.c
+END
+
+cat > reltop.mk << 'END'
+%C%_reltop_whoami:
+ @echo "I am %D%/reltop.mk"
+
+bin_PROGRAMS += %reldir%/sigh
+%canon_reldir%_sigh_SOURCES = %reldir%/three.c
+END
+
+cat > one.c << 'END'
+int main(void) { return 0; }
+END
+
+cp local.mk foo
+cp local.mk foo/bar
+cp local.mk foo/foobar
+cp local.mk zot
+echo "include %reldir%/bar/local.mk" >> foo/local.mk
+
+cp one.c foo
+cp one.c foo/bar
+cp one.c foo/foobar
+cp one.c zot
+cp one.c two.c
+cp one.c three.c
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE -a
+./configure
+
+$MAKE whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am local.mk" output
+$MAKE foo_whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am foo/local.mk" output
+$MAKE foo_bar_whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am foo/bar/local.mk" output
+$MAKE foo_foobar_whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am foo/foobar/local.mk" output
+
+$MAKE
+./mumble
+foo/mumble
+foo/bar/mumble
+foo/foobar/mumble
+
+cd zot
+
+$MAKE ___top_whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am ../top.mk" output
+$MAKE ___reltop_whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am ../reltop.mk" output
+$MAKE whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am local.mk" output
+
+$MAKE
+./mumble
+../scream
+../sigh
--
1.7.9
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Fri, 08 Feb 2013 08:47:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 13524 <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
* t/preproc-demo.sh: New test, a "demo" of how the new pre-processing
feature could be used in a real-world package.
* t/preproc-errmsg.sh: New test, check that error messages remain
useful when the new pre-processing features are involved.
* t/preproc-reldir.sh: Split up ...
* t/preproc-basics.sh, t/preproc-c-compile.sh: ... into these two
tests, with some refactorings, clean-up and enhancements.
* t/list-of-tests.mk: Adjust.
Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
t/list-of-tests.mk | 5 +-
t/preproc-basics.sh | 106 +++++++++++++++++++++++
t/preproc-c-compile.sh | 118 +++++++++++++++++++++++++
t/preproc-demo.sh | 222 ++++++++++++++++++++++++++++++++++++++++++++++++
t/preproc-errmsg.sh | 75 ++++++++++++++++
t/preproc-reldir.sh | 129 ----------------------------
6 files changed, 525 insertions(+), 130 deletions(-)
create mode 100755 t/preproc-basics.sh
create mode 100755 t/preproc-c-compile.sh
create mode 100755 t/preproc-demo.sh
create mode 100755 t/preproc-errmsg.sh
delete mode 100755 t/preproc-reldir.sh
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 72c99ee..679fe5d 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -865,7 +865,10 @@ t/pr401.sh \
t/pr401b.sh \
t/pr401c.sh \
t/prefix.sh \
-t/preproc-reldir.sh \
+t/preproc-basics.sh \
+t/preproc-c-compile.sh \
+t/preproc-demo.sh \
+t/preproc-errmsg.sh \
t/primary.sh \
t/primary2.sh \
t/primary3.sh \
diff --git a/t/preproc-basics.sh b/t/preproc-basics.sh
new file mode 100755
index 0000000..6000d88
--- /dev/null
+++ b/t/preproc-basics.sh
@@ -0,0 +1,106 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Basic tests for '%...%' preprocessing in included Makefile fragments:
+# %reldir% a.k.a. %D%
+# %canon_reldir% a.k.a. %C%
+
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_CONFIG_FILES([zot/Makefile])
+AC_OUTPUT
+END
+
+mkdir foo foo/bar foo/foobar zot
+
+cat > Makefile.am << 'END'
+include $(top_srcdir)/foo/local.mk
+include $(srcdir)/foo/foobar/local.mk
+include local.mk
+END
+
+cat > zot/Makefile.am << 'END'
+include $(top_srcdir)/zot/local.mk
+
+## Check that '%canon_reldir%' doesn't remain overridden
+## by the previous include.
+%canon_reldir%_zot_whoami:
+ echo "I am %reldir%/Makefile.am" >$@
+
+include $(top_srcdir)/top.mk
+include ../reltop.mk
+END
+
+cat > local.mk << 'END'
+%canon_reldir%_whoami:
+ echo "I am %reldir%/local.mk" >$@
+END
+
+cat > top.mk << 'END'
+%canon_reldir%_top_whoami:
+ echo "I am %reldir%/top.mk" >$@
+END
+
+cat > reltop.mk << 'END'
+%C%_reltop_whoami:
+ echo "I am %D%/reltop.mk" >$@
+END
+
+cp local.mk foo
+cp local.mk foo/bar
+cp local.mk foo/foobar
+cp local.mk zot
+
+cat >> foo/local.mk << 'END'
+include %reldir%/bar/local.mk
+## Check that '%canon_reldir%' doesn't remain overridden by the
+## previous include. The duplicated checks are done to ensure that
+## Automake substitutes all pre-processing occurrences on a line,
+## not just the first one.
+test-%reldir%:
+ test '%reldir%' = foo && test '%reldir%' = foo
+ test '%D%' = foo && test '%D%' = foo
+ test '%canon_reldir%' = foo && test '%C%' = foo
+END
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+./configure
+
+check ()
+{
+ test $# -eq 2 || fatal_ "made_into(): bad usage"
+ target=$1 contents=$2
+ rm -f "$target" \
+ && $MAKE "$target" \
+ && test x"$(cat "$target")" = x"$contents"
+}
+
+check whoami "I am local.mk"
+check foo_whoami "I am foo/local.mk"
+check foo_bar_whoami "I am foo/bar/local.mk"
+check foo_foobar_whoami "I am foo/foobar/local.mk"
+$MAKE test-foo
+
+cd zot
+check whoami "I am local.mk"
+check ___top_whoami "I am ../top.mk"
+check ___reltop_whoami "I am ../reltop.mk"
+check zot_whoami "I am Makefile.am"
+
+:
diff --git a/t/preproc-c-compile.sh b/t/preproc-c-compile.sh
new file mode 100755
index 0000000..79e9325
--- /dev/null
+++ b/t/preproc-c-compile.sh
@@ -0,0 +1,118 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Test pre-processing substitutions '%reldir%' and '%canon_reldir%'
+# with C compilation and subdir objects.
+
+require=cc
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_PROG_CC
+AM_PROG_CC_C_O
+AC_CONFIG_FILES([zot/Makefile])
+AC_OUTPUT
+END
+
+mkdir foo
+mkdir foo/bar
+mkdir foo/foobar
+mkdir zot
+
+cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
+SUBDIRS = zot
+bin_PROGRAMS =
+
+include $(top_srcdir)/foo/local.mk
+include $(srcdir)/foo/foobar/local.mk
+include local.mk
+
+check-local:
+ is $(bin_PROGRAMS) == \
+ foo/mumble2$(EXEEXT) \
+ foo/bar/mumble$(EXEEXT) \
+ foo/foobar/mumble$(EXEEXT) \
+ mumble$(EXEEXT)
+ test '$(mumble_SOURCES)' = one.c
+ test '$(foo_mumble2_SOURCES)' = foo/one.c
+ test '$(foo_bar_mumble_SOURCES)' = foo/bar/one.c
+ test '$(foo_foobar_mumble_SOURCES)' = foo/foobar/one.c
+ test -f mumble$(EXEEXT)
+ test -f foo/mumble2$(EXEEXT)
+ test -f foo/bar/mumble$(EXEEXT)
+ test -f foo/foobar/mumble$(EXEEXT)
+ test -f zot/mumble$(EXEEXT)
+ : Test some of the object files too.
+ test -f one.$(OBJEXT)
+ test -f foo/foobar/one.$(OBJEXT)
+ test -f zot/one.$(OBJEXT)
+END
+
+cat > zot/Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
+bin_PROGRAMS =
+include $(top_srcdir)/zot/local.mk
+
+test:
+ test '$(bin_PROGRAMS)' == mumble$(EXEEXT)
+ test '$(mumble_SOURCES)' = one.c
+check-local: test
+END
+
+cat > local.mk << 'END'
+bin_PROGRAMS += %reldir%/mumble
+%canon_reldir%_mumble_SOURCES = %reldir%/one.c
+END
+
+echo 'int main (void) { return 0; }' > one.c
+
+sed 's/mumble/mumble2/' local.mk > foo/local.mk
+cp local.mk foo/bar
+cp local.mk foo/foobar
+cp local.mk zot
+echo "include %reldir%/bar/local.mk" >> foo/local.mk
+
+cp one.c foo
+cp one.c foo/bar
+cp one.c foo/foobar
+cp one.c zot
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+./configure
+
+$MAKE
+$MAKE check-local
+if ! cross_compiling; then
+ ./mumble
+ ./foo/mumble2
+ ./foo/bar/mumble
+ ./foo/foobar/mumble
+ ./zot/mumble
+fi
+
+(cd zot && $MAKE test)
+
+# GNU install refuses to override a just-installed file; since we
+# have plenty of 'mumble' dummy programs to install in the same
+# location, such "overridden installations" are not a problem for
+# us, so just force the use the 'install-sh' script
+ac_cv_path_install=$(pwd)/install-sh; export ac_cv_path_install
+$MAKE distcheck
+
+:
diff --git a/t/preproc-demo.sh b/t/preproc-demo.sh
new file mode 100755
index 0000000..f8d1e25
--- /dev/null
+++ b/t/preproc-demo.sh
@@ -0,0 +1,222 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Demo of a package using pre-processing substitutions '%reldir%' and
+# '%canon_reldir%', and their respective shorthands '%D%' and '%C%'.
+
+am_create_testdir=empty
+required=cc
+. test-init.sh
+
+if cross_compiling; then
+ WE_ARE_CROSS_COMPILING=yes
+else
+ WE_ARE_CROSS_COMPILING=no
+fi
+export WE_ARE_CROSS_COMPILING
+
+cat > configure.ac << 'END'
+AC_INIT([GNU Demo], [0.7], [bug-automake <at> gnu.org])
+AC_CONFIG_AUX_DIR([build-aux])
+AM_INIT_AUTOMAKE([1.12.6 foreign subdir-objects -Wall])
+AM_CONDITIONAL([NATIVE_BUILD], [test $WE_ARE_CROSS_COMPILING != yes])
+AC_CONFIG_FILES([Makefile])
+AC_PROG_CC
+AM_PROG_CC_C_O
+AM_PROG_AR
+AC_PROG_RANLIB
+AC_OUTPUT
+END
+
+mkdir build-aux lib lib/tests src tests
+
+## Top level.
+
+cat > Makefile.am << 'END'
+bin_PROGRAMS =
+check_PROGRAMS =
+noinst_LIBRARIES =
+AM_CPPFLAGS =
+AM_TESTS_ENVIRONMENT =
+CLEANFILES =
+EXTRA_DIST =
+LDADD =
+TESTS =
+XFAIL_TESTS =
+
+include $(srcdir)/src/progs.am
+include $(srcdir)/lib/gnulib.am
+include $(srcdir)/tests/check.am
+END
+
+## Src subdir.
+
+cat > src/progs.am <<'END'
+bin_PROGRAMS += %reldir%/hello
+
+bin_PROGRAMS += %D%/goodbye
+%canon_reldir%_goodbye_SOURCES = %D%/hello.c
+%C%_goodbye_CPPFLAGS = $(AM_CPPFLAGS) -DGREETINGS='"Goodbye"'
+
+# The testsuite should have access to our built programs.
+AM_TESTS_ENVIRONMENT += \
+ PATH='$(abs_builddir)/%reldir%':$$PATH; \
+ export PATH;
+END
+
+cat > src/hello.c <<'END'
+#include "safe-print.h"
+#include <stdlib.h>
+#include <stdio.h>
+
+#ifndef GREETINGS
+# define GREETINGS "Hello"
+#endif
+
+int
+main (void)
+{
+ safe_print (stdout, GREETINGS ", World!\n");
+ exit (EXIT_SUCCESS);
+}
+END
+
+## Lib subdir.
+
+cat > lib/gnulib.am << 'END'
+noinst_LIBRARIES += %D%/libgnu.a
+
+AM_CPPFLAGS += -I%D% -I$(top_srcdir)/%D%
+LDADD += $(noinst_LIBRARIES)
+
+%C%_libgnu_a_SOURCES = \
+ %D%/safe-print.c \
+ %D%/safe-print.h
+
+if NATIVE_BUILD
+include %D%/tests/gnulib-check.am
+endif
+END
+
+cat > lib/safe-print.c <<'END'
+#include "safe-print.h"
+#include <string.h>
+#include <stdlib.h>
+
+void
+safe_print (FILE *fp, const char * str)
+{
+ if (fprintf (fp, "%s", str) != strlen (str)
+ || fflush (fp) != 0 || ferror (fp))
+ {
+ fprintf (stderr, "I/O error\n");
+ exit (EXIT_FAILURE);
+ }
+}
+
+END
+
+cat > lib/safe-print.h <<'END'
+#include <stdio.h>
+void safe_print (FILE *, const char *);
+END
+
+## Lib/Tests (sub)subdir.
+
+cat > lib/tests/gnulib-check.am <<'END'
+check_PROGRAMS += %D%/safe-print-test
+TESTS += $(check_PROGRAMS)
+XFAIL_TESTS += %D%/safe-print-test
+END
+
+cat > lib/tests/safe-print-test.c <<'END'
+#include "safe-print.h"
+int
+main (void)
+{
+ FILE *fp;
+ if ((fp = fopen ("/dev/full", "w")) == NULL)
+ return 77;
+ safe_print (fp, "dummy\n");
+ return 0;
+}
+END
+
+## Tests subdir.
+
+cat > tests/check.am <<'END'
+TEST_EXTENSIONS = .sh
+SH_LOG_COMPILER = $(SHELL)
+
+TESTS += %D%/hello.sh
+EXTRA_DIST += %D%/hello.sh
+
+TESTS += %D%/goodbye.sh
+CLEANFILES += %D%/goodbye.sh
+%D%/goodbye.sh: %D%/hello.sh
+ $(MKDIR_P) %D%
+ rm -f $@ $@-t
+ sed -e 's/hello/goodbye/' \
+ -e 's/Hello/Goodbye/' \
+ < $(srcdir)/%D%/hello.sh >$@-t
+ chmod a-w,a+x $@-t && mv -f $@-t $@
+END
+
+cat > tests/hello.sh <<'END'
+#!/bin/sh
+set -x -e
+if test "$WE_ARE_CROSS_COMPILING" = yes; then
+ echo Skipping: cannot run in cross-compilation mode
+ exit 77
+else
+ hello || exit 1
+ test "`hello`" = 'Hello, World!' || exit 1
+fi
+END
+
+## Go.
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --add-missing --copy
+test ! -e compile
+test -f build-aux/compile
+
+./configure
+
+$MAKE
+
+$MAKE check >stdout || { cat stdout; exit 1; }
+cat stdout
+cat tests/hello.log
+cat tests/goodbye.log
+if cross_compiling; then
+ test ! -e lib/tests/safe-print-test.log
+ count_test_results total=2 pass=0 fail=0 xpass=0 xfail=0 skip=2 error=0
+else
+ if test -c /dev/full && test -w /dev/full; then
+ s=0 x=1
+ grep "I/O error" lib/tests/safe-print-test.log
+ else
+ cat lib/tests/safe-print-test.log
+ s=1 x=0
+ fi
+ count_test_results total=3 pass=2 fail=0 xpass=0 xfail=$x skip=$s error=0
+fi
+
+$MAKE distcheck
+
+:
diff --git a/t/preproc-errmsg.sh b/t/preproc-errmsg.sh
new file mode 100755
index 0000000..d7cf488
--- /dev/null
+++ b/t/preproc-errmsg.sh
@@ -0,0 +1,75 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Tests error messages when '%reldir%' and '%canon_reldir%' substitutions
+# (and their shorthands '%D%' and '%C%') are involved.
+
+. test-init.sh
+
+cat >> configure.ac <<'END'
+AC_PROG_CC
+AC_PROG_RANLIB
+AM_PROG_AR
+END
+
+: > ar-lib
+
+mkdir sub sub/sub2
+
+cat > Makefile.am <<'END'
+%canon_reldir%_x1_SOURCES = bar.c
+include sub/local.mk
+END
+
+cat > sub/local.mk <<'END'
+AUTOMAKE_OPTIONS = -Wno-extra-portability
+include %D%/sub2/more.mk
+noinst_LIBRARIES = %reldir%-one.a %D%-two.a
+%C%_x2_SOURCES = foo.c
+END
+
+cat > sub/sub2/more.mk <<'END'
+%C%_UNDEFINED +=
+END
+
+$ACLOCAL
+AUTOMAKE_fails
+
+cat > expected << 'END'
+sub/sub2/more.mk:1: sub_sub2_UNDEFINED must be set with '=' before using '+='
+Makefile.am:2: 'sub/local.mk' included from here
+sub/local.mk:2: 'sub/sub2/more.mk' included from here
+sub/local.mk:3: 'sub-one.a' is not a standard library name
+sub/local.mk:3: did you mean 'libsub-one.a'?
+Makefile.am:2: 'sub/local.mk' included from here
+sub/local.mk:3: 'sub-two.a' is not a standard library name
+sub/local.mk:3: did you mean 'libsub-two.a'?
+Makefile.am:2: 'sub/local.mk' included from here
+Makefile.am:1: variable 'x1_SOURCES' is defined but no program or
+Makefile.am:1: library has 'x1' as canonical name (possible typo)
+sub/local.mk:4: variable 'sub_x2_SOURCES' is defined but no program or
+sub/local.mk:4: library has 'sub_x2' as canonical name (possible typo)
+Makefile.am:2: 'sub/local.mk' included from here
+END
+
+sed -e '/warnings are treated as errors/d' \
+ -e 's/: warning:/:/' -e 's/: error:/:/' \
+ -e 's/ */ /g' \
+ <stderr >obtained
+
+diff expected obtained
+
+:
diff --git a/t/preproc-reldir.sh b/t/preproc-reldir.sh
deleted file mode 100755
index ab443df..0000000
--- a/t/preproc-reldir.sh
+++ /dev/null
@@ -1,129 +0,0 @@
-#! /bin/sh
-# Copyright (C) 2013 Free Software Foundation, Inc.
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2, or (at your option)
-# any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, see <http://www.gnu.org/licenses/>.
-
-# Test %reldir% and %canon_reldir%.
-
-. test-init.sh
-
-cat >> configure.ac << 'END'
-AC_PROG_CC
-AM_PROG_CC_C_O
-AC_CONFIG_FILES([zot/Makefile])
-AC_OUTPUT
-END
-
-mkdir foo
-mkdir foo/bar
-mkdir foo/foobar
-mkdir zot
-
-cat > Makefile.am << 'END'
-AUTOMAKE_OPTIONS = subdir-objects
-bin_PROGRAMS =
-include $(top_srcdir)/foo/local.mk
-include $(srcdir)/foo/foobar/local.mk
-include local.mk
-END
-
-cat > zot/Makefile.am << 'END'
-AUTOMAKE_OPTIONS = subdir-objects
-bin_PROGRAMS =
-include $(top_srcdir)/zot/local.mk
-include $(top_srcdir)/top.mk
-include ../reltop.mk
-END
-
-cat > local.mk << 'END'
-%canon_reldir%_whoami:
- @echo "I am %reldir%/local.mk"
-
-bin_PROGRAMS += %reldir%/mumble
-%canon_reldir%_mumble_SOURCES = %reldir%/one.c
-END
-
-cat > top.mk << 'END'
-%canon_reldir%_top_whoami:
- @echo "I am %reldir%/top.mk"
-
-bin_PROGRAMS += %D%/scream
-%C%_scream_SOURCES = %D%/two.c
-END
-
-cat > reltop.mk << 'END'
-%C%_reltop_whoami:
- @echo "I am %D%/reltop.mk"
-
-bin_PROGRAMS += %reldir%/sigh
-%canon_reldir%_sigh_SOURCES = %reldir%/three.c
-END
-
-cat > one.c << 'END'
-int main(void) { return 0; }
-END
-
-cp local.mk foo
-cp local.mk foo/bar
-cp local.mk foo/foobar
-cp local.mk zot
-echo "include %reldir%/bar/local.mk" >> foo/local.mk
-
-cp one.c foo
-cp one.c foo/bar
-cp one.c foo/foobar
-cp one.c zot
-cp one.c two.c
-cp one.c three.c
-
-$ACLOCAL
-$AUTOCONF
-$AUTOMAKE -a
-./configure
-
-$MAKE whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am local.mk" output
-$MAKE foo_whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am foo/local.mk" output
-$MAKE foo_bar_whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am foo/bar/local.mk" output
-$MAKE foo_foobar_whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am foo/foobar/local.mk" output
-
-$MAKE
-./mumble
-foo/mumble
-foo/bar/mumble
-foo/foobar/mumble
-
-cd zot
-
-$MAKE ___top_whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am ../top.mk" output
-$MAKE ___reltop_whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am ../reltop.mk" output
-$MAKE whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am local.mk" output
-
-$MAKE
-./mumble
-../scream
-../sigh
--
1.7.9
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Fri, 08 Feb 2013 09:12:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 2013-02-08 09:45, Peter Rosin wrote:
> Stefano Lattarini wrote:
>> Fine as well. And of curse, if you want to speed thing up and have more
>> control on the final result, feel free to shepherd the pending patches to
>> the agreed form ;-) -- which if I'm not mistaken is:
>>
>> - make the series consist of only two patches, one introducing the
>> feature (complete with documentation and NEWS additions, plus your
>> original test case), and one follow-up patch implementing my
>> testsuite enhancement;
>>
>> - use the '%...%' form, and prefer lower-case for long names (so,
>> '%reldir%' a.k.a. '%D%' and '%canon-reldir%' a.k.a. '%C%').
>
> Done. I didn't address the canonicalization concern raised by Miles. That
> seems like a bigger issue than this patch series. However, If that naming
> is changing, it must be done before this series lands in a released
> version, or we'll end up with bad comptibility hacks...
Errm, compatibility...
Forgot to ask, but should I push out this non-fast-forward to the
experimental/preproc branch?
That would be 'git checkout experimental/preproc' followed by
'git push -f origin', right? I did rewrite that branch locally
assuming the old branch was destined for the bin, but I have
never actually done such a rewind of upstream before...
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Fri, 08 Feb 2013 11:35:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/08/2013 05:13 AM, Miles Bader wrote:
>>> Hmm, if that's the case, then I think "canon" is the wrong term to
>>> use, as it typically implies that the result is still in the same
>>> domain as the input.
>>>
>> Suggestions for a better name then?
>
> Dunno... something like "RELDIR_SYM" would make sense ... it's a
> symbol corresponding to RELDIR...
>
But if we go this way, we should also fix the manual (and some function
names in the automake script itself) to use the new terminology instead
of the one based on "canonicalization"; otherwise we risk more confusion
and inconsistencies. And this "SYM" doesn't sounds clear nor expressive
enough IMHO.
So, unless someone comes up with a new term that can be easily used in
the documentation as well, I think staying with "canonicalize" is the
lesser evil.
Regards,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Fri, 08 Feb 2013 12:32:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/08/2013 10:11 AM, Peter Rosin wrote:
> On 2013-02-08 09:45, Peter Rosin wrote:
>> Stefano Lattarini wrote:
>>> Fine as well. And of curse, if you want to speed thing up and have more
>>> control on the final result, feel free to shepherd the pending patches to
>>> the agreed form ;-) -- which if I'm not mistaken is:
>>>
>>> - make the series consist of only two patches, one introducing the
>>> feature (complete with documentation and NEWS additions, plus your
>>> original test case), and one follow-up patch implementing my
>>> testsuite enhancement;
>>>
>>> - use the '%...%' form, and prefer lower-case for long names (so,
>>> '%reldir%' a.k.a. '%D%' and '%canon-reldir%' a.k.a. '%C%').
>>
>> Done. I didn't address the canonicalization concern raised by Miles. That
>> seems like a bigger issue than this patch series. However, If that naming
>> is changing, it must be done before this series lands in a released
>> version, or we'll end up with bad comptibility hacks...
>
> Errm, compatibility...
>
> Forgot to ask, but should I push out this non-fast-forward to the
> experimental/preproc branch?
>
Yes please. I will rewind it again once I have, as you suggest, fixed
my "demo test" not to needlessly fiddle with '/dev/full'.
> That would be 'git checkout experimental/preproc' followed by
> 'git push -f origin', right? I did rewrite that branch locally
> assuming the old branch was destined for the bin, but I have
> never actually done such a rewind of upstream before...
>
I fear that Savannah forbid such simple for of non-fast-forward pushes.
Here is what you can do to still force the rewind:
$ git branch -m experimental/preproc x
$ git push origin :experimental/preproc
$ git branch -m x experimental/preproc
$ git push origin experimental/preproc
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 14 Feb 2013 10:28:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/08/2013 01:31 PM, Stefano Lattarini wrote:
> On 02/08/2013 10:11 AM, Peter Rosin wrote:
>> On 2013-02-08 09:45, Peter Rosin wrote:
>>> Stefano Lattarini wrote:
>>>> Fine as well. And of curse, if you want to speed thing up and have more
>>>> control on the final result, feel free to shepherd the pending patches to
>>>> the agreed form ;-) -- which if I'm not mistaken is:
>>>>
>>>> - make the series consist of only two patches, one introducing the
>>>> feature (complete with documentation and NEWS additions, plus your
>>>> original test case), and one follow-up patch implementing my
>>>> testsuite enhancement;
>>>>
>>>> - use the '%...%' form, and prefer lower-case for long names (so,
>>>> '%reldir%' a.k.a. '%D%' and '%canon-reldir%' a.k.a. '%C%').
>>>
>>> Done. I didn't address the canonicalization concern raised by Miles. That
>>> seems like a bigger issue than this patch series. However, If that naming
>>> is changing, it must be done before this series lands in a released
>>> version, or we'll end up with bad comptibility hacks...
>>
>> Errm, compatibility...
>>
>> Forgot to ask, but should I push out this non-fast-forward to the
>> experimental/preproc branch?
>>
> Yes please. I will rewind it again once I have, as you suggest, fixed
> my "demo test" not to needlessly fiddle with '/dev/full'.
>
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; 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>).
Thanks,
Stefano
-*-*-*-
Peter Rosin (1):
preproc: add support for relative names in included fragments
Stefano Lattarini (1):
preproc: enhance and extend tests
NEWS | 12 +++
automake.in | 26 ++++--
doc/automake.texi | 20 +++++
t/list-of-tests.mk | 4 +
t/preproc-basics.sh | 106 +++++++++++++++++++++++
t/preproc-c-compile.sh | 118 +++++++++++++++++++++++++
t/preproc-demo.sh | 230 +++++++++++++++++++++++++++++++++++++++++++++++++
t/preproc-errmsg.sh | 75 ++++++++++++++++
8 files changed, 585 insertions(+), 6 deletions(-)
create mode 100755 t/preproc-basics.sh
create mode 100755 t/preproc-c-compile.sh
create mode 100755 t/preproc-demo.sh
create mode 100755 t/preproc-errmsg.sh
--
1.8.1.1.662.gaa39828
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 14 Feb 2013 10:28:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 13524 <at> debbugs.gnu.org (full text, mbox):
From: Peter Rosin <peda <at> lysator.liu.se>
The rationale for this change is that it is annoying to have
to repeat the directory name when including a Makefile fragment.
For deep directory structures these repeats can generate a lot
of bloat. It also hinders reuse and easy directory restructuring
if all Makefile fragments have to know exactly where they live.
Suggested by Bob Friesenhahn, and later discussed in bug#13524.
In the course of discussion, the following notations were rejected:
&{reldir}& - to hard to type, {reldir} - interferes with ${reldir},
{am_reldir} - short form {D} interferes with ${D}, @am_reldir@ - short
form @D@ interferes with AC_SUBST([D]) as well as invading the
config.status turf. Other notations were also suggested...
* automake.in (read_am_file): Add third argument specifying the
relative directory of this Makefile fragment compared to the
main Makefile. Replace %reldir% and %canon_reldir% in the
fragment with this relative directory (with slashes etc, or
canonicalized).
(read_main_am_file): Adjust.
* t/preproc-reldir.sh: New test.
* t/list-of-tests.mk: Augment.
* doc/automake.texi (Include): Document the new feature.
NEWS: Add new feature.
Co-authored-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Signed-off-by: Peter Rosin <peda <at> lysator.liu.se>
---
NEWS | 12 +++++
automake.in | 26 ++++++++---
doc/automake.texi | 20 ++++++++
t/list-of-tests.mk | 1 +
t/preproc-reldir.sh | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 182 insertions(+), 6 deletions(-)
create mode 100755 t/preproc-reldir.sh
diff --git a/NEWS b/NEWS
index 6dcce72..e27e0cf 100644
--- a/NEWS
+++ b/NEWS
@@ -100,6 +100,18 @@ New in 1.13.2:
be longer necessary, so we deprecate it with runtime warnings. It will
likely be removed altogether in Automake 1.14.
+* Relative directory in Makefile fragments:
+
+ - The special Automake-time substitutions '%reldir%' and '%canon_reldir%'
+ (and their short versions, '%D%' and '%C%' respectively) can now be used
+ in an included Makefile fragment. The former is substituted with the
+ relative directory of the included fragment (compared to the top level
+ including Makefile), and the latter with the canonicalized version of
+ the same relative directory:
+
+ bin_PROGRAMS += %reldir%/foo
+ %canon_reldir%_foo_SOURCES = {reldir}/bar.c
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13.2:
diff --git a/automake.in b/automake.in
index d6ed599..80e54ff 100644
--- a/automake.in
+++ b/automake.in
@@ -6330,15 +6330,16 @@ sub check_trailing_slash ($\$)
}
-# &read_am_file ($AMFILE, $WHERE)
-# -------------------------------
+# &read_am_file ($AMFILE, $WHERE, $RELDIR)
+# ----------------------------------------
# Read Makefile.am and set up %contents. Simultaneously copy lines
# from Makefile.am into $output_trailer, or define variables as
# appropriate. NOTE we put rules in the trailer section. We want
# user rules to come after our generated stuff.
-sub read_am_file ($$)
+sub read_am_file ($$$)
{
- my ($amfile, $where) = @_;
+ my ($amfile, $where, $reldir) = @_;
+ my $canon_reldir = &canonicalize ($reldir);
my $am_file = new Automake::XFile ("< $amfile");
verb "reading $amfile";
@@ -6423,6 +6424,17 @@ sub read_am_file ($$)
my $new_saw_bk = check_trailing_slash ($where, $_);
+ if ($reldir eq '.')
+ {
+ # If present, eat the following '_' or '/', converting
+ # "%reldir%/foo" and "%canon_reldir%_foo" into plain "foo"
+ # when $reldir is '.'.
+ $_ =~ s,%(D|reldir)%/,,g;
+ $_ =~ s,%(C|canon_reldir)%_,,g;
+ }
+ $_ =~ s/%(D|reldir)%/${reldir}/g;
+ $_ =~ s/%(C|canon_reldir)%/${canon_reldir}/g;
+
if (/$IGNORE_PATTERN/o)
{
# Merely delete comments beginning with two hashes.
@@ -6584,8 +6596,10 @@ sub read_am_file ($$)
push_dist_common ("\$\(srcdir\)/$path");
$path = $relative_dir . "/" . $path if $relative_dir ne '.';
}
+ my $new_reldir = File::Spec->abs2rel ($path, $relative_dir);
+ $new_reldir = '.' if $new_reldir !~ s,/[^/]*$,,;
$where->push_context ("'$path' included from here");
- &read_am_file ($path, $where);
+ &read_am_file ($path, $where, $new_reldir);
$where->pop_context;
}
else
@@ -6658,7 +6672,7 @@ sub read_main_am_file ($$)
&define_standard_variables;
# Read user file, which might override some of our values.
- &read_am_file ($amfile, new Automake::Location);
+ &read_am_file ($amfile, new Automake::Location, '.');
}
diff --git a/doc/automake.texi b/doc/automake.texi
index feae3ac..d420d28 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -10519,6 +10519,26 @@ condition applies to the entire contents of that fragment.
Makefile fragments included this way are always distributed because
they are needed to rebuild @file{Makefile.in}.
+Inside a fragment, the construct @code{%reldir%} is replaced with the
+directory of the fragment relative to the base @file{Makefile.am}.
+Similarly, @code{%canon_reldir%} is replaced with the canonicalized
+(@pxref{Canonicalization}) form of @code{%reldir%}. As a convenience,
+@code{%D%} is a synonym for @code{%reldir%}, and @code{%C%}
+is a synonym for @code{%canon_reldir%}.
+
+A special feature is that if the fragment is in the same directory as
+the base @file{Makefile.am} (i.e., @code{%reldir%} is @code{.}), then
+@code{%reldir%} and @code{%canon_reldir%} will expand to the empty
+string as well as eat, if present, a following slash or underscore
+respectively.
+
+Thus, a makefile fragment might look like this:
+
+@example
+bin_PROGRAMS += %reldir%/mumble
+%canon_reldir%_mumble_SOURCES = %reldir%/one.c
+@end example
+
@node Conditionals
@chapter Conditionals
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 0acbdcf..72c99ee 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -865,6 +865,7 @@ t/pr401.sh \
t/pr401b.sh \
t/pr401c.sh \
t/prefix.sh \
+t/preproc-reldir.sh \
t/primary.sh \
t/primary2.sh \
t/primary3.sh \
diff --git a/t/preproc-reldir.sh b/t/preproc-reldir.sh
new file mode 100755
index 0000000..ab443df
--- /dev/null
+++ b/t/preproc-reldir.sh
@@ -0,0 +1,129 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Test %reldir% and %canon_reldir%.
+
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_PROG_CC
+AM_PROG_CC_C_O
+AC_CONFIG_FILES([zot/Makefile])
+AC_OUTPUT
+END
+
+mkdir foo
+mkdir foo/bar
+mkdir foo/foobar
+mkdir zot
+
+cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
+bin_PROGRAMS =
+include $(top_srcdir)/foo/local.mk
+include $(srcdir)/foo/foobar/local.mk
+include local.mk
+END
+
+cat > zot/Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
+bin_PROGRAMS =
+include $(top_srcdir)/zot/local.mk
+include $(top_srcdir)/top.mk
+include ../reltop.mk
+END
+
+cat > local.mk << 'END'
+%canon_reldir%_whoami:
+ @echo "I am %reldir%/local.mk"
+
+bin_PROGRAMS += %reldir%/mumble
+%canon_reldir%_mumble_SOURCES = %reldir%/one.c
+END
+
+cat > top.mk << 'END'
+%canon_reldir%_top_whoami:
+ @echo "I am %reldir%/top.mk"
+
+bin_PROGRAMS += %D%/scream
+%C%_scream_SOURCES = %D%/two.c
+END
+
+cat > reltop.mk << 'END'
+%C%_reltop_whoami:
+ @echo "I am %D%/reltop.mk"
+
+bin_PROGRAMS += %reldir%/sigh
+%canon_reldir%_sigh_SOURCES = %reldir%/three.c
+END
+
+cat > one.c << 'END'
+int main(void) { return 0; }
+END
+
+cp local.mk foo
+cp local.mk foo/bar
+cp local.mk foo/foobar
+cp local.mk zot
+echo "include %reldir%/bar/local.mk" >> foo/local.mk
+
+cp one.c foo
+cp one.c foo/bar
+cp one.c foo/foobar
+cp one.c zot
+cp one.c two.c
+cp one.c three.c
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE -a
+./configure
+
+$MAKE whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am local.mk" output
+$MAKE foo_whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am foo/local.mk" output
+$MAKE foo_bar_whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am foo/bar/local.mk" output
+$MAKE foo_foobar_whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am foo/foobar/local.mk" output
+
+$MAKE
+./mumble
+foo/mumble
+foo/bar/mumble
+foo/foobar/mumble
+
+cd zot
+
+$MAKE ___top_whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am ../top.mk" output
+$MAKE ___reltop_whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am ../reltop.mk" output
+$MAKE whoami >output 2>&1 || { cat output; exit 1; }
+cat output
+grep "I am local.mk" output
+
+$MAKE
+./mumble
+../scream
+../sigh
--
1.8.1.1.662.gaa39828
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 14 Feb 2013 10:28:03 GMT)
Full text and
rfc822 format available.
Message #140 received at 13524 <at> debbugs.gnu.org (full text, mbox):
* t/preproc-demo.sh: New test, a "demo" of how the new pre-processing
feature could be used in a real-world package.
* t/preproc-errmsg.sh: New test, check that error messages remain
useful when the new pre-processing features are involved.
* t/preproc-reldir.sh: Split up ...
* t/preproc-basics.sh, t/preproc-c-compile.sh: ... into these two
tests, with some refactorings, clean-up and enhancements.
* t/list-of-tests.mk: Adjust.
Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
t/list-of-tests.mk | 5 +-
t/preproc-basics.sh | 106 ++++++++++++
t/{preproc-reldir.sh => preproc-c-compile.sh} | 115 ++++++-------
t/preproc-demo.sh | 230 ++++++++++++++++++++++++++
t/preproc-errmsg.sh | 75 +++++++++
5 files changed, 467 insertions(+), 64 deletions(-)
create mode 100755 t/preproc-basics.sh
rename t/{preproc-reldir.sh => preproc-c-compile.sh} (50%)
create mode 100755 t/preproc-demo.sh
create mode 100755 t/preproc-errmsg.sh
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 72c99ee..679fe5d 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -865,7 +865,10 @@ t/pr401.sh \
t/pr401b.sh \
t/pr401c.sh \
t/prefix.sh \
-t/preproc-reldir.sh \
+t/preproc-basics.sh \
+t/preproc-c-compile.sh \
+t/preproc-demo.sh \
+t/preproc-errmsg.sh \
t/primary.sh \
t/primary2.sh \
t/primary3.sh \
diff --git a/t/preproc-basics.sh b/t/preproc-basics.sh
new file mode 100755
index 0000000..6000d88
--- /dev/null
+++ b/t/preproc-basics.sh
@@ -0,0 +1,106 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Basic tests for '%...%' preprocessing in included Makefile fragments:
+# %reldir% a.k.a. %D%
+# %canon_reldir% a.k.a. %C%
+
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_CONFIG_FILES([zot/Makefile])
+AC_OUTPUT
+END
+
+mkdir foo foo/bar foo/foobar zot
+
+cat > Makefile.am << 'END'
+include $(top_srcdir)/foo/local.mk
+include $(srcdir)/foo/foobar/local.mk
+include local.mk
+END
+
+cat > zot/Makefile.am << 'END'
+include $(top_srcdir)/zot/local.mk
+
+## Check that '%canon_reldir%' doesn't remain overridden
+## by the previous include.
+%canon_reldir%_zot_whoami:
+ echo "I am %reldir%/Makefile.am" >$@
+
+include $(top_srcdir)/top.mk
+include ../reltop.mk
+END
+
+cat > local.mk << 'END'
+%canon_reldir%_whoami:
+ echo "I am %reldir%/local.mk" >$@
+END
+
+cat > top.mk << 'END'
+%canon_reldir%_top_whoami:
+ echo "I am %reldir%/top.mk" >$@
+END
+
+cat > reltop.mk << 'END'
+%C%_reltop_whoami:
+ echo "I am %D%/reltop.mk" >$@
+END
+
+cp local.mk foo
+cp local.mk foo/bar
+cp local.mk foo/foobar
+cp local.mk zot
+
+cat >> foo/local.mk << 'END'
+include %reldir%/bar/local.mk
+## Check that '%canon_reldir%' doesn't remain overridden by the
+## previous include. The duplicated checks are done to ensure that
+## Automake substitutes all pre-processing occurrences on a line,
+## not just the first one.
+test-%reldir%:
+ test '%reldir%' = foo && test '%reldir%' = foo
+ test '%D%' = foo && test '%D%' = foo
+ test '%canon_reldir%' = foo && test '%C%' = foo
+END
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+./configure
+
+check ()
+{
+ test $# -eq 2 || fatal_ "made_into(): bad usage"
+ target=$1 contents=$2
+ rm -f "$target" \
+ && $MAKE "$target" \
+ && test x"$(cat "$target")" = x"$contents"
+}
+
+check whoami "I am local.mk"
+check foo_whoami "I am foo/local.mk"
+check foo_bar_whoami "I am foo/bar/local.mk"
+check foo_foobar_whoami "I am foo/foobar/local.mk"
+$MAKE test-foo
+
+cd zot
+check whoami "I am local.mk"
+check ___top_whoami "I am ../top.mk"
+check ___reltop_whoami "I am ../reltop.mk"
+check zot_whoami "I am Makefile.am"
+
+:
diff --git a/t/preproc-reldir.sh b/t/preproc-c-compile.sh
similarity index 50%
rename from t/preproc-reldir.sh
rename to t/preproc-c-compile.sh
index ab443df..79e9325 100755
--- a/t/preproc-reldir.sh
+++ b/t/preproc-c-compile.sh
@@ -14,8 +14,10 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-# Test %reldir% and %canon_reldir%.
+# Test pre-processing substitutions '%reldir%' and '%canon_reldir%'
+# with C compilation and subdir objects.
+require=cc
. test-init.sh
cat >> configure.ac << 'END'
@@ -32,49 +34,53 @@ mkdir zot
cat > Makefile.am << 'END'
AUTOMAKE_OPTIONS = subdir-objects
+SUBDIRS = zot
bin_PROGRAMS =
+
include $(top_srcdir)/foo/local.mk
include $(srcdir)/foo/foobar/local.mk
include local.mk
+
+check-local:
+ is $(bin_PROGRAMS) == \
+ foo/mumble2$(EXEEXT) \
+ foo/bar/mumble$(EXEEXT) \
+ foo/foobar/mumble$(EXEEXT) \
+ mumble$(EXEEXT)
+ test '$(mumble_SOURCES)' = one.c
+ test '$(foo_mumble2_SOURCES)' = foo/one.c
+ test '$(foo_bar_mumble_SOURCES)' = foo/bar/one.c
+ test '$(foo_foobar_mumble_SOURCES)' = foo/foobar/one.c
+ test -f mumble$(EXEEXT)
+ test -f foo/mumble2$(EXEEXT)
+ test -f foo/bar/mumble$(EXEEXT)
+ test -f foo/foobar/mumble$(EXEEXT)
+ test -f zot/mumble$(EXEEXT)
+ : Test some of the object files too.
+ test -f one.$(OBJEXT)
+ test -f foo/foobar/one.$(OBJEXT)
+ test -f zot/one.$(OBJEXT)
END
cat > zot/Makefile.am << 'END'
AUTOMAKE_OPTIONS = subdir-objects
bin_PROGRAMS =
include $(top_srcdir)/zot/local.mk
-include $(top_srcdir)/top.mk
-include ../reltop.mk
+
+test:
+ test '$(bin_PROGRAMS)' == mumble$(EXEEXT)
+ test '$(mumble_SOURCES)' = one.c
+check-local: test
END
cat > local.mk << 'END'
-%canon_reldir%_whoami:
- @echo "I am %reldir%/local.mk"
-
bin_PROGRAMS += %reldir%/mumble
%canon_reldir%_mumble_SOURCES = %reldir%/one.c
END
-cat > top.mk << 'END'
-%canon_reldir%_top_whoami:
- @echo "I am %reldir%/top.mk"
-
-bin_PROGRAMS += %D%/scream
-%C%_scream_SOURCES = %D%/two.c
-END
-
-cat > reltop.mk << 'END'
-%C%_reltop_whoami:
- @echo "I am %D%/reltop.mk"
+echo 'int main (void) { return 0; }' > one.c
-bin_PROGRAMS += %reldir%/sigh
-%canon_reldir%_sigh_SOURCES = %reldir%/three.c
-END
-
-cat > one.c << 'END'
-int main(void) { return 0; }
-END
-
-cp local.mk foo
+sed 's/mumble/mumble2/' local.mk > foo/local.mk
cp local.mk foo/bar
cp local.mk foo/foobar
cp local.mk zot
@@ -84,46 +90,29 @@ cp one.c foo
cp one.c foo/bar
cp one.c foo/foobar
cp one.c zot
-cp one.c two.c
-cp one.c three.c
$ACLOCAL
$AUTOCONF
-$AUTOMAKE -a
+$AUTOMAKE
./configure
-$MAKE whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am local.mk" output
-$MAKE foo_whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am foo/local.mk" output
-$MAKE foo_bar_whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am foo/bar/local.mk" output
-$MAKE foo_foobar_whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am foo/foobar/local.mk" output
-
-$MAKE
-./mumble
-foo/mumble
-foo/bar/mumble
-foo/foobar/mumble
-
-cd zot
-
-$MAKE ___top_whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am ../top.mk" output
-$MAKE ___reltop_whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am ../reltop.mk" output
-$MAKE whoami >output 2>&1 || { cat output; exit 1; }
-cat output
-grep "I am local.mk" output
-
$MAKE
-./mumble
-../scream
-../sigh
+$MAKE check-local
+if ! cross_compiling; then
+ ./mumble
+ ./foo/mumble2
+ ./foo/bar/mumble
+ ./foo/foobar/mumble
+ ./zot/mumble
+fi
+
+(cd zot && $MAKE test)
+
+# GNU install refuses to override a just-installed file; since we
+# have plenty of 'mumble' dummy programs to install in the same
+# location, such "overridden installations" are not a problem for
+# us, so just force the use the 'install-sh' script
+ac_cv_path_install=$(pwd)/install-sh; export ac_cv_path_install
+$MAKE distcheck
+
+:
diff --git a/t/preproc-demo.sh b/t/preproc-demo.sh
new file mode 100755
index 0000000..4c1b2d9
--- /dev/null
+++ b/t/preproc-demo.sh
@@ -0,0 +1,230 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Demo of a package using pre-processing substitutions '%reldir%' and
+# '%canon_reldir%', and their respective shorthands '%D%' and '%C%'.
+
+am_create_testdir=empty
+required=cc
+. test-init.sh
+
+if cross_compiling; then
+ WE_ARE_CROSS_COMPILING=yes
+else
+ WE_ARE_CROSS_COMPILING=no
+fi
+export WE_ARE_CROSS_COMPILING
+
+SAFE_PRINT_FAIL=; unset SAFE_PRINT_FAIL
+
+cat > configure.ac << 'END'
+AC_INIT([GNU Demo], [0.7], [bug-automake <at> gnu.org])
+AC_CONFIG_AUX_DIR([build-aux])
+AM_INIT_AUTOMAKE([1.12.6 foreign subdir-objects -Wall])
+AM_CONDITIONAL([NATIVE_BUILD], [test $WE_ARE_CROSS_COMPILING != yes])
+AC_CONFIG_FILES([Makefile])
+AC_PROG_CC
+AM_PROG_CC_C_O
+AM_PROG_AR
+AC_PROG_RANLIB
+AC_OUTPUT
+END
+
+mkdir build-aux lib lib/tests src tests
+
+## Top level.
+
+cat > Makefile.am << 'END'
+bin_PROGRAMS =
+check_PROGRAMS =
+noinst_LIBRARIES =
+AM_CPPFLAGS =
+AM_TESTS_ENVIRONMENT =
+CLEANFILES =
+EXTRA_DIST =
+LDADD =
+TESTS =
+
+include $(srcdir)/src/progs.am
+include $(srcdir)/lib/gnulib.am
+include $(srcdir)/tests/check.am
+END
+
+## Src subdir.
+
+cat > src/progs.am <<'END'
+bin_PROGRAMS += %reldir%/hello
+
+bin_PROGRAMS += %D%/goodbye
+%canon_reldir%_goodbye_SOURCES = %D%/hello.c
+%C%_goodbye_CPPFLAGS = $(AM_CPPFLAGS) -DGREETINGS='"Goodbye"'
+
+# The testsuite should have access to our built programs.
+AM_TESTS_ENVIRONMENT += \
+ PROGDIR='$(top_builddir)/%reldir%'; \
+ export PROGDIR; \
+ PATH='$(abs_builddir)/%reldir%'$(PATH_SEPARATOR)$$PATH; \
+ export PATH;
+END
+
+cat > src/hello.c <<'END'
+#include "safe-print.h"
+#include <stdlib.h>
+#include <stdio.h>
+
+#ifndef GREETINGS
+# define GREETINGS "Hello"
+#endif
+
+int
+main (void)
+{
+ safe_print (stdout, GREETINGS ", World!\n");
+ exit (EXIT_SUCCESS);
+}
+END
+
+## Lib subdir.
+
+cat > lib/gnulib.am << 'END'
+noinst_LIBRARIES += %D%/libgnu.a
+
+AM_CPPFLAGS += -I%D% -I$(top_srcdir)/%D%
+LDADD += $(noinst_LIBRARIES)
+
+%C%_libgnu_a_SOURCES = \
+ %D%/safe-print.c \
+ %D%/safe-print.h
+
+if NATIVE_BUILD
+include %D%/tests/gnulib-check.am
+endif
+END
+
+cat > lib/safe-print.c <<'END'
+#include "safe-print.h"
+#include <string.h>
+#include <stdlib.h>
+
+void
+safe_print (FILE *fp, const char * str)
+{
+ if (fprintf (fp, "%s", str) != strlen (str)
+ || fflush (fp) != 0 || ferror (fp))
+ {
+ fprintf (stderr, "I/O error\n");
+ exit (EXIT_FAILURE);
+ }
+}
+
+END
+
+cat > lib/safe-print.h <<'END'
+#include <stdio.h>
+void safe_print (FILE *, const char *);
+END
+
+## Lib/Tests (sub)subdir.
+
+cat > lib/tests/gnulib-check.am <<'END'
+check_PROGRAMS += %D%/safe-print-test
+TESTS += $(check_PROGRAMS)
+AM_TESTS_ENVIRONMENT += EXEEXT='$(EXEEXT)'; export EXEEXT;
+END
+
+cat > lib/tests/safe-print-test.c <<'END'
+#include "safe-print.h"
+int
+main (void)
+{
+ safe_print (stdout, "dummy\n");
+ return 0;
+}
+END
+
+## Tests subdir.
+
+cat > tests/check.am <<'END'
+TEST_EXTENSIONS = .sh
+SH_LOG_COMPILER = $(SHELL)
+
+handwritten_TESTS = \
+ %D%/hello.sh \
+ %D%/built.sh
+TESTS += $(handwritten_TESTS)
+EXTRA_DIST += $(handwritten_TESTS)
+
+TESTS += %D%/goodbye.sh
+CLEANFILES += %D%/goodbye.sh
+%D%/goodbye.sh: %D%/hello.sh
+ $(MKDIR_P) %D%
+ rm -f $@ $@-t
+ sed -e 's/hello/goodbye/' \
+ -e 's/Hello/Goodbye/' \
+ < $(srcdir)/%D%/hello.sh >$@-t
+ chmod a-w,a+x $@-t && mv -f $@-t $@
+END
+
+cat > tests/hello.sh <<'END'
+#!/bin/sh
+set -x -e
+if test "$WE_ARE_CROSS_COMPILING" = yes; then
+ echo Skipping: cannot run in cross-compilation mode
+ exit 77
+else
+ hello || exit 1
+ test "`hello`" = 'Hello, World!' || exit 1
+fi
+END
+
+cat > tests/built.sh <<'END'
+#!/bin/sh
+set -x
+test -n "$PROGDIR" || exit 99
+test -f "$PROGDIR/hello$EXEEXT" || exit 1
+test -x "$PROGDIR/hello$EXEEXT" || exit 1
+test -f "$PROGDIR/goodbye$EXEEXT" || exit 1
+test -x "$PROGDIR/goodbye$EXEEXT" || exit 1
+END
+
+
+## Go.
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --add-missing --copy
+test ! -e compile
+test -f build-aux/compile
+
+./configure
+
+$MAKE
+
+VERBOSE=x $MAKE check >stdout || { cat stdout; exit 1; }
+cat stdout
+cat tests/built.log
+cat tests/hello.log
+cat tests/goodbye.log
+if cross_compiling; then
+ test ! -e lib/tests/safe-print-test.log
+ count_test_results total=3 pass=1 fail=0 xpass=0 xfail=0 skip=2 error=0
+else
+ count_test_results total=4 pass=4 fail=0 xpass=0 xfail=0 skip=0 error=0
+fi
+
+$MAKE distcheck
+
+:
diff --git a/t/preproc-errmsg.sh b/t/preproc-errmsg.sh
new file mode 100755
index 0000000..d7cf488
--- /dev/null
+++ b/t/preproc-errmsg.sh
@@ -0,0 +1,75 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Tests error messages when '%reldir%' and '%canon_reldir%' substitutions
+# (and their shorthands '%D%' and '%C%') are involved.
+
+. test-init.sh
+
+cat >> configure.ac <<'END'
+AC_PROG_CC
+AC_PROG_RANLIB
+AM_PROG_AR
+END
+
+: > ar-lib
+
+mkdir sub sub/sub2
+
+cat > Makefile.am <<'END'
+%canon_reldir%_x1_SOURCES = bar.c
+include sub/local.mk
+END
+
+cat > sub/local.mk <<'END'
+AUTOMAKE_OPTIONS = -Wno-extra-portability
+include %D%/sub2/more.mk
+noinst_LIBRARIES = %reldir%-one.a %D%-two.a
+%C%_x2_SOURCES = foo.c
+END
+
+cat > sub/sub2/more.mk <<'END'
+%C%_UNDEFINED +=
+END
+
+$ACLOCAL
+AUTOMAKE_fails
+
+cat > expected << 'END'
+sub/sub2/more.mk:1: sub_sub2_UNDEFINED must be set with '=' before using '+='
+Makefile.am:2: 'sub/local.mk' included from here
+sub/local.mk:2: 'sub/sub2/more.mk' included from here
+sub/local.mk:3: 'sub-one.a' is not a standard library name
+sub/local.mk:3: did you mean 'libsub-one.a'?
+Makefile.am:2: 'sub/local.mk' included from here
+sub/local.mk:3: 'sub-two.a' is not a standard library name
+sub/local.mk:3: did you mean 'libsub-two.a'?
+Makefile.am:2: 'sub/local.mk' included from here
+Makefile.am:1: variable 'x1_SOURCES' is defined but no program or
+Makefile.am:1: library has 'x1' as canonical name (possible typo)
+sub/local.mk:4: variable 'sub_x2_SOURCES' is defined but no program or
+sub/local.mk:4: library has 'sub_x2' as canonical name (possible typo)
+Makefile.am:2: 'sub/local.mk' included from here
+END
+
+sed -e '/warnings are treated as errors/d' \
+ -e 's/: warning:/:/' -e 's/: error:/:/' \
+ -e 's/ */ /g' \
+ <stderr >obtained
+
+diff expected obtained
+
+:
--
1.8.1.1.662.gaa39828
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 14 Feb 2013 12:22:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 13524 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Thu, Feb 14, 2013 at 11:26 AM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> From: Peter Rosin <peda <at> lysator.liu.se>
>
> The rationale for this change is that it is annoying to have
> to repeat the directory name when including a Makefile fragment.
> For deep directory structures these repeats can generate a lot
> of bloat. It also hinders reuse and easy directory restructuring
> if all Makefile fragments have to know exactly where they live.
>
> Suggested by Bob Friesenhahn, and later discussed in bug#13524.
>
> In the course of discussion, the following notations were rejected:
> &{reldir}& - to hard to type, {reldir} - interferes with ${reldir},
> {am_reldir} - short form {D} interferes with ${D}, @am_reldir@ - short
> form @D@ interferes with AC_SUBST([D]) as well as invading the
> config.status turf. Other notations were also suggested...
>
> * automake.in (read_am_file): Add third argument specifying the
> relative directory of this Makefile fragment compared to the
> main Makefile. Replace %reldir% and %canon_reldir% in the
> fragment with this relative directory (with slashes etc, or
> canonicalized).
> (read_main_am_file): Adjust.
> * t/preproc-reldir.sh: New test.
> * t/list-of-tests.mk: Augment.
> * doc/automake.texi (Include): Document the new feature.
> NEWS: Add new feature.
>
> Co-authored-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
> Signed-off-by: Peter Rosin <peda <at> lysator.liu.se>
> ---
> NEWS | 12 +++++
> automake.in | 26 ++++++++---
> doc/automake.texi | 20 ++++++++
> t/list-of-tests.mk | 1 +
> t/preproc-reldir.sh | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 182 insertions(+), 6 deletions(-)
> create mode 100755 t/preproc-reldir.sh
>
> diff --git a/NEWS b/NEWS
> index 6dcce72..e27e0cf 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -100,6 +100,18 @@ New in 1.13.2:
> be longer necessary, so we deprecate it with runtime warnings. It will
> likely be removed altogether in Automake 1.14.
>
> +* Relative directory in Makefile fragments:
> +
> + - The special Automake-time substitutions '%reldir%' and '%canon_reldir%'
> + (and their short versions, '%D%' and '%C%' respectively) can now be used
> + in an included Makefile fragment. The former is substituted with the
> + relative directory of the included fragment (compared to the top level
> + including Makefile), and the latter with the canonicalized version of
> + the same relative directory:
> +
> + bin_PROGRAMS += %reldir%/foo
> + %canon_reldir%_foo_SOURCES = {reldir}/bar.c
the rejected '{reldir}' is still used in this example.
Does this substition happens in the whole file, or only in specific
syntactic constructs? What definitily will not work ist something like
this, right?
here = %reldir%
target = %canon_reldir%/foo
bin_PROGRAMS += ${here}/foo
${target}_SOURCES = ${here}/bar.c
Speaking of 'here' wouldn't that also an candidate instead of
'reldir'? and %.% as the shortform of %reldir% does sound:
bin_PROGRAMS += %.%/foo
%canon_here%_foo_SOURCES = %.%/bar.c
Regards,
Bert
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 14 Feb 2013 12:41:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/14/2013 01:20 PM, Bert Wesarg wrote:
> Hi,
>
> On Thu, Feb 14, 2013 at 11:26 AM, Stefano Lattarini wrote:
>
>> diff --git a/NEWS b/NEWS
>> index 6dcce72..e27e0cf 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -100,6 +100,18 @@ New in 1.13.2:
>> be longer necessary, so we deprecate it with runtime warnings. It will
>> likely be removed altogether in Automake 1.14.
>>
>> +* Relative directory in Makefile fragments:
>> +
>> + - The special Automake-time substitutions '%reldir%' and '%canon_reldir%'
>> + (and their short versions, '%D%' and '%C%' respectively) can now be used
>> + in an included Makefile fragment. The former is substituted with the
>> + relative directory of the included fragment (compared to the top level
>> + including Makefile), and the latter with the canonicalized version of
>> + the same relative directory:
>> +
>> + bin_PROGRAMS += %reldir%/foo
>> + %canon_reldir%_foo_SOURCES = {reldir}/bar.c
>
> the rejected '{reldir}' is still used in this example.
>
Yikes! Good catch, fixed now. Thanks.
> Does this substition happens in the whole file, or only in specific
> syntactic constructs?
>
On the whole file, before the automake limited makefile parser is
called. This is by design.
> What definitily will not work ist something like this, right?
>
> here = %reldir%
> target = %canon_reldir%/foo
>
> bin_PROGRAMS += ${here}/foo
> ${target}_SOURCES = ${here}/bar.c
>
The ${target}_SOURCES wouldn't work even when no %...% substitution
is used. As for ${here}, it can work only if that variable is not
redefined in other included fragments. But the reason behind the
%reldir% introduction is exactly saving the developers from the need
of using this kind of brittle indirections ...
>
> Speaking of 'here' wouldn't that also an candidate instead of
> 'reldir'?
>
Actually I find the latter clearer and more expressive. After all,
what we are expanding is exactly the relative directory of the
current makefile fragment w.r.t. the "master" makefile, so the
name 'reldir' sounds really appropriate.
> and %.% as the shortform of %reldir% does sound:
>
> bin_PROGRAMS += %.%/foo
> %canon_here%_foo_SOURCES = %.%/bar.c
>
I find the above rather unreadable; the existing '%D%' shorthand
is good enough IMHO.
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 14 Feb 2013 14:55:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On Thu, 14 Feb 2013, Stefano Lattarini wrote:
> From: Peter Rosin <peda <at> lysator.liu.se>
>
> The rationale for this change is that it is annoying to have
> to repeat the directory name when including a Makefile fragment.
> For deep directory structures these repeats can generate a lot
> of bloat. It also hinders reuse and easy directory restructuring
> if all Makefile fragments have to know exactly where they live.
I was not aware that it is my birthday today but it sure feels like it
now after reading this email. Much thanks to Peter and Stefano for
implementing this.
A substantial blocker for converting large packages to non-recursive
builds will be eliminated. Considerable time and electricity will be
saved.
Bob
--
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 14 Feb 2013 18:53:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/14/2013 03:53 PM, Bob Friesenhahn wrote:
> On Thu, 14 Feb 2013, Stefano Lattarini wrote:
>
>> From: Peter Rosin <peda <at> lysator.liu.se>
>>
>> The rationale for this change is that it is annoying to have
>> to repeat the directory name when including a Makefile fragment.
>> For deep directory structures these repeats can generate a lot
>> of bloat. It also hinders reuse and easy directory restructuring
>> if all Makefile fragments have to know exactly where they live.
>
> I was not aware that it is my birthday today but it sure feels like
> it now after reading this email. Much thanks to Peter and Stefano
> for implementing this.
>
Note that it's Peter the one who should have most of the credit, since
he was the one who set things in motion, wrote all of the code and
documentation (I basically just added tests and did very minor tweaks),
and put up with my nitpicks and bikeshedding. So thanks Peter! And
of course, thanks to anyone else who has contributed feedback and
suggestions.
> A substantial blocker for converting large packages to non-recursive
> builds will be eliminated. Considerable time and electricity will
> be saved.
By chance, do you plan to start using the feature in some package of
yours, even before it lands in a released Automake version? I'm asking
because it could be some months before the next minor (non-bug-fixing)
Automake release.
Best regards,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 14 Feb 2013 19:12:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On Thu, 14 Feb 2013, Stefano Lattarini wrote:
>
>> A substantial blocker for converting large packages to non-recursive
>> builds will be eliminated. Considerable time and electricity will
>> be saved.
>
> By chance, do you plan to start using the feature in some package of
> yours, even before it lands in a released Automake version? I'm asking
> because it could be some months before the next minor (non-bug-fixing)
> Automake release.
I might be convinced to test it with GraphicsMagick (presumably a
collection of sed substitutions would be sufficient to edit the
Makefiles) but would not want to release any software based on an
unreleased Automake.
Bob
--
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Thu, 14 Feb 2013 19:24:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/14/2013 08:10 PM, Bob Friesenhahn wrote:
> On Thu, 14 Feb 2013, Stefano Lattarini wrote:
>>
>>> A substantial blocker for converting large packages to non-recursive
>>> builds will be eliminated. Considerable time and electricity will
>>> be saved.
>>
>> By chance, do you plan to start using the feature in some package of
>> yours, even before it lands in a released Automake version? I'm asking
>> because it could be some months before the next minor (non-bug-fixing)
>> Automake release.
>
> I might be convinced to test it with GraphicsMagick (presumably a
> collection of sed substitutions would be sufficient to edit the Makefiles)
> but would not want to release any software based on an unreleased Automake.
>
Of course. I was thinking more about an experimental branch where the
new feature could be used (so that an unreleased Automake version would
be required only to bootstrap that branch); and such a branch wouldn't
be merged back into the "trunk" until the require feature has appeared
in a released Automake.
Regards,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Sat, 23 Feb 2013 17:49:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 13524 <at> debbugs.gnu.org (full text, mbox):
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; 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).
OK? I will proceed to do so in a couple of days if there are no
objections.
Thanks,
Stefano
Reply sent
to
Stefano Lattarini <stefano.lattarini <at> gmail.com>:
You have taken responsibility.
(Tue, 05 Mar 2013 16:34:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Miles Bader <miles <at> gnu.org>:
bug acknowledged by developer.
(Tue, 05 Mar 2013 16:34:02 GMT)
Full text and
rfc822 format available.
Message #166 received at 13524-done <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 11 Mar 2013 09:33:01 GMT)
Full text and
rfc822 format available.
Message #169 received at 13524 <at> debbugs.gnu.org (full text, mbox):
Hi,
I have one more question here:
On Thu, Feb 14, 2013 at 1:39 PM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> On 02/14/2013 01:20 PM, Bert Wesarg wrote:
>> Hi,
>>
>> On Thu, Feb 14, 2013 at 11:26 AM, Stefano Lattarini wrote:
>> What definitily will not work ist something like this, right?
>>
>> here = %reldir%
>> target = %canon_reldir%/foo
>>
>> bin_PROGRAMS += ${here}/foo
>> ${target}_SOURCES = ${here}/bar.c
>>
I have the impression that variable references in filenames aren't
supported anyway, right?
Thanks,
Bert
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 11 Mar 2013 09:49:01 GMT)
Full text and
rfc822 format available.
Message #172 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 03/11/2013 10:31 AM, Bert Wesarg wrote:
> Hi,
>
> I have one more question here:
>
> On Thu, Feb 14, 2013 at 1:39 PM, Stefano Lattarini
> <stefano.lattarini <at> gmail.com> wrote:
>> On 02/14/2013 01:20 PM, Bert Wesarg wrote:
>>> Hi,
>>>
>>> On Thu, Feb 14, 2013 at 11:26 AM, Stefano Lattarini wrote:
>>> What definitily will not work ist something like this, right?
>>>
>>> here = %reldir%
>>> target = %canon_reldir%/foo
>>>
>>> bin_PROGRAMS += ${here}/foo
>>> ${target}_SOURCES = ${here}/bar.c
>>>
>
> I have the impression that variable references in filenames aren't
> supported anyway, right?
>
Wrong, actually. What isn't supported are variable references in
variable/primary names:
$ cat > Makefile.am <<-END
foo = bin
$(foo)_PROGRAMS = bar
END
$ automake -a
Makefile.am:2: bad characters in variable name `$(foo)_PROGRAMS'
Makefile.am:2: `$(foo)_PROGRAMS' is used but `$(foo)dir' is undefined
Best regards,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 11 Mar 2013 12:07:02 GMT)
Full text and
rfc822 format available.
Message #175 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 11, 2013 at 10:46 AM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> On 03/11/2013 10:31 AM, Bert Wesarg wrote:
>> I have the impression that variable references in filenames aren't
>> supported anyway, right?
>>
> Wrong, actually.
But when I prefixing a source file with '$(src)/' and use
subdir-objects then I get something like this in the Makefile.in
$(src)/test-test.o: $(src)/test.c
And after a configure I get an '$(src)' directory in my build dir.
- 8< - Makefile.am - >8 -
src = .
bin_PROGRAMS = test
test_SOURCES = \
$(src)/test.c
test_CPPFLAGS = \
$(AM_CPPFLAGS) -W
- >8 - Makefile.am - 8< -
Bert
>
> Best regards,
> Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#13524; Package
automake.
(Mon, 11 Mar 2013 19:00:02 GMT)
Full text and
rfc822 format available.
Message #178 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 03/11/2013 01:05 PM, Bert Wesarg wrote:
> On Mon, Mar 11, 2013 at 10:46 AM, Stefano Lattarini
> <stefano.lattarini <at> gmail.com> wrote:
>> On 03/11/2013 10:31 AM, Bert Wesarg wrote:
>>> I have the impression that variable references in filenames aren't
>>> supported anyway, right?
>>>
>> Wrong, actually.
>
> But when I prefixing a source file with '$(src)/' and use
> subdir-objects then I get something like this in the Makefile.in
>
> $(src)/test-test.o: $(src)/test.c
>
> And after a configure I get an '$(src)' directory in my build dir.
>
Yes -- and this is intended behavior of subdir-objects. Why do you
think Automake is acting wrong? (Honest question, I might be missing
something here ...)
> - 8< - Makefile.am - >8 -
>
> src = .
> bin_PROGRAMS = test
> test_SOURCES = \
> $(src)/test.c
> test_CPPFLAGS = \
> $(AM_CPPFLAGS) -W
>
> - >8 - Makefile.am - 8< -
>
> Bert
>
Regards,
Stefano
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 09 Apr 2013 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 130 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.