[PATCH] Add func_append_quoted and do inline func_append substitutions.
Looking through the XSI substitutions, or more correctly the bash/ksh
func_append usage, there's room here to consistently use func_append
everywhere to make for easier maintenance... but rather than take the
additional overhead of a function call in the sensitive quadratic scaling
parts that prompted the introduction of the += idiom in the first place:
use the libtool rewriting machinery to substitute inline `+=' where
possible, with a fallback to the earlier longhand otherwise.
Okay to push?
* libtool/config/ltmain.m4sh: Replace all occurrences of
`foo="$foo bar"' with func_append. No decorator comment was
added since /func_append [a-zA-Z0-9_]* "/ is already an
excellent match regexp, and additional comments would only
complicate things.
(func_append_quoted): New function that quotes a value with
func_quote_for_eval before appending it. To avoid quoting the
whitespace in the passed value, a single whitespace is added
automatically. Changed callers where possible.
* libtool/m4/libtool.m4 (_LT_PROG_XSI_SHELLFNS): Perform an
`+=' implementation substitution for func_append_quoted. More
importantly, systematically replace matching func_append calls
with inline `+=' when supported (for maximum speed), and
longhand `foo="$foo bar"' otherwise to avoid the function
overhead.
---
ChangeLog | 17 ++
libltdl/config/ltmain.m4sh | 455 ++--
libltdl/m4/libtool.m4 | 17 ++
3 files changed, 263 insertions(+), 226 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index cf3af83..298058d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,22 @@
2010-06-28 Gary V. Vaughan
+ Add func_append_quoted and do inline func_append substitutions.
+ * libtool/config/ltmain.m4sh: Replace all occurrences of
+ `foo="$foo bar"' with func_append. No decorator comment was
+ added since /func_append [a-zA-Z0-9_]* "/ is already an
+ excellent match regexp, and additional comments would only
+ complicate things.
+ (func_append_quoted): New function that quotes a value with
+ func_quote_for_eval before appending it. To avoid quoting the
+ whitespace in the passed value, a single whitespace is added
+ automatically. Changed callers where possible.
+ * libtool/m4/libtool.m4 (_LT_PROG_XSI_SHELLFNS): Perform an
+ `+=' implementation substitution for func_append_quoted. More
+ importantly, systematically replace matching func_append calls
+ with inline `+=' when supported (for maximum speed), and
+ longhand `foo="$foo bar"' otherwise to avoid the function
+ overhead.
+
Add an XSI replacement for func_split_short_opt, with test cases.
* libltdl/config/getopt.m4sh (m4go_shortnoargs): Remove 'v' now
that getopt.m4sh doesn't steal that letter for the --version
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 217643d..46a8aa3 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -156,6 +156,14 @@ func_append ()
eval "${1}=\$${1}\${2}"
} # func_append may be replaced by XSI optimised implementation
+# func_append_quoted var value
+# Quote VALUE and append to the end of shell variable VAR.
+func_append_quoted ()
+{
+func_quote_for_eval "${2}"
+eval "${1}=\$${1} \$func_quote_for_eval_result"
+} # func_append_quoted may be replaced by XSI optimised implementation
+
# func_arith arithmetic-term...
func_arith ()
@@ -364,24 +372,24 @@ M4SH_GETOPTS(
;;
esac],
[], [--no-silent|--no-quiet], [false],[
- preserve_args="$preserve_args $opt"],
+ func_append preserve_args " $opt"],
[], [--no-verbose], [false],[
- preserve_args="$preserve_args $opt"],
+ func_append preserve_args " $opt"],
[], [--silent|--quiet], [], [
- preserve_args="$preserve_args $opt"
+ func_append preserve_args " $opt"
opt_verbose=false],
[v], [--verbose],[], [
- preserve_args="$preserve_args $opt"
+ func_append preserve_args " $opt"
opt_silent=false],
[!], [--tag],[], [
- preserve_args="$preserve_args $opt $optarg"
+ func_append preserve_args " $opt $optarg"
func_enable_tag "$optarg"],
[
# save first non-option argument
nonopt="$opt"; shift
# preserve --debug
- $opt_debug && preserve_args="$preserve_args --debug"
+ $opt_debug && func_append preserve_args " --debug"
case $host in
*cy
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
Hallo Ralf,
Thanks for the review.
On 27 Jun 2010, at 19:02, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Sun, Jun 27, 2010 at 12:58:03PM CEST:
>> Okay to push?
>
> No, ${parameter:offset} and ${parameter:offset:length} are bash specific
> not XSI mandated.
Ah, okay. Didn't think to look that up. Nice catch.
> IIRC we already have a separate test for bash
> features that won't regress on non-bash XSI shells. Please add the test
> there.
I guess you were referring to the += feature test. I decided instead
to make a separate new ${foo:n:m} test alongside in case we ever encounter
a shell that supports one but not the other.
> Then, the patch is ok if you have ensured that our testsuite
> covers the code path (i.e., tries a short option that needs splitting
> this way) or added it there,
I hadn't checked the short option splitting, but during the process of
writing the test uncovered (and fixed) a small bug. Good call. Thanks.
> help.at would be a good place.
Instead, I created a new getopt-m4sh.at file, since I should really get
around to writing some unit tests for the other features of getopt.m4sh
as well as just the option splitting. I'll add them to this new file
with additional patches later on.
> And tested
> on one system that has a good shell and one that has a bad shell.
Done. Passed. And pushed!
>> * libltdl/m4/libtool.m4 (_LT_CHECK_SHELL_FEATURES): Also ensure
>> that XSI substring extraction is supported.
>> (_LT_PROG_XSI_SHELLFNS): Use XSI substring extraction to split
>> short options to avoid unnecessary forks if the host shell
>> supports that.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)
Hi Chuck,
Thanks for persevering with the Windows support in Libtool.
Regarding our patch review process, I honestly find the tough reviews
valuable in keeping up the quality of my patches, not least because it
makes me more careful not to leave loose ends in my submissions.
Nevertheless, please do remember that it is a *review*, and if you find
yourself disagreeing with something (excepting an outright veto of course),
Ralf and I are both acutely aware that you are the one doing the work on
these patches and the last thing we want to do is retard the progress of
Libtool on Windows, so please don't be afraid to say "on balance, I'd
rather see this patch move Libtool forward in some small way without
addressing issue X right now". Often, we'll concede in exchange for a
TODO item! :)
On 28 Jun 2010, at 13:10, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Mon, Jun 28, 2010 at 12:05:40AM CEST:
>> On 6/27/2010 4:43 PM, Ralf Wildenhues wrote:
>>> * Charles Wilson wrote on Sun, Jun 27, 2010 at 02:51:21PM CEST:
>>>> I tried to use Gary's _LT_PROG_XSI_REPLACE function, but using a sed
>>>> script to create a sed script and all the quoting nightmares just made
>>>> my head hurt. So, I have _LT_PROG_FUNCTION_REPLACE that uses the old
>>>> 'copy half the script, emit the new function content, copy the rest of
>>>> the script' algorithm.
>>>
>>> I don't see this method as the new method of choice. We already have a
>>> mechanism for years to transport values to the libtool script with
>>> _LT_DECLs and _LT_TAGDECLs, and at least for small code snippets,
>>
>> Yeah, that's the problem.
I wrote _LT_DECL and _LT_TAGDECL to propagate shell variable declarations to
the libtool script, and I fear it will behave badly if we try to use that
mechanism for shoehorning anything else through, especially because it works
by doing a *lot* of booking-keeping at m4 time.
_LT_PROG_XSI_REPLACE is designed for swapping out fallback implementations
of full functions (suitably decorated) for more efficient implementations
based on the build-time environment. I think that is exactly what you're
trying to do, but it seems to me like you might be able to work more
effectively in reverse: by putting the full Windows required implementations
into ltmain.m4sh, and using _LT_PROG_XSI_REPLACE to replace them with
stubs when configure is not building on (or for!!) a Windows machine?
(At that point, we should come up with a better name, and changing the
decorator strings to match. The "XSI" is already a misnomer now that I'm
using it for `+=' and ${foo:n:m} constructions.)
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
Hi Eric,
Thanks for the feedback!
On 29 Jun 2010, at 05:37, Eric Blake wrote:
> On 06/28/2010 04:19 PM, Ralf Wildenhues wrote:
>> * Eric Blake wrote on Mon, Jun 28, 2010 at 02:49:40PM CEST:
>>> tmp=${1#?}
>>> patt=
>>> i=2
>>> while test $i -lt ${#1}; do
>>> patt="?$patt"
>>
>> If the parameter may be expected to be very long (which I don't think it
>> will be) then
>> func_append patt '?'
>>
>> would be useful here, and even if not, appending rather than prepending
>> here helps with current bash.
>>
>>> i=$((i+1))
I think we can't rely on the availability of $((expr)) :(
>>> done
>>> result=${tmp%$patt}
>
> After thinking a bit more, this alternative should do the same job in
> fewer lines of code and fewer temporary variables:
>
> result=${1#?}
> while test ${#result} -gt 1; do
> result=${result%?}
> done
>
> Also, you have to be a bit careful:
> $ tmp=a
> $ echo ${tmp:2}
>
> $ echo ${tmp#??}
> a
>
> that is, before trying to split off the first two bytes using XSI, you
> must ensure that ${#1} has at least two bytes to be split in the first
> place.
Well, really the problem is this:
while $# -gt 0; do
opt=$1; shift
case $opt in
-p) opt_p="$1"; shift ;;
-q) opt_q="$1"; shift ;;
-x) opt_x=: ;;
-y) opt_y=: ;;
-p*|-q*) # option args
func_split_short_arg $opt
set dummy $arg "$rest" ${1+"$@"}; shift ;;
-x*|-y*) # non-option args
func_split_short_arg $opt
set dummy $arg -$rest ${1+"$@"}; shift ;;
esac
done
So, we know there will always be at least 3 characters available in $1
by the time we reach func_split_short_arg. Also we don't really discard
the leading '-'. Which means that this works correctly:
func_split_short_arg ()
{
arg="$1"; while test ${#arg} -gt 2; do arg="${arg%?}"; done
rest=${1%??}
}
However, I think that will be considerably slower than the ${1:0:2}/${1:2}
approach. But we're probably talking microseconds... so I'm open to
advice on whether to use bash/ksh variable substrings exclusively (as per
current master); XSI exclusively (although we make heavy use of += already
if it is available, so not really exclusively); or to prefer substring
syntax over the XSI syntax if either or both are available, falling back
on sed if necessary?
We also need to keep in mind that we plan to migrate at least the core of
the option processing code generation into Autoconf after 2.66, and I
haven't yet figured out how to generalize the function substitution to
apply to all M4SH_GETOPTS clients when that happens (Libtool master
currently hardcodes just the libtool script for function substitution,
with everything else using just the sed fallback implementations).
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
Hi Paolo,
On 29 Jun 2010, at 15:21, Paolo Bonzini wrote:
> On 06/29/2010 08:52 AM, Gary V. Vaughan wrote:
>> func_split_short_arg ()
>> {
>> arg="$1"; while test ${#arg} -gt 2; do arg="${arg%?}"; done
>> rest=${1%??}
>> }
>
> What about
>
> func_split_short_arg () {
> rest=${1#??};
> arg=${1%"$rest"};
> }
Perfect! I amended libtool.m4 and pushed, many thanks.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
Hi Eric,
On 29 Jun 2010, at 21:03, Eric Blake wrote:
> On 06/29/2010 12:52 AM, Gary V. Vaughan wrote:
>>>>> i=$((i+1))
>>
>> I think we can't rely on the availability of $((expr)) :(
>
> Is there any shell that supports XSI but not $(()), seeing as how both
> are mandated by POSIX? But we've already come up with better
> alternatives, so this is a moot point.
I have no idea, but you make a good point. Currently libtool is testing
for every non-basic feature it uses - which is still a giant leap forward
from just a few years ago where we were still afraid to use functions!
>> However, I think that will be considerably slower than the ${1:0:2}/${1:2}
>> approach. But we're probably talking microseconds... so I'm open to
>> advice on whether to use bash/ksh variable substrings exclusively (as per
>> current master); XSI exclusively (although we make heavy use of += already
>> if it is available, so not really exclusively); or to prefer substring
>> syntax over the XSI syntax if either or both are available, falling back
>> on sed if necessary?
>
> Ultimately, I'd like to fix m4sh to make it easier to probe/require XSI
> support, but that will have to wait until after autoconf 2.66.
While that might turn out to be useful elsewhere (I wrote a quick esyscmd
to check for the things that Libtool needs, so it's not difficult in
principle), it's not useful for Autotools as things stand right now, since
m4sh generally runs on the developers machine to generate scripts that are
shipped and executed on the user's shell.
It might be nice if a future Autotools does the m4sh->sh generation from
some AC_macros that expand at distribution time but are still executed on
the user's machine - but then we are requiring that the user have modern
GNU m4 available, which might not be smart.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
Hallo Ralf,
On 30 Jun 2010, at 01:22, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 05:09:29PM CEST:
>> On 29 Jun 2010, at 21:03, Eric Blake wrote:
>>> Ultimately, I'd like to fix m4sh to make it easier to probe/require XSI
>>> support, but that will have to wait until after autoconf 2.66.
>>
>> While that might turn out to be useful elsewhere (I wrote a quick esyscmd
>> to check for the things that Libtool needs, so it's not difficult in
>> principle), it's not useful for Autotools as things stand right now, since
>> m4sh generally runs on the developers machine to generate scripts that are
>> shipped and executed on the user's shell.
>>
>> It might be nice if a future Autotools does the m4sh->sh generation from
>> some AC_macros that expand at distribution time but are still executed on
>> the user's machine - but then we are requiring that the user have modern
>> GNU m4 available, which might not be smart.
>
> I think m4sh can simply use code like
>
> if ( eval '$smart_works' ) >/dev/null 2>&1; then
>func_foo () { smart code; }
> else
>func_foo () { safe code; }
> fi
>
> for code run a handful of times, without need for extra m4 magic, it's
> just that libtool is easily run hundreds of times in a typical large
> software build so it warrants optimization.
In that case might the retarded shell choke and die as it parses 'smart
code;'?
I don't actually know whether retarded shells mostly ignore the code
during parsing, and can be reliably fed what they would otherwise consider
garbage as long they are never instructed to execute the garbage... but
it seems like something we'd need to be very careful about.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Re: libtool head fails under Solaris 10 & FreeBSD
Hi Bob, On 30 Jun 2010, at 01:40, Bob Friesenhahn wrote: > As a heads-up, yesterday libtool was passing the normal number of tests > (usually fails 2) under Solaris 10. With latest changes from today, libtool > tests are failing badly: > > > 26 of 53 tests failed > (53 tests were not run) > Please report to bug-libt...@gnu.org > I can't reproduce this one. But that might be something to do with the fix I just committed... > Usually the test suite works perfectly under FreeBSD 8.0 but it is failing 3 > tests now: > > > 3 of 96 tests failed > (10 tests were not run) > Please report to bug-libt...@gnu.org > I don't have access to FreeBSD 8.0, could you retest, and show verbose logs of the fails if they haven't gone away please? Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: libtool head fails under Solaris 10 & FreeBSD
Hi Bob, On 30 Jun 2010, at 05:39, Bob Friesenhahn wrote: > On Wed, 30 Jun 2010, Gary V. Vaughan wrote: >> >> I can't reproduce this one. But that might be something to do with the fix >> I just committed... > > I am dutifully re-running the tests with your latest patch > (d8bdf9339ba7de82f40c49705650506e0cc3f979). Early impressions are that there > are far fewer failures than before under Solaris 10 but the "stress" tests > are still running. This one is still new though: > > 6: enhanced shell option appending FAILED > (getopt-m4sh.at:183) I can't reproduce. Are you sure you got a new libtool generated by this test-run? That test is copying func_append from libtool into tests/testsuite.dir/006/options and running a test to make sure that it works correctly. What does tests/testsuite.dir/006/options contain? What is the error message in tests/testsuite.dir/006/testsuite.log? Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: libtool head fails under Solaris 10 & FreeBSD
Hi Bob, On 30 Jun 2010, at 08:10, Bob Friesenhahn wrote: > but with FreeBSD 8.0: > > > 3 of 96 tests failed > (10 tests were not run) > Please report to bug-libt...@gnu.org > > > I found that the file tests/testsuite.log was from a very old run. So I > removed the build tree and did everything from scratch. No > tests/testsuite.log file was produced. This similar failure was counted > three times: > > FAIL: tests/depdemo-make.test > FAIL: tests/depdemo-make.test > FAIL: tests/depdemo-make.test Old tests results are not logged, you need to run 'VERBOSE=1 make check TESTS='prerequisite tests from the failing batch depedemo-make.test' to see what is going wrong here. If you have time to bisect your way to the commit that introduced the failure that would help narrow it down some too. I don't think the changes I've committed in the last couple of days should cause this failure, so it might have been around a little longer... Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: libtool head fails under Solaris 10 & FreeBSD
Hi Bob, On 30 Jun 2010, at 22:20, Bob Friesenhahn wrote: > On Wed, 30 Jun 2010, Gary V. Vaughan wrote: >>> >>> 6: enhanced shell option appending FAILED >>> (getopt-m4sh.at:183) >> >> I can't reproduce. >> >> Are you sure you got a new libtool generated by this test-run? That test is >> copying >> func_append from libtool into tests/testsuite.dir/006/options and running a >> test to >> make sure that it works correctly. What does >> tests/testsuite.dir/006/options contain? >> What is the error message in tests/testsuite.dir/006/testsuite.log? > > I rebuilt from scratch and get the same failure. The > tests/testsuite.dir/006/testsuite.log file is attached. > > The file tests/testsuite.dir/006/options contains 230K of code. I see a > definition for func_fatal_help 96% of the way through that file. That file is > attached as well. Ah-ha! For some reason your /bin/sh doesn't support += and my Solaris 10 machine's /bin/sh does (maybe we have some peculiar links set up to save tripping over things while package building or something?), and when the test tries to find the += enhanced func_append, the sed expression fails and ends up splicing the whole of libtool into the test :-o I've added a skip to cover that case in the last commit. Thanks for the report! Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add func_append_quoted and do inline func_append substitutions.
Hi Peter, On 2 Jul 2010, at 00:25, Peter Rosin wrote: > Den 2010-06-28 01:24 skrev Gary V. Vaughan: >> Looking through the XSI substitutions, or more correctly the bash/ksh >> func_append usage, there's room here to consistently use func_append >> everywhere to make for easier maintenance... but rather than take the >> additional overhead of a function call in the sensitive quadratic scaling >> parts that prompted the introduction of the += idiom in the first place: >> use the libtool rewriting machinery to substitute inline `+=' where >> possible, with a fallback to the earlier longhand otherwise. >> >> Okay to push? >> >> @@ -6569,7 +6572,7 @@ EOF >> *) >>case " $deplibs " in >>*" -L$path/$objdir "*) >> -new_libs="$new_libs -L$path/$objdir" ;; >> +func_append new_libs "_libs -L$path/$objdir" ;; >>esac >>;; >> esac > > This hunk is royally hosed. Oops, that'll teach me to make patches with emacs keyboard macros :*) Thanks for the fix! > 2010-07-01 Peter Rosin > > Fix regression caused by "Add func_append_quoted and do..." > * libltdl/config/ltmain.m4sh (func_mode_link): Remove leftover > "_libs" trash. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add func_append_quoted and do inline func_append substitutions.
Hi Peter, On 2 Jul 2010, at 00:38, Peter Rosin wrote: > Den 2010-06-28 01:24 skrev Gary V. Vaughan: >> Looking through the XSI substitutions, or more correctly the bash/ksh >> func_append usage, there's room here to consistently use func_append >> everywhere to make for easier maintenance... but rather than take the >> additional overhead of a function call in the sensitive quadratic scaling >> parts that prompted the introduction of the += idiom in the first place: >> use the libtool rewriting machinery to substitute inline `+=' where >> possible, with a fallback to the earlier longhand otherwise. >> >> Okay to push? >> @@ -704,15 +710,14 @@ func_mode_compile () >>save_ifs="$IFS"; IFS=',' >>for arg in $args; do >> IFS="$save_ifs" >> -func_quote_for_eval "$arg" >> -lastarg="$lastarg $func_quote_for_eval_result" >> +func_append lastarg " $arg" >>done >>IFS="$save_ifs" >>func_stripname ' ' '' "$lastarg" > > Oh, and this look suspicious... > > s/func_append/func_append_quoted/ ? Yes, please push. That'll teach me to make patches without writing an emacs keyboard macro to do the heavy lifting :*) Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [SCM] GNU Libtool branch, master, updated. v2.2.10-49-gc13532a
Hallo Ralf, On Jul 5, 2010, at 1:26 AM, Ralf Wildenhues wrote: > Hi Gary, Peter, > > * Gary V. Vaughan wrote on Sat, Jul 03, 2010 at 10:23:12AM CEST: >> On 3 Jul 2010, at 15:15, Peter Rosin wrote: >>> Fix typo in "Add func_append_quoted and do..." >>> >>> * libltdl/config/ltmain.m4sh (func_mode_compile): Use >>> func_append_quoted instead of func_append. > [...] >> In an ideal world, we'd have test coverage of this part of the >> code, > > at least after the bug was found and fixed ;-) > >> and I would never have made the bogus commit in the >> first place :( > > Oh well. So, is anyone of you working on a testsuite addition, so I'd > be doing double work? I plan to look at it eventually, and have it on my todo list to try and make a teat that covers that part of the code... But I haven't even looked at the bogus lines to analyse what is required to reach them with an appropriate test. Likely I won't get to it for at least a week, so if you see what is needed already, or want to work on the test case and fix, that is perfectly fine by me :-) Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [SCM] GNU Libtool branch, master, updated. v2.2.10-49-gc13532a
On 5 Jul 2010, at 12:36, Gary V. Vaughan wrote: > On Jul 5, 2010, at 1:26 AM, Ralf Wildenhues wrote: >> So, is anyone of you working on a testsuite addition, so I'd >> be doing double work? > > I plan to look at it eventually, and have it on my todo list to try and make > a teat ^Wtest *blush* > that covers that part of the code... But I haven't even looked at the bogus > lines to analyse what is required to reach them with an appropriate test. > Likely I won't get to it for at least a week, so if you see what is needed > already, or want to work on the test case and fix, that is perfectly fine by > me :-) Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)
Hi Chuck,
On 3 Jul 2010, at 22:34, Charles Wilson wrote:
> It's non-timely and off-point "reviews" that I tire of.
>
> The non-timely bit is just a reflection of the manpower and free time
> issues that all open source projects are subject to, so that kinda goes
> with the territory. Nobody likes it, but...you just gotta live with it.
>
> By "off-point" I mean discussing non-germane or wishlist items as part
> of a review. If the reviewer isn't VERY careful, such off-topic dicta
> can appear to imply that acceptance of a particular patch is predicated
> on solving longstanding wishlist items or software design misfeatures
> that long predate the patch in question.
>
> Most potential contributors -- myself included -- are scratching their
> own itch: X doesn't work, and I want to fix it. It's discouraging to be
> told (or THINK you are told) "we won't fix X until you or somebody else
> fixes huge, gaping, gargantuan problems Y and Z. Those problems are
> really hard to solve, and have existed for years. They are SO hard that
> none of US experts have even tried to tackle it. BUT...we won't accept
> your patch for X until somebody steps up to the plate for Y and Z"
>
> Which...sounds a whole lot like "We appreciate the submission of your
> manuscript "The Life and Times of an New York Meter Maid". However, at
> this time there are no opportunities for additional entries in our New
> York True Life book series. Thank you for your interest in Bob's
> Publishing Company, and Keep Writing!"
>
> Unless the contributor of patch X goes off to scratch YOUR itch
> regarding Y and Z. That's not the way free software contributors are
> best motivated.
>
> On 6/28/2010 3:23 AM, Gary V. Vaughan wrote:
>> Nevertheless, please do remember that it is a *review*, and if you find
>> yourself disagreeing with something (excepting an outright veto of course),
>> Ralf and I are both acutely aware that you are the one doing the work on
>> these patches and the last thing we want to do is retard the progress of
>> Libtool on Windows, so please don't be afraid to say "on balance, I'd
>> rather see this patch move Libtool forward in some small way without
>> addressing issue X right now". Often, we'll concede in exchange for a
>> TODO item! :)
>
> That's an...interesting take. I've never assumed that ANY contribution
> would be acceptable unless it received an actual approval by a
> maintainer. I mean, really: here's this patch, and no single maintainer
> has endorsed it without some significant objection -- and I should feel
> free as a non-maintainer to say "well, I disagree, so I'm pushing anyway"??
Just to clarify, that isn't what I meant -- rather, "well, I disagree, and
as you can see, despite its faults, patch X alone already makes things
less bad than they were previously. Is it okay if I push X in its current
state, and then tackle Y later? I've no inclination to work on Z, but
I'll put a reference to this thread in libtool/TODO so it isn't entirely
forgotten."
And I believe that we'll often say "sure", or "good point, go ahead".
> Maybe you mean "after a few more rounds of negotiation on the mailing
> list, maintainers may acquiesce with reservation to an un-revised
> version of particular patch"...
That too.
>> On 28 Jun 2010, at 13:10, Ralf Wildenhues wrote:
>>> * Charles Wilson wrote on Mon, Jun 28, 2010 at 12:05:40AM CEST:
>>>> On 6/27/2010 4:43 PM, Ralf Wildenhues wrote:
>>>>> I don't see this method as the new method of choice. We already have a
>>>>> mechanism for years to transport values to the libtool script with
>>>>> _LT_DECLs and _LT_TAGDECLs, and at least for small code snippets,
>>>>
>>>> Yeah, that's the problem.
>>
>> I wrote _LT_DECL and _LT_TAGDECL to propagate shell variable declarations to
>> the libtool script, and I fear it will behave badly if we try to use that
>> mechanism for shoehorning anything else through, especially because it works
>> by doing a *lot* of booking-keeping at m4 time.
>
> That's what I thought. Windows postinstall_cmds is pretty much the
> outer limit, IMO:
>
> postinstall_cmds="base_file=\\\`basename \\\${file}\\\`~
> dlpath=\\\`\$SHELL 2>&1 -c '. \$dir/'\\\${base_file}'i; echo
> \\\$dlname'\\\`~
> dldir=\$destdir/\\\`dirname \\\$dlpath\\\`~
> test -d \\\$dldir || mkdir -p \\\$dldir~
> \$install_prog \$dir/\$dlname \\\$dldir/\$dlname~
> ch
Re: MSVC: Support for response files with $NM.
Hi Peter, On 2 Jul 2010, at 19:45, Peter Rosin wrote: > Ok to push? > 2010-07-01 Ralf Wildenhues > Peter Rosin > > Support for response files with $NM. > * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS) > : New tag variable. Set it to '@' if input > files can be passed to $NM in a file named with the '@' option. > * libltdl/config/ltmain.m4sh (func_mode_link): When > nm_file_list_spec is nonempty, use it to avoid skipped_export. > * doc/libtool.texi (libtool script contents): Document > new variable. While I haven't tested (it should have no effect on the hosts I use anyway!), I read through the previous discussions. Also, by inspection, the code looks good to me, and more than 72 hours have passed without objections having been raised, so please go ahead and push! Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: MSVC: Make export.at pass
Hi Peter, On 5 Jul 2010, at 13:43, Peter Rosin wrote: > I'd like to make the "Export test" work on MSVC. > > Therefore I'm asking if I can cherry-pick commit > 89a3cdc7a57314fb3ca8f57bf47afd20809e5608 > "* tests/export.at [MSVC]: dllimport all imported variables." > into master (the patch is also attached). Looks good. Please push. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: MSVC: Preloading in ltdl doesn't heed libname_spec.
Howdy Bob, On 6 Jul 2010, at 13:19, Ralf Wildenhues wrote: > * Bob Friesenhahn wrote on Tue, Jul 06, 2010 at 06:48:56AM CEST: >> On Mon, 5 Jul 2010, Bob Friesenhahn wrote: >>> Yesterday's libtool was doing quite good with the tests but I am >>> seeing plenty of failures now for all Unixish targets. Even Linux >>> blows failures all over the place. Not to worry, it is likely >>> something simple. >> >> Perhaps things are not all that bad. While 35 of 110 tests fail >> under Debian Linux, only these two extra are failing under FreeBSD, >> OS-X, and Solaris: >> >> FAIL: tests/mdemo2-make.test >> FAIL: tests/pdemo-make.test You might want to run the new testsuite verbosely too for more context: make check TESTS= TESTSUITEFLAGS='-v' > It would probably be even more helpful if you posted verbose test > failure output (or excerpts), that would make assigning blame easier, > I guess. For the record, at this commit: 2010-07-05 Peter Rosin * tests/export.at [MSVC]: dllimport all imported variables. All tests behave as expected on Mac OS 10.6.3 (although I have no gcj or gfortran). Cheers, -- Gary V. Vaughan (g...@gnu.org)
[PATCH] Rename _LT_PROG_XSI_REPLACE macro to _LT_PROG_FUNCTION_REPLACE.
Pushed as obvious:
While it looks large, the entire patch was made with a 5-line sed script
that replaces "XSI" with "Extended shell" or similar as appropriate to
each context, followed by some manual layout cleanups and a complete run
of the testsuite.
* libltdl/m4/libtool.m4 (_LT_PROG_XSI_SHELLFNS): Rename to
_LT_PROG_REPLACE_SHELLFNS.
(_LT_PROG_XSI_REPLACE): Rename to _LT_PROG_FUNCTION_REPLACE.
(_LT_PROG_FUNCTION_REPLACE): Change decorator comment to use
'Extended shell' rather than 'XSI' on successful replacement.
* libltdl/config/general.m4sh (func_dirname, func_basename)
(func_dirname_and_basename, func_stripname): Change decorator
comment to use 'extended shell' rather than 'XSI' on fallback
implementations.
* libltdl/config/getopt.m4sh (func_split_short_opt)
(func_split_long_opt): Ditto.
* libltdl/config/ltmain.m4sh (func_append, func_append_quoted)
(func_arith, func_len, func_lo2o, func_xform): Ditto.
* tests/getopt-m4sh.at (_LT_AT_XSI_FUNC_EXTRACT): Rename to
_LT_AT_EXTENDED_SHELL_FUNC_EXTRACT.
(_LT_AT_EXTENDED_SHELL_FUNC_EXTRACT): Change regular expression to
match new replacable function decorator comments.
Signed-off-by: Gary V. Vaughan
---
ChangeLog | 19 +++
libltdl/config/general.m4sh |8 +++---
libltdl/config/getopt.m4sh |4 +-
libltdl/config/ltmain.m4sh | 12 +-
libltdl/m4/libtool.m4 | 52 +-
tests/getopt-m4sh.at|8 +++---
6 files changed, 61 insertions(+), 42 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b180dc6..acb9e2b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,24 @@
2010-07-08 Gary V. Vaughan
+ Rename _LT_PROG_XSI_REPLACE macro to _LT_PROG_FUNCTION_REPLACE.
+ * libltdl/m4/libtool.m4 (_LT_PROG_XSI_SHELLFNS): Rename to
+ _LT_PROG_REPLACE_SHELLFNS.
+ (_LT_PROG_XSI_REPLACE): Rename to _LT_PROG_FUNCTION_REPLACE.
+ (_LT_PROG_FUNCTION_REPLACE): Change decorator comment to use
+ 'Extended shell' rather than 'XSI' on successful replacement.
+ * libltdl/config/general.m4sh (func_dirname, func_basename)
+ (func_dirname_and_basename, func_stripname): Change decorator
+ comment to use 'extended shell' rather than 'XSI' on fallback
+ implementations.
+ * libltdl/config/getopt.m4sh (func_split_short_opt)
+ (func_split_long_opt): Ditto.
+ * libltdl/config/ltmain.m4sh (func_append, func_append_quoted)
+ (func_arith, func_len, func_lo2o, func_xform): Ditto.
+ * tests/getopt-m4sh.at (_LT_AT_XSI_FUNC_EXTRACT): Rename to
+ _LT_AT_EXTENDED_SHELL_FUNC_EXTRACT.
+ (_LT_AT_EXTENDED_SHELL_FUNC_EXTRACT): Change regular expression to
+ match new replacable function decorator comments.
+
Fix a cut-n-pasto in "2010-07-07 Charles Wilson" patch.
* libltdl/config/ltmain.m4sh (func_mode_link): Remove spurious
variable dereference.
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 5d7bef7..1245fe5 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -84,14 +84,14 @@ func_dirname ()
else
func_dirname_result="$func_dirname_result${2}"
fi
-} # func_dirname may be replaced by XSI optimised implementation
+} # func_dirname may be replaced by extended shell implementation
# func_basename file
func_basename ()
{
func_basename_result=`$ECHO "${1}" | $SED "$basename"`
-} # func_basename may be replaced by XSI optimised implementation
+} # func_basename may be replaced by extended shell implementation
# func_dirname_and_basename file append nondir_replacement
@@ -116,7 +116,7 @@ func_dirname_and_basename ()
func_dirname_result="$func_dirname_result${2}"
fi
func_basename_result=`$ECHO "${1}" | $SED -e "$basename"`
-} # func_dirname_and_basename may be replaced by XSI optimised implementation
+} # func_dirname_and_basename may be replaced by extended shell implementation
# func_stripname prefix suffix name
@@ -131,7 +131,7 @@ func_stripname ()
.*) func_stripname_result=`$ECHO "${3}" | $SED "s%^${1}%%;
s%${2}\$%%"`;;
*) func_stripname_result=`$ECHO "${3}" | $SED "s%^${1}%%; s%${2}\$%%"`;;
esac
-} # func_stripname may be replaced by XSI optimised implementation
+} # func_stripname may be replaced by extended shell implementation
# These SED scripts presuppose an absolute path with a trailing slash.
diff --git a/libltdl/config/getopt.m4sh b/libltdl/config/getopt.m4sh
index e9da56f..806c1d4 100644
--- a/libltdl/config/getopt.m4sh
+++ b/libltdl/config/getopt.m4sh
@@ -628,7 +628,7 @@ func_split_short_opt ()
func_split_short_opt_name=`$ECHO "$1" | $SED "$my_sed_short_opt"`
func_split_short_op
Re: [PATCH] Rename _LT_PROG_XSI_REPLACE macro to _LT_PROG_FUNCTION_REPLACE.
Hi Peter, On 9 Jul 2010, at 12:48, Peter O'Gorman wrote: > On 07/08/2010 08:27 AM, Gary V. Vaughan wrote: >> Pushed as obvious: >> >> While it looks large, the entire patch was made with a 5-line sed script >> that replaces "XSI" with "Extended shell" or similar as appropriate to >> each context, followed by some manual layout cleanups and a complete run >> of the testsuite. >> > > What was wrong with XSI? += is not an XSI feature, but I'm using these functions to switch the implementation of func_append depending on whether += is seen to work on the host shell, and Chuck Wilson is considering using these functions to swap out big cygmsyswingw-only functions for stubs on hosts that don't need the big functions. _LT_PROG_FUNCTION_REPLACE seems like a better name under these circumstances. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [SCM] GNU Libtool branch, master, updated. v2.2.10-59-g8c4dae1
On 9 Jul 2010, at 00:46, Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf, > * Gary V. Vaughan wrote on Thu, Jul 08, 2010 at 03:37:23PM CEST: >> commit 8c4dae1232958c24989f31ab5b5768d00be2ef03 >> Author: Gary V. Vaughan >> Date: Thu Jul 8 18:47:59 2010 +0700 >> >>Fix a spurious trailing space and a botched merge. >> >>* libltdl/m4/libtool.m4 (_LT_PROG_FUNCTION_REPLACE): Remove >>spurious trailing space. >>* ChangeLog: Reorder to match commit order after botched >>merge. > > Make botched ChangeLog merges a thing of the distant, easily forgotten > past by getting to know, installing and configuring git-merge-changelog, > currently distributed as a gnulib module of the same name. Be sure to > use recent git gnulib. It's really that good! I use it already... but screwed things up manually by doing a pull-merge between two commits, and git adding back the merged files without thinking it through properly. So I ended up with the bogus half-merged commit that came before the correction above. D'oh! Using git still feels to me like driving a tank after only having ever practiced with a pea-shooter... ;) Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Don't always skip XSI tests
Hi Chuck, On 26 Jul 2010, at 11:03, Charles Wilson wrote: > tests/getopt-m4sh.at: Use new signature as implemented by > de8a0992b21b76a13c302cf48588ad5f6042595c, when determining > whether to test Extended-shell functions. > --- > tests/getopt-m4sh.at |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > In the referenced commit, the signature of functions replaced > by _LT_PROG_FUNCTION_REPLACE was changed from '# XSI $function' > to '# Extended-shell $function'. Ensure that getopt-m4sh.at > tests for the correct signature, instead of always skipping the > affected tests. > > Tested on cygwin. Before, tests 2,4,6 were skipped. After, they > are no longer skipped (and they pass) since cygwin shell does > support the XSI features. > > OK to commit? Gah! I could have sworn I'd changed that file too, but somehow it seems I didn't commit :( Thanks for the catch, and please push! Cheers, -- Gary V. Vaughan (g...@gnu.org)
Next Libtool Point Release Pending [Was Re: [RFT PATCH v4 0/8] Sysroot series]
On 6 Aug 2010, at 02:08, Ralf Wildenhues wrote: > You guys have done a great job so far, and I'm really trying to > not delay review; it would be sad to see this not fly just because we > talk past each other about some related questions. Which reminds me: I promised to roll a 2.2.12 release this month. But looking at the huge progress we've made so far with Windows since 2.2.10, I'm wondering if we would be better to roll 2.2.12 sooner rather than later? Or would you prefer that I wait until this patch series has been pushed first? (remember that I'm aiming at a point release every 2 or 3 months, so it will not be much of a wait until the next release rolls around). Slightly related, I wonder whether all the progress on Windows justifies calling the next release 2.4? Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: Next Libtool Point Release Pending
On 6 Aug 2010, at 11:59, Ralf Wildenhues wrote: > Hello Gary, Hallo Ralf! > * Gary V. Vaughan wrote on Fri, Aug 06, 2010 at 06:01:37AM CEST: >> I promised to roll a 2.2.12 release this month. But looking at the >> huge progress we've made so far with Windows since 2.2.10, I'm >> wondering if we would be better to roll 2.2.12 sooner rather than >> later? > > I am still looking at several regressions in git over 2.2.10, so no, > a release right now (as opposed to in a couple of weeks, hopefully) > would make me rather unhappy. > > Also, I would prefer a release with this patch series in, at least if > the series is in mergeable shape in the near future. Okay, I'll pencil in a new release for the end of August. >> Slightly related, I wonder whether all the progress on Windows >> justifies calling the next release 2.4? > > A higher number could help notify people that more new bugs have crept > in, certainly. ;-) The w32 support requires Automake support to be > really usable though, and we're still working on that. I had kinda > hoped that there could at least an Automake beta that carries that work. > > OTOH, since I hope to have more larger changes in the future, I'm not > sure we really want another major number bump already. That's only a minor bump, according to major.minor.micro: major bump => substantial rewrite minor bump => new features, new code and new bugs micro bump => regressions and bugs fixed This is the scheme I believe most people recognize, and that suggests to me that 2.4.0 would be the next logical release number? Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: Next Libtool Point Release Pending
Hi Bob, On 6 Aug 2010, at 22:30, Bob Friesenhahn wrote: > On Fri, 6 Aug 2010, Gary V. Vaughan wrote: >>> >>> OTOH, since I hope to have more larger changes in the future, I'm not >>> sure we really want another major number bump already. >> >> That's only a minor bump, according to major.minor.micro: >> >> major bump => substantial rewrite >> minor bump => new features, new code and new bugs >> micro bump => regressions and bugs fixed >> >> This is the scheme I believe most people recognize, and that suggests >> to me that 2.4.0 would be the next logical release number? > > You do make a good point. It is better to advance the minor number (rather > than continually increase the micro number) if significant new features have > been added. However, the objectives should be met (e.g. really able to build > adequately with MSVC) before we bump to 2.4. This should not discourage > including 99% of the necessary updates in another 2.2 release. Nonetheless I still think that users should have some confidence that releases get more stable as micro increases. Rolling a ton of new code into a micro bump violates that idea. In this case I should either release a 2.2.12b alpha while we wait for the new MSVC code to be "adequate" for 2.4.0, or else make a retroactive 2.2 maintenance branch at v2.2.10 in git, and back- merge fix changesets only from trunk to make stable 2.2.12 while waiting for an appropriate time to roll 2.4.0 from master. IMHO 2.4.0 from master at the end of the month (assuming no known show-stoppers at that time) is a good and proper way to inform users that there's some new code (minor+=2), and that it's not at all mature (micro=0). 2.2.12, on the other hand, misinforms users that this is a stable release with nothing important altered (major.minor unchanged), and they really should upgrade to pick up the last round of bug fixes (micro+=2). Another viable compromise might be to call the next release 2.3.0? Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add func_append_quoted and do inline func_append substitutions.
On 7 Aug 2010, at 18:15, Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf, > * Ralf Wildenhues wrote on Mon, Jun 28, 2010 at 07:34:35AM CEST: >> * Gary V. Vaughan wrote on Mon, Jun 28, 2010 at 01:24:39AM CEST: >>> Looking through the XSI substitutions, or more correctly the bash/ksh >>> func_append usage, there's room here to consistently use func_append >>> everywhere to make for easier maintenance... but rather than take the >>> additional overhead of a function call in the sensitive quadratic scaling >>> parts that prompted the introduction of the += idiom in the first place: >>> use the libtool rewriting machinery to substitute inline `+=' where >>> possible, with a fallback to the earlier longhand otherwise. >>> >>> Okay to push? >> >> OK thanks! > > I approved this patch v2.2.10-40-g0da7d80 aka. > <http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00190.html> > back then without much concern, but trying to debug libtool script > issues, and seeing users struggle with nonportable shell constructs > (even if these turn out to be user side issues later): > <http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7475> > > I'm now wondering whether we shouldn't maybe reevaluate the inline > expansion of nonportable code. The change has an unknown performance > upside and a known usability downside of needing to hack several places > rather than just one func_append instance. Has the speedup been > measured? If not, is there a chance that we can somehow agree on either > having numbers to prove that this actually helps in practice, or > otherwise reverting the inlining part of this patch? Sure. Whatever you think is best is generally fine with me. I don't see that the +=/func_append substitution is causing any additional concerns to the XSI function substitution though. The whole function substitution is really a single issue in this case, right? Either we need to work on it to the point where it will DTRT reliably, or else we should remove all of the function substitution machinery, and go back to writing portable shell everywhere. I'd rather not do that actually, but I don't have time to work on getting timings or looking at bugs right now, so I'm more than happy to leave the decision in your capable hands. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: Next Libtool Point Release Pending
Hallo Ralf, On 7 Aug 2010, at 02:02, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Fri, Aug 06, 2010 at 08:53:15PM CEST: >> Another viable compromise might be to call the next release >> 2.3.0? > > Maybe it's early enough to finalize a decision on this when we > know a bit better which patches are in, and which features can > be advertised. Okay, I'll pick this up again in a couple of weeks :) But first... > There is also our numbering scheme description on > <http://www.gnu.org/software/libtool/contribute.html>. Tx. It was good to reread that, as I was going by (several) year old memories of what I had written ;) By the reasoning I stated there, we should really have branched for 2.2 releases before adding any new features. So, if we want to release a 2.2.12, then we should make a branch at v2.2.10 and merge only fixes to it. Whether or not we decide to do that, master definitely has new features/code/bugs and should be renumbered to 2.3a until we decide to make a release from there (either 2.4 or 2.3b depending on how stable it turns out to be under pre-release testing). Unless someone disagrees, I'll make branch-2-2 at the v2.2.10 tag, merge the bug fixes since the tag into it, and bump the version number in master to 2.3a - all in a day or three. Actually, I'm open to persuasion for branching at an earlier tag and merging back all the fixes since the branch point to make for less new code in 2.2.12: although I have reservations about removing anything that was mentioned in NEWS already, because that would be rather surprising to our users. We can figure out later where to make a release from, and what to call it, at the end of the month. > Gary, any way BTW I can get you to look at > <http://lists.gnu.org/archive/html/bug-libtool/2010-08/msg4.html> > that would be lovely. I've been meaning to find time for this. I'll definitely get to it this week. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add func_append_quoted and do inline func_append substitutions.
Hallo Ralf, On 9 Aug 2010, at 12:15, Ralf Wildenhues wrote: > I think we should have a rule to not apply pure optimization patches > without measurement results. Agreed. We should document that somewhere too, so that we don't forget. Cheers, -- Gary V. Vaughan (g...@gnu.org)
[PATCH] Autotest 2.62 bug?
Hallo Ralf, The following patch makes it possible to bootstrap libtool.git master with Autoconf 2.62, though it is not necessary when using a newer Autoconf. Unfortunately I don't know my way around the innards of Autotest well enough to be able to figure out what the problem is, though with time it should be possible to bisect to the changeset that fixes it I suppose. Having said that, if it's really a bug in Autoconf 2.62, then we either need to require a newer version of Autoconf to bootstrap the Libtool testsuite, or else test and commit a variant of the following patch to work around it. Cheers, Gary --- tests/getopt-m4sh.at |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/tests/getopt-m4sh.at b/tests/getopt-m4sh.at index 768d595..914d17b 100644 --- a/tests/getopt-m4sh.at +++ b/tests/getopt-m4sh.at @@ -96,11 +96,10 @@ AT_CHECK([$SHELL ./options -fvi], 0, [expout]) AT_CLEANUP - AT_SETUP([enhanced shell short option splitting]) # Don't bother with additional XSI checks unless functions were substituted -AT_CHECK([fgrep '# Extended-shell func_split_short_opt' $abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)]) +fgrep '# Extended-shell func_split_short_opt' $abs_top_builddir/libtool >/dev/null 2>&1 || exit 77 AT_DATA(expout, [[ force verbose install @@ -134,7 +133,7 @@ AT_CLEANUP AT_SETUP([XSI long option splitting]) # Don't bother with additional XSI checks unless functions were substituted -AT_CHECK([fgrep '# Extended-shell func_split_long_opt' $abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)]) +fgrep '# Extended-shell func_split_long_opt' $abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77) AT_DATA(expout, [[ ltdl=long @@ -171,7 +170,7 @@ AT_CLEANUP AT_SETUP([enhanced shell option appending]) # Don't bother with additional += check unless functions were substituted -AT_CHECK([fgrep '# Extended-shell func_append ' $abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)]) +fgrep '# Extended-shell func_append ' $abs_top_builddir/libtool >/dev/null 2>&1 || exit 77 AT_DATA(expout, [[first --append second -- 1.7.1
Re: Next Libtool Point Release Pending
On Aug 9, 2010, at 10:38 PM, Peter O'Gorman wrote: > On 08/09/2010 12:33 AM, Gary V. Vaughan wrote: >> By the reasoning I stated there, we should really have branched >> for 2.2 releases before adding any new features. So, if we >> want to release a 2.2.12, then we should make a branch at >> v2.2.10 and merge only fixes to it. > > I don't think having a stable and development branch worked well with 1.5.x > and 2.x. It added more work for us, and did not serve our users well - they > had to wait years for the development branch's features to make it into a > released libtool. That's true, but I think that was because we tried too hard to make the 2.x branch perfect, and spent altogether too much time pumping out more and more 1.5.x releases with patches merged back from an ever diverging code base. As long as we're careful not to do any of this things, then we can avoid repeating history. > Developing new features etc. on a branch is, of course, ok, in my opinion > (having to wait several years to merge is not so good though). You make a good point. Does git offer the means to relabel the head of a branch as master? Then I can cherry-pick the bug fixes from the current master, rename it to branch-2-2, and relabel the cherry-picked branch as the new master... voilà : stable master, and feature branch for msvc :-) > I don't really care what the version number is - as long as it's greater than > the previous one :-) Then I'm still voting for 2.4.0 for a release from master :-) Cheers, -- Gary V. Vaughan (g...@vaughan.pe)
Re: How to maintain compatibility with Automake.
On 10 Aug 2010, at 15:19, Peter Rosin wrote:
> Hi!
Hi Peter,
> A macro by the name AM_PROG_AR might be on its way into Automake,
> and I would like to use it sooner rather than later. But I don't
> think it is prudent to require an Automake version which has the
> macro. Would something like this be a workable solution in
> libtool.m4 (untested, needs adjustments to _LT_CMD_OLD_ARCHIVE
> of course)?
>
> m4_ifndef([AM_PROG_AR],
>
>
> # NOTE: A macro with the same interface as this has been #
> # submitted for inclusion into GNU Automake as#
> # AM_PROG_AR. When we require an Automake version which #
> # has this macro we should remove this macro from here#
> # and use the Automake macro unconditionally. #
>
> [
> m4_defun([AM_PROG_AR],
> [AC_CHECK_TOOLS(AR, [ar], false)
> : ${AR=ar}
> AC_SUBST([AR])dnl
> ])# AM_PROG_AR
> ])
Just like that!
> Or how are situations like this generally handled?
Following, is a somewhat long-winded answer for the list archives
and the search engine indexing bots:
When I wanted to make use of modern (2.64 era) m4sugar facilities
in getopt.m4sh, but maintaining compatibility back to at least
Autoconf 2.62, I took this approach:
# m4go_expand(ARG)
#
# M4SH_GETOPTS wants to pass unbalanced parentheses to m4_expand to
# build the branches of a shell `case' statement. That is only
# supported by the implementation of m4_expand in Autoconf-2.64 and
# newer. Since we want to be compatible back to at least
# Autoconf-2.62, reimplement our own 2.64 based m4_expand in the
# m4go_ namespace so that we can be compatible with Autoconf versions
# supporting either semantic.
m4_define([m4go_expand],
[m4_chomp(_$0([$1
]))])
m4_define([_m4go_expand], [...])
However, I was worried about changing semantics between the various
releases, which is why I took a concrete implementation as a copy
of the simplest version, and renamed that into a known namespace.
By contrast, when we submitted AC_PROG_SED to Autoconf, we wrapped
the incumbent Libtool implementation in:
m4_ifndef([AC_PROG_SED], [
# NOTE: This macro has been submitted for inclusion into #
# GNU Autoconf as AC_PROG_SED. When it is available in #
# a released version of Autoconf we should remove this#
# macro and use it instead. #
m4_defun([AC_PROG_SED],
[...
])#AC_PROG_SED
])#m4_ifndef
The latter is closer to what you're aiming at, and thus I think your
proposal is perfectly fine :)
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
[PATCH] Make testsuite compatible with Autoconf 2.62 again.
Pushed to origin/master as obvious: * tests/getopt-m4sh.at (AT_CHECK): Autotest 2.62 chokes on unquoted '#' in AT_CHECK, so replace all uses with '@%:@' quadrigraph. Suggested by Eric Blake Reported by Ralf Wildenhues --- ChangeLog|8 tests/getopt-m4sh.at |6 +++--- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index b71c668..ce4c9db 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2010-08-10 Gary V. Vaughan(tiny change) + + Make testsuite compatible with Autoconf 2.62 again. + * tests/getopt-m4sh.at (AT_CHECK): Autotest 2.62 chokes on unquoted + '#' in AT_CHECK, so replace all uses with '@%:@' quadrigraph. + Suggested by Eric Blake + Reported by Ralf Wildenhues + 2010-08-09 Ralf Wildenhues Fix more problematic code from "Add func_append_quoted and do..." diff --git a/tests/getopt-m4sh.at b/tests/getopt-m4sh.at index 768d595..3e58db1 100644 --- a/tests/getopt-m4sh.at +++ b/tests/getopt-m4sh.at @@ -100,7 +100,7 @@ AT_CLEANUP AT_SETUP([enhanced shell short option splitting]) # Don't bother with additional XSI checks unless functions were substituted -AT_CHECK([fgrep '# Extended-shell func_split_short_opt' $abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)]) +AT_CHECK([fgrep '@%:@ Extended-shell func_split_short_opt' $abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)]) AT_DATA(expout, [[ force verbose install @@ -134,7 +134,7 @@ AT_CLEANUP AT_SETUP([XSI long option splitting]) # Don't bother with additional XSI checks unless functions were substituted -AT_CHECK([fgrep '# Extended-shell func_split_long_opt' $abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)]) +AT_CHECK([fgrep '@%:@ Extended-shell func_split_long_opt' $abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)]) AT_DATA(expout, [[ ltdl=long @@ -171,7 +171,7 @@ AT_CLEANUP AT_SETUP([enhanced shell option appending]) # Don't bother with additional += check unless functions were substituted -AT_CHECK([fgrep '# Extended-shell func_append ' $abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)]) +AT_CHECK([fgrep '@%:@ Extended-shell func_append ' $abs_top_builddir/libtool >/dev/null 2>&1 || (exit 77)]) AT_DATA(expout, [[first --append second -- 1.7.2.1
Re: using git Libtool with Autoconf 2.59, Automake 1.9.6
Hallo Ralf, On 21 Aug 2010, at 12:06, Ralf Wildenhues wrote: > I tried running the Libtool test suites with old Autoconf 2.59 and > Automake 1.9.6 (on GNU/Linux only) after 'autoreconf -fvi'-ing all > but the toplevel directory with those tools. I was surprised to see > that it still works more or less! :-) > > This patch fixes the fall-out. OK to push if the use of $at_status is > sanctioned? > <http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/7323> Nice catch! I have no idea about at_status, but pending that please do push. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: Tidy and fix clean and distclean rules for old testsuite.
Hallo Ralf, On 22 Aug 2010, at 11:23, Ralf Wildenhues wrote: > In the Libtool tree, invoking 'make distclean' after 'make clean' > or before 'make check' has ever run, fails because there are no > Makefiles in the old test subdirectories (and automake's distclean > rule looks at DIST_SUBDIRS not SUBDIRS). This patch fixes this > long-standing error by creating stub Makefiles, and IMHO using > minimal insider information about Automake-generated rules: > basically only the name of the 'distclean-recursive' rule, to > which we must add a prerequisite. Just adding to distclean-local > doesn't work, that gets invoked too late. > > OK to apply? Well, it is an improvement over what we have, so... sure, go ahead. However, I continue to strongly dislike the old testsuite, and would much prefer to migrate it's tests into Autotest. I understand the argument that our kludgy old tests are good for coverage of libtool with the bootstrapped autotools... but, honestly, I'd rather find out that the libtool I'm planning to install is going to fail with *my* autotools, than I would be told that the old testsuite still passes with whatever versions it happened to be bootstrapped with! Getting rid of the old testsuite was actually my motivation for starting an Autotest based testsuite in the first place; and because bootstrap and reconf issues with the old testsuite have always been (and continue to be) a real pain. > Even with this patch, 'make clean' may be very slow in the case where > the test subdirectories need reconfiguring. That is an orthogonal and > IMVHO minor issue, which I don't know how fix easily though. I do: see the first six words of my last para ;) Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: Tidy and fix clean and distclean rules for old testsuite.
Hallo Ralf, On 22 Aug 2010, at 17:29, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 06:46:55AM CEST: >> On 22 Aug 2010, at 11:23, Ralf Wildenhues wrote: >> However, I continue to strongly dislike the old testsuite, and would >> much prefer to migrate it's tests into Autotest. > > Oh. I was going to propose a patch series to convert the old testsuite > to use the parallel-tests driver. Despite the new one having grown > nicely, there are still several issues only found with the old one > (and some tests in the new one that probably need more work). > > Oh well. I think I'll still propose the patch series, since it > shouldn't make a future migration any worse. I don't intend to work > on the migration myself; I prefer spending my time on other things. Sure, a step forward is a step forward. And besides I might not find the time to work on migrating the old tests for a long while, and have a less annoying old testsuite is definitely a good thing in my book :) >> I understand the >> argument that our kludgy old tests are good for coverage of libtool >> with the bootstrapped autotools... but, honestly, I'd rather find >> out that the libtool I'm planning to install is going to fail with >> *my* autotools, than I would be told that the old testsuite still >> passes with whatever versions it happened to be bootstrapped with! > > Sure. > >> Getting rid of the old testsuite was actually my motivation for >> starting an Autotest based testsuite in the first place; and because >> bootstrap and reconf issues with the old testsuite have always been >> (and continue to be) a real pain. > > And look what the new testsuite gained us: much better test coverage! Yes indeed! > In that way I think it's a huge success even if it hasn't (yet) achieved > the goal you intended it for. :-) That's great. I could have sworn that we discussed this and reached a consensus that the old tests should stay... but a quick search through the archives didn't turn up the conversation I thought I'd remembered. I would have done the work to migrate long ago if my memory hadn't been implanted by aliens (8> I've added it to my TODO, so it should arrive here at some point in the not too distant future. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 0/6] Allow to run the old testsuite in parallel
Hallo Ralf, On 22 Aug 2010, at 17:55, Ralf Wildenhues wrote: > I've had this patch series half-done in my tree for a long time, > and have now taken the time to fix the missing bits. Do you have (or could you easily move) this on a private topic branch already? If so, please push the topic branch to a public repo to make it easier for me to test. > The old testsuite is, well, old, and unloved. But it also covers > crucial aspects, so as long as there's no rewrite, we might as well > enable some parallelism and have a decent log creation mechanism (both > through Automake 1.11's parallel-tests feature). Sounds good. As do the benefits to Windows testers that I elided from the quoted text. I'd still like to roll the next release in a week or two though. Do you think this patch series is stable enough to push just before that release? I'm leaning towards holding off until just after the release: anyone who wants to test that code can easily clone the post-release head of the master branch... and we don't run the risk of making a release that blows up for casual users in unforseen ways. WDYT? > parallel-tests requires a new Automake for building the Libtool package > itself. Users of Libtool macros should still be able to cope with > Autoconf 2.59 and Automake 1.9.6. I tested this on GNU/Linux. So, with a distribution's preinstalled libtool package, we are still able to work fully with older autotools, and the Automake 1.11.1 requirement is only for running the old testsuite? Or only for running the old testsuite in parallel? > If requiring Automake 1.11.1 is too strict, then it would be possible, > alternatively, to only enable parallel-tests iff Automake is new enough. > This would make both code and documentation a bit more complicated, so > I'm hoping that it won't be necessary. I'd like to try it out (preferably without extracting the patches from emails on my laptop, transferring them to the test servers, and applying them there) before giving the all clear. But, I think it is not worth your expending too much more effort on enhancing this series if my plan to migrate those tests to Autotest comes to fruition in the next month or two, so if I don't get back with a review in 72hrs, and if you are confident that we're not opening ourselves up to a slew of reports from casual early adopters who have trouble with the altered testsuite, then in principle I have no problem with merging. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.
Hallo Ralf, On 22 Aug 2010, at 17:56, Ralf Wildenhues wrote: > (LTDL_SUBDIR_LIBOBJS): Remove now-obsolete conditional and > feature test for Autoconf 2.59 and Automake 1.9.x workaround. > * Makefile.am: Simplify accordingly. > * bootstrap: Remove obsolete WORKING_LIBOBJ_SUPPORT workarounds > for Autoconf 2.59 and Automake 1.9.6. Earlier comments aside, I'm very happy to throw away a requirement for 7 and 5 year old Autoconf and Automake (resp) under any circumstances. So this part is good with me already! > * configure.ac (AM_INIT_AUTOMAKE): Require 1.11.1. Enable > color-tests. I'm still a little worried that the Automake 1.11.1 requirement might leak out of 'required to bootstrap' and into 'required to use' however, which is why I'd like to test it some more to convince myself that I'm just being paranoid :) I wonder whether it is possible to write a test that looks for the oldest Automake and Autoconf we declare our support for, and rerun the relevant tests with them? That would have caught several of the errors I made with the m4sh patches I submitted over the last couple of months... Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.
Hallo Ralf, On 22 Aug 2010, at 22:09, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 04:17:49PM CEST: >> I wonder whether it is possible to write a test that looks for >> the oldest Automake and Autoconf we declare our support for, >> and rerun the relevant tests with them? That would have >> caught several of the errors I made with the m4sh patches I >> submitted over the last couple of months... > > Ah, maybe a good idea. [[snip]] Thanks :) > #! /bin/sh > # Try out Libtool with oldest supported tools. > # Use this in a fresh directory. > set -e > > # consider using shallow clones here, to ease server load. > git clone git://git.sv.gnu.org/autoconf.git > git clone git://git.sv.gnu.org/automake.git We could pull the already bootstrapped release tarballs from an ftp.gnu.org mirror here instead. > git clone git://git.sv.gnu.org/libtool.git Of course, that doesn't test the patch series you haven't pushed yet... And running it as an Autotest inside the existing tree would get us better coverage, and obviate the need for a separate checkout of the libtool tree entirely. > mkdir inst > inst=`pwd`/inst > PATH=$inst/bin:$PATH > > cd libtool > reconfdirs=. ./bootstrap > > cd ../autoconf > git checkout AUTOCONF-2.59 > # autoreconf -vi needed here? > ./configure --prefix="$inst" > make all install > > cd ../automake > git checkout Release-1-9-6 > ./bootstrap > ./configure --prefix="$inst" > make all install > > cd ../libtool > reconfdirs="libltdl "`ls -d tests/*demo*/` ./bootstrap > mkdir build > cd build > ../configure --prefix="$inst" > make all > make -k check > > # Now, mail all output and logs to the autobuild site ... > # ... and consider cleaning up afterwards. The last bit of the script is missing ;) Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 0/6] Allow to run the old testsuite in parallel
On 22 Aug 2010, at 21:30, Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf! > * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 04:05:12PM CEST: >> On 22 Aug 2010, at 17:55, Ralf Wildenhues wrote: >>> I've had this patch series half-done in my tree for a long time, >>> and have now taken the time to fix the missing bits. >> >> Do you have (or could you easily move) this on a private topic branch >> already? If so, please push the topic branch to a public repo to make >> it easier for me to test. > > Done now: it's named parallel-tests. That's great. Thanks :) I'm pulling the branch now... although it will be Monday here in just over an hour, so I'll probably get some sleep before I look at it properly. >> I'd still like to roll the next release in a week or two though. Do >> you think this patch series is stable enough to push just before that >> release? > > I was definitely aiming for this release. Actually, I have one more > patch to use Autobuild, and my plan was to then get the sysroot branch > merged and then build and test Libtool in all setups I have available > and send them to the Autobuild site for reference. This parallel-tests > patch series makes it easier to submit logs of the failed tests. Okay, I'm convinced (pending the results of my testing); that's a lot of advantages for a comparatively small risk. I'd like to do at least one more release after the next one before the end of the year anyway, so we have the opportunity to address anything unexpected that does come up. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.
On 22 Aug 2010, at 22:30, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Sun, Aug 22, 2010 at 05:24:05PM CEST: >> On 22 Aug 2010, at 22:09, Ralf Wildenhues wrote: > >>> # consider using shallow clones here, to ease server load. >>> git clone git://git.sv.gnu.org/autoconf.git >>> git clone git://git.sv.gnu.org/automake.git >> >> We could pull the already bootstrapped release tarballs from an >> ftp.gnu.org mirror here instead. > > Sure. > >>> git clone git://git.sv.gnu.org/libtool.git >> >> Of course, that doesn't test the patch series you haven't >> pushed yet... > > Just add 'git checkout origin/parallel-tests'. I meant that if I want to check that my next round of m4sh patches don't break with older Autotools before I push, this script doesn't help, since it wants a fresh libtool checkout. The script would be more useful if it can be run inside a dirty working directory. >> And running it as an Autotest inside the existing tree would >> get us better coverage, and obviate the need for a separate >> checkout of the libtool tree entirely. > > Sure. But look at the existing sort-of-recursive tests. They are > tricky. I am waiting for the day where we add infinite recursion in > some corner case and have developers complain. Actually, I've not looked at the details of those recursive tests, so I must admit that I don't know how tricky they are. I just assumed that we could reuse that pattern here. > The net is abundant now, I think such test helper scripts are a real > easy way to get more coverage, but I don't think it is necessary to > run them as part of each testsuite run, because they are very expensive. A very good point. Maybe we should add a 'maintainer-test' target or similar, which executes this and other expensive test-helper scripts in addition to the regular testsuite(s). And it's also worth considering migrating our other recursive tests to helper scripts too in that case. >>> # Now, mail all output and logs to the autobuild site ... >>> # ... and consider cleaning up afterwards. >> >> The last bit of the script is missing ;) > > TBD when I have all the autobuild setup figured out and all. Kidding!! LOL Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: proposed autobuild_mode naming scheme (was: autobuild logs for Libtool)
> runtimelinking, $host would be powerpc-aix53-.., my autobuild_mode would > be > gcc-native-rtl > > I'm not yet sure whether and when to leave out the compiler and binutils > vendor strings; on some systems there is one canonical choice and there > would be no need to distinguish. Not sure if the vendor one would > always be the best default though. Considering the amount of data we (or at least the autoconf and gnulib list) collects about bugs in particular vendor compiler patch levels, I think that it would be useful to capture this information too -- and then we can take note of trends in test failures caused by particular releases. > Additions welcome. HTH, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: autobuild logs for Libtool
Hallo Ralf, On 23 Aug 2010, at 01:38, Ralf Wildenhues wrote: > * Ralf Wildenhues wrote on Mon, Aug 09, 2010 at 08:50:55PM CEST: >> I think Libtool should use Autobuild, <http://josefsson.org/autobuild/>, >> for testing, and developers as well as users should be encouraged to >> send results to the gathering site. It's about time I try to get my >> various build setups sorted out in some manner suitable for that. > > OK to commit? My other comments on this thread notwithstanding, please go ahead... if you have time and inclination to automate the setting of autobuild_mode per those other comments before you push, so much the better. > The AB_INIT invocation causes something like this extra info to appear > in the configure output: > > configure: autobuild project... GNU Libtool > configure: autobuild revision... 2.2.11a (1.3227 2010-08-09) is it about time we started using git-version-gen instead of our crazy CVS version number faking script? I'll do this before the pending release if you'd like. > configure: autobuild hostname... fuchs > configure: autobuild mode... default > configure: autobuild timestamp... 20100822T183040Z > > When you don't have autobuild installed, thus AB_INIT not defined, > the patch should be a no-op. autobuild will still be usable without > the above output, it's just that the developer then needs to explicitly > provide the information as command-line arguments to autobuild. > > I'd rather avoid adding libltdl/m4/autobuild.m4 to our git, that might > introduce version conflicts in the future. Agreed. > > A better long-term solution would be to start using gnulib-tool (for > argz, autobuild, maybe eventually bootstrap), Ack. > but I *really* don't want > to start experimenting with that option before the release. Strongly agreed! >configure: use Autobuild AB_INIT if available. > >* configure.ac: Call AB_INIT if it is defined, with >$autobuild_mode as argument, to be set at configure time. > Set AB_VERSION to the Libtool version string. >* HACKING: Update. >* libltdl/m4/.gitignore: Ignore autobuild.m4. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: proposed autobuild_mode naming scheme (was: autobuild logs for Libtool)
Some other possible additions:
On 23 Aug 2010, at 09:45, Gary V. Vaughan wrote:
>> Here's the scheme:
>>
>> $autobuild_mode is
>>
>> - either 'default' (when the user forgets, or knows no better ;-)
>>
>> or a hyphen-separated string denoting:
>>
>> - the compiler vendor (gcc, llvm, clang, xl, hp, sun, sgi, dec, intel, pgi,
>> msvc),
>
> Is the compiler version number interesting? (or the os release number for
> native compilers with a hard to extract version string)
>
>> - the binutils vendor (bfd or gold, native),
>>
>> and then zero or more features from the following list, in that order,
>> and denoting that configure was passed the respective arguments:
>>
>> - shared --disable-static
>> - static --disable-shared
>> - pic--with-pic
>> - nonpic --without-pic
>> - fast --enable-fast-install
>> - nofast --disable-fast-install
>> - rtlruntimelinking on AIX (LDFLAGS=-Wl,-brtl)
>> - c++CC=g++
>
> I often run on machines with no f77,gfortran,gcj etc:
>
> - nof77test -z "${F77}"
> - nofc test -z "${FC}"
> - nogcjtest -z "${GCJ}"
> - rc test -n "${RC}"
>
> (picking the "no"-ness to minimize the mode string length in the common case)
>
>> - ltoCC='gcc -flto' CXX='gcc -flto' FC='gfortran -flto'
>> F77='gfortran -flto'
>> - lto-plugin same as lto with gold, but also LDFLAGS=-fuse-linker-plugin
>>(or '-O4 -use-gold-plugin' with llvm)
>> - ksh/ksh93/dash/...
>>CONFIG_SHELL=/bin/ksh was set in the environment and
>>/bin/ksh was used to call configure
Maybe split this into:
- ksh/ksh93/dash/...
the shell that was actually used
- config:ksh/ksh93/dash/...
whether CONFIG_SHELL was set (and what to?)
>> - debian-X.Y/gentoo-X.Y/rhel-X.Y/ubuntu-X.Y/...
>>distribution (maybe including version) that was used
>>(for those systems where $host is not distinguishing)
>> - ac-X.Y/am-X.Z
>>Autoconf and Automake versions used (if interesting)
If we're using '-' as the mode string field delimiter, then something other than
'-' for a version separator seems prudent: maybe ':'?
>> - pmake/gmake
>>setting MAKE=pmake and running the build with $MAKE rather
>>than the native make.
I'd add the version here too, since gmake-3.79 vs gmake-3.81 can make a
difference
in some circumstances.
And a few others that might also be useful:
- sitecache whether a config.site cache was used
- localcachewhether a local config.cache was used
- vpath using an out of tree build
- sed: gnu or vendor sed (& version string)
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
Re: Fix AC_LANG_PROGRAM warnings from git Autoconf.
Hallo Ralf, On 28 Aug 2010, at 14:10, Ralf Wildenhues wrote: > OK to commit? I didn't test, but by inspection everything looks good from here. >Fix AC_LANG_PROGRAM warnings from git Autoconf. > >* libltdl/m4/libtool.m4 (_LT_SYS_MODULE_PATH_AIX): Fix >underquoted AC_LANG_PROGRAM call. >(LT_PROG_AR): Use AC_LANG_PROGRAM. >(_LT_LINKER_SHLIBS) [irix, GCC]: Use the right source for the >given language. Add a NEWS item for lack of warnings/fixed latent bug? Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: ChangeLog entries for sysroot branch, and merge
Hallo Ralf, On 28 Aug 2010, at 15:16, Ralf Wildenhues wrote: > OK to apply to the sysroot branch and merge? > I'm not sure if I need to ask, so I'll leave a bit of time for comments. I'm assuming that the ChangeLog entries map to the actual changes? How come the ChangeLogs weren't committed at the time of the changes that they log? But sure... we don't want changes in the tree without corresponding ChangeLog entries after all, so please go ahead. > I don't actually care too much if after the merge, ChangeLog dates are > not all monotonic. That's just life with trying to map a graph > linearly. Me neither, although our TIMESTAMP is currently taken from the top date of the ChangeLog, which was designed to help us find the right state of the tree for any bugreports on unreleased versions. Actually, I have a patch series that moves to git-version-gen, but it's fiddly enough that we should wait until after the next release before merging. But, at least that means we don't have to worry about TIMESTAMPS being screwy for too long between the next release and merging that patch series :-) > +2010-08-22 Ralf Wildenhues + > + fix AIX testsuite regression > + * libltdl/config/ltmain.m4sh (func_resolve_sysroot): Partly > + revert v2.2.10-83-gc45a288: Do not absolutize path here, only do > + sysroot replacement. > + (func_mode_link): Adjust. > + > +2010-08-22 Charles Wilson + > + fix --mode=finish > + * libltdl/config/ltmain.m4sh (func_mode_finish): Invert then/else > + blocks of the "if $opt_dry_run" conditional. > + [[...]] Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH] Path conversion documentation
Hi Chuck, On 30 Aug 2010, at 06:50, Charles Wilson wrote: > * doc/libtool.texi (Platform quirks): Add new subsections > 'Cross compiling' and 'File name/path conversion'. > * libltdl/config/ltmain.m4sh (func_convert_file_check): Update > comments and warning message. > func_convert_path_check): Update warning message. > --- > Documentation updates for path conversion. Plus a missed > path<->file-name terminology correction. Awesome! Thanks for that. An interesting read. > OK to push? Please do. Two patches though - otherwise we have two independent changes in a single commit. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Backport non-gnulib dependent parts of my use-gnulib topic branch
In the process of moving our version number tracking (and associated run-time sanity checks) over to git-version-gen, I ended up with a full-blown 'use-gnulib' topic branch (which I'll post here after the next release). That branch as a whole is potentially destabilizing, but I've backported the non-gnulib depenedent parts back to master in this series, which I would like to push before rolling the release. In addition to more compatibility with gnulib's announce-gen, this series also tidies up our bootstrap process quite considerably, and fixes the long-standing leak of developer tool paths into distributed files bug. Okay to push? Cheers, -- Gary V. Vaughan (g...@gnu.org)
[PATCH 1/6] Add --gnulib-version and --news options to announce-gen.
From: Gary V. Vaughan
* libltdl/config/announce-gen.m4sh: Add support for gnulib
announce-gen options, previously missing from our m4sh
implementation, and enforce specifying --gnulib-version when
`gnulib' is listed in --bootstrap-tools.
---
ChangeLog|8
libltdl/config/announce-gen.m4sh | 26 +-
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index c6c2447..c3287b2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-08-26 Gary V. Vaughan
+
+ Add --gnulib-version and --news options to announce-gen.
+ * libltdl/config/announce-gen.m4sh: Add support for gnulib
+ announce-gen options, previously missing from our m4sh
+ implementation, and enforce specifying --gnulib-version when
+ `gnulib' is listed in --bootstrap-tools.
+
2010-08-29 Peter Rosin
Fix typo when renaming path conversion functions.
diff --git a/libltdl/config/announce-gen.m4sh b/libltdl/config/announce-gen.m4sh
index 38e6232..fafa2c7 100644
--- a/libltdl/config/announce-gen.m4sh
+++ b/libltdl/config/announce-gen.m4sh
@@ -32,9 +32,12 @@ AS_INIT[]m4_divert_push([HEADER-COPYRIGHT])dnl
# autoconf,automake,bison,gnulib
# --current-version=VER override current release version number
# --debug enable verbose shell tracing
+# --gnulib-version=VERset the version string if gnulib is named
+# in the --bootstrap-tools list
# --gpg-key-id=ID gnupg ID of signature key for release files
# -h STRING --header=STRING insert mail header into announcement
# -m STRING --message=STRINGinsert into message blurb for announcement
+# --news=NEWS_FILEpath to the NEWS file [../NEWS]
# -c--no-print-checksumsdo not emit MD5 and SHA1 checksums
# -o--outputoutput to stdout
# --package-name=NAME override default package name
@@ -128,13 +131,18 @@ M4SH_GETOPTS(
mailnotify_flags="${mailnotify_flags+$mailnotify_flags }$opt"],
[!], [--bootstrap-tools|--bootstrap|--boots], [],[
for tool in `echo "$optarg"|$SED 's|,| |g'`; do
- ($tool --version) >/dev/null 2>&1 || {
- func_error "$opt \`$optarg' does not respond to --version
option."
- cmd_exit=exit
- }
- done],
+ test gnulib = "$tool" ||
+ ($tool --version) >/dev/null 2>&1 || {
+ func_error "$opt \`$optarg' does not respond to --version
option."
+ cmd_exit=exit
+ }
+ done
+ # squash spaces so that delimiter is just `,' and nothing else:
+ opt_bootstrap_tools=`echo "$optarg" |$SED 's|, *|,|g'`],
[!], [--current-version|--current|--curr], [...@version@], [],
+ [!], [--gnulib-version|--gnulib],[], [],
[!], [--gpg-key-id|--gpg], [], [],
+ [!], [--news], [], [],
[], [--no-print-checksums], [], [],
[!], [--previous-version|--previous|--prev], [...@lastrelease@], [],
[!], [--release-type], [], [],
@@ -152,6 +160,14 @@ M4SH_GETOPTS(
func_error "you must specify some tools with --bootstrap-tools."
exit_cmd=exit
}
+ case ,gnulib, in
+ ,$opt_bootstrap_tools,)
+ test -n "$opt_gnulib_version" || {
+ func_error "you must specify a --gnulib-version when gnulib is
in --bootstrap-tools."
+ exit_cmd=exit
+ }
+ ;;
+ esac
# validate $opt_blurb and $opt_message
test -n "$opt_blurb" && test -n "$opt_message" && {
--
1.7.2.2
[PATCH 2/6] Fix partial commit support.
From: Gary V. Vaughan
* clcommit.m4sh (func_commit): Commit only staged files instead
of passing `-a' when no file list was given on the command line.
Signed-off-by: Gary V. Vaughan
---
ChangeLog |6 ++
clcommit.m4sh | 15 +++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index c3287b2..49fe694 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-08-27 Gary V. Vaughan
+
+ Fix partial commit support.
+ * clcommit.m4sh (func_commit): Commit only staged files instead
+ of passing `-a' when no file list was given on the command line.
+
2010-08-26 Gary V. Vaughan
Add --gnulib-version and --news options to announce-gen.
diff --git a/clcommit.m4sh b/clcommit.m4sh
index 8292d6a..f916cd9 100644
--- a/clcommit.m4sh
+++ b/clcommit.m4sh
@@ -268,11 +268,18 @@ func_commit ()
sleep 1 # give the user some time for a ^C
-subject=`git status 2>/dev/null | $SED -n 's/^#.*[mad][ode][dl].*ed: *//p'`
-test $# -gt 0 && subject="$@"
+if test $# -gt 0; then
+ # Given a list of files to commit from the command line: unstage all
+ # files, and add back those in the list...
+ for staged in `$GIT status -s --porcelain 2>/dev/null | $SED -n 's/^M.
//p'`
+ do
+$GIT reset -- $staged
+ done
+ $GIT add ${1+"$@"}
+fi
+# ...otherwise, by default, only staged files are committed.
-test $# -gt 0 || { set dummy -a; shift; }
-func_show_eval "$GIT commit $git_flags -F $log_file ${...@}" "exit
$EXIT_FAILURE"
+func_show_eval "$GIT commit $git_flags -F $log_file" "exit $EXIT_FAILURE"
$opt_push && {
func_show_eval "$GIT push"
--
1.7.2.2
[PATCH 3/6] Support missing detached signatures, like gnulib implementation.
From: Gary V. Vaughan
* libltdl/config/announce-gen.m4sh (func_print_locations): Don't
bail out or print garbage when trying to find the size of a
non-existent file.
Signed-off-by: Gary V. Vaughan
---
ChangeLog|7 +++
libltdl/config/announce-gen.m4sh |8 ++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 49fe694..b8dc314 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2010-08-29 Gary V. Vaughan
+
+ Support missing detached signatures, like gnulib implementation.
+ * libltdl/config/announce-gen.m4sh (func_print_locations): Don't
+ bail out or print garbage when trying to find the size of a
+ non-existent file.
+
2010-08-27 Gary V. Vaughan
Fix partial commit support.
diff --git a/libltdl/config/announce-gen.m4sh b/libltdl/config/announce-gen.m4sh
index fafa2c7..1e24ca9 100644
--- a/libltdl/config/announce-gen.m4sh
+++ b/libltdl/config/announce-gen.m4sh
@@ -267,8 +267,12 @@ func_print_locations ()
echo "Here are the $1:"
echo
for my_file in $3; do
- my_size=`$DU -h $my_file|sed 's,[bB]*[ ].*$,,'`
- echo " $2/$my_file (${my_size}B)"
+ if test -f "$my_file"; then
+ my_size=" (`$DU -h $my_file|sed 's,[bB]*[ ].*$,,'`B)"
+ else
+ my_size=""
+ fi
+ echo " $2/$my_file$my_size"
done
}
--
1.7.2.2
[PATCH 4/6] Rewrite bootstrap script for consistency with our other shell code.
From: Gary V. Vaughan
* bootstrap: Add a proper option parsing loop, along with copies
of supporting functions from `libltd/m4/getopt.m4sh' and
`libltdl/m4/general.m4sh'.
Reformat header comments to work with `func_help' and
`func_version'.
(my_sed_traces): Expanded to extract all parameters from
configure.ac, without additional shell munging.
Signed-off-by: Gary V. Vaughan
---
ChangeLog | 11 ++
bootstrap | 561 +
2 files changed, 461 insertions(+), 111 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b8dc314..4e6e5a0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-08-30 Gary V. Vaughan
+
+ Rewrite bootstrap script for consistency with our other shell code.
+ * bootstrap: Add a proper option parsing loop, along with copies
+ of supporting functions from `libltd/m4/getopt.m4sh' and
+ `libltdl/m4/general.m4sh'.
+ Reformat header comments to work with `func_help' and
+ `func_version'.
+ (my_sed_traces): Expanded to extract all parameters from
+ configure.ac, without additional shell munging.
+
2010-08-29 Gary V. Vaughan
Support missing detached signatures, like gnulib implementation.
diff --git a/bootstrap b/bootstrap
index 7ad0979..eab1a3f 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1,16 +1,16 @@
#! /bin/sh
-# bootstrap -- Helps bootstrapping libtool, when checked out from repository.
-#
-# Copyright (C) 2003, 2004, 2005, 2006, 2009, 2010 Free Software
-# Foundation, Inc,
-# Mritten by Gary V. Vaughan, 2003
-#
-# This file is part of GNU Libtool.
-#
-# GNU Libtool 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 of
-# the License, or (at your option) any later version.
+
+# bootstrap (GNU Libtool) version 2010-08-30
+# Written by Gary V. Vaughan, 2010
+
+# Copyright (C) 2010 Free Software Foundation, Inc.
+# This is free software; see the source for copying conditions. There is NO
+# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+# GNU Libtool 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 of the License, or
+# (at your option) any later version.
#
# GNU Libtool is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -22,10 +22,26 @@
# can be downloaded from http://www.gnu.org/licenses/gpl.html,
# or obtained by writing to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-# Exit upon failure.
-set -e
+# Usage: $progname [OPTION]...
+
+# --debug enable verbose shell tracing
+# -n, --dry-run print commands rather than running them
+# -f, --force bootstrap even when sources are not from git
+# -r, --reconf-dirs=DIR1,DIR2,...
+# limit the directories to be bootstrapped to the
+# comma delimited list of DIR1,DIR2,
+# -v, --verbose verbosely report processing
+# --version print version information and exit
+# -h, --help print short or long help message
+
+# You can also set the following variables to help $progname
+# locate the right tools:
+# AUTORECONF, AUTOCONF, AUTOMAKE, AUTOM4TE, CONFIG_SHELL,
+# EGREP, FGREP, GREP, LN_S, M4, MAKE, MAKEINFO, RM, SED
+
+# This script bootstraps a git checkout of GNU Libtool by correctly calling
+# out to parts of the GNU Build Platform.
# It is okay for the bootstrap process to require unreleased autoconf
# or automake, as long as any released libtool will work with at least
@@ -33,8 +49,11 @@ set -e
# better features, and configure.ac documents oldest version of each
# required for bootstrap (AC_PREREQ, and AM_INIT_AUTOMAKE).
-SHELL=${CONFIG_SHELL-/bin/sh}
-export SHELL
+# Report bugs to
+
+# Exit upon failure.
+set -e
+
: ${AUTORECONF=autoreconf}
: ${AUTOCONF=autoconf}
: ${AUTOMAKE=automake}
@@ -43,127 +62,440 @@ export SHELL
: ${GREP=grep}
: ${EGREP=egrep}
: ${FGREP=fgrep}
+: ${RM='rm -f'}
: ${SED=sed}
: ${LN_S='ln -s'}
: ${MAKEINFO=makeinfo}
-case $1 in
---help|-h*)
- cat <&2
}
+# func_fatal_error arg...
+# Echo program name prefixed message to standard error, and exit.
+func_fatal_error ()
+{
+func_error ${1+"$@"}
+exit $EXIT_FAILURE
+}
-# Extract auxdir and m4dir from configure.ac:
-lt_tab=' '
-my_sed_traces='s,#.*$,,; s,^dnl .*$,,; s, dnl .*$,,;
- /AC_CONFIG_AUX_DIR[^_]/ {
- s,^.*AC_CONFIG_AUX_DIR([[ '"$lt_tab"']*\([^])]*\).*$,auxdir=\1,; p;
- };
- /AC_CONFIG_MACRO_DIR/ {
- s,^.*AC_CONFIG_
[PATCH 6/6] Simplify and improve safety of bootstrap process.
From: Gary V. Vaughan * Makefile.am (bootstrap_files): List files that need to be generated at bootstrap time before `./configure && make' can work. It turns out that this is considerably fewer files than we had thought necessary previously. (bootstrap-deps-prep): Ensure minimum set of required substitution variables are non-empty. (bootstrap-deps): Depend on `bootstrap' files. * bootstrap (Generate bootstrap dependencies): Now that `Makefile.am' is entirely responsible for rebuilding files at bootstrap time, we need only specify the new `bootstrap-deps' target, and supply values for the substitutions checked by `bootstrap-deps-prep'. Signed-off-by: Gary V. Vaughan --- ChangeLog | 14 ++ Makefile.am | 36 bootstrap | 22 -- 3 files changed, 54 insertions(+), 18 deletions(-) diff --git a/ChangeLog b/ChangeLog index 218bd48..736a1d8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,19 @@ 2010-08-30 Gary V. Vaughan + Simplify and improve safety of bootstrap process. + * Makefile.am (bootstrap_files): List files that need to be + generated at bootstrap time before `./configure && make' can + work. It turns out that this is considerably fewer files than we + had thought necessary previously. + (bootstrap-deps-prep): Ensure minimum set of required substitution + variables are non-empty. + (bootstrap-deps): Depend on `bootstrap' files. + * bootstrap (Generate bootstrap dependencies): Now that + `Makefile.am' is entirely responsible for rebuilding files at + bootstrap time, we need only specify the new `bootstrap-deps' + target, and supply values for the substitutions checked by + `bootstrap-deps-prep'. + Don't leak developer GREP, SED etc into distribution file. * bootstrap (rebuild): Set the shell variable `revision' rather than `correctver' for clarity. diff --git a/Makefile.am b/Makefile.am index f6c0a9a..ba3aa08 100644 --- a/Makefile.am +++ b/Makefile.am @@ -78,6 +78,11 @@ CLEANFILES += libtool libtoolize libtoolize.tmp \ ## These are the replacements that need to be made at bootstrap time, ## because they must be static in distributed files, and not accidentally ## changed by configure running on the build machine. + +## !! NOTE !! If you change anything here, ensure that the## +## `bootstrap-deps-prep' rule will still diagnose ## +## any missing setting ## + bootstrap_edit = sed \ -e "s,@configure_input\@,Generated from $$input.,g" \ -e 's,@MACRO_VERSION\@,$(VERSION),g' \ @@ -191,6 +196,37 @@ $(srcdir)/libltdl/Makefile.am: $(srcdir)/libltdl/Makefile.inc -e '1s,^\(.. Makefile.\)inc.*,\1am -- Process this file with automake to produce Makefile.in,' > $$out; chmod a-w $(srcdir)/libltdl/Makefile.am +## Document the make macros that are needed to build bootstrap-deps +## dependencies when called from `bootstrap' (developer's machine), +## where the Makefile.am is fed to make in its raw format before +## `configure' has found the correct values (on the build machine). +bootstrap_files = \ +$(auxdir)/ltmain.sh \ +$(m4dir)/ltversion.m4 \ +libltdl/Makefile.am + +.PHONY: bootstrap-deps bootstrap-deps-prep +bootstrap-deps: bootstrap-deps-prep $(bootstrap_files) +bootstrap-deps-prep: +## The following variables are substituted by `bootstrap-dep-preps' + @test -n "$(srcdir)" \ + || echo "ERROR: don't call $(MAKE) with srcdir unset." + @test -n "$(M4SH)" \ + || echo "ERROR: don't call $(MAKE) with M4SH unset." + @test -n "$(PACKAGE)" \ + || echo "ERROR: don't call $(MAKE) with PACKAGE unset." + @test -n "$(PACKAGE_BUGREPORT)" \ + || echo "ERROR: don't call $(MAKE) with PACKAGE_BUGREPORT unset." + @test -n "$(PACKAGE_NAME)" \ + || echo "ERROR: don't call $(MAKE) with PACKAGE_NAME unset." + @test -n "$(PACKAGE_URL)" \ + || echo "ERROR: don't call $(MAKE) with PACKAGE_URL unset." + @test -n "$(SED)" \ + || echo "ERROR: don't call $(MAKE) with SED unset." + @test -n "$(VERSION)" \ + || echo "ERROR: don't call $(MAKE) with VERSION unset." + rm -f $(bootstrap_files) + ## Unfortunately, all this bogeyness means that we have to manually ## keep the generated files in libltdl up to date. diff --git a/bootstrap b/bootstrap index eab1a3f..dabecea 100755 --- a/bootstrap +++ b/bootstrap @@ -449,24 +449,10
[PATCH 5/6] Don't leak developer GREP, SED etc into distribution file.
From: Gary V. Vaughan * bootstrap (rebuild): Set the shell variable `revision' rather than `correctver' for clarity. (edit): Split into two parts... (bootstrap_edit): ...substitutions that should happen at bootstrap time... (configure_edit): ...and substitution that should not happen until configure time. * bootstrap: Move the bootstrap related section up towards the top of the file. (libltdl/m4/ltversion.m4): Extract `$macro_revision' from this file for direct comparison with `$revision', rather than munging the file's serial number. Use `bootstrap_edit' for substitutions when generating from `ltversion.in'. (libltdl/config/ltmain.sh): Similarly, extract `$package_revision' for comparison with rebuild's `$revision' setting, and make bootstrap time substitutions with `bootstrap_edit'. (libtool): Likewise. (libtoolize): Use `configure_edit' for substitutions at configure time. (tests/package.m4, tests/defs): Likewise. * HACKING (Release Procedure): Remove the note to workaround the bug fixed by this changeset. * NEWS (Bug fixes): Mention that this bug is now fixed. Signed-off-by: Gary V. Vaughan --- ChangeLog | 25 +++ HACKING |9 --- Makefile.am | 211 ++- NEWS|2 + 4 files changed, 134 insertions(+), 113 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4e6e5a0..218bd48 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,30 @@ 2010-08-30 Gary V. Vaughan + Don't leak developer GREP, SED etc into distribution file. + * bootstrap (rebuild): Set the shell variable `revision' rather + than `correctver' for clarity. + (edit): Split into two parts... + (bootstrap_edit): ...substitutions that should happen at bootstrap + time... + (configure_edit): ...and substitution that should not happen until + configure time. + * bootstrap: Move the bootstrap related section up towards the top + of the file. + (libltdl/m4/ltversion.m4): Extract `$macro_revision' from this + file for direct comparison with `$revision', rather than munging + the file's serial number. Use `bootstrap_edit' for substitutions + when generating from `ltversion.in'. + (libltdl/config/ltmain.sh): Similarly, extract `$package_revision' + for comparison with rebuild's `$revision' setting, and make + bootstrap time substitutions with `bootstrap_edit'. + (libtool): Likewise. + (libtoolize): Use `configure_edit' for substitutions at configure + time. + (tests/package.m4, tests/defs): Likewise. + * HACKING (Release Procedure): Remove the note to workaround the + bug fixed by this changeset. + * NEWS (Bug fixes): Mention that this bug is now fixed. + Rewrite bootstrap script for consistency with our other shell code. * bootstrap: Add a proper option parsing loop, along with copies of supporting functions from `libltd/m4/getopt.m4sh' and diff --git a/HACKING b/HACKING index 19b4b66..9d213ae 100644 --- a/HACKING +++ b/HACKING @@ -620,15 +620,6 @@ or obtained by writing to the Free Software Foundation, Inc., * Update NEWS, ChangeLog. -* Until the bug that leaks developer tool paths into the release tarballs - from ./bootstrap is fixed, make sure the right tools are first in your - PATH and then: - export EGREP=egrep - export FGREP=fgrep - export GREP=grep - export MAKE=make - export SED=sed - * Run ./bootstrap. * Run ./configure (or create a build directory first and run configure diff --git a/Makefile.am b/Makefile.am index de3eafe..f6c0a9a 100644 --- a/Makefile.am +++ b/Makefile.am @@ -57,89 +57,13 @@ timestamp = set dummy `$(MKSTAMP) $(srcdir)`; shift; \ *) TIMESTAMP="" ;; \ esac -rebuild = rebuild=:; $(timestamp); correctver=$$1 - - -## ## -## Libtool scripts. ## -## ## - -# The libtool distributor and the standalone libtool script. -bin_SCRIPTS = libtoolize libtool - -libtoolize: $(srcdir)/libtoolize.in $(top_builddir)/config.status - rm -f libtoolize.tmp libtoolize - $(timestamp); \ - input="libtoolize.m4sh"; \ - $(edit) -e "s,@TIMESTAMP\@,$$TIMESTAMP,g" \ - -e 's,@aclocal_DATA\@,$(aclocalfiles),g' \ - -e "s,@pkgltdl_files\@,$(ltdldatafiles),g" \ - -e "s,@pkgconfig_files\@,$(auxfiles),g" \ - $(srcdir)/libtoolize.in > libtoolize.tmp - chmod a+x libtoolize.tmp - chmod a-w libtoolize.tmp - mv -f libtoolize.tmp libtoolize - -# Use `$(srcdir)' for the benefit of non-GNU makes: this is -# how libtoolize.in appears in our dependencies. -EXTRA_DIST += libtoolize.m4sh -$(srcdir)/libtoolize.in: $(sh_files) libtooli
Remove double `Generated from foo.m4sh' lines.
Pushed as obvious. Remove double `Generated from foo.m4sh' lines. We now require a modern Autoconf to bootstrap libtool, which will add the `Generated by ...' boiler-plate automatically, so we can remove the hand-rolled @configure_input@ substitutions we had been doing: * clcommit.m4sh, libtoolize.m4sh, tests/defs.sh, libltdl/config/announce-gen.m4sh, libltdl/config/ltmain.m4sh, libltdl/config/mailnotify.m4sh: Remove @configure_in...@. * Makefile.am (edit): Remove configure_input substitution. (libtoolize, libltdl/config/ltmain.sh, libltdl/m4/ltversion.m4) (tests/defs): Don't set `$input' shell variable. * Makefile.maint (announce_gen, libltdl/config/mailnotify) (commit): Likewise.
Re: [PATCH 1/6] Add --gnulib-version and --news options to announce-gen.
Hi Eric, On 31 Aug 2010, at 21:08, Eric Blake wrote: > On 08/31/2010 12:43 AM, Gary V. Vaughan wrote: >> From: Gary V. Vaughan >> >> * libltdl/config/announce-gen.m4sh: Add support for gnulib >> announce-gen options, previously missing from our m4sh >> implementation, and enforce specifying --gnulib-version when >> `gnulib' is listed in --bootstrap-tools. > > Are you planning on swapping over to gnulib's announce-gen once gnulib is > fully integrated? No, it doesn't work quite right for our release procedure. I tried to make it work again while pulling gnulib modules into the post-release patch series, but Perl still makes my eyes bleed. > And in the meantime, what good does it do to have a --gnulib-version option > if we aren't using gnulib yet? None yet, I just picked all the patches from my use-gnulib topic branch that don't *require* gnulib. Although this particular one has zero impact on user facing code, we can leave the push until after the release... although I was hoping to keep the queue short for easier review. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: Backport non-gnulib dependent parts of my use-gnulib topic branch
Hallo Ralf, On 1 Sep 2010, at 00:38, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Tue, Aug 31, 2010 at 08:43:14AM CEST: >> Okay to push? Please ignore this patch series. Cherry picking back to master from a long divergent branch that has fairly intrusive reorganisation to move Libtool to use gnulib doesn't work as well as I'd hoped. I'll repost the entire series for consideration after the release. > Please state if and how you tested your patches, each by itself or only > all in conjunction? On the original branch, each one had to pass `make distcheck' before commit. > On what system(s)? For this series, on my development machine only, since the changees are not machine specific. > Did you use GNU tools in $PATH > or maybe ensure they are not found while testing? No. > Anything unusual in your environment setup? No. > Do you try different versions of relevant tools (autoconf, git)? git: no. Autoconf, Automake: minimum supported versions and latest stable versions. > Whenever making things more complex rather than > simpler, do you have a rationale for doing so (besides "that looked like > a cool thing to try out")? For this series, moving towards gnulib is the majority of the rationale, and standardization of our use of scripts is the rest. I assume you are asking why I rewrote the bootstrap script here - that was because the existing script is out on a limb by itself, and I thought it sensible to reuse the format and code from our other scripts. > Why do you post FYI commit emails without patches in them, and without > non-patch content over what gets auto-posted to the libtool-commit list? Sorry, ./commit and ./libltdl/config/mailnotify run amok. I haven't really updated the latter to work properly with git. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 1/6] Add --gnulib-version and --news options to announce-gen.
On 1 Sep 2010, at 00:41, Ralf Wildenhues wrote: > this is a review, not an approval. No problem; thanks for the review. [[Review comments I agree with elided...]] > * Gary V. Vaughan wrote on Tue, Aug 31, 2010 at 08:43:15AM CEST: >> * libltdl/config/announce-gen.m4sh: Add support for gnulib >> announce-gen options, previously missing from our m4sh >> implementation, and enforce specifying --gnulib-version when >> `gnulib' is listed in --bootstrap-tools. > > I had avoided looking much at announce-gen so far; I've taken another > look now. I found a few issues: > > Using --output to direct output to stdout seems unusual and inconsistent > with both the GNU Coding Standards recommendations (nodes 'Command-Line > Interfaces' and 'Option Table') and other tools like git. Good point. The intention is to have --output vs --post. I'll look at this again after the release. > I personally find the M4SH_GETOPTS rather unreadable; it's a nice table, > but I cannot make sense of the entries, or review them, except by > looking at the generated code, at which point I'd rather just read the > generated code directly; after all, that's how we found several bugs in > the ltmain incarnation of this code. The documentation is in getopts.m4sh, just above the M4SH_GETOPTS definition. Surely you're not suggesting that we continue to hand code, maintain, synchronize the option parsing loop in each of our scripts? > The --rcfile handling code mistreats quoting in the rcfile, and things > like multiple adjacent whitespace. Examples please. I haven't had any issues using this idiom in any of the --rcfile parsing in any of the shell scripts I've used this code with since I wrote it for cvs-utils (if memory serves). > The help text claims that ./.announcerc is the default place for the > rcfile, but the code looks like $top_srcdir/.announcerc is being used. > > The announce-gen script claims: > # This is the .announcerc for GNU Libtool. Announce-gen is pretty > # smart about picking defaults for package-name and current-version > # and often guesses previous-version correctly too. > > and yet the expanded script contains code like: > top_srcdir=`cd "../libtool" && pwd` > test -d "$top_srcdir" || top_srcdir='../libtool' > > that, when used for another package, will luckily cause stderr noise > that will alert me that just maybe things won't go as smooth as > advertised. Or did you really mean for the script to be generated > anew as part of each package? Well, I mostly intended for it to generate Libtool release announcements for me when I roll up a release. But also to be somewhat similar to the gnulib version, with an eye towards contributing it later. I originally tried to fix the gnulib version to work with libtool's release process, but frankly I'd rather stick forks in my eyes than develop in Perl. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 2/6] Fix partial commit support.
Hallo Ralf, On 1 Sep 2010, at 00:46, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Tue, Aug 31, 2010 at 08:43:16AM CEST: >> * clcommit.m4sh (func_commit): Commit only staged files instead >> of passing `-a' when no file list was given on the command line. > > FWIW, I've never used clcommit since we moved to git; I just use > plain git. Actually, I was using it as a crutch not to get to grips with git, which is indeed very powerful... but also complex and difficult to understand fully. Now that I've had the opportunity to use git properly, I concur that our commit script is obsolete... especially if we eventually move towards generating our ChangeLog from git commit messages, sidestepping the main point of our commit script entirely (to keep ChangeLog and git log messages in sync). When I next have time after the release, I'll submit a patch to remove it. > Come to think, why do we have this script in the Libtool tree at all? For historical reasons. > There is no apparent connection to the Libtool functionality. Maybe > this, as well as announce-gen, could live in their own project? announce-gen is referenced by cfk.mk (nee Makefile.maint) in the release rules, which makes it useful for automating the release process. Maybe it makes sense to remove announce-gen and the rules that reference it none-the-less, and free the person making each release to type up their release announcement as they see fit. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 3/6] Support missing detached signatures, like gnulib implementation.
On 1 Sep 2010, at 00:49, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Tue, Aug 31, 2010 at 08:43:17AM CEST: >> * libltdl/config/announce-gen.m4sh (func_print_locations): Don't >> bail out or print garbage when trying to find the size of a >> non-existent file. > > OK thanks. While you're at it, TAB before space is a little less likely > to be garbage-collected by editors. Gah! That is a habit I really need to break :( Anyway, I'll add an sc_avoid_space_tab check to save me from myself on the use-gnulib branch for submission after the release. > The summary lines of the commit entry and the ChangeLog entry of this > patch do not match the detailed explanation nor the actual patch though. I guess. The intent of the patch is to cope with the gnulib release rules, which use gnupload to generate detached upload signatures on demand so that they are not available to announce-gen when it tries to display their size with func_print_locations(). I'll amend and resubmit after the release. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 4/6] Rewrite bootstrap script for consistency with our other shell code.
On 1 Sep 2010, at 01:03, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Tue, Aug 31, 2010 at 08:43:18AM CEST: >> * bootstrap: Add a proper option parsing loop, along with copies >> of supporting functions from `libltd/m4/getopt.m4sh' and >> `libltdl/m4/general.m4sh'. >> Reformat header comments to work with `func_help' and >> `func_version'. >> (my_sed_traces): Expanded to extract all parameters from >> configure.ac, without additional shell munging. > > This patch does not add new functionality to Libtool, nor does it fix > existing bugs. It is unknown whether this patch introduces regressions, > but experience shows that a patch of this size has a nonzero chance of > doing so. On these grounds, I reject the patch. > > Specifically, I think that bootstrap needs to be only about a screenful > long, excluding comments. We should be making it shorter, not longer. I posted a v2 patch which hasn't made it to the archives yet which address all of these by generating from getopts.m4sh like our other scripts. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 5/6] Don't leak developer GREP, SED etc into distribution file.
On 1 Sep 2010, at 01:12, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Tue, Aug 31, 2010 at 08:43:19AM CEST: >> From: Gary V. Vaughan >> >> * bootstrap (rebuild): Set the shell variable `revision' rather >> than `correctver' for clarity. >> (edit): Split into two parts... >> (bootstrap_edit): ...substitutions that should happen at bootstrap >> time... >> (configure_edit): ...and substitution that should not happen until >> configure time. >> * bootstrap: Move the bootstrap related section up towards the top >> of the file. >> (libltdl/m4/ltversion.m4): Extract `$macro_revision' from this >> file for direct comparison with `$revision', rather than munging >> the file's serial number. Use `bootstrap_edit' for substitutions >> when generating from `ltversion.in'. >> (libltdl/config/ltmain.sh): Similarly, extract `$package_revision' >> for comparison with rebuild's `$revision' setting, and make >> bootstrap time substitutions with `bootstrap_edit'. >> (libtool): Likewise. >> (libtoolize): Use `configure_edit' for substitutions at configure >> time. >> (tests/package.m4, tests/defs): Likewise. >> * HACKING (Release Procedure): Remove the note to workaround the >> bug fixed by this changeset. >> * NEWS (Bug fixes): Mention that this bug is now fixed. > > Please credit Joerg Sonnenberger for finding the bug. Thanks. Will do. > I usually do VPATH builds exclusively, except when trying out patches > where I think in-tree builds could be broken. In my VPATH tree, when I > make -f ../libtool/Makefile.main announce-gen SHELL='/bin/sh -x' > > that contains the following output: > > + -e 's,@TIMESTAMP\@, 1.3257 2010-08-30,g' -e 's,@LASTRELEASE\@,2.2.11,g' -e > 's,@top_srcdir\@,../libtool,g' announce-gen.in > /bin/sh: line 4: -e: command not found As I mentioned already, it seems that I was overly optimistic about being able to cherry pick the non-gnulib related parts of my use-gnulib topic brach onto master and expect them to work :( The error above comes from Makefile.maint, which doesn't exist in use-gnulib, superceded by maint.mk/cfg.mk. Sorry for the bad merge. > Please, once and for all, whenever you rename some identifier, > use some method to verify that you've renamed all instances; > git grep '\' > > is quite a good approximation to the perfect method, and costs maybe a > couple of seconds on your part. Then submit that as separate patch. As I did when writing, testing and committing within the series I developed in. > When you do pure code move-arounds, that also is much easier to review > when done as a separate patch, without any actual changes to the text > that was moved. I remember that we took more than dozen iterations on > the makefile rules to get them halfway correct, I have no intentions of > going there again. Okay. > I have stopped reviewing at this point. I would gladly re-review a > minimal patch based on minimal prerequisites that has been properly > tested. The Makefile.am changes should be tested with both GNU and > non-GNU make, and both VPATH and in-tree. As I did in the context of the use-gnulib branch. On balance, there is an inordinate amount of time and effort involved from each of us to fully test and review these patches out of context (i.e. on master) when half the work has already been done once on another branch (i.e use-gnulib). Let's just forget this patch series for now. Thanks for the review, and sorry for not making the time to retest everything all over again as I cherry-picked. I'll take the pertinent parts into consideration before resubmitting the use-gnulib branch series in its entirety after the release. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 6/6] Simplify and improve safety of bootstrap process.
On 1 Sep 2010, at 01:16, Ralf Wildenhues wrote: > This is a fairly nice cleanup that I think is valuable to redo without > the other rejected patches. Please resubmit with nit below addressed, > and I will approve it then after looking over once more. Well, since it has zero impact on user-facing code, and because I was far too optimistic already about cherry-picking and reordering patches from another branch with significant reorganization without redoing the time consuming testing from scratch... I'll wait until after the release and resubmit then along with the rest of that series where it has all been tested properly. > * Gary V. Vaughan wrote on Tue, Aug 31, 2010 at 08:43:20AM CEST: >> --- a/Makefile.am >> +++ b/Makefile.am > >> +## Document the make macros that are needed to build bootstrap-deps >> +## dependencies when called from `bootstrap' (developer's machine), >> +## where the Makefile.am is fed to make in its raw format before >> +## `configure' has found the correct values (on the build machine). >> +bootstrap_files = \ >> +$(auxdir)/ltmain.sh \ >> +$(m4dir)/ltversion.m4 \ >> +libltdl/Makefile.am >> + >> +.PHONY: bootstrap-deps bootstrap-deps-prep >> +bootstrap-deps: bootstrap-deps-prep $(bootstrap_files) >> +bootstrap-deps-prep: >> +## The following variables are substituted by `bootstrap-dep-preps' >> +@test -n "$(srcdir)" \ >> + || echo "ERROR: don't call $(MAKE) with srcdir unset." >> +@test -n "$(M4SH)" \ >> +|| echo "ERROR: don't call $(MAKE) with M4SH unset." >> +@test -n "$(PACKAGE)" \ >> +|| echo "ERROR: don't call $(MAKE) with PACKAGE unset." >> +@test -n "$(PACKAGE_BUGREPORT)" \ >> +|| echo "ERROR: don't call $(MAKE) with PACKAGE_BUGREPORT unset." >> +@test -n "$(PACKAGE_NAME)" \ >> +|| echo "ERROR: don't call $(MAKE) with PACKAGE_NAME unset." >> +@test -n "$(PACKAGE_URL)" \ >> +|| echo "ERROR: don't call $(MAKE) with PACKAGE_URL unset." >> +@test -n "$(SED)" \ >> +|| echo "ERROR: don't call $(MAKE) with SED unset." >> +@test -n "$(VERSION)" \ >> +|| echo "ERROR: don't call $(MAKE) with VERSION unset." >> +rm -f $(bootstrap_files) > > It would be nice if this rule would actually error out (i.e., have > nonzero exit status) if any of the variables were unset. Agreed. >> -test -f clcommit.m4sh && $MAKE -f Makefile.maint ./commit \ >> -srcdir=. top_srcdir=. PACKAGE="$package" VERSION="$version" \ >> -M4SH="$AUTOM4TE -l m4sh" \ >> -SED="$SED" GREP="$GREP" FGREP="$FGREP" EGREP="$EGREP" LN_S="$LN_S" >> +func_show_eval "$MAKE bootstrap-deps \ >> +M4SH='$AUTOM4TE --language=m4sh' PACKAGE='$package' \ >> +PACKAGE_BUGREPORT='$package_bugreport' PACKAGE_NAME='$package_name' \ >> +PACKAGE_URL='$package_url' SED='$SED' srcdir=. VERSION='$version'" > > For bootstrap, the func_show_eval from the rejected patch is probably > gotten just as easily by just 'set -x'; besides the fact that using eval > on this string is wrong. I was under the impression that the following were equivalent (with the former removing the opportunity for two near copies of the same complex invocation to get out of sync): func_show_eval "$MAKE bootstrap-deps M4SH='$AUTOM4TE --language=m4sh' " and: echo "$MAKE bootstrap-deps M4SH='$AUTOM4TE --language=m4sh' ..." $MAKE bootstrap-deps M4SH='$AUTOM4TE --language=m4sh' ..." What am I missing? Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
[PATCH] Remove clcommit.m4sh.
Does anyone else use the commit script?
* clcommit.m4sh: Removed. This script was written to help keep
ChangeLog and commit messages in sync when committing to CVS,
and is an anachronism now that Libtool uses git.
Okay to push?
---
ChangeLog |7 +
clcommit.m4sh | 375 -
2 files changed, 7 insertions(+), 375 deletions(-)
delete mode 100644 clcommit.m4sh
diff --git a/ChangeLog b/ChangeLog
index a4c91cb..aba79b5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2010-09-01 Gary V. Vaughan
+
+ Remove clcommit.m4sh.
+ * clcommit.m4sh: Removed. This script was written to help keep
+ ChangeLog and commit messages in sync when committing to CVS,
+ and is an anachronism now that Libtool uses git.
+
2010-08-31 Gary V. Vaughan
Remove double `Generated from foo.m4sh' lines.
diff --git a/clcommit.m4sh b/clcommit.m4sh
deleted file mode 100644
index c189cf3..000
--- a/clcommit.m4sh
+++ /dev/null
@@ -1,375 +0,0 @@
-AS_INIT[]m4_divert_push([HEADER-COPYRIGHT])
-# clcommit (GNU @PACKAGE@) version 2.1
-# Written by Gary V. Vaughan
-# and Alexandre Oliva
-
-# Copyright (C) 1999, 2000, 2004, 2006, 2008, 2009, 2010 Free Software
-# Foundation, Inc.
-# This is free software; see the source for copying conditions. There is NO
-# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
-# Clcommit 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 of the License, or
-# (at your option) any later version.
-#
-# Clcommit 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 clcommit; see the file COPYING. If not, a copy
-# can be downloaded from http://www.gnu.org/licenses/gpl.html,
-# or obtained by writing to the Free Software Foundation, Inc.,
-# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-# Usage: $progname [OPTION]... [--] [filepattern ...]
-
-# -a AUTHOR --author=AUTHORoverride changeset author name with AUTHOR
-# -C FILE --changelog=FILE extract commit message from specified FILE
-# --debugenable verbose shell tracing
-# -n--dry-run don't commit anything
-# --fast same as --force --first
-# -F FILE --file=FILEread commit message from FILE
-# -1--firstextract first entry from ChangeLog, no git diff
-# -f--forcedon't check (unless *followed* by -n), and just
-# display commit message instead of running $PAGER
-# --from=ADDRESS override default from ADDRESS in commit email
-# -m STRING --message=STRING set commit message to STRING
-# --msg=STRING same as -m
-# -p--push push the changes back to origin
-# -r [FILE] --rcfile[=FILE]read default option from FILE [./.clcommitrc]
-# -s ADDR --sendmail=ADDRsend commit email of the differences to ADDRESS
-# --signature[=FILE] add FILE to the end of the email [~/.signature]
-# --signoff add a Signed-off-by attribution at the end
-# -S TEXT --summary=TEXT specify a TEXT subject line for the commit email
-# --tags in conjunction with -p, also push tags
-# -v--verbose run in verbose mode
-# --version print version information
-# -h,-? --help print short or long help message
-
-# This script eases checking in changes to git-maintained projects
-# with ChangeLog files. It will check that there have been no
-# conflicting commits in the git repository and print which files it
-# is going to commit to stderr. A list of files to compare and to
-# check in can be given in the command line. If it is not given, all
-# files in the current working directory are considered for check in.
-
-# The commit message will be extracted from the differences between a
-# file named ChangeLog* in the commit list, or named after -C, and the
-# one in the repository (unless a message was specified with `-m' or
-# `-F'). An empty message is not accepted (but a blank line is). If
-# the message is acceptable, it will be presented for verification
-# (and possible edition) using the $PAGER environment variable (or
-# `more', if it is not set, or `cat', if the `-f' switch is given).
-# If $PAGER exits successfully, the modified files (at that moment)
-# are checked in, unless `-n' was specified, in which case nothing is
-# checked in.
-
-# Report bugs to
-
-: ${GIT="git"}
-: ${MAILNOTIFY="mai
Re: [PATCH] Remove clcommit.m4sh.
Hi Chuck, On 1 Sep 2010, at 10:50, Charles Wilson wrote: > On 8/31/2010 10:53 PM, Gary V. Vaughan wrote: >> Does anyone else use the commit script? >> >> * clcommit.m4sh: Removed. This script was written to help keep >> ChangeLog and commit messages in sync when committing to CVS, >> and is an anachronism now that Libtool uses git. >> >> Okay to push? >> >> --- >> ChangeLog |7 + >> clcommit.m4sh | 375 >> - >> 2 files changed, 7 insertions(+), 375 deletions(-) >> delete mode 100644 clcommit.m4sh > > Don't you also need to patch Makefile.maint to remove references to this > file? (There's a comment referring to it in mailnotify.m4sh too, but > that's not important). Yes, I was a bit too keen to remove it. Thanks. I've also removed the command from bootstrap that generates the commit script, and I'm in the process of checking that the amended `./commit' free release process still works, and editing HACKING to match. The release process takes a few hours though, so it'll be a short while before I post an updated patch. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
[PATCH v2] Remove clcommit.m4sh.
Total Annihilation: Removed insidious references from the rest of the tree. * clcommit.m4sh: Removed. This script was written to help keep ChangeLog and commit messages in sync when committing to CVS, and is an anachronism now that Libtool uses git. * Makefile.maint (commit): Target removed. * bootstrap: Don't generate commit. * HACKING (Release Procedure): Adjusted. Okay to push? --- ChangeLog | 10 ++ HACKING|6 +- Makefile.maint | 17 +--- bootstrap |7 +- clcommit.m4sh | 375 5 files changed, 16 insertions(+), 399 deletions(-) delete mode 100644 clcommit.m4sh diff --git a/ChangeLog b/ChangeLog index a4c91cb..d678169 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2010-09-01 Gary V. Vaughan + + Remove clcommit.m4sh. + * clcommit.m4sh: Removed. This script was written to help keep + ChangeLog and commit messages in sync when committing to CVS, + and is an anachronism now that Libtool uses git. + * Makefile.maint (commit): Target removed. + * bootstrap: Don't generate commit. + * HACKING (Release Procedure): Adjusted. + 2010-08-31 Gary V. Vaughan Remove double `Generated from foo.m4sh' lines. diff --git a/HACKING b/HACKING index 19b4b66..e079e4b 100644 --- a/HACKING +++ b/HACKING @@ -647,7 +647,7 @@ or obtained by writing to the Free Software Foundation, Inc., and `make distcheck CC=g++' If there are any problems, fix them and start again. -* Run `./commit -p' from the source tree. +* Run `git commit' from the source tree. * Run `make -fMakefile.maint git-dist' (or `make -f../Makefile.maint git-dist' if you are running from a VPATH build directory, where `../' @@ -676,7 +676,9 @@ or obtained by writing to the Free Software Foundation, Inc., * Update NEWS, ChangeLog. -* Run `./commit -p --tags', to push the new changes and tags to origin. +* Run `git commit'. + +* Run `git push --tags', to push the new changes and tags to origin. * Update the webpages, libtool.html will need to indicate the latest release number. diff --git a/Makefile.maint b/Makefile.maint index 2e655ae..15d5a14 100644 --- a/Makefile.maint +++ b/Makefile.maint @@ -36,17 +36,6 @@ Makefile: TEXI2HTML = texi2html -$(srcdir)/commit: $(srcdir)/$(auxdir)/mailnotify clcommit.m4sh - $(timestamp); \ - cd $(srcdir); \ - rm -f commit commit.in commit.tmp; \ - $(M4SH) -B $(auxdir) clcommit.m4sh > commit.in; \ - $(edit) -e "s,@TIMESTAMP\@,$$TIMESTAMP,g" commit.in > commit.tmp; \ - chmod a+x commit.tmp; \ - chmod a-w commit.tmp; \ - mv -f commit.tmp commit; \ - rm -f commit.in - announce-gen: $(auxdir)/announce-gen.m4sh $(auxdir)/getopt.m4sh $(timestamp); \ rm -f announce-gen announce-gen.in announce-gen.tmp; \ @@ -73,7 +62,7 @@ $(srcdir)/$(auxdir)/mailnotify: $(auxdir)/mailnotify.m4sh rm -f mailnotify.in .PHONY: git-release -git-release: version-check prev-tarball check-news fetch git-commit git-dist diffs web-manual +git-release: version-check prev-tarball check-news fetch git-dist diffs web-manual @tarname="$(PACKAGE)-$(VERSION).tar.gz"; \ lzmaname="$(PACKAGE)-$(VERSION).tar.lzma"; \ diffname="$(PACKAGE)-$(LASTRELEASE)-$(VERSION).diff.gz"; \ @@ -160,10 +149,6 @@ fetch: GPG = gpg # set it to `:' to avoid gpg operations -.PHONY: git-commit -git-commit: check-news - cd $(srcdir) && $(SHELL) ./commit - .PHONY: git-dist git-dist: check-news check-commit ## Build the distribution: diff --git a/bootstrap b/bootstrap index 7ad0979..82828db 100755 --- a/bootstrap +++ b/bootstrap @@ -140,11 +140,6 @@ $MAKE ./$auxdir/ltmain.sh ./$m4dir/ltversion.m4 \ AUTOTEST="$AUTOM4TE --language=autotest" SED="$SED" MAKEINFO="$MAKEINFO" \ GREP="$GREP" FGREP="$FGREP" EGREP="$EGREP" LN_S="$LN_S" -test -f clcommit.m4sh && $MAKE -f Makefile.maint ./commit \ -srcdir=. top_srcdir=. PACKAGE="$PACKAGE" VERSION="$VERSION" \ -M4SH="$AUTOM4TE -l m4sh" \ -SED="$SED" GREP="$GREP" FGREP="$FGREP" EGREP="$EGREP" LN_S="$LN_S" - rm -f Makefile # Make a dummy libtoolize script for autoreconf: @@ -193,7 +188,7 @@ done # Commit script caveat: cat < -# and Alexandre Oliva - -# Copyright (C) 1999, 2000, 2004, 2006, 2008, 2009, 2010 Free Software -# Foundation, Inc. -# This is free software; see the source for copying conditions. There is NO -# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - -# Clcommit 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
[PATCH] Remove announce-gen.m4sh and mailnotify.m4sh.
>From earlier discussion, there is no need to clutter the
Libtool tree with these scripts, and we can amend our release
process to use the gnulib announce-gen script in due course.
* libltdl/config/announce-gen.m4sh: Removed. This script has
no apparent connection to libtool functionality, and mostly
duplicates the better maintained gnulib announce-gen script.
* libltdl/config/mailnotify.sh: Removed. This script was used
by only clcommit.m4sh and announce-gen.m4sh, both of which are
now removed too.
* Makefile.maint (announce-gen): Target removed.
* bootstrap: Remove the mailnotify regeneration warning.
* HACKING (Release Procedure): Remove references to
announce-gen.
(Alpha release note template, Full release note template):
Reinstated from before announce-gen was introduced.
Okay to push?
Signed-off-by: Gary V. Vaughan
---
ChangeLog| 14 ++
HACKING | 181 +--
Makefile.maint | 25 --
bootstrap| 10 -
libltdl/config/.cvsignore|1 -
libltdl/config/.gitignore|1 -
libltdl/config/announce-gen.m4sh | 464 --
libltdl/config/mailnotify.m4sh | 403 -
8 files changed, 171 insertions(+), 928 deletions(-)
delete mode 100644 libltdl/config/announce-gen.m4sh
delete mode 100644 libltdl/config/mailnotify.m4sh
diff --git a/ChangeLog b/ChangeLog
index d678169..9fcb522 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,19 @@
2010-09-01 Gary V. Vaughan
+ Remove announce-gen.m4sh and mailnotify.m4sh.
+ * libltdl/config/announce-gen.m4sh: Removed. This script has
+ no apparent connection to libtool functionality, and mostly
+ duplicates the better maintained gnulib announce-gen script.
+ * libltdl/config/mailnotify.sh: Removed. This script was used
+ by only clcommit.m4sh and announce-gen.m4sh, both of which are
+ now removed too.
+ * Makefile.maint (announce-gen): Target removed.
+ * bootstrap: Remove the mailnotify regeneration warning.
+ * HACKING (Release Procedure): Remove references to
+ announce-gen.
+ (Alpha release note template, Full release note template):
+ Reinstated from before announce-gen was introduced.
+
Remove clcommit.m4sh.
* clcommit.m4sh: Removed. This script was written to help keep
ChangeLog and commit messages in sync when committing to CVS,
diff --git a/HACKING b/HACKING
index e079e4b..b462c98 100644
--- a/HACKING
+++ b/HACKING
@@ -687,38 +687,171 @@ or obtained by writing to the Free Software Foundation,
Inc.,
doc/manual using cvs to here:
@cvs.savannah.gnu.org:/webcvs/libtool
-* In the build directory, run `Make -f[../]Makefile.maint announce-gen'.
+* Write a release announcement, and post it to `libt...@gnu.org' and
+ `autotools-annou...@gnu.org' with the Reply-To header set to
+ `bug-libt...@gnu.org'. Stable releases should also be announced
+ on `info-...@gnu.org'.
-* Make sure the source directory has an appropriate .announcerc, along
- the lines of:
+* Post a copy of your release announcement to savannah news:
+ https://savannah.gnu.org/news/submit.php?group=libtool
+ which will automatically propogate to http://planet.gnu.org.
---bootstrap-tools='autoconf,automake'
---gpg-key-id={the id of the key you signed the tarballs with}
---header 'From: {your name} <{your email address}>
---header 'To: Libtool List '
---header 'Cc: Autotools Announce List '
---header 'Reply-To: Libtool Bugs '
---message 'GNU Libtool hides the complexity of using shared'
---message 'libraries behind a consistent, portable interface.'
---message 'GNU Libtool ships with GNU libltdl, which hides the'
---message 'complexity of loading dynamic runtime libraries'
---message '(modules) behind a consistent, portable interface.'
---signature
-* Check the release announcement with:
+13. Alpha release note template
+===
-./announce-gen -r -o --prev=LASTRELEASE alpha
+To: libt...@gnu.org, autotools-annou...@gnu.org
+Reply-To: bug-libt...@gnu.org
+Subject: GNU Libtool @VERSION@ released (alpha release).
- or for a stable release:
+The Libtool Team is pleased to announce alpha release @VERSION@ of GNU
+Libtool.
-./announce-gen -r -o -h 'Cc: info-...@gnu.org' --prev=LASTRELEASE stable
+GNU Libtool hides the complexity of using shared libraries behind a
+consistent, portable interface. GNU Libtool ships with GNU libltdl,
+which hides the complexity of loading dynamic runtime libraries
+(modules) behind a consistent, portable interface.
- When you're happy with the announcement text, post it by rerunning the
- command with `-p' instead of `-o'.
Re: [PATCH 6/6] Simplify and improve safety of bootstrap process.
On 1 Sep 2010, at 12:32, Ralf Wildenhues wrote: > func_show_eval > is still buggy in that it causes more filename expansion than we'd like > to have (leading to commits like v2.2.10-48-g3ab9879), but yes, that > shouldn't be an issue here. Ah... I had wondered what that was all about. It makes sense now, thanks. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 1/6] Add --gnulib-version and --news options to announce-gen.
On 1 Sep 2010, at 12:25, Ralf Wildenhues wrote: > Hello Gary, Hallo Ralf, > * Gary V. Vaughan wrote on Wed, Sep 01, 2010 at 03:59:19AM CEST: >> On 1 Sep 2010, at 00:41, Ralf Wildenhues wrote: >>> I personally find the M4SH_GETOPTS rather unreadable; it's a nice table, >>> but I cannot make sense of the entries, or review them, except by >>> looking at the generated code, at which point I'd rather just read the >>> generated code directly; after all, that's how we found several bugs in >>> the ltmain incarnation of this code. >> >> The documentation is in getopts.m4sh, just above the M4SH_GETOPTS >> definition. > > That didn't help to make it more readable, or cause less buggy code > though. Well that's because the shared code in getopts.m4sh is still getting exposure. I think that M4SH_GETOPTS is infinitely more readable and maintainable, and especially worth the effort of using and debugging if I am to contribute a variation to Autoconf's m4sugar libraries. Why maintain several copies of the same code if we can do it just once? >> Surely you're not suggesting that we continue to hand code, maintain, >> synchronize the option parsing loop in each of our scripts? > > Well, bootstrap didn't need one so far, did it? How much maintenance > does an option parsing loop need, once it is written? I didn't have the > feeling that that was a biggie on our list before that. Certainly not a biggie. But after using the M4SH_GETOPTS generated bootstrap script on my gnulib branch for less than a week, going back to the under-featured master branch version is already painful. >>> The --rcfile handling code mistreats quoting in the rcfile, and things >>> like multiple adjacent whitespace. >> >> Examples please. I haven't had any issues using this idiom in any of >> the --rcfile parsing in any of the shell scripts I've used this code >> with since I wrote it for cvs-utils (if memory serves). > > Put this in the rcfile, observe how the two spaces are flattened to one: > --message 'One sentence. Another sentence.' Oh yuck. Nice catch though. I've added a note to investigate that in my copy of announce-gen.m4sh incase I ever publish an --rcfile using shell script that pastes code from here in future. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH] Path conversion documentation
On 2 Sep 2010, at 12:40, Charles Wilson wrote: > 'Course, I notice that I screwed up the date in the ChangeLog. Could > the next person to commit a change to that file, please fix it? > > -2010-09-31 ... > +2010-09-01 ... Might be unnecessary... In my use-gnulib branch, I'm wondering whether to incorporate gitlog-to-changelog, and have it generate the current year's ChangeLog at distribution time. However the first few months of the year don't have suitable gitlog's to convert nicely. I can think of a few options: i) wait until next year ii) post process the output of gitlog-to-changelog for now iii) fix the gitlog entries -- if that's even viable? Comments? Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: git log -> changelog
[[sorry for the thread hijack]] On 6 Sep 2010, at 03:44, Ralf Wildenhues wrote: > * Eric Blake wrote on Thu, Sep 02, 2010 at 11:23:57PM CEST: >> The git pages are clear that S-O-B has project-dependent >> interpretation. Coreutils currently doesn't even use it (the only >> people with commit privileges to the master coreutils.git have FSF >> copyright, and it is assumed that they are each trustworthy enough >> to do due diligence in verifying that patches from other >> contributors meet copyright rules, without relying on any markup in >> the commit message itself). >> >> But if we wanted, we could adopt a policy that S-O-B on GNU projects >> using the gitlog-to-changelog conversion implies (partial) >> authorship, above and beyond the --author. > > Except that the autotools project logs contain lots of S-O-B entries > which explicitly do not have that particular meaning. :-/ I suppose we can create an annotation for logs that have a non-compliant SoB as if it was any other commit log typo we want to override to make sure gitlog-to-changelog creates a beautiful ChangeLog -- after we document our policy, and for entries going back to the beginning of the year in which we decide to start using gitlog-to-changelog. Even if we wait until next year to start using gitlog-to-changelog, I think it worthwhile to know in advance how we will cope with a commit log that needs a correction. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: git log -> changelog
On 6 Sep 2010, at 12:47, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Mon, Sep 06, 2010 at 05:20:30AM CEST: >> On 6 Sep 2010, at 03:44, Ralf Wildenhues wrote: >>> Except that the autotools project logs contain lots of S-O-B entries >>> which explicitly do not have that particular meaning. :-/ >> >> I suppose we can create an annotation for logs that have a non-compliant >> SoB as if it was any other commit log typo we want to override to make >> sure gitlog-to-changelog creates a beautiful ChangeLog -- after we document >> our policy, and for entries going back to the beginning of the year in >> which we decide to start using gitlog-to-changelog. >> >> Even if we wait until next year to start using gitlog-to-changelog, I >> think it worthwhile to know in advance how we will cope with a commit log >> that needs a correction. > > Definitely, yes. I'm afraid I still don't quite understand the intended > semantics though. All S-O-B entries are to be co-authors of the patch, > starting from, say, January 1, 2011? As a start, yes. We also need to come up with a way to annotate for `(tiny change)', and to override typos without changing history. And then we need to patch gitlog-to-changelog so that it produces correct ChangeLog entries when it encounters those annotations. > I wonder whether it makes sense to ask for a more consistent notation > upstream, or push for one. It'd be nice if gitk, cgit, and the like, > could also display things as intended. That would be very nice! Before we can pursue any of that though, we might like to fiddle with gitlog-to-changelog and add appropriate annotations to the 2010 Libtool commits to ensure we can rebuild our current ChangeLog from the git commit logs. Really, I'm just throwing that all out there so it isn't forgotten... I have plenty of unfinished patches backed up on the use-gnulib branch already to be able to tackle anything else in earnest until a few weeks after the release at the earliest. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH] Adjust naming of MSVC import libraries.
Hi Peter, On 7 Sep 2010, at 16:25, Peter Rosin wrote: > Den 2010-09-04 16:21 skrev Charles Wilson: >> On 9/4/2010 4:52 AM, Peter Rosin wrote: >>> And the testsuite runs have finished and results are the same. I still >>> want to push this. >> >> I have no objections anymore, but I can't approve it. > > Here's a rebased and adjusted version now that 5/7 from the other thread > has gone in and finalized the interface. The testsuite is still happy... > > Ok to push? It seems to me that none of this patch affects non-win32 systems, so I can't test it... otherwise I might have spoken up sooner. > (or are you all on the 72 hour clock since the first post? > I'm setting a new 72 hour clock now in case you're not) No need for that I think. As long as the testsuite is still passing on the systems that use this codepath, the original 72 hour clock is plenty long enough time for any of us to exercise a veto, or ask for more time to review. > (BTW, what's up with the strange date generated by git in the next line?) > -- > 1.7.1 Dunno, but git is up to 1.7.2.2. If you see it again after updating, please forward a report to g...@vger.kernel.org. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
How many spaces after a period? [WAS: Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.]
On 12 Sep 2010, at 15:01, Ralf Wildenhues wrote: > * Peter Rosin wrote on Sat, Sep 11, 2010 at 02:24:18PM CEST: >> * libltdl/config/ltmain.m4sh (func_mode_link): Avoid calculating >> the command line length and take the @file branch *if* the file >> names needs to be converted for the toolchain and the @file >> branch works. Fixes stresstest.at when doing a cross from Cygwin > > Two spaces after period. Only for texinfo markup I believe, since two spaces after a period are widely regarded as typographically bad (see the following and the reports it cites at the end): http://webword.com/reports/period.html And even then, there is still support for normal spacing in texinfo: http://www.gnu.org/software/hello/manual/texinfo/frenchspacing.html [[ASIDE: Curious that the default `...@frenchspacing off' is used to indicate the use of 2 spaces at the end of a sentence, and declaring `...@frenchspacing on' conversely indicates the use of a single space at the end of a sentence - the exact opposite of how the term is normally used: "French spacing—a term synonymous with single space sentence spacing until the late 20th century.[7] Double spacing,[8] or placing two spaces between sentences (sometimes referred to as English spacing), came into widespread use with the introduction of the typewriter in the late 19th century" -- http://en.wikipedia.org/wiki/Sentence_spacing]] I see that the GCS wants two spaces after a period in code comments, but when I tested in emacs, my single spaced sentences worked just fine. It turns out that I added the following to my startup so long ago that I'd forgotten I had done it: (setq sentence-end-double-space nil) Is there some other mandate that explains why we should go against modern typographical conventions and insist on double spaces? Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: getopt-m4sh tests failures with autom4te 2.61
On 12 Sep 2010, at 16:42, Ralf Wildenhues wrote: > * Ralf Wildenhues wrote on Thu, Sep 02, 2010 at 10:36:54PM CEST: >> Hi Gary, Hallo Ralf, Sorry I didn't see the original yet... I still have 400 emails backed up in my Inbox. :( >> I get testsuite failures of the first six tests with autom4te 2.61 early >> in PATH (the testsuite itself has been created with 2.67). See below >> for an example failure. Maybe getopt-m4sh.at really relies on >= 2.62? Yes, you're right. I had thought my ~/old-autotools/bin had 2.61 installed, but it turns out that it was 2.62 all along, which is why I haven't experienced any failures in my tests. Also, I don't think it is worth worrying about 2.61 compatibility, since getopt.m4sh is only needed when bootstrapping, which requires newer autotools anyway. > I've pushed the patch below to fix this failure now. Thanks. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: test with old autotools (was: [PATCH 1/6] Require Automake 1.11.1 for Libtool, enable color-tests.)
On 12 Sep 2010, at 17:47, Ralf Wildenhues wrote: > you wanted a way to test old Autoconf and Automake with a git Libtool > tree: Awesome, thanks :) > [[snip]] > At this point, I'm not actually asking to commit this now. Consider it > a test balloon that you could use in your git tree to test things. :-) > > Cheers, > Ralf > <0001-Try-out-new-testsuite-with-old-Autoconf-and-Automake.patch> You forgot to `git add tests/old-autoconf.at' before you generated the patch though... Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: doc: wrapping, categorizing, and indexing improvements.
he module loaders, returning the first loader if @var{place} is
> @code{NULL}, and the next one on subsequent calls. The handle is for use with
> @code{lt_dlloader_add}.
> @@ -4516,7 +4526,7 @@ if (lt_dlloader_add (lt_dlloader_next (NULL), myloader)
> != 0)
> @end example
> @end deftypefun
>
> -...@deftypefun {lt_dlloader *}lt_dlloader_find (@w{const char
> *...@var{loader_name}})
> +...@deftypefun {lt_dlloader *} lt_dlloader_find (@w{const char
> *...@var{loader_name}})
> Return the first loader with a matching @var{loader_name} identifier, or else
> @code{NULL}, if the identifier is not found.
>
> @@ -4533,14 +4543,14 @@ if (lt_dlloader_add (lt_dlloader_find ("dlopen"),
> myloader) != 0)
> @end example
> @end deftypefun
>
> -...@deftypefun {const char *}lt_dlloader_name (@w{lt_dlloader
> *...@var{place}})
> +...@deftypefun {const char *} lt_dlloader_name (@w{lt_dlloader
> *...@var{place}})
> Return the identifying name of @var{place}, as obtained from
> @code{lt_dlloader_next} or @code{lt_dlloader_find}. If this function fails,
> it will return @code{NULL} and set an error for retrieval with
> @code{lt_dlerror}.
> @end deftypefun
>
> -...@deftypefun {lt_user_data *}lt_dlloader_data (@w{lt_dlloader
> *...@var{place}})
> +...@deftypefun {lt_user_data *} lt_dlloader_data (@w{lt_dlloader
> *...@var{place}})
> Return the address of the @code{dlloader_data} of @var{place}, as
> obtained from @code{lt_dlloader_next} or @code{lt_dlloader_find}. If
> this function fails, it will return @code{NULL} and set an error for
> @@ -6875,7 +6885,7 @@ tree, @code{/home/src/libtool/libtool} is a libtool
> script that has been
> configured for your platform, and @code{~/bin} is a directory in your
> @env{PATH}:
>
> -...@example
> +...@smallexample
> trick$ cd ~/bin
> trick$ sed 's%^\(macro_version=\).*$%\1@@VERSION@@%;
> s%^\(macro_revision=\).*$%\1@@package_revision@@%;
> @@ -6889,7 +6899,7 @@ Copyright (C) 2010 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> trick$
> -...@end example
> +...@end smallexample
> @end itemize
>
> The output of the final @samp{libtool --version} command shows that the
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
Re: How many spaces after a period?
Hi Karl, Thanks for the swift response. On 13 Sep 2010, at 05:01, Karl Berry wrote: > Baffled on several fronts ... > >declaring `...@frenchspacing on' conversely indicates the use of a >single space at the end of a sentence - the exact opposite of how >the term is normally used: > > No, it is not the opposite, it is the normal meaning. You're right, @frenchspacing as implemented is quite correct; I must have been low on caffeine when I thought otherwise. Sorry for the noise. > Also, frenchspacing is definitely not the usual typographic convention > in English-language typesetting, so I don't think GNU manuals written in > English should use it. Normal spacing in English is @frenchspacing off > (the default). > > Two space chars vs. one after periods in input files and typewriter-ish > contexts like Info is not exactly the same question as frenchspacing or > not. Not that I'm especially opposed to double spacing, – I'd just like to not have to be religious about requiring it unless single spaces cause an actual problem – but if @frenchspacing is orthogonal to the use of single spaces after a period in texinfo documents, will texinfo render badly spaced dvi (or other) if we use single spaces after a period, or even if we are inconsistent throughout an input document? For example, HTML really doesn't care, and renders output consistently no matter what spacing is used in the raw html document, and I'd be happy to learn that texinfo is the same. >Is there some other mandate that explains why we should go against >modern typographical conventions and insist on double spaces? > > I always thought it was (fundamentally) about Emacs as well. That's > what rms told me in 1985, anyway :). At any rate, the convention ever > since GNU started was to have two spaces at the end of sentences. I > never liked two spaces in my input files either, but I don't see any > percentage in changing it now. Well, I'm almost entirely ambivalent. But I'd certainly like to avoid having to count spaces during patch reviews. If double spaces turn out to be required in texinfo, then I'll write a maintainer make rule to check for violations - but, if single spaces are okay too, then we can all relax and type whatever our muscle memory prefers. > There are plenty of other GCS "rules"/conventions which not every > package follows, so if you can't bring yourself to type the extra space, > the world won't come to an end. Phew! ;-) Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH] maint: ship .xz, not .lzma
On 14 Sep 2010, at 11:58, Ralf Wildenhues wrote: > Hi Eric, > > * Eric Blake wrote on Mon, Sep 13, 2010 at 11:34:23PM CEST: >> * configure.ac (AM_INIT_AUTOMAKE): Prefer better file format. > >> Any objections to this patch? xz is a more robust successor to lzma. > > I'm fine with, if you also adjust HACKING, .gitignore, Makefile.maint. > We require new-enough Automake for the toplevel anyway now. Please give > Gary a couple of days to object, in case his release setup has other > requirements. No objections. I'm curious to know what the history of lzma and xz is that makes this desirable though. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
[PATCH] maint: improve README instructions for fetching latest version.
* README, README-alpha (Obtaining the Latest Sources): New section, describing use of savannah repositories and bootstrap. * README.alpha (Reporting Bugs): Remove git instructions in favour of a reference to the new `Obtaining the Latest Sources' section. Okay to push? --- ChangeLog|9 README | 47 - README.alpha | 59 - 3 files changed, 103 insertions(+), 12 deletions(-) diff --git a/ChangeLog b/ChangeLog index 543623f..4663c12 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2010-09-15 Gary V. Vaughan + + maint: improve README instructions for fetching latest version. + * README, README-alpha (Obtaining the Latest Sources): New + section, describing use of savannah repositories and bootstrap. + * README.alpha (Reporting Bugs): Remove git instructions in + favour of a reference to the new `Obtaining the Latest Sources' + section. + 2010-09-14 Eric Blake maint: ship .xz, not .lzma diff --git a/README b/README index 0c13518..780400a 100644 --- a/README +++ b/README @@ -113,7 +113,51 @@ If you wish to report test failures to the libtool list, you need to send the file `tests/testsuite.log' to the bug report mailing list, . -4. Version Numbering +4. Obtaining the Latest Sources +=== + +* The master libtool repository is stored in git. + + If you are a member of the savannah group for GNU Libtool, a writable + copy of the libtool repository can be obtained by: + +git clone @git.sv.gnu.org:/srv/git/libtool.git + + If you are behind a firewall that blocks the git protocol, you may + find it useful to use + +git config --global url.http://git.sv.gnu.org/r/.insteadof \ + git://git.sv.gnu.org/ + + to force git to transparently rewrite all savannah git references to + use http. + + If you are not a member of the savannah group for GNU Libtool, you can + still fetch a read-only copy with either: + +git clone git://git.sv.gnu.org/gnulib.git + + or using the CVS pserver protocol: + +cvs -d:pserver:anonym...@pserver.git.sv.gnu.org:/srv/git/gnulib.git \ +co -d gnulib HEAD + +* Before you can build from git, you need to bootstrap. This requires: + - Autoconf 2.62 or later + - Automake 1.11.1 or later + - Help2man 1.29 or later + - Xz 4.999.8beta or later (from <http://tukaani.org/xz) + - Texinfo 4.8 or later + - Any prerequisites of the above (such as m4, perl, tex) + + Note that these bootstrapping dependencies are much stricter that + required to use a destributed release for your own packages. After + installation, GNU Libtool is designed to work either standalone, or + optionally with: + - Autoconf 2.62 or later + - Automake 1.9.6 or later + +5. Version Numbering People have complained that they find the version numbering scheme under @@ -168,7 +212,6 @@ things: For more details about version numbers, see: http://www.gnu.org/software/libtool/contribute.html - -- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc. diff --git a/README.alpha b/README.alpha index 2632e75..4dc7534 100644 --- a/README.alpha +++ b/README.alpha @@ -21,21 +21,17 @@ subject line including the string `[PLATFORM]'. = If this distribution doesn't work for you, before you report the -problem, please try upgrading to the latest version from git first: - - git clone git://git.savannah.gnu.org/libtool.git - cd libtool - ./bootstrap +problem, please try upgrading to the latest version first (see +`Obtaining the latest sources' below). The `bootstrap' script sets up the source directory for you to hack, -though it may take quite some time to run. To use it, you need a recent -(maybe yet to be released) version of both Autoconf and Automake. If -you don't intend to run the test suite, you can speed up the `bootstrap' -step by an order of magnitude if you call it like this instead: +though it may take quite some time to run. If you don't intend to +re-run the test suite, you can speed up the `bootstrap' step by an +order of magnitude if you call it like this instead: reconfdirs='. libltdl' ./bootstrap -If your bug is not fixed in the latest version, please send a full +If your bug is still not fixed in the latest version, please send a full report to , including the information from the end of the help message given by `./libtool --help', and the verbose output of any failed test groups (as described below). @@ -109,6 +105,49 @@ If you wish to report test failures to the libtool list, you need to send the file `tests/testsuite.log' to the bug report mailing list, . +4. Obtaining the Latest Sources +=== + +* The master libtool repository is stored in git. + + If
Re: [PATCH] maint: improve README instructions for fetching latest version.
On 17 Sep 2010, at 00:24, Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf, > * Gary V. Vaughan wrote on Thu, Sep 16, 2010 at 04:49:47AM CEST: >> * README, README-alpha (Obtaining the Latest Sources): New >> section, describing use of savannah repositories and bootstrap. >> * README.alpha (Reporting Bugs): Remove git instructions in >> favour of a reference to the new `Obtaining the Latest Sources' >> section. >> >> Okay to push? > > Sure, with a couple of nits addressed. Oops. Thanks for the review. Pushed. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
README cleanups
With the recent additions I made to README, I noticed that we're maintaining a lot of duplicated redundant information, and also that README and README.alpha have needlessly drifted apart, effectively hiding useful information from users of our alpha and stable release tarballs. All but the last patch in this series consolidate the differences between these two files to make sure all the useful README details are shipped in both alpha and stable releases. At that point, the only difference remaining is the wording of the very first paragraph - rather than having to make future additions to both files, I've deleted README.alpha and replaced it with a dist-time sed script which edits the README file in situ to contain the alpha wording, along with a change to the Makefile dist-hook rule to call it. Tested by inspecting the contents of README in a tarball after `make dist' with the AC_INIT version number set to 2.2.11a and 2.4.0 respectively. Okay to push? Cheers, -- Gary V. Vaughan (g...@gnu.org)
[PATCH 3/6] maint: improve `Reporting Bugs' in README and README.alpha.
* README (Reporting Bugs): Rewritten to a more complete and concise guide to providing a good bug report. * README.alpha (Reporting Bugs): Adjust to match. --- ChangeLog|5 + README | 36 +++- README.alpha | 44 ++-- 3 files changed, 66 insertions(+), 19 deletions(-) diff --git a/ChangeLog b/ChangeLog index 9db58e1..2e04bda 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2010-09-18 Gary V. Vaughan + maint: improve `Reporting Bugs' in README and README.alpha. + * README (Reporting Bugs): Rewritten to a more complete and + concise guide to providing a good bug report. + * README.alpha (Reporting Bugs): Adjust to match. + maint: consolidate Introductions of README and README.alpha. * README (Introduction): Rewritten to a more logical order for first time users, incorporating some additional text that was diff --git a/README b/README index acf8f8b..a40f96c 100644 --- a/README +++ b/README @@ -39,11 +39,37 @@ details. 2. Reporting Bugs = -If you have any suggestions or bug reports, or you wish to port Libtool -to a new platform, please send electronic mail to the libtool mailing -list or bug reports to . Be sure -to send us your information from the end of the help message given by -`./libtool --help'. +If this distribution doesn't work for you, before you report the +problem, at least try upgrading to the latest released version first, +and see whether the issue persists. If you feel able, you can also +check whether the issue has been fixed in the development sources for +the next release (see `Obtaining the Latest Sources' below). + +Once you've determined that your bug is still not fixed in the latest +version, please send a full report to , including: + + 1. the information from the end of the help message given by + `./libtool --help', and the verbose output of any failed tests + (see `The Test Suites' immediately below); + 2. complete instructions for how to reproduce your bug, along with + the results you were expecting, and how they differ from what you + actually see; + 3. a workaround or full fix for the bug, if you have it; + 4. a copy of `tests/testsuite.log' if you are experiencing failures + in the Autotest testsuite. + 5. new test cases for the testsuite that demonstrate the bug are + especially welcome, and will help to ensure that future releases + don't reintroduce the problem - if you're not able to write a + complete testsuite case, a simple standalone shell script is + usually good enough to help us write a test for you. + +If you have any other suggestions, or if you wish to port Libtool to a +new platform, please send email to the mailing list . + +Please note that if you send us an non-trivial code for inclusion in a +future release, we may ask you for a copyright assignment (for brief +details see the `Copyright Assignment' section on our `Contributing' +webpage <http://www.gnu.org/software/libtool/contribute.html>). 3. The Test Suites diff --git a/README.alpha b/README.alpha index 6f4ed3b..a8912a6 100644 --- a/README.alpha +++ b/README.alpha @@ -40,20 +40,36 @@ details. = If this distribution doesn't work for you, before you report the -problem, please try upgrading to the latest version first (see -`Obtaining the latest sources' below). - -The `bootstrap' script sets up the source directory for you to hack, -though it may take quite some time to run. If you don't intend to -re-run the test suite, you can speed up the `bootstrap' step by an -order of magnitude if you call it like this instead: - - reconfdirs='. libltdl' ./bootstrap - -If your bug is still not fixed in the latest version, please send a full -report to , including the information from the end -of the help message given by `./libtool --help', and the verbose output -of any failed test groups (as described below). +problem, at least try upgrading to the latest released version first, +and see whether the issue persists. If you feel able, you can also +check whether the issue has been fixed in the development sources for +the next release (see `Obtaining the Latest Sources' below). + +Once you've determined that your bug is still not fixed in the latest +version, please send a full report to , including: + + 1. the information from the end of the help message given by + `./libtool --help', and the verbose output of any failed tests + (see `The Test Suites' immediately below); + 2. complete instructions for how to reproduce your bug, along with + the results you were expecting, and how they differ from what you + actually see; + 3. a workaround or full fix for the bug, if you have it; + 4. a copy of `tests/testuite.log' if
[PATCH 2/6] maint: consolidate Introductions of README and README.alpha.
* README (Introduction): Rewritten to a more logical order for first time users, incorporating some additional text that was previously only in README.alpha. * README.alpha (Introduction): Adjust to match. --- ChangeLog|6 ++ README | 30 -- README.alpha | 37 - 3 files changed, 54 insertions(+), 19 deletions(-) diff --git a/ChangeLog b/ChangeLog index 3e1cb95..9db58e1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2010-09-18 Gary V. Vaughan + maint: consolidate Introductions of README and README.alpha. + * README (Introduction): Rewritten to a more logical order for + first time users, incorporating some additional text that was + previously only in README.alpha. + * README.alpha (Introduction): Adjust to match. + maint: copy the Version Numbering section into README.alpha. * README.alpha (Version Numbering): No less useful for users of alpha releases. Copied from README. diff --git a/README b/README index 16328bb..acf8f8b 100644 --- a/README +++ b/README @@ -8,22 +8,32 @@ This is GNU Libtool, a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. -To use Libtool, add the new generic library building commands to your -Makefile, Makefile.in, or Makefile.am. See the documentation for -details. - Libtool's home page is: - http://www.gnu.org/software/libtool/libtool.html +http://www.gnu.org/software/libtool/libtool.html See the file NEWS for a description of recent changes to Libtool. -See the file INSTALL for generic instructions on how to build and install -Libtool. Please see the file doc/notes.txt for some platform-specific -information. Please note that you need GNU make to build Libtool. +See the file INSTALL for generic instructions on how to build and +install Libtool. Please see the file doc/notes.txt for some platform- +specific information. Please note that you need GNU make to build +Libtool. + +See the info node (libtool)Tested Platforms. (or the file doc/PLATFORMS) +for a list of platforms that Libtool already supports. -See the info node (libtool)Tested Platforms. (or the file -doc/PLATFORMS) for a list of platforms that Libtool supports. +Please try it on all the platforms you have access to: + + * If it builds and passes the test suite (`gmake check'), please send + a short note to the libtool mailing list with a + subject line including the string `[PLATFORM]', and containing the + details from the end of `./libtool --help' in the body. + * Otherwise, see `Reporting Bugs' below for how to help us fix any + problems you discover. + +To use Libtool, add the new generic library building commands to your +Makefile, Makefile.in, or Makefile.am. See the documentation for +details. 2. Reporting Bugs diff --git a/README.alpha b/README.alpha index 8c72c03..6f4ed3b 100644 --- a/README.alpha +++ b/README.alpha @@ -4,17 +4,36 @@ GNU Libtool 1. Introduction === -This is an alpha testing release of GNU Libtool, please try it on all -the platforms you have access to. Using it more or less implicitly -signs you up to help us find whatever problems you report. +This is an alpha testing release of GNU Libtool, a generic library +support script. Libtool hides the complexity of using shared libraries +behind a consistent, portable interface. -See the file INSTALL for generic instructions on how to build and install -Libtool. Please see the file doc/notes.txt for some platform-specific -information. Please note that you need GNU make to build Libtool. +Libtool's home page is: -If it builds and passes the test suite (`gmake check'), please send -notification to the libtool mailing list with a -subject line including the string `[PLATFORM]'. +http://www.gnu.org/software/libtool/libtool.html + +See the file NEWS for a description of recent changes to Libtool. + +See the file INSTALL for generic instructions on how to build and +install Libtool. Please see the file doc/notes.txt for some platform- +specific information. Please note that you need GNU make to build +Libtool. + +See the info node (libtool)Tested Platforms. (or the file doc/PLATFORMS) +for a list of platforms that Libtool already supports. + +Please try it on all the platforms you have access to: + + * If it builds and passes the test suite (`gmake check'), please send + a short note to the libtool mailing list with a + subject line including the string `[PLATFORM]', and containing the + details from the end of `./libtool --help' in the body. + * Otherwise, see `Reporting Bugs' below for how to help us fix any + problems you discover. + +To use Libtool, add the new generic library building commands to your +Makefile, Makefile.in, or Makefile.am. See the documentation for +details. 2. Reporting Bugs -- 1.7.2.2
[PATCH 4/6] maint: reformat README `The Test Suites' for consistency.
* README (The Test Suites): Reformatted for consistency. * README.alpha (The Test Suites): Adjust to match. --- ChangeLog|4 README | 38 -- README.alpha | 39 +-- 3 files changed, 49 insertions(+), 32 deletions(-) diff --git a/ChangeLog b/ChangeLog index 2e04bda..25c23db 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2010-09-18 Gary V. Vaughan + maint: reformat README `The Test Suites' for consistency. + * README (The Test Suites): Reformatted for consistency. + * README.alpha (The Test Suites): Adjust to match. + maint: improve `Reporting Bugs' in README and README.alpha. * README (Reporting Bugs): Rewritten to a more complete and concise guide to providing a good bug report. diff --git a/README b/README index a40f96c..efd678d 100644 --- a/README +++ b/README @@ -79,15 +79,15 @@ Libtool comes with two integrated sets of tests to check that your build is sane. You can run both test suites like this, assuming that `gmake' refers to GNU make: - gmake -k check +gmake -k check If you want to run the old testsuite only, do it like this: - gmake check TESTSUITEFLAGS=-V +gmake check TESTSUITEFLAGS=-V If you want to run the new testsuite only, do it like this: - gmake check-local +gmake check-local The tests of the old test suite run in groups in the various demo subdirectories, so if one of the tests early in a group FAILs, the rest @@ -100,9 +100,8 @@ To run a test group of the old test suite in isolation (say, you think you have fixed a bug, but don't want to rerun the entire suite), you can do it like this: - gmake check TESTS="tests/cdemo-static.test tests/cdemo-static-make.test \ - tests/cdemo-static-exec.test" \ - TESTSUITEFLAGS=-V +gmake check TESTSUITEFLAGS=-V TESTS="tests/cdemo-static.test \ +tests/cdemo-static-make.test tests/cdemo-static-exec.test" Providing that you have a FAIL from the most recent group from a particular demo directory (like the cdemo-static.test group above), you @@ -118,37 +117,40 @@ the verbose output from all failed tests. In order to enable debug shell tracing, you can set VERBOSE=debug when running the old test suite. +In the long run, Libtool will move to using only the new, Autotest- +driven testsuite. Its usage is documented in: -In the long run, Libtool will move to using only the new, -Autotest-driven testsuite. Its usage is documented in +info Autoconf 'testsuite Invocation' - info Autoconf 'testsuite Invocation' +but simple help may also be obtained through: -but simple help may also be obtained through - - gmake check-local TESTSUITEFLAGS='--help' +gmake check-local TESTSUITEFLAGS='--help' For verbose output, add the flag `-v', for running only a subset of the independent tests, merely specify them by number or by keyword, both of which are displayed with the `--list' flag. For example, the `libtool' keyword is used for the tests that exercise only this script. So it is possible to test an installed script, possibly from a different Libtool -release, with - gmake check-local TESTSUITEFLAGS="-k libtool LIBTOOL=/path/to/libtool" +release, with: + +gmake check-local \ +TESTSUITEFLAGS="-k libtool LIBTOOL=/path/to/libtool" Some tests, like the one exercising max_cmd_len limits, make use of this to invoke the testsuite recursively on a subset of tests. For these tests, the variable INNER_TESTSUITEFLAGS may be used. It will be -expanded right after the `-k libtool', without separating whitespace, -so that further limiting of the recursive set of tests is possible. -For example, to run only the template tests within the max_cmd_len, use - gmake check-local TESTSUITEFLAGS="-v -x -k max_cmd_len \ +expanded right after the `-k libtool', without separating whitespace, so +that further limiting of the recursive set of tests is possible. For +example, to run only the template tests within the max_cmd_len, use: + +gmake check-local TESTSUITEFLAGS="-v -x -k max_cmd_len \ INNER_TESTSUITEFLAGS=',template -v -x'" If you wish to report test failures to the libtool list, you need to send the file `tests/testsuite.log' to the bug report mailing list, . + 4. Obtaining the Latest Sources === diff --git a/README.alpha b/README.alpha index a8912a6..5082ed3 100644 --- a/README.alpha +++ b/README.alpha @@ -79,15 +79,15 @@ Libtool comes with two integrated sets of tests to check that your build is sane. You can run both test suites like this, assuming that `gmake' refers to GNU make: - gmake -k check +gmake -k check If you want to run the old testsuite only, do it like t
[PATCH 5/6] maint: improve README's `Obtaining the Latest Sources'.
* README (Obtaining the Latest Sources): Add instructions for obtaining stable, alpha and nightly snapshot tarballs. * README.alpha (Obtaining the Latest Sources): Adjust to match. --- ChangeLog|5 + README | 56 +++- README.alpha | 56 +++- 3 files changed, 115 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 25c23db..a4781d9 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2010-09-18 Gary V. Vaughan + maint: improve README's `Obtaining the Latest Sources'. + * README (Obtaining the Latest Sources): Add instructions for + obtaining stable, alpha and nightly snapshot tarballs. + * README.alpha (Obtaining the Latest Sources): Adjust to match. + maint: reformat README `The Test Suites' for consistency. * README (The Test Suites): Reformatted for consistency. * README.alpha (The Test Suites): Adjust to match. diff --git a/README b/README index efd678d..21bfe21 100644 --- a/README +++ b/README @@ -154,6 +154,52 @@ send the file `tests/testsuite.log' to the bug report mailing list, 4. Obtaining the Latest Sources === +* With the exception of ancient releases, all official GNU Libtool + releases have a detached GPG signature file. With this you can verify + that the corresponding file (i.e. without the `.sig' suffix) is the + same file that was released by the owner of it's GPG key ID. First, + be sure to download both the .sig file and the corresponding release, + then run a command like this: + +gpg --verify libtool-x.y.z.tar.gz.sig + + If that command fails because you don't have the required public key, + then run this command to import it: + +gpg --keyserver keys.gnupg.net --recv-keys 2983D606 + + and then rerun the `gpg --verify' command. + +* Official stable releases of GNU Libtool, along with these detached + signature files are available from: + +ftp://ftp.gnu.org/gnu/libtool + + To reduce load on the main server, please use one of the mirrors + listed at: + +http://www.gnu.org/order/ftp.html + +* Alpha quality pre-releases of GNU Libtool, also with detached + signature files are available from: + +ftp://alpha.gnu.org/gnu/libtool + + and some of the mirrors listed at: + +http://www.gnu.org/order/ftp.html + +* Nightly snapshots of the unreleased development trunk of GNU Libtool + are available from: + +http://pogma.com/libtool + + These files do not have signatures, but will allow you to easily + determine whether the most recent development code still exhibits any + bugs you have discovered, without requiring you to install a complete + build environment and the extra tools needed to bootstrap a version + control checkout. + * The master libtool repository is stored in git. If you are a member of the savannah group for GNU Libtool, a writable @@ -195,6 +241,14 @@ send the file `tests/testsuite.log' to the bug report mailing list, - Autoconf 2.59 or later - Automake 1.9.6 or later +* The `bootstrap' script sets up the source directory for you to hack, + though it may take quite some time to run. If you don't intend to + re-run the test suite, you can speed up the `bootstrap' step by an + order of magnitude if you call it like this instead: + +reconfdirs='. libltdl' ./bootstrap + + 5. Version Numbering @@ -250,7 +304,7 @@ things: For more details about version numbers, see: http://www.gnu.org/software/libtool/contribute.html --- +-- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc. Written by Gary V. Vaughan, 2004 diff --git a/README.alpha b/README.alpha index 5082ed3..1771124 100644 --- a/README.alpha +++ b/README.alpha @@ -154,6 +154,52 @@ send the file `tests/testsuite.log' to the bug report mailing list, 4. Obtaining the Latest Sources === +* With the exception of ancient releases, all official GNU Libtool + releases have a detached GPG signature file. With this you can verify + that the corresponding file (i.e. without the `.sig' suffix) is the + same file that was released by the owner of it's GPG key ID. First, + be sure to download both the .sig file and the corresponding release, + then run a command like this: + +gpg --verify libtool-x.y.z.tar.gz.sig + + If that command fails because you don't have the required public key, + then run this command to import it: + +gpg --keyserver keys.gnupg.net --recv-keys 2983D606 + + and then rerun the `gpg --verify' command. + +* Official stable releases of GNU Libtool, along with these detached + signature files are available from: + +ftp://ftp.gnu.org/gnu/libtool + + To reduce load on the main server, please use o
[PATCH 6/6] maint: use sed instead of maintaining 2 README files.
* README.alpha: Deleted. It was mostly identical to README. * libltdl/config/edit-readme-alpha: New script to edit the contents of README in the dist tree prior to tarring up. * Makefile.am (dist-hook): Run it before rolling alpha release tarball. --- ChangeLog|7 + Makefile.am | 11 +- README.alpha | 324 -- libltdl/config/edit-readme-alpha | 49 ++ 4 files changed, 63 insertions(+), 328 deletions(-) delete mode 100644 README.alpha create mode 100755 libltdl/config/edit-readme-alpha diff --git a/ChangeLog b/ChangeLog index a4781d9..05c4466 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,12 @@ 2010-09-18 Gary V. Vaughan + maint: use sed instead of maintaining 2 README files. + * README.alpha: Deleted. It was mostly identical to README. + * libltdl/config/edit-readme-alpha: New script to edit the + contents of README in the dist tree prior to tarring up. + * Makefile.am (dist-hook): Run it before rolling alpha release + tarball. + maint: improve README's `Obtaining the Latest Sources'. * README (Obtaining the Latest Sources): Add instructions for obtaining stable, alpha and nightly snapshot tarballs. diff --git a/Makefile.am b/Makefile.am index dcd0876..6e29a29 100644 --- a/Makefile.am +++ b/Makefile.am @@ -406,6 +406,10 @@ install-data-local: libltdl/Makefile.in ## Distribution. ## ## - ## +edit_readme_alpha = $(auxdir)/edit-readme-alpha + +EXTRA_DIST += $(edit_readme_alpha) + uninstall-hook: @$(NORMAL_UNINSTALL) @list='$(ltdldatafiles) $(auxfiles)'; for f in $$list; do \ @@ -419,11 +423,10 @@ uninstall-hook: done dist-hook: -## Ship README.alpha only in alpha release, but renamed to README - @if test -f $(srcdir)/README.alpha; then \ +## Edit the README file for alpha releases. case $(VERSION) in \ - *[a-z]) cp -p $(srcdir)/README.alpha $(distdir)/README ;; \ - esac; else :; fi + *[a-z]) $(SHELL) $(srcdir)/$(edit_readme_alpha) $(distdir)/README ;; \ + esac ## Ensure aclocal has not wrongly picked up old macro definitions. for macro in LT_INIT AC_PROG_LIBTOOL AM_PROG_LIBTOOL; do \ if grep $$macro $(srcdir)/aclocal.m4 $(srcdir)/libltdl/aclocal.m4; then \ diff --git a/README.alpha b/README.alpha deleted file mode 100644 index 1771124..000 --- a/README.alpha +++ /dev/null @@ -1,324 +0,0 @@ -GNU Libtool -*** - -1. Introduction -=== - -This is an alpha testing release of GNU Libtool, a generic library -support script. Libtool hides the complexity of using shared libraries -behind a consistent, portable interface. - -Libtool's home page is: - -http://www.gnu.org/software/libtool/libtool.html - -See the file NEWS for a description of recent changes to Libtool. - -See the file INSTALL for generic instructions on how to build and -install Libtool. Please see the file doc/notes.txt for some platform- -specific information. Please note that you need GNU make to build -Libtool. - -See the info node (libtool)Tested Platforms. (or the file doc/PLATFORMS) -for a list of platforms that Libtool already supports. - -Please try it on all the platforms you have access to: - - * If it builds and passes the test suite (`gmake check'), please send - a short note to the libtool mailing list with a - subject line including the string `[PLATFORM]', and containing the - details from the end of `./libtool --help' in the body. - * Otherwise, see `Reporting Bugs' below for how to help us fix any - problems you discover. - -To use Libtool, add the new generic library building commands to your -Makefile, Makefile.in, or Makefile.am. See the documentation for -details. - - -2. Reporting Bugs -= - -If this distribution doesn't work for you, before you report the -problem, at least try upgrading to the latest released version first, -and see whether the issue persists. If you feel able, you can also -check whether the issue has been fixed in the development sources for -the next release (see `Obtaining the Latest Sources' below). - -Once you've determined that your bug is still not fixed in the latest -version, please send a full report to , including: - - 1. the information from the end of the help message given by - `./libtool --help', and the verbose output of any failed tests - (see `The Test Suites' immediately below); - 2. complete instructions for how to reproduce your bug, along with - the results you were expecting, and how they differ from what you - actually see; - 3. a workaround or full fix for the bug, if you have it; - 4. a copy of `tests/testuite.log' if you are experiencing failures - in the Autotest testsuite. - 5. new test cases for the testsuite that demonstrate the bug
[PATCH 1/6] maint: copy the Version Numbering section into README.alpha.
* README.alpha (Version Numbering): No less useful for users of alpha releases. Copied from README. --- ChangeLog|6 ++ README.alpha | 56 2 files changed, 62 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index d72d9e0..3e1cb95 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2010-09-18 Gary V. Vaughan + + maint: copy the Version Numbering section into README.alpha. + * README.alpha (Version Numbering): No less useful for users + of alpha releases. Copied from README. + 2010-09-17 Peter Rosin tests: actually detect missing 'test' in 'if "$foo" = ...'. diff --git a/README.alpha b/README.alpha index a58167e..8c72c03 100644 --- a/README.alpha +++ b/README.alpha @@ -148,6 +148,62 @@ send the file `tests/testsuite.log' to the bug report mailing list, or optionally with: - Autoconf 2.59 or later - Automake 1.9.6 or later + +5. Version Numbering + + +People have complained that they find the version numbering scheme under +which libtool is released confusing... so we've changed it! + +It works like this: + + . + +Releases with a less than 1 were not yet feature +complete. Releases with a of 1 used the old numbering +scheme that everyone disliked so much. Releases with a +of 2 us the new scheme described here. If libtool ever undergoes a +major rewrite or substantial restructuring, the will be +incremented again. + +If we make a patch release to fix bugs in a stable release, we use a +third number, so: + + .. + +Version numbers are chosen to make it easy for users to decide two +things: + + Q: How `developed' is this release? + A: The higher the number, the better! + Q: How `stable' is this release? + A: - If the is even, it is a stable release, `2.0'. + - If the is odd, it is a development version with + new features compared to the last stable release, `2.1a'. + - If it has an `odd'[1] letter after the version number, it is a + snapshot direct from CVS, `2.1a'. + - If it has an `even'[1] letter after the version number, it is an + alpha quality release, `2.1b'. + - If it has three numbers in the version, it is a patch release, + fixing bugs from the stable release (with no new features), `2.0.1'. + +[1] We always increment the letter in the repository before *and* after +making a release tarball. This means that "odd" letters +(a,c,e,g...) only exist in the repository, and "even" letters are +used instantaneously for an alpha release. Since the odd lettered +version numbers cover many states of the tree, we also qualify them +by adding the cvs version of the ChangeLog: + +$ libtool --version +ltmain.sh (GNU libtool 1.1603 2004/09/12 22:02:07) 2.1a + +Copyright (C) 2004 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +For more details about version numbers, see: + +http://www.gnu.org/software/libtool/contribute.html -- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc. -- 1.7.2.2
Re: [PATCH 2/6] maint: consolidate Introductions of README and README.alpha.
[[top-post re-ordered]] Hi Bob, Thanks for the reviews. > On Sat, 18 Sep 2010, Gary V. Vaughan wrote: > >> * README (Introduction): Rewritten to a more logical order for >> first time users, incorporating some additional text that was >> previously only in README.alpha. >> * README.alpha (Introduction): Adjust to match. >> --- >> ChangeLog|6 ++ >> README | 30 -- >> README.alpha | 37 - >> 3 files changed, 54 insertions(+), 19 deletions(-) >> >> diff --git a/ChangeLog b/ChangeLog >> index 3e1cb95..9db58e1 100644 >> --- a/ChangeLog >> +++ b/ChangeLog >> @@ -1,5 +1,11 @@ >> 2010-09-18 Gary V. Vaughan >> >> +maint: consolidate Introductions of README and README.alpha. >> +* README (Introduction): Rewritten to a more logical order for >> +first time users, incorporating some additional text that was >> +previously only in README.alpha. >> +* README.alpha (Introduction): Adjust to match. >> + >> maint: copy the Version Numbering section into README.alpha. >> * README.alpha (Version Numbering): No less useful for users >> of alpha releases. Copied from README. >> diff --git a/README b/README >> index 16328bb..acf8f8b 100644 >> --- a/README >> +++ b/README >> @@ -8,22 +8,32 @@ This is GNU Libtool, a generic library support script. >> Libtool hides >> the complexity of using shared libraries behind a consistent, portable >> interface. >> >> -To use Libtool, add the new generic library building commands to your >> -Makefile, Makefile.in, or Makefile.am. See the documentation for >> -details. >> - >> Libtool's home page is: >> >> - http://www.gnu.org/software/libtool/libtool.html >> +http://www.gnu.org/software/libtool/libtool.html >> >> See the file NEWS for a description of recent changes to Libtool. >> >> -See the file INSTALL for generic instructions on how to build and install >> -Libtool. Please see the file doc/notes.txt for some platform-specific >> -information. Please note that you need GNU make to build Libtool. >> +See the file INSTALL for generic instructions on how to build and >> +install Libtool. Please see the file doc/notes.txt for some platform- >> +specific information. Please note that you need GNU make to build >> +Libtool. >> + >> +See the info node (libtool)Tested Platforms. (or the file doc/PLATFORMS) >> +for a list of platforms that Libtool already supports. >> >> -See the info node (libtool)Tested Platforms. (or the file >> -doc/PLATFORMS) for a list of platforms that Libtool supports. >> +Please try it on all the platforms you have access to: >> + >> + * If it builds and passes the test suite (`gmake check'), please send >> + a short note to the libtool mailing list with a >> + subject line including the string `[PLATFORM]', and containing the >> + details from the end of `./libtool --help' in the body. >> + * Otherwise, see `Reporting Bugs' below for how to help us fix any >> + problems you discover. >> + >> +To use Libtool, add the new generic library building commands to your >> +Makefile, Makefile.in, or Makefile.am. See the documentation for >> +details. >> >> >> 2. Reporting Bugs >> diff --git a/README.alpha b/README.alpha >> index 8c72c03..6f4ed3b 100644 >> --- a/README.alpha >> +++ b/README.alpha >> @@ -4,17 +4,36 @@ GNU Libtool >> 1. Introduction >> === >> >> -This is an alpha testing release of GNU Libtool, please try it on all >> -the platforms you have access to. Using it more or less implicitly >> -signs you up to help us find whatever problems you report. >> +This is an alpha testing release of GNU Libtool, a generic library >> +support script. Libtool hides the complexity of using shared libraries >> +behind a consistent, portable interface. >> >> -See the file INSTALL for generic instructions on how to build and install >> -Libtool. Please see the file doc/notes.txt for some platform-specific >> -information. Please note that you need GNU make to build Libtool. >> +Libtool's home page is: >> >> -If it builds and passes the test suite (`gmake check'), please send >> -notification to the libtool mailing list with a >> -subject line including the string `[PLATFORM]'. >> +http://www.gnu.org/software/libtool/libtool.html >> + >> +See the file NEWS for a description
Re: README cleanups
Hallo Ralf, Thanks for the reviews. On 18 Sep 2010, at 13:15, Ralf Wildenhues wrote: > > * Gary V. Vaughan wrote on Sat, Sep 18, 2010 at 07:20:12AM CEST: >> Okay to push? > > I'm fine with this patch series. Thanks. Pushing... > A minor nit: users don't really need GNU make to build Libtool from a > release tarball unless they want to do VPATH builds. This was stated > before your patch though. (For a git checkout, I think GNU make may be > necessary.) The INSTALL file should already warn about non-GNU make and > VPATH anyway. I've amended the wording of that paragraph in 1/6 to now read: "Please note that you can build GNU Libtool from this directory using a vendor Make program as long as this is an official release tarball; otherwise you will need GNU Make for sane VPATH support. See the file INSTALL for complete generic instructions on how to build and install Libtool. Also, see the file doc/notes.txt for some platform- specific information." Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 6/6] maint: use sed instead of maintaining 2 README files.
On 18 Sep 2010, at 13:40, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Sat, Sep 18, 2010 at 07:20:18AM CEST:
>> * README.alpha: Deleted. It was mostly identical to README.
>> * libltdl/config/edit-readme-alpha: New script to edit the
>> contents of README in the dist tree prior to tarring up.
>> * Makefile.am (dist-hook): Run it before rolling alpha release
>> tarball.
>
> For what it's worth ...
>
>> --- /dev/null
>> +++ b/libltdl/config/edit-readme-alpha
>
>> +for file in "$@"; do
>> + trap 'x=$?; rm $file.T; exit $x' 1 2 13 15
>> +
>> + sed -e '/^This is GNU Libtool,/,/^interface.$/c\
>> +This is an alpha testing release of GNU Libtool, a generic library\
>> +support script. Libtool hides the complexity of using shared libraries\
>> +behind a consistent, portable interface.' $file > $file.T \
>
> this script will wrongly exit with status 0 if the stdout redirection
> fails at this point.
Ah, true. I was trying to keep the script simple, and overdid it a bit. In
light of that, and my having noticed that the script also didn't complain if
sed was unable to match any text to edit, I've now improved the script thus:
> EXIT_SUCCESS=0
> EXIT_FAILURE=1
>
> # Work around backward compatibility issue on IRIX 6.5. On IRIX 6.4+, sh
> # is ksh but when the shell is invoked as "sh" and the current value of
> # the _XPG environment variable is not equal to 1 (one), the special
> # positional parameter $0, within a function call, is the name of the
> # function.
> progpath="$0"
>
> # The name of this program:
> progname=`echo "$progpath" |sed 's|^.*/||'`
>
>
> # func_fatal_error ARG...
> # ---
> # Echo program name prefixed message to standard error, and exit.
> func_fatal_error ()
> {
> echo "$progname: $*" >&2
> exit $EXIT_FAILURE
> }
>
>
> for file in "$@"; do
> # Make sure the paragraph we are matching has not been edited since
> # this script was written.
> matched=`sed -n -e '/^This is GNU Libtool,/,/^interface.$/p' $file \
> |wc -l |sed 's|^ *||'`
> test 3 = "$matched" \
> || func_fatal_error "$file format has changed, please fix \`$0'"
>
> # Don't leave file droppings.
> trap 'x=$?; rm $file.T; exit $x' 1 2 13 15
>
> # Edit the first paragraph to be suitable for an alpha release.
> sed -e '/^This is GNU Libtool,/,/^interface.$/c\
> This is an alpha testing release of GNU Libtool, a generic library\
> support script. Libtool hides the complexity of using shared libraries\
> behind a consistent, portable interface.' $file > $file.T
>
> # Diagnose redirection failure.
> test -f $file.T || func_fatal_error "Unable to write $file.T"
>
> # Overwrite the original file with our edited version.
> mv $file.T $file || func_fatal_error "Unable to edit $file"
> done
>
> exit $EXIT_SUCCESS
Retested with version 2.2.11a and version 2.4.0 before pushing.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
Re: [PATCH 2/6] maint: consolidate Introductions of README and README.alpha.
On 19 Sep 2010, at 14:34, Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf, > * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 04:49:34AM CEST: >> In due course, I'd rather try to encourage people to install >> autobuild, and submit results there, than waste time maintaining a >> parallel list in PLATFORMS manually. But I won't have time to get to >> that for a while, nor is it urgent while our autobuild support in the >> libtool tree is still incomplete. > > I agree that autobuild should not be optional. I think a good idea is > to let bootstrap install autobuild.m4 (from gnulib, once you've > converted it that way). That patch is done already, although it is later in the queue than the bootstrap import from gnulib, which I'm almost done rewriting. However, the queue is becoming rather long, so I'll drip feed the patches to the list starting right after the release, to leave me with the flexiblity to edit and rebase the remainder as we progress. > I'll try to finish the mode setting patch by then. Cool. Thanks =)O| Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
[PATCH] maint: edit-readme-alpha shouldn't try to re-edit during dist.
Hallo Ralf,
On 21 Sep 2010, at 00:34, Ralf Wildenhues wrote:
> a regression: this code will cause 'make distcheck' to
> fail, because at 'make dist' time the file will be rewritten before
> being added to the tarball (if the version doesn't indicate a stable
> release), then when distcheck tries to create yet another tarball, the
> above check will catch:
>
> | case 2.2.11a in \
> | *[a-z]) /bin/sh ../libltdl/config/edit-readme-alpha
> libtool-2.2.11a/README ;; \
> | esac
> | edit-readme-alpha: libtool-2.2.11a/README format has changed, please fix
> `../libltdl/config/edit-readme-alpha'
> | make[3]: *** [dist-hook] Error 1
> | make[3]: *** Waiting for unfinished jobs
Ah. D'oh.
Well, it does at least show that the script interacts correctly with
an error for make to help catch the case where someone commits a change
to the first paragraph of README without a matching edit to the sed
expressions in edit-readme-alpha.
Here is (an overkill) patch to not exit with an error, so that `make
distcheck' can complete.
Okay to push?
* libltdl/config/edit-readme-alpha: If README is non-writable
assume that it is being run from distcheck, and bail out with
a warning (to help diagnose cases where the heuristic is not
correct). However, if README has already been edited to the
alpha text, quietly skip without an error message.
---
ChangeLog|9 +
libltdl/config/edit-readme-alpha | 15 ++-
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ceb193c..342c2ed 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-09-21 Gary V. Vaughan
+
+ maint: edit-readme-alpha shouldn't try to re-edit during dist.
+ * libltdl/config/edit-readme-alpha: If README is non-writable
+ assume that it is being run from distcheck, and bail out with
+ a warning (to help diagnose cases where the heuristic is not
+ correct). However, if README has already been edited to the
+ alpha text, quietly skip without an error message.
+
2010-09-20 Eric Blake
maint: drop autobuild requirement
diff --git a/libltdl/config/edit-readme-alpha b/libltdl/config/edit-readme-alpha
index 6070a31..c60fbc0 100755
--- a/libltdl/config/edit-readme-alpha
+++ b/libltdl/config/edit-readme-alpha
@@ -55,10 +55,23 @@ func_fatal_error ()
for file in "$@"; do
+ # Assume that read-only README indicates that we are running inside
+ # the latter part of a `make distcheck'.
+ test -w $file || {
+echo "$progname: not editing non-writeable \`$file' (distcheck?)"
+continue
+ }
+
# Make sure the paragraph we are matching has not been edited since
# this script was written.
- matched=`sed -n -e '/^This is GNU Libtool,/,/^interface.$/p' $file \
+ matched=`sed -n -e '/^This is GNU Libtool,/,/^interface\.$/p' $file \
|wc -l |sed 's|^ *||'`
+
+ # Unless, of course, it was edited by this script already.
+ test 3 = "$matched" \
+ || matched=`sed -n -e '/^This is an alpha testing release/,/behind a
consistent, portable interface\.$/p' $file \
+ |wc -l |sed 's|^ *||'`
+
test 3 = "$matched" \
|| func_fatal_error "$file format has changed, please fix \`$0'"
--
1.7.2.2
Re: [PATCH] maint: edit-readme-alpha shouldn't try to re-edit during dist.
On 21 Sep 2010, at 12:07, Ralf Wildenhues wrote:
> Hi Gary,
Hallo Ralf,
Thanks again for the review.
> * Gary V. Vaughan wrote on Tue, Sep 21, 2010 at 03:05:46AM CEST:
>> Well, it does at least show that the script interacts correctly with
>> an error for make to help catch the case where someone commits a change
>> to the first paragraph of README without a matching edit to the sed
>> expressions in edit-readme-alpha.
>>
>> Here is (an overkill) patch to not exit with an error, so that `make
>> distcheck' can complete.
>>
>> Okay to push?
>
> Well, I don't want to appear overly nitpicky for this issue,
> but if you don't absolutely need to check and skip non-writable files,
> I wouldn't do it, and rather error out in that case.
Well, the thing that is screwing up distcheck is when the distribution
tarball is unpacked into a read-only tree, and edit-readme-alpha wants
to rewrite the file again...
...although, the "don't re-edit when the alpha text is already there"
check later on should catch this already. Although I feel happier with
both checks in place, I'll remove the writeable test if you'd prefer.
>> * libltdl/config/edit-readme-alpha: If README is non-writable
>> assume that it is being run from distcheck, and bail out with
>> a warning
>
> FWIW, exiting 0 is not what I'd call "bail out".
I mean "bail out" as in: don't do the rest of the processing.
>> for file in "$@"; do
>> + # Assume that read-only README indicates that we are running inside
>> + # the latter part of a `make distcheck'.
>> + test -w $file || {
>> +echo "$progname: not editing non-writeable \`$file' (distcheck?)"
>
> If you prefer to, or need to keep the warning+skip, I suggest to
> print warnings on stderr.
Oops. Well caught, thanks.
>> +continue
>> + }
>> +
>> # Make sure the paragraph we are matching has not been edited since
>> # this script was written.
>> - matched=`sed -n -e '/^This is GNU Libtool,/,/^interface.$/p' $file \
>> + matched=`sed -n -e '/^This is GNU Libtool,/,/^interface\.$/p' $file \
>> |wc -l |sed 's|^ *||'`
>> +
>> + # Unless, of course, it was edited by this script already.
>> + test 3 = "$matched" \
>> + || matched=`sed -n -e '/^This is an alpha testing release/,/behind a
>> consistent, portable interface\.$/p' $file \
>> + |wc -l |sed 's|^ *||'`
>
> Indentation is a bit weird here, I'd have expected the | to align one
> after the ` in the line above.
Okay. I was lining it up with previous clause, but it is ugly. I'll fix
that too.
With those addressed, and another successful distcheck, okay to push?
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
Re: [PATCH] tests: reloadable objects do not work on MSVC, SKIP test.
Hi Peter, On 22 Sep 2010, at 15:02, Peter Rosin wrote: > This is fixing a testsuite issue for MSVC, and I don't need it > to go in before the release. So, no rush. > > The patch was previously discussed here: > http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00051.html > > and it is on the pr-msvc-support branch as commit > fbc144008bd66848111fb8ef2d7293b33957ea1a (even though that commit > happened by mistake and was one of the very unpolished ones). > > Ok to push after the 2.4 release? (or before if Gary is ok with that) > > (with this patch and the other one making need_lib_prefix.at skip, > there are no more fails for MSVC/MSYS. Boggle!) Sure, go ahead. And please add a `no test failures with msvc/msys' entry to NEWS while you're there. > * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) > [cygwin, mingw, pw32, cegcc] : Indicate that > reloadable objects do not work. > * tests/duplicate_conv.at: Skip last test if reloadable > objects do not work. > * doc/libtool.texi (libtool script contents) : > Document how to indicate that reloadable objects do not work. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH] tests: reloadable objects do not work on MSVC, SKIP test.
Hi Peter, On 22 Sep 2010, at 15:15, Peter Rosin wrote: > Den 2010-09-22 10:11 skrev Gary V. Vaughan: >> Hi Peter, >> >> On 22 Sep 2010, at 15:02, Peter Rosin wrote: >>> This is fixing a testsuite issue for MSVC, and I don't need it >>> to go in before the release. So, no rush. >>> >>> The patch was previously discussed here: >>> http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00051.html >>> >>> and it is on the pr-msvc-support branch as commit >>> fbc144008bd66848111fb8ef2d7293b33957ea1a (even though that commit >>> happened by mistake and was one of the very unpolished ones). >>> >>> Ok to push after the 2.4 release? (or before if Gary is ok with that) >>> >>> (with this patch and the other one making need_lib_prefix.at skip, >>> there are no more fails for MSVC/MSYS. Boggle!) >> >> Sure, go ahead. And please add a `no test failures with msvc/msys' >> entry to NEWS while you're there. > > I assume you mean that both patches are OK to push then? Both patches? I saw only the one attached to the mail I replied to. That one is fine to push, yes. What's the other one? Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
[PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
The start of my post-release patch queue... okay to push? * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on the intermediate files, since they might have changed without giving make the opportunity to update the actual binaries that help2man calls in time. Signed-off-by: Gary V. Vaughan --- ChangeLog |8 Makefile.am |4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 566b74e..77dbb59 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2010-09-01 Gary V. Vaughan + + maint: help2man targets should rely on the binaries they call. + * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on + the intermediate files, since they might have changed without + giving make the opportunity to update the actual binaries that + help2man calls in time. + 2010-09-22 Gary V. Vaughan Post-release administrivia. diff --git a/Makefile.am b/Makefile.am index 6e29a29..0123180 100644 --- a/Makefile.am +++ b/Makefile.am @@ -326,9 +326,9 @@ MAINTAINERCLEANFILES+= $(dist_man1_MANS) update_mans = \ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \ $(HELP2MAN) --output=$@ -$(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh +$(srcdir)/doc/libtool.1: libtool $(update_mans) --help-option=--help-all libtool -$(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in +$(srcdir)/doc/libtoolize.1: libtoolize $(update_mans) libtoolize -- 1.7.3
[PATCH 2/4] maint: rearrange Makefile.am in preparation for a follow-up patch.
I've posted this one before, but this time it's split into two separate patches. This one to do the rearranging without any changes, and the next to perform the functional edits. Okay to push? * Makefile.am (Libtool scripts.): Move this section below the `Bootstrap.' section... (libtoolize.in): ...except this one which is generated at bootstrap time, and was added into the `Bootstrap.' section. (Libltdl.): Move this section below the `Libtool scripts.' section. Signed-off-by: Gary V. Vaughan --- ChangeLog | 10 Makefile.am | 142 +- 2 files changed, 81 insertions(+), 71 deletions(-) diff --git a/ChangeLog b/ChangeLog index 77dbb59..14866a9 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2010-08-31 Gary V. Vaughan + + maint: rearrange Makefile.am in preparation for a follow-up patch. + * Makefile.am (Libtool scripts.): Move this section below the + `Bootstrap.' section... + (libtoolize.in): ...except this one which is generated at + bootstrap time, and was added into the `Bootstrap.' section. + (Libltdl.): Move this section below the `Libtool scripts.' + section. + 2010-09-01 Gary V. Vaughan maint: help2man targets should rely on the binaries they call. diff --git a/Makefile.am b/Makefile.am index 0123180..1f3c584 100644 --- a/Makefile.am +++ b/Makefile.am @@ -60,63 +60,21 @@ timestamp = set dummy `$(MKSTAMP) $(srcdir)`; shift; \ rebuild = rebuild=:; $(timestamp); correctver=$$1 -## ## -## Libtool scripts. ## -## ## - -# The libtool distributor and the standalone libtool script. -bin_SCRIPTS = libtoolize libtool - -libtoolize: $(srcdir)/libtoolize.in $(top_builddir)/config.status - rm -f libtoolize.tmp libtoolize - $(timestamp); \ - $(edit) -e "s,@TIMESTAMP\@,$$TIMESTAMP,g" \ - -e 's,@aclocal_DATA\@,$(aclocalfiles),g' \ - -e "s,@pkgltdl_files\@,$(ltdldatafiles),g" \ - -e "s,@pkgconfig_files\@,$(auxfiles),g" \ - $(srcdir)/libtoolize.in > libtoolize.tmp - chmod a+x libtoolize.tmp - chmod a-w libtoolize.tmp - mv -f libtoolize.tmp libtoolize - -# Use `$(srcdir)' for the benefit of non-GNU makes: this is -# how libtoolize.in appears in our dependencies. -EXTRA_DIST += libtoolize.m4sh -$(srcdir)/libtoolize.in: $(sh_files) libtoolize.m4sh Makefile.am - cd $(srcdir); \ - rm -f libtoolize.in; \ - $(M4SH) -B $(auxdir) libtoolize.m4sh > libtoolize.in - -# We used to do this with a 'stamp-vcl' file, but non-gmake builds -# would rerun configure on every invocation, so now we manually -# check the version numbers from the build rule when necessary. -libtool: $(top_builddir)/config.status $(srcdir)/$(auxdir)/ltmain.sh ChangeLog - @target=libtool; $(rebuild); \ - if test -f "$$target"; then \ - set dummy `./$$target --version | sed 1q`; actualver="$$5"; \ - test "$$actualver" = "$$correctver" && rebuild=false; \ - fi; \ - for prereq in $?; do \ - case $$prereq in *ChangeLog);; *) rebuild=:;; esac; \ - done; \ - if $$rebuild; then \ - echo $(SHELL) ./config.status $$target; \ - cd $(top_builddir) && $(SHELL) ./config.status $$target; \ - fi - -.PHONY: configure-subdirs -configure-subdirs distdir: $(DIST_MAKEFILE_LIST) -...@dist_makefile_list@: - dir=`echo $@ | sed 's,^[^/]*$$,.,;s,/[^/]*$$,,'`; \ - test -d $$dir || mkdir $$dir || exit 1; \ - abs_srcdir=`$(lt__cd) $(srcdir) && pwd`; \ - (cd $$dir && $$abs_srcdir/$$dir/configure --with-dist) || exit 1 - - # -- # # Bootstrap. # # -- # +sh_files = $(auxdir)/general.m4sh $(auxdir)/getopt.m4sh +EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in $(auxdir)/ltmain.m4sh \ + $(auxdir)/mkstamp $(sh_files) \ + ChangeLog.1996 ChangeLog.1997 ChangeLog.1998 \ + ChangeLog.1999 ChangeLog.2000 ChangeLog.2001 \ + ChangeLog.2002 ChangeLog.2003 ChangeLog.2004 \ + ChangeLog.2005 ChangeLog.2006 ChangeLog.2007 \ + ChangeLog.2008 ChangeLog.2009 +CLEANFILES += libtool libtoolize libtoolize.tmp \ + $(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp + edit = sed \ -e 's,@EGREP\@,$(EGREP),g' \ -e 's,@FGREP\@,$(FGREP),g' \ @@ -138,17 +96,6 @@ edit = sed \ -e 's,@host_triplet\@,$(host_triplet),g' \ -e 's,@prefix\@,$(prefix),g' -sh_files = $(auxdir)/general.m4sh $(auxdir)/getopt.m4sh -EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in $(auxdir)/ltmain.m4sh \ - $(auxdir)/mkstamp $(sh_files) \ -
[PATCH 3/4] maint: don't leak developer GREP, SED etc into distribution file.
This is the second part of the patch I've split since the last time I posted. I added Joerg as reporter, and he is already named in THANKS. Okay to push? * Makefile.am: Having rearranged the file, now apply the actual changes to follow-up. (LT_M4SH): Call $(M4SH) with the libtool m4sh directory at the front of the search path. (rebuild): Set the shell variable `revision' rather than `correctver' for clarity. (edit): Split into two parts... (bootstrap_edit): ...substitutions that should happen at bootstrap time... (configure_edit): ...and substitutions that should not happen until configure time. * libtoolize.m4sh (package_revision): For consistency, and ease of extraction when deciding whether libtoolize needs to be regenerated. * Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh) (libtoolize.in): Much simplified - only rebuild if the recalculated timestamp is newer than the timestamp recorded in the target already; regenerate in one step without changing directories, using `$(bootstrap_edit)'. (libtoolize, libtool): Hugely simplified - since we already depend on `libtoolize.in' and `libltdl/config/ltmain.sh' respectively, no need to recheck version numbers; also they have the `$(bootstrap_edit)' substitutions made already, so we can just go ahead and process with `$(configure_edit)' whenever the dependencies go out of date. * Makefile.maint (commit, libltdl/config/mailnotify, bootstrap): Likewise. * HACKING (Release Procedure): Remove the note to workaround the bug fixed by this changeset. * NEWS (Bug fixes): Mention that this bug is now fixed. Reported by Joerg Sonnenberger. Signed-off-by: Gary V. Vaughan --- ChangeLog | 33 ++ HACKING |9 --- Makefile.am | 178 +- NEWS|3 +- libtoolize.m4sh |1 + 5 files changed, 118 insertions(+), 106 deletions(-) diff --git a/ChangeLog b/ChangeLog index 14866a9..fe75e0f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,38 @@ 2010-08-31 Gary V. Vaughan + maint: don't leak developer GREP, SED etc into distribution file. + * Makefile.am: Having rearranged the file, now apply the actual + changes to follow-up. + (LT_M4SH): Call $(M4SH) with the libtool m4sh directory at the + front of the search path. + (rebuild): Set the shell variable `revision' rather than + `correctver' for clarity. + (edit): Split into two parts... + (bootstrap_edit): ...substitutions that should happen at bootstrap + time... + (configure_edit): ...and substitutions that should not happen until + configure time. + * libtoolize.m4sh (package_revision): For consistency, and ease of + extraction when deciding whether libtoolize needs to be + regenerated. + * Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh) + (libtoolize.in): Much simplified - only rebuild if the + recalculated timestamp is newer than the timestamp recorded in the + target already; regenerate in one step without changing + directories, using `$(bootstrap_edit)'. + (libtoolize, libtool): Hugely simplified - since we already depend + on `libtoolize.in' and `libltdl/config/ltmain.sh' respectively, + no need to recheck version numbers; also they have the + `$(bootstrap_edit)' substitutions made already, so we can just + go ahead and process with `$(configure_edit)' whenever the + dependencies go out of date. + * Makefile.maint (commit, libltdl/config/mailnotify, bootstrap): + Likewise. + * HACKING (Release Procedure): Remove the note to workaround the + bug fixed by this changeset. + * NEWS (Bug fixes): Mention that this bug is now fixed. + Reported by Joerg Sonnenberger. + maint: rearrange Makefile.am in preparation for a follow-up patch. * Makefile.am (Libtool scripts.): Move this section below the `Bootstrap.' section... diff --git a/HACKING b/HACKING index 977be10..b17de29 100644 --- a/HACKING +++ b/HACKING @@ -619,15 +619,6 @@ or obtained by writing to the Free Software Foundation, Inc., * Update NEWS, ChangeLog. -* Until the bug that leaks developer tool paths into the release tarballs - from ./bootstrap is fixed, make sure the right tools are first in your - PATH and then: - export EGREP=egrep - export FGREP=fgrep - export GREP=grep - export MAKE=make - export SED=sed - * Run ./bootstrap. * Run ./configure (or create a build directory first and run configure diff --git a/Makefile.am b/Makefile.am index 1f3c584..48cd3a7 100644 --- a/Makefile.am +++ b/Makefile.am @@ -43,6 +43,8 @@ noinst_LTLIBRARIES= lib_LTLIBRARIES= EXTRA_LTLIBRARIES = +LT_M4SH= $(M4SH) -B $(srcdir)/$(auxdir) + auxdir
[PATCH 4/4] maint: simplify and improve safety of bootstrap process.
I also posted this one before... this time rebased against post-2.4 release HEAD. Okay to push? * Makefile.am (bootstrap_files): List files that need to be generated at bootstrap time before `./configure && make' can work. It turns out that this is considerably fewer files than we had thought necessary previously. (bootstrap-deps-prep): Ensure minimum set of required substitution variables are non-empty. (bootstrap-deps): Depend on `bootstrap' files. * bootstrap (Generate bootstrap dependencies): Now that `Makefile.am' is entirely responsible for rebuilding files at bootstrap time, we need only specify the new `bootstrap-deps' target, and supply values for the substitutions checked by `bootstrap-deps-prep'. Signed-off-by: Gary V. Vaughan --- ChangeLog | 16 Makefile.am | 41 + bootstrap | 17 - 3 files changed, 61 insertions(+), 13 deletions(-) diff --git a/ChangeLog b/ChangeLog index fe75e0f..309f8b6 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,19 @@ +2010-08-30 Gary V. Vaughan + + maint: simplify and improve safety of bootstrap process. + * Makefile.am (bootstrap_files): List files that need to be + generated at bootstrap time before `./configure && make' can + work. It turns out that this is considerably fewer files than we + had thought necessary previously. + (bootstrap-deps-prep): Ensure minimum set of required substitution + variables are non-empty. + (bootstrap-deps): Depend on `bootstrap' files. + * bootstrap (Generate bootstrap dependencies): Now that + `Makefile.am' is entirely responsible for rebuilding files at + bootstrap time, we need only specify the new `bootstrap-deps' + target, and supply values for the substitutions checked by + `bootstrap-deps-prep'. + 2010-08-31 Gary V. Vaughan maint: don't leak developer GREP, SED etc into distribution file. diff --git a/Makefile.am b/Makefile.am index 48cd3a7..0a1b17d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -198,6 +198,47 @@ $(srcdir)/libltdl/Makefile.am: $(srcdir)/libltdl/Makefile.inc -e '1s,^\(.. Makefile.\)inc.*,\1am -- Process this file with automake to produce Makefile.in,' > $$out; chmod a-w $(srcdir)/libltdl/Makefile.am +## Document the make macros that are needed to build bootstrap-deps +## dependencies when called from `bootstrap' (developer's machine), +## where the Makefile.am is fed to make in its raw format before +## `configure' has found the correct values (on the build machine). +bootstrap_files = \ +$(auxdir)/ltmain.sh \ +$(m4dir)/ltversion.m4 \ +libltdl/Makefile.am + +.PHONY: bootstrap-deps bootstrap-deps-prep +bootstrap-deps: bootstrap-deps-prep $(bootstrap_files) +bootstrap-deps-prep: +## The following variables are substituted by `bootstrap-dep-preps' + @exit_cmd=:; \ + test -z "$(srcdir)" \ + && echo "ERROR: don't call $(MAKE) with srcdir unset." \ + && exit_cmd=exit; \ + test -z "$(M4SH)" \ + && echo "ERROR: don't call $(MAKE) with M4SH unset." \ + && exit_cmd=exit; \ + test -z "$(PACKAGE)" \ + && echo "ERROR: don't call $(MAKE) with PACKAGE unset." \ + && exit_cmd=exit; \ + test -z "$(PACKAGE_BUGREPORT)" \ + && echo "ERROR: don't call $(MAKE) with PACKAGE_BUGREPORT unset." \ + && exit_cmd=exit; \ + test -z "$(PACKAGE_NAME)" \ + && echo "ERROR: don't call $(MAKE) with PACKAGE_NAME unset." \ + && exit_cmd=exit; \ + test -z "$(PACKAGE_URL)" \ + && echo "ERROR: don't call $(MAKE) with PACKAGE_URL unset." \ + && exit_cmd=exit; \ + test -z "$(SED)" \ + && echo "ERROR: don't call $(MAKE) with SED unset." \ + && exit_cmd=exit; \ + test -z "$(VERSION)" \ + && echo "ERROR: don't call $(MAKE) with VERSION unset." \ + && exit_cmd=exit; \ + $$exit_cmd 1 + rm -f $(bootstrap_files) + ## Unfortunately, all this bogeyness means that we have to manually ## keep the generated files in libltdl up to date. diff --git a/bootstrap b/bootstrap index 78b4d30..e66b151 100755 --- a/bootstrap +++ b/bootstrap @@ -126,19 +126,10 @@ $SED '/^if /,/^endif$/d;/^else$/,/^endif$/d;/^include /d' $makes > Makefile # Building distributed files from configure is bad for automake, so we # generate them here, and have Makefile rules to keep them up to date. -# W
