bug#13435: Please don't kill DJGPP support...
On 02/03/2013 09:33 PM, Stefano Lattarini wrote: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13435 On 01/28/2013 02:55 PM, Stefano Lattarini wrote: On 01/23/2013 01:16 PM, Stefano Lattarini wrote: I've pushed my attempt to the public rewindable branch 'experimental/djgpp-for-WinNT'. Could you give it a try, when you have time? Ping? I'd like to have confirmation of whether DJGPP support works for modern Windows before doing the 1.13.2 release; if that's the case, the planned backward incompatibilities section in NEWS will have to be update to make it clear that we only plan to remove DJGPP-on-DOS support, and that DGJPP-on-Windows should continue to work correctly. Ping x 2 ? Another ping. Consider that I will not merge the patch reinstating DJGPP support until someone has confirmed it actually works. Regards, Stefano
bug#13435: Please don't kill DJGPP support...
tags 13435 + moreinfo patch thanks On 03/05/2013 08:43 PM, DJ Delorie wrote: I won't hold you up. Since none of my folks thought it important enough to take the time to test it, please just back-burner it. If someone here needs the patch, they know where to find it. OK. I just find it a pity to throw away DJGPP support at this point, since it turned out that the code needed to support it was really simple after all. Anyway, in the meantime I'm marking this report as more info needed (where such info is the result of the needed test exposure). I'll close the report as wontfix a couple of months in the future if nobody has reported anything by then. Thanks, and best regards, Stefano
Re: bug#13435: Please don't kill DJGPP support...
On 02/03/2013 09:33 PM, Stefano Lattarini wrote: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13435 On 01/28/2013 02:55 PM, Stefano Lattarini wrote: On 01/23/2013 01:16 PM, Stefano Lattarini wrote: I've pushed my attempt to the public rewindable branch 'experimental/djgpp-for-WinNT'. Could you give it a try, when you have time? Ping? I'd like to have confirmation of whether DJGPP support works for modern Windows before doing the 1.13.2 release; if that's the case, the planned backward incompatibilities section in NEWS will have to be update to make it clear that we only plan to remove DJGPP-on-DOS support, and that DGJPP-on-Windows should continue to work correctly. Ping x 2 ? Another ping. Consider that I will not merge the patch reinstating DJGPP support until someone has confirmed it actually works. Regards, Stefano
Re: bug#13524: [PATCH 0/2] Improving user experience for non-recursive builds
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
Re: bug#13435: Please don't kill DJGPP support...
tags 13435 + moreinfo patch thanks On 03/05/2013 08:43 PM, DJ Delorie wrote: I won't hold you up. Since none of my folks thought it important enough to take the time to test it, please just back-burner it. If someone here needs the patch, they know where to find it. OK. I just find it a pity to throw away DJGPP support at this point, since it turned out that the code needed to support it was really simple after all. Anyway, in the meantime I'm marking this report as more info needed (where such info is the result of the needed test exposure). I'll close the report as wontfix a couple of months in the future if nobody has reported anything by then. Thanks, and best regards, Stefano
[PATCH] perl: perl subroutine prototypes are evil, don't use them
Basically, they are not really prototypes, but rather a trick to have
user-defined subroutines that behave more similarly to perl built-in
functions, by allowing them to be called without parentheses and to
impose context on their argument. Such semantics can be useful in some
selected situations, but it causes unexpected and harmful behaviours
and side effects if we try to use perl prototypes as we would use C
prototypes.
See the excellent article Far More than Everything You've Ever Wanted
to Know about Prototypes in Perl by Tom Christiansen for more detailed
information:
http://www.perlmonks.org/?node_id=861966
http://web.archive.org/web/20080421062920/\
library.n0i.net/programming/perl/articles/fm_prototypes
It is important to note that modern perl allows a non-predeclared
subroutine to be called without the '' character, as long as its
call uses proper parentheses:
foo 'str', 2; # will trigger errors if foo is not predeclared
foo('str', 2); # ok even if foo is not predeclared
foo('str', 2); # ditto; but the '' is old-style and redundant
Note also that the prototype indicating no argument:
sub func() { ... }
can actually be useful, and has no discernible downsides, so we'll
keep using it where it makes sense.
Also, in few, selected cases, we *want* to have subroutines behave like
perl builtins (e.g., we want the 'append_exeext' function to be able
to take a code block as first argument). In such cases, we will of
course continue to make use of perl subroutine prototypes.
Let's just see an example that might clarify the kind of problems the
use of subroutine prototypes in perl can cause. This is just scratching
the surface; there are several other aspects, typically subtler and more
dangerous, that are not touched here.
If you have the prototyped subroutine definition:
sub foo ($@)
{
my $s = shift;
print SCALAR: $s\n;
print ARRAY: @_\n;
}
and call 'foo' in code like:
@list = (-1, 0, 1);
foo(@list);
you won't get a compile-time nor a runtime error (as a naive interpretation
of the prototype characterization would let you think). Rather, the
prototype will cause the array '@list' will be coerced into scalar context
before being passed too 'foo', which means that its *length* (3) will be
passed to 'foo' as first argument; and since no further arguments are
present after '@list', that *void* will be coerced to an empty list before
being passed to 'foo'.
So code above will have the result of printing:
SCALAR: 3
ARRAY:
Quite tricky, and definitely a behaviour we don't want to rely on.
* automake.in: Delete most subroutine prototypes. Fix few of the
remaining ones. Related minor simplifications and adjustments.
* lib/gen-perl-protos: Adjust.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
As usual, I'll push in 72 hours if there no reviews or objections by then.
automake.in | 224 +++-
1 file changed, 117 insertions(+), 107 deletions(-)
diff --git a/automake.in b/automake.in
index 70f1f67..bbf0c88 100644
--- a/automake.in
+++ b/automake.in
@@ -529,7 +529,7 @@ my %am_file_cache;
# macro_define() call because SUFFIXES definitions impact
# on $KNOWN_EXTENSIONS_PATTERN which is used used when parsing
# the input am file.
-sub var_SUFFIXES_trigger ($$)
+sub var_SUFFIXES_trigger
{
my ($type, $value) = @_;
accept_extensions (split (' ', $value));
@@ -946,23 +946,23 @@ register_language ('name' = 'java',
# err_am ($MESSAGE, [%OPTIONS])
# -
# Uncategorized errors about the current Makefile.am.
-sub err_am ($;%)
+sub err_am
{
- msg_am ('error', shift, @_);
+ msg_am ('error', @_);
}
# err_ac ($MESSAGE, [%OPTIONS])
# -
# Uncategorized errors about configure.ac.
-sub err_ac ($;%)
+sub err_ac
{
- msg_ac ('error', shift, @_);
+ msg_ac ('error', @_);
}
# msg_am ($CHANNEL, $MESSAGE, [%OPTIONS])
# ---
# Messages about about the current Makefile.am.
-sub msg_am ($$;%)
+sub msg_am
{
my ($channel, $msg, %opts) = @_;
msg $channel, ${am_file}.am, $msg, %opts;
@@ -971,7 +971,7 @@ sub msg_am ($$;%)
# msg_ac ($CHANNEL, $MESSAGE, [%OPTIONS])
# ---
# Messages about about configure.ac.
-sub msg_ac ($$;%)
+sub msg_ac
{
my ($channel, $msg, %opts) = @_;
msg $channel, $configure_ac, $msg, %opts;
@@ -985,7 +985,7 @@ sub msg_ac ($$;%)
# We do this to avoid having the substitutions directly in automake.in;
# when we do that they are sometimes removed and this causes confusion
# and bugs.
-sub subst ($)
+sub subst
{
my ($text) = @_;
return '@' . $text . '@';
@@ -1000,7 +1000,7 @@ sub subst ($)
# If I cd $RELDIR, then to come back, I should cd $BACKPATH.
# For instance 'src/foo' = '../..'.
# Works with non strictly increasing paths, i.e., 'src/../lib' = '..'.
-sub backname
Re: [PATCH] build: use AC_CONFIG_HEADERS, not AM_CONFIG_HEADER
Hi Pavel. On 03/05/2013 02:56 PM, Pavel Raiskup wrote: Dear Stefano, sorry for so late response, On 12/30/2012 10:35 AM, Paolo Bonzini wrote: Il 29/12/2012 21:43, Stefano Lattarini ha scritto: On 12/29/2012 08:46 PM, Paolo Bonzini wrote: Il 29/12/2012 17:32, Stefano Lattarini ha scritto: * configure.ac: Here. The latter has been removed in Automake 1.13. Is there any reason for this, Avoiding to keep too much cruft around the codebase, and smoothing possible future transitions to Automake-NG. Two lines of code are not cruft. It's only cruft if it happens _outside_ the definition of AM_CONFIG_HEADER itself. apart from randomly breaking perfectly-working packages? The right way to do this is to rely on the autoupdate machinery. I thought I had deprecated this macro in the 1.12.x series already, with proper warnings. Wasn't that the case? Deprecating is different from letting autoupdate convert it automatically. At any rate, I agree the error message caused by the abrupt removal is horrible. I'll soon post a patch to have still-exiting uses of AM_CONFIG_HEADER give a clear error message (as is done for the AM_C_PROTOTYPES since Automake 1.12). Making that fix quickly available will be a good reason for a 1.13.1 release. I'm still thinking about this resolution. Could you please reconsider again this situation? We have in Fedora 18 about 700+ packages dependent on automake. I gues No need to, the AM_CONFIG_HEADER will be re-introduced in 1.13.2 (it will raise a warning, but no fatal error). Not sure when I'll have proper time to tie the loose ends still present in the repo, and roll a new beta for 1.13.2, though, so just be patient. s that other distributions have similar numbers. Quite a lot of these packages are still dependent on AM_CONFIG_HEADER, etc. The future incompatibility is *not* big pain for developers; but mostly for disto build systems :( I hadn't consider this aspect originally. Still, the issue can in the meantime wroked around by having you packagers patch the automake used to package re-bootstrapping (unfortunately, having you simply redefine AM_CONFIG_HEADER in a custom $ACLOCAL_PATH entry is not an option ATM, since currently Automake prefers its own m4 macros unconadionaly; that will be fixed in the next major version, where Automake will give precedence to definitions in $ACLOCAL_PATH entries). Maintainers are thus forced not to do updates for automake because of these problems ~ and users will not have then easy access to the newest up2date automake source. I know that because I have done the automake update to 1.13 and it was **too** early. My bad I know - I should know that but it seems to be quite unnecessary. Important to note is that I really don't want to make multiple packages like automake113/automake114/(or whatever new version it will be). I just want to have one easy and stable package 'automake'. I don't want to have the same source in distribution multiple times — to fix some security/code problems on multiple places each time they comes. The only solution for me was revert as quickly as possible your changes — re-add obsoleted macros back to automake downstream. And next time I'll be definitely **much more** careful. Could you please look at it once again please? [SNIP] First of all, please consider re-adding the obsolete macros back to automake, it would be really appreciated. It's already done. You'll just have to wait for the fix to hit a released version, sorry. Regards, Stefano
Re: bug#13578: [IMPORTANT] Savannah issues
On 02/28/2013 08:59 AM, Peter Rosin wrote: [SNIP] A second rewrite undoing (quotes here since the rewrite can't be undone, and me and probably others as well will have to adjust the local repo a second time) the first is probably the lesser evil, even if it is another branch rewrite. It should be done now. Please check the repository really is in a correct state. Regards, Stefano
Re: bug#13578: [IMPORTANT] Savannah issues
On 02/28/2013 09:12 AM, Miles Bader wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: So we should maybe go (after the next major release) with this naming scheme for the branches? * maint - for next micro version * stable - for next minor version * master - for next major version That seems to match common practice, insofar as I understand it... OK, I don't dislike this naming scheme, so I will implement it once 1.14 has been released (at that point, we'll be able to do so without having to resort to non-fast-forward pushes). That might take an undetermined time between a couple of months and forever. I have no intention of discussing further the bike-shedding of branch naming, so this naming scheme will be the one we'll use, period. [Another consideration is whether you have a single named branch for maintenance (e.g. maint, and stable), or just use version-named branches (and thus can maintain multiple versions simultaneously).] The former, I only want to have one maintenance branch. Having several for older versions is just too work for no real gain (and if a security fix is needed, bug-fixing branches for several old releases can just be created on demand without anu fuss). Thanks for the feedback, and best regards, Stefano
Re: bug#13578: [IMPORTANT] Savannah issues
On 02/27/2013 02:25 AM, Miles Bader wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: You might have good points, and possibly even be completely right... But I must ask, why didn't you step up during the lengthy discussion about this change, nor objected during the delay (almost a week) that was deliberately let pass between the decision and the implementation -- precisely to let this kind of late objections to come out? I just didn't notice the name change... In retrospective, since that change wasn't strictly required to implement the new versioning scheme, it should have been proposed and discussed in a separate thread, to make sure it sticked out properly ... Regards, Stefano
Re: bug#13578: [IMPORTANT] Savannah issues
On 02/27/2013 02:31 AM, Miles Bader wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: And while you *might* have changed my mind before (because you have valid points, and maybe it would have better to err on the side of safety), I have now already rewritten maint, so rather than messing up by rewriting it again (to its old value, granted, but a rewrite nonetheless) and reverting an already made decision (and made after considerable discussion and not negligible efforts), I'd rather stuck with the current minor mess. Rewriting to the old value makes a _huge_ difference (at least with git), because people that haven't done a pull or whatever of the new value will then have no problem at all. So whether another rename causes more or less pain depends on what proportion of people that have a pointer to your repository do frequent updates. As automake seems to be the sort of project that has mostly casual contributors, I'd wager many people _haven't_ pulled the changed version, and so would be _helped_ by a rename-to-the-old-value (and hurt by not doing so). As I said in my reply to Peter, feel free to reach a decision on-list and implement it. I'm not going to touch the Automake repository myself for some (possibly several) days anyway. Regards, Stefano
Re: bug#13578: [IMPORTANT] Savannah issues
On 02/27/2013 10:28 AM, Peter Rosin wrote: [SNIP] The long winding eyes glossing over discussion about version numbers had nothing in it about branches, except the initial proposal which stated: * None of 'maint', 'master' and 'next' should be rewindable. It also stated: I also propose the following change to the branching scheme currently implemented in the Automake Git repository: * The 'maint' branch will be reserved to cut of the next micro release; so it will just see fixes for regressions, trivial bugs, or documentation issues, and no active development whatsoever. * The 'master' branch will be where the development of the next minor release will take place; that is, a sort of middle-ground between the roles so far fulfilled by the 'maint' and 'master' branches in the current branching scheme. * The (new) 'next' branch will be reserved for the development of the next major release; it will basically take over the rule that is currently fulfilled by the 'master' branch. I thought that was making clear that the then-current 'maint' and 'master' branches would have needed to be renamed in order to implement that new scheme. But re-reading the above, I realize I wasn't making that clear at all (it sounded clear to me because the details were fresh and clear in my mind then). I was not aware that 'master' and 'next' were rewindable before. Then there was the last message before the implementation that stated: In a couple of days, I will proceed with this branch moving: * branch-1.13.2 - maint * maint - master * master - next No other message mentions git branches that I could find, but I might have missed some instance. Now, there are more than one way to move branches. The most natural is to merge your way forward, Not in this case, as 'master' had several commits lacking in 'maint'. in fact that's the only one that makes sense if the branches are *not* *rewindable*. Thinking about this for a few minutes, I think I would have (with better commit messages): # create 'next' $ git branch next master # update 'master' $ git branch new-master maint $ git checkout new-master $ git merge --strategy=ours master -m rename maint - master This would have obtained the wrong effect; what was in master before my attempted renaming shouldn't have landed in the new 'master', but only in 'next'. In the new 'master', we only wanted what was in the old 'maint'. $ git checkout master $ git merge new-master # a simple fast-forward $ git branch -D new-master # update 'maint' $ git branch new-maint branch-1.13.2 $ git checkout new-maint $ git merge --strategy=ours maint -m rename branch-1.13.2 - maint $ git checkout maint $ git merge new-maint # a simple fast-forward $ git branch -D new-maint Same issue as above. Forgive me for assuming that the branches would not be rewound. Also, I was away skiing last week, but I wouldn't have caught this even if I had been present. BTW, I assume you could still use the mid part to update master, instead of waiting for the savannah crew to help you. Of course, we don't need any help from Savannah, since, as I said, no commit has been lost. If you want to revert the botched renaming, you just need to rename the current 'maint' to 'branch-1.13.2', and recover the previous 'maint' from the last merge into 'master' (that has not been re-written), and delete the 'next' branch. As I said, if you reach a consensus on that (and I guess you will), feel free to go ahead with that. No objection from me. You just have to replace the first git branch new-master ... with $ git branch new-master b4dbcb75 (Because I think b4dbcb75 is what 'maint' was before you rewrote it.) [BIG SNIP] OK, I thought about those considerations, but the situation seemed much less bleak [SNIP] Why why why didn't you explain that in your rationale when proposing the change? If you truly wanted input, you should have stated the negatives as well in case someone had stronger reasons for being negative. Because I mistakenly didn't think they were relevant negatives. So new rule for me: from now on, all the negative sides I can think of are relevant, no matter how tiny or even irrelevant they appear to me. [SNIP] Regards, Stefano
Re: bug#13578: [IMPORTANT] Savannah issues
On 02/27/2013 02:07 PM, Nate Bargmann wrote: [SNIP] Not in this case, as 'master' had several commits lacking in 'maint'. Would 'git cherry-pick' have worked? No, because those commit were to be *dropped* (not added) from master; the old 'master' containing them was to be renamed to 'next'. [SNIP] In other words, master contained commits intended for '2.0'+ (for instance) that you didn't want in 1.13+, etc.? Exactly. Perhaps a new branch for 1.13+ cut from some earlier commit in master and leaving master alone would have worked? What would have worked with minimal disruption would have been to keep the current names until the next major version (maybe just renaming 'branch-1.13.2' to 'fix' or 'micro' *after* the bug-fixing release); just after the new major release, 'fix', 'maint' and 'master' would have pointed to the *same* commit, so we could have juggled and swapped their names without causing any non-ff push. I thought the disruption of doing the renames right now would have been negligible anyway, but apparently I was badly wrong in that. master would have then been consigned to being for new development which isn't what you explicitly stated in the policy above. I have to agree with Miles on the common assumption of the master branch in Git as sort of a quasi-stable of the development tree. So we should maybe go (after the next major release) with this naming scheme for the branches? * maint - for next micro version * stable - for next minor version * master - for next major version [SNIP] Thank, Stefano
Re: bug#13578: [IMPORTANT] Savannah issues
On 02/28/2013 12:00 AM, Peter Rosin wrote: [SNIP] What I meant was that you can use (some of) my above proposed merges to go forward with the new role for master instead of requiring help from Savannah to allow rewriting master. So... now are you ok with *completing* my branch renaming instead of reverting the part of it that has already been done? Puzzled... As I said, if you reach a consensus on that (and I guess you will), feel free to go ahead with that. No objection from me. You are the maintainer, I'm just stating my opinion. I honestly don't know what I think is best to do now, when the rewriting has already started but not yet completed. I guess it's your mess, and I don't really want to take responsibility for it by stepping in and trying to clear it up. I.e., I will only offer my opinion at this point. Fine, I'll revert the partial branch renaming when I have time to do that with enough care and attention to avoid another half-done botch-up (might be few days or a week or more; please don't push to the repo in the meantime). [BIG SNIP] Regards, Stefano
Re: bug#13578: [IMPORTANT] Savannah issues
Hi Peter. On 02/26/2013 12:53 AM, Peter Rosin wrote: On 2013-02-25 10:16, Stefano Lattarini wrote: Note that the users can avoid branch-rewriting issues by renaming their 'master' to 'next' and their 'maint' to 'master' before pulling. This should probably be stated in a message (on list *and* on savannah news) advertising the new versioning and branching scheme (message not yet written; it will be once the current issue is sorted out). Hiding stuff like that in some documentation or on a mailing list will not help. You should make it *easy* for people to work on and contribute to automake. Forcing everyone to do a bunch of silly boring renames is not *easy*. It's an obstacle, and obstacles make people nervous and uneasy. Not good, and no, you can't document it away. You might have good points, and possibly even be completely right... But I must ask, why didn't you step up during the lengthy discussion about this change, nor objected during the delay (almost a week) that was deliberately let pass between the decision and the implementation -- precisely to let this kind of late objections to come out? What is the point of having such discussions in the first place, if people who oppose a proposed change (maybe even on solid ground and with sound reasons) only object *after* the change has been discussed, accepted and implemented? It's quite hostile to do non-fast-forwards on branches as central as master and maint. And I think git/savannah is rejecting them quite rightly! Savannah is rejecting all non-fast-forward pushes (which I find annoying); but it didn't prevent me from deleting and recreating maint, a change that will still appear as a non-fast-forward to any clone of our repository. The reason it doesn't allow me to delete master as well is that doing so would prevent a git clone from checking out the sources of a freshly cloned automake, which can be very confusing (and of course, git cannot be aware of the fact that I intend to re-create 'master' just after having deleted it). The reason is irrelevant. non-fast-forwards of central branches is evil. Mostly, yes. This time, considering that no commits were actually being dropped or rewritten, I believed it wasn't not that bad, and was IMHO justified by the new improved versioning and branching scheme. And while you *might* have changed my mind before (because you have valid points, and maybe it would have better to err on the side of safety), I have now already rewritten maint, so rather than messing up by rewriting it again (to its old value, granted, but a rewrite nonetheless) and reverting an already made decision (and made after considerable discussion and not negligible efforts), I'd rather stuck with the current minor mess. That said, if it turns out that I'm in minority in supporting such an approach, then feel free to revert the maint rewrite [1] (and I'll drop the planned master rewrite); I'm not here to forcibly impose my will on the majority, at least not when the majority has good points or valid concerns. [1] And rename the bug-fixing branch to something like 'fix' or 'micro', and adjust HACKING accordingly -- with a clear and explicative commit message. Whatever the result will be, I'm starting to lose faith in the usefulness of having lengthy discussion for controversial changes beforehand; if we don't and I just go ahead with my idea, some (or most) people will complain after the fact; if we do, and a consensus is reached and implemented, some people still complain after the fact. Not a great situation, motivational-wise ... master and maint have never been published as rewindable, and it should be correct to base new work on them. They should be left alone, IMHO. Their content has been left alone in fact; it's their name that hasn't. You should have implemented this more gradually, such that next would have taken its role directly, but maint and master should have been allowed to grow into the correct branches once the relevant releases had been made. This would give a very confusing interim period IMHO. Yes, confusing. Changes like this cause confusion. However, note that that we can still implement such a gentler transition (for 'master' only) if you really want to, by using a new branch name (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a temporary alias to 'next' until the 2.0 release (at which point all of 'maint', 'master' and 'next' will be fast-forwarded to the commit that implements the 2.0 release). I still prefer to pull this sore tooth out right now, though. So messy. Indeed. Better be consistent and rewrite 'master' too. Or even better, implement the change right after a major release so that master and maint would have been correctly positioned from the start. I have a few single-commit local branches that I will simply have to cherry-pick to the new world order. No, just rebase them on the new name
bug#13578: [IMPORTANT] Savannah issues
On 02/25/2013 09:14 AM, Peter Rosin wrote: On 2013-02-23 19:06, Stefano Lattarini wrote: On 02/23/2013 06:46 PM, Stefano Lattarini wrote: On 02/21/2013 04:06 PM, Stefano Lattarini wrote: In a couple of days, I will proceed with this branch moving: * branch-1.13.2 - maint * maint - master * master - next Done. Damn, not really. For some questionable reason, Savannah is rejecting my non-fast-forward push to master even if I specify '--force', and I cannot use the usual trick delete the remote branch, then push the local one to it trick that I typically use to work around this problem, since 'master' is the current branch of the remote repository, and that cannot be deleted to avoid confusing git clone. I was not aware that those moves would be non-fast-forwards, and I think this is bad bad bad. Note that the users can avoid branch-rewriting issues by renaming their 'master' to 'next' and their 'maint' to 'master' before pulling. This should probably be stated in a message (on list *and* on savannah news) advertising the new versioning and branching scheme (message not yet written; it will be once the current issue is sorted out). It's quite hostile to do non-fast-forwards on branches as central as master and maint. And I think git/savannah is rejecting them quite rightly! Savannah is rejecting all non-fast-forward pushes (which I find annoying); but it didn't prevent me from deleting and recreating maint, a change that will still appear as a non-fast-forward to any clone of our repository. The reason it doesn't allow me to delete master as well is that doing so would prevent a git clone from checking out the sources of a freshly cloned automake, which can be very confusing (and of course, git cannot be aware of the fact that I intend to re-create 'master' just after having deleted it). master and maint have never been published as rewindable, and it should be correct to base new work on them. They should be left alone, IMHO. Their content has been left alone in fact; it's their name that hasn't. You should have implemented this more gradually, such that next would have taken its role directly, but maint and master should have been allowed to grow into the correct branches once the relevant releases had been made. This would give a very confusing interim period IMHO. However, note that that we can still implement such a gentler transition (for 'master' only) if you really want to, by using a new branch name (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a temporary alias to 'next' until the 2.0 release (at which point all of 'maint', 'master' and 'next' will be fast-forwarded to the commit that implements the 2.0 release). I still prefer to pull this sore tooth out right now, though. Or even better, implement the change right after a major release so that master and maint would have been correctly positioned from the start. I have a few single-commit local branches that I will simply have to cherry-pick to the new world order. No, just rebase them on the new name of the branch they were based on; that is, if they were based on 'master', they are now to be considered based on 'next', if they were based on 'maint', they are now to be considered based on 'master', and if they were based on 'branch-1.13.2' they are not to be considered based on 'maint'. Or is there some better way to move these branches after their base has been pulled from under them? The good thing is that is has not been really pulled away, just *renamed*. Remember that Git branches are just movable tags basically, so as long as you have another handle referencing the same commit a branch points to (be that a tag or another branch), nothing is lost by removing the branch -- you are just removing a tag, not any real content. Hopefully there isn't some big chunk of unpublished work that will be killed by these disruptive changes... No, there is not. As said, no pre-existing commit has been dropped by my planned renames. HTH, Stefano
bug#13578: [IMPORTANT] Savannah issues
On 02/23/2013 07:06 PM, Stefano Lattarini wrote: In a couple of days, I will proceed with this branch moving: * branch-1.13.2 - maint * maint - master * master - next Done. Damn, not really. For some questionable reason, Savannah is rejecting my non-fast-forward push to master even if I specify '--force', and I cannot use the usual trick delete the remote branch, then push the local one to it trick that I typically use to work around this problem, since 'master' is the current branch of the remote repository, and that cannot be deleted to avoid confusing git clone. So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN INCONSISTENT STATE* (not broken, mind you, merely inconsistent with our new declared policies), and should not be used until this issue is resolved. I don't have time to look into this presently, I had time today, so I submitted a Task in the Savannah interface: https://savannah.gnu.org/task/index.php?12497 Regards, Stefano
Re: bug#13578: [IMPORTANT] Savannah issues
On 02/25/2013 09:14 AM, Peter Rosin wrote: On 2013-02-23 19:06, Stefano Lattarini wrote: On 02/23/2013 06:46 PM, Stefano Lattarini wrote: On 02/21/2013 04:06 PM, Stefano Lattarini wrote: In a couple of days, I will proceed with this branch moving: * branch-1.13.2 - maint * maint - master * master - next Done. Damn, not really. For some questionable reason, Savannah is rejecting my non-fast-forward push to master even if I specify '--force', and I cannot use the usual trick delete the remote branch, then push the local one to it trick that I typically use to work around this problem, since 'master' is the current branch of the remote repository, and that cannot be deleted to avoid confusing git clone. I was not aware that those moves would be non-fast-forwards, and I think this is bad bad bad. Note that the users can avoid branch-rewriting issues by renaming their 'master' to 'next' and their 'maint' to 'master' before pulling. This should probably be stated in a message (on list *and* on savannah news) advertising the new versioning and branching scheme (message not yet written; it will be once the current issue is sorted out). It's quite hostile to do non-fast-forwards on branches as central as master and maint. And I think git/savannah is rejecting them quite rightly! Savannah is rejecting all non-fast-forward pushes (which I find annoying); but it didn't prevent me from deleting and recreating maint, a change that will still appear as a non-fast-forward to any clone of our repository. The reason it doesn't allow me to delete master as well is that doing so would prevent a git clone from checking out the sources of a freshly cloned automake, which can be very confusing (and of course, git cannot be aware of the fact that I intend to re-create 'master' just after having deleted it). master and maint have never been published as rewindable, and it should be correct to base new work on them. They should be left alone, IMHO. Their content has been left alone in fact; it's their name that hasn't. You should have implemented this more gradually, such that next would have taken its role directly, but maint and master should have been allowed to grow into the correct branches once the relevant releases had been made. This would give a very confusing interim period IMHO. However, note that that we can still implement such a gentler transition (for 'master' only) if you really want to, by using a new branch name (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a temporary alias to 'next' until the 2.0 release (at which point all of 'maint', 'master' and 'next' will be fast-forwarded to the commit that implements the 2.0 release). I still prefer to pull this sore tooth out right now, though. Or even better, implement the change right after a major release so that master and maint would have been correctly positioned from the start. I have a few single-commit local branches that I will simply have to cherry-pick to the new world order. No, just rebase them on the new name of the branch they were based on; that is, if they were based on 'master', they are now to be considered based on 'next', if they were based on 'maint', they are now to be considered based on 'master', and if they were based on 'branch-1.13.2' they are not to be considered based on 'maint'. Or is there some better way to move these branches after their base has been pulled from under them? The good thing is that is has not been really pulled away, just *renamed*. Remember that Git branches are just movable tags basically, so as long as you have another handle referencing the same commit a branch points to (be that a tag or another branch), nothing is lost by removing the branch -- you are just removing a tag, not any real content. Hopefully there isn't some big chunk of unpublished work that will be killed by these disruptive changes... No, there is not. As said, no pre-existing commit has been dropped by my planned renames. HTH, Stefano
Re: [IMPORTANT] Savannah issues
On 02/23/2013 07:06 PM, Stefano Lattarini wrote: In a couple of days, I will proceed with this branch moving: * branch-1.13.2 - maint * maint - master * master - next Done. Damn, not really. For some questionable reason, Savannah is rejecting my non-fast-forward push to master even if I specify '--force', and I cannot use the usual trick delete the remote branch, then push the local one to it trick that I typically use to work around this problem, since 'master' is the current branch of the remote repository, and that cannot be deleted to avoid confusing git clone. So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN INCONSISTENT STATE* (not broken, mind you, merely inconsistent with our new declared policies), and should not be used until this issue is resolved. I don't have time to look into this presently, I had time today, so I submitted a Task in the Savannah interface: https://savannah.gnu.org/task/index.php?12497 Regards, Stefano
Re: [IMPORTANT] Savannah issues
On 02/25/2013 11:28 PM, Miles Bader wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: * maint - master * master - next Damn, not really. For some questionable reason, Savannah is rejecting my non-fast-forward push to master even if I specify '--force', and I cannot use the usual trick delete the remote branch, then push the local one to it trick that I typically use to work around this problem, since 'master' is the current branch of the remote repository, and that cannot be deleted to avoid confusing git clone. So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN INCONSISTENT STATE* (not broken, mind you, merely inconsistent with our new declared policies), and should not be used until this issue is resolved. I don't have time to look into this presently, I had time today, so I submitted a Task in the Savannah interface: https://savannah.gnu.org/task/index.php?12497 What's the point of this renaming, anyway? The fact that the master branch, being in many ways the default one in the Git world, is the one that is most visible and tested; so it should be the one where the future minor releases (that we now pledge to keep backward-compatible) are cut from. It doesn't seem to make any functional difference what the names of the branches you use for dev sources and releases are Functional differences, no, strictly speaking. Yet, when someone clones the Automake repository, he has the 'master' branch checked out automatically (apart for 'bare' clones, where no branch is checked out -- but that is a different usage scenario). And the automated Hydra builder checks the master branch: http://hydra.nixos.org/jobset/gnu/automake-master. And there surely are many other situations where the 'master' branch is handled in special ways, either technically or culturally. -- and besides being a practical problem, the scheme you've chosen doesn't follow common git practice, How so? If you are referring the practice of having 'next' as a test bed for the features to be eventually merged into 'master', note that is not an usual setup, but is only employed by the Git project itself for its own repository; and while I admit it is an intelligent approach that works quite well there, it only does so because of Git's large developer base and very dedicated and very capable maintainer -- things these that Automake lacks at present. so will be surprising/confusing to people... Maybe to Git's developers, but I don't see many lurking in here ;-) And anyway, even if that turns out to be the case, the solution would not be to change the new policy for 'master', but to change name to the 'next' branch. And I'm not particularly attached to that name; if anyone wants to suggest a better one, and manage to get a consensus on it, I'm quite ready to rename accordingly. Regards, Stefano
bug#13578: [IMPORTANT] *Implemented* a new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/21/2013 04:06 PM, Stefano Lattarini wrote: On 02/21/2013 03:32 PM, Stefano Lattarini wrote: Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as well as few miscellaneous comments in tests and scripts). Then we can finally proceed with the re-shuffling of the Git repository -- which I guess will also have to be announced in autotools-announce at least, as well as reported as a news on Savannah. So here is my attempt; OK to push to branch-1.13.2? I will proceed in a couple of days if there is no objection. Pushed now. In a couple of days, I will proceed with this branch moving: * branch-1.13.2 - maint * maint - master * master - next Done. I'm thus closing this bug report. Note that there are still some pending, tentative proposals about how to improve the names and release policy for beta versions; but since those proposals are more a follow-up to this discussion than an integral part of it, they are IMO more suited to be further discussed in new, dedicated threads. So, if anyone is still interested in pursuing those ideas, please open a new bug report (preferably complete with references to the relevant messages in this thread, and with a summary of the main ideas, motivations, and consensus -- or lack thereof -- reached so far). Thanks to all that have participated to this discussion, and offered their feedback, ideas and experiences. Best regards, Stefano
Re: bug#13524: [PATCH 0/2] Improving user experience for non-recursive builds
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
[IMPORTANT] *Implemented* a new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/21/2013 04:06 PM, Stefano Lattarini wrote: On 02/21/2013 03:32 PM, Stefano Lattarini wrote: Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as well as few miscellaneous comments in tests and scripts). Then we can finally proceed with the re-shuffling of the Git repository -- which I guess will also have to be announced in autotools-announce at least, as well as reported as a news on Savannah. So here is my attempt; OK to push to branch-1.13.2? I will proceed in a couple of days if there is no objection. Pushed now. In a couple of days, I will proceed with this branch moving: * branch-1.13.2 - maint * maint - master * master - next Done. I'm thus closing this bug report. Note that there are still some pending, tentative proposals about how to improve the names and release policy for beta versions; but since those proposals are more a follow-up to this discussion than an integral part of it, they are IMO more suited to be further discussed in new, dedicated threads. So, if anyone is still interested in pursuing those ideas, please open a new bug report (preferably complete with references to the relevant messages in this thread, and with a summary of the main ideas, motivations, and consensus -- or lack thereof -- reached so far). Thanks to all that have participated to this discussion, and offered their feedback, ideas and experiences. Best regards, Stefano
[IMPORTANT] Savannah issues
On 02/23/2013 06:46 PM, Stefano Lattarini wrote: On 02/21/2013 04:06 PM, Stefano Lattarini wrote: On 02/21/2013 03:32 PM, Stefano Lattarini wrote: Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as well as few miscellaneous comments in tests and scripts). Then we can finally proceed with the re-shuffling of the Git repository -- which I guess will also have to be announced in autotools-announce at least, as well as reported as a news on Savannah. So here is my attempt; OK to push to branch-1.13.2? I will proceed in a couple of days if there is no objection. Pushed now. In a couple of days, I will proceed with this branch moving: * branch-1.13.2 - maint * maint - master * master - next Done. Damn, not really. For some questionable reason, Savannah is rejecting my non-fast-forward push to master even if I specify '--force', and I cannot use the usual trick delete the remote branch, then push the local one to it trick that I typically use to work around this problem, since 'master' is the current branch of the remote repository, and that cannot be deleted to avoid confusing git clone. For reference, this is the error message I got when I try to delete master: remote: error: By default, deleting the current branch is denied, because the next remote: error: 'git clone' won't result in any file checked out, causing confusion. remote: error: remote: error: You can set 'receive.denyDeleteCurrent' configuration variable to remote: error: 'warn' or 'ignore' in the remote repository to allow deleting the remote: error: current branch, with or without a warning message. remote: error: remote: error: To squelch this message, you can set it to 'refuse'. remote: error: refusing to delete the current branch: refs/heads/master So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN INCONSISTENT STATE* (not broken, mind you, merely inconsistent with our new declared policies), and should not be used until this issue is resolved. I don't have time to look into this presently, so I'd appreciate if anyone could look into the issue (finding a way not have savannah to reject non-fast-forward pushes would be enough). Thanks, and sorry for the confusion, Stefano
Re: Autogen.sh error
On 02/22/2013 07:11 PM, Olmide wrote: I've solved the problem. It was not with autotools but with Microsoft's find appearing in the PATH before the Cygwin find. I suspected something of that kind. Thanks for letting us know, Stefano
[Automake-NG] [FYI] Merge branch 'master' into ng/master
commit 10a1f8b1d17cf1602819fb93a758f3102e737d6e Merge: 87b62c3 a5ed87e Author: Stefano Lattarini stefano.lattar...@gmail.com Date: Thu Feb 21 18:12:27 2013 +0100 Merge branch 'master' into ng/master * master: maint: more adjustments to the new versioning scheme aclocal: fix for more-than-once specified directories aclocal: just warn if the primary local m4 dir doesn't exist (don't error) coverage: expose automake bug#13760 tests: refactor/enhance tests about make dry-run mode maint: describe new versioning and branching scheme, and adjust to it cosmetics: fix some docstring-like comments in automake + t/make-dryrun.tap: Several adjustments, since this test had diverged quite significantly from the version in mainline Automake. Particularly relevant is the fact that Automake-NG seems immune to bug#13760, so that some tests that are returning XFAIL in mainline automake succeeds for Automake-NG. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Re: [PATCH] {maint} cosmetics: fix some docstring-like comments in automake
On 02/17/2013 12:09 AM, Stefano Lattarini wrote: * automake.in: Here. And remove some redundant ones. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- I intend to push this in a couple of days (to maint) if there is no objection. Regards, Stefano automake.in | 107 1 file changed, 20 insertions(+), 87 deletions(-) Pushed. Regards, Stefano
Re: bug#13514: [PATCH v3 1/2] aclocal: just warn if the primary local m4 dir doesn't exist (don't error)
tags 13514 + patch close 13514 stop On 02/20/2013 10:11 PM, Stefano Lattarini wrote: On 02/18/2013 09:53 AM, Pavel Raiskup wrote: Hi Stefano, thanks for refinements! I'm ok with these patches. Good! I will push them tomorrow if I hear no objection by then. Pushed now. I'm thus closing this bug report. Thanks, Stefano
[FYI] Merge branch 'maint' into master
commit a5ed87e7944deaea33914230e3d67ff08eb18382 Merge: 5e074aa b4dbcb7 Author: Stefano Lattarini stefano.lattar...@gmail.com Date: Thu Feb 21 16:39:22 2013 +0100 Merge branch 'maint' into master * maint: maint: more adjustments to the new versioning scheme aclocal: fix for more-than-once specified directories aclocal: just warn if the primary local m4 dir doesn't exist (don't error) coverage: expose automake bug#13760 tests: refactor/enhance tests about make dry-run mode maint: describe new versioning and branching scheme, and adjust to it cosmetics: fix some docstring-like comments in automake Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Re: Configure should failed in case format ustar and big UID are used
On 02/20/2013 02:40 PM, Petr Hracek wrote: Hi, Hi Petr, sorry for the delay. after reading of ustar format (http://www.gnu.org/software/tar/manual/html_section/Formats.html) I have made patch for m4/tar.m4 file against upstream: In case that ustar format is used and uid or gid is bigger than 2^21 than configure will always failed Yes, you have already reported that (offering a fix): http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13588 As I said, I will integrate it before the next beta for 1.13.2, and will get back to you for ACK and testing. I can't promise I will do so quickly, but I will definitely do it. Please be patient (and again, sorry for the delay). Now, some miscellaneous nits about your patch, which you might want to take into account in case you need to send other patches in the future (which will make the review and integration of your patches faster and more efficient): Patch is: diff --git a/m4/tar.m4 b/m4/tar.m4 index ec8c83e..1eca282 100644 --- a/m4/tar.m4 +++ b/m4/tar.m4 We actually prefer patches formatted with git-format, that are easier to apply with git-provided tools. Also, when preparing a commit, you should write a proper commit message explaining what changes it introduces, and for what reasons; this should be complemented by a ChangeLog entry in the GNU style. See the file HACKING (section Writing a good commit message) in the top-level directory of the Automake source tree for more information. @@ -81,6 +81,27 @@ do AM_RUN_LOG([tardir=conftest.dir eval $am__tar_ conftest.tar]) rm -rf conftest.dir if test -s conftest.tar; then +AC_CHECK_PROG([ID_TEST], id, [yes], [no]) No need to check this (see below). Also, using 'ID_TEST' as a variable, you are invading the user's name space; since this is a variable for internal use, a name like '_am_have_id' would have been more appropriate. +if test x$ID_TEST = xyes; then This conditional should be dropped as well (see below), + if test x$1 = xustar ; then This should be an m4-time conditional, not a shell-time one, to avoid emitting useless code in the generated configure script. + user_id=`id -u` + if test $? -eq 0; then This is better: if user_id=`id -u 2/dev/null` test $user_id -ge 0; then ... Also, we should avoid invading the user's namespace -- what if he's using a variable named 'user_uid' in other parts of his configure script? A variable name like '_am_uid' would be more appropriate. + # Maximum allowed UID in case ustar format is 2097151 + if test $user_id -ge 2097152; then + AC_MSG_ERROR([The uid is big and not allowed in case of ustar format. Change format in configure.ac],[2]) This change would prevent an user with a high ID to install a package that he can in all likelihood build and run without problems, only because he *might* see some failures if he tried to run make dist -- a target this reserved for developers and maintainers anyway! This is unacceptable. The right thing to do if we find out that the user ID is too large is simply to skip the later test on pax that might cause configure to hand. If configure is not able to find any appropriate packaging tool, the user won't be able to build a distribution tarball from his system -- no big deal. OTOH, having configure to hang during a test is a serious problem, and we need to prevent that from happening. Also, as a further aside, notice that a basic tenet of the autotools philosophy is that the the final users should not be required to have *any* of the autotools installed in ordter to configure, build or install a distributed package created with the autotools; suggesting the user to edit configure.ac and to re-run the autotools to fix a configure-time problem is in general unacceptable. + exit 1 + fi + fi + group_id=`id -g` + if test $? -eq 0; then + # Maximum allowed GID in case ustar format is 2097151 + if test $group_id -ge 2097152; then + AC_MSG_ERROR([The gid is big and not allowed in case of ustar format. Change format in configure.ac],[2]) + exit 1 + fi + fi The same issues pointed out above apply to this hunk as well. + fi +fi AM_RUN_LOG([$am__untar conftest.tar]) grep GrepMe conftest.dir/file /dev/null 21 break fi Please review it and let me now whether something is wrong. If something will be wrong I will make a correction. Tests where performed as on big uid as on big gid and both. I have been looking for making test in that case, but found that useradd binary should be called and I think that we do not what to do that. I agree a test case for this would be too demanding. I will ask you to test my patch in your production environment before applying it, to ensure it actually fix the issue under discussion. Thanks, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/17/2013 03:57 PM, Stefano Lattarini wrote: On 02/13/2013 07:39 PM, Stefano Lattarini wrote: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578 OK, so far I've seen only positive feedback about this proposal. There are still some unresolved issues about how to handle beta releases; but the related proposals can be seen as a refinement of my scheme, not as something incompatible or in competition with it. So I see no reason to hold back the implementation of my proposal on their account: we can implement those refinements later, once some consensus is reached and the details are worked out. So, if I see no further objections, I'm going ahead with my proposal in a few days. Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as well as few miscellaneous comments in tests and scripts). Then we can finally proceed with the re-shuffling of the Git repository -- which I guess will also have to be announced in autotools-announce at least, as well as reported as a news on Savannah. So here is my attempt; OK to push to branch-1.13.2? I will proceed in a couple of days if there is no objection. Pushed now. Regards, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/21/2013 03:32 PM, Stefano Lattarini wrote: Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as well as few miscellaneous comments in tests and scripts). Then we can finally proceed with the re-shuffling of the Git repository -- which I guess will also have to be announced in autotools-announce at least, as well as reported as a news on Savannah. So here is my attempt; OK to push to branch-1.13.2? I will proceed in a couple of days if there is no objection. Pushed now. And here is the follow-up to fix some left-over references to the older versioning scheme in 'maint' (they were not present in 'branch-1.13.2'). Already pushed to 'maint'. In a couple of days, I will proceed with this branch moving: * branch-1.13.2 - maint * maint - master * master - next Regards, Stefano 8 8 8 8 8 8 8 8 8 From d5f83b89cc4d2da9078669018877b3bac5c2fadc Mon Sep 17 00:00:00 2001 Message-Id: d5f83b89cc4d2da9078669018877b3bac5c2fadc.1361458350.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Thu, 21 Feb 2013 15:52:22 +0100 Subject: [PATCH] maint: more adjustments to the new versioning scheme This is a follow-up to commit 'v1.13.1b-11-g97aaf12'. * automake.in: Adjust a comment. * PLANS: Adjust several files in here. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- PLANS/obsolete-removed/am-prog-mkdir-p.txt | 8 +++- PLANS/obsolete-removed/configure.in.txt| 10 +- PLANS/rm-f-without-args.txt| 10 +- PLANS/subdir-objects.txt | 10 +- PLANS/texi/drop-split-info-files.txt | 6 +++--- automake.in| 2 +- 6 files changed, 22 insertions(+), 24 deletions(-) diff --git a/PLANS/obsolete-removed/am-prog-mkdir-p.txt b/PLANS/obsolete-removed/am-prog-mkdir-p.txt index d5b7695..20d5cf5 100644 --- a/PLANS/obsolete-removed/am-prog-mkdir-p.txt +++ b/PLANS/obsolete-removed/am-prog-mkdir-p.txt @@ -1,6 +1,4 @@ -The macro AM_PROG_MKDIR_P is no longer going to be removed in Automake 1.14 -(and in fact, any plan to remove it evenatually has been dropped as well). - +The macro AM_PROG_MKDIR_P is no longer going to be removed from Automake. Let's see a bit of history to understand why. I had already scheduled the removal of the long-deprecated AM_PROG_MKDR_P @@ -46,14 +44,14 @@ out, and we lose. That already happened in practice: http://lists.gnu.org/archive/html/bug-grep/2013-01/msg3.html Moreover, while I might see it as not unreasonable to ask a developer -using Automake 1.14 to also update Gettext to 1.18.2, that would not +using Automake 2.0 to also update Gettext to 1.18.2, that would not be enough; in order for gettext to use the correct data files, that developer would have to update his configure.ac to read: AM_GNU_GETTEXT_VERSION([0.18.2]) thus requiring *all* of his co-developers to install Gettext 1.18.2, -even if they are still using, say, Automake 1.13. Bad. +even if they are still using, say, Automake 1.13 or 1.14. Bad. So I decided to re-instate this macro as a simple alias for AC_PROG_MKDIR_P (plus a non-fatal runtime warning in the 'obsolete' category), and drop diff --git a/PLANS/obsolete-removed/configure.in.txt b/PLANS/obsolete-removed/configure.in.txt index baed853..180f92c 100644 --- a/PLANS/obsolete-removed/configure.in.txt +++ b/PLANS/obsolete-removed/configure.in.txt @@ -13,16 +13,16 @@ present in the development version of autoconf so far (scheduled to become Autoconf 2.70). So ... -For Automake 1.14 -- +For Automake 2.0 + ... we have decided to wait until 2.70 is out before really removing 'configure.in' support. Since we plan to require Autoconf 2.70 in -Automake 1.14 (so that we can remove the hacky code emulating +Automake 2.0 (so that we can remove the hacky code emulating AC_CONFIG_MACRO_DIRS for older autoconf versions), we are quite sure that Autoconf will actually have started deprecating 'configure.in' -by the time Automake 1.14 is released. +by the time Automake 2.0 is released. Note that the removal of 'configure.in' has already been implemented -in our master branch (from where the 1.14 release will be finally +in our 'next' branch (from where the 2.0 release will be finally cut); see commits 'v1.13-17-gbff57c8' and 'v1.13-21-g7626e63'. diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt index 5362f98..918e049 100644 --- a/PLANS/rm-f-without-args.txt +++ b/PLANS/rm-f-without-args.txt @@ -21,20 +21,20 @@ the no-args rm -f usage is supported on the system configure is being run on; complain loudly if this is not the case, and tell the user to report the situation to us. -For Automake 1.14 -- +For Automake 2.0 + Make any failure in the configure-time probe check introduced by the previous point fatal; and in case
bug#13514: [PATCH v3 1/2] aclocal: just warn if the primary local m4 dir doesn't exist (don't error)
tags 13514 + patch close 13514 stop On 02/20/2013 10:11 PM, Stefano Lattarini wrote: On 02/18/2013 09:53 AM, Pavel Raiskup wrote: Hi Stefano, thanks for refinements! I'm ok with these patches. Good! I will push them tomorrow if I hear no objection by then. Pushed now. I'm thus closing this bug report. Thanks, Stefano
bug#13760: [PATCH 1/2] tests: refactor/enhance tests about make dry-run mode
* t/make-dryrun.tap: Here.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
t/make-dryrun.tap | 99 ++-
1 file changed, 47 insertions(+), 52 deletions(-)
diff --git a/t/make-dryrun.tap b/t/make-dryrun.tap
index 14d379a..4aa7146 100755
--- a/t/make-dryrun.tap
+++ b/t/make-dryrun.tap
@@ -20,14 +20,12 @@
plan_ 14
-if echo all: ; @+printf %sbb%s aa cc | $MAKE -n -f - | grep aabbcc; then
+if echo all: ; +@printf %sbb%s aa cc | $MAKE -n -f - | grep aabbcc; then
make_plus_silence () { return 0; }
else
make_plus_silence () { return 1; }
fi
-mkdir sub
-
echo AC_OUTPUT configure.ac
cat Makefile.am 'END'
@@ -35,14 +33,48 @@ all:
: Dummy, nothing to do.
foo:
$(MAKE) all
-notdry:
+run:
@echo :: $$MAKEFLAGS ::; : For debugging.
- $(am__make_dryrun) exit 1; exit 0
+ $(am__make_dryrun) exit 1; echo ok from-run
dry:
+@echo :: $$MAKEFLAGS ::; : For debugging.
- +$(am__make_dryrun) || exit 1; echo ok from-dry-mode
+ +$(am__make_dryrun) || exit 1; echo ok from-dry
END
+check_make ()
+{
+ r=ok msg= mode= condition=: directive= reason= skip_reason=
+ case $1 in
+--dry) mode=dry;;
+--run) mode=run;;
+*) fatal_ check_run: invalid usage;;
+ esac
+ shift
+ while test $# -gt 0; do
+case $1 in
+ -C) condition=$2 skip_reason=$3; shift; shift;;
+ -M) msg=$2; shift;;
+ -X) directive=TODO;;
+ --) shift; break;;
+ *) break;;
+esac
+shift
+ done
+ msg=${mode}${msg:+ [$msg]}
+ if $condition; then
+$MAKE $mode ${1+$@} || r='not ok'
+test -f from-$mode || r='not ok'
+test ! -e bad || r='not ok'
+rm -f bad from-*|| fatal_ cleaning up
+ else
+directive=SKIP reason=$skip_reason
+ fi
+ result_ $r -D $directive -r $reason $msg
+ unset r msg mode condition directive reason skip_reason
+}
+
+# --
+
$ACLOCAL|| fatal_ aclocal failed
$AUTOCONF || fatal_ autoconf failed
$AUTOMAKE || fatal_ automake failed
@@ -50,48 +82,21 @@ $AUTOMAKE || fatal_ automake failed
# --
-check_no_dryrun ()
-{
- command_ok_ dry-run ($cnt) $MAKE notdry ${1+$@}
- cnt=$(($cnt + 1))
-}
-cnt=1
-
-check_no_dryrun
+check_make --run
# Test against a known regression. This was especially heinous, since
# make running in normal mode was sometimes mistaken for make running
# in dry mode.
-check_no_dryrun TESTS=n1.test n2.test
-check_no_dryrun TESTS=n1 n2 AM_MAKEFLAGS=TESTS='n1 n2'
-check_no_dryrun TESTS=n1 n2 AM_MAKEFLAGS='TESTS=n1 n2'
-check_no_dryrun FOOFLAGS=-n -n -knf2 n --none -n
-check_no_dryrun MYFLAGS=-n --dryrun -n --dry-run -n
+check_make --run TESTS=n1.test n2.test
+check_make --run TESTS=n1 n2 AM_MAKEFLAGS=TESTS='n1 n2'
+check_make --run TESTS=n1 n2 AM_MAKEFLAGS='TESTS=n1 n2'
+check_make --run FOOFLAGS=-n -n -knf2 n --none -n
+check_make --run MYFLAGS=-n --dryrun -n --dry-run -n
# --
-check_dryrun ()
-{
- r=ok directive=
- case $1 in
--C) condition=$2 reason=$3; shift; shift; shift;;
- *) condition=: reason=;;
- esac
- if $condition; then
-$MAKE dry ${1+$@} || r='not ok'
-test -f from-dry-mode || r='not ok'
-rm -f from-dry-mode || fatal_ cleaning up
- else
-directive=SKIP
- fi
- result_ $r -D $directive -r $reason not dry-run ($cnt)
- unset r directive reason
- cnt=$(($cnt + 1))
-}
-cnt=1
-
-check_dryrun -C make_plus_silence 'recipe prefix + unsupported' -n
-check_dryrun -C using_gmake \$MAKE is not GNU make --dry-run -k
+check_make --dry -C make_plus_silence 'recipe prefix + unsupported' -n
+check_make --dry -C using_gmake \$MAKE is not GNU make --dry-run -k
# --
@@ -99,18 +104,8 @@ check_dryrun -C using_gmake \$MAKE is not GNU make
--dry-run -k
check_metachars ()
{
- r=ok
- $MAKE notdry ${1+$@} || r='not ok'
- if test -f bad; then
-r='not ok'
- else
-rm -f bad || fatal_ cleaning up
- fi
- result_ $r dry-run, with shell metachars ($cnt)
- unset r
- cnt=$(($cnt + 1))
+ check_make --run -M metachars $@
}
-cnt=1
check_metachars MYFLAGS=-n \n\ '-n' --none -n
check_metachars MYFLAGS='-knf2\ n\ \\n'
--
1.8.1.1.754.gb3600c3
bug#13514: [PATCH v3 1/2] aclocal: just warn if the primary local m4 dir doesn't exist (don't error)
On 02/18/2013 09:53 AM, Pavel Raiskup wrote:
Hi Stefano, thanks for refinements! I'm ok with these patches.
Good! I will push them tomorrow if I hear no objection by then.
[..]
See also:
http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html
http://lists.gnu.org/archive/html/automake-patches/2010-02/msg00030.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565663
https://bugzilla.redhat.com/show_bug.cgi?id=901333
* aclocal.in (SCAN_M4_DIRS_SILENT, SCAN_M4_DIRS_WARN,
SCAN_M4_DIRS_ERROR): New constants.
This is a nit but the first line should be closed by ')' and second line
opened with '('.
Actually, both forms are acceptable according to the GNU Coding Standards,
and I marginally prefer the form I've used. CORRECTION: No, not really:
it used to be that way, but I've checked and the form you've suggested
is the only one recommended now. Sigh. Will fix; thanks for catching
this!
[..]
diff --git a/THANKS b/THANKS
index 66498d4..5c014bf 100644
--- a/THANKS
+++ b/THANKS
@@ -297,6 +297,7 @@ Paul Jarc p...@po.cwru.edu
Paul Lunau t...@lunau.me.uk
Paul Martinolichmarti...@datasync.com
Paul Thomas ptho...@novell.com
+Pavel Raiskup prais...@redhat.com
Thanks :).
+$ACLOCAL -Wno-error 2stderr \
+ cat stderr 2 \
+ test $(grep -c couldn't open directory 'not-exist' stderr) -eq 1 \
Nice check!
Pavel
Thanks again for your work on this,
Stefano
[PATCH 0/2] am__make_dryrun fails to handle GNU make -I option
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13760 On 02/19/2013 11:34 AM, Boris Kolpackov wrote: Hi, Hi Boris, thanks for the clear and detailed report. After upgrading from 1.11.1 to 1.11.6 or 1.12.6, or 1.13.1 my project's dist target stopped working. After some debugging, the culprit turned out to be am__make_dryrun function that mis-detects make dry-run mode (make -n) if make flags contain a -I option with a path containing character 'n'. For the moment, I have exposed the bug you have reported in the testsuite (see the two upcoming patches). This issue shouldn't be too difficult too fix; I hope I'll be able to cook something in the next days, in time for the next beta for 1.13.2. So, based on this knowledge, for GNU make, all we need to do is examine the first word in MAKEFLAGS. If it contains '=', then it is a variable assignment, otherwise, we search for the 'n' character. This might be OK for GNU make: $ gmake -ki -I none -k -f- 'all:;@echo $$MAKEFLAGS' kI none -i but not, e.g., for the FreeBSD and NetBSD make: $ bsd-make -ki -I none -k -f- 'all:;@echo $$MAKEFLAGS' -k -i -I none -k nor for Solaris CCS make (note that this doesn't even support thr -I option, though): $ /usr/ccs/bin/make -ki -k -f - 'all:;@echo $$MAKEFLAGS' -ik The complication is that we have to also support other makes (BSD, Solaris). I have no idea about their MAKEFLAGS behavior. I have only a patchy knowledge too, but combining that with some experimenting might be enough to find a fix Boris Thanks, Stefano -*-*-*- Stefano Lattarini (2): tests: refactor/enhance tests about make dry-run mode coverage: expose automake bug#13760 t/make-dryrun.tap | 123 -- 1 file changed, 72 insertions(+), 51 deletions(-) -- 1.8.1.1.754.gb3600c3
[PATCH 2/2] coverage: expose automake bug#13760
* t/make-dryrun.tap: Here.
* THANKS: Update with the name of the bug reporter.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
t/make-dryrun.tap | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/t/make-dryrun.tap b/t/make-dryrun.tap
index 4aa7146..1459a9f 100755
--- a/t/make-dryrun.tap
+++ b/t/make-dryrun.tap
@@ -18,7 +18,7 @@
. test-init.sh
-plan_ 14
+plan_ 18
if echo all: ; +@printf %sbb%s aa cc | $MAKE -n -f - | grep aabbcc; then
make_plus_silence () { return 0; }
@@ -26,6 +26,13 @@ else
make_plus_silence () { return 1; }
fi
+mkdir none
+if echo nil: | $MAKE -I none -f -; then
+ make_supports_option_I () { return 0; }
+else
+ make_supports_option_I () { return 1; }
+fi
+
echo AC_OUTPUT configure.ac
cat Makefile.am 'END'
@@ -100,6 +107,25 @@ check_make --dry -C using_gmake \$MAKE is not GNU make
--dry-run -k
# --
+# Automake bug#13760: the n in none used to confound am__make_dryrun
+# into thinking the '-n' option had been passed.
+
+pr='bug#13760'
+
+check_make --run -X -C make_supports_option_I -I make option unsupported \
+ -M $pr -I none
+
+check_make --run -X -C using_gmake \$MAKE is not GNU make \
+ -M $pr -I none --include dry-run
+
+check_make --dry -C make_supports_option_I -I make option unsupported \
+ -M $pr -I none -n
+
+check_make --dry -C using_gmake \$MAKE is not GNU make \
+ -M $pr --dry-run -I none --include dry-run
+
+# --
+
# Test for when shell metacharacters or backslashes are in $(MAKEFLAGS).
check_metachars ()
--
1.8.1.1.754.gb3600c3
Re: [PATCH 0/2] am__make_dryrun fails to handle GNU make -I option
On 02/20/2013 02:07 PM, Stefano Lattarini wrote: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13760 [SNIP] I have only a patchy knowledge too, but combining that with some experimenting might be enough to find a fix ESENTTOOEARLY, sorry. Here is the complete paragraph I intended to send: I too have only a patchy knowledge of them, but combining that with some experimenting might be enough to find a fix for this bug. And of course, if you want to attempt a fix yourself in the meantime, be my guest ;-) Sorry for the noise, Stefano
Re: bug#13514: [PATCH v3 1/2] aclocal: just warn if the primary local m4 dir doesn't exist (don't error)
On 02/18/2013 09:53 AM, Pavel Raiskup wrote:
Hi Stefano, thanks for refinements! I'm ok with these patches.
Good! I will push them tomorrow if I hear no objection by then.
[..]
See also:
http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html
http://lists.gnu.org/archive/html/automake-patches/2010-02/msg00030.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565663
https://bugzilla.redhat.com/show_bug.cgi?id=901333
* aclocal.in (SCAN_M4_DIRS_SILENT, SCAN_M4_DIRS_WARN,
SCAN_M4_DIRS_ERROR): New constants.
This is a nit but the first line should be closed by ')' and second line
opened with '('.
Actually, both forms are acceptable according to the GNU Coding Standards,
and I marginally prefer the form I've used. CORRECTION: No, not really:
it used to be that way, but I've checked and the form you've suggested
is the only one recommended now. Sigh. Will fix; thanks for catching
this!
[..]
diff --git a/THANKS b/THANKS
index 66498d4..5c014bf 100644
--- a/THANKS
+++ b/THANKS
@@ -297,6 +297,7 @@ Paul Jarc p...@po.cwru.edu
Paul Lunau t...@lunau.me.uk
Paul Martinolichmarti...@datasync.com
Paul Thomas ptho...@novell.com
+Pavel Raiskup prais...@redhat.com
Thanks :).
+$ACLOCAL -Wno-error 2stderr \
+ cat stderr 2 \
+ test $(grep -c couldn't open directory 'not-exist' stderr) -eq 1 \
Nice check!
Pavel
Thanks again for your work on this,
Stefano
bug#13748: Numerous failures/errors
tags 13748 + notabug close 13748 stop On 02/18/2013 08:19 AM, Andrew Brager wrote: Numerous failures/errors. I don't know if this is normal. See below. [SNIP] PACKAGE='iksemel' This package has nothing to do with Automake. You'll have to report the failure to the developers if the 'iksmel' package. Regards, Stefano
Re: Parallel tests
On 02/19/2013 02:39 PM, Simon Richter wrote: Hi, I have a library that, among other things, has a number of functions related to event handling with timeouts. In order to get reliable results, I have to use long timeouts, which add up in the total test time. Is there a way to have tests run in parallel? http://www.gnu.org/software/automake/manual/automake.html#Parallel-Test-Harness HTH, Stefano
bug#13761: FAIL: t/objc-megademo.sh (OS X 10.6)
severity 13761 minor tags 13761 moreinfo stop Hi Daniel, thanks for the report. On 02/19/2013 03:39 PM, Daniel Macks wrote: Building automake on OS X 10.6 with autoconf-2.69 installed, I get a self-test failure: FAIL: t/objc-megademo.sh It passes on 10.7. This is good news; it suggests that the failure was due to a bug of Mac OS X rather than of automake; in fact, the test has been regularly succeeding on Fedora, Debian and Solaris. So I'm marking the bug with minor severity, until the issue gets sorted out. I don't know much about objc, Neither do I (nor about Mac OS X, for that matter). but can try any ideas to debug or solve that someone has. Let's see if someone steps up; in the meantime, I'm also marking the bug are more info needed (from Objective C experts, in this case). Thanks, Stefano
bug#13588: Pax hangs in case big UID
tags 13588 + patch tags 8343 + patch merge 13588 8343 thanks Merging with bug#8343, since it's the same issue Regards, Stefano
Re: on naming test files for parallel test harness and not removing extensions
On 02/07/2013 11:01 AM, Marco Maggi wrote: Ciao, Ciao Marco, sorry for the delay. this is somewhat a silly request... :-) I am a new user of the parallel test harness; I have a project with a set of tests that I want to run under different implementations of the same language; I put all the tests in a library and then load the library from test programs, one program for each language implementation[1]. Due to the way Automake names the .log and .trs files (by removing the selected file extensions from program files), for the language implementations Guile and Vicare I have to name the test programs: test-sofa-guile.guile test-sofa-vicare.vicare rather than just: test-sofa.guile test-sofa.vicare else I get .log and .trs file names conflict; this is a bit ugly. Unless I missed it, there is no way to overcome this uglyness with Automake up to version 1.13. A possible workaround would be to place the guile and vicare tests in two separate subdirectories, so that there is no conflict for the .log files: vicare-tests/test-sofa.vicare guile-tests/test-sofa.guile The parallel tests harness will generate the following log files from the tests above: vicare-tests/test-sofa.log guile-tests/test-sofa.log so no conflict. And note that you don't need to recurse in the two subdirectories to obtain that effect; you can just have: TESTS = \ vicare-tests/test-sofa.vicare \ guile-tests/test-sofa.guile in you top-level Makefile (in fact, I'd advise against extra make recursion whenever possible). Of course, this makes sense only if you have several tests for each of guile and vicare; if you only have a couple of test each, this approach would just bring to a pointless proliferation of basically dummy directories ... Other users may be in the same situation (for example Pythonistas also have to deal with multiple language implementations). So I wonder if it is possible to introduce an option that disables building the names of .log and .trs files by first stripping the selected extensions; so program files like: test-sofa.guile test-sofa.vicare would generate: test-sofa.guile.log test-sofa.guile.trs test-sofa.vicare.log test-sofa.vicare.trs with no conflict. You can already do this by writing a custom test runner that take a script and runs it with the correct interpreter (guile or vicare, in your case), depending on its extensions; then you can have this in your Makefile.am: TEST_EXTENSIONS = # empty LOG_COMPILER = my-test-runner TESTS = test-sofa.guile test-sofa.vicare and the generated .log and .trs files should keep the extension of the original test file. The downside of this is that tit will require you to write more non-trivial code. All in all, I'm not truly convinced your use case is general/relevant enough to warrant a new automake option; my opinion is that: - if you have only few tests per interpreter, the workaround you are currently using (of having the interpreter name also as part of the test basename) is not too cumbersome, and works pretty well; - if you have several tests per interpreter, you can go with my proposed workaround of one subdirectory per interpreter. TIA [1] From line 224 onwards: http://github.com/marcomaggi/r6rs-sofa/blob/master/tests/Makefile.am HTH, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/13/2013 07:39 PM, Stefano Lattarini wrote: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578 OK, so far I've seen only positive feedback about this proposal. There are still some unresolved issues about how to handle beta releases; but the related proposals can be seen as a refinement of my scheme, not as something incompatible or in competition with it. So I see no reason to hold back the implementation of my proposal on their account: we can implement those refinements later, once some consensus is reached and the details are worked out. So, if I see no further objections, I'm going ahead with my proposal in a few days. Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as well as few miscellaneous comments in tests and scripts). Then we can finally proceed with the re-shuffling of the Git repository -- which I guess will also have to be announced in autotools-announce at least, as well as reported as a news on Savannah. So here is my attempt; OK to push to branch-1.13.2? I will proceed in a couple of days if there is no objection. Thanks, Stefano 8 8 8 8 8 8 8 8 From 97aaf121e92767dc06385d020dd30cdfaa86126f Mon Sep 17 00:00:00 2001 Message-Id: 97aaf121e92767dc06385d020dd30cdfaa86126f.136789.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Sun, 17 Feb 2013 10:25:29 +0100 Subject: [PATCH] describe new versioning and branching scheme, and adjust to it See discussion about automake bug#13578 for more details and background. Basically, for the versioning scheme: - micro versions only for bug and regression fixing; - minor versions for new backward-compatible features, and new non-fatal deprecations; - major versions for backward-incompatibilities, complex new features, and major refactoring. And for the git branching scheme: + branch 'next' is for the upcoming major version; + branch 'master' is now for the upcoming minor version; + branch 'maint' is for the upcoming micro (bug-fixing) version; + the merging hierarchy is: 'maint' - 'master' - 'next'. * HACKING (Automake versioning and compatibility scheme): New. (Working with git): Adjust. * NEWS: Update and fix. * aclocal.in: Adjust some FIXME messages. * automake.in: Likewise. * m4/mkdirp.m4: Likewise. * t/aclocal-acdir.sh: Likewise. * t/aclocal-macrodir.tap: Likewise. * t/aclocal-macrodirs.tap: Likewise. * lib/Automake/Options.pm: Likewise. * m4/internal/ac-config-macro-dirs.m4: Likewise. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- HACKING | 100 +--- NEWS| 59 + aclocal.in | 8 +-- automake.in | 12 +++-- lib/Automake/Options.pm | 4 +- m4/internal/ac-config-macro-dirs.m4 | 2 +- m4/mkdirp.m4| 3 +- t/aclocal-acdir.sh | 2 +- t/aclocal-macrodir.tap | 2 +- t/aclocal-macrodirs.tap | 2 +- 10 files changed, 150 insertions(+), 44 deletions(-) diff --git a/HACKING b/HACKING index c70143e..604bf67 100644 --- a/HACKING +++ b/HACKING @@ -93,6 +93,48 @@ code without. += Automake versioning and compatibility scheme + +* There are three kinds of automake releases: + +- new major releases (e.g., 2.0, 5.0) +- new minor releases (e.g., 1.14, 2.1) +- micro a.k.a. bug-fixing releases (e.g., 1.13.2, 2.0.1, 3.5.17). + + A new major release should have the major version number bumped, and + the minor and micro version numbers reset to zero. A new minor release + should have the major version number unchanged, the minor version number + bumped, and the micro version number reset to zero. Finally, a new + micro version should have the major and minor version numbers unchanged, + and the micro version number bumped. + + For example, the first minor version after 1.13.2 will be 1.14; the + first bug-fixing version after 1.14 that will be 1.14.1; the first + new major version after all such releases will be 2.0; the first + bug-fixing version after 2.0 will be 2.0.1; and a further bug-fixing + version after 2.0.1 will be 2.0.2. + +* Micro releases should be just bug-fixing releases; no new features + should be added, and ideally, only trivial bugs, recent regressions, + or documentation issues should be addressed by them. + +* Minor releases can introduce new safe features, do non-trivial + but mostly safe code clean-ups, and even add new runtime warnings + (rigorously non-fatal); but they shouldn't include any backward + incompatible change, nor contain any potentially destabilizing + refactoring or sweeping change, nor introduce new features whose + implementation might be liable to cause bugs
bug#13514: [PATCH v3 2/2] aclocal: fix for more-than-once specified directories
From: Pavel Raiskup prais...@redhat.com
Related to automake bug#13514.
Do not explore directories for extra m4 files multiple times in 'aclocal'.
Doing so caused problems on older packages that specify
configure.ac: AC_CONFIG_MACRO_DIRS([m4])
Makefile.am: ACLOCAL_AMFLAGS = -I m4
when the 'm4' directory does not exist when aclocal is called the first
time by autoreconf.
See:
http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html
* aclocal.in (scan_m4_files): Remove duplicates in @user_includes.
* t/aclocal-macrodir.tap: Extend.
* t/aclocal-macrodirs.tap: Likewise.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
aclocal.in | 10 ++
t/aclocal-macrodir.tap | 22 +-
t/aclocal-macrodirs.tap | 22 +-
3 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/aclocal.in b/aclocal.in
index e65b0ab..d68ea33 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -432,6 +432,16 @@ sub scan_m4_files ()
if (@user_includes)
{
+ # Don't explore the same directory multiple times. This is here not
+ # only for speedup purposes. We need this when the user has e.g.
+ # specified 'ACLOCAL_AMFLAGS = -I m4' and has also set
+ # AC_CONFIG_MACRO_DIR[S]([m4]) in configure.ac. This makes the 'm4'
+ # directory to occur twice here and fail on the second call to
+ # scan_m4_dirs([m4]) when the 'm4' directory doesn't exist.
+ # TODO: Shouldn't there be rather a check in scan_m4_dirs for
+ # @user_includes[0]?
+ @user_includes = uniq @user_includes;
+
# Don't complain if the first user directory doesn't exist, in case
# we need to create it later (can happen if '--install' was given).
scan_m4_dirs (FT_USER,
diff --git a/t/aclocal-macrodir.tap b/t/aclocal-macrodir.tap
index a480c4c..051fdb5 100755
--- a/t/aclocal-macrodir.tap
+++ b/t/aclocal-macrodir.tap
@@ -20,7 +20,7 @@
am_create_testdir=empty
. test-init.sh
-plan_ 6
+plan_ 7
ocwd=$(pwd) || fatal_ getting current working directory
ACLOCAL_PATH=; unset ACLOCAL_PATH
@@ -181,6 +181,26 @@ test_end
#---
+test_begin AC_CONFIG_MACRO_DIR([not-exist]) and ACLOCAL_AMFLAGS = -I
not-exist
+
+cat configure.ac 'END'
+AC_INIT([oops], [1.0])
+AC_CONFIG_MACRO_DIR([not-exist])
+END
+
+cat Makefile.am 'END'
+ACLOCAL_AMFLAGS = -I not-exist
+END
+
+$ACLOCAL -Wno-error 2stderr \
+ cat stderr 2 \
+ test $(grep -c couldn't open directory 'not-exist' stderr) -eq 1 \
+ || r='not ok'
+
+test_end
+
+#---
+
# Avoid spurious failures with pre-2.70 autoconf.
# FIXME: remove this in automake 1.14, once we require Autoconf 2.70.
if echo 'AC_INIT AC_CONFIG_MACRO_DIRS' | $AUTOCONF -o/dev/null -; then
diff --git a/t/aclocal-macrodirs.tap b/t/aclocal-macrodirs.tap
index c0bb0ac..0deae72 100755
--- a/t/aclocal-macrodirs.tap
+++ b/t/aclocal-macrodirs.tap
@@ -20,7 +20,7 @@
am_create_testdir=empty
. test-init.sh
-plan_ 14
+plan_ 15
ocwd=$(pwd) || fatal_ getting current working directory
ACLOCAL_PATH=; unset ACLOCAL_PATH
@@ -381,6 +381,26 @@ test_end
#---
+test_begin AC_CONFIG_MACRO_DIRS([not-exist]) and ACLOCAL_AMFLAGS = -I
not-exist
+
+cat configure.ac 'END'
+AC_INIT([oops], [1.0])
+AC_CONFIG_MACRO_DIRS([not-exist])
+END
+
+cat Makefile.am 'END'
+ACLOCAL_AMFLAGS = -I not-exist
+END
+
+$ACLOCAL -Wno-error 2stderr \
+ cat stderr 2 \
+ test $(grep -c couldn't open directory 'not-exist' stderr) -eq 1 \
+ || r='not ok'
+
+test_end
+
+#---
+
# Avoid spurious failures with pre-2.70 autoconf.
# FIXME: remove this in automake 1.14, once we require Autoconf 2.70.
if echo 'AC_INIT AC_CONFIG_MACRO_DIRS' | $AUTOCONF -o/dev/null -; then
--
1.8.1.1.701.g02339dd
bug#13514: [PATCH v3 1/2] aclocal: just warn if the primary local m4 dir doesn't exist (don't error)
From: Pavel Raiskup prais...@redhat.com
Related to automake bug#13514.
Every package which does not need to have the local m4 macro
directory pre-existing in the version control system (because
e.g., it does not have nor need any private m4 macros) would
fail during the autoreconf -vfi phase if AC_CONFIG_MACRO_DIRS([m4])
is specified in configure.ac (it could be to instruct tools like
'autopoint' and 'libtoolize' to use 'm4' as the local directory
where to install definitions of their m4 macros, and to instruct
aclocal to look into it). The failure would go like this:
autoreconf: Entering directory `.'
autoreconf: running: aclocal --force
aclocal: error: couldn't open directory 'm4': No such file or directory
autoreconf: aclocal failed with exit status: 1
The problem is that when 'aclocal' is run for the first time during
'autoreconf', the directory 'm4' does not exist yet. It will be
created by e.g., 'libtoolize' or 'autopoint' later on. During the
second 'aclocal' run, the 'm4' directory exists and aclocal does not
complain.
To work around this issue, we degrade the error to a simple warning.
The warning is still quite useful when aclocal is run by hand - so
we are not removing completely.
See also:
http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html
http://lists.gnu.org/archive/html/automake-patches/2010-02/msg00030.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565663
https://bugzilla.redhat.com/show_bug.cgi?id=901333
* aclocal.in (SCAN_M4_DIRS_SILENT, SCAN_M4_DIRS_WARN,
SCAN_M4_DIRS_ERROR): New constants.
(scan_m4_dirs): Change the second parameter name to $ERR_LEVEL to
better reflect new semantic. Use new constants.
(scan_m4_files): Adjust to reflect the new 'scan_m4_dirs' semantics.
* t/aclocal-macrodir.tap: Adjust.
* t/aclocal-macrodirs.tap: Likewise.
* THANKS: Update.
* NEWS: Likewise.
Suggested-by: Ben Pfaff b...@cs.stanford.edu
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS| 7 +++
THANKS | 1 +
aclocal.in | 46 ++
t/aclocal-macrodir.tap | 12 ++--
t/aclocal-macrodirs.tap | 17 +
5 files changed, 69 insertions(+), 14 deletions(-)
diff --git a/NEWS b/NEWS
index f629fe2..70c4532 100644
--- a/NEWS
+++ b/NEWS
@@ -90,6 +90,13 @@ New in 1.13.2:
Automake 1.13, has turned out to be a similarly very bad idea,
for exactly the same reason.
+ - Aclocal no longer error out if the first local m4 directory (as
+specified by the '-I' option or the 'AC_CONFIG_MACRO_DIRS' or
+'AC_CONFIG_MACRO_DIR' macros) doesn't exist; it merely report a
+warning in the 'unsupported' category. This is done to support
+some pre-existing real-world usages; refer to automake bug#13514
+for more details.
+
New in 1.13.1:
diff --git a/THANKS b/THANKS
index 66498d4..5c014bf 100644
--- a/THANKS
+++ b/THANKS
@@ -297,6 +297,7 @@ Paul Jarc p...@po.cwru.edu
Paul Lunau t...@lunau.me.uk
Paul Martinolichmarti...@datasync.com
Paul Thomas ptho...@novell.com
+Pavel Raiskup prais...@redhat.com
Pavel Roskinpavel_ros...@geocities.com
Pavel Sanda p...@twin.jikos.cz
Per Bothner both...@cygnus.com
diff --git a/aclocal.in b/aclocal.in
index b51c09d..e65b0ab 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -165,6 +165,11 @@ my @ac_config_macro_dirs;
# If set, names a temporary file that must be erased on abnormal exit.
my $erase_me;
+# Constants for the $ERR_LEVEL parameter of the 'scan_m4_dirs' function.
+use constant SCAN_M4_DIRS_SILENT = 0;
+use constant SCAN_M4_DIRS_WARN = 1;
+use constant SCAN_M4_DIRS_ERROR = 2;
+
# Prototypes for all subroutines.
@@ -355,21 +360,42 @@ sub list_compare (\@\@)
-# scan_m4_dirs($TYPE, $ERR_ON_NONEXISTING, @DIRS)
+# scan_m4_dirs($TYPE, $ERR_LEVEL, @DIRS)
# ---
# Scan all M4 files installed in @DIRS for new macro definitions.
# Register each file as of type $TYPE (one of the FT_* constants).
+# If a directory in @DIRS cannot be read:
+# - fail hardif $ERR_LEVEL == SCAN_M4_DIRS_ERROR
+# - just print a warning if $ERR_LEVEL == SCAN_M4_DIRS_WA
+# - continue silentlyif $ERR_LEVEL == SCAN_M4_DIRS_SILENT
sub scan_m4_dirs ($$@)
{
- my ($type, $err_on_nonexisting, @dirlist) = @_;
+ my ($type, $err_level, @dirlist) = @_;
foreach my $m4dir (@dirlist)
{
if (! opendir (DIR, $m4dir))
{
# TODO: maybe avoid complaining only if errno == ENONENT?
- next unless $err_on_nonexisting;
- fatal couldn't open
[PATCH v3 0/2] AC_CONFIG_MACRO_DIR non-existent directories
On 02/11/2013 01:11 PM, Pavel Raiskup wrote: Hi, thanks for your comments! Here is second iteration of my proposal. [SNIP] And here is my re-roll, as promised. Among the changes: - tweaks to comments and commit messages; - style fixes to the code, and more sanity checks; - dropped the redundant parts of the testsuite adjustments; - extended the relevant parts of the testsuite a little; - updated the test 'aclocal-macrodirs.tap' as well; - added a NEWS entry; - added Pavel's name and address to THANKS; Pavel, since the adjusted patches are still in your name, I'd like your ACK before pushing. And of course, further reviews (by you or anyone else) would be welcome. I will push in a couple of days. Regards, Stefano -*-*-*- Pavel Raiskup (2): aclocal: just warn if the primary local m4 dir doesn't exist (don't error) aclocal: fix for more-than-once specified directories NEWS| 7 +++ THANKS | 1 + aclocal.in | 56 ++--- t/aclocal-macrodir.tap | 34 +++--- t/aclocal-macrodirs.tap | 39 +- 5 files changed, 121 insertions(+), 16 deletions(-) -- 1.8.1.1.701.g02339dd
[PATCH v3 2/2] aclocal: fix for more-than-once specified directories
From: Pavel Raiskup prais...@redhat.com
Related to automake bug#13514.
Do not explore directories for extra m4 files multiple times in 'aclocal'.
Doing so caused problems on older packages that specify
configure.ac: AC_CONFIG_MACRO_DIRS([m4])
Makefile.am: ACLOCAL_AMFLAGS = -I m4
when the 'm4' directory does not exist when aclocal is called the first
time by autoreconf.
See:
http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html
* aclocal.in (scan_m4_files): Remove duplicates in @user_includes.
* t/aclocal-macrodir.tap: Extend.
* t/aclocal-macrodirs.tap: Likewise.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
aclocal.in | 10 ++
t/aclocal-macrodir.tap | 22 +-
t/aclocal-macrodirs.tap | 22 +-
3 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/aclocal.in b/aclocal.in
index e65b0ab..d68ea33 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -432,6 +432,16 @@ sub scan_m4_files ()
if (@user_includes)
{
+ # Don't explore the same directory multiple times. This is here not
+ # only for speedup purposes. We need this when the user has e.g.
+ # specified 'ACLOCAL_AMFLAGS = -I m4' and has also set
+ # AC_CONFIG_MACRO_DIR[S]([m4]) in configure.ac. This makes the 'm4'
+ # directory to occur twice here and fail on the second call to
+ # scan_m4_dirs([m4]) when the 'm4' directory doesn't exist.
+ # TODO: Shouldn't there be rather a check in scan_m4_dirs for
+ # @user_includes[0]?
+ @user_includes = uniq @user_includes;
+
# Don't complain if the first user directory doesn't exist, in case
# we need to create it later (can happen if '--install' was given).
scan_m4_dirs (FT_USER,
diff --git a/t/aclocal-macrodir.tap b/t/aclocal-macrodir.tap
index a480c4c..051fdb5 100755
--- a/t/aclocal-macrodir.tap
+++ b/t/aclocal-macrodir.tap
@@ -20,7 +20,7 @@
am_create_testdir=empty
. test-init.sh
-plan_ 6
+plan_ 7
ocwd=$(pwd) || fatal_ getting current working directory
ACLOCAL_PATH=; unset ACLOCAL_PATH
@@ -181,6 +181,26 @@ test_end
#---
+test_begin AC_CONFIG_MACRO_DIR([not-exist]) and ACLOCAL_AMFLAGS = -I
not-exist
+
+cat configure.ac 'END'
+AC_INIT([oops], [1.0])
+AC_CONFIG_MACRO_DIR([not-exist])
+END
+
+cat Makefile.am 'END'
+ACLOCAL_AMFLAGS = -I not-exist
+END
+
+$ACLOCAL -Wno-error 2stderr \
+ cat stderr 2 \
+ test $(grep -c couldn't open directory 'not-exist' stderr) -eq 1 \
+ || r='not ok'
+
+test_end
+
+#---
+
# Avoid spurious failures with pre-2.70 autoconf.
# FIXME: remove this in automake 1.14, once we require Autoconf 2.70.
if echo 'AC_INIT AC_CONFIG_MACRO_DIRS' | $AUTOCONF -o/dev/null -; then
diff --git a/t/aclocal-macrodirs.tap b/t/aclocal-macrodirs.tap
index c0bb0ac..0deae72 100755
--- a/t/aclocal-macrodirs.tap
+++ b/t/aclocal-macrodirs.tap
@@ -20,7 +20,7 @@
am_create_testdir=empty
. test-init.sh
-plan_ 14
+plan_ 15
ocwd=$(pwd) || fatal_ getting current working directory
ACLOCAL_PATH=; unset ACLOCAL_PATH
@@ -381,6 +381,26 @@ test_end
#---
+test_begin AC_CONFIG_MACRO_DIRS([not-exist]) and ACLOCAL_AMFLAGS = -I
not-exist
+
+cat configure.ac 'END'
+AC_INIT([oops], [1.0])
+AC_CONFIG_MACRO_DIRS([not-exist])
+END
+
+cat Makefile.am 'END'
+ACLOCAL_AMFLAGS = -I not-exist
+END
+
+$ACLOCAL -Wno-error 2stderr \
+ cat stderr 2 \
+ test $(grep -c couldn't open directory 'not-exist' stderr) -eq 1 \
+ || r='not ok'
+
+test_end
+
+#---
+
# Avoid spurious failures with pre-2.70 autoconf.
# FIXME: remove this in automake 1.14, once we require Autoconf 2.70.
if echo 'AC_INIT AC_CONFIG_MACRO_DIRS' | $AUTOCONF -o/dev/null -; then
--
1.8.1.1.701.g02339dd
[PATCH v3 1/2] aclocal: just warn if the primary local m4 dir doesn't exist (don't error)
From: Pavel Raiskup prais...@redhat.com
Related to automake bug#13514.
Every package which does not need to have the local m4 macro
directory pre-existing in the version control system (because
e.g., it does not have nor need any private m4 macros) would
fail during the autoreconf -vfi phase if AC_CONFIG_MACRO_DIRS([m4])
is specified in configure.ac (it could be to instruct tools like
'autopoint' and 'libtoolize' to use 'm4' as the local directory
where to install definitions of their m4 macros, and to instruct
aclocal to look into it). The failure would go like this:
autoreconf: Entering directory `.'
autoreconf: running: aclocal --force
aclocal: error: couldn't open directory 'm4': No such file or directory
autoreconf: aclocal failed with exit status: 1
The problem is that when 'aclocal' is run for the first time during
'autoreconf', the directory 'm4' does not exist yet. It will be
created by e.g., 'libtoolize' or 'autopoint' later on. During the
second 'aclocal' run, the 'm4' directory exists and aclocal does not
complain.
To work around this issue, we degrade the error to a simple warning.
The warning is still quite useful when aclocal is run by hand - so
we are not removing completely.
See also:
http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html
http://lists.gnu.org/archive/html/automake-patches/2010-02/msg00030.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565663
https://bugzilla.redhat.com/show_bug.cgi?id=901333
* aclocal.in (SCAN_M4_DIRS_SILENT, SCAN_M4_DIRS_WARN,
SCAN_M4_DIRS_ERROR): New constants.
(scan_m4_dirs): Change the second parameter name to $ERR_LEVEL to
better reflect new semantic. Use new constants.
(scan_m4_files): Adjust to reflect the new 'scan_m4_dirs' semantics.
* t/aclocal-macrodir.tap: Adjust.
* t/aclocal-macrodirs.tap: Likewise.
* THANKS: Update.
* NEWS: Likewise.
Suggested-by: Ben Pfaff b...@cs.stanford.edu
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS| 7 +++
THANKS | 1 +
aclocal.in | 46 ++
t/aclocal-macrodir.tap | 12 ++--
t/aclocal-macrodirs.tap | 17 +
5 files changed, 69 insertions(+), 14 deletions(-)
diff --git a/NEWS b/NEWS
index f629fe2..70c4532 100644
--- a/NEWS
+++ b/NEWS
@@ -90,6 +90,13 @@ New in 1.13.2:
Automake 1.13, has turned out to be a similarly very bad idea,
for exactly the same reason.
+ - Aclocal no longer error out if the first local m4 directory (as
+specified by the '-I' option or the 'AC_CONFIG_MACRO_DIRS' or
+'AC_CONFIG_MACRO_DIR' macros) doesn't exist; it merely report a
+warning in the 'unsupported' category. This is done to support
+some pre-existing real-world usages; refer to automake bug#13514
+for more details.
+
New in 1.13.1:
diff --git a/THANKS b/THANKS
index 66498d4..5c014bf 100644
--- a/THANKS
+++ b/THANKS
@@ -297,6 +297,7 @@ Paul Jarc p...@po.cwru.edu
Paul Lunau t...@lunau.me.uk
Paul Martinolichmarti...@datasync.com
Paul Thomas ptho...@novell.com
+Pavel Raiskup prais...@redhat.com
Pavel Roskinpavel_ros...@geocities.com
Pavel Sanda p...@twin.jikos.cz
Per Bothner both...@cygnus.com
diff --git a/aclocal.in b/aclocal.in
index b51c09d..e65b0ab 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -165,6 +165,11 @@ my @ac_config_macro_dirs;
# If set, names a temporary file that must be erased on abnormal exit.
my $erase_me;
+# Constants for the $ERR_LEVEL parameter of the 'scan_m4_dirs' function.
+use constant SCAN_M4_DIRS_SILENT = 0;
+use constant SCAN_M4_DIRS_WARN = 1;
+use constant SCAN_M4_DIRS_ERROR = 2;
+
# Prototypes for all subroutines.
@@ -355,21 +360,42 @@ sub list_compare (\@\@)
-# scan_m4_dirs($TYPE, $ERR_ON_NONEXISTING, @DIRS)
+# scan_m4_dirs($TYPE, $ERR_LEVEL, @DIRS)
# ---
# Scan all M4 files installed in @DIRS for new macro definitions.
# Register each file as of type $TYPE (one of the FT_* constants).
+# If a directory in @DIRS cannot be read:
+# - fail hardif $ERR_LEVEL == SCAN_M4_DIRS_ERROR
+# - just print a warning if $ERR_LEVEL == SCAN_M4_DIRS_WA
+# - continue silentlyif $ERR_LEVEL == SCAN_M4_DIRS_SILENT
sub scan_m4_dirs ($$@)
{
- my ($type, $err_on_nonexisting, @dirlist) = @_;
+ my ($type, $err_level, @dirlist) = @_;
foreach my $m4dir (@dirlist)
{
if (! opendir (DIR, $m4dir))
{
# TODO: maybe avoid complaining only if errno == ENONENT?
- next unless $err_on_nonexisting;
- fatal couldn't open
Re: [PATCH 0/4] Use more perl function prototypes, and prefer func() over func()
On 02/14/2013 01:43 PM, Stefano Lattarini wrote: I will push this series to maint in a couple of days if there is no objection. Reviews are welcome. Regards, Stefano Stefano Lattarini (4): refactor: rip module Automake::Language out of automake script build: auto-generate perl subroutines prototypes for automake and aclocal maint: use more perl subroutines prototypes in the automake script style: call perl functions 'like_this()', not 'like_this()' HACKING | 5 +- Makefile.am | 14 +- aclocal.in | 22 +- automake.in | 752 bootstrap.sh| 11 +- lib/Automake/Language.pm| 122 +++ lib/gen-perl-protos | 36 +++ maintainer/syntax-checks.mk | 19 +- 8 files changed, 522 insertions(+), 459 deletions(-) create mode 100644 lib/Automake/Language.pm create mode 100755 lib/gen-perl-protos I've merged merged these into maint, merged maint into master, and pushed. Regards, Stefano
[PATCH] {maint} cosmetics: fix some docstring-like comments in automake
* automake.in: Here. And remove some redundant ones.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
I intend to push this in a couple of days (to maint) if there is no objection.
Regards,
Stefano
automake.in | 107
1 file changed, 20 insertions(+), 87 deletions(-)
diff --git a/automake.in b/automake.in
index d4c25c4..1523053 100644
--- a/automake.in
+++ b/automake.in
@@ -1070,11 +1070,9 @@ sub define_verbose_var ($$;$)
if (! vardef ($verbose_var, TRUE));
}
-# Above should not be needed in the general automake code.
-
# verbose_flag (NAME)
# ---
-# Contents of %VERBOSE%: variable to expand before rule command.
+# Contents of '%VERBOSE%' variable to expand before rule command.
sub verbose_flag ($)
{
my ($name) = @_;
@@ -1104,8 +1102,6 @@ sub define_verbose_tagvar ($)
define_verbose_var ($name, '@echo '. $name . ' ' x (8 - length ($name))
. ' $@;');
}
-# define_verbose_texinfo
-# --
# Engage the needed silent rules machinery for assorted texinfo commands.
sub define_verbose_texinfo ()
{
@@ -1118,8 +1114,6 @@ sub define_verbose_texinfo ()
define_verbose_var('texidevnull', ' /dev/null');
}
-# define_verbose_libtool
-# --
# Engage the needed silent rules machinery for 'libtool --silent'.
sub define_verbose_libtool ()
{
@@ -2302,7 +2296,7 @@ sub handle_ALLOCA ($$$)
saw_extension ('.c');
}
-# Canonicalize the input parameter
+# Canonicalize the input parameter.
sub canonicalize ($)
{
my ($string) = @_;
@@ -2329,9 +2323,6 @@ sub check_canonical_spelling ($@)
return $xname;
}
-
-# handle_compile ()
-# -
# Set up the compile suite.
sub handle_compile ()
{
@@ -2386,8 +2377,6 @@ sub handle_compile ()
$output_rules .= $coms$rules;
}
-# handle_libtool ()
-# -
# Handle libtool rules.
sub handle_libtool ()
{
@@ -2415,9 +2404,7 @@ sub handle_libtool ()
LTRMS = join (\n, @libtool_rms));
}
-# handle_programs ()
-# --
-# Handle C programs.
+
sub handle_programs ()
{
my @proglist = am_install_var ('progs', 'PROGRAMS',
@@ -2507,9 +2494,6 @@ sub handle_programs ()
}
-# handle_libraries ()
-# ---
-# Handle libraries.
sub handle_libraries ()
{
my @liblist = am_install_var ('libs', 'LIBRARIES',
@@ -2620,9 +2604,6 @@ sub handle_libraries ()
}
-# handle_ltlibraries ()
-# -
-# Handle shared libraries.
sub handle_ltlibraries ()
{
my @liblist = am_install_var ('ltlib', 'LTLIBRARIES',
@@ -2892,7 +2873,6 @@ sub check_typos ()
}
-# Handle scripts.
sub handle_scripts ()
{
# NOTE we no longer automatically clean SCRIPTS, because it is
@@ -2904,8 +2884,6 @@ sub handle_scripts ()
}
-
-
## ##
## Handling Texinfo files. ##
## ##
@@ -3064,7 +3042,7 @@ sub output_texinfo_build_rules ($$$@)
# ($MOSTLYCLEAN, $TEXICLEAN, $MAINTCLEAN)
# handle_texinfo_helper ($info_texinfos)
# --
-# Handle all Texinfo source; helper for handle_texinfo.
+# Handle all Texinfo source; helper for 'handle_texinfo'.
sub handle_texinfo_helper ($)
{
my ($info_texinfos) = @_;
@@ -3384,9 +3362,6 @@ EOF
}
-# handle_texinfo ()
-# -
-# Handle all Texinfo source.
sub handle_texinfo ()
{
reject_var 'TEXINFOS', 'TEXINFOS' is an anachronism; use 'info_TEXINFOS';
@@ -3415,7 +3390,6 @@ sub handle_texinfo ()
}
-# Handle any man pages.
sub handle_man_pages ()
{
reject_var 'MANS', 'MANS' is an anachronism; use 'man_MANS';
@@ -3554,7 +3528,7 @@ sub handle_man_pages ()
unless option 'no-installman';
}
-# Handle DATA variables.
+
sub handle_data ()
{
am_install_var ('-noextra', '-candist', 'data', 'DATA',
@@ -3563,7 +3537,7 @@ sub handle_data ()
'pkgdata', 'lisp', 'noinst', 'check');
}
-# Handle TAGS.
+
sub handle_tags ()
{
my @config;
@@ -3631,8 +3605,6 @@ sub user_phony_rule ($)
}
-# handle_dist
-# ---
# Handle 'dist' target.
sub handle_dist ()
{
@@ -3825,9 +3797,7 @@ sub check_directories_in_var ($)
skip_ac_subst = 1);
}
-# handle_subdirs ()
-# -
-# Handle subdirectories.
+
sub handle_subdirs ()
{
my $subdirs = var ('SUBDIRS');
@@ -3883,7 +3853,7 @@ sub scan_aclocal_m4 ()
}
-# Helper function for substitute_ac_subst_variables.
+# Helper function for 'substitute_ac_subst_variables'.
sub substitute_ac_subst_variables_worker($)
{
my ($token) = @_;
@@ -4290,7 +4260,6 @@ sub handle_configure ($$$@)
@actual_other_vpath_files);
}
-# Handle C headers.
sub handle_headers ()
{
my @r = am_install_var ('-defaultdist', 'header', 'HEADERS', 'include',
@@ -4359,7 +4328,7 @@ sub handle_gettext ()
require_file ($ac_gettext_location, GNU, 'ABOUT-NLS
bug#13514: [PATCH 1/2] aclocal: just warn if the primary local m4 dir doesn't exist (no error)
Hi Pavel.
There are still some issues with your patches (most of them reported
below). No need for your to re-roll; I will fix them locally, and then
send the amended patches out for further review before pushing. Not
sure whether I can do that today though, so be patient.
On 02/11/2013 01:11 PM, Pavel Raiskup wrote:
Related to automake bug#13514.
Every bootstrapping process which does not need to have the local
macro directory existing in version control system (because it does
not have any user-defined macros) would fail during 'autoreconf -vfi'
phase if the AC_CONFIG_MACRO_DIRS([m4]) is specified (to force tools
like 'autopoint' and 'libtoolize' to use 'm4' as the local directory
where to install definitions of their m4 macros, and to instruct
aclocal to look into it):
autoreconf: Entering directory `.'
autoreconf: running: aclocal --force
aclocal: error: couldn't open directory 'm4': No such file or directory
autoreconf: aclocal failed with exit status: 1
The problem is that when the 'aclocal' is run for the first time
during 'autoreconf', the directory 'm4' does not exist yet. It will
be created by e.g. by 'libtoolize' later on. During the second run
(after 'libtoolize'), the 'm4' directory exists and aclocal does not
complain.
For that reason, we degrade the error to a simple warning. The
warning is quite useful for running aclocal by hand - so we are not
removing completely.
See:
http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html
http://lists.gnu.org/archive/html/automake-patches/2010-02/msg00030.html
* aclocal.in (SCAN_M4_DIRS_SILENT, SCAN_M4_DIRS_WARN)
(SCAN_M4_DIRS_ERROR): New constants.
(scan_m4_dirs): Change the second parameter name to $ERR_LEVEL to
better reflect new semantic. Use new constants.
(scan_m4_files): Adjust to reflect the new 'scan_m4_dirs' semantics.
* t/aclocal-macrodir.tap: Check for proper return value of 'aclocal'
when AC_CONFIG_MACRO_DIR is specified. Check whether warning is (is
not) printed to stderr when the primary macro directory does not
exist.
Suggested-by: Ben Pfaff b...@cs.stanford.edu
---
aclocal.in | 31 +++
t/aclocal-macrodir.tap | 12
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/aclocal.in b/aclocal.in
index b51c09d..8bae156 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -165,6 +165,11 @@ my @ac_config_macro_dirs;
# If set, names a temporary file that must be erased on abnormal exit.
my $erase_me;
+# constants for scan_m4_dirs($ERR_LEVEL) parameter
+use constant SCAN_M4_DIRS_SILENT = 0;
+use constant SCAN_M4_DIRS_WARN = 1;
+use constant SCAN_M4_DIRS_ERROR = 2;
+
# Prototypes for all subroutines.
@@ -355,21 +360,29 @@ sub list_compare (\@\@)
-# scan_m4_dirs($TYPE, $ERR_ON_NONEXISTING, @DIRS)
+# scan_m4_dirs($TYPE, $ERR_LEVEL, @DIRS)
# ---
# Scan all M4 files installed in @DIRS for new macro definitions.
# Register each file as of type $TYPE (one of the FT_* constants).
+# Fail without discussion on non-existing include directory when the
+# $ERR_LEVEL parameter equals to SCAN_M4_DIRS_ERROR, just print warning
+# when it equals to SCAN_M4_DIRS_WARN and don't complain at all when
+# it is set to SCAN_M4_DIRS_SILENT.
sub scan_m4_dirs ($$@)
{
- my ($type, $err_on_nonexisting, @dirlist) = @_;
+ my ($type, $err_level, @dirlist) = @_;
foreach my $m4dir (@dirlist)
{
if (! opendir (DIR, $m4dir))
{
# TODO: maybe avoid complaining only if errno == ENONENT?
- next unless $err_on_nonexisting;
- fatal couldn't open directory '$m4dir': $!;
+ my $message = couldn't open directory '$m4dir': $!;
+
+ fatal $message if $err_level == SCAN_M4_DIRS_ERROR;
+ msg ('unsupported', $message) if $err_level == SCAN_M4_DIRS_WARN;
+ # don't complain if $err_level == SCAN_M4_DIRS_SILENT
+ next
}
# We reverse the directory contents so that foo2.m4 gets
@@ -408,11 +421,13 @@ sub scan_m4_files ()
{
# Don't complain if the first user directory doesn't exist, in case
# we need to create it later (can happen if '--install' was given).
- scan_m4_dirs (FT_USER, !$install, $user_includes[0]);
- scan_m4_dirs (FT_USER, 1, @user_includes[1..$#user_includes]);
+ my $first_dir_lvl = $install ? SCAN_M4_DIRS_SILENT : SCAN_M4_DIRS_WARN;
+ scan_m4_dirs (FT_USER, $first_dir_lvl, $user_includes[0]);
+ scan_m4_dirs (FT_USER, SCAN_M4_DIRS_ERROR,
+ @user_includes[1..$#user_includes]);
}
- scan_m4_dirs (FT_AUTOMAKE, 1, @automake_includes);
- scan_m4_dirs (FT_SYSTEM, 1, @system_includes);
+ scan_m4_dirs (FT_AUTOMAKE, SCAN_M4_DIRS_ERROR, @automake_includes);
[FYI] {branch-1.13.2} typofix: in comments in 't/ax/test-lib.sh'
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- t/ax/test-lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/ax/test-lib.sh b/t/ax/test-lib.sh index 81f9170..a3c16ee 100644 --- a/t/ax/test-lib.sh +++ b/t/ax/test-lib.sh @@ -258,7 +258,7 @@ am_set_exit_traps () trap fatal_ 'caught signal SIGINT' 2 trap fatal_ 'caught signal SIGTERM' 15 # Various shells seems to just ignore SIGQUIT under some circumstances, - # even if the signal is not blocked; however, if the signal it trapped, + # even if the signal is not blocked; however, if the signal is trapped, # the trap gets correctly executed. So we also trap SIGQUIT. # Here is a list of some shells that have been verified to exhibit the # problematic behavior with SIGQUIT: -- 1.8.1.1.662.gaa39828
[FYI] Merge branch 'maint' into master
commit 73e9f71c130dd620350553752d63edb761336e0e Merge: b9384c4 f637fc3 Author: Stefano Lattarini stefano.lattar...@gmail.com Date: Fri Feb 15 15:39:02 2013 +0100 Merge branch 'maint' * maint: typofix: in comments in 't/ax/test-lib.sh' tests on TAP: don't run the driver with perl unconditionally typofix: in comments in 'automake.in' tests: remove obsolete (and now wrong) comment typofix: in diagnostic in test 't/tap-realtime.sh' automake: fix reference to relevant tests in comments NEWS: we no longer plan to drop $(INCLUDES) support in next major version
[FYI] Merge branch 'branch-1.13.2' into maint
commit f637fc39a65cac7eb7050359e6c352a235f64528 Merge: 0756a43 24dbfd9 Author: Stefano Lattarini stefano.lattar...@gmail.com Date: Fri Feb 15 15:06:19 2013 +0100 Merge branch 'branch-1.13.2' into maint * branch-1.13.2: typofix: in comments in 't/ax/test-lib.sh' tests on TAP: don't run the driver with perl unconditionally typofix: in comments in 'automake.in' tests: remove obsolete (and now wrong) comment typofix: in diagnostic in test 't/tap-realtime.sh' automake: fix reference to relevant tests in comments NEWS: we no longer plan to drop $(INCLUDES) support in next major version
bug#13524: [PATCH 0/2] Improving user experience for non-recursive builds
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
bug#13524: [PATCH 1/2] preproc: add support for relative names in included fragments
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
bug#13524: [PATCH 1/2] preproc: add support for relative names in included fragments
On 02/14/2013 03:53 PM, Bob Friesenhahn wrote: On Thu, 14 Feb 2013, Stefano Lattarini wrote: From: Peter Rosin p...@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
[PATCH 0/2] Improving user experience for non-recursive builds
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
[PATCH 1/2] preproc: add support for relative names in included fragments
From: Peter Rosin p...@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.lattar...@gmail.com
Signed-off-by: Peter Rosin p...@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
[PATCH 2/2] preproc: enhance and extend tests
* 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.lattar...@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 000..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%' = footest '%reldir%' = foo
+ test '%D%'= footest '%D%' = foo
+ test '%canon_reldir%' = footest '%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
[FYI] {branch-1.13.2} tests: remove obsolete (and now wrong) comment
* t/ax/am-test-lib.sh: Here.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
t/ax/am-test-lib.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/t/ax/am-test-lib.sh b/t/ax/am-test-lib.sh
index f3fcacc..8508197 100644
--- a/t/ax/am-test-lib.sh
+++ b/t/ax/am-test-lib.sh
@@ -439,8 +439,6 @@ fetch_tap_driver ()
|| framework_failure_ couldn't fetch $am_tap_implementation TAP driver
sed 10q tap-driver # For debugging.
}
-# The shell/awk implementation of the TAP driver is still mostly dummy, so
-# use the perl implementation by default for the moment.
am_tap_implementation=${am_tap_implementation-shell}
# $PYTHON and support for PEP-3147. Needed to check our python-related
--
1.8.1.1.662.gaa39828
[FYI] {branch-1.13.2} tests on TAP: don't run the driver with perl unconditionally
* t/ax/tap-setup.sh: When a 'Makefile.am' was pre-existent in the test directory at the moment the client test script sourced this file, said 'Makefile.am' was tweaked to provide it with a proper definition of TEST_LOG_DRIVER. However, there was an error in this automatic definition, since it caused the TAP test driver to be unconditionally invoked with perl. This wasn't an issue in most situations, since perl is smart enough to re-execute a given script with the proper interpreter if it sees a she-bang line that doesn't seem to point to perl itself. Still, there is no reason to do something blatantly wrong even if our tools correct the dumb mistake for us. So fix the TEST_LOG_DRIVER definition. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- t/ax/tap-setup.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/ax/tap-setup.sh b/t/ax/tap-setup.sh index 4fef7b3..6955c86 100644 --- a/t/ax/tap-setup.sh +++ b/t/ax/tap-setup.sh @@ -36,7 +36,7 @@ fetch_tap_driver if test -f Makefile.am~; then mv -f Makefile.am~ Makefile.am \ || fatal_ failed to restore Makefile.am - echo 'TEST_LOG_DRIVER = $(PERL) $(srcdir)/tap-driver' Makefile.am \ + echo 'TEST_LOG_DRIVER = $(srcdir)/tap-driver' Makefile.am \ || fatal_ failed to update Makefile.am $AUTOMAKE Makefile \ || fatal_ failed to remake Makefile.in -- 1.8.1.1.662.gaa39828
Re: bug#13524: [PATCH 1/2] preproc: add support for relative names in included fragments
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
[PATCH 1/4] refactor: rip module Automake::Language out of automake script
This is just a preparatory patch in view of future changes.
* lib/Automake/Language.pm: New module, ripped out from ...
* automake.in: ... here. Related adjustments.
* Makefile.am (dist_perllib_DATA): List the new module.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
Makefile.am | 1 +
automake.in | 94 ++--
lib/Automake/Language.pm | 122 +++
3 files changed, 128 insertions(+), 89 deletions(-)
create mode 100644 lib/Automake/Language.pm
diff --git a/Makefile.am b/Makefile.am
index fa3dd3f..c245369 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -188,6 +188,7 @@ dist_perllib_DATA = \
lib/Automake/Getopt.pm \
lib/Automake/Item.pm \
lib/Automake/ItemDef.pm \
+ lib/Automake/Language.pm \
lib/Automake/Location.pm \
lib/Automake/Options.pm \
lib/Automake/Rule.pm \
diff --git a/automake.in b/automake.in
index d6ed599..5b57d3f 100644
--- a/automake.in
+++ b/automake.in
@@ -25,7 +25,9 @@ eval 'case $# in 0) exec @PERL@ -S $0;; *) exec @PERL@ -S
$0 $@;; esac'
# Perl reimplementation by Tom Tromey tro...@redhat.com, and
# Alexandre Duret-Lutz a...@gnu.org.
-package Language;
+package Automake;
+
+use strict;
BEGIN
{
@@ -43,93 +45,6 @@ BEGIN
$ENV{'SHELL'} = '@SHELL@' if exists $ENV{'DJDIR'};
}
-use Class::Struct ();
-Class::Struct::struct (
- # Short name of the language (c, f77...).
- 'name' = \$,
- # Nice name of the language (C, Fortran 77...).
- 'Name' = \$,
-
- # List of configure variables which must be defined.
- 'config_vars' = '@',
-
- # 'pure' is '1' or ''. A 'pure' language is one where, if
- # all the files in a directory are of that language, then we
- # do not require the C compiler or any code to call it.
- 'pure' = \$,
-
- 'autodep' = \$,
-
- # Name of the compiling variable (COMPILE).
- 'compiler' = \$,
- # Content of the compiling variable.
- 'compile' = \$,
- # Flag to require compilation without linking (-c).
- 'compile_flag' = \$,
- 'extensions' = '@',
- # A subroutine to compute a list of possible extensions of
- # the product given the input extensions.
- # (defaults to a subroutine which returns ('.$(OBJEXT)', '.lo'))
- 'output_extensions' = \$,
- # A list of flag variables used in 'compile'.
- # (defaults to [])
- 'flags' = @,
-
- # Any tag to pass to libtool while compiling.
- 'libtool_tag' = \$,
-
- # The file to use when generating rules for this language.
- # The default is 'depend2'.
- 'rule_file' = \$,
-
- # Name of the linking variable (LINK).
- 'linker' = \$,
- # Content of the linking variable.
- 'link' = \$,
-
- # Name of the compiler variable (CC).
- 'ccer' = \$,
-
- # Name of the linker variable (LD).
- 'lder' = \$,
- # Content of the linker variable ($(CC)).
- 'ld' = \$,
-
- # Flag to specify the output file (-o).
- 'output_flag' = \$,
- '_finish' = \$,
-
- # This is a subroutine which is called whenever we finally
- # determine the context in which a source file will be
- # compiled.
- '_target_hook' = \$,
-
- # If TRUE, nodist_ sources will be compiled using specific rules
- # (i.e. not inference rules). The default is FALSE.
- 'nodist_specific' = \$);
-
-
-sub finish ($)
-{
- my ($self) = @_;
- if (defined $self-_finish)
-{
- {$self-_finish} (@_);
-}
-}
-
-sub target_hook (%)
-{
-my ($self) = @_;
-if (defined $self-_target_hook)
-{
- {$self-_target_hook} (@_);
-}
-}
-
-package Automake;
-
-use strict;
use Automake::Config;
BEGIN
{
@@ -156,6 +71,7 @@ use Automake::VarDef;
use Automake::Rule;
use Automake::RuleDef;
use Automake::Wrap 'makefile_wrap';
+use Automake::Language;
use File::Basename;
use File::Spec;
use Carp;
@@ -5956,7 +5872,7 @@ sub register_language (%)
$option{'nodist_specific'} = 0
unless defined $option{'nodist_specific'};
- my $lang = new Language (%option);
+ my $lang = new Automake::Language (%option);
# Fill indexes.
$extension_map{$_} = $lang-name foreach @{$lang-extensions};
diff --git a/lib/Automake/Language.pm b/lib/Automake/Language.pm
new file mode 100644
index 000..6408e86
--- /dev/null
+++ b/lib/Automake/Language.pm
@@ -0,0 +1,122 @@
+# 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
[PATCH 2/4] build: auto-generate perl subroutines prototypes for automake and aclocal
This will allow us to avoid either using the 'foo' invocation form when
invoking a subroutine before its definition, or having to maintain the
list of prototypes by hand (with the risk of having it become incomplete
or fall out-of-sync when future edits to the automake and aclocal scripts
are done).
* Makefile.am (automake, aclocal): Automatically generate a list of
prototypes by looking at the subroutines definitions.
* bootstrap.sh: Likewise, when generating the temporary automake and
aclocal scripts used for bootstrapping.
* automake.in: Add a placeholder that will be tracked by the new recipes
and substituted with the computed prototypes. Remove existing prototypes,
that are now superfluous. Some adjustments required by the new, more
comprehensive prototypes declarations.
* aclocal.in: Likewise.
* maintainer/syntax-checks.mk (sc_diff_automake, sc_diff_aclocal): Adjust.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
Makefile.am | 13 +
aclocal.in | 22 +-
automake.in | 18 +-
bootstrap.sh| 11 ++-
lib/gen-perl-protos | 36
maintainer/syntax-checks.mk | 19 +++
6 files changed, 72 insertions(+), 47 deletions(-)
create mode 100755 lib/gen-perl-protos
diff --git a/Makefile.am b/Makefile.am
index c245369..2e05561 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -96,13 +96,18 @@ uninstall-hook:
# $(datadir) or other do_subst'ituted variables change.
automake: automake.in
aclocal: aclocal.in
-automake aclocal: Makefile
- $(AM_V_at)rm -f $@ $@-t
- $(AM_V_GEN)in=$@.in; $(do_subst) $(srcdir)/$@.in $@-t
+automake aclocal: Makefile lib/gen-perl-protos
+ $(AM_V_GEN)rm -f $@ $@-t $@-t2 \
+## Common substitutions.
+ in=$@.in $(do_subst) $(srcdir)/$$in $@-t \
+## Auto-compute prototypes of perl subroutines.
+ $(PERL) -w $(srcdir)/lib/gen-perl-protos $@-t $@-t2 \
+ mv -f $@-t2 $@-t \
## We can't use '$(generated_file_finalize)' here, because currently
## Automake contains occurrences of unexpanded @substitutions@ in
## comments, and that is perfectly legit.
- $(AM_V_at)chmod a+x,a-w $@-t mv -f $@-t $@
+ chmod a+x,a-w $@-t mv -f $@-t $@
+EXTRA_DIST += lib/gen-perl-protos
# The master location for INSTALL is lib/INSTALL.
# This is where make fetch will install new versions.
diff --git a/aclocal.in b/aclocal.in
index b51c09d..9e4ab79 100644
--- a/aclocal.in
+++ b/aclocal.in
@@ -169,27 +169,7 @@ my $erase_me;
# Prototypes for all subroutines.
-sub unlink_tmp (;$);
-sub xmkdir_p ($);
-sub check_acinclude ();
-sub reset_maps ();
-sub install_file ($$);
-sub list_compare (\@\@);
-sub scan_m4_dirs ($$@);
-sub scan_m4_files ();
-sub add_macro ($);
-sub scan_configure_dep ($);
-sub add_file ($);
-sub scan_file ($$$);
-sub strip_redundant_includes (%);
-sub trace_used_macros ();
-sub scan_configure ();
-sub write_aclocal ($@);
-sub usage ($);
-sub version ();
-sub handle_acdir_option ($$);
-sub parse_arguments ();
-sub parse_ACLOCAL_PATH ();
+#! Prototypes here will automatically be generated by the build system.
diff --git a/automake.in b/automake.in
index 5b57d3f..3e27843 100644
--- a/automake.in
+++ b/automake.in
@@ -76,6 +76,13 @@ use File::Basename;
use File::Spec;
use Carp;
+## --- ##
+## Subroutine prototypes. ##
+## --- ##
+
+#! Prototypes here will automatically be generated by the build system.
+
+
## --- ##
## Constants. ##
## --- ##
@@ -531,13 +538,6 @@ Automake::Variable::hook ('SUFFIXES',
\var_SUFFIXES_trigger);
-## - ##
-## Forward subroutine declarations. ##
-## - ##
-sub register_language (%);
-sub file_contents_internal ($$$%);
-sub define_files_variable ($\@$$);
-
# initialize_per_input ()
#
@@ -948,7 +948,7 @@ register_language ('name' = 'java',
# Uncategorized errors about the current Makefile.am.
sub err_am ($;%)
{
- msg_am ('error', @_);
+ msg_am ('error', shift, @_);
}
# err_ac ($MESSAGE, [%OPTIONS])
@@ -956,7 +956,7 @@ sub err_am ($;%)
# Uncategorized errors about configure.ac.
sub err_ac ($;%)
{
- msg_ac ('error', @_);
+ msg_ac ('error', shift, @_);
}
# msg_am ($CHANNEL, $MESSAGE, [%OPTIONS])
diff --git a/bootstrap.sh b/bootstrap.sh
index 93bf3fd..541280e 100755
--- a/bootstrap.sh
+++ b/bootstrap.sh
@@ -95,14 +95,15 @@ dosubst ()
dosubst automake-$APIVERSION/Automake/Config.in \
automake-$APIVERSION/Automake/Config.pm
-# Create temporary replacement for aclocal.
-dosubst aclocal.in aclocal.tmp
-
# Overwrite amversion.m4.
dosubst m4/amversion.in m4/amversion.m4
-# Create temporary replacement
[PATCH 3/4] maint: use more perl subroutines prototypes in the automake script
* automake.in: Throughout this file. Note that these new prototypes
are not much useful, since many subroutine calls still use the old
'foo' form; but we'll take care of that in later patches.
* lib/Automake/Language.pm (target_hook): Call the '_target_hook'
of the given language in a more modern form, avoiding ''.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
automake.in | 90
lib/Automake/Language.pm | 2 +-
2 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/automake.in b/automake.in
index 3e27843..8466ee4 100644
--- a/automake.in
+++ b/automake.in
@@ -1146,7 +1146,7 @@ sub handle_silent ()
# Handle AUTOMAKE_OPTIONS variable. Return 1 on error, 0 otherwise.
-sub handle_options
+sub handle_options ()
{
my $var = var ('AUTOMAKE_OPTIONS');
if ($var)
@@ -1219,7 +1219,7 @@ sub check_user_variables (@)
}
# Call finish function for each language that was used.
-sub handle_languages
+sub handle_languages ()
{
if (! option 'no-dependencies')
{
@@ -1526,7 +1526,7 @@ sub append_exeext ($)
# mentioned. This is a separate function (as opposed to being inlined
# in handle_source_transform) because it isn't always appropriate to
# do this check.
-sub check_libobjs_sources
+sub check_libobjs_sources ($$)
{
my ($one_file, $unxformed) = @_;
@@ -2133,7 +2133,7 @@ sub handle_source_transform (%)
# transformed name of object being built, or empty string if no object
# name of _LDADD/_LIBADD-type variable to examine
# Returns 1 if LIBOBJS seen, 0 otherwise.
-sub handle_lib_objects
+sub handle_lib_objects ($$)
{
my ($xname, $varname) = @_;
@@ -2303,7 +2303,7 @@ sub handle_ALLOCA ($$$)
}
# Canonicalize the input parameter
-sub canonicalize
+sub canonicalize ($)
{
my ($string) = @_;
$string =~ tr/A-Za-z0-9_\@/_/c;
@@ -2313,7 +2313,7 @@ sub canonicalize
# Canonicalize a name, and check to make sure the non-canonical name
# is never used. Returns canonical name. Arguments are name and a
# list of suffixes to check for.
-sub check_canonical_spelling
+sub check_canonical_spelling ($@)
{
my ($name, @suffixes) = @_;
@@ -2389,7 +2389,7 @@ sub handle_compile ()
# handle_libtool ()
# -
# Handle libtool rules.
-sub handle_libtool
+sub handle_libtool ()
{
return unless var ('LIBTOOL');
@@ -2418,7 +2418,7 @@ sub handle_libtool
# handle_programs ()
# --
# Handle C programs.
-sub handle_programs
+sub handle_programs ()
{
my @proglist = am_install_var ('progs', 'PROGRAMS',
'bin', 'sbin', 'libexec', 'pkglibexec',
@@ -2510,7 +2510,7 @@ sub handle_programs
# handle_libraries ()
# ---
# Handle libraries.
-sub handle_libraries
+sub handle_libraries ()
{
my @liblist = am_install_var ('libs', 'LIBRARIES',
'lib', 'pkglib', 'noinst', 'check');
@@ -2623,7 +2623,7 @@ sub handle_libraries
# handle_ltlibraries ()
# -
# Handle shared libraries.
-sub handle_ltlibraries
+sub handle_ltlibraries ()
{
my @liblist = am_install_var ('ltlib', 'LTLIBRARIES',
'noinst', 'lib', 'pkglib', 'check');
@@ -2893,7 +2893,7 @@ sub check_typos ()
# Handle scripts.
-sub handle_scripts
+sub handle_scripts ()
{
# NOTE we no longer automatically clean SCRIPTS, because it is
# useful to sometimes distribute scripts verbatim. This happens
@@ -3416,7 +3416,7 @@ sub handle_texinfo ()
# Handle any man pages.
-sub handle_man_pages
+sub handle_man_pages ()
{
reject_var 'MANS', 'MANS' is an anachronism; use 'man_MANS';
@@ -3555,7 +3555,7 @@ sub handle_man_pages
}
# Handle DATA variables.
-sub handle_data
+sub handle_data ()
{
am_install_var ('-noextra', '-candist', 'data', 'DATA',
'data', 'dataroot', 'doc', 'dvi', 'html', 'pdf',
@@ -3564,7 +3564,7 @@ sub handle_data
}
# Handle TAGS.
-sub handle_tags
+sub handle_tags ()
{
my @config;
foreach my $spec (@config_headers)
@@ -4291,7 +4291,7 @@ sub handle_configure ($$$@)
}
# Handle C headers.
-sub handle_headers
+sub handle_headers ()
{
my @r = am_install_var ('-defaultdist', 'header', 'HEADERS', 'include',
'oldinclude', 'pkginclude',
@@ -4303,7 +4303,7 @@ sub handle_headers
}
}
-sub handle_gettext
+sub handle_gettext ()
{
return if ! $seen_gettext || $relative_dir ne '.';
@@ -4360,7 +4360,7 @@ sub handle_gettext
}
# Handle footer elements.
-sub handle_footer
+sub handle_footer ()
{
reject_rule ('.SUFFIXES',
use variable 'SUFFIXES', not target '.SUFFIXES');
@@ -4612,7 +4612,7 @@ sub target_cmp
# handle_factored_dependencies ()
#
# Handle everything related to gathered targets.
-sub handle_factored_dependencies
+sub handle_factored_dependencies ()
{
# Reject bad hooks.
foreach my
[PATCH 4/4] style: call perl functions 'like_this()', not 'like_this()'
We can do so now that our build rules auto-generate a list of
prototypes for all functions ins our scripts.
* automake.in: Adjust throughout.
* HACKING: Adjust advises.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
HACKING | 5 +-
automake.in | 552 ++--
2 files changed, 278 insertions(+), 279 deletions(-)
diff --git a/HACKING b/HACKING
index 8f51ff4..a4f89bd 100644
--- a/HACKING
+++ b/HACKING
@@ -96,11 +96,8 @@
default), and other portions using the GNU style (cperl-mode's
default). Write new code using GNU style.
-* Don't use for function calls, unless required.
+* Don't use for function calls, unless really required.
The use of prevents prototypes from being checked.
- Just as above, don't change massively all the code to strip the
- , just convert the old code as you work on it, and write new
- code without.
= Working with git
diff --git a/automake.in b/automake.in
index 8466ee4..0df0965 100644
--- a/automake.in
+++ b/automake.in
@@ -264,7 +264,7 @@ my %ac_config_files_location = ();
my %ac_config_files_condition = ();
# Directory to search for configure-required files. This
-# will be computed by locate_aux_dir and can be set using
+# will be computed by locate_aux_dir() and can be set using
# AC_CONFIG_AUX_DIR in configure.ac.
# $CONFIG_AUX_DIR is the 'raw' directory, valid only in the source-tree.
my $config_aux_dir = '';
@@ -539,8 +539,8 @@ Automake::Variable::hook ('SUFFIXES',
\var_SUFFIXES_trigger);
-# initialize_per_input ()
-#
+# initialize_per_input ()
+# ---
# (Re)-Initialize per-Makefile.am variables.
sub initialize_per_input ()
{
@@ -995,8 +995,8 @@ sub subst ($)
# $BACKPATH
-# backname ($RELDIR)
-#
+# backname ($RELDIR)
+# ---
# If I cd $RELDIR, then to come back, I should cd $BACKPATH.
# For instance 'src/foo' = '../..'.
# Works with non strictly increasing paths, i.e., 'src/../lib' = '..'.
@@ -1228,10 +1228,10 @@ sub handle_languages ()
if (keys %extension_seen keys %dep_files)
{
# Set location of depcomp.
- define_variable ('depcomp',
- \$(SHELL) $am_config_aux_dir/depcomp,
- INTERNAL);
- define_variable ('am__depfiles_maybe', 'depfiles', INTERNAL);
+ define_variable ('depcomp',
+\$(SHELL) $am_config_aux_dir/depcomp,
+INTERNAL);
+ define_variable ('am__depfiles_maybe', 'depfiles', INTERNAL);
require_conf_file ($am_file.am, FOREIGN, 'depcomp');
@@ -1254,15 +1254,15 @@ sub handle_languages ()
# Compute the set of directories to remove in distclean-depend.
my @depdirs = uniq (map { dirname ($_) } @deplist);
- $output_rules .= file_contents ('depend',
-new Automake::Location,
-DEPDIRS = @depdirs);
+ $output_rules .= file_contents ('depend',
+ new Automake::Location,
+ DEPDIRS = @depdirs);
}
}
else
{
- define_variable ('depcomp', '', INTERNAL);
- define_variable ('am__depfiles_maybe', '', INTERNAL);
+ define_variable ('depcomp', '', INTERNAL);
+ define_variable ('am__depfiles_maybe', '', INTERNAL);
}
my %done;
@@ -1297,7 +1297,7 @@ sub handle_languages ()
'FASTDEP' = $FASTDEP,
'-c' = $lang-compile_flag || '',
# These are not used, but they need to be defined
-# so transform do not complain.
+# so transform() do not complain.
SUBDIROBJ = 0,
'DERIVED-EXT' = 'BUG',
DIST_SOURCE = 1,
@@ -1320,7 +1320,7 @@ sub handle_languages ()
# Compute a possible derived extension.
# This is not used by depend2.am.
- my $der_ext = ({$lang-output_extensions} ($ext))[0];
+ my $der_ext = ($lang-output_extensions-($ext))[0];
# When we output an inference rule like '.c.o:' we
# have two cases to consider: either subdir-objects
@@ -1490,7 +1490,7 @@ sub handle_languages ()
if ($needs_c)
{
- define_compiler_variable ($languages{'c'})
+ define_compiler_variable ($languages{'c'})
unless defined $done{$languages{'c'}};
define_linker_variable ($languages{'c'});
}
@@ -1625,13 +1625,13 @@ sub handle_single_transform ($%)
# language function.
my $aggregate = 'AM
[PATCH 0/4] Use more perl function prototypes, and prefer func() over func()
I will push this series to maint in a couple of days if there is no objection. Reviews are welcome. Regards, Stefano Stefano Lattarini (4): refactor: rip module Automake::Language out of automake script build: auto-generate perl subroutines prototypes for automake and aclocal maint: use more perl subroutines prototypes in the automake script style: call perl functions 'like_this()', not 'like_this()' HACKING | 5 +- Makefile.am | 14 +- aclocal.in | 22 +- automake.in | 752 bootstrap.sh| 11 +- lib/Automake/Language.pm| 122 +++ lib/gen-perl-protos | 36 +++ maintainer/syntax-checks.mk | 19 +- 8 files changed, 522 insertions(+), 459 deletions(-) create mode 100644 lib/Automake/Language.pm create mode 100755 lib/gen-perl-protos -- 1.8.1.1.662.gaa39828
Re: [PATCH 1/2] preproc: add support for relative names in included fragments
On 02/14/2013 03:53 PM, Bob Friesenhahn wrote: On Thu, 14 Feb 2013, Stefano Lattarini wrote: From: Peter Rosin p...@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
Re: bug#13524: [PATCH 1/2] preproc: add support for relative names in included fragments
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
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Hi Diego. On 02/12/2013 06:50 PM, Diego Elio Pettenò wrote: On 12/02/2013 17:44, Stefano Lattarini wrote: Ah, ok, so in the end you already agree that this is a documentation issue rather than a versioning one. Please correct me if I'm wrong! I guess it's a matter of perception. I honestly don't see the point of beta software if nobody's using it, as it would just actually be an alpha for the beta (.0/.1 releases) which then becomes stable (.2+ — sometimes). If we go with a new major version we could have: 2.0.x - new major, testing branch (let's not call it beta!), all fine but it throws a huge warning at runtime that the branch is not finalized yet and thus that it should not be used for distributed software 2.1.x - new major, stable branch, micro versions for bugfix only 2.2.x - new major, new features branch, introduces deprecation warnings for features leaving in 3.0, possibly some opt-in versions of features becoming standard in 3.0. _If needed_ only: 2.90.x - experimental branch for the upcoming 3.0 testing branch The scheme you are proposing seems sensible to me. Anyway, it is an *extension* to my new proposed versioning/branching scheme, so we don't have to decide on its adoption right away -- we can switch to my proposed scheme first, and then refine/enhance it with your proposal, if nobody objects. OK? Thanks, Stefano
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Hi Miles. On 02/12/2013 12:50 AM, Miles Bader wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: But what if we want to have multiple betas for, say, Automake 1.14? Today, we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme you are proposing? There's always 1.14.0.1, ... Yuck; the new versioning scheme is done exactly to avoid that kind of overly long version numbers -- otherwise, we could just have 1.13.1.1 as bug-fixing release, 1.13.2 as new minor release, and 1.14 as new major release. But if that leading 1 is going to remain unchanged anyway, what is the point of keeping it? It's just visual noise IMO. (In addition, the current version-checking code in Automake only grasps version numbers with at most three numbers). Or the widely used in FOSS 1.13.99... [sometimes they start at 90, to leave room for updates, This might work. But see below. but I suppose you could always just use .99.1, .99.2, ...] (No, because, as said above, I don't want to have version numbers with four or more components) Anyway, before changing the current naming scheme for beta versions, we'd need some numbers about which the most widespread naming schemes are, and weight their advantages and disadvantages w.r.t. our workflow; we don't want to trade the current naming scheme for another that is only marginally more popular, or for a one that will give use a new and bigger set of problems down the road. Thanks, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Hi Miles. On 02/12/2013 12:50 AM, Miles Bader wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: But what if we want to have multiple betas for, say, Automake 1.14? Today, we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme you are proposing? There's always 1.14.0.1, ... Yuck; the new versioning scheme is done exactly to avoid that kind of overly long version numbers -- otherwise, we could just have 1.13.1.1 as bug-fixing release, 1.13.2 as new minor release, and 1.14 as new major release. But if that leading 1 is going to remain unchanged anyway, what is the point of keeping it? It's just visual noise IMO. (In addition, the current version-checking code in Automake only grasps version numbers with at most three numbers). Or the widely used in FOSS 1.13.99... [sometimes they start at 90, to leave room for updates, This might work. But see below. but I suppose you could always just use .99.1, .99.2, ...] (No, because, as said above, I don't want to have version numbers with four or more components) Anyway, before changing the current naming scheme for beta versions, we'd need some numbers about which the most widespread naming schemes are, and weight their advantages and disadvantages w.r.t. our workflow; we don't want to trade the current naming scheme for another that is only marginally more popular, or for a one that will give use a new and bigger set of problems down the road. Thanks, Stefano
Re: subdir-objects and generated file names
On 02/12/2013 07:28 AM, Vincent Torri wrote: Hey I'm porting a lib to a non recursive make build system. I have a single top level Makefile.am which has: AUTOMAKE_OPTIONS = subdir-objects include src/lib/css/Makefile.mk In that Makefile.mk, yacc is called and generates the file src_lib_css_libecss_la-ecss_grammar.h from ecss_grammar.y (both of them are in src/lib/css) is it possible to keep the name grammar.h You means 'ecss_grammar.y', right? and not src_lib_css_libecss_la-ecss_grammar.h while using the subdir-objects option ? Not really; but you can at least shorten the name considerably using the _SHORTNAME trick: http://www.gnu.org/software/automake/manual/automake.html#index-maude_005fSHORTNAME-477 HTH, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/11/2013 04:00 PM, Diego Elio Pettenò wrote: On 11/02/2013 15:54, Stefano Lattarini wrote: But what if we want to have multiple betas for, say, Automake 1.14? Today, we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme you are proposing? Given that 1.12.0 was not really final release, Why not? and 1.13.0 _and_ .1 were not really final releases, This is true, but is only due to the fact that I released them with too much haste, without giving time for proper testing. IOW, this debacle has been a fault of mine, not of the naming scheme. I would suggest calling the first beta as 1.14.0 with the big fat warning, I don't see any need for this; everyone knows that a new major release is more likely to contain bugs and rough edges. (OTOH, this is not excuse to be sloppy and hastily in the release process as I've been for 1.13; but avoiding repeating the mistake in the future will only require more care and attention from the maintainer, and not a change of policy). then everybody's satisfied (no missing features, for instance), it rolls as 1.14.4 (say) really final release. This should be more or less equivalent to Apache's versioning, Any link about this? The info I found on Google doesn't seem very helpful nor relevant. and leads to decency, I'd say. Thanks, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/12/2013 09:25 AM, Miles Bader wrote: 2013/2/12 Stefano Lattarini stefano.lattar...@gmail.com: But what if we want to have multiple betas for, say, Automake 1.14? Today, we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme you are proposing? There's always 1.14.0.1, ... Yuck; the new versioning scheme is done exactly to avoid that kind of overly long version numbers Well, I agree in general that too many components is yucky, but keep in mind that these _aren't releases_, so assigning them awkward version numbers doesn't really seem all that annoying. These really aren't part of the historical record. The existing naming scheme for betas does the same thing (uses weird version numbers), but is problematic because it's not mechanically consistent with ordinary version numbers (and so screws up cases such as packaging software). Mostly fair points; but the biggest issue with this proposal (not sure why I didn't think of it before, sorry) is that it is not at all clear that a version like 1.13.0.1 is supposed to be a beta release. People will easily mistake it for a stable release. OK, we can add warnings and info and whatnot in the manual and homepage of automake about our unusual versioning scheme, but how many people will read them? And in the end, even those who do will likely be just annoyed by the fact that we are trying to be clever and invent a new versioining scheme incompatible with every other existing one. No, if we want to change the versioning scheme for beta and rc versions, we want the new scheme to be already used and well known. I do agree that removing the leading 1. might be a good idea if it's meaningless in practice. Linux's similar action was good. -miles -- Cat is power. Cat is peace. Thanks, Stefano
Re: subdir-objects and generated file names
On 02/12/2013 03:27 PM, Vincent Torri wrote: On Tue, Feb 12, 2013 at 9:24 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On 02/12/2013 07:28 AM, Vincent Torri wrote: Hey I'm porting a lib to a non recursive make build system. I have a single top level Makefile.am which has: AUTOMAKE_OPTIONS = subdir-objects include src/lib/css/Makefile.mk In that Makefile.mk, yacc is called and generates the file src_lib_css_libecss_la-ecss_grammar.h from ecss_grammar.y (both of them are in src/lib/css) is it possible to keep the name grammar.h You means 'ecss_grammar.y', right? no, ecss_grammar.h. Yes, that what I meant. Sorry for the typo and the confusion. Regards, Stefano
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
On 02/12/2013 04:15 PM, Diego Elio Pettenò wrote: On 12/02/2013 09:26, Stefano Lattarini wrote: Given that 1.12.0 was not really final release, Why not? AM_PROG_MKDIR_P. Ah, right. I had forgot about that (selective memory? A dangerous thing). This is true, but is only due to the fact that I released them with too much haste, without giving time for proper testing. IOW, this debacle has been a fault of mine, not of the naming scheme. True, but it shows a pattern: most people (even developers who get involved in the process, such as Paolo) do not even look at the beta versions.. That is not something automake can do anything about. Releasing beta versions whose version numbers suggests they are actually stable versions is a solution worse than the problem. But you might correctly point out that, due to lack of proper testing, this is already what we are doing right now (albeit not by choice); so the issue becomes at this point a documentation issue (that is, we should find a way to inform the users that early stable versions of new major releases might turn out to be lamentably unstable in practice, if nobody has given the betas proper testing). See again below. I don't see any need for this; everyone knows that a new major release is more likely to contain bugs and rough edges. (OTOH, this is not excuse to be sloppy and hastily in the release process as I've been for 1.13; but avoiding repeating the mistake in the future will only require more care and attention from the maintainer, and not a change of policy). True, but a new beta also is also more likely to contain bugs and rough edges... so it's basically the same thing, thus why I'm saying that it should just be the same. Put out the new major at not stable yet, try it out all around, then make a release to call it stable. This sounds sensible, but I think it should be done in addition to the usual release of classic beta versions (with the hope that someone will get to testing them eventually). And if we agree on this approach, the only required change would be a new section about this versioning and stability issues in the Automake manual (and/or in the Autotools Mythbuster guide). As usual, patches are welcome (this is not really my itch). Any link about this? The info I found on Google doesn't seem very helpful nor relevant. I'm afraid I don't have anything that Google wouldn't have. But at least for 2.2, it was declared stable much later than .0 if I'm not mistaken. That happened with Python as well, and I guess with many other softwares who did a major version bump with non-trivial backward incompatibilities. Basically, it would be like making policy that the new major branch is not stable until we say it is.. which is really what we need. Ah, ok, so in the end you already agree that this is a documentation issue rather than a versioning one. Please correct me if I'm wrong! Thanks, Stefano
bug#13514: [PATCH v2 0/0] AC_CONFIG_MACRO_DIR non-existent directory
On 02/11/2013 01:11 PM, Pavel Raiskup wrote: Hi, thanks for your comments! Thanks for your patches, and you patience. Here is second iteration of my proposal. [PATCH 1/2] aclocal: just warn if the primary local m4 dir doesn't aclocal.in | 10 ++ t/aclocal-macrodir.tap | 22 +- [PATCH 2/2] aclocal: fix for more-than-once specified directories aclocal.in | 31 +++ t/aclocal-macrodir.tap | 12 Review will follow later today, or in the next days. Two meta-questions first, though: - Do you have copyright assignment paperwork for Automake in place? Your changes definitely don't qualify as trivial or very short, so I fear the paperwork is required. These shouldn't be needed as Red Hat should have already signed papers with FSF covering all employees - if the patch it is part of the work - Which is this case. Nice! And thanks to Red Hat for that. - In the future, if it doesn't take you too much time, could you try to send the patches in-line rather than as attachments? (You can use the excellent git send-email command for that). This would make it more convenient for reviewers to answer to your patches separately, and to quote relevant chunks from them. Thanks. From now I'm using git send-email, Thanks. sorry for inconvenience. And please, no need to apologize! See: http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html * aclocal.in (scan_m4_files): Unique multiply specified directories. s/Unique multiply/uniquify/ perhaps? Good catch, BTW! I think we also need a testsuite addition to cover for the use case fixed by this patch (not a requirement to get your patches in; if you don't want to write such a test, I'll get to it myself eventually). I tried to write a test. Feel free to trash/rewrite it just to speed this process up. OK. = === PATCH [3/3] = Subject: [PATCH 3/3] docs: Mention consequences with AC_CONFIG_MACRO_DIRS I'm quite unconvinced of the usefulness of this patch. More details below. [...] diff --git a/doc/automake.texi b/doc/automake.texi index e700ab9..944fd9d 100644 --- a/doc/automake.texi +++ b/doc/automake.texi [...] +There is strictly encouraged not to change the 'm4' directory name to +some different name at the moment. Why not? Have you examples of real-world issues caused by different names? Ok, I was considering situation that we can live without ACLOCAL_AMFLAGS. Because we can not, there is no problem (I'm thinking about gettext). For this reason, do you think it would be possible to freeze ACLOCAL_AMFLAGS and AC_CONFIG_MACRO_DIR a 'little' bit longer in automake then until 1.14? Do you mean not removing ACLOCAL_AMFLAGS in 1.14? Sure, that has never been the plan. ACLOCAL_AMFLAGS will cause non-fatal warnings in 1.14, but will still work. And very likely it will keep working with Automake 1.15 (and possibly 1.16 too). ASIDE Notice that if the new versioning and releasing scheme planned at http://debbugs.gnu.org/13578 is finally picked up, what we are now labelling as Automake 1.14 will actually be released as Automake 2.0 (to be released no sooner than an year and a half from now); similarly, 1.15 will actually be released as 3.0, and 1.16 as 4.0, and so on. /ASIDE I'm afraid that all tools will have problems to follow these changes... Indeed, we should tread carefully here. [SNIP] + The least problematic way seems to be now: + +@example +configure.ac: AC_CONFIG_MACRO_DIRS([m4]) +Makefile.am: # **NO** ACLOCAL_AMFLAGS +@end example + Alas, this is not true; the above will not work with Automake 1.12.x, I forgot about it, sorry. nor with the (so far) latest version of libtool (2.4.2). This is because of AC_CONFIG_MACRO_DIRS, there should be AC_CONFIG_MACRO_DIR. But anyway, this is not a good idea.. as we need ACLOCAL_AMFLAGS. For the moment, all the users not willing to require cutting-edge autotools for their build systems will still have to specify ACLOCAL_AMFLAGS. Yes, but not if they don't want (or don't necessarily need) to switch macros into different directory than 'm4'? There might be a misunderstanding here (either from your part, or in my understanding of what you are saying). Are you aware that none of the autotools use *any* local m4 directory if it is not explicitly instructed to, right? So there is not default local m4 directory. The 'AC_CONFIG_MACRO_DIR' and 'AC_CONFIG_MACRO_DIRS' macros are not used to switch to an alternate name for the local m4 directory, but to declare such directory (or directories). This is somehow complicated and inconsistent behavior among autotools :( and I'm still not sure what should I suggest to package maintainers which are dependant on autotools for that issue. Should we suggest in general something like this? configure.ac:
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Hi Diego, Jack, sorry for the late reply. On 02/01/2013 06:47 AM, Jack Kelly wrote: Diego Elio Pettenò flamee...@flameeyes.eu writes: On 31/01/2013 20:58, Jack Kelly wrote: IMHO, that seems like a great way to cause trouble for unsuspecting users. (Anyone remember KDE4.0?) Can you expand on why you think it's a good plan? Because unlike KDE, automake can put a big fat warning in the generated configure that says You're using a version unsuitable for production, and then people would understand it much better. Or at automake invocation time? KDE 4.0 was a screwup because there was no big fat warning, and users insisted to have it. No user _asks_ for automake. Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit the ordering system for most package managers? Bonus points if it works in asciibetical order, too. Good luck finding one. Gentoo would be fine with X.Y_betaZ — but I honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y for almost everything but autotools.. Fair points. +1 to calling the betas X.0. But what if we want to have multiple betas for, say, Automake 1.14? Today, we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the scheme you are proposing? As for the naming scheme for alpha/beta versions in Automake: I agree it is suboptimal and a little confusing, its roots being likely based in the messy 1.4 - 1.6 transition. So far, it hasn't yet grated on me enough to motivate me to try to improve it [1]; but if anyone wants to take a shot at that, be my guest! (that will probably require some mail archive digging and git blame invocations to see who introduced what for which reason). [1] In a way that is enough backward compatible, I mean. Regards, Stefano
bug#13514: unintentional regression with AC_CONFIG_MACRO_DIR in 1.13.1
[+cc automake-patches] Reference: http://lists.gnu.org/archive/html/bug-automake/2013-02/msg00041.html Related ticket: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13514 On 02/08/2013 01:56 PM, Pavel Raiskup wrote: Hi Stefano, Hi Pavel, and thanks for the patches. Your work is really appreciated! [ ... ] Ping. Are you considering my opinions OK? Basically yes; and a patch would obviously be welcome, if you want to speed up the fixing of this bug ;-) First proposal attached :) (0001-*). Thanks. I've given a cursory look, and they seem generally good (apart the documentation patch); my review is below. Two meta-questions first, though: - Do you have copyright assignment paperwork for Automake in place? Your changes definitely don't qualify as trivial or very short, so I fear the paperwork is required. - In the future, if it doesn't take you too much time, could you try to send the patches in-line rather than as attachments? (You can use the excellent git send-email command for that). This would make it more convenient for reviewers to answer to your patches separately, and to quote relevant chunks from them. Thanks. Quickly again (let's say that AC_CONFIG_MACRO_DIR([m4]) is specified): a) Warn because 'aclocal -I m4' It should be just 'aclocal' here. The point of the new code is that, if you specify a directory as argument to AC_CONFIG_MACRO_DIR, you don't need to repeat it again on the aclocal command line nor in ACLOCAL_AMFLAGS anymore. This may cause problems when user wants to use gettext specify target directory on a different place than 'm4'. Such an issue should be reported to the gettext developers, and at most warned about in the gettext manual, rather than in the automake manual. We definitely want to support different directory names, if the user have reasons to use them. For these I'm attaching the 0003-* patch. I don't truly like it; see below for more details. wants to search 'm4' dir which does not exist. Ignoring this completely is imo idea; s/idea/bad idea/ here, I guess. Right? IF yes, I mostly agree. Yes - typo, sorry. To summarize: for what concerns automake, I think degrading the fatal error in aclocal to a warning is the best and safest approach for now. Improvements or re-tightening can be done later, if needed. Done. The purpose of patch 0002-* should be obvious from its description. It seems clear enough to me. Thanks. Patches are generated against 1.13.2 branch. Good choice. Pavel = === PATCH [1/3] = Subject: [PATCH 1/3] maint: Warn only if primary -Idir directory does not exist Style: we use only one space after the colon, and don't upper-case the first word after it. Also, the word before the semicolon should refer to the area/tool touched by the patch; so, in this case, the summary line should be: aclocal: just warn if the primary local m4 dir doesn't exist (no hard error) Finally, since this series has an associated entry in the bug tracker, it would be nice to reference it in your commit message: Related to automake bug#13514 The same holds for the other patches. Every bootstrapping process which does not need to have the target macro s/target/local/ IMO. directory existing in version control system (because it does not have any user-defined macros) would fail during autoreconf -vfi phase if the AC_CONFIG_MACRO_DIRS([m4]) is specified (to force tools to use 'm4' as target directory and to instruct aclocal to look into this directory): What about this instead? (to force tools like 'autopoint' and 'libtoolize' to use 'm4' as the local directory where to install definitions of their m4 macros, and to instruct aclocal to look into it): autoreconf: Entering directory `.' autoreconf: running: aclocal --force aclocal: error: couldn't open directory 'm4': No such file or directory autoreconf: aclocal failed with exit status: 1 The problem is that when the aclocal is run for the first time during autoreconf, the directory 'm4' does not exist yet. It will be created by e.g. by 'libtoolize' later on. During the second run (after libtoolize), the 'm4' directory exists and aclocal does not complain anything. That trailing anything seems superfluous; I'd just remove it. For that reason, we degrade the error to warning only s/warning only/a simple warning/ (when the --install option is not passed). This sentence is confusing, since it gives the impression that the fatal error will still be present in this case, while the reality is that not even a warning will be given. I'd just remove it. The warning is quite useful for running aclocal by hand - so not removing completely. s/not removing/we are not removing/ perhaps? See: http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html http://lists.gnu.org/archive/html/automake-patches/2010-02/msg00030.html Thanks for digging out these
Re: bug#13514: unintentional regression with AC_CONFIG_MACRO_DIR in 1.13.1
[+cc automake-patches] Reference: http://lists.gnu.org/archive/html/bug-automake/2013-02/msg00041.html Related ticket: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13514 On 02/08/2013 01:56 PM, Pavel Raiskup wrote: Hi Stefano, Hi Pavel, and thanks for the patches. Your work is really appreciated! [ ... ] Ping. Are you considering my opinions OK? Basically yes; and a patch would obviously be welcome, if you want to speed up the fixing of this bug ;-) First proposal attached :) (0001-*). Thanks. I've given a cursory look, and they seem generally good (apart the documentation patch); my review is below. Two meta-questions first, though: - Do you have copyright assignment paperwork for Automake in place? Your changes definitely don't qualify as trivial or very short, so I fear the paperwork is required. - In the future, if it doesn't take you too much time, could you try to send the patches in-line rather than as attachments? (You can use the excellent git send-email command for that). This would make it more convenient for reviewers to answer to your patches separately, and to quote relevant chunks from them. Thanks. Quickly again (let's say that AC_CONFIG_MACRO_DIR([m4]) is specified): a) Warn because 'aclocal -I m4' It should be just 'aclocal' here. The point of the new code is that, if you specify a directory as argument to AC_CONFIG_MACRO_DIR, you don't need to repeat it again on the aclocal command line nor in ACLOCAL_AMFLAGS anymore. This may cause problems when user wants to use gettext specify target directory on a different place than 'm4'. Such an issue should be reported to the gettext developers, and at most warned about in the gettext manual, rather than in the automake manual. We definitely want to support different directory names, if the user have reasons to use them. For these I'm attaching the 0003-* patch. I don't truly like it; see below for more details. wants to search 'm4' dir which does not exist. Ignoring this completely is imo idea; s/idea/bad idea/ here, I guess. Right? IF yes, I mostly agree. Yes - typo, sorry. To summarize: for what concerns automake, I think degrading the fatal error in aclocal to a warning is the best and safest approach for now. Improvements or re-tightening can be done later, if needed. Done. The purpose of patch 0002-* should be obvious from its description. It seems clear enough to me. Thanks. Patches are generated against 1.13.2 branch. Good choice. Pavel = === PATCH [1/3] = Subject: [PATCH 1/3] maint: Warn only if primary -Idir directory does not exist Style: we use only one space after the colon, and don't upper-case the first word after it. Also, the word before the semicolon should refer to the area/tool touched by the patch; so, in this case, the summary line should be: aclocal: just warn if the primary local m4 dir doesn't exist (no hard error) Finally, since this series has an associated entry in the bug tracker, it would be nice to reference it in your commit message: Related to automake bug#13514 The same holds for the other patches. Every bootstrapping process which does not need to have the target macro s/target/local/ IMO. directory existing in version control system (because it does not have any user-defined macros) would fail during autoreconf -vfi phase if the AC_CONFIG_MACRO_DIRS([m4]) is specified (to force tools to use 'm4' as target directory and to instruct aclocal to look into this directory): What about this instead? (to force tools like 'autopoint' and 'libtoolize' to use 'm4' as the local directory where to install definitions of their m4 macros, and to instruct aclocal to look into it): autoreconf: Entering directory `.' autoreconf: running: aclocal --force aclocal: error: couldn't open directory 'm4': No such file or directory autoreconf: aclocal failed with exit status: 1 The problem is that when the aclocal is run for the first time during autoreconf, the directory 'm4' does not exist yet. It will be created by e.g. by 'libtoolize' later on. During the second run (after libtoolize), the 'm4' directory exists and aclocal does not complain anything. That trailing anything seems superfluous; I'd just remove it. For that reason, we degrade the error to warning only s/warning only/a simple warning/ (when the --install option is not passed). This sentence is confusing, since it gives the impression that the fatal error will still be present in this case, while the reality is that not even a warning will be given. I'd just remove it. The warning is quite useful for running aclocal by hand - so not removing completely. s/not removing/we are not removing/ perhaps? See: http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html http://lists.gnu.org/archive/html/automake-patches/2010-02/msg00030.html Thanks for digging out these
Re: AM_MAINTAINER_MODE
On 02/08/2013 01:40 PM, Diego Elio Pettenò wrote:
On 08/02/2013 13:26, Stefano Lattarini wrote:
But maintainer-mode won't help you here; it will just cause make to ignore
some remake rules that require maintainer tools, so you are *more* likely
to end up with a subtly and silently broken package (or at least one that
is in an inconsistent state). No?
Definitely not inconsistent: it'll be consistently messed up in the same
way.
(Aside: No it doesn't; if a package has been bootstrapped with 1.9.x,
it will call automake-1.9 and aclocal-1.9 in the rebuild rules,
ensuring the correct versions are used, or that the remake fails if
those versions are not available).
Sometimes, sometimes not. I've seen it happen, especially for older
automakes.
Ah, if you go back to automake 1.4, then you're right; the versioned
binaries where introduced in the 1.4 - 1.6 transition exactly to
prevent this kind of problem from then on.
I think it might have something to do on whether they were
built with a suffix or not, when they made the dist.
No, this shouldn't have any influence; the generated rebuild rules invoke
$(AUTOMAKE), and that (unless overridden at configure or make runtime),
defaults to automake-${APIVERSION} (i.e., automake-1.11 for Automake
1.11.x, automake-1.12 for Automake 1.12.x, etc).
But if the patch legitimately modified some Makefile.am, then you are
as much as screwed if you do not re-bootstrap with the autotools in a
controlled fashion nor have the automatic remake rules kick in: the
Makefile will not be regenerated, which might cause build errors (in
the best scenario) or leave the built package in an inconsistent
state.
Again, the consistency issue is the other way from what you think: if it
always fails, and the patch to Makefile.am always get ignored, it's much
more consistent than it sometimes sticking, and sometimes not. For a
distribution packager that has to troubleshoot errors, that consistency
is gold.
OK, I now get what your use case is. And it's a valid one. But I still
think that such timestamp issues due to the patching of generated files
should be dealt with by the one doing the patching (be it a program or a
person).
But still, it is conceptually wrong, because it suggests that having
incompletely specified dependencies is a legitimate way to avoid
potentially useless rebuilds due to issues in other tools.
It's conceptually wrong that I need to fix every other package because
upstream ignores most of the best practices ever said about development,
but I still have to deal with it.
We have a split here: you want a perfect world where nothing that is
conceptually wrong exists; I live in a world where conceptually wrong is
daily bread and I want a weapon against time waste.
But OTOH, I certainly do not want to encourage any new use of it: unless
I'm still missing something fundamental here, AM_MAINTAINER_MODE is
basically an hack to work around suboptimal practices or brokenness
in other tools, and we should work toward fixing those rather than
offering brittle workarounds.
If that's what you want, fine. Do know that I _will_ fiercely suggest to
developers to use AM_MAINTAINER_MODE([enable]) in their configure.ac.
If that's what you want; I will *not* flag AM_MAINTAINER_MODE for
potential removal, nor make plans to remove it, so you can rely on
its presence now and in the future. But I might discourage it more
prominently in the documentation in the not-so-far future (also,
while I don't plan to add runtime warnings for the time being, that
might change in the quite-far future).
It does not make a change by default, but it allows us to have a
reproducible build, which is what we really need.
Regards,
Stefano
Re: bug#13524: Improving user experience for non-recursive builds
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
Re: bug#13524: Improving user experience for non-recursive builds
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
Re: AM_MAINTAINER_MODE
On 02/08/2013 12:37 AM, Diego Elio Pettenò wrote: On 07/02/2013 19:47, Stefano Lattarini wrote: So you want to allow users to disable maintainer-mode rules in every package? Yes. Where users here is distribution packagers. Better risk an extra rebuild than to miss a required one IMVHO. Or understand why timestamps get mangled, and fix that problem instead of its symptoms (i.e., unnecessary rebuilds, in this case). Yes and no. In some cases, the problem we get is that the rebuild only happens in some circumstances, and thus the developer is missing it, but it happens on the users' systems, and then they report a bug that we can't reproduce... Basically, I want to have a build failure rather than a build that might be wrong. But maintainer-mode won't help you here; it will just cause make to ignore some remake rules that require maintainer tools, so you are *more* likely to end up with a subtly and silently broken package (or at least one that is in an inconsistent state). No? I failed to understand what you're saying here, sorry. Care to rephrase, or give an example? I don't have an example at hand, but let's say this: - you got a package that for whatever reason is completely messed up if generated with automake-1.12, but works fine with 1.9; - when I'm rebuilding it as part of an ebuild (Gentoo's spec files equivalent, give or take), I declare WANT_AUTOMAKE=1.9; - but I'm not rebuilding it in the ebuild; - until I get a patch that I don't check thoroughly and messes up the timestamps; - I still do not rebuild autotools in a controlled fashion; - automake triggers the rebuild, and rebuilds with 1.12; (Aside: No it doesn't; if a package has been bootstrapped with 1.9.x, it will call automake-1.9 and aclocal-1.9 in the rebuild rules, ensuring the correct versions are used, or that the remake fails if those versions are not available). - I'm screwed. But if the patch legitimately modified some Makefile.am, then you are as much as screwed if you do not re-bootstrap with the autotools in a controlled fashion nor have the automatic remake rules kick in: the Makefile will not be regenerated, which might cause build errors (in the best scenario) or leave the built package in an inconsistent state. Variations can happen if for instance the configure relies on a variable that is not declared with AC_ARG_VAR (way too common). Yes, it's all solvable with more attention to details and similar, but since we care for stuff to at least behave, --disable-maintainer-mode is much nicer _to us_. But still, it is conceptually wrong, because it suggests that having incompletely specified dependencies is a legitimate way to avoid potentially useless rebuilds due to issues in other tools. Now, I understand that AM_MAINTAINER_MODE has been there for so long, and its use widespread enough, that I cannot remove it without upsetting a huge number of people and breaking a lot of packages, no matter how long a deprecation period I use; so it will stay with us -- you don't need to worry about that. But OTOH, I certainly do not want to encourage any new use of it: unless I'm still missing something fundamental here, AM_MAINTAINER_MODE is basically an hack to work around suboptimal practices or brokenness in other tools, and we should work toward fixing those rather than offering brittle workarounds. Regards, Stefano
bug#13524: Improving user experience for non-recursive builds
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
Re: [FYI] {branch-1.13.2} NEWS: we no longer plan to drop $(INCLUDES) support in next major version
Hi Diego. On 02/07/2013 01:09 AM, Diego Elio Pettenò wrote: On 03/02/2013 20:28, Stefano Lattarini wrote: And note that support for INCLUDES has not been re-introduced in the master branch yet, at the moment of writing; but we plan to definitely do so before the next major release. Stefano, just to be clear (so I can actually update my forward porting notes as well), INCLUDES is still considered deprecated, right? Is it going to trigger a warning? Yes, that is my intention. Thanks, Stefano
Re: bug#13524: Improving user experience for non-recursive builds
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
Re: bug#13524: Improving user experience for non-recursive builds
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
Re: bug#13524: Improving user experience for non-recursive builds
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
Re: [FYI] {branch-1.13.2} NEWS: we no longer plan to drop $(INCLUDES) support in next major version
Hi Diego. On 02/07/2013 01:09 AM, Diego Elio Pettenò wrote: On 03/02/2013 20:28, Stefano Lattarini wrote: And note that support for INCLUDES has not been re-introduced in the master branch yet, at the moment of writing; but we plan to definitely do so before the next major release. Stefano, just to be clear (so I can actually update my forward porting notes as well), INCLUDES is still considered deprecated, right? Is it going to trigger a warning? Yes, that is my intention. Thanks, Stefano
Re: serial-tests option and backwards compatibility
On 02/05/2013 12:22 AM, Peter Johansson wrote: On 02/04/2013 11:31 PM, Stefano Lattarini wrote: On 02/04/2013 01:16 AM, Luke Mewburn wrote: [CUT] Especially when the time between previous major releases was 2.5 years. Examining the Changelog and release dates: [Aside: note that the ChangeLog is not really faithful w.r.t. Automake actual development, since the dates in there fails to account for topic branches or commits that get merged weeks or even months after having been written]. 2009-12-08 Release automake 1.11.1 2012-02-21 Add serial-tests support (in HEAD) 2012-04-13 Release automake 1.11.5 (without serial-tests) 2012-05-18 Parallel tests now the default (in HEAD, not 1.11.x) 2012-06-01 Release automake 1.12.1 (with serial-tests) When I did this, I should really have published a 1.11.x release offering this same option as well; that would have removed all confusion. Sigh, such a low-hanging fruit not picked :-( I disagree. IMVHO micro releases should only fix bugs and not introduce new features, I agree, but this wouldn't have been the case; 'serial-tests' would have just been recognized as a no-op option (as it is in 1.12), to enhance forward compatibility. i.e., versions within 1.11.x should be both back and forward compatible. And it would have been so -- better than now! The way to avoid these problems would have been to let the fruit sit there for, say 3-5 years, and then change the default value. Indeed (which is just what I've before admitted has been my mistake). 2013-01-01 Release automake 1.13.1 (parallel tests now default) This isn't the only backwards incompatible change made recently, and in my humble opinion I think the timeframes introducing backwards incompatibility are too aggressive. You are not the only one to think so, and I've come to agree (at least partially); for some more discussions and background, see: http://lists.gnu.org/archive/html/automake/2013-02/msg1.html http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578 So things should proceed more carefully in the future (I hope). In hindsight, I'm surprised no one objected to your aggressive changes. From a backwards-compatibility point of view, I think the default should be reverted to serial tests, and make it clearer that parallel tests are available as an option. With this I must disagree, sorry. I agree with your disagreement ;) flip-flopping back and forth would cause complete confusion and chaos. It would, however, be useful to document a workaround (perhaps in FAQ) I fear we don't have FAQs; the closest thing is the Autotools Mythbuster guide from Diego Elio Pattenò: http://www.flameeyes.eu/autotools-mythbuster/ Perhaps you might want to bring the issue up there (and I guess Diego would welcome a patch ;-) how to support serial-test using both Automake 1.11 and Automake 1.13. Is there such a workaround? Yes, albeit not particularly pretty: http://lists.gnu.org/archive/html/automake/2013-01/msg00060.html At this point, I'd rather encourage a switch to Automake 1.12 or later (especially considering that Automake 1.12 had far few backward compatibility issues than 1.13), or (if there is a *strong* demand) release a forward-compatibility-fixing 1.11.7 release that will accept the 'serial-tests' option as a no-op. Regards, Stefano
Re: Inconsistencies in boolean parameters
On 02/07/2013 03:06 PM, Diego Elio Pettenò wrote: While working on my guide, I've noticed that there is an inconsistency with the way boolean parameters are passed. AM_MAINTAINER_MODE expects [enable] to be on-by-default. (Side note: using AM_MAINTAINER_MODE these days is generally a bad idea IMHO; we should find a way to deprecate its usage in documentation, and eventually start warning at runtime if it is used -- and don't worry, with *no* plans for a later removal!) AM_SILENT_RULES expects [yes] to be on-by-default. Indeed, using 'enable' instead of 'yes' and 'disable' instead of 'no' would be (marginally) clearer, and more consistent with the implied command line of configure (which accepts the options '--enable-silent-rules' and '--disable-silent-rules'). Maybe it's something to keep in mind for future cleanups to accept both forms, and normalize the documentation? Sure, why not. As usual, in the meantime, patches are welcome. Thanks, Stefano
Re: AM_MAINTAINER_MODE
On 02/07/2013 06:17 PM, Diego Elio Pettenò wrote: On 07/02/2013 16:18, Stefano Lattarini wrote: (Side note: using AM_MAINTAINER_MODE these days is generally a bad idea IMHO; we should find a way to deprecate its usage in documentation, and eventually start warning at runtime if it is used -- and don't worry, with *no* plans for a later removal!) I would argue that it would be nice to have AM_MAINTAINER_MODE([enable]) as default (and that's what I'm going to suggest on my documentation. So you want to allow users to disable maintainer-mode rules in every package? The reason is that while it makes total sense for developers and users alike, it's a pain for package maintainers, as sometimes timestamps end up mangled by patches, and we get unexpected maintainer-mode rebuilds... Better risk an extra rebuild than to miss a required one IMVHO. Or understand why timestamps get mangled, and fix that problem instead of its symptoms (i.e., unnecessary rebuilds, in this case). especially for source-based distribution like Gentoo, we have to be wary about maintainer mode as it would make different users end up with different versions of the build system... I failed to understand what you're saying here, sorry. Care to rephrase, or give an example? Thanks, Stefano
bug#13524: Improving user experience for non-recursive builds
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
bug#13524: Improving user experience for non-recursive builds
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
bug#13524: Improving user experience for non-recursive builds
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
