Re: [PATCH] testsuite: fix race conditions in ltdl dryrun
On Dec 15, 2014, at 1:13 PM, Pavel Raiskup prais...@redhat.com wrote: [+cc autoconf, as this seems to be relevant] Hi all, Hi Pavel, Thanks for the fix. This one has caught me out occasionally too, so I'll also be glad to banish it! Sorry for the delay in applying and pushing... it's been a crazy month! after several random [ltdl dryrun] failures, I used the 'make --debug' and some stat calls to debug. Logs are attached for ok failed runs as tarball. Seems like after 'aclocal' run there should be an explicit 'sleep 1', similarly like in autoreconf [1]. Possible fix attached. The problem seems to be in autoheader and Perl's move function (underlying utime() handling?): $ touch /tmp/a $ stat /tmp/a File: ‘/tmp/a’ Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 23h/35d Inode: 1296845 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/praiskup) Gid: ( 1000/praiskup) Context: unconfined_u:object_r:user_tmp_t:s0 Access: 2014-12-15 14:03:35.744530946 +0100 Modify: 2014-12-15 14:03:35.744530946 +0100 Change: 2014-12-15 14:03:35.744530946 +0100 Birth: - $ perl -MFile::Copy -e 'move (/tmp/a, a);' $ stat a File: ‘a’ Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd00h/64768dInode: 11068678Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/praiskup) Gid: ( 1000/praiskup) Context: unconfined_u:object_r:user_home_t:s0 Access: 2014-12-15 14:03:42.0 +0100 Modify: 2014-12-15 14:03:35.0 +0100 ^^^ floor()-ed Change: 2014-12-15 14:03:42.678581581 +0100 Birth: - [1] http://git.savannah.gnu.org/cgit/autoconf.git/tree/bin/autoreconf.in#n356 Pavel racy-tests.tar.gz0001-tests-fix-race-in-aclocal-autoheader-calls.patch Applied and pushed. Thanks again! Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: bug#19370: Acknowledgement (LT 2.4.4 regression (vs. 2.4.2))
[[Adding Autoconf List, the home of autoreconf]] On Jan 16, 2015, at 1:26 PM, Gary V. Vaughan g...@vaughan.pe wrote: And the problem is that autoreconf, as called from the autogen.sh in the tarball, still runs the tools in the wrong order. Autoreconf stupidly runs aclocal first, and then calls libtoolize which adds more m4 files to AC_CONFIG_MACRO_DIR, and that in turn causes aclocal.m4 to be out of date (because it needs to be regenerated to pick up the local versions of the libtoolize added m4 files added to ../config/ after it was first generated). actually, (at least modern enough) autoreconf runs the aclocal twice. Once before libtoolize call (do detect whether it should call the libtoolize tool at all) and second time [1] after libtoolize to incorporate the macros. That's good to know. I stopped closely following autoconf development a few years ago, and didn't realise this was finally cleaned up. Some of these corner case may be because of my slightly out of date view of how these tools interact :-( Now that I think about it, why is it necessary to run aclocal just to find out whether LT_INIT, AM_PROG_LIBTOOL or AC_PROG_LIBTOOL is invoked? I know that for a full m4 --trace run, one needs to have some (possibly outdated) versions of required macros available, but it's very easy to work around that: see the implementation of `func_require_libtoolize` in the libtool bootstrap script (my clean rewrite of the gnulib bootstrap script). Further, now that autoconf is actively maintained again, why do we have a vestigial autoreconf and a whole zoo of autogen.sh and bootstrap scripts? Wouldn't it make more sense to centralize and maintain all of this in the one true autoreconf? Merging my bootstrap script with the latest autoreconf eliminates the spurious rerun of aclocal, and brings support for gettext, gnulib and per-project customizations. It doesn't seem like a great deal of work to translate 700 lines of perl into shell, fold it into bootstrap, and ship the result as autoreconf in the next release of Autoconf. Then everyone can go back to running `autoreconf -fvi` and be done with the whole mess of wrapper scripts... Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: bug#18916: libtool-2.4.3 caused autoconf test failure
On Oct 31, 2014, at 10:11 PM, Eric Blake ebl...@redhat.com wrote: [adding libtool] On 10/31/2014 10:54 AM, Bruce Dubbs wrote: From the test output: Compatibility with other tools. 501: Libtool FAILED (foreign.at:61) -- This was caused by libtool-2.4.3. Using the identical instructions when libtool-2.4.2 is used, the test passes. Thanks for the report. Yes, autoconf should be taught to be more tolerant of new libtool, but this is probably also worth investigating if it is a libtool regression worth fixing for the upcoming 2.4.4. The failure is because latest libtool (and libtoolize et. al) are following the rest of GNU in eschewing `backtick opening quotes' in favour of 'regular single quotes at both ends' style. The sed expression in foreign.at at line 60 should accept either format to be compatible with new and old libtoolize output. E.g.: AT_CHECK([sed -n [s,^[^']*[\`']\\(/[^']*\\)'.*,\\1,p] stdout], [0], [stdout]) Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: A Closer Look at GNU AutoTools
On Sep 5, 2014, at 12:34 PM, Henrique de Moraes Holschuh h...@debian.org wrote: On Fri, 05 Sep 2014, Hartmut Holzgraefe wrote: * the good old Goats Book which is also available online, and seems to have received an update lately: https://www.sourceware.org/autobook/autobook/autobook_toc.html I still refer to my paper copy every once in a while, but by now that one's so old that a lot of things need to be cross-checked against current autotools documentation This one is available under the OPL v1.0 with no extra options (http://opencontent.org/openpub/). It was updated in 2006 to address autoconf-2.59, automake-1.9.6, libtool 1.5.22. This _should_ be fresh enough to be useful. If someone looks it over and states that it is indeed useful for recent autotools, I believe a pointer to this book should be added to the autotools (autoconf, automake, libtool) websites. In fact, the Debian project had it packaged in non-free for quite a while[1]. It was removed in 2008, because non-free was carrying the unofficial 1.4.4 edition from http://mdcc.cx/autobook/, which is obsolete as it was never updated to the 1.5 official release. [1] The Debian DFSG when applied to documentation is more restrictive than the GNU free documentation license guidelines. The autobook complies to the GNU requirements for a free documentation license, at least according to http://www.gnu.org/licenses/license-list.html#FreeDocumentationLicenses since no options of the OPL were exercised in the autobook license. I've been meaning to make the time to update The Goat Book to latest autotools for a few years, maybe even a complete overhaul for a 2ed. But it keeps slipping down my TODO. I'll see if I can get it moved to Savannah presently, and in the mean time patches, corrections or even reports of examples that are broken or otherwise misleading with current releases would be enough to prompt me into taking the first few bites if the elephant. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te'
On Jun 27, 2014, at 8:55 AM, Jeff Sheen j...@stargazystudios.com wrote: On 27 Jun 2014, at 02:39, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Thu, 26 Jun 2014, Jeff Sheen wrote: Is it expected behaviour that GNU Autotools are incompatible with some file systems natively supported by the OS? FAT32 provides only one second file timestamp resolution. That can cause significant problems for modern computers which often perform several steps in one second. A test to see if a file has changed may fail to obtain the correct results. N.B. despite FAT's age, and subsequent flaws, it is still the de facto standard for portable drives. This is because FAT is the only file system fully supported by all modern operating systems. I run a multi-OS development environment, with a spread of tools across OSX and Windows. I wanted to migrate away from using FAT on my shared data partition, but found no other viable options. The process of testing alternative file systems was extensive, and meticulous. I spent weeks trying out NTFS and HFS partitions, with different combinations of drivers in both operating systems. Ultimately, it is partisan nonsense that the only file system that can be agreed on is FAT, but that is the reality. Patient: It hurts when I do this. Doctor: Well, then don't do that! There really are many, many more elegant solutions than sharing files using FAT! - use a NAS with a proper filesystem; - mount a proper filesystem to one server and then run NFS on that server so that client machines can access it; - use SMB on windows and Samba on Unix to cross mount a NTFS share; - sychronize shared files using DropBox or Box.net or OwnCloud etc; - replicate the filesystem across architectures and synchronize with rsync or git or mercurial or bzr; - create a TrueCrypt volume if you're moving a single physical drive between machines; - or a PKZip volume which also preserves metadata far better than FAT; And that's just the ones I could brainstorm in the time it took me to type this up, there are surely many others. HTH, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te'
Hi Jeff, On Jun 27, 2014, at 11:10 AM, Jeffrey Sheen j...@stargazystudios.com wrote: Thanks for the suggestions Gary. No problem. I do run a NAS on my LAN, and backup from my shared data partition to both Dropbox and Copy (the only cloud storage clients that support symlinks over multiple file system types). These both rely on network connectivity, where the solution I require is a partition on local drive attached to the device. Assuming this means you need to unmount, detach, walk to another machine, plug, mount and then access... you still have a few better options than FAT, I think. Is it possible to have a local, NTFS data partition and access it with Samba on a local boot partition? I would have thought that fundamentally you'd need a layer converting Samba I/O calls into NTFS calls, in which case, why not address the NTFS partition directly (functionality which does not exist in OSX). You answered your own question :) OSX can mount windows shares, even though it can't read an NTFS filesystem (actually I did once find a way to mount NTFS read-only on Snow Leopard, so you might want to google that if it seems attractive in case it is still maintained and/or improved). But again, that requires at least an adhoc wifi network to connect the OSX client to the Windows SMB server, which you seem to have ruled out. Synchronising data across multiple local partitions is certainly not more elegant than a single, shared data partition, and would require multiple times the redundancy of storage. Well, that's hard to say without more context. But, I have all my open source projects checked in to local git repos on a dropbox share, and use them from dozens of heterogenous machines scattered across the globe all of which DropBox synchronizes invisibly for me... which suits me far better than FAT + sneaker net ;-) But, that only works because I know I'm only working on one machine at a time and don't have to worry about merge conflicts. With regards to TrueCrypt and PKZip, are these not application layer implementations that create files on top of a file system? If this is not the case, and they have their own file system implementations, then let me know and I will test them. They create a filesystem in a file on the host filesytem that contains contents of the packaged files + metadata (timestamps, ownership etc). You would either pkunzip into a local featureful filesystem, edit and then pkzip back into the host filesystem for sneaker net transport to the next machine, or in the case of TrueCrypt mount the embedded filesystem from either a disk image in the host fs, or from a whole disk image -- lots of details in the TrueCrypt docs. Be careful to avoid the deliberately brain-damaged most recent release though - and pick up 6.1a images for all the machines that need to read the TrueCrypt fs. Without a viable alternative, I will continue to use a FAT data partition, and temporarily copy source trees onto my boot partition when executing GNU Autotools over them. I can then copy them back, and proceed normally. In that case, what about hosting the transported files in a VM that boots with virtual box or vmware (or other multi-arch compatible VM image format) on each target machine and have the running VM export the shared files over sshfs/samba/nfs/all-3! for live mounting and editing on the target machine? Docker also seems to run on Windows, according to its website: So a modern solution might be to wrap the whole thing up in a docker container on the external drive and deploy that on each target machine in turn for access to the files it contains. And with a little extra care you could easily incorporate snapshotting and/or backups into the process without additional tools. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How can I set a subproject to build as a static library by default
On Jan 20, 2014, at 3:52 PM, Steven Stewart-Gallus sstewartgallu...@mylangara.bc.ca wrote: I know I can use LT_INIT([static]) to build libraries in my project statically (by default) but how can I make subprojects build statically? Pass --disable-shared to AC_CONFIG_SUBDIRS. http://www.gnu.org/s/autoconf/manual/autoconf.html#Subdirectories ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
as_echo/bs_echo still required?
Hi Paul, Some time ago, with regard to my bootstrap rewrite, you suggested that the hoop-jumping I do to find a backslash-friendly echo equivalent on the host machine was probably overkill nowadays, and that it would be cleaner to just use `printf '%s\n'` everywhere. The bs_echo boilerplate in bootstrap is shared with libtoolize, libtool, bootstrap and others with my funclib.sh library, and that in turn was mostly copied from the as_echo guts of a recent Autoconf, with some additional gunk that libtool has been carrying around for several years to cope with some of the nasty delayed-evaluation of scriptlets containing backslashes stored in shell variables dance it does at runtime - for which a non-backslash mangling echo is essential. Now, while I'd like to go ahead and make this change, which would save me from a few $ECHO/$bs_echo related bug reports every year at least, this comment still worries me: # There are still modern systems that have problems with 'echo' mis- # handling backslashes, among others, so make sure $bs_echo is set to a # command that correctly interprets backslashes. # (this code from Autoconf 2.68) # Printing a long string crashes Solaris 7 /usr/bin/printf. bs_echo='\\\' bs_echo=$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo bs_echo=$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo$bs_echo And a little further down: # Prefer a ksh shell builtin over an external printf program on Solaris, # but without wasting forks for bash or zsh. My current thinking is that I'd happily move to a printf-everywhere simplification across the board, as long as Autoconf also committed to the same improvement. I'll provide the patches if there is a consensus to apply them. But, it looks like doing so effectively deprecates Solaris 7 support, which may be premature... Comments? Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: as_echo/bs_echo still required?
Hi Paul, On Jan 2, 2014, at 3:45 PM, Paul Eggert egg...@cs.ucla.edu wrote: Gary V. Vaughan wrote: it looks like doing so effectively deprecates Solaris 7 support That's fine. Sun (now Oracle) stopped supporting Solaris 7 in August 2008. Even Solaris 8 is fair game now; its end of support was March 2012. (Solaris 9's end of support will be in October of this year.) I wouldn't spend much time worrying about the older systems that lack a 'printf' command. Deja-vu! $ cd ~/gnu/projects/autoconf--savannah--0 $ git log | less ... commit 2b59b6f8a79b8bf77e178ff4e5aa0ede433d39cf Author: Gary V. Vaughan g...@gnu.org Date: Mon Jan 28 10:44:45 2013 +0700 m4sugar: factor away _AS_ECHO_PREPARE. printf '%s\n' ... has been a fine replacement for plain echo for at least 5 years (probably more like 10), even with most museum-piece shells. * lib/m4sugar/m4sh.m4 (_AS_ECHO_PREPARE): Remove. (_AS_SHELL_SANITIZE): Keep as_nl setting originally from _AS_ECHO_PREPARE here where it more properly belongs. (AS_ECHO, AS_ECHO_N): Use printf unconditionally. * doc/autoconf.texi (Limitations of Shell Builtins): Document preference for 'printf' over working around 'echo' bugs. * NEWS: Updated. Reported by Jim Meyering. ... Apparently I already pushed the Autoconf patch I was about to write :) I'm excising bs_echo from bootstrap now too... D'oh! Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail
_AC_PROG_FC_V_OUTPUT fails to parse SunStudio12.13 fortran output
Autoconfers, Currently, Libtool's git master (upcoming 4.2.3 release) fails its fortran tests on Solaris with gcc: http://vaughan.pe/libtool/libtool-2.4.2.427.logs/sparc-sun-solaris2.11-gcc4.4.6/testsuite.dir/153/config.log One or both of the following need fixing for those tests to work: 1. _AC_F77_FC needs to prefer gfortran over f77 on Solaris, otherwise mixed language compiles end up with objects from SunStudio's f77 (itself a wrapper for f90 in recent releases) and GNU's gcc - where gfortran would have done a much better job. (Aside: Does g77 even exist in the wild any more?) 2. _AC_PROG_FC_V_OUTPUT needs to pick up the location of the fortran libraries correctly, where the weird quoting of -R arguments and/or unnecessary `grep '\-L'` filtering currently skips it: configure:4149: checking how to get verbose linking output from f77 configure:4159: f77 -c -g conftest.f 5 NOTICE: Invoking /opt/solarisstudio12.3/bin/f90 -f77 -ftrap=%none -c -g conftest.f conftest.f: MAIN main: configure:4159: $? = 0 configure:4177: f77 -o conftest -g -v -L/opt/fsw/gcc44r/lib -R/opt/fsw/gcc44r/lib conftest.f NOTICE: Invoking /opt/solarisstudio12.3/bin/f90 -f77 -ftrap=%none -o conftest -g -v -L/opt/fsw/gcc44r/lib -R/opt/fsw/gcc44r/lib conftest.f [[snip]] ### f90: Note: LD_LIBRARY_PATH = (null) ### f90: Note: LD_RUN_PATH = (null) ### f90: Note: LD_OPTIONS = (null) ln -s /opt/solarisstudio12.3/prod/lib /tmp/lib_link.1387624254.755.01 /usr/ccs/bin/ld -zld32=-S/tmp/lib_link.1387624254.755.01/libldstab_ws.so -zld64=-S/tmp/lib_link.1387624254.755.01/v9/libldstab_ws.so -zld32=-S/tmp/lib_link.1387624254.755.01/libld_annotate.so -zld64=-S/tmp/lib_link.1387624254.755.01/v9/libld_annotate.so /opt/solarisstudio12.3/prod/lib/crti.o /opt/solarisstudio12.3/prod/lib/crt1.o /opt/solarisstudio12.3/prod/lib/misalign.o /opt/solarisstudio12.3/prod/lib/values-xi.o -L/opt/fsw/gcc44r/lib conftest.o -lf77compat -o conftest -Y P,/opt/solarisstudio12.3/lib/sparc:/opt/solarisstudio12.3/lib:/opt/solarisstudio12.3/prod/lib/sparc:/opt/solarisstudio12.3/prod/lib:/usr/ccs/lib:/lib:/usr/lib -Qy -R/opt/fsw/gcc44r/lib -R/opt/solarisstudio12.3/lib/sparc:/opt/solarisstudio12.3/lib -t -lifai -lsunimath -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai -lfminvai -lfmaxvai -lfui -lfsu -lsunmath -lmtsk -lm -lc /opt/solarisstudio12.3/prod/lib/crtn.o [[snip]] configure:4260: result: -v configure:4262: checking for Fortran 77 libraries of f77 configure:4285: f77 -o conftest -g -v -L/opt/fsw/gcc44r/lib -R/opt/fsw/gcc44r/lib conftest.f [[snip]] configure:4481: result: -L/opt/fsw/gcc44r/lib -R/opt/fsw/gcc44r/lib -lf77compat -lifai -lsunimath -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai -lfminvai -lfmaxvai -lfui -lfsu -lsunmath -lmtsk -lm configure:4498: checking for dummy main to link with Fortran 77 libraries configure:4532: gcc -o conftest -O2 -mcpu=ultrasparc -mvis -L/opt/fsw/gcc44r/lib -R/opt/fsw/gcc44r/lib conftest.c -L/opt/fsw/gcc44r/lib -R/opt/fsw/gcc44r/lib -lf77compat -lifai -lsunimath -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai -lfminvai -lfmaxvai -lfui -lfsu -lsunmath -lmtsk -lm 5 ld: fatal: library -lf77compat: not found ld: fatal: library -lifai: not found ld: fatal: library -lsunimath: not found ld: fatal: library -lfai: not found ld: fatal: library -lfai2: not found ld: fatal: library -lfsumai: not found ld: fatal: library -lfprodai: not found ld: fatal: library -lfminlai: not found ld: fatal: library -lfmaxlai: not found ld: fatal: library -lfminvai: not found ld: fatal: library -lfmaxvai: not found ld: fatal: library -lfui: not found ld: fatal: library -lfsu: not found ld: fatal: library -lsunmath: not found ld: fatal: file processing errors. No output written to conftest collect2: ld returned 1 exit status configure:4532: $? = 1 Note the quoted -R/opt/solarisstudio12.3/lib/sparc:/opt/solarisstudio12.3/lib in the verbose f77 output holds the location of the list of not found libraries above. I'm not at all familiar with FORTRAN, and don't know what the right approach to fix this would be, so I'm afraid I didn't write a patch :( But I'm willing to cut a first draft if someone can explain what needs to be done :) Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: AC_*/AM_* macros for options
Hi Jeff, On Oct 29, 2013, at 12:05 PM, Jeffrey Walton noloa...@gmail.com wrote: I'm reading Vaughan, Elliston, Tromey and Taylor's book on Autotools. At page 22, they list some macros and begin to explain them. The macros are AC_PROG_CC. AM_PROG_LEX, AC_PROG_YACC, and a few others. Thanks for your interest in the book, but please beware that Autotools have come a *really* long way since the book was written. I have a back burner project to update the content, and self-publish a second edition. I’d be delighted if you emailed me with details of anything you find that really confounds you, or anything else you think needs fixing. What are the canned macros to specify ASLR (-fPIE/-pie for a program; -fPIC/-shared for shared objects) It’s a private API (per the leading _), but libtool.m4 sets PIC flags with _LT_COMPILER_PIC, which uses tags to keep track of different settings for cc/cxx etc. Even libtool doesn’t deal with PIE flags though. Fortified Sources (-DFORTIFY_SOURCE), You can set that in CPPFLAGS without any problems, though that doesn’t tell you if it is changing compilation of course. Stack Protector (-fstack-protector-all and --param ssp-buffer-size), NX Stack (-Wl,-z,noexecstack), NX Heap (-Wl,-z,noexecheap), GOT hardening (-Wl,-z,relro), PLT hardening (-Wl,-z,now)? Related: are there canned macros for warning such as -Wall, -Wextra, and -Wconversion? For these others, there’s another private API in libtool.m4 for checking whether compiler options work: _LT_COMPILER_OPTION. While I wouldn’t recommend relying on internal APIs in your own code, it’s definitely useful to study the implementation to see how you can do something similar for your own code. HTH, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: process result code in if
On 7 Jun 2013, at 08:41, Miles Bader mi...@gnu.org wrote: Wait, why can't you use test $x -gt 0...? You mean test 0 -lt $x, otherwise if x starts with a hyphen (e.g -1) things will go awry! Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
[FYI] m4sugar: fix AS_VAR_GET regression.
AS_VAR_GET expands AS_ECHO inside en evaled single quoted string,
which causes the single quotes in printf '%s\n' to expose the
%s\n to the shell which expands \n to simply n before passing
it to printf.
* lib/m4sugar/m4sh.m4 (AS_ECHO): Use double quotes around the
format string.
* doc/autoconf.texi (Limitations of Shell Builtins): Show double
quotes to match AS_ECHO expansion.
* NEWS: Likewise.
---
NEWS| 2 +-
doc/autoconf.texi | 2 +-
lib/m4sugar/m4sh.m4 | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/NEWS b/NEWS
index 35e7b88..16de922 100644
--- a/NEWS
+++ b/NEWS
@@ -10,7 +10,7 @@ GNU Autoconf NEWS - User visible changes.
** Use of printf is now recommended instead of working around bugs in
echo. Macros AS_ECHO and AS_ECHO_N now expand unconditionally to
- printf '%s\n' and printf %s.
+ 'printf %s\n' and 'printf %s'.
** Macros
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index c95d871..8f58d4a 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -17523,7 +17523,7 @@ only if you know that @var{foo}'s value cannot contain
backslashes and
cannot start with @samp{-}.
Normally, @command{printf} is safer and easier to use than @command{echo}
-and @command{echo -n}. Thus, you should use @command{printf '%s\n'}
+and @command{echo -n}. Thus, you should use @command{printf %s\n}
instead of @command{echo}, and similarly use @command{printf %s} instead
of @command{echo -n}.
diff --git a/lib/m4sugar/m4sh.m4 b/lib/m4sugar/m4sh.m4
index 479c2d9..53fdf8d 100644
--- a/lib/m4sugar/m4sh.m4
+++ b/lib/m4sugar/m4sh.m4
@@ -1026,7 +1026,7 @@ fi
# (typically a quoted string). The bytes of WORD are output as-is, even
# if it starts with - or contains \.
m4_defun([AS_ECHO],
-[printf '%s\n' $1])
+[printf %s\n $1])
# AS_ECHO_N(WORD)
--
1.8.1.1
Re: [FYI] m4sugar: fix AS_VAR_GET regression.
Hi Peter,
On 29 Jan 2013, at 20:17, Peter Rosin p...@lysator.liu.se wrote:
On 2013-01-29 13:27, Gary V. Vaughan wrote:
Normally, @command{printf} is safer and easier to use than @command{echo}
-and @command{echo -n}. Thus, you should use @command{printf '%s\n'}
+and @command{echo -n}. Thus, you should use @command{printf %s\n}
Shouldn't it be
printf %s\\n
when you write it outside single quotes?
Apparently not; before my original patch, AS_ECHO would (under the right
circumstances) expand to 'printf %s\n' (single backslash), and indeed
passes the testsuite again now that I've patched it to expand to the same
under all circumstances.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
[PATCH] m4sugar: factor away _AS_ECHO_PREPARE.
From: Gary V. Vaughan g...@gnu.org Following a recent discussion on bug-gnulib, Jim tells me not to use the ugly as_echo setting boilerplate in my scripts anymore, since printf has been available on every shell we care about for at least 5 if not 10 years. That affords us the opportunity to simplify Autoconf somewhat in the same area. Patch follows. Okay to push? Cheers, Gary printf '%s\n' ... has been a fine replacement for plain echo for at least 5 years (probably more like 10), even with most museum-piece shells. * lib/m4sugar/m4sh.m4 (_AS_ECHO_PREPARE): Remove. (_AS_SHELL_SANITIZE): Keep as_nl setting originally from _AS_ECHO_PREPARE here where it more properly belongs. (AS_ECHO, AS_ECHO_N): Use printf unconditionally. Reported by Jim Meyering. --- lib/m4sugar/m4sh.m4 | 60 +++-- 1 file changed, 7 insertions(+), 53 deletions(-) diff --git a/lib/m4sugar/m4sh.m4 b/lib/m4sugar/m4sh.m4 index 25b4fe3..cd1718b 100644 --- a/lib/m4sugar/m4sh.m4 +++ b/lib/m4sugar/m4sh.m4 @@ -453,7 +453,6 @@ m4_defun([_AS_SHELL_SANITIZE], [m4_text_box([M4sh Initialization.]) AS_BOURNE_COMPATIBLE -_AS_ECHO_PREPARE _AS_PATH_SEPARATOR_PREPARE # IFS @@ -461,6 +460,9 @@ _AS_PATH_SEPARATOR_PREPARE # there to prevent editors from complaining about space-tab. # (If _AS_PATH_WALK were called with IFS unset, it would disable word # splitting by setting IFS to empty value.) +as_nl=' +' +export as_nl IFS=$as_nl # Find who we are. Look in the path if we contain no directory separator. @@ -1023,63 +1025,15 @@ fi # Output WORD followed by a newline. WORD must be a single shell word # (typically a quoted string). The bytes of WORD are output as-is, even # if it starts with - or contains \. -m4_defun_init([AS_ECHO], -[AS_REQUIRE([_$0_PREPARE])], -[$as_echo $1]) +m4_defun([AS_ECHO], +[printf '%s\n' $1]) # AS_ECHO_N(WORD) # --- # Like AS_ECHO(WORD), except do not output the trailing newline. -m4_defun_init([AS_ECHO_N], -[AS_REQUIRE([_AS_ECHO_PREPARE])], -[$as_echo_n $1]) - - -# _AS_ECHO_PREPARE -# -# Arrange for $as_echo 'FOO' to echo FOO without escape-interpretation; -# and similarly for $as_echo_n, which omits the trailing newline. -# 'FOO' is an optional single argument; a missing FOO is treated as empty. -m4_defun([_AS_ECHO_PREPARE], -[[as_nl=' -' -export as_nl -# Printing a long string crashes Solaris 7 /usr/bin/printf. -as_echo='\\\' -as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo -as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo$as_echo -# Prefer a ksh shell builtin over an external printf program on Solaris, -# but without wasting forks for bash or zsh. -if test -z $BASH_VERSION$ZSH_VERSION \ - (test X`print -r -- $as_echo` = X$as_echo) 2/dev/null; then - as_echo='print -r --' - as_echo_n='print -rn --' -elif (test X`printf %s $as_echo` = X$as_echo) 2/dev/null; then - as_echo='printf %s\n' - as_echo_n='printf %s' -else - if test X`(/usr/ucb/echo -n -n $as_echo) 2/dev/null` = X-n $as_echo; then -as_echo_body='eval /usr/ucb/echo -n $][1$as_nl' -as_echo_n='/usr/ucb/echo -n' - else -as_echo_body='eval expr X$][1 : X\\(.*\\)' -as_echo_n_body='eval - arg=$][1; - case $arg in @%:@( - *$as_nl*) - expr X$arg : X\\(.*\\)$as_nl; - arg=`expr X$arg : .*$as_nl\\(.*\\)`;; - esac; - expr X$arg : X\\(.*\\) | tr -d $as_nl -' -export as_echo_n_body -as_echo_n='sh -c $as_echo_n_body as_echo' - fi - export as_echo_body - as_echo='sh -c $as_echo_body as_echo' -fi -]])# _AS_ECHO_PREPARE +m4_defun([AS_ECHO_N], +[printf '%s' $1]) # AS_TEST_X -- 1.8.1
Re: [PATCH] m4sugar: factor away _AS_ECHO_PREPARE.
Hi Paul,
On 29 Jan 2013, at 06:13, Paul Eggert egg...@cs.ucla.edu wrote:
This change would break gnulib's gl_CACHE_VAL_SILENT.
Is there some way you can fix that?
Sure, since gl_CACHE_VAL_SILENT is already using undocumented
internals of Autoconf, how about:
m4_pushdef([_AS_ECHO_N], [:
])
...
m4_popdef([_AS_ECHO_N])
It's OK if we
have to modify gl_CACHE_VAL_SILENT, it's just that
we need to modify it in a way that'll work with both
old and new Autoconf.
However, is there a rationale for sometimes having Autoconf show
the '(cached) ' message, except for gnulib tests? Maybe a better
approach is to weigh the pros and cons of showing '(cached) ' and
then consistently display it for all tests, or take it out of
Autoconf altogether? That would also decouple gnulib from having
to keep a careful eye on changes to internal APIs in Autoconf for
at least this one usage.
Also, any such patch to Autoconf should update
the documentation a bit for @item @command {echo},
and it needs a NEWS item.
Okay, I'll reroll the patch with those additions presently.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
[PATCHv2] m4sugar: factor away _AS_ECHO_PREPARE.
Added NEWS entry, and updated texinfo documentation for echo.
Okay to push?
printf '%s\n' ... has been a fine replacement for plain echo
for at least 5 years (probably more like 10), even with most
museum-piece shells.
* lib/m4sugar/m4sh.m4 (_AS_ECHO_PREPARE): Remove.
(_AS_SHELL_SANITIZE): Keep as_nl setting originally from
_AS_ECHO_PREPARE here where it more properly belongs.
(AS_ECHO, AS_ECHO_N): Use printf unconditionally.
* doc/autoconf.text (Limitations of Shell Builtins): Document
preference for 'printf' over working around 'echo' bugs.
* NEWS: Updated.
Reported by Jim Meyering.
---
NEWS| 4
doc/autoconf.texi | 21 +--
lib/m4sugar/m4sh.m4 | 60 +++--
3 files changed, 21 insertions(+), 64 deletions(-)
diff --git a/NEWS b/NEWS
index a9b2226..2d76040 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,10 @@ GNU Autoconf NEWS - User visible changes.
** Older version of automake and aclocal ( 1.8) are no longer supported
by autoreconf.
+** Use of 'printf' is now recommended instead of working around bugs in
+ 'echo'. Macros AS_ECHO and AS_ECHO_N now expand unconditionally to
+ 'printf %s\n' and 'printf %s' unconditionally.
+
** Macros
- New macro AC_C__GENERIC.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index bb83443..356c089 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -17494,12 +17494,16 @@ characters to @command{echo}. For example,
@samp{echo $foo} is safe
only if you know that @var{foo}'s value cannot contain backslashes and
cannot start with @samp{-}.
-If this may not be true, @command{printf} is in general safer and
-easier to use than @command{echo} and @command{echo -n}. Thus, scripts
-where portability is not a major concern should use @command{printf
-'%s\n'} whenever @command{echo} could fail, and similarly use
-@command{printf %s} instead of @command{echo -n}. For portable shell
-scripts, instead, it is suggested to use a here-document like this:
+Normally, @command{printf} is safer and easier to use than @command{echo}
+and @command{echo -n}. Thus, you should use @command{printf '%s\n'}
+instead of @command{echo}, and similarly use @command{printf %s} instead
+of @command{echo -n}.
+
+Where portability to obsolete environments, prior to the common
+availability of @command{printf}, is still a concern, and where you
+cannot be certain the arguments to @command{echo} do not contain
+backslashes or begin with a minus, it is suggested to use a
+here-document like this:
@example
cat EOF
@@ -17507,11 +17511,6 @@ $foo
EOF
@end example
-Alternatively, M4sh provides @code{AS_ECHO} and @code{AS_ECHO_N} macros
-which choose between various portable implementations: @samp{echo}
-or @samp{print} where they work, @command{printf} if it is available,
-or else other creative tricks in order to work around the above problems.
-
@item @command{eval}
@c -
diff --git a/lib/m4sugar/m4sh.m4 b/lib/m4sugar/m4sh.m4
index 25b4fe3..cd1718b 100644
--- a/lib/m4sugar/m4sh.m4
+++ b/lib/m4sugar/m4sh.m4
@@ -453,7 +453,6 @@ m4_defun([_AS_SHELL_SANITIZE],
[m4_text_box([M4sh Initialization.])
AS_BOURNE_COMPATIBLE
-_AS_ECHO_PREPARE
_AS_PATH_SEPARATOR_PREPARE
# IFS
@@ -461,6 +460,9 @@ _AS_PATH_SEPARATOR_PREPARE
# there to prevent editors from complaining about space-tab.
# (If _AS_PATH_WALK were called with IFS unset, it would disable word
# splitting by setting IFS to empty value.)
+as_nl='
+'
+export as_nl
IFS=$as_nl
# Find who we are. Look in the path if we contain no directory separator.
@@ -1023,63 +1025,15 @@ fi
# Output WORD followed by a newline. WORD must be a single shell word
# (typically a quoted string). The bytes of WORD are output as-is, even
# if it starts with - or contains \.
-m4_defun_init([AS_ECHO],
-[AS_REQUIRE([_$0_PREPARE])],
-[$as_echo $1])
+m4_defun([AS_ECHO],
+[printf '%s\n' $1])
# AS_ECHO_N(WORD)
# ---
# Like AS_ECHO(WORD), except do not output the trailing newline.
-m4_defun_init([AS_ECHO_N],
-[AS_REQUIRE([_AS_ECHO_PREPARE])],
-[$as_echo_n $1])
-
-
-# _AS_ECHO_PREPARE
-#
-# Arrange for $as_echo 'FOO' to echo FOO without escape-interpretation;
-# and similarly for $as_echo_n, which omits the trailing newline.
-# 'FOO' is an optional single argument; a missing FOO is treated as empty.
-m4_defun([_AS_ECHO_PREPARE],
-[[as_nl='
-'
-export as_nl
-# Printing a long string crashes Solaris 7 /usr/bin/printf.
-as_echo='\\\'
-as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo
-as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo$as_echo
-# Prefer a ksh shell builtin over an external printf program on Solaris,
-# but without wasting forks for bash or zsh.
-if test -z $BASH_VERSION$ZSH_VERSION \
- (test X`print -r -- $as_echo` = X$as_echo) 2/dev/null; then
- as_echo='print -r --'
- as_echo_n='print -rn
Re: [PATCHv2] m4sugar: factor away _AS_ECHO_PREPARE.
On 29 Jan 2013, at 09:24, Gary V. Vaughan g...@gnu.org wrote: Added NEWS entry, and updated texinfo documentation for echo. Okay to push? [[snip]] +** Use of 'printf' is now recommended instead of working around bugs in + 'echo'. Macros AS_ECHO and AS_ECHO_N now expand unconditionally to + 'printf %s\n' and 'printf %s' unconditionally. Erm. [PATCHv3] Minus the final word of that sentence before pushing. Sorry. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
[PATCHv3] m4sugar: factor away _AS_ECHO_PREPARE.
Incorporating feedback from Paul and Paul. Thank you both :)
Okay to push?
printf '%s\n' ... has been a fine replacement for plain echo
for at least 5 years (probably more like 10), even with most
museum-piece shells.
* lib/m4sugar/m4sh.m4 (_AS_ECHO_PREPARE): Remove.
(_AS_SHELL_SANITIZE): Keep as_nl setting originally from
_AS_ECHO_PREPARE here where it more properly belongs.
(AS_ECHO, AS_ECHO_N): Use printf unconditionally.
* doc/autoconf.texi (Limitations of Shell Builtins): Document
preference for 'printf' over working around 'echo' bugs.
* NEWS: Updated.
Reported by Jim Meyering.
---
NEWS| 4
doc/autoconf.texi | 19 +++--
lib/m4sugar/m4sh.m4 | 60 +++--
3 files changed, 19 insertions(+), 64 deletions(-)
diff --git a/NEWS b/NEWS
index a9b2226..3934a06 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,10 @@ GNU Autoconf NEWS - User visible changes.
** Older version of automake and aclocal ( 1.8) are no longer supported
by autoreconf.
+** Use of printf is now recommended instead of working around bugs in
+ echo. Macros AS_ECHO and AS_ECHO_N now expand unconditionally to
+ printf '%s\n' and printf %s.
+
** Macros
- New macro AC_C__GENERIC.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index bb83443..7011da6 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -17494,12 +17494,14 @@ characters to @command{echo}. For example,
@samp{echo $foo} is safe
only if you know that @var{foo}'s value cannot contain backslashes and
cannot start with @samp{-}.
-If this may not be true, @command{printf} is in general safer and
-easier to use than @command{echo} and @command{echo -n}. Thus, scripts
-where portability is not a major concern should use @command{printf
-'%s\n'} whenever @command{echo} could fail, and similarly use
-@command{printf %s} instead of @command{echo -n}. For portable shell
-scripts, instead, it is suggested to use a here-document like this:
+Normally, @command{printf} is safer and easier to use than @command{echo}
+and @command{echo -n}. Thus, you should use @command{printf '%s\n'}
+instead of @command{echo}, and similarly use @command{printf %s} instead
+of @command{echo -n}.
+
+Older scripts, written before @command{printf} was portable,
+sometimes used a here-document as a safer alternative to @command{echo},
+like this:
@example
cat EOF
@@ -17507,11 +17509,6 @@ $foo
EOF
@end example
-Alternatively, M4sh provides @code{AS_ECHO} and @code{AS_ECHO_N} macros
-which choose between various portable implementations: @samp{echo}
-or @samp{print} where they work, @command{printf} if it is available,
-or else other creative tricks in order to work around the above problems.
-
@item @command{eval}
@c -
diff --git a/lib/m4sugar/m4sh.m4 b/lib/m4sugar/m4sh.m4
index 25b4fe3..479c2d9 100644
--- a/lib/m4sugar/m4sh.m4
+++ b/lib/m4sugar/m4sh.m4
@@ -453,7 +453,6 @@ m4_defun([_AS_SHELL_SANITIZE],
[m4_text_box([M4sh Initialization.])
AS_BOURNE_COMPATIBLE
-_AS_ECHO_PREPARE
_AS_PATH_SEPARATOR_PREPARE
# IFS
@@ -461,6 +460,9 @@ _AS_PATH_SEPARATOR_PREPARE
# there to prevent editors from complaining about space-tab.
# (If _AS_PATH_WALK were called with IFS unset, it would disable word
# splitting by setting IFS to empty value.)
+as_nl='
+'
+export as_nl
IFS=$as_nl
# Find who we are. Look in the path if we contain no directory separator.
@@ -1023,63 +1025,15 @@ fi
# Output WORD followed by a newline. WORD must be a single shell word
# (typically a quoted string). The bytes of WORD are output as-is, even
# if it starts with - or contains \.
-m4_defun_init([AS_ECHO],
-[AS_REQUIRE([_$0_PREPARE])],
-[$as_echo $1])
+m4_defun([AS_ECHO],
+[printf '%s\n' $1])
# AS_ECHO_N(WORD)
# ---
# Like AS_ECHO(WORD), except do not output the trailing newline.
-m4_defun_init([AS_ECHO_N],
-[AS_REQUIRE([_AS_ECHO_PREPARE])],
-[$as_echo_n $1])
-
-
-# _AS_ECHO_PREPARE
-#
-# Arrange for $as_echo 'FOO' to echo FOO without escape-interpretation;
-# and similarly for $as_echo_n, which omits the trailing newline.
-# 'FOO' is an optional single argument; a missing FOO is treated as empty.
-m4_defun([_AS_ECHO_PREPARE],
-[[as_nl='
-'
-export as_nl
-# Printing a long string crashes Solaris 7 /usr/bin/printf.
-as_echo='\\\'
-as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo
-as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo$as_echo
-# Prefer a ksh shell builtin over an external printf program on Solaris,
-# but without wasting forks for bash or zsh.
-if test -z $BASH_VERSION$ZSH_VERSION \
- (test X`print -r -- $as_echo` = X$as_echo) 2/dev/null; then
- as_echo='print -r --'
- as_echo_n='print -rn --'
-elif (test X`printf %s $as_echo` = X$as_echo) 2/dev/null; then
- as_echo='printf %s\n'
- as_echo_n='printf %s'
-else
- if test X`(/usr/ucb/echo -n -n
Re: [PATCHv3] m4sugar: factor away _AS_ECHO_PREPARE.
On 29 Jan 2013, at 13:17, Gary V. Vaughan g...@gnu.org wrote: Incorporating feedback from Paul and Paul. Of course that should say Paul and *Peter*. Apologies. Typos on parade. Time for a break methinks. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
Hi Nick, On Oct 17, 2012, at 3:46 AM, Nick Bowler nbow...@elliptictech.com wrote: Tools like libtoolize will (again, hopefully) be using this information to decide where to copy libtool macros. Probably aclocal --install will need to do this as well. If multiple macro directories are specified, which one should they use? I think the answer should be: The first directory in the documented ordering, if for no other reason than that is what libtoolize currently does when it snarfs in ACLOCAL_AMFLAGS. For a few years now, libtoolize has checked that the first -I dirname matches the argument to AC_CONFIG_MACRO_DIR, when both are given, providing a diagnostic error if they do not. Otherwise if only one of those is provided by the calling project, it uses whichever is provided as the destination for libtool.m4 and friends. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
Hi Eric, On Oct 17, 2012, at 4:45 AM, Eric Blake ebl...@redhat.com wrote: On 10/16/2012 03:38 PM, Andrew W. Nosenko wrote: Excuse, may be it's too late to party, but... What is the reason to to invent yet another macro name? Anyway in the most packages there will be one and the only one line: AC_CONFIG_MACRO_DIR([m4]) And even when the many dirs are need, they will be written one by one in the theirs own macro call: AC_CONFIG_MACRO_DIR([m4]) AC_CONFIG_MACRO_DIR([sub/m4]) AC_CONFIG_MACRO_DIR([pack/m4]) (The reasons for such stacking is the same as the reasons for lineup an arguments in a function call with a number of parameters in the C-like languages -- aesthetics and ability to easy comment out some of them. The later becomes even more important in languages with the only one style of comment -- from comment-char to the end-of-line, like autoconf language.) The problem is that existing tools (here's looking at you libtool) are inconsistent if you HAPPEN to use AC_CONFIG_MACRO_DIR - some use the first directory, others use the last, and some crash altogether. Libtool does its best with an under-specified interface, and tries to be future proof by checking for consistency between the AC_CONFIG_MACRO_DIR argument and the first -I argument in ACLOCAL_AMFLAGS. By inspection, it seems that released libtools (at least the recent ones I looked at) will take the last directory if AC_CONFIG_MACRO_DIR is given more than once. Using just the m4 perspective, yes, the macros are aliases (they both do nothing). But from the autoconf --trace perspective, having two macros matters, because not all tools used --trace (older libtool was using sed, rather poorly), and we don't want to break interoperability with old tools, all while still allowing new tools (automake 1.13) to take advantage of the multiple directories. It's not possible for libtoolize to use autoconf traces to examine the contents of configure.ac/aclocal.m4 since it needs to be able to run before all the macros required from there (e.g. libtool.m4) are available. Because of that ALL released versions of libtoolize use sed to find out what macros are declared by the user. Please tell me what is poor about the use of sed in libtoolize and I will fix it and make a point release. I imagine aclocal must be parsing configure.ac with regular expressions too for the same reason, but Perl makes my eyes bleed so I can't tell by looking at it. In the meanwhile, I found a way to use GNU M4 traces to look at autoconf macro arguments in the user's configure.ac even before all the relevant macro definitions are available (before aclocal/autopoint/libtoolize have completed), so the next major release is much more robust to M4 quoting etc. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
Hi Stefano, On Oct 17, 2012, at 2:25 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: based solely on this documentation, that deal with these macro directories. It would be very bad if we ended up with two tools that, for example, interpreted the directory ordering differently. ... but your rationale has convinced me I was wrong. I will send (later or tomorrow) a re-roll with improved documentation. Tools like libtoolize will (again, hopefully) be using this information to decide where to copy libtool macros. Probably aclocal --install will need to do this as well. If multiple macro directories are specified, which one should they use? I think the answer should be: The first directory in the documented ordering, Yes, this is the behaviour I intended to implement in aclocal. I remember many years ago that Tom Tromey (IIRC) stated that aclocal was just a stop-gap measure until autoconf could find it's own macros. I'd *really* like to see aclocal die as a separate program, and have autoconf look for (and if requested, copy into the project tree) all the .m4 files it needs to generate a configure script. No need even for aclocal.m4 in that case anymore... the fewer files and tools we have to teach people about, the less baroque those people will feel that the Autotools are, and the easier the GBS is to understand and learn. I'd have written patches myself long ago, but sadly, Autoconf moved its implementation to Perl before I had time to do it :( I think simplifying Autotools to the point where you no longer need to write a separate bootstrap script to invoke them in just the right order will be necessary -- just an 'autoreconf' and off you go! :) Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [RFC] Superseding aclocal? (was: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal)
Hi Stefano,
Thanks for the fast response!
On 17 Oct 2012, at 15:52, Stefano Lattarini stefano.lattar...@gmail.com wrote:
[Adding Automake list in CC:]
Reference:
https://lists.gnu.org/archive/html/autoconf-patches/2012-10/msg00018.html
On 10/17/2012 10:25 AM, Gary V. Vaughan wrote:
[SNIP]
I remember many years ago that Tom Tromey (IIRC) stated that aclocal
was just a stop-gap measure until autoconf could find it's own macros.
I'd *really* like to see aclocal die as a separate program, and have
autoconf look for (and if requested, copy into the project tree) all the .m4
files it needs to generate a configure script.
Me too... But aclocal has existed and been used for so many years now that
I think we can't just make it disappear overnight; we'd need a carefully
crafted, documented and publicized transition plan. A fist step might be
to move aclocal out into its own git repository, while still distributing
it bundled with Automake (this could be done for Automake 1.14). But before
starting even to plan for that move, I'd want to be sure that the intended
replacement is well underway (that is, designed, agreed upon, and with at
least a semi-working prototype), and that the community is happy with this
transition and committed to help it.
I think there is no need for such a cumbersome transition. Instead, I would
do it like this:
1. Fold macro search/copy code into autoconf (along with -I argument support)
2. Reimplement aclocal as a wrapper to call autoconf
Tools that still use aclocal can do so harmlessly while it is deprecated,
but in the mean time everyone can begin to move to a more streamlined build
that simply skips the aclocal step.
No need even for aclocal.m4
in that case anymore... the fewer files and tools we have to teach people
about, the less baroque those people will feel that the Autotools are, and
the easier the GBS is to understand and learn.
Honestly, AFAICS, few people complained about aclocal so far (which sadly
can't be said for automake and autoconf). So aclocal might be annoying for
us to maintain, but doesn't seem a real burden for the users.
Most likely because the folks that complain can't distinguish between
where aclocal ends and automake/autoconf begins ;)
I'd have written patches myself long ago, but sadly, Autoconf moved its
implementation to Perl before I had time to do it :(
I honestly believe having an implementation of autom4te, aclocal or automake
in portable shell scripting would be insane. Perl is much, much safer and
easier to use for such moderately big programs. Not to mention more
efficient, especially for platforms with expensive fork() like Cygwin.
Agreed. Perl was a good choice at the time.
I meant unfortunate for me, since after two failed attempts comprising several
painful readings of the Camel and Llama books, I finally gave up trying to
understand Perl over a decade ago. If it were in a language that made sense to
me, I'd have written the patches already. I can sorta kinda still hit Perl code
with a hammer, and make it work, but it would be as unreadable to everyone
else, as other Perl code is to me.
-- And unfortunate for whoever writes the perl patches, since I didn't do it
for them ;)
At least I can help with the design a bit...
Here's a minimal modernish bootstrap script:
#!/bin/sh
autopoint --force
libtoolize --copy --install
aclocal # m4 dir from ACLOCAL_AMFLAGS
autoconf
autoheader
automake --add-missing --copy
With aclocal search and copy rolled into autoconf, it could look the same,
or else like this:
#!/bin/sh
autopoint --force
libtoolize --copy --install
autoconf # m4 dir from AC_CONFIG_MACRO_DIR{,S}
autoheader
automake --add-missing --copy
OFF-TOPIC
If autoreconf were smarter about autopoint and libtoolize ordering, it might
even be possible to fold much of the bootstrap script nonsense back into
autoreconf, but that's a discussion for another day.
/OFF-TOPIC
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Re: Testing the value of a variable defined with m4_define (configure.ac)
On 5 Nov 2011, at 21:10, Thomas Adam wrote: previously defined: if test x$ISRELEASED = xyes; then VAR=somevalue VAR2=somevalue2 fi Now, though, the shell script I mentioned is instead setting ISRELEAED like this: m4_define([ISRELEASED], [$VALUE_OF_RELEASE_STATUS]) So my question is, how can I change the if test above to now test the value of ISRELEASED Comparing an expansion at m4 time to insert shell code conditionally: m4_if(ISRELEASED, [yes], [VAR=somevalue; VAR2=somevalue2]) Generating code to compare the expansion at shell-time: if yes = ISRELEASED; then VAR=somevalue; VAR2=somevalue2; fi HTH, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Getting AC_PROG_CC_C99
[Re-adding bug-autoconf] Hi Bruno, On 30 Sep 2011, at 16:56, Bruno Haible wrote: Gary V. Vaughan wrote: But why emit a warning when we can just fix-up the definition on the fly? ... This changeset fixes AC_PROG_CC_C99 (and effectively AC_PROG_CC_STDC) whether it is called before or after gl_EARLY, directly or by AC_PROG_CC_STDC, or even not at all! ... +[AC_PROVIDE_IFELSE([AC_PROG_CC_C99], +[AC_DEFUN([AC_PROG_CC_C99])], + [AC_DEFUN([AC_PROG_CC_C99], +m4_defn([AC_PROG_CC_C99])[AC_DEFUN([AC_PROG_CC_C99])])])]) We can't use this. AC_PROVIDE_IFELSE is undocumented. Oh yuck. Good point. Libtool is a bad citizen... oopsie. By putting the fix in gl_EARLY rather than autoconf itself, there's still the possibility of getting multiple expansions with something like: AC_PROG_CC AC_PROG_CC_C99 AC_PROG_CC_STDC gl_EARLY But that seems pathological to me in any case, so I haven't tried to address that. That's why I think it should be addressed in Autoconf. And I think it is as easy as adding AC_DEFUN([AC_PROG_CC_C99]) to the end of the existing AC_PROG_CC_C99 macro to make sure subsequent invocations expand to nothing. And maybe the same thing in AC_PROG_CC_C89 if it has the same bug. Autoconf folks, please ask me if you'd like a patch to that effect. * m4/gnulib-common (gl_PROG_CC_C99_ONCE): New macro to automatically neuter AC_PROG_CC_C99 after first invocation. We didn't say that we want to enable C99 for all programs. See http://lists.gnu.org/archive/html/bug-gnulib/2011-09/msg00441.html Ah yes, I got a bit too excited there. I'm applying this for now. Maybe you have a more acceptable workaround against the $CC gets augmented twice problem? Your patch is perfectly acceptable to me already. Thank you! 2011-09-30 Bruno Haible br...@clisp.org Centralize C99 requirement. * m4/gnulib-common.m4 (gl_PROG_CC_C99): New macro. * modules/stdarg (configure.ac-early): Invoke it instead of AC_PROG_CC_STDC. Reported by Gary V. Vaughan and Paul Eggert. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Fwd: Getting AC_PROG_CC_C99
From a private discussion about preventing CFLAGS getting -std=gnu99 twice, that leads to a bug report for gnulib and maybe autoconf too... Begin forwarded message: From: Gary V. Vaughan g...@gnu.org Subject: Re: Getting AC_PROG_CC_C99 Date: 28 September 2011 12:38:33 GMT+07:00 To: Reuben Thomas r...@sc3d.org Hi Reuben, On 27 Sep 2011, at 20:16, Reuben Thomas wrote: According to the Zile commit logs: configury: remove duplicate AC_GNU_SOURCE et al AC_GNU_SOURCE and AC_PROG_CC_C99 are automatically required by gl_INIT, no need to specify them again in configure.ac (which results in running `gcc -std=gnu99 -std=gnu99'. I hasten to add there's nothing going wrong in Zile AFAICS. However, in another project (occurs, as mentioned yesterday), I don't automatically get AC_PROG_CC_C99, even though I'm using gnulib, and definitely have the extensions module in there. I've looked at the configure files (sadly hard to examine as there are no comments telling you which bit was expanded from which configure.ac line), and can't see anything obvious. I've stared at the configure.ac files, natch, and ditto. Any hints? I have also looked at the list of gnulib modules for each project and can't see anything there. Actually, AC_PROG_CC_C99 is automatically called in autoconf's own macros by AC_PROG_CC_STDC (see /usr/share/autoconf/autoconf/c.m4), and it is *that* macro that gnulib is hooking automatically. By grepping through the Zile m4 directory after bootstrapping I quickly came across this in gnulib-comp.m4: # Code from module stdarg: dnl Some compilers (e.g., AIX 5.3 cc) need to be in c99 mode dnl for the builtin va_copy to work. With Autoconf 2.60 or later, dnl AC_PROG_CC_STDC arranges for this. With older Autoconf AC_PROG_CC_STDC dnl shouldn't hurt, though installers are on their own to set c99 mode. AC_REQUIRE([AC_PROG_CC_STDC]) The stdarg module is listed explicitly in Zile's bootstrap.conf module list, so that is how Zile gets an expansion of AC_PROG_CC_STDC (and the c99 mode setting option tests) for free. Now, the interesting thing is that if I grep through the gnulib/modules directory for AC_PROG_CC_STDC calls, *only* stdarg has it. That strikes me as kind of odd. Shouldn't all the C99 related modules be calling at least AC_PROG_CC_C99 if not the whole AC_PROG_CC_STDC set? And that points to another problem, because AC_PROG_CC_STDC is not safe to call multiple times, since it adds another --std=gnu99 to CFLAGS every time it is invoked (at least the version in my Apple suppied Autoconf-2.61), so gnulib should probably also have some multiple expansion protection code for at least us poor Mac based devs using Homebrew (untested!!): dnl make sure we only expand AC_PROG_CC_STDC once AC_DEFUN_ONCE([gl_PROG_CC_C99], [ AC_PROVIDE_IFELSE([AC_PROG_CC_C99], [], [AC_PROG_CC_C99])m4_define([AC_PROG_CC_C99])]) And then add gl_PROG_CC_C99 to all the C99 modules. It's not a big problem, as I can just reinstate AC_PROG_CC_C99 in occurs's configure.ac, but it suggests I'm not understanding something. Might as well try to fix it right in gnulib though, and maybe in autoconf too if the latest release hasn't made it multi-call safe yet. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: How to enable/disable my debug code?
On 31 Jul 2011, at 02:04, NightStrike wrote: On Wed, Jul 27, 2011 at 10:22 PM, narke narkewo...@gmail.com wrote: On 27 July 2011 14:36, Gary V. Vaughan g...@vaughan.pe wrote: because those are in the users' namespace. Instead, Makefile.am should be setting required (but not compiler specific!!) options inside AM_CPPFLAGS/AM_CFLAGS/AM_LDFLAGS/etc. The info manuals will help you How can you have compiler-generic options? It's not like POSIX says that -O2 is for optimization, -g is for debug, and -D is for a commandline define. Unless I'm completely wrong, and there is in fact some sort of standard for compiler options other than do whatever gcc does. For example: AM_CPPFLAGS = -I../gnulib -I../libltdl AM_LDFLAGS = -L../libltdl @LIBTHREAD@ As in things that need to be there for your project to build, even if the user passes flags of their own at make time. Consider, though, using cl.exe in an msys environment. That uses / instead of - for switches, for instance. I would be quite surprised if more that a very few Autotools using projects compiled in that environment out of the box. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How to enable/disable my debug code?
On 31 Jul 2011, at 06:57, NightStrike wrote: On Sat, Jul 30, 2011 at 3:26 PM, Gary V. Vaughan g...@gnu.org wrote: On 31 Jul 2011, at 02:04, NightStrike wrote: Unless I'm completely wrong, and there is in fact some sort of standard for compiler options other than do whatever gcc does. For example: AM_CPPFLAGS = -I../gnulib -I../libltdl AM_LDFLAGS = -L../libltdl @LIBTHREAD@ As in things that need to be there for your project to build, even if the user passes flags of their own at make time. My point was just that there's nothing that forces every compiler to make -Idir the way to set the include path. It happens to be that way for a few popular ones like icc because people generally just do what GCC does. But nothing stops someone from making a compiler where it uses lowercase i, for instance. These options HAVE to be compiler specific. You're not wrong. But I was answering the original question be stating that current best practice for Autotools using projects is to separate the various build and link flags into two groups: i) my project won't build without this; ii) users might like to set this. Group (i) goes into the AM_* prefixed automake macros and are set by the developer in advance of the release; Group (ii) are entirely at the discretion of the user and can be set arbitrarily at compile and/or configure time. That's just the way automake was designed. Consider, though, using cl.exe in an msys environment. That uses / instead of - for switches, for instance. I would be quite surprised if more that a very few Autotools using projects compiled in that environment out of the box. I'm trying to make that work, actually. It's very hard. Current best practice in this case is to make a compiler wrapper script that translates the flags from what Autotools expect to be universally available (-I, -L etc) into whatever unusual syntax cl.exe might prefer, and then to pass the wrapper script as CC at configure time. There is still some hair to untangle if you want Autotools to ship that wrapper script and/or automatically set CC to use it. But in principle it shouldn't be too difficult to solve in the same way that Automake's `compile` script works around the unportability of '-c -o' - infact it's not a bad idea to patch `compile` to take care of any other useful command line rewriting problems... Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How to enable/disable my debug code?
On 27 Jul 2011, at 12:56, narke wrote: With a same set of autoconf/automake files, how to I distribute my program that allows user to build it with or without debug code enabled? In my code, there are something like below: #if (__MY_DEBUG__) ... #endif Thanks in advance. For debug builds: ./configure CFLAGS='-g' CPPFLAGS=-D__MY_DEBUG__ For regular builds: ./configure If you use assert.h, you can also speed things up a bit more by turning off the assertions with: ./configure CPPFLAGS=-DNDEBUG Of course you can write (or find and copy) some Autoconf M4 code to do some or all of the above automatically depending on the presence of configure options like: ./configure --enable-debug Googling for 'AC_ARG_ENABLE debug' turns up many examples such as: AC_ARG_ENABLE([debug], [ --enable-debug build with additional debugging code], [CFLAGS='-g';AC_DEFINE([__MY_DEBUG__])]) HTH, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How to enable/disable my debug code?
On 27 Jul 2011, at 19:22, narke wrote: Hi, Gary Howdy! On 27 July 2011 14:36, Gary V. Vaughan g...@vaughan.pe wrote: On 27 Jul 2011, at 12:56, narke wrote: With a same set of autoconf/automake files, how to I distribute my program that allows user to build it with or without debug code enabled? In my code, there are something like below: #if (__MY_DEBUG__) ... #endif Thanks in advance. For debug builds: ./configure CFLAGS='-g' CPPFLAGS=-D__MY_DEBUG__ For this approach, will it overwrite my already defined flags or just append values to them? It usual that my CPPFLAGS had already set as something like -I/my/include in a Makefile.am If the Makefile.am's have been written correctly (as described in the info manual and elsewhere), then CPPFLAGS/CFLAGS/LDFLAGS/etc should not be *set* in Makefile.am (although of course they are referenced often) because those are in the users' namespace. Instead, Makefile.am should be setting required (but not compiler specific!!) options inside AM_CPPFLAGS/AM_CFLAGS/AM_LDFLAGS/etc. The info manuals will help you here. Anyway, even if Makefile.am sets these flags incorrectly, since you set the options at configure time as shown above, you might still get away with it, since the configure values are then spliced into the generated Makefile's. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Parsing autoconf input before running aclocal [Was Re: autoreconf and gettext]
Hi Eric, On 31 May 2011, at 21:23, Eric Blake ebl...@redhat.com wrote: Right now, autoreconf greps configure.ac for /^AM_GNU_GETTEXST_VERSION/, rather than using autoconf --trace mechanisms. Which is unfortunate, because for situations like this, it gets the wrong answers. Sometimes, particularly with bootstrap tools that need to work before all the .m4 files required are available, it is not possible to run 'autoconf --trace' without failing on undefined macros. The solution to that /has/ been to grep through the source files; however, in the replacement bootstrap script I've submitted to gnulib on a few occasions over the last year, I came up with a much better mechanism than grep, which uses M4 itself to parse the input files for calls to important macros, so is not subject to false positives or inability to parse M4 constructed symbols... but which continues to work even which aclocal has not yet copied the depended upon macro files into view -- unlike Autoconf proper. This seems like a good mechanism to port to autoreconf IMHO. Or better yet, for incorporation into Autoconf itself as a separate --language option. Ping me if you're interested but can't find my relevant posts, and I'll look up the links for you in the gnulib archives. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Version number constructed with m4_esyscmd not a literal?
On 28 Feb 2011, at 06:12, Marko Lindqvist cazf...@gmail.com wrote: Freeciv ( http://www.freeciv.org ) configure.ac has AC_INIT like this: AC_INIT([freeciv], [m4_esyscmd([./fc_version | tr -d '\n'])]) This results in warnings from aclocal, autoheader, autoconf and automake: configure.ac:5: warning: AC_INIT: not a literal: m4_esyscmd([./fc_version | tr -d '\n']) Resulting configure seems to work correctly, and it even has correct line # Generated by GNU Autoconf 2.68 for freeciv 2.3.99-dev in it. What is wrong with our AC_INIT? I've seen use of m4_esyscmd recommended for similar cases in this list, so I assume it can be somehow used without such warning. Removing the outer quotes will let m4_esyscmd run to completion during argument collection, and (untested!) avoid the warning: AC_INIT([freeciv], m4_esyscmd([./fc_version | tr -d '\n'])) Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Use pipe and sed in configure.ac
On 10 Feb 2011, at 10:39, Lyre 417...@gmail.com wrote: I tried to exact an option from php-config using: php-config --configure-options | sed -n 's|.*--with-config-file-scan-dir=\([^ ]*\).*|\1|p' It works on shell, and outputs /etc/php5/conf.d/ on opensuse. And I tired it in configure.ac, as following: PHPINC=`php-config --includes` PHPCDIR=`php-config --configure-options | sed -n 's|.*--with-config-file-scan-dir=\([^ ]*\).*|\1|p'` AC_SUBST([PHPINC]) AC_SUBST([PHPCDIR]) After subsitution in Makefile, the PHPCDIR is empty， meanwhile PHPINC get the correct result. What' the correct way to use it? Autoconf turns your configure.ac specification in a configure shell script by running it through GNU M4, with the M4 quote characters set to [ and ]. So M4 thinks you are telling it not to expand [^ ] in the sed match expression, and after doing that, it then throws those quote marks away. If you search for the expanded text in the configure script, you'll see something like this: PHPCDIR=`php-config --configure-options | sed -n \ 's|.*--with-config-file-scan-dir=\(^ *\).*|\1|p'` Note the missing brackets, which means the sed match expression no longer works as expected. A rule of thumb is that you need to M4 quote sections of raw shell code in the configure.ac file if you don't want them to remain unmolested in the generated configure script. Things get a little more complicated if you are writing Autoconf macros, but in this case doubling up the [ and ] in configure.ac should work: PHPCDIR=`php-config --configure-options | sed -n \ 's|.*--with-config-file-scan-dir=\([[^ ]]*\).*|\1|p'` And you can search the generated configure script for PHPCDIR to check! There are some other M4 syntaxes you need to watch out for too, but I'm pretty sure they're all covered by the info manuals. HTH, Gary -- Gary V. Vaughan (g...@gnu.org) ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: minimum m4 version
Hi Adam, On 9 Nov 2010, at 13:21, Adam Mercer wrote: I'm trying to track down a strange build problem on an old Linux system (Debian Woody), I think it may be related to an m4 issue. What is the minimum version of m4 that is required for modern autotools systems as I can't find anything in the release notes (apologies if I've missed the appropriate information), Woody has 1.4 by default? The minimum m4 version is specified in the README for the version of autoconf you wish to use. Currently the relevant section says: You should install GNU M4 (version 1.4.6 or later is required 1.4.14 or later is recommended)[[...]] Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: installable gnulib library
adding AC_FUNC_ALLOCA to configure.ac.
I'll reraise the issue if it happens again.
3. missing AM_CONDITIONAL declarations
--
I suppose the following definitions are supposed to have been added to
gl_INIT
somewhere, but `git grepping' around the gnulib sources didn't lead me to the
culprit.
libposix/Makefile.am:4192: LIBUNISTRING_COMPILE_UNISTR_U8_MBTOUCR does not
appear in AM_CONDITIONAL
libposix/Makefile.am:4200: LIBUNISTRING_COMPILE_UNISTR_U8_UCTOMB does not
appear in AM_CONDITIONAL
libposix/Makefile.am:4240: LIBUNISTRING_COMPILE_UNIWIDTH_WIDTH does not
appear in AM_CONDITIONAL
Strange, I haven't seen these. Can you prepare a real bug report (tarball with
commands to execute) which shows this?
Definitely pilot error on my behalf. Please disregard this one.
4. pt_chown module
--
gnulib/modules/pt_chown hardcodes libgnu.a, so I had to edit the gnulib
generated libposix/Makefile.am in libposix to refer to libposix.la instead.
Yes, this seems unavoidable. I don't see how a program's LDADD could refer to
the library; what kind of syntax in the module description file would you
suggest for this?
libgnu.a seems like a fine syntax already, and works well for --extract-xxx
options too. I'd like to see gnulib-tool transform libgnu.a into whatever
is appropriate according to --lib and --libtool/--no-libtool arguments
without a manual post-gnulib-tool sed though.
5. AC_USE_SYSTEM_EXTENSIONS references
--
This is just a warning, and doesn't prevent compilation so I didn't try to
figure out exactly how to fix a series of these warnings:
configure.ac:12: warning: AC_COMPILE_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
configure.ac:12: the top levelconfigure.ac:12: warning: AC_RUN_IFELSE was
called before AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
configure.ac:12: the top levelconfigure.ac:12: warning: AC_COMPILE_IFELSE
was called before AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
configure.ac:12: the top levelconfigure.ac:12: warning: AC_RUN_IFELSE was
called before AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
configure.ac:12: the top level
The common way to get rid of these warnings is to insert an invocation of
gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.
Seems like a kludge to me. Either the AC_{RUN,COMPILE}_IFELSE using modules
should AC_REQUIRE_ONCE([gl_USE_SYSTEM_EXTENSIONS]) themselves, or AC_{RUN,
COMPILE}_IFELSE should invoke the require rather than the warning, no? And
if that doesn't work, then AC_REQUIRE is not outputting macro expansions in
the right order.
What's the difference between AC_USE_SYSTEM_EXTENSIONS and gl_USE_SYSTEM_
EXTENSIONS? The warnings seem to indicate that adding AC_REQUIRE([AC_
USE_SYSTEM_EXTENSIONS]) to AC_{RUN,COMPILE}_IFELSE is the right solution.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
Re: docs: document zsh specialty with empty here-documents.
On 12 Sep 2010, at 23:41, Ralf Wildenhues wrote:
docs: document zsh specialty with empty here-documents.
* doc/autoconf.texi (Here-Documents): zsh 4.3.10 adds a newline
to empty here-docs.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index e8d65cb..344aefa 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -14897,6 +14897,15 @@ Here-Documents
@samp{ksh93g} (1998-04-30) but as of 2006 many operating systems were
still shipping older versions with the bug.
+Empty here-documents are not portable either: @command{zsh} 4.3.10 creates
+a file with a single newline upon, whereas other shells create an empty
+file, upon:
Two colons in a sentence seems odd to me, and the English doesn't parse
well either. How about:
Empty here-documents are not portable either; with the following code,
@command{zsh} 4.3.10 creates a file with a single newline, whereas other
shells create an empty file:
Also, is it really just that one micro release of zsh that has this
problem? Or do you mean since 4.3.10 or maybe before 4.3.10 or
even at least 4.3.10?
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
Re: [PATCH 2/5] docs: mention cost of globbing during variable expansion
Hi Eric,
On 26 Aug 2010, at 20:45, Eric Blake wrote:
Not true, if $TMPDIR already has a value that contains globbing characters
(of course, the likelihood of this is slim, but the whole point of ${a=b} is
that you are assigning a value to $a _if_ it doesn't already have one, which
implies that you are also admitting that $a may already have an unspecified
value inherited from the user - and we know that it is never a good idea to
blindly trust user input to be sane.
Ah-hah! The penny has dropped... now I see why the outer quotes are worthwhile.
Thanks for the explanation.
If you didn't do it already (I didn't go over the follow-up patches as
carefully, so I might have missed it), I think some version of the above added
to the Autoconf manual would make it easier for others to understand what the
difference is, and internalise the advantages of using outer quotes when
possible.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
Re: [PATCH 2/5] docs: mention cost of globbing during variable expansion
' for more information])
AC_MSG_WARN([you should use --build, --host, --target])
expr x$ac_option : [.*[^-._$as_cr_alnum]] /dev/null
AC_MSG_WARN([invalid host type: $ac_option])
-: ${build_alias=$ac_option} ${host_alias=$ac_option}
${target_alias=$ac_option}
+: ${build_alias=$ac_option} ${host_alias=$ac_option}
${target_alias=$ac_option}
;;
Agreed - although I prefer the look of:
: ${build_alias=$ac_option} ${host_alias=$ac_option}
${target_alias=$ac_option}
But that's just a stylistic issue, unless one form avoids a shell bug somewhere?
[[snip many more examples of the same]]
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
Re: porting with autotools
On 26 Aug 2010, at 09:25, Reuben Hawkins wrote:
I was
thinking output a Makefile.am in each dir which has source in this
format...
noist_LTLIBRARIES = libdir_name.la
libdir_name_la_SOURCES = source files in this directory
func_output ()
{
dirname=`echo $1 | sed 's,^.*/,,g'`
sources=*.c
cat Makefile.am EOF
noinst_LTLIBRARIES=lib$dirname.la
lib${dirname}_la_SOURCES = $sources
EOF
}
find . -type d -exec func_output {} \;
Any thoughts would be appreciated.
Don't know whether it's sensible without more context, but the code
above is probably close to what you asked for :)
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_TRY_EVAL
Hallo Ralf, On 7 Aug 2010, at 15:20, Ralf Wildenhues wrote:] AC_TRY_EVAL is undocumented, but I don't see equivalent functionality that Automake (and Libtool) can use to try and log test commands. So, I guess I'm asking to either let this not die, or provide a similar but safer new API instead. Or both, for bugward compatibility. I just ran a grep for all occurrences of AC_TRY_EVAL outside of aclocal.m4, and the only places it cropped up - among the (almost 5000) package sources we maintain at work - is in libtool.m4. I think we can safely drop AC_TRY_EVAL without too much ceremony, although we'll need something (better!) for Automake and Libtool to use instead, as you say. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: How to correctly generate 'foobar.h' from 'foobar.h.in'
On Aug 7, 2010, at 10:31 AM, Mike Frysinger vap...@gentoo.org wrote:
On Friday, August 06, 2010 20:19:41 Tao Wang wrote:
Thank you. It works for my C/C++ files.
However, how it works on text file and script file? They don't have
compiler to pass the define from parameters. For most scripts, they don't
accept bash syntax ${prefix}, they do need the value of
${prefix}/share. How can I do that?
typically people dont expand things in such files
Or you can add a rule to Makefile.am (or Makefile if you're not using Automake)
that performs the substitution with a shell snippet that calls sed - that way
${prefix} is expanded by the shell before passing it to sed.
Have a look at how GNU M4 creates its bootstrap script for an example.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: The problem with pgk-config
[RESEND - apologies if you see this twice... no echo from the list after 10 hours or so] On 1 Aug 2010, at 04:31, Bob Friesenhahn wrote: On Sat, 31 Jul 2010, Ralf Wildenhues wrote: I'd rather avoid (3), and I know (2) is going to be quite some work, but should be done. What things go wrong with pkg-config? (Please adjust the Subject: when replying to this, thanks!) The main problem I find with pgk-config is that it has nothing to do with the libraries the linker actually finds. Instead it is producing an incantation based on some other paths (PATH and PKG_CONFIG_PATH). This is particularly a problem on a stable system like Solaris 10 where one wants to use some system-provided libraries, yet use more modern libraries from a different path. This may result in two pkg-config directories which contain non-dependent libraries from different vintages. The result is that the wrong libraries may be used. Libtool works at a lower level (more similar to the linker) so that it knows the actual libraries which were used. Regardless, pkg-config only proposes configuration information while autoconf tests to make sure that it really works. Agree with all of the above. pkg-config is especially onerous when one wants to maintain a separate GNU Stow like arrangement of open source packages maintained separately to the vendor tools -- where each package gets it's own installation directory to make concurrent installation of multiple package versions, and upgrading of individual packages as easy as possible. In this case, when linking a utility that has a moderately deep deplib stack and which wants to use pkg-config, you have to either build a staging directory with links to each of the .pc files, or else construct a bespoke unreasonably long PKG_CONFIG_PATH setting per-package. In itself, not so bad, except that (unlike libtool or an ELF-like linker), pkg-config forces you to manually unwind the entire deplib stack before it will work to ensure that you didn't forget any indirect deplib that is not even used by the utility at the top of the stack that you are trying to link. For example, with each package is installed to /opt/fsw/package-version, the PKG_CONFIG_PATH for monodevelop turns out to be: PKG_CONFIG_PATH=/opt/fsw/boo-0.7.6/lib/pkgconfig:\ /opt/fsw/fcpackage-0.22/lib/pkgconfig:\ /opt/fsw/gecko-sharp-2.0-0.12/lib/pkgconfig:\ /opt/fsw/gettext-0.17/lib/pkgconfig\ /opt/fsw/gnome-2.22/lib/pkgconfig:\ /opt/fsw/gtk-sharp-2.0-2.4.3/lib/pkgconfig:\ /opt/fsw/gtksourceview-sharp-2.0-0.11/lib/pkgconfig:\ /opt/fsw/libart_lgpl-2.3.16/lib/pkgconfig:\ /opt/fsw/libatk-1.9.1/lib/pkgconfig:\ /opt/fsw/libglade-2.5.1/lib/pkgconfig:\ /opt/fsw/libglib--2.6.5/lib/pkgconfig:\ /opt/fsw/libgtk+-2.6.5/lib/pkgconfig:\ /opt/fsw/libpango-1.8.2/lib/pkgconfig:\ /opt/fsw/libttf-2.1.9/lib/pkgconfig:\ /opt/fsw/libxml2-2.6.22/lib/pkgconfig:\ /opt/fsw/mono-1.2.4/lib/pkgconfig:\ /opt/fsw/libz-1.2.3/lib/pkgconfig:\ /opt/fsw/monodebugger-0.50/lib/pkgconfig}:\ /opt/fsw/libiconv-0.12/lib/pkgconfig Luckily, we installed all the GNOME packages under gnome-2.22, otherwise there would have been another dozen entries to take into account in addition to these, and even more luckily only GNOME related packages seem to have adopted pkg-config, otherwise there would also have been another dozen entries for the other libraries (jpeg, tiff, etc) that the linker knows I used when building libgtk+ but for which there is no .pc file depended on by libgtk+-2.0.pc. Also, don't forget that this isn't only an annoyance for the packages at the top of the stack, but also has to be addressed over and over again for every pkg-config using library all the way down the stack as those libraries are built and installed. Not to mention that the package maintenance process now includes a mostly unnecessary (but for pkg-config) step of keeping track of PKG_CONFIG_PATHs incase we want to relink something later. I'm still somewhat disgruntled that all of the effort that was spent on pkg-config (not to mention the pain one has to endure when using it!) wasn't spent on a patch for libtool to store and extract the flags that pkg-config wants to manage. There's a huge overlap already, and libtool is already 80% of the way to providing the functionality of pkg-config, as well as having all the infrastructure in place already to avoid at least the problem I outline above. The one fly in the ointment is that a significant selection of libtool users seem to find life more convenient when they delete all installed .la files, which would make folding in pkg-config like functionality impossible. I confess that I haven't really tried to understand why that is, since I always leave the .la files in place, and they have never given me any problems personally. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org
Re: The problem with pgk-config
On 1 Aug 2010, at 04:31, Bob Friesenhahn wrote: On Sat, 31 Jul 2010, Ralf Wildenhues wrote: I'd rather avoid (3), and I know (2) is going to be quite some work, but should be done. What things go wrong with pkg-config? (Please adjust the Subject: when replying to this, thanks!) The main problem I find with pgk-config is that it has nothing to do with the libraries the linker actually finds. Instead it is producing an incantation based on some other paths (PATH and PKG_CONFIG_PATH). This is particularly a problem on a stable system like Solaris 10 where one wants to use some system-provided libraries, yet use more modern libraries from a different path. This may result in two pkg-config directories which contain non-dependent libraries from different vintages. The result is that the wrong libraries may be used. Libtool works at a lower level (more similar to the linker) so that it knows the actual libraries which were used. Regardless, pkg-config only proposes configuration information while autoconf tests to make sure that it really works. Agree with all of the above. pkg-config is especially onerous when one wants to maintain a separate GNU Stow like arrangement of open source packages maintained separately to the vendor tools -- where each package gets it's own installation directory to make concurrent installation of multiple package versions, and upgrading of individual packages as easy as possible. In this case, when linking a utility that has a moderately deep deplib stack and which wants to use pkg-config, you have to either build a staging directory with links to each of the .pc files, or else construct a bespoke unreasonably long PKG_CONFIG_PATH setting per-package. In itself, not so bad, except that (unlike libtool or an ELF-like linker), pkg-config forces you to manually unwind the entire deplib stack before it will work to ensure that you didn't forget any indirect deplib that is not even used by the utility at the top of the stack that you are trying to link. For example, with each package is installed to /opt/fsw/package-version, the PKG_CONFIG_PATH for monodevelop turns out to be: PKG_CONFIG_PATH=/opt/fsw/boo-0.7.6/lib/pkgconfig:\ /opt/fsw/fcpackage-0.22/lib/pkgconfig:\ /opt/fsw/gecko-sharp-2.0-0.12/lib/pkgconfig:\ /opt/fsw/gettext-0.17/lib/pkgconfig\ /opt/fsw/gnome-2.22/lib/pkgconfig:\ /opt/fsw/gtk-sharp-2.0-2.4.3/lib/pkgconfig:\ /opt/fsw/gtksourceview-sharp-2.0-0.11/lib/pkgconfig:\ /opt/fsw/libart_lgpl-2.3.16/lib/pkgconfig:\ /opt/fsw/libatk-1.9.1/lib/pkgconfig:\ /opt/fsw/libglade-2.5.1/lib/pkgconfig:\ /opt/fsw/libglib--2.6.5/lib/pkgconfig:\ /opt/fsw/libgtk+-2.6.5/lib/pkgconfig:\ /opt/fsw/libpango-1.8.2/lib/pkgconfig:\ /opt/fsw/libttf-2.1.9/lib/pkgconfig:\ /opt/fsw/libxml2-2.6.22/lib/pkgconfig:\ /opt/fsw/mono-1.2.4/lib/pkgconfig:\ /opt/fsw/libz-1.2.3/lib/pkgconfig:\ /opt/fsw/monodebugger-0.50/lib/pkgconfig}:\ /opt/fsw/libiconv-0.12/lib/pkgconfig Luckily, we installed all the GNOME packages under gnome-2.22, otherwise there would have been another dozen entries to take into account in addition to these, and even more luckily only GNOME related packages seem to have adopted pkg-config, otherwise there would also have been another dozen entries for the other libraries (jpeg, tiff, etc) that the linker knows I used when building libgtk+ but for which there is no .pc file depended on by libgtk+-2.0.pc. Also, don't forget that this isn't only an annoyance for the packages at the top of the stack, but also has to be addressed over and over again for every pkg-config using library all the way down the stack as those libraries are built and installed. Not to mention that the package maintenance process now includes a mostly unnecessary (but for pkg-config) step of keeping track of PKG_CONFIG_PATHs incase we want to relink something later. I'm still somewhat disgruntled that all of the effort that was spent on pkg-config (not to mention the pain one has to endure when using it!) wasn't spent on a patch for libtool to store and extract the flags that pkg-config wants to manage. There's a huge overlap already, and libtool is already 80% of the way to providing the functionality of pkg-config, as well as having all the infrastructure in place already to avoid at least the problem I outline above. The one fly in the ointment is that a significant selection of libtool users seem to find life more convenient when they delete all installed .la files, which would make folding in pkg-config like functionality impossible. I confess that I haven't really tried to understand why that is, since I always leave the .la files in place, and they have never given me any problems personally. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Document, test, and fix AT_ARG_OPTION, AT_ARG_OPTION_ARG.
Hi Eric, Ralf, On 18 Jun 2010, at 03:00, Eric Blake wrote: On 06/15/2010 11:09 PM, Ralf Wildenhues wrote: Undocumented good features are a waste of goodness! :-) I'm not sure in which way this code may overlap, conflict, or profit from, Gary's option parsing endeavor, but a code search showed me that the macros are used in third-party code already, so might as well get these right. Sorry if there is duplication, this came from 2003. I think the only thing we should be mindful of when the time comes to move getopt.m4sh into Autoconf is that the GNUish semantics I have supported are not subtly different from the GNUish semantics of the existing macros. Perhaps we can ease the transition by renaming or wrapping up parts of getopt.m4sh in the existing macro names. And ultimately, I'd like to see this moved to the M4sh level (then both autoconf and autotest get it for free). But that will be post-2.66. Agreed. I'm not planning on worrying too much about how to merge things after 2.66, since getopt.m4sh is still cooking in Libtool for the moment... Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: Defining dependencies in Automake
[please delete autoconf@gnu.org from Cc: if you reply] This is really an automake question, so you posted to the wrong list! On 22 Jun 2010, at 22:32, Sam Silla wrote: Greetings, I have a Makefile.am file right now that looks like this: lib_LIBRARIES = foo.a foo_a_SOURCES = bar.F90 baz.F90 However, bar.F90 depends on several other Fortran files (x.F90, y.F90, z.F90). I would like to set up Automake to rebuild bar.o if the source of one of these dependencies change. I've been reading the GNU manuals for automake/autoconf and was unable to find an applicable solution to this. Thanks for reading. Remember that Makefile.am is just a Makefile, and that automake copies any rules you add to Makefile.am into Makefile. If bar.F90 somehow includes the contents of the other source files: EXTRA_SOURCES = x.F90 y.F90 z.F90 bar.o: bar.F90 x.F90 y.F90 z.F90 Or if bar.o is made from partially linked objects (I'm not a fortran programmer, so I don't know how the fortran compiler links): bar.o: x.o y.o z.o If you have several dependencies in the form of either of the above, you also might want to look into storing the dependencies in make variables. HTH, -- Gary V. Vaughan (g...@gnu.org) ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Comment on introduction pages
Hi Chris, On 3 Jun 2010, at 21:01, Christina Gratorp wrote: I found a bug in the intro pages for automake: http://sources.redhat.com/automake/automake.html#Introduction. The sentence The developer expresses the recipe to build *his* package in a Makefile must be wrong since I'm a woman and a user and have packages I want to build and those packages are mine, i.e *hers* would be correct in this case. Suggestion: change the sentence to The developer expresses the recipe to build *his/hers* package in a Makefile or The developer expresses the recipe to build *the* package in a Makefile But then it would be wrong for an even larger percentage of automake users, almost none of which are hermaphrodites. At least with male pronouns we're exactly right 90% of the time or so. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: AC_BEFORE does not warn when it should
Hi Bruno, On 1 Jun 2010, at 17:04, Bruno Haible wrote: If so, then you have the arguments reversed in the second case. Oh, I added the AC_BEFORE invocation in the second place only after I got no warning from the AC_BEFORE invocation in the first place. Ah, okay. I had wondered why your example didn't reflect the contents of gnulib in git master... The idiom I always use to avoid confusing the argument order is this: AC_BEFORE([$0], [warn-if-this-macro-name-was-already-called]) This is what I started with: A definition of gl_LIBUNISTRING that starts with AC_BEFORE([$0], [gl_LIBUNISTRING_LIB_PREPARE]) # XXX gl_LIBUNISTRING starts here and a definition of gl_LIBUNISTRING_LIB_PREPARE that starts with # XXX gl_LIBUNISTRING_LIB_PREPARE starts here This produced the same effects: an output order that violates the constraint, and no warning from autoconf. Agreed. I can reproduce this with gnulib git master. Unfortunately, even with the generous commenting of m4_require in autoconf's m4sugar.m4, I can't figure out why it's happening :( IIRC Akim wrote the original implementation, and maybe has time to help... Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: Best practices for autotools
On 4 May 2010, at 08:59, Diego Saravia wrote: http://sourceware.org/autobook/ 2010/5/3 Matěj Týč matej@gmail.com: On Mon, 2010-05-03 at 19:38 +0200, Lukas Kaser wrote: since some weeks I'm working with autotools and I am wondering if some experienced users/developers wrote about best practices with this tools. CAVEAT EMPTOR: While it is certainly worth skimming through the autobook to get a feel for how the various programs interact and can be used together, the book will be 10 years old this year, and much has changed in that time that makes plenty of the details described in the book inaccurate, obsolete or just plain wrong. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: sed on binary files
Hi Eric, On 2 Oct 2008, at 10:51, Eric Blake wrote: Is there any portable way to process files that contain NUL bytes? None that I'm aware of. Many GNU utilities are reasonably well behaved with respect to '\0', and m4 is unusual to some extent in that we don't handle them well ourselves. I'm working on making m4 1.6 transparently handle NUL, Excellent! I made an attempt to do that myself on the 2.0 branch some years ago, but it didn't go well so I never committed... and want to post-process the output to normalize error messages while still verifying that NUL bytes appeared where expected on stderr. But on Solaris, the native sed strips NUL bytes before processing the line (NUL bytes cannot appear in text files, and POSIX does not define behavior on non-text files, so this is not a bug, just a difference from GNU diff). As a result, the m4 testsuite either fails (if I only postprocess the captured stderr and not the expected error) or can have false positives (if both stderr and expected error are normalized, then regressions involving added or missing NUL are not detected). I don't want to require perl for just this one test; m4 seems fundamental enough to keep the testsuite restricted to the GNU coding standards set of tools. I'd be inclined to do that in C. A few lines should be sufficient to write a minimal filter that writes '\' '0' or '^' '@' to output whenever a NUL byte arrives? The Solaris man pages mention that /usr/xpg4/bin/tr can handle NUL bytes, but not /usr/bin/tr; maybe I could search for an adequate tr, and change all NUL to some other byte that does not otherwise appear in my expected output (with the added benefit that diff might not give up early with the complaint that the files are binary), but I don't know if that is portable either. It's probably a safe bet that whatever vendor tool you rely on to postprocess will do the wrong thing on one machine or another :( Any suggestions? Is this worth documenting in the autoconf manual? Certainly, especially since many of the GNU tools *do* endeavour to handle '\0' input gracefully. Cheers, Gary -- Email me: [EMAIL PROTECTED](\(\ Read my blog: http://blog.azazil.net ( o.O) And my other blog: http://www.machaxor.net (uu )o ...and my book:http://sources.redhat.com/autobook ((_) ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: 1-gary-leopard-dSYM-removal.patch
On 18 Jan 2008, at 17:07, Gary V. Vaughan wrote:
Hi Paul,
On 18 Jan 2008, at 08:32, Paul Eggert wrote:
Gary V. Vaughan [EMAIL PROTECTED] writes:
+# Clean up potential compiler droppings:
+ac_files=a.out.* a.exe.* a_out.exe.* b.out.* conftest.*
+for ac_file in $ac_files; do
+ case $ac_file in
+_AC_COMPILER_OBJEXT_REJECT ) rm -rf $ac_file ;;
+ esac
+done
Sorry, I'm a bit lost. Shouldn't this be done inside the
AC_CACHE_CHECK?
Also, why not just do this?
rm -f a.out.* a.exe.* a_out.exe.* b.out.* conftest.*
This whole area seems to be a bit of a mess to me. Shouldn't all
these dropping files be removed unconditionally as part of the
existing rm -f -r conftest* confdefs* conf$[$]* $ac_clean_files
line?
I agree that droppings from all compilers should be deleted, though
I have
no clue where the cleanest place to achieve that would be.
The main gotcha is removing conftest.* during the tests from lang.m4
breaks
because the OBJEXT test wants to see conftest.c and/or conftest.
{o,obj} and
throws it's arms in the air and halts configure if they have been
removed. I
guess the EXEEXT test relies on them.
Since the macros are order sensitive, another way I thought of doing
it was
to find the sites that call:
m4_expand_once([_AC_COMPILER_EXEEXT])
m4_expand_once([_AC_COMPILER_OBJEXT])
And replace with a single:
m4_expand_once([_AC_COMPILER_CHECKS])
and add to lang.m4:
m4_define([_AC_COMPILER_CHECKS], [
_AC_COMPILER_EXEEXT
_AC_COMPILER_OBJEXT
_AC_COMPILER_CLEAN_DROPPINGS
])
where _AC_COMPILER_CLEAN_DROPPINGS contains the case statement of my
original
patch.
Ping?
Cheers,
Gary
--
())_. Email me: [EMAIL PROTECTED]
( '/ Read my blog: http://blog.azazil.net
/ )= ...and my book: http://sources.redhat.com/autobook
`(_~)_
PGP.sig
Description: This is a digitally signed message part
Autoreconf calling order order [WAS FYI: 333-gary-refactor-LTDL_INIT.patch]
Hi Eric, On 23 Jan 2008, at 22:00, Eric Blake wrote: The problem seems to stem from the fact that I had an older version of libltdl copied into my M4 tree, and autoreconf runs aclocal prior to libtoolize, so it was picking up the old definition of LTDL_INIT which conflicted with my new contents of configure.ac. I haven't picked through the logic inside autoreconf, but it seems completely wrong to me for it to run any tool that affects the contents of aclocal.m4 after aclocal itself (unless, perhaps, it reruns aclocal again later). From libtoolize.m4sh(func_scan_files): # Libtoolize affects the contents of aclocal.m4, and should be run before # aclocal, so we can't use configure --trace which relies on a consistent # configure.(ac|in) and aclocal.m4. I'm punting this one as an autoreconf bug. Cheers, Gary -- Gary V. Vaughan ([EMAIL PROTECTED]) PGP.sig Description: This is a digitally signed message part
Re: 1-gary-leopard-dSYM-removal.patch
On 18 Jan 2008, at 05:44, Ralf Wildenhues wrote: Hi Gary, Hallo Ralf, * Gary V. Vaughan wrote on Thu, Jan 17, 2008 at 08:16:46PM CET: I'm not convinced that this is the cleanest way to achieve this, but in any case the equivalent is needed in order for 'make distcheck' to pass with current libtool HEAD. Thanks for the report. The patch looks too broad. What about this one? I thought it better to remove all of the file droppings we check for in _AC_COMPILER_OBJEXT_REJECT, incase I move to an OS that drops one of the other files and try to run make distcheck for libtool... Note that it is actually an a.out.dSYM file that distcheck chokes on, so removing conftest.dSYM is no help :-( Also, see my other reply on this thread for more detail. diff --git a/lib/autoconf/lang.m4 b/lib/autoconf/lang.m4 index f17aa8c..567240e 100644 --- a/lib/autoconf/lang.m4 +++ b/lib/autoconf/lang.m4 @@ -630,7 +630,8 @@ AS_IF([_AC_DO_VAR(ac_compile)], done], [_AC_MSG_LOG_CONFTEST AC_MSG_FAILURE([cannot compute suffix of object files: cannot compile])]) -rm -f conftest.$ac_cv_objext conftest.$ac_ext]) +rm -f conftest.$ac_cv_objext conftest.$ac_ext +rm -rf conftest.dSYM]) AC_SUBST([OBJEXT], [$ac_cv_objext])dnl ac_objext=$OBJEXT ])# _AC_COMPILER_OBJEXT Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part
Re: 1-gary-leopard-dSYM-removal.patch
Hi Paul,
On 18 Jan 2008, at 08:32, Paul Eggert wrote:
Gary V. Vaughan [EMAIL PROTECTED] writes:
+# Clean up potential compiler droppings:
+ac_files=a.out.* a.exe.* a_out.exe.* b.out.* conftest.*
+for ac_file in $ac_files; do
+ case $ac_file in
+_AC_COMPILER_OBJEXT_REJECT ) rm -rf $ac_file ;;
+ esac
+done
Sorry, I'm a bit lost. Shouldn't this be done inside the
AC_CACHE_CHECK?
Also, why not just do this?
rm -f a.out.* a.exe.* a_out.exe.* b.out.* conftest.*
This whole area seems to be a bit of a mess to me. Shouldn't all
these dropping files be removed unconditionally as part of the
existing rm -f -r conftest* confdefs* conf$[$]* $ac_clean_files
line?
I agree that droppings from all compilers should be deleted, though I
have
no clue where the cleanest place to achieve that would be.
The main gotcha is removing conftest.* during the tests from lang.m4
breaks
because the OBJEXT test wants to see conftest.c and/or conftest.
{o,obj} and
throws it's arms in the air and halts configure if they have been
removed. I
guess the EXEEXT test relies on them.
Since the macros are order sensitive, another way I thought of doing
it was
to find the sites that call:
m4_expand_once([_AC_COMPILER_EXEEXT])
m4_expand_once([_AC_COMPILER_OBJEXT])
And replace with a single:
m4_expand_once([_AC_COMPILER_CHECKS])
and add to lang.m4:
m4_define([_AC_COMPILER_CHECKS], [
_AC_COMPILER_EXEEXT
_AC_COMPILER_OBJEXT
_AC_COMPILER_CLEAN_DROPPINGS
])
where _AC_COMPILER_CLEAN_DROPPINGS contains the case statement of my
original
patch.
Cheers,
Gary
--
())_. Email me: [EMAIL PROTECTED]
( '/ Read my blog: http://blog.azazil.net
/ )= ...and my book: http://sources.redhat.com/autobook
`(_~)_
PGP.sig
Description: This is a digitally signed message part
1-gary-leopard-dSYM-removal.patch
I'm not convinced that this is the cleanest way to achieve this, but in any case the equivalent is needed in order for 'make distcheck' to pass with current libtool HEAD. Please apply something similar. 2008-01-18 Gary V. Vaughan [EMAIL PROTECTED] * lib/autoconf/lang.m4 (_AC_COMPILER_OBJEXT): Be sure to remove compiler file droppings. For example, without this patche, it is impossible for 'make distcheck' to succeed with libtool HEAD on Mac OS 10.5 Cheers, Gary --- ChangeLog|0 lib/autoconf/lang.m4 |8 2 files changed, 8 insertions(+) Index: b/ChangeLog from Gary V. Vaughan [EMAIL PROTECTED] * lib/autoconf/lang.m4 (_AC_COMPILER_OBJEXT): Be sure to remove compiler file droppings. For example, without this patche, it is impossible for 'make distcheck' to succeed with libtool HEAD on Mac OS 10.5 Index: b/lib/autoconf/lang.m4 === --- a/lib/autoconf/lang.m4 +++ b/lib/autoconf/lang.m4 @@ -633,6 +633,14 @@ AC_MSG_FAILURE([cannot compute suffix of rm -f conftest.$ac_cv_objext conftest.$ac_ext]) AC_SUBST([OBJEXT], [$ac_cv_objext])dnl ac_objext=$OBJEXT + +# Clean up potential compiler droppings: +ac_files=a.out.* a.exe.* a_out.exe.* b.out.* conftest.* +for ac_file in $ac_files; do + case $ac_file in +_AC_COMPILER_OBJEXT_REJECT ) rm -rf $ac_file ;; + esac +done ])# _AC_COMPILER_OBJEXT -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part
Re: M4 syntax $11 vs. ${11}
Apologies for joining the conversation so late:
On 30 Jan 2007, at 07:23, Eric Blake wrote:
How about if M4 uses a slightly-different syntax, so that the two
uses
are never confused? That way, the conversion problem won't ever have
to be addressed, and Autoconf won't have to disable the extension
during a transition period.
So, for example, suppose M4 uses the syntax ${{11}} to refer to
argument 11? Or (if you prefer something shorter) ${+11}? An
advantage to this sort of approach is that it gives you more leeway
for future extensions.
You have a reasonable point there. My current plan was to add new
syntax
categories that could be controlled through the changesyntax builtin
(available in beta since at least 1.4o several years ago). So
using $1
instead of ${1} is easy - just use changesyntax([{], [}]) up
front in
m4sugar. On the other hand, supporting a multi-character delimiter
that
is still selectable by the m4 user is a bit tougher; I would need to
introduce a new macro similar to changequote and changecom (perhaps
changeextarg({{, }}) for choosing ${{1}} to mean an m4-parsed extended
argument, leaving ${1} for literal output).
The intention with m4-2.0 and beyond was to make the rescanning engine
become modular enough that it would be possible to select a
``language''.
For example we already have 3 such languages (albeit implemented outside
the current module system): traditional, gnu, and posix. Ultimately,
we should freeze core parsing issues to make an ``autoconf'' language,
which autoconf-3.0 could extend with modules it chose to ship. Also,
I'd like to have an m5 language (Prof Dain Samples extended m4), and
to split gnu into gnu-m4 (1.4.x syntax) and gnu-m42 (2.0 extensions).
Considering how little time I've had for gnu recently, I think it is
fine to push these ideas out past the 2.0 release, though the default
configuration of m4-2.0 (and beyond) should be fully compatible with
m4-1.4 -- any syntax improvements or extensions are the remit of
gnu-m42.
Cheers,
Gary
--
())_. Email me: [EMAIL PROTECTED]
( '/ Read my blog: http://blog.azazil.net
/ )= ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912
PGP.sig
Description: This is a digitally signed message part
Re: Aclocal bug?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hallo Stepan!
On 9 Nov 2006, at 08:59, Stepan Kasal wrote:
wow this is an interesting bug, I enjoyed analysing it!
And I enjoyed your analysis! Thankyou :-)
On Wed, Nov 08, 2006 at 11:49:31PM -0600, Gary V. Vaughan wrote:
On 8 Nov 2006, at 13:17, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Wed, Nov 08, 2006 at 06:34:45AM CET:
configure.ac:147: warning: AM_INTL_SUBDIR is m4_require'd but not
m4_defun'd
I tried to reproduce your bug, and I succeeded! Actually, it was
because I'm still using Fedora Core 4 and have m4 1.4.3.
As I haven't built CVS m4 yet, the only binary in my path is the
Apple
shipped m4-1.4.2 in /usr/bin.
The cause is the following bug:
$ echo ifdef(\`MAC', bug) |m4 --trace=MAC
bug
I observed it in 1.4.[34], while 1.4.5 seems to be fixed.
To build m4 HEAD, upgrade to m4 = 1.4.5 first and things will just
work!
Yes, that fixes it for me too. It's a shame that we have this ugly
bootstrap problem though... anyone who is interested in using CVS M4
on a machine that ships GNU M4 1.4.5 (e.g. Apple!) needs to first
install from a GNU M4 release tarball in order to be able to be able
to bootstrap the HEAD tree :-(
I think that Autoconf should require m4 = 1.4.5.
(Autoconf's confgiure should check for it; should it be done in
m4/m4.m4 in AM_PROG_GNU_M4, or in configure.ac?)
I agree. Both when building and installing the tools from source,
autoconf's configure should complain if the installed m4 is not new
enough; and also when bootstrapping Autoconf itself, a diagnostic for
too old a GNU M4 should given when necessary.
I've spent the last 12 hours in the saddle, so it'll be another 24
hours until the next entry :-)
Great. I wish you safe ride without any accident!
Thanks,
Gary
- --
Gary V. Vaughan ())_. [EMAIL PROTECTED]
Research Scientist ( '/ http://blog.azazil.net
GNU Hacker / )= http://www.gnu.org/software/{libtool,m4}
Technical Author `(_~)_ http://sources.redhat.com/autobook
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFFU2GWFRMICSmD1gYRAr+ZAJ9a4egMd/G5edAN+zkx2ApP2rsthQCdEQwm
N9B9M5GDHPadRSmyNplS3tM=
=gBup
-END PGP SIGNATURE-
Re: RFC: rename symbols to m4symbols
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Eric!
On 18 Sep 2006, at 14:09, Eric Blake wrote:
symbols is an English word, but was added to m4-1.4o as a macro that
takes 0 arguments (even worse, the 1.4o manual documented the new
macro,
but NEWS did not). This has the potential to break preprocessing of
English text that used to work with m4 1.4.x, when someone upgrades
and
makes no changes to their command line. I propose renaming the
macro to
m4symbols (and we should probably document a policy that any future
macro added in the gnu module that take 0 arguments either be in
the m4
or __ namespace, such as the __program__ macro added in m4 1.4.6).
m4sugar currently handles this case by mapping symbols to
m4_symbols,
consistent with the other remappings it handles, so a rename
visible in m4
2.0 would slightly impact autoconf; there are other macros that
m4sugar
still needs to pick up from CVS M4, such as changeresyntax.
Agreed. symbols has only been present in alpha releases thus far, so
I think changing it now rather than feeling the pain of having not
done it
later is the best course of action. Besides, one or two of the GNU M4
maintainers also have a commit bit for Autoconf ;-)
Also, is it worth putting the macros in the load module in a proper
namespace? modules, load, and unload are all English words,
but at
least with CVS m4, you have to explicitly request -m load at the
command
line to enable them.
I suppose that it makes sense to do that with the modules builtin by
virtue of your english words with 0 arguments rule above, but I see no
compelling reason to change load or unload when they are perfectly in
keeping with the style of many SUSv3 builtin names.
Cheers,
Gary.
- --
Gary V. Vaughan ())_. gary@
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]
Research Scientist ( '/ http://blog.azazil.net
GNU Hacker / )= http://www.gnu.org/software/{libtool,m4}
Technical Author `(_~)_ http://sources.redhat.com/autobook
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFFDynRFRMICSmD1gYRAnEGAKCk7o7d4U7EbBXaPFgwiXMPInSbnwCcCPC5
dBnkiBKs1puN4UakFX77m94=
=kNgX
-END PGP SIGNATURE-
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: libtool --ltdl vs. autoreconf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Eric, autotoolers: On Tue, 09 May 2006 06:04:23 -0600 Eric Blake [EMAIL PROTECTED] wrote: As promised here, http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html, I noticed that m4 bootstrap invokes libtoolize --ltdl prior to autoreconf, which reinvokes libtoolize without --ltdl. This seems like a bit of a waste of time, but when I tried removing the explicit libtoolize line, I got a bootstrap failure that a required file, ltmain.sh, was not found. I thought that using LT_CONFIG_LTDL_DIR in configure.ac would take care of everything that --ltdl used to do on the command line, but I was obviously mistaken. Is there another libtool macro that I need to use in configure.ac to ensure that all needed libtool files are installed at autoreconf time? Or should we enhance autoreconf to accept an --ltdl option to pass along to libtoolize? It would be nice if we could avoid an explicit libtoolize pass outside of autoreconf. I think the problem is simply that autoreconf doesn't yet understand the new macros introduced in Libtool HEAD. I'm afraid I've gotten so used to working around it with a manual libtoolize invocation that I had stopped seeing it as a bug. It is something that should be fixed before releasing Autoconf-2.60 though, or else Libtool-2.0 will need another Autoconf release for proper integration :-( Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEYI9GFRMICSmD1gYRAlaQAJ9tZ2ToDfbiNMeo6PkXYbe6cQ3QZQCdGr21 CcrJJG9bYYO8Osfx1VObBm8= =tbSG -END PGP SIGNATURE- ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Autotesting - GNU Autoconf
Ralf Wildenhues wrote: AT_DATA([experr], [[/import/eno/2/rnsr312/param-0.3/tests/syntaxerr:8.0: syntax error, unexpected TOKEN_ID_INT, expecting %% or int or intlist educt: Syntax error in file. ]]) AT_CHECK([educt --prettyprint /import/eno/2/rnsr312/param-0.3/tests/syntaxerr],[1],,experr, [echo Failed],[echo Passed]) For stuff like this you could AT_CHECK([educt --prettyprint $at_srcdir/syntaxerr], [1], [], [stderr], [echo Failed], [echo Passed]) AT_CHECK([grep 'syntaxerr:8.0: syntax error' stderr], [0], [ignore]) ... Consider also the case of trying to match strerror() or perror() output, which usually has different wording on different hosts... and libtool's argv[0] mangling with `lt-' prefixes... and search path setting to pick up uninstalled modules and/or configuration when run in the build tree... In order that the suite ports easily to 'make check' and 'make installcheck', the best way to handle such things maintainably is to use a wrapper script for the binaries that are being tested. The scripts job is then to canonicalise any of these cases that you care about. As an example CVS M4 has such a script in test/m4. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: proposed gnulib-related additions to Autoconf
Hi Paul,
Nice work! Yes, I agree that reparenting these macros into Autoconf
is an excellent idea. As you are soliciting feedback...
Paul Eggert wrote:
+** AC_CHECK_DECLS_ONCE, AC_CHECK_FUNCS_ONCE, AC_CHECK_HEADERS_ONCE
+ New once-only variants of commonly-used macros, to make 'configure'
+ smaller and faster in common cases.
I think that putting these in Autoconf pollutes the AC_ namespace with
entries that will need to be supported in all future autoconf releases.
Two issues seem pertinent:
i) Let's just improve AC_CHECK_HEADERS (et al) to always make configure
smaller and faster by despatching to (undocumented internal)
_AC_CHECK_HEADERS_ONCE when it can.
ii) I would have thought that use of shell functions in generated
configure scripts is safe enough by now that it should be feasible
to shrink configure considerably by factoring common shell code
(say, the body of AC_CHECK_HEADERS) into functions, and having the
macros expand into appropriate calls to those functions. Certainly,
the next release of libtool uses shell functions extensively, and
if it doesn't generate a backlash, it seems sensible for Autoconf
to follow suit.
@uref{http://www.gnu.org/software/autoconf/, Autoconf},
[EMAIL PROTECTED]://www.gnu.org/software/automake/, Automake}, and
[EMAIL PROTECTED]://www.gnu.org/software/automake/, Automake},
[EMAIL PROTECTED]://www.gnu.org/software/automake/, Gnulib}, and
@uref{http://www.gnu.org/software/libtool/, Libtool}.
The uref for Gnulib is wrong.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
Re: proposed gnulib-related additions to Autoconf
Hi Paul, Paul Eggert wrote: Gary V. Vaughan [EMAIL PROTECTED] writes: i) Let's just improve AC_CHECK_HEADERS (et al) to always make configure smaller and faster by despatching to (undocumented internal) _AC_CHECK_HEADERS_ONCE when it can. Won't that break old scripts? If they do something like this: if test $ac_feature_foo = yes; then AC_CHECK_HEADERS([sys/param.h]) fi then we'd hoist the test for sys/param.h out of the then-part, which is not what was intended. Hmm. You're right :-( I was thinking that there might be a way to detect from the argument signature of the call which flavour the user wanted; but, looking at the implementation, the only way to do that would be either an optional fifth argument (ugly), or perhaps if the first argument does not end in `.h'. The latter is really a motter of picking between: AC_CHECK_HEADER_ONCE([sys/param.h]) and, for example: AC_CHECK_HEADER([1], [sys/param.h]) On balance, the former is clearer. Pity, as it adds just adds another function that has to be supported in later releases :-( ii) I would have thought that use of shell functions in generated configure scripts is safe enough by now That's the direction I'd like to head too, but it's a big enough change that it will cause problems. Let's wait until after 2.60 comes out. Excellent. Yes, I think it is more important to get a release soon so that the huge improvements since 2.59 can begin to make their way to developers that don't want to risk a CVS snapshot. It might make sense to have an Autoconf 3 that has a lot of changes along these lines (I'd like to assume at least C89 and POSIX-2.1992 conformance, for example; sheesh, it's 2006 already!), and reserve Autoconf 2 for the current basic approach. That sounds like the best way forward to me! Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: No release for 2 years?
Ralf Wildenhues wrote: I hold the necessity of m4-2.0 for autoconf-2.60 to be a myth. Is that correct? If not, why? Yes that's correct. The searchpath manipulation primitives of m4-2.0 are required to do away with aclocal, which was (when m4-2.0 seemed much closer!) something that I think Akim wanted in the next release of autoconf. I don't know of any reason why we couldn't put out an alpha of autoconf right now. Then after a whole lot of platform testing, fixing any bugs that fall out, a 2.60 release seems perfectly feasible. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bug in latest install-sh
Hallo Stepan!
Forgive the nit...
Stepan Kasal wrote:
2005-11-01 Stepan Kasal [EMAIL PROTECTED]
* doc/autoconf.texi (Limitations of Builtins): Document that
trap - SIG is not yet portable.
[[snip]]
+But even though Posix defines that the trap can be unset by
[EMAIL PROTECTED] - SIG}, the feature is not widely supported yet.
+But it si safe to use @samp{trap '' SIG} to ignore the signal; in particular,
^^
s/si/is/
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
Re: Fix LT_WITH_LTDL: AU_ALIAS bug
Hallo Ralf, Ralf Wildenhues wrote: Hunting down bugs in m4 macros sucks. Using $# in macros sucks, too. :-( Can you document in HACKING that because of our use of AU_ALIAS to maintain backwards compatibility with earlier libtool interfaces we must not use $# in m4. Also, we could do with an m4.test to catch violations of our m4 style guidelines -- much as we have sh.test to catch shell style violations. Can you add a TODO item for that too please? First: LT_WITH_LTDL needs to be documented correctly. Its predecessor AC_WITH_LTDL needed documentation as well. I accept patches. :) I've been working on this for almost 2 weeks now. The whole thing is almost hopelessly broken. Now that I've started using quilt I'll start posting the patches in small bits as soon as I have the damn thing working. Anyway, I consider testing against $# error-prone, and bad for forward compatibility anyway (when the possible number of arguments could be greater than one), ACK. so I would like to apply this patch, which uses m4_default instead. OK for HEAD? Okay. * libltdl/m4/ltdl.m4 (LT_WITH_LTDL, LTDL_CONVENIENCE) (LTDL_INSTALLABLE): Use m4_default instead of m4_if, to cope with empty macro arguments. Use less quoting for expanded LIBLTDL, LTDLINCL Cheers, Gary -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: [gettext] changequote considered harmful
Hi Bruno, Stepan,
Bruno Haible wrote:
The desirable way to mix C or sh syntax and a macro language - for me as
someone who has to maintain some of these macros - is so that
1) A valid C or sh snippet without specific macro invocations is
valid inside the macro, and does not change its meaning.
Brackets count as normal C or sh syntax here, since they are frequent
in C and sh.
2) There is a way to insert macro invocation in C or sh snippets,
either directly by writingMACRONAME(ARGS) or with some similar
syntax.
3) There is normally no need to switch into a TeX {verbatim} or XML CDATA
section, because 1) is usually enough.
[[snip]]
The style that fulfills goals 1 and 2 here is like this:
[...
# Found it, now check the version.
]AC_MSG_CHECKING([version of bison])[
ac_prog_version=`$INTLBISON --version 21 | sed -n 's/^.*GNU Bison.*
\([0-9]*\.[0-9.]*\).*$/\1/p'`
case $ac_prog_version in
'') ac_prog_version=v. ?.??, bad; ac_verc_fail=yes;;
1.2[6-9]* | 1.[3-9][0-9]* | [2-9].*)
ac_prog_version=$ac_prog_version, ok; ac_verc_fail=no;;
*) ac_prog_version=$ac_prog_version, bad; ac_verc_fail=yes;;
esac
]AC_MSG_RESULT([$ac_prog_version])[
...]
I.e. put braces around everything, but unbrace the macro invocations and
don't put dnl comments. Unfortunately as long as autoconf does not recommend
this style, other people will not like this style; therefore I cannot really
use this style yet.
In the bad old days, before I understood this idiom, I used to write
(and libtool still contains code in this style :-():
# Found it, now check the version.
AC_MSG_CHECKING([version of bison])
ac_prog_version=`$INTLBISON --version 21 | sed -n 's/^.*GNU
Bison.* \([[0-9]]*\.[[0-9.]]*\).*$/\1/p'`
case $ac_prog_version in
'') ac_prog_version=v. ?.??, bad; ac_verc_fail=yes;;
1.2[[6-9]]* | 1.[[3-9]][[0-9]]* | [[2-9]].*)
ac_prog_version=$ac_prog_version, ok; ac_verc_fail=no;;
*) ac_prog_version=$ac_prog_version, bad; ac_verc_fail=yes;;
esac
AC_MSG_RESULT([$ac_prog_version])
which, as you point out is ugly and error prone. More recently I have
been writing code as you describe above, and life is much better.
Whether the style is widely accepted or understood yet is not an issue
IMNSHO, it is *correct*... and that is far more important. It will
become acceptable style as more projects adopt it when they realise it
is the technically correct thing to do!
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: [PATCH] Support AC_CONFIG_LIBOBJ_DIR (fixes PR/401)
Salut Alexandre,
Thanks for the feedback:
Alexandre Duret-Lutz wrote:
* LIBOBJDIR seems worthy to document from the Autoconf user perspective.
Non-automake might also benefit from this; and we should avoid using
undocumented interfaces in Automake.
Okay, I've added that to the attached revision of this patch.
* The comment in _AC_LIBOBJS_NORMALIZE seems misleading to me,
because LIBOBJDIR is unrelated to the macro
AC_CONFIG_LIBOBJ_DIR as far as Autoconf is concerned.
AC_CONFIG_LIBOBJ_DIR specifies where the *sources* files are.
LIBOBJDIR is a prefix variable the user cano use to relocate
the *object* files. This is not necessary the same place.
True enough also. I've changed the comments to describe the situation more
accurately.
* Autoconf needs to be adjusted to reflect the fact that
Automake scans a new macro. See the comment above the %traced
variable you modified in scan_autoconf_trace.
AC_CONFIG_LIBOBJ_DIR is already there in autoconf-2.59 and HEAD.
* Better write ${LIBOBJDIR} instead of $(LIBOBJDIR) in @LIBOBJS@
(for the same reason we use ${prefix}, etc.)
I disagree, LIBOBJDIR is a make macro not a shell variable, so it is more akin
to $(srcdir) than ${prefix}. If I'm missing something, feel free to change it
before committing.
* The Automake manual should be updated at least in two places:
- the place where it documents all the macros that can
affect its behavior (your patch causes
AC_CONFIG_LIBOBJ_DIR to have a stronger semantic when used
with Automake than when used with only Autoconf).
- the section about how LIBOBJS is used.
* Use $PERL, not perl.
Both done. Thanks for the pointers.
* AFAICT your patch assumes that users use option `subdir-objects' when
using @LIBOBJS@ remotely. I think we should also support the other case.
I suggest you don't bother with the last point unless it looks
easy to you. I'll probably find some time this week-end or next
week.
Agreed on all counts. My perl-fu is as always insufficient to the task,
thanks for offering to do the rest.
ChangeLog entries for automake:
2005-04-25 Gary V. Vaughan [EMAIL PROTECTED]
Fixes PR/401
* automake.in (config_libobj_dir): Either `.' or whatever directory is
given to AC_CONFIG_LIBOBJ_DIR in configure.ac.
(scan_autoconf_traces): Set config_libobj_dir.
(sub_read_am_file): Define LIBOBJDIR according to relative path from
each Makefile to AC_CONFIG_LIBOBJ_DIR directory.
(require_libobj_with_macro): Use $config_libobj_dir when looking for
LIBOBJs.
(handle_LIBOBJS, handle_ALLOCA): Use it.
* tests/Makefile.am (TESTS): Declare pr401.test.
* tests/pr401.test: New test.
* doc/automake.texi (LIBOBJS): Document changes in behaviour of
LIBOBJS, ALLOCA, LTLIBOBJS LTALLOCA in the presence of
subdir-objects and an invocation of AC_CONFIG_LIBOBJ_DIR.
And autoconf:
2004-04-20 Gary V. Vaughan [EMAIL PROTECTED]
* lib/autoconf/general.m4 (_AC_LIBOBJS_NORMALIZE): Prepend each object
named in LIBOBJS and LTLIBOBJS with the $(LIBOBJDIR), as set by latest
automake.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
--- automake.in.orig 2005-02-12 10:06:56.0 +
+++ automake.in 2005-04-20 14:08:05.0 +0100
@@ -142,6 +142,7 @@
use Automake::RuleDef;
use Automake::Wrap 'makefile_wrap';
use File::Basename;
+use File::Spec;
use Carp;
## --- ##
@@ -333,6 +334,10 @@
# in Makefiles.
my $am_config_aux_dir = '';
+# Directory to search for AC_LIBSOURCE file, as set by AC_CONFIG_LIBOBJ_DIR
+# in configure.ac.
+my $config_libobj_dir = '';
+
# Whether AM_GNU_GETTEXT has been seen in configure.ac.
my $seen_gettext = 0;
# Whether AM_GNU_GETTEXT([external]) is used.
@@ -2067,7 +2072,7 @@
if ($iter =~ /\.h$/)
{
- require_file_with_macro ($cond, $var, FOREIGN, $iter);
+ require_libobj_with_macro ($cond, $var, FOREIGN, $iter);
}
elsif ($iter ne 'alloca.c')
{
@@ -2079,7 +2084,7 @@
my $bs = var ('BUILT_SOURCES');
if (! $bs || ! grep (/$rewrite/, $bs-value_as_list_recursive))
{
- require_file_with_macro ($cond, $var, FOREIGN, $iter);
+ require_libobj_with_macro ($cond, $var, FOREIGN, $iter);
}
}
}
@@ -2092,7 +2097,7 @@
$lt ||= '';
$var-requires_variables ([EMAIL PROTECTED]@ used, $lt . 'ALLOCA');
$dep_files{'$(DEPDIR)/alloca.P' . $myobjext} = 1;
- require_file_with_macro ($cond, $var, FOREIGN, 'alloca.c');
+ require_libobj_with_macro ($cond, $var, FOREIGN, 'alloca.c');
saw_extension ('c');
}
@@ -4636,6 +4641,7 @@
AC_CONFIG_AUX_DIR = 1,
AC_CONFIG_FILES = 1,
AC_CONFIG_HEADERS = 1,
+ AC_CONFIG_LIBOBJ_DIR
Re: [PATCH] Support AC_CONFIG_LIBOBJ_DIR
Hallo again,
It turns out that the automake patch is not enough :-(
Attached is an improved patch against automake-1.9.5 (applies to branch-1-9
and HEAD with fuzz). When applied, if configure.ac declares
AC_CONFIG_LIBOBJ_DIR, then automake will look in that directory for
AC_LIBSOURCE declared files. This allows us to have a single toplevel
Makefile.am, that builds a library in a subdirectory that contains
AC_LIBSOURCE source files. Without the patch, automake ignores the
AC_CONFIG_LIBOBJ_DIR, and complains that AC_LIBSOURCEs cannot be found in the
top level project directory.
2005-04-18 Gary V. Vaughan [EMAIL PROTECTED]
* automake.in (config_libobj_dir): Either `.' or whatever directory is
given to AC_CONFIG_LIBOBJ_DIR in configure.ac.
(scan_autoconf_traces): Set config_libobj_dir.
(require_libobj_with_macro): Use $config_libobj_dir when looking for
LIBOBJs.
(handle_LIBOBJS, handle_ALLOCA): Use it.
Also attached is a complementary patch against autoconf-2.59 (porting to HEAD
is trivial) which changes _AC_LIBOBJS_NORMALIZE to prepend the
AC_CONFIG_LIBOBJ_DIR subdirectory to each object named in LIBOBJS and
LTLIBOBJS, so that the substitutions into a toplevel Makefile set up as
described above will build and link the libobjs correctly.
2004-04-18 Gary V. Vaughan [EMAIL PROTECTED]
* lib/autoconf/general.m4 (_AC_LIBOBJS_NORMALIZE): Prepend each object
named in LIBOBJS and LTLIBOBJS with the subdirectory declared by
AC_CONFIG_LIBOBJ_DIR if any.
I can apply the autoconf patch if approved, but I have no write access to
automake CVS...
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
--- automake.in.orig 2005-02-12 10:06:56.0 +
+++ automake.in 2005-04-18 17:47:45.0 +0100
@@ -333,6 +333,10 @@
# in Makefiles.
my $am_config_aux_dir = '';
+# Directory to search for AC_LIBSOURCE file, as set by AC_CONFIG_LIBOBJ_DIR
+# in configure.ac.
+my $config_libobj_dir = '';
+
# Whether AM_GNU_GETTEXT has been seen in configure.ac.
my $seen_gettext = 0;
# Whether AM_GNU_GETTEXT([external]) is used.
@@ -2067,7 +2071,7 @@
if ($iter =~ /\.h$/)
{
- require_file_with_macro ($cond, $var, FOREIGN, $iter);
+ require_libobj_with_macro ($cond, $var, FOREIGN, $iter);
}
elsif ($iter ne 'alloca.c')
{
@@ -2079,7 +2083,7 @@
my $bs = var ('BUILT_SOURCES');
if (! $bs || ! grep (/$rewrite/, $bs-value_as_list_recursive))
{
- require_file_with_macro ($cond, $var, FOREIGN, $iter);
+ require_libobj_with_macro ($cond, $var, FOREIGN, $iter);
}
}
}
@@ -2092,7 +2096,7 @@
$lt ||= '';
$var-requires_variables ([EMAIL PROTECTED]@ used, $lt . 'ALLOCA');
$dep_files{'$(DEPDIR)/alloca.P' . $myobjext} = 1;
- require_file_with_macro ($cond, $var, FOREIGN, 'alloca.c');
+ require_libobj_with_macro ($cond, $var, FOREIGN, 'alloca.c');
saw_extension ('c');
}
@@ -4636,6 +4640,7 @@
AC_CONFIG_AUX_DIR = 1,
AC_CONFIG_FILES = 1,
AC_CONFIG_HEADERS = 1,
+ AC_CONFIG_LIBOBJ_DIR = 1,
AC_CONFIG_LINKS = 1,
AC_INIT = 0,
AC_LIBSOURCE = 1,
@@ -4731,6 +4736,11 @@
push @config_headers, $spec;
}
}
+ elsif ($macro eq 'AC_CONFIG_LIBOBJ_DIR')
+ {
+ $config_libobj_dir = $args[1];
+ check_directory ($config_libobj_dir, $where);
+ }
elsif ($macro eq 'AC_CONFIG_LINKS')
{
foreach my $spec (split (' ', $args[1]))
@@ -6975,6 +6985,22 @@
require_file ($macro-rdef ($cond)-location, $mystrict, @files);
}
+# require_libobj_with_macro ($COND, $MACRO, $MYSTRICT, @FILES)
+# -
+sub require_libobj_with_macro ($$$@)
+{
+my ($cond, $macro, $mystrict, @files) = @_;
+$macro = rvar ($macro) unless ref $macro;
+if ($config_libobj_dir eq '')
+ {
+ require_file ($macro-rdef ($cond)-location, $mystrict, @files);
+ }
+else
+ {
+ require_file_internal ($macro-rdef ($cond)-location, $mystrict,
+ $config_libobj_dir, @files);
+ }
+}
# require_conf_file ($WHERE, $MYSTRICT, @FILES)
# --
--- lib/autoconf/general.m4.orig 2003-10-27 11:10:56.0 +
+++ lib/autoconf/general.m4 2005-04-18 18:00:20.0 +0100
@@ -1,6 +1,6 @@
# This file is part of Autoconf. -*- Autoconf -*-
# Parameterized macros.
-# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
+# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2005,
# 2002, 2003, Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
@@ -2436,14 +2436,19 @@
# _AC_LIBOBJS_NORMALIZE
# -
# Clean up LIBOBJS abd LTLIBOBJS so
Re: [PATCH] Support AC_CONFIG_LIBOBJ_DIR
Hi Paul,
Paul Eggert wrote:
I like the patch from the Autoconf point of view, assuming the Automake
folks take their bit.
Thanks.
One small point:
Gary V. Vaughan [EMAIL PROTECTED] writes:
+ac_libobj_dir=
+test X${ac_config_libobj_dir-.} != X.
+ ac_libobj_dir=`echo $ac_config_libobj_dir/ | sed 's,/*$,/,'`
That would mishandle the case where ac_config_libobj_dir consists
entirely of slashes, or if it contains weird characters like
backslashes or newlines in unusual positions. Is this possible? If
so, how about something like this to avoid the problem?
ac_libobj_dir=
test X${ac_config_libobj_dir-.} != X.
ac_libobj_dir=`expr X$ac_config_libobj_dir/ : 'X\(.*[^/]\)' '|' 'X/' :
'X\(/\)'`
I think that does something different. The idea of my sed expression is
just to avoid adding a trailing slash if configure.ac contains, say,
AC_CONFIG_LIBOBJ_DIR([lib/]).
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
Re: Avoid redirecting to /dev/null
Annamalai Gurusami wrote: We are using autoconf tools for our project. After doing ./configure when I issue the make command, the compiler output is being redirected to /dev/null. How to avoid this redirection? You need to arrange for libtool to receive -no-suppress in compile mode, adding it to CFLAGS is probably an option: $ libtool --help --mode=compile Usage: libtool [OPTION]... --mode=compile COMPILE-COMMAND... SOURCEFILE Compile a source file into a libtool library object. This mode accepts the following additional options: -o OUTPUT-FILEset the output file name to OUTPUT-FILE -no-suppress do not suppress compiler output for multiple passes -prefer-pic try to building PIC objects only -prefer-non-pic try to building non-PIC objects only -shared do not build a `.o' file suitable for static linking -static only build a `.o' file suitable for static linking COMPILE-COMMAND is a command to be used in creating a `standard' object file from the given SOURCEFILE. The output file name is determined by removing the directory component from SOURCEFILE, then substituting the C source code suffix `.c' with the library object suffix, `.lo'. Try `libtool --help' for more information about other modes. HTH, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: C99 support
Kevin P. Fleming wrote: Roger Leigh wrote: and these work well. What it doesn't do is let me use features such as mixed declarations and code. These require you to use gcc -std=c99 or c99 or similar, and I can't enable this portably. If autoconf could find out how to put a given compiler into C99 mode, that would be great (in the same way as AC_PROG_GCC_TRADITIONAL works for KR C). This sort of test is also needed to test C99 support for anonymous unions and structures in declarators, which I have run into problems with before. If there's a way to create AC_PROG_CC_C99 or something similar, that would be wonderful. Armed with a list of the options required to put various compilers into c99 mode, it would be quite straight forward to wrap an implementation of AC_PROG_CC_C99 around libtool's internal _LT_COMPILER_OPTION macro (which blindly tries a basic test compile with the passed option and fails or succeeds on the exit status of the compiler). This is how libtool has been turning of rtti and exceptions for a number of years: _LT_COMPILER_OPTION([if $compiler supports -fno-rtti -fno-exceptions], lt_cv_prog_compiler_rtti_exceptions, [-fno-rtti -fno-exceptions], [], [lt_no_builtin_flag=$lt_no_builtin_flag -fno-rtti -fno-exceptions ]) HTH, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
[BUG] autoupdate vs aclocal m4_include
This is Autoconf-2.59, Automake-1.9.2, CVS Libtool branch-2-0: Unless AC_CONFIG_MACRODIR is called aclocal or m4sugar, autoupdate complains about `unknown set' if aclocal.m4 uses m4_include. The run still works, but there are several pages of spurious warnings. Here's a minimal repeat recipe: $ cat configure.ac '__EOF' AC_INIT(x,0) AC_CONFIG_MACRO_DIR(m4) AC_PROG_LIBTOOL AC_OUTPUT __EOF $ libtoolize ibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/argz.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' $ aclocal -I m4 $ grep m4_include aclocal.m4 m4_include([m4/libtool.m4]) m4_include([m4/ltoptions.m4]) m4_include([m4/ltsugar.m4]) m4_include([m4/ltversion.m4]) $ autoupdate autoupdate: unknown set: m4: AC:libtool.m4:_LT_COPYING autoupdate: unknown set: m4: AC:libtool.m4:m4_location(LT_PREREQ) autoupdate: unknown set: m4: AC:libtool.m4:LT_PREREQ autoupdate: unknown set: m4: AC:libtool.m4:m4_location(LT_INIT) autoupdate: unknown set: m4: AC:libtool.m4:LT_INIT ... autoupdate: unknown set: m4: AC:ltversion.m4:LT_PACKAGE_VERSION autoupdate: unknown set: m4: AC:ltversion.m4:LT_PACKAGE_REVISION autoupdate: unknown set: m4:AC:ltversion.m4:\ m4_location(LTVERSION_VERSION) autoupdate: unknown set: m4: AC:ltversion.m4:LTVERSION_VERSION $ diff -u configure.ac~ configure.ac --- configure.ac~ Fri Nov 19 06:16:21 2004 +++ configure.acFri Nov 19 06:19:20 2004 @@ -1,4 +1,4 @@ -AC_INIT(x, 0) +AC_INIT([x],[0]) AC_CONFIG_MACRO_DIR(.) -AC_PROG_LIBTOOL +LT_INIT() AC_OUTPUT And yet by changing the directory name for AC_CONFIG_MACRO_DIR: $ rm -f *.m4 $ sed 's,(\.),(m4sugar),' configure.ac~ | tee configure.ac AC_INIT(x, 0) AC_CONFIG_MACRO_DIR(m4sugar) AC_PROG_LIBTOOL AC_OUTPUT $ libtoolize libtoolize: `./ltmain.sh' is already up to date. libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4sugar'. libtoolize: copying file `m4sugar/libtool.m4' libtoolize: copying file `m4sugar/argz.m4' libtoolize: copying file `m4sugar/ltoptions.m4' libtoolize: copying file `m4sugar/ltsugar.m4' libtoolize: copying file `m4sugar/ltversion.m4' $ aclocal -I m4sugar $ autoupdate $ diff -u configure.ac~ configure.ac --- configure.ac~ Fri Nov 19 06:28:36 2004 +++ configure.acFri Nov 19 06:31:34 2004 @@ -1,4 +1,4 @@ -AC_INIT(x, 0) +AC_INIT([x],[0]) AC_CONFIG_MACRO_DIR(m4sugar) -AC_PROG_LIBTOOL +LT_INIT AC_OUTPUT HTH, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Hi Peter! Peter O'Gorman wrote: Hmm, sorry that I am so late into the fray. Indeed the -static flag should not require a .la file. Agreed. This was an arbitrary and strange choice. In my opinion, since libtool knows the library search paths, the extension used for shared objects, the extension used for static archives and lots of other information about libraries on every platform already, the -static flag should simply prefer static archives if they are available in the linker path. There should be no need for any lists of system shared objects. Considering Bob's posts about how static linking against system libraries gets you a binary that might stop working if you move it to another similar version, or upgrade your system... and considering that we already extract a list of automatically linked libraries for each compiler incase we want to link with ld: Why do you want to make -static the same as -all-static? Libtool already has a history of trying to protect the user from themself(sic), so I would be inclined to exclude system libraries for -static as the common case, leaving -all-static for the few users that really know they want to trade off deployability against a static only link. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Hi Bill, Bill Moseley wrote: On Tue, Nov 02, 2004 at 12:39:10PM +, Gary V. Vaughan wrote: 2) Is there a standard way to run configure that should build a completely static binary? Assuming libtool is doing all your linking: ./configure LDFLAGS='-all-static' As I posted, that doesn't work. If I had thought about it a little, I wouldn't have told you that it should. My bad. What does work is: ./configure make LDFLAGS=-all-static Since passing LDFLAGS to configure doesn't work does that mean that there's something setup incorrectly in my setup? No, your setup seems fine. Libtool, however, is certainly doing the wrong thing wrt -static. We haven't quite figured out what the right thing is though. Yet. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Hi Peter, Peter O'Gorman wrote: Gary V. Vaughan wrote: Considering Bob's posts about how static linking against system libraries gets you a binary that might stop working if you move it to another similar version, or upgrade your system... and considering that we already extract a list of automatically linked libraries for each compiler incase we want to link with ld: Why do you want to make -static the same as -all-static? I am almost certain that in those cases the system libraries in question are not available as shared libs. Where a system has shared libs at all, libc is invariably one of them. I'm with Bob on excluding any libs that the compiler driver adds automatically, for the reasons above. I don't see -all-static doing anything at all on platforms where lt_prog_compiler_static is not set. Indeed. I am saying that even without this flag libtool can and should look for static libraries in favor of shared ones if -static is on the command line. I see. Maybe that's the same thing then, albeit a different algorithm. The problem with doing it that way is this: when libtool encounters a native (no .la) shared lib and links it, most modern platforms pull in the deplibs automatically AIUI. This certainly isn't true of static archives, so we could breed situations where specifying -static to libtool will break a build that was perfectly correct when using shared libraries. As an aside, I notice that lt_prog_compiler_static is not set for branch-2-0 libtool on my darwin machine. I guess this is a bug, no? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Kevin P. Fleming wrote: Bill Moseley wrote: I don't really understand why libxml2 got linked in statically and not libz. I assume that's an issue in my Makefile.am file or how we setup libz and libxml2 in our configure script. It's probably because libxml2 itself is installed using libtool (and thus there is a libxml2.la file present), where libz is not. Yep! Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Hi Bill, Bill Moseley wrote: Sorry for the cross post, not sure which is the correct list. My project builds a library and then builds a binary and links to that library. Someone has asked how to build a completely static binary. $ libtool --help --mode=link | grep static -all-static do not do any dynamic linking at all -static do not do any dynamic linking of libtool libraries 1) The configure option --disable-shared works at linking our binary with our library statically, but still links the binary dynamically with other libraries. I assume that's correct behavior. What does the --enable-static option do (or suppose to do)? It seems to have no effect when I use it. From libtool.info(The `AC_PROG_LIBTOOL' macro): - Macro: AC_DISABLE_STATIC - Macro: AM_DISABLE_STATIC Change the default behaviour for `AC_PROG_LIBTOOL' to disable static libraries. The user may still override this default by specifying `--enable-static'. 2) Is there a standard way to run configure that should build a completely static binary? Assuming libtool is doing all your linking: ./configure LDFLAGS='-all-static' You can find out what the magic flag for your compiler is by looking at the AC_LIBTOOL_PROG_COMPILER_PIC in libtool.m4 (_LT_COMPILER_PIC in 2.0 alpha releases). And then you could add that manually with: make LDFLAGS=flag-from-libtool.m4 Another message which seems related: http://lists.gnu.org/archive/html/bug-libtool/2002-07/msg00055.html This raises a good point. And although the static link issue comes up occasionally, I don't use it myself and handn't thought too deeply about it. Does anyone use libtool's -static flag to deliberately link statically against libtool libraries only? I would have thought that it is far more common to want all-static behaviour. Unless someone shouts me down, then according to the principle of least surprise, I'm inclined to change the semantics to: -static do not do any dynamic linking at all -lt-staticdo not do any dynamic linking of libtool libraries (We can keep -all-static as an alias to -static). Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Hi Bob! Bob Friesenhahn wrote: On Tue, 2 Nov 2004, Gary V. Vaughan wrote: Unless someone shouts me down, then according to the principle of least surprise, I'm inclined to change the semantics to: -static do not do any dynamic linking at all -lt-staticdo not do any dynamic linking of libtool libraries (We can keep -all-static as an alias to -static). This seems like a particularly bad idea to me. What is the value of changing existing documented libtool behavior? Consistency, and user expectation. Looking through the archives I see the repeated question of why -static still links shared libraries for libtool, but not when linking with the compiler driver or system linker: $ man gcc [[...]] -static On systems that support dynamic linking, this prevents linking with the shared libraries. On other systems, this option has no effect. [[...]] $ man ld [[...]] -static Do not link against shared libraries. This is only meaningful on platforms for which shared libraries are supported. The different variants of this option are for compatibility with various systems. You may use this option multiple times on the command line: it affects library searching for -l options which follow it. This option also implies --unresolved-symbols=report-all. [[...]] $ libtool --mode=link --help [[...]] -static do not do any dynamic linking of libtool libraries [[...]] It seems that our users expect orthogonality of the order: cc -static ... === libtool --mode=compile cc -static ... ld -static ... === libtool --mode=link ld -static ... except that libtool should figure out the equivalent options for whatever compiler it was configured for. The main purpose of building a completely static program is to satisfy security or system bootstrap requirements (/usr partition not mounted). It is not always possible to build a completely static program. It is not usually desirable to build a completely static program. Completely static programs don't necessarily work properly when copied to a somewhat different processor type with the same OS, or a different kernel version. Hmmm... interesting. So is this still the case if I build my program without libtool, using cc/ld -static (which is basically what -all-static currently does)? I guess my argument boils down to this: Unless most of our users who think they want -all-static actually want (libtool's existing) -static, and as long as the use of the -static option in libtool calls in released packages to mean what it currently does is both deliberate and (at least a little) widespread: it makes more sense for libtool to do what one would expect when passed the -static flag. Are these assumptions good? i) people who specify -static to libtool don't want to link against any dynamic libraries, and are suprised that isn't actually the case. ii) the -static option is not used to mean `link static libtool libraries, and dynamic otherwise' in many shipping packages. If not, then maybe we need a third type of static linking in libtool, that links statically where possible, except if no static lib is available (-ldl?). But thats what I expect -all-static to do now, and I think it should be called -static... Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Hi Bill,
Bill Moseley wrote:
$ grep -- -static src/Makefile.am
libtest_LDFLAGS = -static
(which maybe answers your question if anyone is using -static)
Not really. See my other post to this thread.
I'm not using AC_DISABLE_STATIC in configure -- and using
--enable-static (without listing packages) seems to have no effect.
So do I have something setup incorrectly?
Nope. --enable-static is the default unless AC_DISABLE_STATIC is used
in configure.ac. You could stop building static libraries by passing
--disable-static, or adding AC_DISABLE_STATIC to configure.ac.
--{en,dis}able-static vs AC_{DIS,EN}ABLE_STATIC apply to what kind of
libtool libraries to build, and have no effect on how programs are
linked.
$ ./configure --prefix=$HOME/static LD_FLAGS='-all-static' /dev/null make
install /dev/null
just LDFLAGS ^^^
$ ldd $HOME/static/bin/swish-e
libxml2.so.2 = /usr/lib/libxml2.so.2 (0x40027000)
libpthread.so.0 = /lib/tls/libpthread.so.0 (0x40122000)
libz.so.1 = /usr/lib/libz.so.1 (0x40132000)
libswish-e.so.2 = /home/moseley/static/lib/libswish-e.so.2 (0x40144000)
libm.so.6 = /lib/tls/libm.so.6 (0x4017a000)
libc.so.6 = /lib/tls/libc.so.6 (0x4019d000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
So, does that mean I'm not passing in a variable to my Makefile.am?
http://cvs.sourceforge.net/viewcvs.py/swishe/swish-e/src/Makefile.am?rev=1.12view=auto
If you leave libtest_LDFLAGS = -static and pass LDFLAGS=-all-static, you'll
end up running
libtool --mode=link -static -all-static ...
In that case, behaviour is undefined, you should pick just one of those options.
Does anyone use libtool's -static flag to deliberately link statically
against libtool libraries only? I would have thought that it is far
more common to want all-static behaviour.
I'm not really clear on what you are asking, but I use -static in my
Makefile.am to always link a little test program with our library
statically to help with debugging.
$ ldd libtest
libz.so.1 = /usr/lib/libz.so.1 (0x40027000)
libm.so.6 = /lib/tls/libm.so.6 (0x40039000)
libc.so.6 = /lib/tls/libc.so.6 (0x4005d000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
So libswish-e is linked statically there.
But would you be unhappy if libtool took -static to be the same as calling
cc -static and/or ld -static to link?
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Replying to myself after reading more of the thread... Gary V. Vaughan wrote: Bob Friesenhahn wrote: The main purpose of building a completely static program is to satisfy security or system bootstrap requirements (/usr partition not mounted). It is not always possible to build a completely static program. It is not usually desirable to build a completely static program. Completely static programs don't necessarily work properly when copied to a somewhat different processor type with the same OS, or a different kernel version. Hmmm... interesting. So is this still the case if I build my program without libtool, using cc/ld -static (which is basically what -all-static currently does)? From your other post, it seems that cc/ld -static (maybe) gets you a static program that you can't use (reliably) on another machine with a different libc, or after you upgrade your kernel. Taking that argument forward... I guess my argument boils down to this: Unless most of our users who think they want -all-static actually want (libtool's existing) -static, and as long as the use of the -static option in libtool calls in released packages to mean what it currently does is both deliberate and (at least a little) widespread: it makes more sense for libtool to do what one would expect when passed the -static flag. Are these assumptions good? i) people who specify -static to libtool don't want to link against any dynamic libraries, and are suprised that isn't actually the case. i) people who specify -static to libtool don't want to link against any dynamic libraries, except for system libraries, and are surprised when libtool pulls in a bunch of random dynamic libraries that just happened to be missing a .la file. ii) the -static option is not used to mean `link static libtool libraries, and dynamic otherwise' in many shipping packages. ii) people who ship a package that passes -static to libtool would not be surprised if their binary was dynamically linked to a few core system libraries, provided everything else was statically linked. If not, then maybe we need a third type of static linking in libtool, that links statically where possible, except if no static lib is available (-ldl?). But thats what I expect -all-static to do now, and I think it should be called -static... All of which now makes me think that using .la files as the selector for which libraries should be linked statically is a pointless and arbitrary distinction for the -static option. Boiling down to: How do we sensibly figure out which libraries need to be linked dynamically in the face of -static? And I think the answer must be: We add a new libtool configvar that lists libraries that are always linked dynamically per host triplet, and put it in a libtool.m4 macro on HEAD for incremental improvement. And we make -static use that list when choosing which libraries to link dynamically. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Hi Bob, Ralf! Bob Friesenhahn wrote: On Tue, 2 Nov 2004, Ralf Wildenhues wrote: Is that a mail-only typo? You used LD_FLAGS instead of LDFLAGS. But then, configure will most likely fail soon, before libtool is even involved -- the compiler will see -all-static and barf. There's been discussion about this on this list about Libtool-specific environment variables and -Xlinker stuff. However, I do not know a general approach to your setting. I'd just do configure LDFLAGS=-static make LDFLAGS=-all-static but that's obviously a hack. A general solution to this problem is needed. The only fool-proof solution is for autoconf to use libtool to execute its tests, however, libtool itself is dependent on autoconf so there is a seemingly unsolvable problem. This is a classic bootstrap problem. A libtool release tarball can be built without autoconf, and autoconf could generate a configure that used such an installed libtool for running its tests when the configure.ac invoked LT_INIT... Akim and I long ago discussed how life could become much easier if the autotools merged into a single cooperative package to fix this kind of thing. There was some loose agreement that this would happen someday :-( Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Hi Ralf, Ralf Wildenhues wrote: Besides, it's a clear change of published interface (this doesn't mean I'm for or against the change. Just needs to be marked VERY VERY big. Users of former Libtool-type `-static' will need to use libtool --version in order to differentiate old and new behavior, and so on. Ugly. How many packages/people use this? How many people have called other autotools names because of interface changes?) Absolutely. In light of discussion so far, can we get consensus on leaving `-all-static' as is, and making `-static' choose which system libraries to link dynamically based on some other method than whether or not they have a .la file attached? `-lt-static' was still-born, lets pretend I never said that ;-) Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Building all static
Hey Bruce! Bruce Korb wrote: ``-static'' needs to imply the common and ordnary meaning of ``static''. libtool is a less common and ordinary command than either gcc or ld. It is not a directly obvious thing that you would need to add the qualifier all- to it in order to actually get static linking. Being obvious is far more important Not forgetting the excellent advantage that ./configure LDFLAGS=-static would behave as expected. In fact, if configure didn't run a test that noticed the difference between `ld/cc -static' and `libtool --mode=link ld/cc -static', then it could be made to behave even better than expected by cleverly omitting the system libraries from the list of statically linked objects :-) than compatibility for the few users who: 1. use -static 2. don't want fully static 3. would have a hard time coping with the change :-) Cheers - Bruce What he said :-) As long as they are `few'. I happen to think that they really are. And for the very few who really really want fully static, they can still use -all-static to stop libtool trying to outsmart them. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bug in XFile.pm?
Alexandre Duret-Lutz wrote:
Hi Gary,
Salut Alexandre!
Gary == Gary V Vaughan [EMAIL PROTECTED] writes:
Gary While trying to autoconfiscate zlib-1.2.2 on a Linux
Gary RHEL3 box, I keep seeing the following error from
Gary aclocal, automake and autoconf during bootstrap:
Gary Use of uninitialized value in concatenation (.) or string at
Gary /opt/TWWfsw/autoconf25/share/Autom4te/XFile.pm line 229.
Gary XFile.pm hasn't changed in CVS autoconf vs the erroring file.
Could you try this?
--- XFile.pm 23 Oct 2003 14:29:22 - 1.8
+++ XFile.pm 1 Nov 2004 15:56:59 -
@@ -228,7 +228,8 @@
# Admittedly this is a bit of a hack.
if (!flock ($fh, $mode)
(!$!{ENOLCK}
- || -$ENV{'MAKEFLAGS'} =~ / (-[BdeikrRsSw]*j|---?jobs)/))
+ || (exists $ENV{'MAKEFLAGS'}
+ -$ENV{'MAKEFLAGS'} =~ / (-[BdeikrRsSw]*j|---?jobs)/)))
{
my $file = $fh-name;
fatal cannot lock $file with mode $mode (perhaps you are running make -j on
a lame NFS client?): $!;
[...]
Yep. That does the trick. Thanks!
Running automake before aclocal is a mistake.
Gah! I knew that ;-)
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/autoconf
Re: m4sugar.m4
Salut Akim! Akim Demaille wrote: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Would you mind if I ship an implementation of m4sugar.m4 with the next release of GNU m4, with an eye to replacing parts of it with C at some point? There are some issues in m4sugar that were waiting for a better C implementation. In particular: - ERE instead of BRE I'm still not sure how to do this in a backwards compatible way. What about adding an optional 4th parameter for setting the regexp syntax (that defaults to BRE if unset)? Apps that need ERE can use: patsubst(foo, bar, baz, ERE) - text builtins should return their result *quoted*. Agreed. I'll make sure this goes in! However, a C implementation of m4sugar is not the best (=more urgent) service GNU M4 can give to M4sugar: call-stack introspection would be much better, and would considerably speed up Autoconf (I bet of 30%). Basically, everything related on m4_expansion_stack should be provided by m4 itself. Okay, that sounds like a worthy goal. I'll put it at the top of my m4 TODO. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: libtool--release--2.0 test results
I bootstrapped libtool with the autoconf-2.59 release, so maybe this bug is fixed in CVS autoconf? Gary V. Vaughan wrote: hppa2.0-hp-hpux10.20: 3 of 85 tests failed [[All tagdemo-make]] Anyway these fail because of this: checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no ^^^ CXX gets set to g++ if there is no C++ compiler on the host. :-( Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: shell portability question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Paul! On 19 Sep 2004, at 05:11, Paul Eggert wrote: Gary V.Vaughan [EMAIL PROTECTED] writes: # Check that break and continue aren't misused in our portable shell scripts. $EGREP -n '[^]=[^].*(break|continue)' $scripts \ I dunno, but perhaps it's checking for invalid usages like this? foo=bar break That would indeed be invalid, but usages like test -r foo bar=baz break are OK as far as I know. Okay, thanks for the reply. I'll change the test to: $EGREP -n '[^ ]=[^]*[ ]*(break|continue)' $scripts Which will also stop it choking on valid things like this: foo=bar; break Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFBTW1qFRMICSmD1gYRAkHzAJ4+5tI+e/A4P+m0Z57f79zbBS4iUACdF4Ii VW8OWue4Y4o+D/nRGcWxPrc= =8iRo -END PGP SIGNATURE- ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: shell portability question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Paul, On 19 Sep 2004, at 18:00, Paul Eggert wrote: Gary V.Vaughan [EMAIL PROTECTED] writes: I'll change the test to: $EGREP -n '[^]=[^]*[ ]*(break|continue)' $scripts Which will also stop it choking on valid things like this: foo=bar; break Unfortunately that pattern matches foo=bar; break, no? You'll need something a good deal more sophisticated, I'm afraid. Perhaps it'd be simpler just to remove the check. D'oh! Quite right. I think the test has very limited value, so I'll propose a patch to remove it entirely. Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFBTgESFRMICSmD1gYRAkB4AKCYSycwa3wzYwZ0uJPjOdjQSvdiGwCfc4jx mVjTR4SDf1KSlZiqhXV9J24= =wJwz -END PGP SIGNATURE- ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
shell portability question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm in the process of converting libtool to use autom4te to generate its scripts, but now a test I inherited from Gord is failing... The failing test case says: # Check that break and continue aren't misused in our portable shell scripts. $EGREP -n '[^]=[^].*(break|continue)' $scripts \ func_fail cannot use \`break' or \`continue' on the same line as an assign ment But AS_SHELL_SANITIZE says: # Find who we are. Look in the path if we contain no path at all # relative or not. case $[0] in *[[\\/]]* ) as_myself=$[0] ;; *) _AS_PATH_WALK([], [test -r $as_dir/$[0] as_myself=$as_dir/$[0] break]) ;; esac Who is correct? Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFBTHHYFRMICSmD1gYRAmJVAJ98KLXYP3oj1EC5jP9C4BaMekEa3ACfWyxk 7xb7kk9dIf6Eci1odXRZCuU= =UCwN -END PGP SIGNATURE- ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
m4sugar.m4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Would you mind if I ship an implementation of m4sugar.m4 with the next release of GNU m4, with an eye to replacing parts of it with C at some point? Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFBR67wFRMICSmD1gYRAoDKAKComvIeiMmiDDjM1IBCdTD0T39uawCgjUi4 YJb0IE8h5OXjFi/EE62o1O0= =YEQS -END PGP SIGNATURE- ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: help with Failed dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5 Sep 2004, at 19:32, r43233 wrote: I frequently have to install software in a non standard place (I can't be root), which causes other packages not to find the installed ones. I add the path to the installed package to my path as well as to LD_LIBRARY_PATH. I am running RH9 on a pc. You also need to tell the preprocessor where the include files are, and the linker where the libraries are: ./configure --prefix=$HOME/sw CPPFLAGS=-I$HOME/sw/include \ LDFLAGS=-L$HOME/sw/lib If you are using libtool to link, then don't mess with the LD_LIBRARY_PATH, that is for finding libraries when a program starts up, not when it is being compiled. HTH, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFBO4lNFRMICSmD1gYRAv3WAJ9WN3lB2aDVYVqivbkGt6eOJU4f0gCgi/rq eQzWNg2McNJ1oNr2NTE9crY= =+9Mp -END PGP SIGNATURE- ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: checking for gcc
bertold wrote: how to cancel check for gcc? i believe it's in configure.in file. If you want to specify a compiler, other than the one configure finds when left to its own devices, just invoke configure like this: $ ./configure CC=xlc -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: cvs build prob
Hi Patrick! Patrick Welche wrote: On Tue, Jul 27, 2004 at 01:25:43PM -0700, Paul Eggert wrote: Gary V. Vaughan [EMAIL PROTECTED] writes: The workaround in this case is easy. Just omit the outer quotes and remove the inner backslashes: output_verbose_link_cmd=`$echo X$output_verbose_link_cmd | $Xsed -e $no_glob_subst` The outer quotes aren't needed. This issue is discussed in the Autoconf manual's Shellology section. I'm now quite confused :-) I can verify that Gary's libtool patch, which does the above, fixes things, but I find I need the opposite as an autoconf patch (attached). I guess you're talking about libtool--devo--1.0--patch-92, right? It is very belt and braces. Not only have I fixed the obvious cases of nested escaped double quotes in libtool.m4, but I've added the new KSH_VERSION toting AS_SHELL_SANITIZE expansion to ltmain.in (and hence the generated libtool script) and libtoolize.in. There are other nested escaped double quotes in libtool.m4 that I can't remove simply though, hence the note about bootstrapping with CVS autoconf... The quote removal you reference above is probably what fixes your immediate problem, but I guess the new AS_SHELL_SANITIZE is triggering something else. :-( If you revert my patch, or fetch the prepatch revision from my arch mirror, and bootstrap with HEAD autoconf, does the new AS_SHELL_SANITIZE from autoconf prevent the crash when setting output_verbose_link_cmd? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: cvs build prob
Hi Patrick, Good catch! I'm CCing the autoconf list, as this is probably a candidate for AS_SHELL_SANITIZE, and the comparative shellology documentation... Patrick Welche wrote: On Tue, Jul 27, 2004 at 04:07:14PM +0100, Patrick Welche wrote: The great part is this is a ksh quoting problem: Oh joy... (ksh version @(#)PD KSH v5.2.14 99/07/13.2) .. and it is explained in TFM: The following is a list of things that are affected by the state of the posix option: o\ inside double quoted `..` command substitutions: in posix mode, the \ is interpreted when the command is interpreted; in non-posix mode, the backslash is stripped before the command substitution is interpreted. For example, echo `echo \hi\` produces `hi' in posix mode, `hi' in non-posix mode. To avoid problems, use the $(...) form of command substitution. So what now for the libtool point of view? At least until AS_SHELL_SANITIZE handles this, libtool needs to find a workaround. - I still wonder why ksh is chosen over sh on my NetBSD system. ksh has function support for one thing, and maybe $LINENO support. - Should we use the $(...) form of command substitution To avoid problems? We can't use $(...) indiscriminately, as plenty of ancient bourne compatible shells will choke on it :-( Reminder of the miscreant line: output_verbose_link_cmd=`$echo \X$output_verbose_link_cmd\ | $Xsed -e \$no_glob_subst\` (setting set +o posix in configure for the benefit of ksh fixes things too.) Does ksh have a way to detect itself programatically so that libtool can add something of the form: test -z $KSH_VERSION || set +o posix Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
[BUG] autoreconf calls libtoolize too late
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In my current testing with HEAD autoconf, I notice that autoreconf calls autopoint (because it installs m4 files for aclocal), then aclocal, and *then* libtoolize. Presumably this is because for a while libtoolize tried to run aclocal itself and then do a trace to see whether macros were needed. Since, like autopoint, libtoolize installs m4 files for aclocal, I think aclocal should be called after libtoolize... possibly running aclocal again after libtoolize if the first aclocal invocation is needed to set up a trace or something... This is causing real problems for my m4 bootstrap, which currently has to call libtoolize by hand before calling autoreconf (which then calls it again with no effect after aclocal). Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA0VG4FRMICSmD1gYRAqgMAJ4qGvJRv1vLll/Wx2kSghFB/3SALwCfaw+C 5xys6WXFLf4RvSjgLLrqj04= =lMoQ -END PGP SIGNATURE- ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: libtoolize and AC_CONFIG_SUBDIRS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Braden, On 29 Apr 2004, at 19:35, Braden McDaniel wrote: Some issues related to use of CVS libtool with AC_CONFIG_SUBDIRS: 1. libtoolize doesn't appear to recurse into AC_CONFIG_SUBDIRS. Should it? Or is this autoreconf's job? Autoreconf's job. 2. I cannot get CVS autoreconf to work at all with CVS libtool. Perhaps this is a Known Issue; but I haven't seen it mentioned. I have CVS autoconf from a few weeks ago installed and autoreconf works for me. I'll cvs up and recheck. 3. If I execute libtoolize in the subpackage root directory, it seems to know that AC_CONFIG_AUX_DIR should be ... I don't explicitly use the AC_CONFIG_AUX_DIR macro anywhere, so I'm guessing libtoolize does some sniffing. Perhaps it should do something similar for AC_CONFIG_MACRO_DIR? (That is, use the main package's AC_CONFIG_MACRO_DIR if none is set in the subpackage's configure.ac.) That is autoconf simply tracking back up the tree looking for install-sh if AC_CONFIG_AUX_DIR is not set in the subpackage. Libtool doesn't do anything special for either. HTH, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAkgT3FRMICSmD1gYRAg2WAJkBjc93Cx813/97uimorBTiTpECcACbBGe/ 7gziI9WhPBYQNC/IztRhid8= =Il57 -END PGP SIGNATURE-
Fwd: libtool--gary--1.0--patch-8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In response to this thread: Alexandre Oliva wrote: On Apr 7, 2004, Gary V. Vaughan [EMAIL PROTECTED] wrote: Agreed. Autoconf generates a config.h that encourages #ifdef/#ifndef. And then it promotes the use of #if. I recall discussions about this in the autoconf list years ago, and there was a conscious decision to replace most uses of #ifdef with #if in the documentation, but I can't find any wording that explicitly recommends the use of #if over #ifdef. Oh well... I have had to patch up libltdl so that it doesn't give spurious warnings when gcc isn't used: Tree version: [EMAIL PROTECTED]/libtool--devo--1.0 CVSROOT:/cvsroot/libtool TIMESTAMP: 1.1477 2004/04/13 15:30:10 Module name:/cvsroot/libtool/libtool Changes by: [EMAIL PROTECTED] Log Message: * libltdl/lt__pre89.h, libltdl/ltdl.c, libltdl/ltdl.h, libltdl/argz.c, libltdl/argz.h, libltdl/lt__glibc.h, libltdl/lt_dlloader.h, libltdl/lt__dirent.c, libltdl/lt__dirent.h, libltdl/lt__private.h, libltdl/lt__alloc.c, libltdl/lt__alloc.h, libltdl/lt_system.h, libltdl/loader-dld_link.c, libltdl/loader-dlopen.c, libltdl/loader-dyld.c, libltdl/loader-loadlibrary.c, libltdl/loader-shl_load.c, libltdl/lt_error.h, libltdl/lt_mutex.h: Autoconf either defines to 1 or undefs the discovery macros it puts in config.h, and many (non-GNU) compilers throw a spurious warning when testing an #undef macro with #if. For consistency, while we are touching all these lines, use defined(MACRO) style throughout. Reported by Bob Friesenhahn [EMAIL PROTECTED] I figured you might like to document that somewhere in autoconf.texi to save anyone else from the same mistake. Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAfA2qFRMICSmD1gYRAiKOAKDD26wM5vZRv1SWV6D+ya48QDYabgCguZPA aUMolI/bo139+mzkajEqOpM= =uECB -END PGP SIGNATURE-
Re: [PATCH] Fix some bootstrap issues arising from multi-lang support. (Modified by Gary V. Vaughan)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23 Mar 2004, at 00:30, Scott James Remnant wrote: I finally figured out why tagdemo gets run even if we've got no C++ support, AC_PROG_CXX leaves CXX defined to g++ even if it can't find a compiler. So instead we catch errors, and don't do the tests if an error occurred. This also tidies up a few loose ends left over from the LT_LANG patch to ensure GCJ and RC support are enabled correctly. Okay to apply? Excellent! Please do. I'm Cc:ing the Autoconf list so that they can fix AC_PROG_CXX for the next release too. Cheers, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAYVn/FRMICSmD1gYRAsvKAJ457uSztlRWty6UF2GSWMdVqpk+wwCgm6OC NdgTmIck1PwGdxDklvqWmtg= =mqcM -END PGP SIGNATURE-
Re: func_infer_tag() broken on IRIX 6.5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Albert Chin wrote:
| So this means func_infer_tag() is broken in branch-1-5 because it does
| this:
| func_infer_tag () {
| if test -n $available_tags test -z $tagname; then
| CC_quoted=
| ...
| # Blanks at the start of $base_compile will cause this to fail
| # if we don't check for them as well.
| *)
| for z in $available_tags; do
| if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $z$ $0
/dev/null; then
|
| So, should I modify the top of ltmain.in from:
| # The name of this program.
| progname=`$echo $0 | ${SED} 's%^.*/%%'`
| modename=$progname
| to:
| # The name of this program.
| progname=`$echo $0 | ${SED} 's%^.*/%%'`
| full_path_progname=$0
| modename=$progname
|
| and then we can use $full_path_progname in func_infer_tag().
Agreed, although I'd suggest argv0 as the variable name.
I think we should also begin cataloging such portability issues, probably in
the autoconf manual... but for now I would like to nail down exactly how much
functionality we should expect of our shell functions (HEAD libtoolize uses
them extensively for example), and why and where other function features fail.
I've used return in a couple of places (twice with an integer return value),
which I fear may break on old platforms. Otherwise I've assumed that all
shell variables are in global scope, and that positional parameters are
stacked and restored at function call boundaries to an arbitrary nesting
limit.
Removing the returns isn't too hard, but if my other assumptions are bad, then
1.6 is in trouble :-(
Cheers,
Gary.
- --
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://www.oranda.demon.co.uk
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD4DBQFAKnwoFRMICSmD1gYRAkvBAJYgOARzhLn2hvxziSSEp4GJ1lh7AKCuz4wK
6GQ9T+KdeWA960500AHkaw==
=dWhB
-END PGP SIGNATURE-
Re: Trouble with variable substitution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 martin f krafft wrote: | Hi there, I am trying to do the following: | | AC_INIT(libhid, 0.1.91.0.0, [EMAIL PROTECTED]) | | LIBHID_MAJOR_VERSION=`echo $AC_PACKAGE_VERSION | cut -d. -f1` | LIBHID_MINOR_VERSION=`echo $AC_PACKAGE_VERSION | cut -d. -f2` | LIBHID_MICRO_VERSION=`echo $AC_PACKAGE_VERSION | cut -d. -f3` | LIBHID_INTERFACE_AGE=`echo $AC_PACKAGE_VERSION | cut -d. -f4` | LIBHID_BINARY_AGE=`echo $AC_PACKAGE_VERSION | cut -d. -f5` | LIBHID_VERSION=`echo $AC_PACKAGE_VERSION | cut -d. -f1-3` | | PACKAGE=AC_PACKAGE_NAME | VERSION=LIBHID_VERSION ~From libtool configure.ac (which uses maj.min[.mic][alpha]): LT_MAJOR=`echo AC_PACKAGE_VERSION | sed ['s,\..*$,,g']` LT_MINOR=`echo AC_PACKAGE_VERSION | sed ['s,^[0-9]*\.\([0-9]*\).*$,\1,']` LT_MICRO=`echo AC_PACKAGE_VERSION \ | sed ['s,^[0-9]*\.[0-9]*\(\.[0-9]*\).*$,\1,']` LT_ALPHA=`echo AC_PACKAGE_VERSION | sed ['s,^[0-9.]*,,']` Note the lack of $AC_PACKAGE_VERSION, AC_PACKAGE_VERSION is an m4 macro! After this you could add, say: VERSION=$LT_MAJOR.$LT_MINOR.$LT_MICRO HTH, Gary. - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAF4h3FRMICSmD1gYRAgNaAKCQg7sQ4VhXZ9XuQpwoKPFi9R9xrgCfTFlW DJ/yxZREukedlcPzetSo5qk= =pPF6 -END PGP SIGNATURE-
