Re: Putting exact text in a define
On Tue, Nov 21, 2000 at 05:23:08PM -0500, Town, Brad wrote: > I've searched Google and the mailing list for help on this to no avail. > Perhaps someone can help me. (I'm using Autoconf 2.13 with Cygwin.) > > How can I add a define to a Makefile such as this: > > ... -DCONFIG_DIR=$(sysconfdir) > > The thing I thought would work in configure.in: > AC_DEFINE(CONFIG_DIR, "$(sysconfdir)") > > What it produced in the Makefile: > -DCONFIG_DIR=\"\$$\(sysconfdir\)\" See AC_DEFINE_UNQUOTED.
Re: CONFIG_FILES testing on QNX 4.2.5
On Wed, Nov 29, 2000 at 11:00:31AM -0800, David Morgan wrote: > Hi guys, Hi from home :) > The config_files problem is not: Sorry, I fixed that one later, it should be fixed now. I forgot there was this one pending when I first sent you the message. Sorry.
Re: expr ... and `expr ...` return different results on QNX 4.2.5
On Wed, Nov 29, 2000 at 11:23:19AM -0800, David Morgan wrote: > Hi folks, > > Thanks for the changes by including as_expr there is a problem with the test, > and/or another bug in QNX (I suspect). > > The code: > > expr a : '\(a\)' > echo $? > b=`expr a : '\(a\)'` > echo $b,$? > > Gives: > > a > 1 > a,0 Sorry, I was already inefficient I guess. It's the same bug as ASh's one reported by Pavel. I think you can safely change the as_expr test into if expr a : '\(a\)' >dev/null; then as_expr=expr ekse as_expr=false fi I made the test more complex than needed :(
Re: AC_OBJEXT again
On Tue, Dec 12, 2000 at 07:30:05PM +0100, Akim Demaille wrote:
>
> Alexandre> Such a cross-compiler would be a broken compiler. I don't
> Alexandre> know of any such cross-compilers, so this point is moot.
>
> Ah!!! Then you are telling me we just don't care about __CYGWIN32__
> etc. Then that's fine with me, that's all I wanted to hear. All we
> want to know is the default extensions used by the compiler. Fine.
>
Here is my proposal.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
EXEEXT and OBJEXT don't need to know $CYGWIN etc.
* acspecific.m4 (AC_EXEEXT, AC_OBJEXT, _AC_EXEEXT, _AC_OBJEXT):
Move as...
* aclang.m4 (AC_EXEEXT, AC_OBJEXT, _AC_COMPILER_EXEEXT)
(_AC_COMPILER_OBJEXT): these.
(_AC_COMPILER_EXEEXT): Use _AC_LINK_IFELSE.
Don't depend upon $CYGWIN and the like.
(_AC_COMPILER_OBJEXT): Model after _AC_COMPILER_EXEEXT.
Skip more extensions.
Use _AC_COMPILE_IFELSE.
Index: aclang.m4
--- aclang.m4 Tue, 12 Dec 2000 20:23:51 +0100 akim (ace/b/32_aclang.m4 1.5.3.54 644)
+++ aclang.m4 Tue, 12 Dec 2000 21:05:26 +0100 akim (ace/b/32_aclang.m4 1.5.3.54 644)
@@ -613,11 +613,11 @@ AC_DEFUN_ONCE([AC_NO_EXECUTABLES],
[m4_divert_push([KILL])
AC_BEFORE([$0], [_AC_LANG_COMPILER_WORKS])
-AC_BEFORE([$0], [_AC_EXEEXT])
+AC_BEFORE([$0], [_AC_COMPILER_EXEEXT])
m4_define([_AC_LANG_COMPILER_WORKS], [cross_compiling=maybe])
-m4_define([_AC_EXEEXT], [EXEEXT=])
+m4_define([_AC_COMPILER_EXEEXT], [EXEEXT=])
m4_define([AC_LINK_IFELSE],
[AC_FATAL([All the tests involving linking were disabled by $0])])
@@ -626,6 +626,86 @@ m4_define([AC_LINK_IFELSE],
])# # AC_NO_EXECUTABLES
+
+# - #
+# Computing EXEEXT and OBJEXT. #
+# - #
+
+
+# Files to ignore
+# ---
+# Ignore .d files produced by CFLAGS=-MD.
+#
+# On UWIN (which uses a cc wrapper for MSVC), the compiler also generates
+# a .pdb file
+#
+# When the w32 free Borland C++ command line compiler links a program
+# (conftest.exe), it also produces a file named `conftest.tds' in
+# addition to `conftest.obj'
+
+
+# We must not AU define them, because autoupdate would them remove
+# them, which is right, but Automake 1.4 would remove the support for
+# $(EXEEXT) etc.
+# FIXME: Remove this once Automake fixed.
+AC_DEFUN([AC_EXEEXT], [])
+AC_DEFUN([AC_OBJEXT], [])
+
+
+# _AC_COMPILER_EXEEXT
+# ---
+# Check for the extension used for executables. It compiles a test
+# executable. If this is called, the executable extensions will be
+# automatically used by link commands run by the configure script.
+#
+# This macro is called by AC_LANG_COMPILER, the latter being required
+# by the AC_LINK_IFELSE macros, so use _AC_LINK_IFELSE.
+m4_define([_AC_COMPILER_EXEEXT],
+[AC_CACHE_CHECK([for executable suffix], ac_cv_exeext,
+[_AC_LINK_IFELSE([AC_LANG_PROGRAM()],
+[# If both `conftest.exe' and `conftest' are `present' (well, observable)
+# catch `conftest.exe'. For instance with Cygwin, `ls conftest' will
+# work properly (i.e., refer to `conftest.exe'), while it won't with
+# `rm'.
+for ac_file in `ls conftest.exe conftest conftest.* 2>/dev/null`; do
+ case $ac_file in
+*.$ac_ext | *.o | *.obj | *.xcoff | *.tds | *.d | *.pdb ) ;;
+*) ac_cv_exeext=`expr "$ac_file" : 'conftest\(.*\)'`
+ break;;
+ esac
+done],
+ [AC_MSG_ERROR([cannot compute EXEEXT: cannot compile and link])])
+rm -f conftest$ac_cv_exeext])
+AC_SUBST([EXEEXT], [$ac_cv_exeext])dnl
+ac_exeext=$EXEEXT
+])# _AC_COMPILER_EXEEXT
+
+
+# _AC_COMPILER_OBJEXT
+# ---
+# Check the object extension used by the compiler: typically `.o' or
+# `.obj'. If this is called, some other behaviour will change,
+# determined by ac_objext.
+#
+# This macro is called by AC_LANG_COMPILER, the latter being required
+# by the AC_COMPILE_IFELSE macros, so use _AC_COMPILE_IFELSE.
+m4_define([_AC_COMPILER_OBJEXT],
+[AC_CACHE_CHECK([for object suffix], ac_cv_objext,
+[_AC_COMPILE_IFELSE([AC_LANG_PROGRAM()],
+[for ac_file in `ls conftest.o conftest.obj conftest.* 2>/dev/null`; do
+ case $ac_file in
+*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb ) ;;
+*) ac_cv_objext=`expr "$ac_file" : '.*\.\(.*\)'`
+ break;;
+ esac
+done],
+ [AC_MSG_ERROR([cannot compute OBJEXT: cannot compile])])
+rm -f conftest.$ac_cv_objext])
+AC_SUBST([OBJEXT], [$ac_cv_objext])dnl
+ac_objext=$OBJEXT
+])# _AC_COMPILER_OBJEXT
+
+
# #
# 3b. The C compiler. #
# #
@@ -752,8 +832,8 @@ AC_DEFUN([AC_PROG_CC],
_AC_LANG_COMPILER_WORKS
_AC_LANG_COMPILER_GNU
GCC=`test $ac_compiler_gnu = yes && echo yes`
-AC_EXPAND_ONCE([_AC_OBJEXT])
-AC_EXPAND_ONCE([_AC_EXE
Re: More exit() troubles - the answer
Thanks Lars, it's great!
Re: Not-really-cross-compilation issues
On Sat, Jan 20, 2001 at 12:22:58AM +0100, Peter Eisentraut wrote: > I've created a simple shared library that I placed at a non-standard > location for illustration purposes. Imagine I want to configure a package > to link against that library: > > $ cat configure.in > AC_INIT(.) > > AC_PROG_CC > > AC_OUTPUT > > # With Autoconf 2.13: > > $ LIBS='-L/tmp/obscure -ltest' ./configure > creating cache ./config.cache > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > checking whether the C compiler (gcc ) is a cross-compiler... yes > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > updating cache ./config.cache > creating ./config.status > > (everything okay) > > # With Autoconf 2.50-to-be: > > $ LIBS='-L/tmp/obscure -ltest' ./configure > checking for gcc... gcc > checking whether the C compiler works... configure: error: cannot run C compiled >programs. > To enable cross compilation, use `--host'. Indeed... Could you try see what happened? For instance, what does that config.log contain?
Re: Shell crash on SunOS 4.1.3
Thanks. We must be hitting some internal size limitation I guess. I will apply the patch you suggest.
Re: [patch] remove config.status race condition
On Fri, Feb 23, 2001 at 02:54:06PM -0500, Pavel Roskin wrote: > > > Are you sure that $$ is always preserved across subshells? What it I > > > create conf$$ in a subshell but want to access it in the top level shell? > > > > Sorry, but I don't understand why you are referring to subshells here. > > If anyway we were actually playing with subshells, we'd be in trouble > > to have the subshell pass relevant information to the mother, who is > > the one who wants information. > > Unless you are using files with known names. > > > Please develop. > > Maybe it's too primitive, but I hope you will get the idea: > > ( > # Do it in subshell to avoid saving all variables > cat >conf$$.c < $1 > EOF > CFLAGS="$CFLAGS -fnord" > LIBS="$LIBS -lol" > $CC $CFLAGS $LIBS -o conf$$ conf$$.c > ./conf$$ >conf$$.val > rm -f conf$$ conf$$.c > ) > ac_result=`cat conf$$.val` > rm -f conf$$.val So, I have been underspecific. In mean in the context of Autoconf. I just don't care about m4sh.m4 *at all*, the point is Autoconf, preiod. My question is where do you think the subshell issue matters at all for the present problem. We have one issue, and only one: relasing Autoconf. Everything else is pleasant but up to the current date useless, M4sh is *not* released, it is just a detail of Autoconf's implementation. If you can see a problem *in Autoconf*, please make it clear. If there are no problem with Autoconf, then there are no problems at all.
Re: [patch] remove config.status race condition
On Sat, Feb 24, 2001 at 01:08:29PM -0500, Pavel Roskin wrote: > > Feel free to use conf$$. I have nothing to conf$$, I'm a nice guy :)
Re: Ultrix autotest/autoconf problem
A first quick reading seems to demonstrate you found a flow in the test suite itself, we should not conditionally run tests. Better have them be skipped. Thanks, I'll keep you informed!
Re: where can I find "acmkdir" utility?
On Fri, Mar 16, 2001 at 01:48:45PM -0700, Daniel Herrington wrote: > Well, the subject says it all. I'm trying to learn to use the > autotools, but the mysterious "acmkdir" utility is nowhere to be > found. I've downloaded autoconf, automake, and libtool. What is it? Where did you read about it?
Re: AC_LIBOBJ_DECL?
On Thu, Apr 12, 2001 at 11:21:03PM -0400, Steven G. Johnson wrote: > This macro is documented in the manual but I can't seem to find it in the > source. Is it obsolete? Well spotted! It's now AC_LIBSOURCES([foo.c, bar.c]).
Re: AC_CANONICAL_HOST called behind my back?
On Sat, May 12, 2001 at 01:47:32PM -0700, Mo DeJong wrote: > > My point was that the 2.13 version of AC_CYGWIN did > not require AC_CANONICAL_HOST. By adding that AC_REQUIRE() > we are breaking configure.in files that do not use > AC_CANONICAL_HOST. I am saying that the AC_CYGWIN macro > should at least try to be backwards compatible in > this respect. Telling people to add AC_CANONICAL_HOST > along with install.sh, config.guess, and config.sub > is not really an option. I think it is. You are referring to bugward compatibility again, AC_CYGWIN from the start, should not have been any different from the other host: config.guess and config.sub. Adding config.guess and config.sub to your project does not sound like a monstruous bug to me. Adding dedicated code to Autoconf when there is a mainstream strategy sounds like one to my ears. I understand it is inconvenient to you, and I'm sympathetic to your complain, nonetheless, please, think to the actual problem and wonder whether you'd have complained if 2.13 was like this from the start.
Re: m4_shift does not work
On Wed, Aug 01, 2001 at 02:59:53PM +0100, Roger Leigh wrote: > In autoconf-2.13, shift was explicitly undefined in acgeneral.m4. > In 2.50 it seems to be renamed to m4_shift, and there is also > m4_shiftn in m4sh.m4. However, I can't seem to be able to use > either of these macros myself: > > AC_DEFUN([AC_CONFIG_LIBCONFIG_MODULES], > ifelse([$1], , , > [AC_CONFIG_LIBCONFIG_MODULE([$1]) > echo "1 = [$1]" > echo "2 = [$2]" > echo "3 = [$3]" > echo "@ = [$@]" > echo "shift@ = m4_shift($@)" > dnl AC_CONFIG_LIBCONFIG_MODULES(m4_shift($@)) > ])) Quote your definition body. > Another issue I have encountered is that in 2.13, I used > AC_DIVERT_PUSH(AC_DIVERSION_NOTICE)dnl and > AC_DIVERT_POP()dnl > around code that I wanted before the AC_ARG_WITH and AC_ARG_ENABLE > macros, so I could use variables in the option descriptions (for > defaults). Is it still possible to do this? Simply replacing > AC_DIVERSION_NOTICE with '1' did not help. Sorry, this is not precise enough for me to understand the request. Are you referring to sh variables? Anyway, the diversion are internals only, the user must not use them. We'll have to find another means to do what you want.
Re: m4_shift does not work
On Fri, Aug 03, 2001 at 10:01:42PM +0100, Roger Leigh wrote: > On Thu, Aug 02, 2001 at 11:07:21PM +0200, [EMAIL PROTECTED] wrote: > > On Wed, Aug 01, 2001 at 02:59:53PM +0100, Roger Leigh wrote: > > > In autoconf-2.13, shift was explicitly undefined in acgeneral.m4. > > > In 2.50 it seems to be renamed to m4_shift, and there is also > > > m4_shiftn in m4sh.m4. However, I can't seem to be able to use > > > either of these macros myself: > > > > Quote your definition body. > > Oops. Thanks, it works fine now. However, I now have a similar > problem with m4_ifelse and m4_translit etc.: > > AC_DEFUN([AC_CONFIG_LIBCONFIG_IN],[# create a custom library-config file ($1-config) > L=`echo m4_ifelse($1, , $PACKAGE, $1)` > > I do quote the definition body here, but autoconf gives the error: > > configure:2705: error: possibly undefined macro: m4_ifelse > > (the macro is not expanded, but plain `ifelse' is). s/m4_ifelse/m4_if/. I'll answer your other question later :) Gotta sleep.
Re: m4_shift does not work
> > L=`echo m4_ifelse($1, , $PACKAGE, $1)` Quote! m4_default([$1], [$PACKAGE])
Re: m4_warn test fails, removing autom4te.cache helps
On Sat, Aug 04, 2001 at 12:28:43PM -0400, Pavel Roskin wrote: > > Removing autom4te.cache between autoconf invocations fixes the test, but I > believe that the actual problem is in autoconf, not in the test. Please, see the related patches in autoconf-patches. I'm not sure what to do here.
Re: m4_warn test fails, removing autom4te.cache helps
On Sun, Aug 05, 2001 at 03:56:07AM -0400, Pavel Roskin wrote: > Hi, Akim! > > > > Removing autom4te.cache between autoconf invocations fixes the test, but I > > > believe that the actual problem is in autoconf, not in the test. > > > > Please, see the related patches in autoconf-patches. I'm not sure what > > to do here. > > I personally don't feel good about caching, especially if it brings > problems that are hard to solve. I don't think they are that hard to solve, well, at least up to now. They are challenging :) And since I really believe the future is in traces, it's important, IMHO. A lot of the GNU build tools will depend on them, and currently autoconf is way t slow > I don't want you to spend your precious time fixing and improving trace > caching - your time outweighs the time saved in all autoconf and > autoheader invocations across the world. :) Thanks for your kinds words. Byt you know, OTOHG, I really need to get some pleasure from time to time. Merely fixing bugs, trying to explain things etc. is exhausting :( It's yet noather of those periods where I'm ready to drop the maintenance... Existenctial questions (was I right) and this kinda stuff. Still, today, I would like to promote Autotest, M4sh (with the addition of Ad'HoC and so on), so I still have some faith. I don't want to leave before autosystem and specializing macros. > Maybe you could disable autom4te.cache by default (like config.cache) and > play with it when you want to, not when the testsuite fails. Maybe we will for the release, but I believe our community is ready to experiment. And conversely, I believe the current failures, and the other problems I envision are really benign. I don't think missing some warnings on the second run when you changed your -W is a bad failure (that's what the failure is actually saying). I'm having some piece of fun with M4 currently, trying to understand the slowness of Autoconf. I equipped my copy of M4 with dumpstat which counts the number of invocations of a macro. I include the results below for information. Guess what macro is the most used... It's fun :) But I hardly believe it's the slowest macro. I would like to implement profiling in M4, but my knowledge is poor (I don't even know how to get some precise time from the system, counting by second is certainly not fine enough, and worse yet, I don't even have the slighest idea of how to get durations that are not penalized by the profiling itself. Actually, I don't even know if that matters, maybe the figures comprising the profiling itself is relevant enough to understand where the heck we are losing that much time. I do have my idea: the call stack. Once I'm sure that's the culprit, I will proceed and implement in M4, hoping that some day more services from M4 will help us run a better Autoconf. BTW, it helped me discoever some M4 1.4p bugs, and worse yet, some incompatibilities that would break the current Autom4te based system :( ). Here are the figures on the Fileutils. Bad news: it does use syscmd, to `test -f' the presence of regex.h in the package. Bummer. dnl: 198920 invocations m4_shift: 119196 invocations m4_ifdef: 88623 invocations m4_builtin: 57043 invocations m4_if: 48845 invocations m4_ifndef: 47377 invocations m4_define: 32184 invocations m4_pushdef: 27215 invocations m4_popdef: 27210 invocations m4_defn: 18459 invocations m4_eval: 15327 invocations m4_ifval: 14054 invocations __line__: 12649 invocations __file__: 12649 invocations m4_car_quoted: 11610 invocations _m4_divert: 11451 invocations m4_provide: 9733 invocations m4_regexp: 7066 invocations m4_expansion_stack_push: 7026 invocations m4_expansion_stack_pop: 7026 invocations m4_indir: 6698 invocations m4_patsubst: 6649 invocations _m4_foreach_quoted: 6305 invocations len: 5752 invocations m4_divert_push: 5535 invocations m4_divert_pop: 5533 invocations _m4_divert(GROW): 5496 invocations m4_location: 5387 invocations _m4_defun_pro: 5387 invocations _m4_defun_epi: 5387 invocations AC_PROVIDE: 4202 invocations AS_LITERAL_IF: 3852 invocations m4_default: 3797 invocations AS_MESSAGE_LOG_FD: 3648 invocations m4_provide_ifelse: 3520 invocations _m4_shiftn: 3042 invocations m4_n: 1770 invocations m4_ifvaln: 1770 invocations AS_ESCAPE: 1660 invocations m4_translit: 1524 invocations m4_require: 1449 invocations m4_changequote: 1428 invocations _AS_ECHO_UNQUOTED: 1350 invocations m4_len: 1323 invocations _AS_QUOTE_IFELSE: 1318 invocations _AS_QUOTE: 1318 invocations AS_MESSAGE_FD: 1195 invocations _AC_LANG: 1158 invocations m4_car: 1047 invocations m4_shiftn: 963 invocations m4_assert: 963 invocations AS_IF: 868 invocations AS_VAR_GET: 835 invocations _AC_LANG_DISPATCH: 821 invocations _AS_ECHO: 720 invocations m4_split: 714 invocations m4_strip: 699 invocations m
Re: Serious breakage in CVS autoconf tree on case-insensitive filesystems
On Wed, Aug 08, 2001 at 06:43:00PM +0200, Tim Van Holder wrote: > I should have noticed this earlier, but it's been a while > since I last updated the CVS tree. > I just updated it and ran into an annoying problem: there is both a > lib/Autoconf and a lib/autoconf directory. This is not possible on > case-insensitive filesystems (like DOS and Win32), so CVS tries to > lump them all together. This results in both the typical "move away > Makefile.in, it is in the way" problems, as in "cannot find revision > control file for lang.m4" (because it looks for lib/Autoconf/lang.m4,v). In fact, I realized that latter on, and changed that, but I suppose the mere presence of Autoconf (now renamed Autom4te) on the CVS repo is enough to be a problem. Could someone ask the subversion team to completely get rid of lib/Autoconf/ please? As if it had never existed. > Since Struct.pm is shared between autoconf and automake, couldn't you > use lib/AutoTools/Struct.pm instead (both for autoconf and automake)? > Or you could use some other method for resolving this conflict (say, > using share/autoconf for the m4 files). As it stands, autoconf won't > be able to build at all on a DOS or Win32 system (and any other system > with a case insensitive filesystem). Well I thought about this several times, which is also why there is Autom4te/General.pl which contains subs that Automake should use. But I fear compatibility issues in future releases. IMHO, they should share the same sources when being developped, but not when being installed.
Re: RFI: Trailing blanks
On Fri, Aug 17, 2001 at 11:50:24PM +0100, Gary V. Vaughan wrote: > On Friday 17 August 2001 4:49 pm, Akim Demaille wrote: > > Typically, one can observe that the Autotest snippet contain useless > > multiple empty lines, which are to be killed, while those in the test > > values have to be kept. > > > > So I would like to remove that --normalize, completely replaced with > > @""@. Does it sound OK to everybody? :( :( :( That's not the end of the story, unfortunately... Well, consider the following problem: sometimes we want to output user supplied strings with say echo, whatever. But then, we have to escape some characters when embeded in double quotes. So... guess what... Something like AC_MSG_RESULT(@""@) outputs @\"\"@, not @""@. So the quadrigraph is not recognized, and not replaced. I'm not in favor of also replacing @\"\"@, but just because it frightens me a bit. If someone is convinced this is OK, then I'm OK. So we are looking for specially non special characters. @__@? > This solution looks good to me. However, I also wonder whether it would be > more transparent if the `smashing' code were to know about here documents > and test files? Blank lines in such strings could be left untouched. i very much agree! That's definitely what I would like most, but this means you need some form of `eval' in M4 which performs the expansion as if you were at the top level, and after this expansion, add those @""@ at the end of each line. And one such `eval' is almost impossible to write. Well, you can, but then what is it semantics wrt side effects? wrap, define, divert and so on. I once dreamt of it, but I can't see how it would fit with the semantics of M4. Another possibility would be sort of autom4te pragma lines #smash: off some multiple empty lines #smash: on Heeelp!
RFC: Autom4te: defining M4 sets
There are still problems to solve with Autom4te (considered as a package with a set of M4 files, hence the capitalization). One of them is that I don't know how to extend it properly to M4 libraries. Currently running autom4te -I /usr/share/autoconf autoconf/autoconf.m4f aclocal.m4 configure.ac -o configure is the same as running autoconf. To create an Autotest script, run autom4te -I /usr/share/autoconf autotest/general.m4 testsuite.at -o testsuite and so on. Ideally, we should not need wrapper scripts such as `autoconf' or `autotest' which sole purpose today consists in knowing `autoconf => -I /usr/share/autoconf autoconf/autoconf.m4f aclocal.m4', and `autotest => -I /usr/share/autoconf autotest/general.m4'. So I'd like to encode this knowledge into autom4te, so that one could run autom4te testsuite.at or autom4te configure.ac or autom4te --mode=autoconf some-weird-input-name.yy -o configure and have the right thing happen. But I would also like to make it user extendible, i.e., it should be hard coded in autom4te, rather it should be defined in files. I'd like three such files: one in pkglibdir defining the standard libraries, one in $HOME for user global extensions, and one in cwd for specific package extensions. Now the actual question is how should these files look like? What must go in? 1. Globing Obviously, we need some form of globing on the input file: *.ac and configure.in map to Autoconf, *.at maps to Autotest and so on. 2. Set of lib files Autoconf = autoconf/autoconf.m4 (or .m4f) Autotest = autotest/general.m4 M4sh = m4sugar/m4sh.m4 3. Permission One thing that currently autom4te doesn't support is `chmod +x'ing its output, autoconf does it for configure for instance. I think I'll introduce a `-m MODE' option for the command line (or just `-x'?), but one problem is that a set of M4 files, depending whether you use --trace or not, yield completely different results. OTOH, I can't think of a place where a trace output would have to be executable, so maybe we could just ignore -m when --trace. 4. --initialization When tracing, using or not using the frozen files makes a difference (typically, tracing `define' with autoconf.m4f will not output the Autoconf macros since `define' is no longer executed). So we might need a means to say `when --initialization was passed, don't use the frozen files'. Hm, after all, this might be enough. 5. Preselected traces autom4te caches the traces. Say you run it asking `--trace foo', it will run m4. Ask for `--trace bar', it will run m4 again. In a third run, ask for `--trace bar --trace foo', it won't run m4, since it keeps an incremental list of trace requests. But it would be a pity to wait for autoheader and automake to be run to discover we are interested in AC_CONFIG_HEADER, AC_DEFINE etc. OT1H, and AC_SUBST, AM_INIT_AUTOMAKE etc. OTOH. Hence we want preselected traces, thus --preselect. 6. More? I'm sure there are more things to think about. Below is the current state of what I'd like to implement. I did not want to have some Perlism or even shism get into the syntax, so that moving to another language must remain easy. I still have doubts, for instance: globbing, or regex a` la PRCS? I enjoy the power of regex, they make it possible for the user to have her own special rules for some very specific paths. But there might be other problems I have not considered, so please, comment! -- # autom4te.cfg, generated from autom4te.in # -*- Makefile -*- # Autoconf. begin mode: "Autoconf" patterns: "*.ac" patterns: "configure.in" arguments: --include /usr/local/share/autoconf arguments: autoconf/autoconf.m4f arguments: --mode 755 # Wanted by autoheader preselect: AC_CONFIG_HEADERS AH_OUTPUT AC_DEFINE_TRACE_LITERAL # Wanted by Automake preselect: AC_SUBST AC_LIBSOURCE # Wanted by autoscan preselect: AC_CHECK_FUNCS preselect: AC_CHECK_HEADERS preselect: AC_CHECK_LIB preselect: AC_CHECK_TYPES preselect: AC_C_CONST preselect: AC_C_INLINE preselect: AC_DECL_SYS_SIGLIST preselect: AC_FUNC_ALLOCA preselect: AC_FUNC_CHOWN preselect: AC_FUNC_ERROR_AT_LINE preselect: AC_FUNC_FNMATCH preselect: AC_FUNC_FORK preselect: AC_FUNC_FSEEKO preselect: AC_FUNC_GETGROUPS preselect: AC_FUNC_GETLOADAVG preselect: AC_FUNC_GETPGRP preselect: AC_FUNC_LSTAT preselect: AC_FUNC_MALLOC preselect: AC_FUNC_MEMCMP preselect: AC_FUNC_MKTIME preselect: AC_FUNC_MMAP preselect: AC_FUNC_OBSTACK preselect: AC_FUNC_SETPGRP preselect: AC_FUNC_SETVBUF_REVERSED preselect: AC_FUNC_STAT preselect: AC_FUNC_STRCOLL preselect: AC_FUNC_STRERROR_R preselect: AC_FUNC_STRFTIME preselect: AC_FUNC_STRTOD preselect: AC_FUNC_UTIME_NULL preselect: AC_FUNC_VPRINTF preselect: AC_FUNC_WAIT3 preselect: AC_HEADER_DIRENT preselect: AC_HEADER_MAJOR preselect: AC_HEADER_STAT preselect: AC_HEADER_STDC preselect: AC_HEADER_SYS_WAIT preselect: AC_HEADER_TIME preselect: AC_PATH_X preselect: AC_PROG_AWK preselect: AC_PROG_CC preselect: AC_
Re: autogen on macosx/darwin
On Sat, Nov 03, 2001 at 12:29:47PM -0800, Bruce Korb wrote: > Todd Gureckis wrote: > > [[...]] the configure/automake seems unable to correctly > > generate the Makefiles. after running configure > > on my machine the Makefiles are empty. there is a message from sed in > > the ./configure output: > > > > configure: creating ./config.status > > config.status: creating Makefile > > sed: file /tmp/cs29575-17041/subs-1.sed line 37: Unterminated `s' command > [[...]] > > I have tried it using both the sed that Apple ships and with the GNU sed > > version 3.02. > > My guess is that the sed script has an unterminated `s' command. ;-) > The question is not, "Which version of sed do you have?", but > "Where is `configure' going awry in constructing the sed commands?" This is a well known problem. Remove all the CDPATH assignments from Automake's macros.
Re: Learning Autoconf
On Wed, Nov 07, 2001 at 07:49:28PM +, John Poltorak wrote: > > Yes, it does look useful, but it would be better if it included Autoconf > v2.50. > I would definitely buy the book if it did. I find your words quite rude! You don't seem to realize the amount of effort that was put in this, you will never find a better presentation of the Gang Of Three all together. It's doesn't matter the version of Autoconf, not that of Libtool, nor that Automake. You are expected to be a programmer, hence to be willing to learn the big picture, and then, we you hit details, to do and read the product's documentation. There will never ever a book as up to date as the documentation (hm, I should revise Autoconf's documentation ;). And that's simply not the goal. If I were you, I'd buy the book. And read it. And experience what is presented in it. Autoconf 2.5x is compatible with 2.13 if you write proper Autoconf, and this book advocates the right Autoconf writing. Hence, if you learn what they teach, you learn perfectly valid, nonobsolete, information. Let me emphasize it again. You will not find better material than this book to learn about the GNU Build System. You will never get better information about Automake, Autoconf, and Libtool v x.xx than in the respective documentation of v x.xx.
Re: proposed patch to re-execute "configure" with a LINENO-grokking shell
On Fri, Oct 05, 2001 at 05:40:00PM -0700, Paul Eggert wrote: > > From: Akim Demaille <[EMAIL PROTECTED]> > > Date: 04 Oct 2001 17:39:04 +0200 > > > > I also forgot to say that your code could use happily AS_PATH_WALK. > > OK, here's a revised patch that takes all your suggestions into > account. It's much shorter, as I decided to omit AC_PROG_SHELL for > now. This allows us to focus purely on LINENO issues, and not worry > about other POSIX shell features. Thanks Paul! Please, install.
Re: Am I using m4_patsubst and m4_regexp?
On Sat, Oct 13, 2001 at 06:55:19PM +0200, Roberto Bagnara wrote: > > Hi there, > > I have switched to the latest autoconf snapshot (2.52e, cvs-updated today) > and have tried hard to follow all the instructions for the upgrade. > I believe I am no longer using any deprecated feature, but I get > > $ autoreconf > configure.ac:21: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst > configure.ac:312: warning: do not use m4_regexp: use regexp or m4_bregexp > autoheader: `config.h.in' is unchanged You don't use it directly, it is Automake which does. It's only a warning, disregard it. If it is too troublesome, maybe I will turn it off. What Automake are you running? The bad guys are in header.m4.
Re: Am I using m4_patsubst and m4_regexp?
I forgot to say that of course next versions of Automake won't have this problem. Together with the spurious failures of cond5, maybe this deserves a 1.5.1?
Re: How to use cache variables
On Thu, Feb 07, 2002 at 03:06:59PM -0500, Thomas Dickey wrote: > On Thu, Feb 07, 2002 at 02:35:04PM +0100, Akim Demaille wrote: > > >> Anyway, there are so many scripts depending on these names, that > > >> whatever scheme will be chosen, we will keep them. > > > > Thomas> (such as AC_CHECK_LIB ;-) > > > > I must have lost the track here. Many people have asked for its > > modernization, but this precisely never happened because of backward > > compatibility issues. I guess you are referring to some change, but I > > can't remember which one. > > iirc, the first bug I spotted in 2.50 was that AC_CHECK_LIB had changed > the naming convention for the associated cache variable so that checks > for the same function in more than one library would no longer work. Actually, since the message exchange, I digged into a few bug reports, and fell onto a bug report about 2.50 (which was fixed them) that does seem to refer to what you meant. Indeed, there was a backward compatibility issue with AC_CHECK_LIB (and I apologize for it), but really, it was a bug, not something intentional. So, Thomas, maybe my subconscience is working for you and against me, but wrt that particular point, nothing was meant against AC_CHECK_LIB :)
Re: Autoconf 2.53 is released
On Fri, Mar 08, 2002 at 05:57:52PM -0800, Bruce Korb wrote: > Akim Demaille wrote: > > > > The Autoconf team is extremely pleased to announce Autoconf 2.53. We > > hope it will address your problems, and make your life easier. > > > - Double quoting macros > > AC_TRY_CPP, AC_TRY_COMPILE, AC_TRY_LINK and AC_TRY_RUN. > > FYI: this will teach me for upgrading without thorough testing. > I double quoted the program arguments like you said I should, > only to find that when I upgraded I was overquoted and it trashed > *my* release. In the future, I cannot recommend strongly enough > that when you change interfaces like this, CHANGE THE NAME, TOO! There must be some confusion here. The section of the NEWS file you are quoting here refers to the documentation changes: 2.53 documents what macros are double quoting (as oppposed to the rest of Autoconf), because we cannot change the interface for backward compatibility. Thanks.
Re: Bad configure scripts generated with Autoconf 2.52 and 2.53
On Mon, Apr 08, 2002 at 08:58:13AM -0400, Thomas E. Dickey wrote: > On 8 Apr 2002, Akim Demaille wrote: > > > >>>>> "Patrick" == Patrick Hartling <[EMAIL PROTECTED]> writes: > > > > Patrick> So I can't have a configure.in that works with 2.13 and 2.5x? > > > > Sure you can. > > it's just that you cannot count on that happening without some effort. I know few programming languages which accept programs ``without some effort.''
Re: Patch: gcc-3.0.4 workaround for AS_SPARC64_FLAG/autoconf-2.53
On Mon, Apr 08, 2002 at 08:44:44AM -0400, Thomas E. Dickey wrote: > On 8 Apr 2002, Akim Demaille wrote: > > > Actually, YMMV. It depdends how `lucky' you were. Given that the > > name of the macro to be defined was not quoted, the macro was > > expanded. In typical cases, it gave more argument to define than 2, > > hence an error. > > not really (I generally quote the argument of AC_DEFUN). Sorry, I didn't mean you, I was referring to the definition of AC_DEFUN itself, which used to use $1 (the macro name) without quoting it.
Re: Autom4te.cache
On Mon, Jul 29, 2002 at 11:13:14AM -0700, Dan Kegel wrote: > Alexandre Duret-Lutz wrote: > "Dan" == Dan Kegel <[EMAIL PROTECTED]> writes: > >>> > > > > Dan> The name, autom4te.cache, is quite cryptic. > > > >This directory is a cache for autom4te > > ... a tool which most autoconf users have never heard of, > and is only used deep within the new autoconf. Why > expose its name? Because it is documentation and has no vocation of being kept in the shadow of autoconf.
Re: autoconf is broken in various ways
Yipee,
Thanks Martin, it's been too long without huge controversial thread in
here. Foood fiiight!
>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes:
Martin> Did you know that Linux Mandrake 7.0's autoconf claims to be
Martin> version 2.14.1? (martin@wobble) /xemacs/build $ autoconf
Martin> --version Autoconf version 2.14.1
Grrr. I've even heard that even before I was member of the committee,
even before I ever ``publicly'' (i.e., here) talked of the pirate
Autoconf I was maintaining, an RPM packager took the copy he found in
my ftp dir, packaged it, and uploaded it to RedHat!
Now, there's a README-alpha which is rather explicit.
Martin> Did you know that this autoconf uses $SHELL instead of
Martin> ${CONFIG_SHELL-/bin/sh}?
Where?
Martin> This would fail in the most obvious way if the user's shell
Martin> was, say csh (untested).
Martin> My own SHELL is /bin/zsh,
I've always thought that peopling thinking and feeling like XEmacs
*must* run zsh. Seems like I was right :)
Martin> and this is sufficiently different from /bin/sh to cause it to
Martin> be unsuitable for a configure shell. You simply can't use
Martin> SHELL - that variable is reserved for the user's use.
Yes, you are right, but what use of SHELL are you refering to? CVS
Autoconf has
SHELL=${CONFIG_SHELL-/bin/sh}
which is harmless in your sense, and positive in our: we want to make
sure make is using the right shell.
Martin> 2.13 was a no-effort upgrade over 2.12. It doesn't look like
Martin> this will be true of 2.14.
We try to avoid this, but it was to be expected that people who partly
rewrite Autoconf have problems. I am surprised though.
Akim
Re: autoconf is broken in various ways
> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes:
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Martin> (XEmacs redefines AC_DEFINE)
Tom> Wow, why?
Martin> To support the --extra-verbose option
I don't have your failure.
/tmp % cat configure.in nostromo 9:07
dnl Redefine AC_DEFINE* to provide more output if extra_verbose
dnl Set VARIABLE to VALUE, verbatim, or 1.
dnl AC_DEFINE(VARIABLE [, VALUE])
define([AC_DEFINE],
[{ test "$extra_verbose" = "yes" && cat << \EOF
Defining $1[]ifelse($#, 2, [ = $2],)
EOF
cat >> confdefs.h <<\EOF
[#define] $1 ifelse($#, 2, [$2], 1)
EOF
}
])dnl AC_DEFINE
AC_INIT
cat >config.h.in <
Re: config.cache considered harmful
>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: Martin> I've ranted about config.cache before, but it's probably time Martin> again, because of the turnover of the maintainership here. Don't be afraid, we've been around for a few years too, and we know what you are talking about. We also know we agree on the problem, but not on the fix :) Martin> The config cache is _the_ most evil thing in autoconf. Oh no, there are plenty of others which are much worse :) Martin> The config,cache is friendly mostly to Cygnus employees, Martin> hostile to everyone else. Let's optimize for the newbies, not Martin> the pros. This is a sound I like :) But conversely I am extremely attached to provide the users of Autoconf (i.e., the maintainers), a good service: because there are the guys who most run ./configure, they deserve some comfort, such as caches. Martin> Your reaction might be, "Of course you're supposed to do `make Martin> distclean' before re-configuring", But this is an advanced Martin> thing that the newbie should not have to know. I agree on the problem, not on the solution. What Alexandre refers to seems a better approach to me. It should be on by default though. Martin> Let's think about when you would ever want to reuse a cache Martin> within a simple single GNU package. I claim you _never_ want Martin> to reuse that config.cache file sitting in your foo-1.9 Martin> directory. Why are you re-running configure, anyways, instead Martin> of just running `make'? Because the system has changed? Martin> Because configure.in has changed? In any of these cases we Martin> can't trust config.cache. Better to discard it than suffer Martin> the horrible consequences of a wrong guess. I can't think of Martin> any reason to re-run configure that doesn't leave the Martin> config.cache from a previous build untrustworthy. OK, I understand your reasoning. Let's push it to its end point, and forget about separate compilation too. Actually, dependencies are so often wrong in Makefiles, we've suffered so many times of slight inconsistencies due to a missing dependency, that I think we should have the target all depend on `clean' in all our Makefiles. :) Sorry, but I often rerun configure. Martin> I'm not proposing that the config.cache feature be removed, Martin> only that it not be made the _default_. If we can't reach an automatic solution which protects everybody from such failures, then I am all with you. For the time being I still hope we can make it without. I am not committed to death to cache files being the defaults. If they can safely be, let them be, otherwise, I know too well how some users suffer from this trap to require this behavior to be maintained. Martin> Another problem with the cache was that it can become invalid Martin> _during_ a single run of configure. Hm, obviously... But how come so few people ever complained about this? (Real question, not ironic). Akim
Re: config.cache considered harmful
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> Like: Alexandre> How about ``remove config.cache and re-run configure'', as Alexandre> printed by AC_VALIDATE_CACHED_SYSTEM_TUPLE? Why doesn't it suggest distclean? Why isn't it used by default? (we would remove the AC_REQUIRE([AC_CANONICAL_SYSTEM])dnl, of course). >> I'm not proposing that the config.cache feature be removed, only >> that it not be made the _default_. Alexandre> Sounds reasonable to me. How about only enabling it when Alexandre> given the option --cache-file=? Fine with me. Akim
Re: config.cache considered harmful
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: >> Is foo() in libbar? No? Try adding -L/usr/openwin/lib to the link >> path. How about now? Maybe try -L/usr/X11R6/lib instead? Alexandre> Yup, this is quite hard to implement with the feature Alexandre> currently offered by autoconf :-( Alexandre> The unfortunate side-effect of your proposal is that these Alexandre> tests would suddenly start working, *unless* someone used a Alexandre> cache file. Sorry, but I don't understand the relationship here. Whether there is a cache file or not changes nothing to the fact that if a test was performed then ac_cv was set, hence shadows a later test. Akim
Re: AC_CHECK_TYPE search locations
>>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: Paul>From: Akim Demaille <[EMAIL PROTECTED]> Date: 24 Feb 2000 Paul> 17:42:41 +0100 Akim> should we put stdint.h or inttypes.h into the default includes? Paul> inttypes.h. My question was badly asked, there was two actually: - I was suggesting to include more headers in ac_includes_default="\ #include #include #if STDC_HEADERS # include # include #else # if HAVE_STDLIB_H # include # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include # endif # include #else # if HAVE_STRINGS_H # include # endif #endif #if HAVE_UNISTD_H # include #endif" such as one of these two guys (more if people have suggestions) - and if yes, which one of these two (which is the answer you gave). So, do you think I should add inttypes.h? Thanks a lot for the pointers and details! Akim
Re: macro-writer macro up for adoption...
Hi Lars, | I've written a macro which makes it easier to write more flexible | autoconf-macros, and I thought some of you might find it interesting. It's interesting work which might be useful someday in Autoconf, but for now, I don't think we want to introduce ``complications''. In fact, we're trying to simplify the use of Autoconf, even if it means doing too much work. | Any comments? Yes, I have a few comments on your code which you might want to know. | define([$IM_STRING_COMPACT],[dnl | patsubst(patsubst([$1],[[ | ]+],[ ]),[^ \| $],[])]) This is wrong, you have two evaluation here (two patsubst), hence we need to quote twice. Your macro will certainly die if there are commas in $1, and will behaves incorrectly if $a happens to contains something which is a macro name. Also, it is (IMHO), a bad habit to use [dnl as you do. Some day, you will be trapped. define([$IM_STRING_COMPACT], [patsubst(patsubst([[$1]],[[ ]+],[ ]),[^ \| $],[])]) | define([$IM_STRING_WORDCOUNT_COMPACT],[dnl | builtin([eval],(1+len(patsubst([$1],[[^ ]+],[_])))/2)]) [[$1]] | define([$IM_DEFINE_VARIABLE],[dnl | dnl errprint([define( $1, $2 ) $ M4='m4 --trace $IM_DEFINE_VARIABLE -d' autoconf is a better means to trace SIM_PARSE_MODIFIER_LIST | dnl ])dnl | define([$1],[$2]) | ]) |[errprint([SIM_PARSE_MODIFIER_LIST: invalid variable (arg 3): "$2" You should give more details, such as __file__ and __line__. Or use libm4's m4_warn. | define([$IM_PUSHDEF_MODIFIERS],[dnl | ifelse(indir([$IM_STRING_WORDCOUNT_COMPACT],[$1]), Why do you `indir' all the time? Oh!, yes, it's a dollar, not an `S' :) Well, for legibility, it might be better that you reserve your name space and use it: _SIM_STRING_WORDCOUNT_COMPACT or something. | define([$IM_PARSE_MODIFIER_LIST],[dnl | pushdef([wordcount],builtin([eval],(indir([$IM_STRING_WORDCOUNT],[$2]dnl m4_eval is defined in CVS Autoconf, it's much easier to read. |[ifelse($4, , , $4)], Second $4 should be quoted. Akim
Re: AC_CHECK_TYPE search locations
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On Feb 25, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >> So, do you think I should add inttypes.h? Alexandre> It would be nice, because autoconf would detect the Alexandre> presence of certain standard types at configure time, but Alexandre> it could lead old packages, that don't explicitly include Alexandre> inttypes.h in their system.h to fail to find those types at Alexandre> build time. I don't understand what you mean. Anyway the include will be in its HAVE_, so unless configure.in checks for inttypes.h, it will change just nothing. Looking for it in configure.in but not using it in system is bizarre :) Alexandre> Maybe we should have a specialized AC_CHECK_HEADER for Alexandre> inttypes.h, that will add this header to the list of Alexandre> default headers. Eerk! Akim
Re: autoconf is broken in various ways
| Akim> Now, there's a README-alpha which is rather explicit.
|
| Martin> Did you know that this autoconf uses $SHELL instead of
| Martin> ${CONFIG_SHELL-/bin/sh}?
|
| Akim> Where?
|
| (martin@wobble) /usr/share/autoconf $ g -w SHELL acgeneral.m4
| acgeneral.m4:211:SHELL=${CONFIG_SHELL-/bin/sh}
| acgeneral.m4:699:AC_SUBST(SHELL)dnl
| acgeneral.m4:876:ac_config_guess="$SHELL $ac_aux_dir/config.guess"
| acgeneral.m4:877:ac_config_sub="$SHELL $ac_aux_dir/config.sub"
| acgeneral.m4:878:ac_configure="$SHELL $ac_aux_dir/configure" # This should be Cygnus
|configure.
| acgeneral.m4:2135:test "$no_create" = yes || $SHELL $CONFIG_STATUS || exit 1
| acgeneral.m4:2552: ac_sub_configure="$SHELL $ac_sub_srcdir/configure"
|
| I see. That original SHELL=${CONFIG_SHELL-/bin/sh} is in
| AC_INIT_PARSE_ARGS. Naturally I redefine that... OK, this is the
| price we have to pay.
I'm lost. You are saying we're right, XEmacs is wrong, right?
| I'll just redefine AC_PREREQ(2.13) to be a == test, not a <= test.
Why? Give us a chance to catch up. But first, tell us what use of
SHELL you do.
| The one feature I couldn't switch shells for is the autocd feature.
| If I type the name of a directory, I want to go there - what else can
| you do with a directory?
I don't know, rm -rf? :) I too love this feature.
Akim
Re: config.cache considered harmful
>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: Martin> But this is just a special case that will reduce the Martin> mismatches, but leave the most damaging mismatches (because Martin> the most confusing and misleading and most likely to be Martin> silent) to the end. I think we all agree Alexandre proposal is very acceptable. In addition, one just has to export cache_file=./config.cache to have what she was used to. Martin> My new vague proposal above would leave the config.cache used Martin> mostly for programs that were designed to be used together. I don't agree here (or I misunderstood your suggestion). The decisions belongs to the installer, period. She can use both $cache_file (we might discuss yet another envvar name, but I don't see much point here) and --cache-file to do what we wants, this seems enough to me. Martin> I shouldn't be admitting this, but it is possible to turn off Martin> the caching for a specific variable by just setting a Martin> particular shell variable. How??? I see a means with `unset', but it is not portable, so it is excluded. Akim
Re: macro-writer macro up for adoption...
Well, if you're brand new to m4, you're work is even more impressive :) >>>>> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: Lars> I figured that using illegal macro-names and indir'ing Lars> everything could help me avoid "accidental" macro-expansions and Lars> keep the sub-macros "local" in a sense (as described in the m4 Lars> texinfo doc). Didn't work well with AC_DEFUN though (automake autoconf Lars> can't handle macronames with special characters), so I had to Lars> use define() instead for those. Hm, that's probable, thought I wouldn't be surprised recent Autoconves behave better than before. Many quotes are missing in the core, in particular in AC_DEFUN several were missing. Lars> Another thing I'm wondering about; I wasn't able to use m4's Lars> expr() in autoconf without calling it through indir (but it eval I suppose Lars> works in plain m4) - what's the reason for that? Has it been Lars> renamed to m4_expr() or something? Renamed as m4_eval, because eval is a sh construct which is often used in Autoconf scripts. Akim
Re: macro-writer macro up for adoption...
>>>>> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: Lars> Wouldn't think that would be necessary (except for readability), Lars> unless you have some sh eval use that looks like the builting Lars> eval macro given arguments? Huh? Sorry, I don't understand. Are your referring to the fact that m4 builtins are recognized only with the proper number of argument, hence `eval' as used in sh will never be groked by m4? If so, personally, I don't trust this behavior too much, since I can't simulate it with `define' (yes, I can, but it's painful). So just for sake of simplicity, I think m4_eval is a perfectly good approach. Akim
Re: config.cache considered harmful
>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: Martin> I think I used `unset'. And XEmacs' configure uses `unset' Martin> today, and no one I know of has hit this non-portability. I claim that machines without Bourne shells supporting unset and functions are no longer to be considered. No single guy could name me such a broken machine. I'd really love that we move to functions some day. How about leaving an implicit test in Autoconf 2.15's configure, with a message such as `Please warn us that your machine does not support blah blah. This message is not a failure notice, the configuration went smooth, but your machine demonstrates there are things not to change in Autoconf'. Or whatever, you get the idea. Akim
Re: config.cache considered harmful
>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: Martin> system library updates, even user variables like a new setting Martin> for LD_RUN_PATH, and all those variables like CC, CFLAGS, Martin> LIBS, Autoconf is currently being equipped with a means to see if CFLAGS (or whatever variable) has changed between two runs, in order to complain. But this will work only with a cache... :) Martin> By the way, one of the programs I'm most proud of is the Martin> accurate C source dependency generator for XEmacs - it's Martin> src/make-src-depend - a perl script Maintainer side, or end user? Perl is not required downstream, and Automake is developing the same kind of efforts, but on the end side, so without Perl. I suppose the approaches should be compared. Checkout depcomp in CVS Automake. Martin> (does that match Akim's expectations of emacs maintainers)? Nope, src/make-src-depend.el would have made more sense ;) And BTW, I'm horrified to read that you name yourself an emacs maintainer :) :) Akim
Re: config.cache considered harmful
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes: Martin> I think I used `unset'. And XEmacs' configure uses `unset' Martin> today, and no one I know of has hit this non-portability. >> I claim that machines without Bourne shells supporting unset and >> functions are no longer to be considered. No single guy could name >> me such a broken machine. I'd really love that we move to >> functions some day. Lars> /bin/sh on Ultrix. Check out the list archives from April Lars> 1999. Tom Tromey mentioned that autoconf could adopt the Lars> "re-exec non-losing shell" approach by Metaconfig-generated Lars> scripts. So you appear to agree with me, though I admit the key word in my sentence was missing: *any* >> I claim that machines without *any* Bourne shell supporting unset >> and functions are no longer to be considered. No single guy could >> name me such a broken machine.
Re: config.cache considered harmful
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On Feb 25, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >> How about leaving an implicit test in Autoconf 2.15's configure, >> with a message such as `Please warn us that your machine does not >> support blah blah. Alexandre> I like this idea Yehaaa! :)
Re: config.cache considered harmful
>>>>> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
Ian> It's true that this machine has a shell /bin/sh5 which supports
Ian> unset. However, /bin/sh5 does not support shell functions.
Aarg, this is the information I was looking for.
Ian> The point of autoconf is portability to all machines, not just to
Ian> all recent machines.
Please, Ian, give me a little more trust. I'm looking for wrong
hypotheses, I'm not trying to make Autoconf selective.
Ian> This machine is a DECstation 3100 running Ultrix 4.0.
I'm really surprised it doesn't support functions, IIRC I've already
talked to someone about this precise architecture, and he told me that
the simple
#! /bin/sh5
foo(){ unset toto }
toto=tata
foo
echo "{$toto}"
did what was expected.
Still, the presence of unset is a big relief...
Akim
Re: config.cache considered harmful
| I did not mean to imply that I didn't trust you. I apologize for the
| implication.
I'm sorry for having inferred something which was not derivable :)
| However, I think we can all agree that there are machines which do not
| have shells which support functions. For example, SVR2 machines.
| Those machines are still running. Whether anybody runs autoconf
| generated configure scripts on them, I don't know. I've done it in
| the past, but not in the last several years.
I don't want to give the impression I don't trust your word here, but
I know by experience that in the Autoconf world there are many legends
and myths. I'd like to see someone really trying the various shells
on this machine and report the status of unset and of functions.
In addition, though I agree to be extremely oldish compatible, we
should not still fight for PDP11. Yet Autoconf, as we have recently
discovered is far from being really portable as compared to
Metaconfig. But in practice, AFAIK, *never* this has been reported.
| The fact that nobody on these mailing lists is reporting any old
| machines does not mean that they don't exist or that they aren't
| running.
Definitely not, hence my configure-embedded test-spy suggestion.
|#! /bin/sh5
|
|foo(){ unset toto }
|
|toto=tata
|foo
|echo "{$toto}"
|
|did what was expected.
|
|Still, the presence of unset is a big relief...
|
| Sorry, I was wrong, you're right. I was testing using the optional
| `function' keyword, which does not work, and I missed it in the man
| page because it doesn't use the keyword. Your example does work,
| after I add a semicolon after the `unset toto' and fix the last line
Arg, yes, sorry.
| to use ${toto}.
I meant to highlight the emptiness of toto :)
| So Ultrix /bin/sh5 does support functions. You would still want to
| put in the auto-reexec stuff.
Correct :)
| I personally don't really see why shell functions and unset matter
| much for autoconf proper. You can already use m4 and weird shell
| constructs to implement the same functionality (e.g., instead of
| unsetting a cache variable, set it to the empty string, and test for
| that when necessary). Sure, these features could make the configure
| (not configure.in) script much more attractive, but in an ideal world
| no ordinary person should have to look at the configure script.
| People do have to look at the configure script in practice, but this
| problem will not be solved by using unset or shell functions.
I have no intention to use big functions, but I must confess I'd enjoy
a verbose function, a mkdir function etc. I don't want
AC_CHECK_HEADER to turn into a function. Yet being able to use small
functions would help a lot.
But the fact that unset might be portable is completely different and
opens new horizons (the heck with CDPATH, LANG etc.).
Akim
Re: Integrating the macros of the archive?
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> There are two reasons: Tom> 1. We know the FSF site will stay around, whereas we know nothing Tom> about non-FSF sites. Hm... Sounds reasonable. Tom> 2. RMS doesn't even like to have links off the FSF site, as far Tom> as I can tell. I don't agree with this, but we did move the cvs Tom> repository for similar reasons. Being . once does not mean you have to be all the time. And actually here the thing is quite different IMO.
Re: config.cache considered harmful
>>>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> Because I want to try a different _configuration_: Pavel> CFLAGS=-ggdb3 ./configure --enable-cute-feature --without-bloat Pavel, we need evangelists for the new support of variables :) ./configure CFLAGS=-ggdb3 --enable-cute-feature --without-bloat Akim
Re: config.cache considered harmful
>>>>> "Olly" == Olly Betts <[EMAIL PROTECTED]> writes: Olly> It also saves a lot of time if you're using automake and doing Olly> work that involves changing your Makefile.am-s. Whenever one is Olly> modified, running make will run automake to update the Olly> corresponding Makefile.in, then rerun configure to produce a new Olly> Makefile from that Makefile.in. bad example :) Use `config.status src/Makefile'. No need for configure here. That's what Automake's Makefile do. Akim
Re: config.cache considered harmful
|I don't want to give the impression I don't trust your word here, but
|I know by experience that in the Autoconf world there are many legends
|and myths. I'd like to see someone really trying the various shells
|on this machine and report the status of unset and of functions.
|
| I've seen this argument before, but I don't entirely believe it.
| There is a lot of autoconf lore that is the result of people reporting
| problems. People then forget just what the problems were. But that
| does not mean that the problems were not real.
Yes, I agree. Maybe I'm giving the impression I feel that you didn't
trust me on this one while you may have but :)
Yes, of course I'm well aware there are real problems which mandated
weird solutions that I might understand today. But I can also show
you things which were programmed in a very bizarre way, which at first
sight was due to a portability issue, and actually were not.
I'm *extremely* cautious when touching Autoconf. I don't mean to
break something.
But, I'm also critic wrt not-established portability axioms. Trusting
blindly whatever piece of old code does not seem better to me than
trusting blindly new code. I'm talking of a balance.
| I've been using autoconf since the beginning, and I've used a lot of
| different Unix systems. If you have any specific questions, I'm
| willing to take a stab at them.
OK. Can you tell me why the heck the cache looks like this:
ac_cv_path_M4=${ac_cv_path_M4=/usr/bin/m4}
ac_cv_path_PERL=${ac_cv_path_PERL=/usr/bin/perl}
ac_cv_path_install=${ac_cv_path_install='/usr/bin/install -c'}
ac_cv_prog_AWK=${ac_cv_prog_AWK=mawk}
ac_cv_prog_gnu_m4=${ac_cv_prog_gnu_m4=yes}
ac_cv_prog_make_make_set=${ac_cv_prog_make_make_set=yes}
and not like this:
: ${ac_cv_path_M4=/usr/bin/m4}
: ${ac_cv_path_PERL=/usr/bin/perl}
: ${ac_cv_path_install='/usr/bin/install -c'}
: ${ac_cv_prog_AWK=mawk}
: ${ac_cv_prog_gnu_m4=yes}
: ${ac_cv_prog_make_make_set=yes}
| My SVR2 example was not arbitrary. I've run autoconf generated
| configure scripts on Z8000 based SVR2 systems. As of a couple of
| years ago, those systems were still running, and I don't know of any
| reason why they would not still be running today (well, I suppose they
| might have been replaced due to Y2K concerns). (Those systems are so
| old that they don't have setjmp/longjmp--they have a different
| mechanism, called setret/longret.)
Wow :) Never heard of these guys. Still, you didn't answer my
question: there are *no* shells on these machines which support
functions?
|In addition, though I agree to be extremely oldish compatible, we
|should not still fight for PDP11. Yet Autoconf, as we have recently
|discovered is far from being really portable as compared to
|Metaconfig. But in practice, AFAIK, *never* this has been reported.
|
| I guess I don't understand what you mean here. I probably just didn't
| read the messages. I mean, naturally nobody has reported that
| autoconf is being used on a system which does not support shell
| functions, because autoconf doesn't use shell functions.
Yep, but for instance Metaconfig does not use `#' for comments, but
`:', because it is not portable. And Autoconf's configure scripts
cannot run on Eunice, while Configure does. How Eunice and SVR2
compare in terms of age?
This is just a few examples. There is no doubt in my mind that
Metaconfig's Configure are more portable than Autoconf's configure,
there is no doubt in my mind that I don't care (until someone
convinces me `#' is hell).
Akim
Re: config.cache considered harmful
| Well, here is the relevant ChangeLog entry:
|
| Thu Feb 2 11:32:07 1995 David J. MacKenzie <[EMAIL PROTECTED]>
|
| * acgeneral.m4 (AC_CACHE_SAVE): Workaround Ultrix and 4.3BSD sh
| bug in setting the high bit on variable values.
| From Ken Raeburn.
|
| Ken Raeburn is [EMAIL PROTECTED], if you want to ask him about it.
Yep, thanks. I had found the ChangeLog entry, asked him, but had no
reply.
| I can replicate this bug on Ultrix with this shell script:
|
| rm -f foo.cache
| ac_cv_path_M4=/usr/bin/m4
| (set) 2>&1 |
| sed -n "s/^\([a-zA-Z0-9_]*_cv_[a-zA-Z0-9_]*\)=\(.*\)/: \${\1='\2'}/p" \
| >> foo.cache
| /bin/sh -c '
| . foo.cache
| echo $ac_cv_path_M4
| (set) 2>&1 |
| sed -n "s/^\([a-zA-Z0-9_]*_cv_[a-zA-Z0-9_]*\)=\(.*\)/: \${\1='"'"'\2'"'"'}/p" \
| >> foo.cache
| echo $ac_cv_path_M4
| cat -v foo.cache'
|
| On Ultrix, the output is this:
|
| /usr/bin/m4
| /usr/bin/m4
| : ${ac_cv_path_M4='/usr/bin/m4'}
| : ${ac_cv_path_M4='M-/M-uM-sM-rM-/M-bM-iM-nM-/M-mM-4'}
Aaaah, OK. I thought the ChangeLog meant the 8th bit was not
*preserved*. And I could not find a valid explanation to understand
why it would preserve something to assign twice instead of once :)
| This bug does not happen if I change the use of /bin/sh in the script
| to /bin/sh5, and invoke the script with /bin/sh5. In that case, I see
| this:
|
| /usr/bin/m4
| /usr/bin/m4
| : ${ac_cv_path_M4='/usr/bin/m4'}
| : ${ac_cv_path_M4='/usr/bin/m4'}
OK, thanks!
| Note that the ChangeLog entry indicates that this bug arises on the
| 4.3BSD shell as well. The BSD shells used to use the high bit to
| record information--that is, they were not eight bit clean.
Not being 8 bit clean is something I can understand. Here I wouldn't
call it even 7 bits clean.
| This was
| a problem with csh in particular for years. I'm pretty certain that
| 4.3BSD did not have a second shell like the Ultrix /bin/sh5. On the
| other hand, I don't know whether anybody still runs 4.3BSD.
On AIX the solution is bsh. I don't understand the point of having
several Bourne shells actually.
| That is correct: there are no shells on those machines which support
| functions. In those days machines only had one shell. Ultrix only
| has two shell programs because it is trying to merge BSD and Sysem V;
| /bin/sh is the BSD shell, and /bin/sh5 is the System V shell. Having
| two shells is just a holdover from the BSD/System V split. Presumably
| modern systems drop the two shells as they become POSIX.2 compliant.
This answers the previous question, and I guess it explains the `b' of
`bsh'.
| SVR2 came out in 1984. Eunice is a Unix simulator which runs on VMS.
| A little net spelunking reveals that it was around in 1982.
Hm, pretty comparable, but the difference is probably that there are
few VMS machines today.
| I just checked Horton's Portable C Programming. He says ``There have
What is it? A book?
| been some features added to the Bourne shell since V7 that are not
| portable. These include the : operator used with parameter expansion:
| ${x:-y} and the use of # for comments. Systems derived from V7, such
| as 4BSD, do not support these features. The test or [ commands also
| vary from system to system.''
OK. Thanks a lot Ian, the cache syntax has been a mystery to me for a
long time.
Akim
Re: config.cache considered harmful
>>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: Paul> I very much like the bug report quoted below, and I suggest that Paul> it be put into the autoconf source code somewhere, either next Paul> to the code that generates config.cache, or perhaps into a new Paul> section of documentation that discusses autoconf portability Paul> issues. I do agree. In fact I see a few more options: - it's been a long a few of us talked of a `writing portable scripts.texi', and it might be a good time to start it. - extending the ChangeLog entry which corresponds with this additional information. I like the first option, though extending the `portability' section might be a first step to this. Currently I say the portability section as meant for users of Autoconf, who don't know such details IMHO. Anyway, whatever the solution, it must go somewhere :) Nonetheless, I'd really like to extend the ChangeLog entry. I would like that we do that each time we can clarify something. Finally, I'd like to understand how this turns out to be a malign bug. I mean, I do see the 8th bits are set while they should not, but if such a bug could have leaved inside a shell, it probably means that the shell itself doesn't care about the 8th bit, doesn't it? So where did it *hurt*, where did that 8th bit set made a difference? What wrong behavior appeared? Akim
Re: config.cache considered harmful
|I was wrong when I said XEmacs' configure indiscriminately uses |`unset'. In fact it does something like this: | | |if test -n "$ZSH_VERSION"; then | dnl zsh's Bourne shell emulation options | setopt NO_BAD_PATTERN NO_BANG_HIST NO_BG_NICE NO_EQUALS NO_FUNCTION_ARGZERO | setopt GLOB_SUBST NO_HUP INTERACTIVE_COMMENTS KSH_ARRAYS NO_MULTIOS NO_NOMATCH | setopt RM_STAR_SILENT POSIX_BUILTINS SH_FILE_EXPANSION SH_GLOB SH_OPTION_LETTERS | setopt SH_WORD_SPLIT BSD_ECHO IGNORE_BRACES | dnl zsh-3.1-beta drops core on the following | dnl unset CDPATH Do you really care about betas? In fact I have a similar patch for Autoconf, but I have not sent it yet because my zsh (3.1.6-pws16) dumps core on `trap '' 1 2 15' :) BTW, why do you use setopt, which list changes, and not "emulate sh". Also, I need to set NULLCMD=:, otherwise zsh is stuck on `> foo'. How come you don't need it? |elif test -n "$BASH_VERSION"; then | dnl Use Posix mode with bash | set -o posix Hm, good to know, thanks! |I know fanatics who do | |mv /bin/zsh /bin/sh But then zsh it automatically in `emulate sh' mode, so it should make no difference. Akim
Re: config.cache considered harmful
>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: Martin> The configure script I help maintain prints this: Well, CVS Autoconf does this: /tmp/a2ps-4.13 % ./configure --help nostromo 8:49 `configure' configures software source code packages to adapt to many kinds of systems. Usage: configure [OPTION]... [VAR=VALUE]... [HOST] To safely assign special values to environment variables (e.g., CC, CFLAGS...), give to `configure' the definition as VAR=VALUE. [CUT] Some influent environment variables: CFLAGS Extra flags for the C compiler (And it does *not* call your pager, eeek!) Martin> The configure script also recognizes some environment Martin> variables, each of which is equivalent to a corresponding Martin> configure flag. A specified configure flag always overrides Martin> the environment variable. We wanted to avoid the explosion of options. CVS Autoconf remembers all the variables which were set on its command line: ./configure extra_verbose=yes plus those which were selected by the configure.in writer. CFLAGS=-gxemacs ./configure We still have to chose a few default variables, but the next Autoconf might provide a lot of the things you were missing. Come on, join us :) Akim
Re: config.cache considered harmful
>>>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: Harlan> I'd almost like to see a "version" number in the cache, which Harlan> I can "bump" whenever I make a "significant" change to the Harlan> logic which has the effect of... Wel, consider your `bumping action' is `rm config.cache' :) Akim
Re: AC_CHECK_TYPE search locations
>>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: Paul> Perhaps eventually, but I suspect that it's premature to do it Paul> now. Ooops, sorry, it already went in :( Paul> Part of the problem is that STDC_HEADERS is currently specific Paul> to ANSI C (1989); it hasn't been modernized to ISO C 1999. Paul> Now's not the time to fix this, though it might not hurt to Paul> mention this in the manual. I did not change any STDC thing though. While finalizing 2.15 that will be needed, we already make some literature about it :) Just in case, do you see something else we should put in the default includes: ac_includes_default="\ #include #include #if STDC_HEADERS # include # include #else # if HAVE_STDLIB_H # include # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include # endif # include #else # if HAVE_STRINGS_H # include # endif #endif #if HAVE_INTTYPES_H # include #endif #if HAVE_UNISTD_H # include #endif" Akim
Re: xemacs configure script doesn't have AC_DEFINE
>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: Martin> (If you want to try this yourself, get the latest xemacs-21.2 Martin> configure.in. See http://cvs.xemacs.org/ ) I'm looking at it, but frankly, why don't you use m4/*.m4 files? Your configure.in is just huge, and splitting it would help debugging it. Akim
Re: xemacs configure script doesn't have AC_DEFINE
Your AC_OUTPUT section is frightening...
Well, I realize the copy I have is dead broken:
echo " Athena header include path: $athena=
_h_path"
fi
test "$with_dnet" =3D yes && echo " Compiling in support for DNET."
I used wget on cvsweb though :( Any better means to get a correct
configure.in? Anyway, thanks François for `recode /qp' :)
You've done something which is now illegal: using `define' with
another quoting system than [, ]:
changequote(<<,>>)dnl
dnl CPP_MAKEFILE(CPPFLAGS,filename)
define(<>,
echo creating $dir/<<$2>>
$CPP -I. -I${top_srcdir}/src <<$1>> junk.c \
dnl Delete line directives inserted by $CPP
| sed -e 's/^\#.*//' \
dnl Delete spurious blanks inserted by $CPP
-e 's/^[ TAB][ TAB]*$//'\
-e 's/^ /TAB/' \
dnl Delete blank lines
| sed -n -e '/^..*$/p'\
dnl Restore lines quoted above to original contents.
| sed '/^\"/ {
s/\\\([\"]\)/\1/g
s/^[ TAB]*\"//
s/\"[ TAB]*$//
}' > Makefile.new
chmod 444 Makefile.new
mv -f Makefile.new <<$2>>
)dnl CPP_MAKEFILE
(I don't want to criticize, but frankly, by defining a macro inside a
call to AC_OUTPUT, you are looking for troubles).
So I pulled out the definition of the macro out of AC_OUTPUT, removed
the useless (or have I missed something) changequote (changequote is
*hell*), and it works.
dnl CPP_MAKEFILE(CPPFLAGS,filename)
define([CPP_MAKEFILE],
[echo creating $dir/[$2]
$CPP -I. -I${top_srcdir}/src [$1] junk.c \
dnl Delete line directives inserted by $CPP
| sed -e 's/^\#.*//' \
dnl Delete spurious blanks inserted by $CPP
-e 's/^[[ TAB][ TAB]]*$//'\
-e 's/^ /TAB/' \
dnl Delete blank lines
| sed -n -e '/^..*$/p'\
dnl Restore lines quoted above to original contents.
| sed '/^\"/ {
s/\\\([\"]\)/\1/g
s/^[[ TAB]]*\"//
s/\"[[ TAB]]*$//
}' > Makefile.new
chmod 444 Makefile.new
mv -f Makefile.new [$2]
])dnl CPP_MAKEFILE
Akim
Re: passing command-line switches to compiler
>>>>> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: Ian> The GNU binutils use this macro to detect this case: Ian> dnl See whether we need a declaration for a function. Ian> AC_DEFUN(BFD_NEED_DECLARATION, There is something like this in Autoconf now: Generic Declaration Checks -- These macros are used to find declarations not covered by the particular test macros. - Macro: AC_CHECK_DECL (SYMBOL, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND], [INCLUDES]) If the declaration of SYMBOL (a function or a variable) is needed because it is not declared in INCLUDES, run the shell commands ACTION-IF-NOT-FOUND, otherwise ACTION-IF-FOUND. If no INCLUDES are specified, the default includes are used (*note Default Includes::). This macro actually tests whether it is valid to use SYMBOL as an r-value, not if it is really declared, because it is much safer to avoid introducing extra declarations when not needed. - Macro: AC_CHECK_DECLS ((SYMBOL, ...), [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND], [INCLUDES]) For each given SYMBOL (comma separated list), define `HAVE_DECL_SYMBOL' (in all capitals) to `1' if SYMBOL is declared, otherwise to `0'. If ACTION-IF-NOT-FOUND is given, it is additional shell code to execute when one of the function declarations is needed, otherwise ACTION-IF-FOUND is executed. This macro uses an m4 list as first argument: AC_CHECK_DECLS((strlen)) AC_CHECK_DECLS((malloc, realloc, calloc, free)) Unlike the other `AC_CHECK_*S' macros, when a SYMBOL is not declared, `HAVE_DECL_SYMBOL' is defined to `0' instead of leaving `HAVE_DECL_SYMBOL' undeclared. When you are _sure_ that the check was performed, use `HAVE_DECL_SYMBOL' just like any other result of Autoconf: #if !HAVE_DECL_SYMBOL extern char *symbol; #endif But if the test may have not been performed, because it is safer _not_ to declare a symbol than to use a declaration which conflicts with the system's one, you should use: #if defined HAVE_DECL_MALLOC && !HAVE_DECL_MALLOC char *malloc (size_t *s); #endif You fall into the second category only in extreme situations: either your files may be used without being configured, or they are used during the configuration. In most cases the traditional approach is enough. Akim
Pirate Autoconf and CVS Autoconf
Hi! I'm sorry for people who don't read autoconf-patches, there's a news I should have sent before: we have caught up the difference between CVS Autoconf and FTP Autoconf. The latter has been removed, and people who really depend a ultra-new Autoconf are encouraged to check out the CVS one. We know it will not pass all the tests, a patch is waited to be committed, but this failure is minor (it is the test which is actually wrong). Akim
autoconf --trace
POSIX_1_SOURCE], [2], [Define if the system does not provide POSIX.1 features except with this defined.]) Don't you see a tool which would parse it extremely easily? Well, I give you a hint: s/^m4trace:\([^:]*\):\([^:]*\): -[0-9]*- \([^(]*(\)\(.*\)$/\3[\1], [\2], \4/ See what I mean? Well, OK, here is the result: AC_DEFINE([configure.in], [36], [_ALL_SOURCE]) AC_DEFINE([configure.in], [37], [_POSIX_SOURCE], [1], [Define if you need to in order for `stat' and other things to work.]) AC_DEFINE([configure.in], [37], [_POSIX_1_SOURCE], [2], [Define if the system does not provide POSIX.1 features except with this defined.]) See what I mean? So yes, the solution I propose it to transform m4's tracing output in order to re-feed m4 with that. Now if this idea is accepted, the question will be that of the format of the request. It can be directly the definition in m4, autoconf --trace AC_SUBST($1:$3) to ask just for the line number and the variable, separated with a colon. The fact that we feed this to m4 gives us quite a lot of power on the format. Akim
Re: Pirate Autoconf and CVS Autoconf
>>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> => tests/Makefile.in is missing from CVS. Heck! I'm sorry, I'm deeply sorry, I plead guilty :( CVS Autoconf is to be used with Automake 1.4, not 1.4a (well, you can, but then you have to update the m4/*.m4 files and aclocal.m4). Ralf> [BTW: IMO, keeping automake-generated Makefile.ins in CVS is Ralf> rather problematic. Instead, I prefer the autogen.sh/bootstrap Ralf> approach.] Same here, but I just followed the existing convention on Autoconf. I'd be happy to remove *.info, Makefile.in, configure etc. Akim
Re: Pirate Autoconf and CVS Autoconf
Hi Erez,
I have fixed several mistakes in the test suite, so there should be
less failures now.
There are some I really don't understand, and I need your help (I
can't reproduce them). But I would suggest that you pull out a fresh
Autoconf.
Ooops, btw people, we have to tell you we are moving Autoconf from
sourceware to subversions.gnu.org. More soon. For the time being,
cvs -d :pserver:[EMAIL PROTECTED]:/cvs login
[Hit enter]
cvs -d :pserver:[EMAIL PROTECTED]:/cvs checkout autoconf
|
| ./debug-4.sh: Testing AC_CHECK_DECLS
|
| ../../../autoconf/tests/semantics.m4:21: testing...
| ../../../autoconf/tests/semantics.m4:21: testing...
| ../../../autoconf/tests/semantics.m4:21: testing...
| creating cache ./config.cache
| checking whether yes is declared... no
| checking whether no is declared... no
| updating cache ./config.cache
| creating ./config.status
| creating config.h
| ../../../autoconf/tests/semantics.m4:21: testing...
| ../../../autoconf/tests/semantics.m4:21: testing...
| --- - Tue Feb 15 13:00:08 2000
| +++ stdout Tue Feb 15 13:00:08 2000
| @@ -1,2 +1,2 @@
| #define HAVE_DECL_NO 0
| -#define HAVE_DECL_YES 1
| +#define HAVE_DECL_YES 0
Can you run ./debug-4.sh and send me configure, config.log, and
config.status. Make sure to rm config.log and config.status before.
|
| ./debug-32.sh: Testing AC_EXEEXT
|
| ../../../autoconf/tests/macros.m4:45: testing...
| ../../../autoconf/tests/macros.m4:45: testing...
| ../../../autoconf/tests/macros.m4:45: testing...
| configure: error: installation or configuration problem: compiler cannot create
|executables.
Could you run ./debug-32.sh, rm config.log and config.status, then run
./configure and send me config.log?
| ===
| ./debug-63.sh: Testing AC_PATH_TOOL
| ===
| ../../../autoconf/tests/macros.m4:82: testing...
| ../../../autoconf/tests/macros.m4:82: testing...
| ../../../autoconf/tests/macros.m4:82: testing...
| configure: error: cannot find install-sh or install.sh in . ./.. ./../..
Huh? Hm, this macro is not beautiful, and should be reworked. Still,
could you do as for 32?
Thanks!
Akim
Re: autoconf challenge
It'd be much easier if you could send what you have, and how it fails.
Akim
Re: cvs version of autoconf
>>>>> "Gabor" == Gabor Z Papp <[EMAIL PROTECTED]> writes: Gabor> I have this problem configuring midnight commender cvs tree, Gabor> and I think the problem is with my bad autoconf install. My Gabor> question is, that how can I install glib and other packages Gabor> that have glib.m4 and other autoconf related files? I don't Gabor> like make install, and I do everything manually, but it seems, Gabor> that at autoconf I must do something, simpley copy files isn't Gabor> enough. Thanks. I doesn't seem to be related to Autoconf. Are you sure you run the current Autoconf? I see it tries to access /usr/local/share/autoconf/acconfig.h, which is not the way the current Autoconf behaves (it no longer use it). You also need to find where all the macros AM_PATH_GLIB etc. are defined. BTW, personally I would complain to its author: AM_ and actually all the `A[A-Z]_' are reserved by Autoconf and Co. Unless it is planed that this macro becomes an official Automake macros, it is misleading to name it AM_. Gabor> library configure.in:78: warning: AC_LINK_FILES is obsolete; Gabor> instead use AC_CONFIG_LINKS(DEST:SOURCE...) grep: Hm, this goes sound like CVS Autoconf. Weird. Are you sure there is no mixture between executables and library files? Gabor> /bin/autoheader: ./autoh8319.decls: line 413: unexpected EOF Well, no, it is indeed the right autoheader. Gabor> while looking for matching ``' /bin/autoheader: Gabor> ./autoh8319.decls: line 1548: syntax error: unexpected end of Gabor> file grep: /usr/share/autoconf/acconfig.h: No such file or Gabor> directory grep: /usr/share/autoconf/acconfig.h: No such file or Gabor> directory sed: can't read /usr/share/autoconf/acconfig.h: No This is issued by test -r $localdir/acconfig.h && grep @TOP@ $localdir/acconfig.h >/dev/null && sed '/@TOP@/,$d' $localdir/acconfig.h >>$tmpout but I don't understand how grep and sed could have been launched if acconfig.h doesn't exist. What is it that you ran? Akim
Re: ["T.E.Dickey" ] Re: NEED_foo_DECL vs HAVE_DECL_foo
A> Could you share your experience on [EMAIL PROTECTED]?
T> I do on occasion...
Good :)
Current code for AC_CHECK_DECL uses
#ifndef $1
char *p = (char *) $1;
#endif
Thomas suggests
> | #undef $1
> | struct zowie { int a; double b; struct zowie *c; char d; };
> | extern struct zowie *$1();
>
> Why is it that complex? We just
>
> char *p = (char *) $1;
because some compilers won't error on a char* - a struct is better,
and it's complex to make it less likely that it matches an existing
struct.
First of all, I don't get what this #ifndef is doing here in
Autoconf, it does not test what I need, so AFAIC I'd vote for
char *p = (char *) $1;
or maybe
#undef $1
char *p = (char *) $1;
A difference I see between Thomas' approach and Autoconf's is that
Autoconf does not try to force the symbol whose declaration is being
checked to be a function. AC_CHECK_DECL can them be used for errno,
sys_siglist and others.
In this case, Thomas, do you think we still need all the zowie stuff?
Akim
Re: Pirate Autoconf and CVS Autoconf
Yep, sorry, this is also an issue to solve. I had used Automake 1.4a which uses AM_MISSING with two args, and an executable missing. When I fell back to 1.4, I forgot to downgrade the use of AM_MISSING. It will be done. Meanwhile, I'd suggest that you AVAILABILITY The latest version of this distribution is available on- line from: ftp://ftp.gnu.org/gnu/help2man/ http://www.ozemail.com.au/~bod/help2man.tar.gz Akim
Re: ["T.E.Dickey" ] Re: NEED_foo_DECL vs HAVE_DECL_foo
>>>>> "T" == T E Dickey <[EMAIL PROTECTED]> writes: >> AC_CHECK_DECL can [then] be used for >> errno, sys_siglist and others. T> even 'errno' when it's a macro? (no - won't work). Right, my example was a bit light. >> In this case, Thomas, do you think we still need all the zowie >> stuff? T> yes. Err, could you develop? I'd like to leave some documentation in the code of Autoconf to justify any weird stuff. And this is extremely weird. Which machine, which compiler, which code, which failure? Akim
Re: Pirate Autoconf and CVS Autoconf
>>>>> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes: Erez> That's good news, Akim. Oh yes it is! :) Erez> Now, do you have a schedule for when a feature freeze will Erez> happen, and when this autoconf will work with automake 1.4a? We've not talked about this yet, but personally I'm not satisfied yet. At some point in the past it would have been OK to release a 2.15 as is, but since then we took the decision to clean up the code, and to promote better coding styles. Therefore, although the next Autoconf will be backward compatible, we do expect people to follow the new standards. It should not happen several times, hence 2.15 should provide a base layer that satisfies everybody. Today, it is not the case. And, as you noted, the integration with Automake is still to be done. But I'm optimistic. It is good that Tom doesn't jump on Autoconf as is today, because Autoconf is trying to reach him. IMHO, doing efforts in Automake today is wasting time. Erez> After these two happen, I'd like to test autoconf on all of my Erez> platforms. I do it in two ways: (1) run make test, and (2) use Erez> it in my am-utils package. I understand you want to delay (2), but since I believe you have access to a great many architectures, since I think you have scripts that performs the tests in batch, I would really feel better if you could try it a least once early. Way before the code freeze. Some people already *rely* on CVS Autoconf. Erez> It's also easier for me to do the two things at once, esp. since Erez> I have to login to dozens of machines scattered around the Erez> Internet. Well, I am certainly not asking you to `work', but if you have something automated which costs nothing to run, included if it is on a small set of machines, it'd be great. Thanks! Akim
Re: autoconf --trace
>>>>> "Olly" == Olly Betts <[EMAIL PROTECTED]> writes: Olly> One thought: If this tracing is for use when automake is being Olly> used, you can rely on perl being available. As reported by Alexandre, some simple output is sometimes needed by shell scripts. And in most cases we just don't need the quotes since we're only interested in $1. Akim
Re: autoconf --trace
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On Feb 14, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >> - every macro becomes extremely picky on the quotes, since there is >> embedded code which really depends upon [ and ]. Alexandre> Can't this be done in a way that only traced macros become Alexandre> that picky? This would allow for at least a soft Alexandre> transition. No. I would like to avoid entering into the gory details, because it is long, but in a couple of words: - if you want to equip some macros only, you have to do that between the definition of the macro and its uses, i.e., basically between autoconf.m4f and configure.in. This is also why it is bad not to separate definitions from uses in Autoconf. - so you have to equip all the macros so that they launch hooks, and this has to be done first. Well, we could imagine changing `define' so that it equips only the selected macros. But I really don't like overloading define all the time, it is very delicate a neuron burning. Whatever the way we choose to implement it in m4, the observer will change the measure, which we want to avoid. In addition, since we will never manage to make it reflective, we won't be able to trace the very base layer of libm4, which I would regret a lot. And finally, first measuring via m4 --trace, and then processing it via m4 again is a fairly good approximation, imho. But I trust it. >> changequote(<<, >>)dnl << --enable-shared[=PKGS] build shared >> libraries [default=>>AC_ENABLE_SHARED_DEFAULT], changequote([, >> ])dnl Alexandre> Ugh! I swear it was not me who wrote that. :) Honestly, it is hard to write that, this is indeed a typical case where the [ and ] are hard to deal with. The cleanest implementation I know is a bit hacky: define(the-message, [[--enable-shared[=PKGS]build shared libraries [default=$1]]]) and use the-message(AC_ENABLE_SHARED_DEFAULT) because $1 etc. expansion are always performed, no matter the number of quotes you used in the macro definition. >> So yes, the solution I propose it to transform m4's tracing output >> in order to re-feed m4 with that. Alexandre> I really can't express with words how brilliant I consider Alexandre> this idea. :-) (blush, red up to the ears :) Thanks. Alexandre> Go for it! Yeah! Excellent! We have to fine an interface and we'll go for it, and we'll adapt Automake, and we'll release everybody, and we'll win the Contest, and we'll be rich and... [djm in autoconf.texi:] And there was much rejoicing. And I have free time again. I think. Yeah, right. :) :) >> Now if this idea is accepted, the question will be that of the >> format of the request. It can be directly the definition in m4, >> autoconf --trace AC_SUBST($1:$3) >> to ask just for the line number and the variable, separated with a >> colon. Alexandre> Even though the internal tracing macros take the file name Alexandre> and the line number as arguments $1 and $3, respectively, I Alexandre> don't think we should expose this to the users. $1 should Alexandre> be the first actual argument to the macro. We should Alexandre> probably do the translation internally. Yep, definitely. In fact I suggest that we capture everything that m4 --trace can give us, including the -42- we removed, because some people can be interested. $ autoconf --trace AC_SUBST:$f:$l:$0:$1 => configure.in:42:AC_SUBST:prefix $ autoconf --trace AC_SUBST:$1 => prefix Akim
Re: autoconf --trace
|From: Akim Demaille <[EMAIL PROTECTED]> |Date: 14 Feb 2000 10:43:04 +0100 | | s/^m4trace:\([^:]*\):\([^:]*\): -[0-9]*- \([^(]*(\)\(.*\)$/\3[\1], [\2], \4/ | | This looks like a good idea to me. I would improve it slightly by | making it more specific, e.g. | | s/^m4trace:\([^:][^:]*\):\([0-9][0-9]*\): -[0-9][0-9]*- |\([A-Z_a-z][0-9A-Z_a-z]*(\)\(.*\)$/\3[\1], [\2], \4/ Wow, thanks :) I will also adapt it for the case where there are no () (because m4 doesn't output them in this case). |Now if this idea is accepted, the question will be that of the format |of the request. It can be directly the definition in m4, | |autoconf --trace AC_SUBST($1:$3) | |to ask just for the line number and the variable, separated with a colon. | | This sounds good, but I didn't follow that example. Why is $1 the | line number and $3 the variable? As Alexandre pointed out, it should be hidden from the user, but internally, because we re-feed m4 after having added new parameters (line number, file name etc.), there's a shift. We could just leave them before, but the point is to give the control over their output. Akim
Re: autoconf --trace
| On Feb 15, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: | > $ autoconf --trace AC_SUBST:$f:$l:$0:$1 | | > => configure.in:42:AC_SUBST:prefix | Sounds good to me. But are the `:' separators mandatory, or can we | just choose any expansion to a given macro? For example, we could | make it like this: Much freedom should be available. The main problem will be with $@ I guess, where some work from m4 will be required. I'd like to find a means to specify the seperator. Something like --trace AC_SUBST:$0:$:@ I don't know... | autoconf --trace 'AC_SUBST=some-junk $1 some-garbage' | | So as to get: | | some-junk prefix some-garbage Should be possible, indeed. | We could replace the m4trace prefix with define()s of, say, `FILE' and | `LINENO', and leave it up to the user to place FILE or LINENO in the | intended expansion, that, in the example above, would be defined as: | | define([AC_SUBST], [some-junk $1 some-garbage]) In fact I think it won't be AC_SUBST, but trace__AC_SUBST or whatever, to avoid clashes when macros `display' arguments that contain code. The main means to avoid such clashes would be define([AC_SUBST], [[some-junk $1 some-garbage]]) but then you forbid helpy macros that could handle $:@ and the like. OTOH, n-ary macros are not our main preoccupation. But it would be a pity to forget them. Experiments will probably show what the sanest solution. As for LINENO, I don't know. I don't feel it too well because of the rules of expansion. In the `define' right above, in spite of the double quotation, the $1 *will* be expanded, but a LINENO would not. $n is much easier to handle, much safer. Akim
Re: Pirate Autoconf and CVS Autoconf
Wow, sounds like there is plenty of exciting things to check here. I have access to some Solarises, I will try with them to see if I can get all the data I need. Thanks a lot for the report (and don't lose these guys :). Akim
Re: Bug Report: Autoconf 2.13
Thanks for the report. Since then Autoconf uses Automake, so such
failures are less likely. Nonetheless, I don't understand why frozen
files should be taken from srcdir.
Akim
Re: autoconf challenge
| On Thu, Feb 17, 2000 at 02:12:19PM +0100, Akim Demaille wrote: | : It'd be much easier if you could send what you have, and how it fails. | | Well, since I figured out the problem but didn't know how to implement | "compile-time" autoconf macros, I don't really have anything that fails... | I'm reading up on m4 at the moment, and will hopefully be able to implement | it afterwards. | | Before I saw the order of things I thought I could do something like this: | | AC_DEFUN(SIM_CHECK_COIN,[ | AC_PREREQ([2.14.1]) 2.14.1 doesn't exist! | | dnl set up default attributes | default=yes | | for attribute in dummy $3; do | case $attribute in | dummy) ;; | default)default=yes ;; | nodefault) default=no ;; | *) AC_MSG_ERROR(invalid attribute \"$attribute\" for `SIM_CHECK_COIN') |;; | esac | done | | AC_ARG_WITH(coin, AC_HELP_STRING([--with-coin=DIR], [set the prefix directory wh | ere Coin resides [default=$default]]), , [with_coin=$default]) | | [...] | | then I would be able to use something like this when libCoin was a non-default | option: | | SIM_CHECK_COIN( , , nodefault) Maybe I misunderstood your point, but I don't understand why you have sh code here (maybe that's what you meant with m4 compile time), and I don't understand why you don't use `yes' and `no' for $3. Is this OK? define(_SIM_CHECK_COIN_HELP, [AC_HELP_STRING([--with-coin=DIR], [set the prefix directory where Coin resides [default=$1]])]) AC_DEFUN(SIM_CHECK_COIN, [AC_PREREQ([2.14a])dnl ifelse([$3], [], [$3], [yes], [$3], [no], [AC_FATAL([$0: invalid attribute `$3'])])dnl AC_ARG_WITH(coin, _SIM_CHECK_COIN_HELP(m4_default([$3], [yes])) etc. Part of the problem is that AC_ENABLE_ are yet another series of macros which double quote :( Akim
Re: autoconf challenge
| : 2.14.1 doesn't exist! | | It did for a short time. I assume you use the autoconf CVS repository. Yep, sorry, I should have said no longer exists. | : ifelse([$3], [], | :[$3], [yes], | :[$3], [no], | :[AC_FATAL([$0: invalid attribute `$3'])])dnl | | I'm reading up on m4 now. I thought ifelse needed touples of 3 and 3 args to | be used as a switch-case... You are right, sorry: | : ifelse([$3], [],[], | :[$3], [yes], [], | :[$3], [no], [], | :[AC_FATAL([$0: invalid attribute `$3'])])dnl Akim
Re: cvs version of autoconf
>>>>> "Gabor" == Gabor Z Papp <[EMAIL PROTECTED]> writes: Gabor> Midnight Commander CVS. I delete every autoconf/automake Gabor> related files from my host, and install the last releases. Let Gabor> see, what happend. I don't see any commands here. What is it that you run? If it is `make', could you try to do it step by step? If AM_GLIB_BLAH is in configure.in, then I'd advice that you put it in a separate file in m4/*.m4. I don't know why aclocal complains, but anyway it is better this way. Then, as long as aclocal and autoconf complain, there is no point in trying to continue. Akim
Re: cvs version of autoconf
>>>>> "Gabor" == Gabor Z Papp <[EMAIL PROTECTED]> writes: Gabor> Can you please explain me how can I add AM_GLIB_PATH into a Gabor> sample m4 file? Thanks. Take the definition of the macro, paste it in a file m4/glibpath.m4. That's all :) Akim
Re: cvs version of autoconf
>>>>> "Gabor" == Gabor Z Papp <[EMAIL PROTECTED]> writes: Gabor> | Take the definition of the macro, paste it in a file Gabor> m4/glibpath.m4. | | That's all :) Gabor> Heh, but how? What is the definition of macro? And I don't Gabor> have m4 directory. It is /usr/share/aclocal? Please, make me Gabor> the glibpath.m4 and in the future I know, how must I do a new Gabor> one. :) Send me in private the configure.in file. But I'm going to leave soon, maybe someone else can help you too... Akim
Re: cvs version of autoconf
>>>>> "Gabor" == Gabor Z Papp <[EMAIL PROTECTED]> writes: Gabor> It is defined in configure.in, and I don't know how can I tell Gabor> to the script, that glib is installed in /usr/local well, it is *not* defined, it is *used* in your second configure.in. I suppose glib.m4 or so must be available somewhere. Do you have the sources of glib? You probably should. Ask help to the MC guys, your problem does not appear to have anything to do with a bad Autoconf. Akim
Re: cvs version of autoconf
>>>>> "Gabor" == Gabor Z Papp <[EMAIL PROTECTED]> writes: Gabor> When I have a new.m4 file, and I want use with autoconf, its Gabor> enough to copy to the autoconf directory? No. look where there are other m4 files, and place it there. Otherwise read the documentation of Automake, look for `aclocal'. Gabor> There is an acglib.m4 but no related are defined. Sorry, I don't understand. Akim
Re: How to optionally test for a C++ compiler?
>>>>> "Olly" == Olly Betts <[EMAIL PROTECTED]> writes: Olly> Thoughts? I'm happy to do the work, but I'd rather not spend Olly> time on it and then get told it's not useful. It is certainly going to be useful. Nonetheless, I think we should not hurry. The problem you are addressing is clearly much broader than just C++, or even just for the compilers. I, for one, have also been bugged that Autoconf always picks up a candidate, tests it, and then fails. I would like to move AC_PATH_PROG_WITH_TEST into Autoconf. I don't recall the exact name, but it is a macro written by Ulrich Drepper for gettext. This is the right way to go. In fact, there is a rewriting of the AC_TRY which must happen, let it be only for the quoting issues. I think it is also time to provide something better than the weird AC_PATH_PROG, AC_CHECK_PROG, AC_CHECK_TOOl and the like. Then, we will have all the needed technology to address the not-so-special case of compilers. Well, IMHO. Akim
Re: How to optionally test for a C++ compiler?
>>>>> "Olly" == Olly Betts <[EMAIL PROTECTED]> writes: Olly> I hesitate to criticise the valiant efforts of the maintainers, Olly> but this does appear to be a general problem with autoconf. I Olly> don't feel I'm using autoconf in advanced ways, but I seem to Olly> end up having to use CVS versions most of the time. Perhaps Olly> minor releases with just bug fixes would help here? I share your opinion, but I'm somewhat more optimistic. What is currently happening is a walk-through in Autoconf, and almost every single macro is rethought, trying to factor common things, improve the base layer, uniformize the quoting system, standardize the prototypes etc. Therefore it is true that the release 2.15 is delayed more than it should have been. We could decree a feature freeze now, but I don't think it is right, we should do that only once we're done with the base layer. I must confess I am not really interested in fixing deep problems in acspecific and the like. There is urgency in acgeneral, and once we have a cute acgeneral, we should spread it, so that people can use it. Worse: I am even a bit frightened when there are patches submitted for acspecific that suggest to change a proto somewhere, because this commits our future. There is nothing more important in Autoconf than uniformity. There is nothing more painful than macros with are different from the other for free, especially when they use the `right' name. So, yes, I share your opinion, Autoconf 2.15 is overdue. OTOH, this is probably the last time there will be such delays. Akim
Re: cvs version of autoconf
>>>>> "Gabor" == Gabor Z Papp <[EMAIL PROTECTED]> writes: Gabor> In glib source I have an acglib.m4 file, but no AC_PATH_GLIB Gabor> defined or used in it, so I think it isn't usable. MC guys Gabor> didn't answer for my report. You said AM_PATH_GLIB the first time, but I suppose that's what you meant. Sorry, I can't help you. Gabor> BTW, I just compiled libtool. I install manually the binary Gabor> files, but I have some m4 files for aclocal/. So still enough Gabor> that I copy these files to this directory? No additional manual Gabor> editing required in an 'index' file? No index. Akim
Re: autoconf testsuite endless loop
| On Fri, Feb 18, 2000 at 03:39:59PM +0100, Akim Demaille wrote: | > | > Could you change tests/tools.m4 from | > | > # A script in charge of testing `/bin/sh -n'. | > AT_DATA(syntax.sh, | > [[set -e | > (/bin/sh -n endless.sh) & | > cpid=$! | > sleep 2 && kill $cpid >/dev/null 2>&1 | > ]]) | > | > to | > | > # A script in charge of testing `/bin/sh -n'. | > AT_DATA(syntax.sh, | > [[set -e | > (/bin/sh -n endless.sh) & | > cpid=$! | > sleep 2 && kill $cpid >/dev/null 2>&1 || exit 1 | > ]]) | | Both shell scripts seems to work fine, i tested it on command line and | it returns the correct values. | | The problem seems to be in the test that use this return value because | changing : | | if /bin/sh ./syntax.sh; then | AT_CHECK([/bin/sh -n ../autoconf], 0) | AT_CHECK([/bin/sh -n ../autoreconf], 0) | AT_CHECK([/bin/sh -n ../autoupdate], 0) | AT_CHECK([/bin/sh -n ../autoreconf], 0) | AT_CHECK([/bin/sh -n ../ifnames],0) | fi | | to | | /bin/sh ./syntax.sh | if $? -ne 0; then | AT_CHECK([/bin/sh -n ../autoconf], 0) | AT_CHECK([/bin/sh -n ../autoreconf], 0) | AT_CHECK([/bin/sh -n ../autoupdate], 0) | AT_CHECK([/bin/sh -n ../autoreconf], 0) | AT_CHECK([/bin/sh -n ../ifnames],0) | fi | | Give expected behaviour | Humph ? Huh! Well, here I need help, I don't understand. Is there anybody on autoconf@ who can help us? Akim
Re: Pirate Autoconf and CVS Autoconf
>>>>> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes: Erez> Is there a new mailing list for cvs-logs as well? If so, how do Erez> I subscribe to it? Not set up yet, but I think we will propagate the former list of members. Akim
Re: Pirate Autoconf and CVS Autoconf
| I think I know what's wrong. You're using 'cc' instead of $CC somewhere. I | have gcc installed on my machine, and no license for Solaris's /usr/ucb/cc | compiler. So running cc fails. That's correct, another user reported exactly the same failure. I don't know yet how I will fix this, but it definitely messes up many tests. | A few more tests appear to fail when srcdir!=builddir: Some are probably related to install-sh. On my machine Autoconf picks up install, so it doesn't reach the point where it realizes there is no install-sh around if things go really wrong. I will look for a fix. | Some of the new failed tests can't find install-sh. It should look in | $srcdir as well. Hm, well, I should stop answering while reading :) :) :) | BTW Akim, depcomp is missing from the autoconf distribution, and the build | process fails unless it's there. Can you do one of these: It has been decided that currently Autoconf stick to Automake 1.4, hence there is no use for depcomp. We will probably switch to CVS Automake once it is fixed and stops requiring C stuff (depcomp) for a package like Autoconf. | - include depcomp in the distribution | - make sure you run automake --missing | - create a "bootstrap" script ala libtool We don't because the archive contains the distribution in fact. There is everything you need in there (Makefile.in etc.). Thanks for the logs! Akim
Re: How to optionally test for a C++ compiler?
>>>>> "Olly" == Olly Betts <[EMAIL PROTECTED]> writes: >> It is certainly going to be useful. Nonetheless, I think we >> should not hurry. The problem you are addressing is clearly much >> broader than just C++, or even just for the compilers. Olly> I personally need a solution to my current problem (which is Olly> that I can't probe for a C++ compiler without aborting if one's Olly> not found) fairly soon (in the next week say), but that doesn't Olly> necessarily mean that autoconf need adopt it so soon. Well, in that case, since the only occurrence of AC_MSG_ERROR in AC_PROG_CXX is the one that bothers you, you can pushdef([AC_MSG_ERROR], [AC_MSG_RESULT([You don't have any C++ compiler, too bad])]) AC_PROG_CXX popdef([AC_MSG_ERROR]) >> In fact, there is a rewriting of the AC_TRY which must happen, let >> it be only for the quoting issues. I think it is also time to >> provide something better than the weird AC_PATH_PROG, >> AC_CHECK_PROG, AC_CHECK_TOOl and the like. Olly> There are a lot of macros performing small variations of the Olly> same task. It does look like it would benefit from being Olly> replaced with a single macro with a clean, flexible interface. Absolutely. Instead of having several variations, we just need one big macros with all bells and whistles. Thanks to m4, this should not change anything in the output. BTW, I've always wanted to work as if we had `which' available: first look up for all the candidates, then pick up the first one we like. It sounds more like a penalty than anything else, but I expect two benefits: some day, on the platform that really have a `which', I suppose it will be more efficient than walking by hand with sh, and second, on the weird platforms, such as DOS, I expect `which' to handle part of the troubles (such as returning foo.exe for `which foo'). Olly> Do you have a vision of what this might be, or do we need to sit Olly> down and look at analyse exactly what each variant does? IMHO, it should be something like PATH_PROG_WITH_TEST. In particular, the fact that we reject some candidates (AC_PATH_PROG IIRC), is nothing but a particular test. Akim
Re: autoconf testsuite endless loop
On Fri, Feb 18, 2000 at 03:39:59PM +0100, Akim Demaille wrote: > > Could you change tests/tools.m4 from > > # A script in charge of testing `/bin/sh -n'. > AT_DATA(syntax.sh, > [[set -e > (/bin/sh -n endless.sh) & > cpid=$! > sleep 2 && kill $cpid >/dev/null 2>&1 > ]]) You need to use the || exit 1 stuff, otherwise you return with the exit status of kill which is the complement of the one we're interested in. | With buggy shell, syntax.sh return expected value 0 and 1 otherwise. | This part works fine. | | > | if /bin/sh ./syntax.sh; then | > | AT_CHECK([/bin/sh -n ../autoconf], 0) | > | AT_CHECK([/bin/sh -n ../autoreconf], 0) | > | AT_CHECK([/bin/sh -n ../autoupdate], 0) | > | AT_CHECK([/bin/sh -n ../autoreconf], 0) | > | AT_CHECK([/bin/sh -n ../ifnames],0) | > | fi | | The problem is that a `0' return value is equivalent to `true' and `1' | if interpreted as `false'. | | njoly@medusa [~/Softs]> true | njoly@medusa [~/Softs]> echo $? | 0 | njoly@medusa [~/Softs]> false | njoly@medusa [~/Softs]> echo $? | 1 | | We need to reverse this test or syntax.sh return values to have correct | behaviour. We did that. You said that included with || exit 1 it was wrong. You said if /bin/sh ./syntax.sh; then was failing, while /bin/sh ./syntax.sh if test $? = 0; then was giving the expected behavior. I don't understand the difference, to me the two constructs are equivalent. I must confess I am not an expert with background jobs in shell scripts. In fact, I don't think I need to store $!, I was afraid that some shell might reset it after the sleep. Actually, syntax.sh should just be AT_DATA(syntax.sh, [[(/bin/sh -n endless.sh) & sleep 2 kill $! >/dev/null 2>&1 || exit 1 ]] it should $? = 0 if sh -n works, 1 otherwise. Akim
Re: autoconf testsuite endless loop
| If kill works, its return value is 0 and we need to add `&& exit 1' to | have the complement as `|| exit 1' is only executed if kill returns >0. Of course!!! Thanks, brain failure :( | it was: | | if test $? -ne 0; then Sorry, I missed that. Eyes failure :) Will commit the right fix. Again, thanks, and sorry for my slow understanding... Akim
Re: How to optionally test for a C++ compiler?
>>>>> "Olly" == Olly Betts <[EMAIL PROTECTED]> writes: Olly> Perhaps the cleanest approach is to write the macro to assume a Olly> working `which'-like command $WHICH, and then supply tcsh and Olly> bash versions, plus a fallback sh version which walks the path Olly> as we do at present. In a first step, I was thinking of the opposite: generating the list from within configure, and later extract it into missing or alike. Currently Autoconf requires only install-sh and mkinstalldirs, it should not populate our dirs with such tools. An integrated approach such as missing of shtool is what I'm looking for. Nevertheless, 2.15 was delayed enough, and a clean integration of such a satellite needs to be done at peace. Olly> * host-type prefixing (AC_CHECK_TOOL/AC_PATH_TOOL) Olly> Perhaps have an optional argument giving a list of prefixes? Should be handled only by the `which' part of the macro. Olly> AC_CHECK_FILE/AC_CHECK_FILES probably don't want to get rolled Olly> in (but perhaps ought to be merged), since they don't use a Olly> PATH. They also can't be implemented with which, since the Olly> files checked for needn't be executable. Yep, but that's the opposite: AC_CHECK_FILES (extended with tests) can be used by CHECK_PROGS. CHECK_PROGS makes the `which' list :) beforehand. Akim
Re: DOS-style paths
>>>>> "Mark" == Mark E <[EMAIL PROTECTED]> writes: >> There is one effect I don't understand well in fact: that of >> AC_PATH_PROG. You now let Autoconf accept PERL=a:relative/to/perl >> where before it required PERL=a:/absolute/to/perl. Why is it so? Mark> One reason is to avoid the second case in AC_PATH_PROG which Mark> searches the path by setting IFS=":". Mark> This is a big problem when PATH contains drive letters. Hm, I miss a point here: I don't quite understand how it relates with AC_PATH_PROG since this macro considers the absolute/relative thing only when checking the envvar that should point to the tool (e.g., PERL=/usr/bin/perl). I can imagine there is a problem with IFS=: to split the PATH, but I don't quite understand how your patch improves the situation. Akim
CVS Autoconf has moved
Hi People, The Autoconf CVS repository has been moved from sourceware.cygnus.com, run by Jason Molenda, Tom Tromey and others, to subversions.gnu.org, run by Gordon Matzigkeit (the original author of Libtool), Jeff Bailey, and others. The Autoconf gang, no matter how recursive it may sound, would like to thank the sourceware team for the efforts they have put in Autoconf those last two years. In order to checkout Autoconf from subversions, you just: cvs -d :pserver:[EMAIL PROTECTED]:/cvs login [enter] cvs -d :pserver:[EMAIL PROTECTED]:/cvs checkout autoconf You may also browse the archive via CVSWeb: http://subversions.gnu.org/ There are still a few issues to solve in order to recover the comfort we had on sourceware: move the Gnats data base, move the CVS related mailing lists etc. but it will gradually be done. On behalf of the team, Akim
Re: DOS-style paths
>>>>> "Mark" == Mark E <[EMAIL PROTECTED]> writes: Mark> After looking at what Autoconf actually generates, instead of Mark> the raw source which is a challenge to understand, perhaps Mark> you're right and the absolute case should be '/* | ?:[/\\]*'. In Mark> the generated configure script, I see that regular relative Mark> paths are ignored, so then DOS-style ones should be ignored too. It make sense to me. What are the conditions to see a \ instead of a /? Akim
Re: DOS-style paths
>>>>> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
Earnie> I have a local patch for this. I create a variable named
Earnie> path_separator, set a default of ":" and set
Earnie> IFS=${path_separator}. Then use the --path-separator switch
Earnie> to control it's value.
I'm interested in seeing your patch, but I must confess I'd like to
avoid an extra option. Using envvars only should be possible.
Earnie> I've also found that AC_PATH_PROG needs to add the suffix when
Earnie> check for the existance of a program because I get for example
Earnie> m4.exe returned and AC_PATH_PROG check for m4.
Yep, there are still many problems of portability to DOS and OS/2
etc. I, for one, am highly interested in improving the portability of
configure scripts to other arch, but, I think there are other things
to do first, then we will be able to cope with other environments.
Earnie> If interested I can send a diff file against version 2.13.
Yep, I am interested in seeing how you handled this, but I want to
kill (well, major plastic surgery) AC_PATH_PROG, so your patch will
probably not be applicable (hm, is this truly English?).
Thanks!
Akim
Re: Pirate Autoconf and CVS Autoconf
>>>>> "pipe" == Erez: | Akim, you could help folks like me by distributing some sort of wrapper | script that does the following: | | - run make test | - for every failed test, run the debug*.sh script and record its output | - remember to remove config.log etc. before running each debug*.sh test | - create a tar file of everything you need: configure, config.cache, | config.log's for each debug script, the debug scripts themselves, and the | full output of "make test". | - add anything else as needed | - uuencode the tar file As a first step, what is absolutely necessary is that the debug scripts dump the content of config.log. It is now clear that it would have helped us a lot to track down some of the failures you noticed, and they will actually always be needed. I don't have time right now to implement this, but this week-end I will probably sit down and fix some of the remaining issues. | Then, it would be easy for testers like myself to run such a script blindly, | and mail you the resulting archive that contains all the info you need. | That way we won't waste too much time b/t us: you ask "can you try X and | mail me the output of Y" and we have to re-run tests. Tom's scripts might help, indeed. Actually, this issue is so generic that it is surprising that there are no tools already developed. I wouldn't be surprised that François has something automated? Akim
