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.
On 06/29/2010 08:52 AM, Gary V. Vaughan wrote:
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%??}
}
What about
func_split_short_arg () {
rest=${1#??};
arg=${1%$rest};
}
The quoting ensures that it works even if a star is present in $1:
$ func_split_short_arg -X*YZ ; echo $arg; echo $rest
-X
*YZ
$ func_split_short_arg -XYZ ; echo $arg; echo $rest
-X
YZ
Paolo
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.
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.
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.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
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.
Hi Gary,
* 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 21; 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.
Cheers,
Ralf
Re: checking for header/library mismatch, rpath problem?
[ please elide autoconf@ from followups, thanks ] Hi Peter, * Peter Breitenlohner wrote on Tue, Jun 29, 2010 at 10:36:32AM CEST: Here the macro we are using in TeX Live for such tests (C and C++). Our purpose is to test properties of libraries that can be either (1) uninstalled libtool libraries already built when this configure runs, or (2) installed libraries -- libtool or not. Good stuff. Are you willing to turn this into a patch against git Libtool? Otherwise we'll put it on our todo list. You might need to sign papers though, at least if you're adding test coverage. A general set of macros could be LT_USE_LIBTOOL_PUSH and _POP and could adjust the AC_LANG setting of all configured libtool tags; the pop macro could reset them to their original state afterwards; that would help for encapsulation. Or some better names I can't think of right now. # _KPSE_USE_LIBTOOL() # --- AC_DEFUN([_KPSE_USE_LIBTOOL], [## $0: Generate a libtool script for use in configure tests AC_PROVIDE_IFELSE([LT_INIT], , [m4_fatal([$0: requires libtool])])[]dnl LT_OUTPUT m4_append([AC_LANG(C)], [ac_link=./libtool --mode=link --tag=CC $ac_link ])[]dnl AC_PROVIDE_IFELSE([AC_PROG_CXX], [m4_append([AC_LANG(C++)], [ac_link=./libtool --mode=link --tag=CXX $ac_link ])])[]dnl AC_LANG(_AC_LANG)[]dnl ]) # _KPSE_USE_LIBTOOL Thanks, Ralf
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 21; 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: [PATCH] Add an XSI replacement for func_split_short_opt.
* Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 08:30:43PM CEST:
On 30 Jun 2010, at 01:22, Ralf Wildenhues wrote:
I think m4sh can simply use code like
if ( eval '$smart_works' ) /dev/null 21; 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;'?
Good point. IIRC gnulib-tool uses e.g.,
eval 'func_foo () { smart code; }'
or eval inside the smart code, to get around that where needed.
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.
Just trying it with Solaris sh and maybe a couple of the other vendor
systems helps, these things are easily sorted out with your level of
system access.
Cheers,
Ralf
libtool head fails under Solaris 10 FreeBSD
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 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 Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
On 06/29/2010 12:35 PM, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 08:30:43PM CEST:
On 30 Jun 2010, at 01:22, Ralf Wildenhues wrote:
I think m4sh can simply use code like
if ( eval '$smart_works' ) /dev/null 21; 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;'?
Good point. IIRC gnulib-tool uses e.g.,
eval 'func_foo () { smart code; }'
That's how m4sh already does it for AS_VAR_APPEND (take a look at
practically any configure script built with recent autoconf):
if (eval as_var=1; as_var+=2; test x\$as_var = x12) 2/dev/null; then :
eval 'as_fn_append ()
{
eval $1+=\$2
}'
else
as_fn_append ()
{
eval $1=\$$1\$2
}
fi # as_fn_append
which works just fine with retarded Solaris /bin/sh.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
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
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 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? Yes, sir. Will do. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool head fails under Solaris 10 FreeBSD
On Wed, 30 Jun 2010, Gary V. Vaughan wrote: 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... Now Solaris 10 produces just 3 unexpected failures, which is one more than normal. The tests/testsuite.log file is attached. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ testsuite.log.gz Description: Binary data
Re: libtool head fails under Solaris 10 FreeBSD
With OS-X Leopard PowerPC: ## - ## ## Test results. ## ## - ## 100 tests behaved as expected. 15 tests were skipped. 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 Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.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)
