Re: Autoconf --trace
Yeehaa, Yahoo, Yipee and the like! Well, there are some significant steps forward since yesterday :) Gosh, it feels good when m4 finally agrees to do what you wanted to :-) I have implemented support for $.@, which is [$1].[$2]. etc. (`.' is the separator, defaults to comma), and for $.*, which is smash($1).smash($2). etc., where `.' defaults to `:', and `smash' singles out all the white spaces. If you required no tracing format, you get `$f:$l:$n:$*', i.e., for instance: ~fu % ~ace/autotrace -m ~ace --trace AC_DEFINE ./aclocal.m4:1694:AC_DEFINE:AFS:1:Define if you have the Andrew File System. configure.in:12:AC_DEFINE:_GNU_SOURCE configure.in:22:AC_DEFINE:_ALL_SOURCE configure.in:23:AC_DEFINE:_POSIX_SOURCE:1:Define if you need to in order for `stat' and other things to work. or even: ~fu % ~ace/autotrace -m ~ace --trace 'AC_OUTPUT:With quotes: $@ without: $*' With quotes: [Makefile doc/Makefile intl/Makefile lib/Makefile man/Makefile m4/Makefile po/Makefile.in src/Makefile tests/Makefile tests/chmod/Makefile tests/cp/Makefile tests/dd/Makefile tests/dircolors/Makefile tests/install/Makefile tests/ln/Makefile tests/ls/Makefile tests/ls-2/Makefile tests/mkdir/Makefile tests/mv/Makefile tests/rm/Makefile tests/rmdir/Makefile tests/shred/Makefile tests/touch/Makefile ] without: Makefile doc/Makefile intl/Makefile lib/Makefile man/Makefile m4/Makefile po/Makefile.in src/Makefile tests/Makefile tests/chmod/Makefile tests/cp/Makefile tests/dd/Makefile tests/dircolors/Makefile tests/install/Makefile tests/ln/Makefile tests/ls/Makefile tests/ls-2/Makefile tests/mkdir/Makefile tests/mv/Makefile tests/rm/Makefile tests/rmdir/Makefile tests/shred/Makefile tests/touch/Makefile worse yet: | /tmp % cat foo | define([foo]) | foo([several | | | lines]) | | foo([a\ | big\ | token]) | /tmp % ~ace/autotrace --trace foo -m ~ace foo | foo:5:foo:several lines | foo:9:foo:abigtoken Bwahaha :) So I think we will be able to start using this in Automake, no? Well, of course there are problems. The first one being that if you trace an m4 builtin, weird things happen. This can be solved by undefining them. Akim PS/ Beware there is a literal ^Q in it, which you need if you want this to work properly. BTW, is it normal that bash does not split around ^A? I found nothing like this in the doc: | ~ace % cat -v /tmp/ifs | list="a^Qb" | IFS="^Q" | for i in $list | do | echo $i | done | | list="a^Ab" | IFS="^A" | for i in $list | do | echo $i | done | ~ace % bash /tmp/ifs | /tmp/ifs: /tmp/ifs: cannot execute binary file Naah, come on, it is not binary! | ~ace % cat -v /tmp/ifs | #! /bin/sh | | list="a^Qb" | IFS="^Q" | for i in $list | do | echo $i | done | | list="a^Ab" | IFS="^A" | for i in $list | do | echo $i | done | ~ace % bash /tmp/ifs | a | b | ab while zsh (with emulate sh) splits it properly. GNU bash, version 2.04.0(1)-beta5 (i386-pc-linux-gnu) Copyright 1999 Free Software Foundation, Inc. #! @SHELL@ # autoconf -- create `configure' using m4 macros # Copyright (C) 1992, 93, 94, 96, 99, 2000 Free Software Foundation, Inc. # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA # 02111-1307, USA. # If given no args, create `configure' from template file `configure.in'. # With one arg, create a configure script on standard output from # the given template file. me=`echo "$0" | sed -e 's,.*/,,'` usage="\ Usage: autoconf [OPTION] ... [TEMPLATE-FILE] Generate a configuration script from a TEMPLATE-FILE if given, or \`configure.in' by default. Output is sent to the standard output if TEMPLATE-FILE is given, else into \`configure'. If the option \`--trace' is used, no configuration script is created. -h, --help print this help, then exit -V, --version print version number, then exit -d, --debug don't remove temporary files -m, --macrodir=DIR directory storing Autoconf's macro files -l, --localdir=DIR directory storing the \`aclocal.m4' file -t, --trace=MACRO report the list of ca
Re: @BKL@, @BKR@, etc.
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: Paul> No. E.g. grep's configure.in says: Paul> LIBOBJS=`echo $LIBOBJS|sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'` Paul> and bison's aclocal.m4 says: Paul> echo timestamp > `echo <<$>>am_file | sed -e 's%:.*%%' -e Paul> 's%[^/]*$%%'`stamp-h$am_indx Arg. Thanks for the exhaustive check. Paul> But these aren't trigraphs; they're quadrigraphs. :-) :) Paul> I just checked a wide variety of source code using autoconf, and Paul> found no instances of these quadrigraphs in any of them. OK, so I think it is sold. Well, until the great autoconf-patches judgment. Will you submit a patch, or we implement your idea? Akim
Re: xemacs configure script doesn't have AC_DEFINE
> "Olly" == Olly Betts <[EMAIL PROTECTED]> writes: Olly> If you ask someone in the UK to draw you a `pound sign' you'll Olly> get one of these: `£' (that's the British currency symbol in Olly> case something is eating high bits or you aren't reading this in Olly> latin1). And in fact the HTML entity `£' refers this Olly> character. Olly> Anyway, `@PND@' is a poor mnemonic for UK users - perhaps Olly> there's a better choice? Is `hash' (@HSH@) a globally Olly> recognised name for `#', or is that a UK-only usage? Olly> Or `number sign' (@NUM@ or @NMB@)? Not in very common usage Olly> here, but at least not ambiguous. Sorry, I confess I picked up this name not knowing how `#' is actually called. It wanted something quickly and did not take the time to check how appropriate it was. Anyway, we are moving to quadrigraphs now :) Akim
Re: Argh. config.guess breaks things
> BTW this problem doesn't just occur on RedHat Linux boxes without a C > compiler. I have a RedHat 6.1 box here which has gcc installed, but > only as `gcc' and not as `cc'. I'm not totally sure how it got this > way since the egcs rpm does have /usr/bin/cc in. I suspect I built > gcc-2.95.2 from scratch with egcs-1.1.2 and then uninstalled egcs to > make sure that nothing could use it by mistake. This is a known flaw in config.guess. I have every intention of fixing it, soon. It's crazy that a script of such importance fails to use `gcc' if `cc' isn't present. Ben
Re: Argh. config.guess breaks things
%% Ben Elliston <[EMAIL PROTECTED]> writes: >> BTW this problem doesn't just occur on RedHat Linux boxes without a C >> compiler. I have a RedHat 6.1 box here which has gcc installed, but >> only as `gcc' and not as `cc'. I'm not totally sure how it got this >> way since the egcs rpm does have /usr/bin/cc in. I suspect I built >> gcc-2.95.2 from scratch with egcs-1.1.2 and then uninstalled egcs to >> make sure that nothing could use it by mistake. be> This is a known flaw in config.guess. I have every intention of be> fixing it, soon. It's crazy that a script of such importance be> fails to use `gcc' if `cc' isn't present. Just a reminder that this isn't good enough: it wouldn't have helped in the case I mentioned. The script has to also provide an understandable error message if _neither_ gcc or cc is present or usable (remember that sometimes the "cc" program exists, but it doesn't do anything except print an error, like on a base Solaris system). -- --- Paul D. Smith <[EMAIL PROTECTED]> Network Management Development "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: passing command-line switches to compiler
~ :The GNU binutils use this macro to detect this case: ~ : oh, by the way while playing with this macro I noticed a couple of problems : 1. `test $bfd_cv_decl_needed_$1` didn't work because $bfd_cv_decl_needed was considered as two shell variables $bfd_cv_decl_needed and $1, so I had to tweak it with eval "test `echo ..`". 2. It breaks autoheader is some funny way, because autoheader replaces most of macroses which are supposed to define things with it's own pieces which then generate config.h.in. However it doesn't execute shell scripting parts, so for every used macros like this it would have: #undef NEED_DECLARATION_ I have fixed it by adding a wrapper macro with `for f in functions` so #undef NEED_DECLARATION_ appears only once, but now you still have to manually define all #undef NEED_DECLARATION_FUNCTIONS to get the things working properly. other than that it works fine, thanks :)
Re: passing command-line switches to compiler
~ :CyberPsychotic> am using autoconf 1.4.1 package (shipped with ~ :CyberPsychotic> r.h. 6.0) and this macro isn't defined there, starting ~ : ~ :Can you tell me who packaged Autoconf 2.14.1 (I guess that's what you ~ :meant). sure. it's Mandrake linux release 6.0, it's based on r.h. 6.0 package though, so redhat might have it too. ~ :CyberPsychotic> sourceware.cygnus.com and ftp.gnu.org which used to ~ :CyberPsychotic> distribute autoconf in past and they both have the ~ :CyberPsychotic> tarballs of Jan. 16, 1999 as most recent ones. if ~ :CyberPsychotic> there was any development of autoconf package since ~ :CyberPsychotic> that time, it's definitely not the latest snapshot :) ~ : ~ :Huh? There are beta Autoconf somewhere? ~ : :) I don't really understand what you mean. Most sites I checked have autoconf 2.13 version. However on some linux distributions which have autoconf packages, autoconf --version gives various 2.14.* stuff :)
Re: passing command-line switches to compiler
Date: Wed, 1 Mar 2000 01:01:45 +0500 (KGT) From: CyberPsychotic <[EMAIL PROTECTED]> ~ :The GNU binutils use this macro to detect this case: ~ : oh, by the way while playing with this macro I noticed a couple of problems : 1. `test $bfd_cv_decl_needed_$1` didn't work because $bfd_cv_decl_needed was considered as two shell variables $bfd_cv_decl_needed and $1, so I had to tweak it with eval "test `echo ..`". 2. It breaks autoheader is some funny way, because autoheader replaces most of macroses which are supposed to define things with it's own pieces which then generate config.h.in. However it doesn't execute shell scripting parts, so for every used macros like this it would have: #undef NEED_DECLARATION_ I have fixed it by adding a wrapper macro with `for f in functions` so #undef NEED_DECLARATION_ appears only once, but now you still have to manually define all #undef NEED_DECLARATION_FUNCTIONS to get the things working properly. I don't know what sort of playing around you were doing. When used in BFD, where it is an AC_DEFUN, the $1 is replaced at the m4 level, so the shell never sees it. Certainly if you take it out of the AC_DEFUN, or try to make it into a loop, or add an extra level of quoting, it won't work. Perhaps the same issue arises with autoheader. At least for me, autoheader works fine, and I get entries like this: /* Define if malloc is not declared in system header files. */ #undef NEED_DECLARATION_MALLOC In any case, you may want to just pick up the macro that Akim mentioned that is in the current sources, and use that until the next autoconf release comes out. Ian
Re: passing command-line switches to compiler
> sure. it's Mandrake linux release 6.0, it's based on r.h. 6.0 package > though, so redhat might have it too. > As a datapoint, none of the rh dists that i've tried (6.0, 6.1, 6.2 beta) have a listing or version string for autoconf >= 2.14. All of them are 2.13. -eric
Re: passing command-line switches to compiler
~ :> sure. it's Mandrake linux release 6.0, it's based on r.h. 6.0 package ~ :> though, so redhat might have it too. ~ :> ~ :As a datapoint, none of the rh dists that i've tried (6.0, 6.1, 6.2 ~ :beta) have a listing or version string for autoconf >= 2.14. All of ~ :them are 2.13. hmm.. So it's probably mandrake. I also have russian edition of the distribution (which I got from www.isl.ru guys during my last travel to Moscow last fall) so I am not really sure who brought updated version of autoconf into the distro.
Re: passing command-line switches to compiler
Date: Wed, 1 Mar 2000 02:59:56 +0500 (KGT) From: CyberPsychotic <[EMAIL PROTECTED]> AC_DEFINE_UNQUOTED([NEED_DECL_]translit($sn_decl, [a-z], [A-Z]), 1, [you have this cuz autoheader breaks things abit]) This won't work, because translit is an m4 construct, and $sn_decl is a shell variable. This will convert $sn_decl to $SN_DECL, and let the shell cope with that. My macro won't work if you call it with a shell variable, so you can't call it in a loop. ~ : When used in ~ :BFD, where it is an AC_DEFUN, the $1 is replaced at the m4 level, so ~ :the shell never sees it. that is what I would expect it too. Maybe m4/autoconf versions differ. >From what I have seen in configure, these things were not replaced but rather passed as shell variables. The $1 presumably was replaced at the m4 level, but that just resolved it into a shell variable. ~ :In any case, you may want to just pick up the macro that Akim ~ :mentioned that is in the current sources, and use that until the next ~ :autoconf release comes out. well, the problem here is that we have a few developers working on the project (cvs), so if I upgrade and use these macros, the other developers wouldn't be able to generate configure scripts until they upgrade. it would make a good sence to upgrade in long run anyway, but it would take some time, so I placed the macro (shown up above) as temporal solution until everyone in our team would upgrade his autoconf package. Sorry, I wasn't suggesting that you upgrade to a new version of autoconf. I was suggesting that you pick up the new macro, and put it in your acinclude.m4 file, just as you are doing with my macro. If you rename it, you will avoid any conflicts with future autoconf releases. Ian
Re: passing command-line switches to compiler
On 29 Feb 2000 out of nowhere Ian Lance Taylor spoke: ~ : ~ :I don't know what sort of playing around you were doing. here's exact piece which I made based on the macro you suggested: AC_DEFUN(SN_CHECK_DECL,[ AC_MSG_CHECKING([whether $1 must be declared]) AC_CACHE_VAL(sn_cv_decl_needed_$1, [AC_TRY_COMPILE([ #include #ifdef HAVE_STRING_H #include #endif #ifdef HAVE_STRINGS_H #include #endif #ifdef HAVE_STDLIB_H #include #endif #ifdef HAVE_UNISTD_H #include #endif #include #include #ifdef HAVE_SYSLOG_H #include #endif ], [char *(*pfn) = (char *(*)) $1], eval "sn_cv_decl_needed_$1=no",eval "sn_cv_decl_needed_$1=yes")]) if eval "test \"`echo '$sn_cv_decl_needed_'$1`\" != no"; then AC_MSG_RESULT(yes) ifelse([$2], , :, [$2]) else AC_MSG_RESULT(no) ifelse([$3], , ,[$3]) fi ])dnl AC_DEFUN(SN_CHECK_DECLS, [for sn_decl in $1 do SN_CHECK_DECL($sn_decl, [ AC_DEFINE_UNQUOTED([NEED_DECL_]translit($sn_decl, [a-z], [A-Z]), 1, [you have this cuz autoheader breaks things abit]) $2], $3)dnl done ]) SN_CHECK_DECLS(printf fprintf syslog puts putc fputs fputc fopen \ vsnprintf strtoul) and it was breaking in: eval "sn_cv_decl_needed_$1=no",eval "sn_cv_decl_needed_$1=yes")]) (it had extra spaces before sn_cv_decl_needed_$1, so configure was giving `sn_cv_decl_needed_symbol=no: command not found') if eval "test \"`echo '$sn_cv_decl_needed_'$1`\" != no"; then and here, if I placed just $sn_cv_decl_needed_$1 !=no, it always was true because $sn_decl_needed_$1 was equal to "$sn_decl_needed_" (which was empty) and $1 which was symbol itself. ~ : When used in ~ :BFD, where it is an AC_DEFUN, the $1 is replaced at the m4 level, so ~ :the shell never sees it. that is what I would expect it too. Maybe m4/autoconf versions differ. >From what I have seen in configure, these things were not replaced but rather passed as shell variables. ~ :Perhaps the same issue arises with autoheader. At least for me, ~ :autoheader works fine, and I get entries like this: ~ :/* Define if malloc is not declared in system header files. */ ~ :#undef NEED_DECLARATION_MALLOC yes. if replacement takes place when m4 preprocesses it, it should work. oddly in my case it didnt. ~ :In any case, you may want to just pick up the macro that Akim ~ :mentioned that is in the current sources, and use that until the next ~ :autoconf release comes out. well, the problem here is that we have a few developers working on the project (cvs), so if I upgrade and use these macros, the other developers wouldn't be able to generate configure scripts until they upgrade. it would make a good sence to upgrade in long run anyway, but it would take some time, so I placed the macro (shown up above) as temporal solution until everyone in our team would upgrade his autoconf package. -- Key fingerprint = 4422 16FC 3C7D E10A B044 CA4F 2BE0 3943 9758 9324 http://www.kalug.lug.net/fygrave/
Re: passing command-line switches to compiler
~ : ~ :This won't work, because translit is an m4 construct, and $sn_decl is ~ :a shell variable. This will convert $sn_decl to $SN_DECL, and let the ~ :shell cope with that. oops.. yep. Noticed that :-\ Thanks. ~ :My macro won't work if you call it with a shell variable, so you can't ~ :call it in a loop. yeah, also figured it out just now :) ~ : that is what I would expect it too. Maybe m4/autoconf versions differ. ~ : >From what I have seen in configure, these things were not replaced but ~ : rather passed as shell variables. ~ : ~ :The $1 presumably was replaced at the m4 level, but that just resolved ~ :it into a shell variable. yes. That is what I have seen there. ~ : ~ :Sorry, I wasn't suggesting that you upgrade to a new version of ~ :autoconf. I was suggesting that you pick up the new macro, and put it ~ :in your acinclude.m4 file, just as you are doing with my macro. Opps.. I didn't know about it. I usually place macros into configure.in or some randomly named file and then do `include(./filename.m4)' from configure.in. Would it make difference if I name file `acinclude.m4'? ~ : If ~ :you rename it, you will avoid any conflicts with future autoconf ~ :releases. ~ : Yeah, I will probably go for it, thanks.
Re: passing command-line switches to compiler
Date: Wed, 1 Mar 2000 03:29:17 +0500 (KGT) From: CyberPsychotic <[EMAIL PROTECTED]> ~ :Sorry, I wasn't suggesting that you upgrade to a new version of ~ :autoconf. I was suggesting that you pick up the new macro, and put it ~ :in your acinclude.m4 file, just as you are doing with my macro. Opps.. I didn't know about it. I usually place macros into configure.in or some randomly named file and then do `include(./filename.m4)' from configure.in. Would it make difference if I name file `acinclude.m4'? autoconf will automatically include any macros you put in aclocal.m4. No need for the include. If you use automake, it includes an aclocal program which builds aclocal.m4 for you; in that case, you put your own macros into acinclude.m4. Ian
config.* files via FTP
These files are now checked out and placed in: ftp://ftp.gnu.org/pub/gnu/config/ You can use this as a means of getting the latest versions if you'd rather not bother with anonymous CVS. Ben
