[PATCH] maint: resync files from upstream
Since the perl version required in Automake::Getopt has been recently lowered from 5.6.2 to 5.6.0, this change has the nice effect of making autoconf compatible again with all perls in the 5.6.x release series. * maint.mk: Resync via 'make fetch'. * lib/Autom4te/Channels.pm: Likewise. * lib/Autom4te/Configure_ac.pm: Likewise. * lib/Autom4te/FileUtils.pm: Likewise. * lib/Autom4te/Getopt.pm: Likewise. * lib/Autom4te/XFile.pm: Likewise. --- OK for master, so that it will appear in the upcoming 2.69 release? Thanks, Stefano lib/Autom4te/Channels.pm |2 +- lib/Autom4te/Configure_ac.pm |1 + lib/Autom4te/FileUtils.pm|1 + lib/Autom4te/Getopt.pm |2 +- lib/Autom4te/XFile.pm|2 +- maint.mk |2 +- 6 files changed, 6 insertions(+), 4 deletions(-) diff --git a/lib/Autom4te/Channels.pm b/lib/Autom4te/Channels.pm index d62a3f0..1f0fc1e 100644 --- a/lib/Autom4te/Channels.pm +++ b/lib/Autom4te/Channels.pm @@ -66,7 +66,7 @@ etc.) that can also be overridden on a per-message basis. =cut -use 5.005; +use 5.006; use strict; use Exporter; use Carp; diff --git a/lib/Autom4te/Configure_ac.pm b/lib/Autom4te/Configure_ac.pm index 2db7339..924b23c 100644 --- a/lib/Autom4te/Configure_ac.pm +++ b/lib/Autom4te/Configure_ac.pm @@ -20,6 +20,7 @@ package Autom4te::Configure_ac; +use 5.006; use strict; use Exporter; use Autom4te::Channels; diff --git a/lib/Autom4te/FileUtils.pm b/lib/Autom4te/FileUtils.pm index b91f653..30bbdb9 100644 --- a/lib/Autom4te/FileUtils.pm +++ b/lib/Autom4te/FileUtils.pm @@ -34,6 +34,7 @@ This perl module provides various general purpose file handling functions. =cut +use 5.006; use strict; use Exporter; use File::stat; diff --git a/lib/Autom4te/Getopt.pm b/lib/Autom4te/Getopt.pm index c880e1f..d73c5ef 100644 --- a/lib/Autom4te/Getopt.pm +++ b/lib/Autom4te/Getopt.pm @@ -30,7 +30,7 @@ line options in conformance to the GNU Coding standards. =cut -use 5.006_002; +use 5.006; use strict; use warnings FATAL = 'all'; use Exporter (); diff --git a/lib/Autom4te/XFile.pm b/lib/Autom4te/XFile.pm index bfa6a43..28d5bc6 100644 --- a/lib/Autom4te/XFile.pm +++ b/lib/Autom4te/XFile.pm @@ -69,7 +69,7 @@ and Cgetlines methods to translate C\r\n to C\n. =cut -require 5.000; +use 5.006; use strict; use vars qw($VERSION @EXPORT @EXPORT_OK $AUTOLOAD @ISA); use Carp; diff --git a/maint.mk b/maint.mk index 4cbd5f4..a97e0bd 100644 --- a/maint.mk +++ b/maint.mk @@ -1332,7 +1332,7 @@ alpha beta stable: $(local-check) writable-files $(submodule-checks) $(MAKE) vc-diff-check $(MAKE) news-check $(MAKE) distcheck - $(MAKE) dist XZ_OPT=-9ev + $(MAKE) dist $(MAKE) $(release-prep-hook) RELEASE_TYPE=$@ $(MAKE) -s emit_upload_commands RELEASE_TYPE=$@ -- 1.7.9
Re: [PATCH] maint: resync files from upstream
On 03/06/2012 02:03 PM, Eric Blake wrote: On 03/06/2012 04:46 AM, Stefano Lattarini wrote: Since the perl version required in Automake::Getopt has been recently lowered from 5.6.2 to 5.6.0, this change has the nice effect of making autoconf compatible again with all perls in the 5.6.x release series. * maint.mk: Resync via 'make fetch'. * lib/Autom4te/Channels.pm: Likewise. * lib/Autom4te/Configure_ac.pm: Likewise. * lib/Autom4te/FileUtils.pm: Likewise. * lib/Autom4te/Getopt.pm: Likewise. * lib/Autom4te/XFile.pm: Likewise. --- OK for master, so that it will appear in the upcoming 2.69 release? Yes, it can't hurt to push this now. I will re-run 'make fetch' on the actual day of the release, in case there's anything newer at that point, as well. Pushed. Thanks, Stefano
[PATCH] tests: port AT_CHECK_ENV to hosts with flaky grep
* tests/local.at (AT_CHECK_ENV): Don't assume that if one grep fails, the other will too. It could be that 'grep' is flaky, and fails somewhat at random. This would explain the problems reported for autoconf-2.68b on FreeBSD and MacOS X, for example: http://lists.gnu.org/archive/html/bug-autoconf/2012-03/msg00032.html http://lists.gnu.org/archive/html/bug-autoconf/2012-03/msg00035.html http://lists.gnu.org/archive/html/bug-autoconf/2012-03/msg00036.html http://lists.gnu.org/archive/html/bug-autoconf/2012-03/msg00044.html --- tests/local.at | 16 1 files changed, 12 insertions(+), 4 deletions(-) diff --git a/tests/local.at b/tests/local.at index cce24f0..eb01cc0 100644 --- a/tests/local.at +++ b/tests/local.at @@ -297,9 +297,10 @@ test -f state-ls.after \ # Compare variable space dumps. if test -f state-env.before test -f state-env.after; then set +x + grep_failed=false for act_file in state-env.before state-env.after do -$EGREP -v '^(m4_join([|], +($EGREP -v '^(m4_join([|], [a[cs]_.*], [(exec_)?prefix|DEFS|CONFIG_STATUS], [CC|CFLAGS|CPP|GCC|CXX|CXXFLAGS|CXXCPP|GXX|F77|FFLAGS|FLIBS|G77], @@ -323,12 +324,19 @@ if test -f state-env.before test -f state-env.after; then [GREP|[EF]GREP|SED], [[_@]|.[*#?$].], [argv|ARGC|LINENO|OLDPWD|PIPESTATUS|RANDOM|SECONDS]))=' \ - $act_file 2/dev/null | + $act_file || + test $? -eq 1 || echo failed 2 +) 2stderr-$act_file | # There may be variables spread on several lines; remove latter lines. - $GREP '^m4_defn([m4_re_word])=' clean-$act_file + $GREP '^m4_defn([m4_re_word])=' clean-$act_file || +test $? -eq 1 || grep_failed=: +if test -s stderr-$act_file; then + cat stderr-$act_file 2 + grep_failed=: +fi done $at_traceon - $at_diff clean-state-env.before clean-state-env.after + $grep_failed || $at_diff clean-state-env.before clean-state-env.after fi } [#]at_check_env]) -- 1.7.6.5
Re: how to fine tune AM_PYTHON_PATH's pythondir?
On 03/06/2012 07:29 AM, Charles Brown wrote:
autoconf (GNU Autoconf) 2.67
AM_PYTHON_PATH provides a pythondir that is hardcoded to
${prefix}/lib/ Our project would prefer to place the python code
elsewhere, say ${prefix}/scripts/
AM_PYTHON_PATH is maintained by automake (hence the AM_ prefix).
There's nothing that autoconf can do about it, since it is not
autoconf's macro. You'll probably get a better answer by asking on the
automake list.
Is there a way to refine the path through AM_PYTHON_PATH, or a configure
command line option?
-
This message is intended only for the addressee and may contain
It is considered poor netiquette to include company disclaimers when
posting to publicly-archived lists, as the disclaimer cannot be enforced
in that situation. You may want to consider sending from a different
email account that does not slap on such legalese.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
On 3/6/2012 2:31 AM, Olaf Lenz wrote: On 03/06/2012 10:27 AM, Alberto Luaces wrote: Warren Young writes: At least version 1.26 implements -a, which determines the compressor from the file suffix. I think that may be a red herring, because... I think since some years now I don't need to give neither -z or -a, just tar xvf bla.tar.xz or tar xvf bla.tar.gz I did some research, and this was added in GNU tar 1.15, about 8 years ago: https://lists.gnu.org/archive/html/bug-tar/2004-12/msg00019.html Serves me right for not watching ChangeLogs religiously. Thanks all for cluing me into this new feature. Alas, I do still use machines with tar 1.15... On 3/6/2012 4:10 AM, Werner LEMBERG wrote: On Mac OS X Lion, this actually happens: Regardless of the compression algorithm, you always use `-z' while extracting. I think this is probably also the same feature, where -z or -j is simply no longer needed for -x or -t. I tested with bsdtar, and it apparently has the same feature, at least as of Lion. Anyway, back to your regularly-scheduled autoconf. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why I am happy to dump gzip for xz
On Tuesday 06 March 2012 04:57:27 Jim Meyering wrote: Why I am happy to dump gzip for xz: - xz decompresses more quickly is that true ? i thought last i looked, they were close, but gzip was consistently slightly faster. maybe if the bottleneck is more I/O than CPU/memory, xz would win ? -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why I am happy to dump gzip for xz
Mike Frysinger wrote: On Tuesday 06 March 2012 04:57:27 Jim Meyering wrote: Why I am happy to dump gzip for xz: - xz decompresses more quickly is that true ? i thought last i looked, they were close, but gzip was consistently slightly faster. maybe if the bottleneck is more I/O than CPU/memory, xz would win ? Hi Mike, Even back when the program was named lzma, it was always much more efficient at decompressing than *bzip2*: (this is on a tmpfs file system) $ du -sh gcc-* 69M gcc-4.6.3.tar.bz2 90M gcc-4.6.3.tar.gz 52M gcc-4.6.3.tar.xz Here xz decompression speed is about triple than bzip2: $ env time xz -dc gcc-4.6.3.tar.xz /dev/null 3.76user 0.04system 0:03.82elapsed 99%CPU (0avgtext+0avgdata 66576maxresident)k 0inputs+0outputs (0major+850minor)pagefaults 0swaps $ env time bzip2 -dc gcc-4.6.3.tar.bz2.orig /dev/null 12.11user 0.04system 0:12.21elapsed 99%CPU (0avgtext+0avgdata 4152maxresident)k 88inputs+0outputs (0major+573minor)pagefaults 0swaps However, you're right that gzip decompresses faster than xz: $ env time gzip -dc gcc-4.6.3.tar.gz /dev/null 2.31user 0.03system 0:02.35elapsed 99%CPU (0avgtext+0avgdata 772maxresident)k 0inputs+0outputs (0major+235minor)pagefaults 0swaps Thanks for the correction. Jim ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why I am happy to dump gzip for xz
Jim Meyering j...@meyering.net writes: If you were more intimately familiar with gzip's code, you would have switched long ago ;-) [...] Thanks for this. I hadn't realized the issues with the gzip code. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why I am happy to dump gzip for xz
On Tuesday 06 March 2012 12:03:43 Jim Meyering wrote: Mike Frysinger wrote: On Tuesday 06 March 2012 04:57:27 Jim Meyering wrote: Why I am happy to dump gzip for xz: - xz decompresses more quickly is that true ? i thought last i looked, they were close, but gzip was consistently slightly faster. maybe if the bottleneck is more I/O than CPU/memory, xz would win ? Even back when the program was named lzma, it was always much more efficient at decompressing than *bzip2*: sure, i agree completely that xz over bzip2 is a no brainer in pretty much every way possible :) -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [GNU Autoconf 2.68] testsuite: 1 10 11 12 14 16 17 20 22 24 25 27 28 32 33 36 38 208 211 212 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 231 232 233 234 235 236 237 238 239 240
That sure is a lot of test failures. Can you please try our latest Autoconf beta? It has some fixes in this area. ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.68b.tar.gz I suggest applying these post-2.68b patches as well: http://lists.gnu.org/archive/html/bug-autoconf/2012-03/txtmjhqa66pjL.txt Thanks.
Re: Autoconf-2.68b possible patch for FreeBSD, MacOS X
On Mar 6, 2012, Paul Eggert egg...@cs.ucla.edu wrote: Can you please also try the attached patch? It's needed regardless, and I think it may attack some failures being reported for FreeBSD and MacOS X. I've pushed this to autoconf master as: http://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=16126bc4302f2cb1b4bd06ca7d7da31d2f82156a Very much appreciated, but very much worse. I fail nearly all the tests now after about 270 on OSX Lion. Please lmk if you want some test dirs. This was just a quick update.
Re: [GNU Autoconf 2.68] testsuite: 1 10 11 12 14 16 17 20 22 24 25 27 28 32 33 36 38 208 211 212 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 231 232 233 234 235 236 237 238 239 240
Hi Paul, Not much of a difference with version 2.68b or older (2.65): [GNU Autoconf 2.68b] testsuite: 1 10 11 12 14 16 17 20 22 24 25 27 28 32 33 36 38 75 100 212 215 216 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 281 282 283 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 4 54 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 502 failed Possibly, the some failures due to pre-installed bash (test status below): $ bash --version GNU bash, version 4.1.9(1)-release (i386-pc-solaris2.11) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html Have not tested any post-2.68b patches and running out of time. The failures should be easily reproducible on a vanilla Solaris 11/x86_64. Regards, Martin On 2012-03-06 9:45 PM, Paul Eggert wrote: That sure is a lot of test failures. Can you please try our latest Autoconf beta? It has some fixes in this area. ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.68b.tar.gz I suggest applying these post-2.68b patches as well: http://lists.gnu.org/archive/html/bug-autoconf/2012-03/txtmjhqa66pjL.txt Thanks. /bin/sh ./testsuite ## -- ## ## GNU Autoconf 2.68b test suite. ## ## -- ## Executables (autoheader, autoupdate...). 1: Syntax of the shell scripts FAILED (tools.at:53) 2: Syntax of the Perl scripts ok 3: autom4te cache ok 4: autom4te --forceok 5: autom4te and whitespace in file names ok 6: autom4te --trace and unusual macro namesok 7: autom4te --trace and whitespace ok 8: autoconf --trace: user macros ok 9: autoconf --trace: builtins ok 10: autoconf: forbidden tokens, basic FAILED (tools.at:390) 11: autoconf: forbidden tokens, exceptions FAILED (tools.at:431) 12: autoconf: automatically allowed tokens FAILED (tools.at:456) 13: autoconf: the empty token ok 14: autoconf: subdirectoriesFAILED (tools.at:495) 15: autoconf: input from stdin ok 16: autoconf: AC_AUTOCONF_VERSION FAILED (tools.at:530) 17: autoconf: AC_PRESERVE_HELP_ORDERFAILED (tools.at:553) 18: ifnames ok 19: autoheader ok 20: autoheader and macros FAILED (tools.at:770) 21: autoupdate ok 22: autoupdating AC_LINK_FILES FAILED (tools.at:846) 23: autoupdating AC_PREREQ ok 24: autoupdating AU_ALIAS FAILED (tools.at:893) 25: autoupdating OLD to NEW FAILED (tools.at:920) 26: autoupdating macros recursively expected failure (tools.at:945) 27: autoupdating AC_HELP_STRING FAILED (tools.at:964) 28: autoupdating with m4sugar FAILED (tools.at:1001) 29: autoupdating with m4_pushdefexpected failure (tools.at:1027) 30: autoupdating with AC_REQUIREexpected failure (tools.at:1053) 31: autoupdating with complex quoting expected failure (tools.at:1079) 32: autoupdating AC_LANG_SAVE FAILED (tools.at:1100) 33: autoupdating AC_FOREACH FAILED (tools.at:1123) 34: autoupdating with aclocal and m4_includeok 35: autom4te preselections ok 36: autom4te cache creation FAILED (tools.at:1243) 37: autom4te cache locking ok 38: autotools and whitespace in file names FAILED (tools.at:1315) M4sugar. 39: m4_stackok 40: m4_defn ok 41: m4_dumpdef ok
