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
First, a little bit of context for people who don't read autoconf-patches. One of the major failures of Autoconf is its total lack of openness to other tools, and in particular it is wrong that automake parses configure.in and so on. Nobody better than m4 will read m4, nobody better than Autoconf can tell what autoconf does. Based on this idea, a patch was committed which uses m4's tracing features to provide the `client' with an easy to read trace of the macro expansions. This is much safer than parsing configure.in. For instance, consider the fact that automake needs to know all the output variables. It both reads configure.in and aclocal.m4 to find AC_SUBST, and also hard codes a list of `AC_MACRO -> output variables'. Hick. ~/src/ace % ./autoconf --trace AC_SUBST nostromo 9:51 configure.in:2:AC_SUBST:SHELL configure.in:2:AC_SUBST:CFLAGS configure.in:2:AC_SUBST:CPPFLAGS configure.in:2:AC_SUBST:CXXFLAGS configure.in:2:AC_SUBST:FFLAGS [CUT] This is much better, automake just has to parse this. But, the patch that was committed smashes all the new-lines in the arguments: AC_OUTPUT(Makefile src/Makefile) gives: configure.in:373:AC_OUTPUT:Makefile src/Makefile in addition, for technical but unjustified reasons, it will choke on any `@'. Alexandre added the wish to specify which argument you want (for instance automake is only interested in $1 of AC_OUTPUT etc.). He also spotted the fact that no difference is made between FOO([a,b]) and FOO(a, b). He doesn't want the `@' brain-damage (but why??? ;), and suggested an implementation based on hooks on the macros (other macros executed when a main macro is expanded). I have implemented the hook stuff. It's a pain, but it's doable. There are two failures: - the code for `ifset' is no longer valid. When you check the `defn' of a macro, it cannot be empty since there is the code to launch the hook. You can fix this by using a different macro to define pseudo-variables (the case above) and for the macros which `perform' something. Of course one will insert the code to run the hooks, while not the other. - every macro becomes extremely picky on the quotes, since there is embedded code which really depends upon [ and ]. Well, Autoconf itself had no problem, but a certain package for portably building libraries has several times this code: changequote(<<, >>)dnl << --enable-shared[=PKGS] build shared libraries [default=>>AC_ENABLE_SHARED_DEFAULT], changequote([, ])dnl note that AC_ENABLE_SHARED_DEFAULT is evaluated with << and >> as quotes, so it chokes. Once you wrote changequote(<<, >>)dnl << --enable-shared[=PKGS] build shared libraries [changequote([, ])default=>>AC_ENABLE_SHARED_DEFAULT[]changequote(<<, >>)], changequote([, ])dnl it works (there are other syntaxes possible, I'm not particularly for this one, but I'm really sad that [ and ] have been used to denote default values in Autoconf's --help. I'd be happy to change this. AC_HELP_STRING is also very fragile because of [ and ]). After this, Autoconf distchecks but the tests for autoupdate (you bet!!!). In my opinion, this is not the right track. This is only the beginning of the troubles. In addition, I see no reasons to lose the ability to trace the uses of `variables': ~ace % ./autoconf -m . --trace AC_LIST_FILES nostromo 10:09 configure.in:44:AC_LIST_FILES configure.in:44:AC_LIST_FILES configure.in:44:AC_LIST_FILES: ~ace % ./autoconf -m . --trace AC_LIST_FILES_COMMANDSnostromo 10:10 This gives me information. So you might think that m4 the C-program is the right place to install hooks (m4_addhook or something), but I know that René already has reentrancy issues to solve in m4, so adding such hooks would be a additional. And think just a second of a hook that messes around with quotes and syntax etc. B! But m4 could provide a better control over the output of the traces, but then we would depend upon m4 1.5. I don't consider this as wrong (Autoconf is a maintainer tool!), but I don't think 1.5 will be ready soon enough. So we *have* to deal with m4's --trace output. Part of the problem is that we have to parse balanced [ and ], ( and ) etc. and I must say I don't know how to do that in sh and Co (I'd be happy that someone teach me) (well, I don't mean counting them one by one in AWK :). There's an idea which is really attractive, and I would like to know what people think about it. Take a look at the raw output from m4: m4trace:configure.in:36: -1- AC_DEFINE([_ALL_SOURCE]) m4trace:configure.in:37: -1- AC_DEFINE([_POSIX_SOURCE], [1], [Define if you need to in order for `stat' and other things to work.]) m4trace:configure.in:37: -1- AC_DEFINE([_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 hi
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
Re: Pirate Autoconf and CVS Autoconf
> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes: Erez> Question: is the "make check" interface and behavior expected to Erez> be the same for all packages that use GNU auto*? For example, Erez> I've never seen these debug*.sh scripts generated for libtool Erez> and automake? It is actually irrelevant: the debug scripts are run by the test suite itself, so Automake needs not know about them. The only thing which we need is just to have the test suite dump the sick config.logs. Akim
Re: cvs version of autoconf
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> I disagree. In fact, I often recommend that people start Alexandre> their own macros with AC_uid_, so that autoconf prints an Alexandre> error if the macro fails to be properly expanded in the Alexandre> configure script. I disagree too :) You should have suggested uid_AC_. Akim
Re: Patch to avoid unnecessary uses of AC_TRY_RUN
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Olly> I'm unsure how `int a[0];' will be handled by various compilers. Tom> gcc accepts this as an extension. It is useful when using the Tom> "struct hack", at least. I don't understand what you are referring to. Could you give details? Akim
Re: cvs version of autoconf
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On Feb 23, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >>>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> >>>>>>> writes: Alexandre> I disagree. In fact, I often recommend that people start Alexandre> their own macros with AC_uid_, so that autoconf prints an Alexandre> error if the macro fails to be properly expanded in the Alexandre> configure script. >> I disagree too :) >> You should have suggested uid_AC_. Alexandre> But then autoconf wouldn't have flagged an error, would it? Yes.
Re: Integrating the macros of the archive?
> "Stephane" == Stephane Bortzmeyer <[EMAIL PROTECTED]> writes: Stephane> Since it seems a new version of autoconf is close, could I Stephane> ask that we integrate the macros in the official archive: Stephane> http://peti.cys.de/autoconf-archive/ Stephane> They are well tested (I maintain some Java macros and I can Stephane> testify that I receive bug reports, which is a good sign Stephane> that the archive is used) and would simplify the work of Stephane> developers. Stephane> I regret that Java or Perl is not supported "out of the box" Stephane> by autoconf. I'm only expressing my own feeling, and in no way a summary of the development team's opinion. Firstly, I think it is too early to integrate too many specialized macros in Autoconf. Yet the one we have are still buggy, out of dated, fragile to strict environments which require the prototypes (because many #includes are missing) etc. We first have to clean up the whole Autoconf so that we can step backward, look what happened, and write down the requirements on the wannabe-Autoconf macros. For me this step is in the medium term (2.17 or so). Nonetheless, of course, shortcomings of the current acspecific.m4 should be fixed. Secondly, and more importantly, the issue of other languages. Yet with the three languages we have, we have problems to solve. Tiny steps are made, but there are not enough. Again, the problem appears to be the programmer interface provided by Autoconf. This is, IMHO, much more urgent, and should be solved either for 2.15, or next to follow 2.16. Then, at this time, we will be able to integrate support for other languages. Since 2.15 is needed, I'd like to avoid adding this requirement to the spec of 2.15. Finally, IMHO, it is not the mission of Autoconf to be a constellation of specialized macros (I don't mean you believed it was, I just want to state publicly my opinion). The true nature of Autoconf is to provide the environment. Major improvements were done so that Autoconf is extendable. I would like to ask people to help us finalize Autoconf, which means, concentrate of the problems of today. It is too late to open new horizons to Autoconf but those which concerns the base programmer interface. We need it to be tested (yet there are problems on the test suite which are not fixed, so don't rush onto make check :), we need the documentation to be criticized, we need acspecific to be updated etc. Wide spread macros in the style of acspecific will be included, but only a small set of them (I'm thinking in particular to Paul's LARGE_FS macros). Akim
Re: Integrating the macros of the archive?
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: Bob> Autoconf is both a framework, and a collection of macros. Absolutely. Maybe there is a factor I should have stressed more: time. We don't have time now to integrate all these macros, we first have to finish the work needed by the base layer. Bob> While the framework is quite valuable, by itself it does not Bob> achieve the objective of improving the quality/portability of Bob> free software across many platforms. Inclusion of a macro in Bob> autoconf frees the free software developer to focus on his/her Bob> program rather than portability of a shell script fragment across Bob> many platforms (which may not even be available to the Bob> developer). I'm sorry, but I don't quite agree: your picture lacks the Autoconf macro archive. Its existence makes a huge difference with the former state of Autoconf. Bob> The value of a macro has little to do with whether it is Bob> "specialized" or not. If your measure is the number of macros which depend upon one macro, yes it does. Currently this is my main concern. The base layer of Autoconf is aged, it was not designed for some new problems, and we first have to clean it up so that everything downstream can use a saner ground. Until this is done, any work on terminal macros is wasting time, and in particular, integrating new macros now would slow down the development of Autoconf. Bob> There are many specialized macros which are of value to a large Bob> population of software projects. I suggest that the selection Bob> criteria should be based on how many existing projects/developers Bob> find the macro to be of value. Definitely! I insist on the fact I was not saying that there will never be new specific macros in Autoconf, I was just saying that there won't be many *in 2.15*. We are in a delicate balance between urgency and care. Akim
Re: A problem on anoncvs
We did not update the pages yet, time is lacking. Sorry. From: Akim Demaille <[EMAIL PROTECTED]> Subject: CVS Autoconf has moved To: Autoconf List <[EMAIL PROTECTED]> X-Sent: 1 day, 8 hours, 58 minutes, 32 seconds ago Resent-From: [EMAIL PROTECTED] 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: A problem on anoncvs
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes: Lars> It was only posted here _yesterday_. Yes, I apologize.
Re: Integrating the macros of the archive?
> "Olly" == Olly Betts <[EMAIL PROTECTED]> writes: Olly> The archive would be even more useful if there was a clear Olly> pointer to it in the autoconf documentation. A quick grep Olly> through all files for `autoconf-archive' (part of the URL) turns Olly> up nothing... That's correct. It's on the TODO list of Autoconf, as is updating the sourceware page. Akim
Re: Integrating the macros of the archive?
>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes: Russ> Akim Demaille <[EMAIL PROTECTED]> writes: >> I'm sorry, but I don't quite agree: your picture lacks the Autoconf >> macro archive. Its existence makes a huge difference with the >> former state of Autoconf. Russ> A macro archive by itself is useful but not sufficient to Russ> replace a set of useful macros distributed with autoconf. The Russ> advantage of having the macros distributed with autoconf is that Russ> one can then know for certain precisely which macros are Russ> available in a given version and not include a whole bunch of Russ> general macros in every package. I don't think we statically disagree, we just differ on the dynamics :) Russ> It may be worth considering whether autoconf should no longer Russ> serve as the general-purpose macro repository as well as the Russ> infrastructure, and instead a separate distribution with Russ> specific version numbers be created that will. At least technically this is what is currently happening. Was used to be reserved to the Autoconf maintainer is now available to end users. OTOH, it is also good that Autoconf keeps in touch with the real world, and swallows some specific macros, let it be to `dictate' the good coding style and the proper use of the API. Russ> It may be worthwhile considering whether to just break backwards Russ> compatibility to some degree and fix things once and for all, Russ> resulting in an autoconf 3 release. I sentimentally 100% agree with you, but unfortunately I sort of understood the incredible momentum users of Autoconf have. At first, since they are maintainers, I thought they'd easily agree on deep changes in the interface of Autoconf, but I had to realize this is not the case[1]. So now I'm more in favor of a soft transition (which does not mean there are no earth quakes underneath :). Akim [1] I am criticizing nobody. I'm amongst the most fervent detractors of Autoconf because it requires too much knowledge from the maintainers who use it, so I am certainly not criticizing maintainers who don't want to learn again something they just shouldn't know. It just happens to be different from what I first imagined.
Re: checking for fixed-size types
> "lars" == lars brinkhoff <[EMAIL PROTECTED]> writes: lars> To check for e.g. uint16_t, I could do AC_CHECK_TYPE(uint16_t, lars> unsigned short) , but this seems sub-optimal considering that lars> 'unsigned short' isn't necessarily 16 bits wide. lars> Is there a better macro for this? Well, you did not check, you REPLACEd uint16_t. You can actually AC_CHECK_TYPES((uint16_t)), which will define HAVE_UINT16_T or not, then you can use AC_CHECK_SIZEOF to look for the replacement you need: #if! HAVE_UINT16_T # if SIZEOF_UNSIGNED == 16 typedef unsigned uint16_t; # elsi SIZEOF_UNSIGNED_SHORT == 16 typedef unsigned short uint16_t; # else etc. etc. (I'm not sure I answered the right question ;) Akim
Re: Integrating the macros of the archive?
>>>>> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes: Earnie> --- Akim Demaille <[EMAIL PROTECTED]> wrote: >> >>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes: Russ> It may be worthwhile considering whether to just break backwards Russ> compatibility to some degree and fix things once and for all, Russ> resulting in an autoconf 3 release. >> I'm more in favor of a soft transition (which does not mean there >> are no earth quakes underneath :). Earnie> This could be affected with a package rename/fork. Change the Earnie> name to Autoconf2 and allow the major focus of change be to Earnie> Autoconf2 and only minor bug fixes for Autoconf. This is what I was answering to, changing the name does not change the momentum. It appears more changes are possible without breaking anything than I first thought. We will push this logic as far as it can go, then maybe it will be time to break something. Right now, there are compromises, but not enough to force the big jump. Akim
Re: The Universal Source Package: GNU Autoconf Solves Only Part of the Problem
> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes: Earnie> So, I would like to suggest that instead of Earnie> --prefix=/usr/local as the default that Earnie> --prefix=/opt/package-major.minor.patch be the default. Earnie> Comments? You're touching the untouchable, the GNU standards. Drop it :) Anyway, not everybody has an /opt (are your running Solaris? :), and your suggestion introduces a lot of hidden problems (what of the man pages, info files, NLS_PATH, libraries etc.). This is left to the installer, and it is a good thing. Akim
Re: Patch to avoid unnecessary uses of AC_TRY_RUN
Thanks, Paul and Tom, for the details. Akim
Re: AC_CHECK_TYPE search locations
> "Tomas" == Tomas Berndtsson <[EMAIL PROTECTED]> writes: Tomas> AC_CHECK_TYPE only looks in some header files for the Tomas> type. But, for other types, there is no way to specify what Tomas> header file(s) to look in. For example, the new ISO C 9X Tomas> standard have uint16_t in stdint.h, included in inttypes.h but Tomas> not in sys/types.h. Thus, AC_CHECK_TYPE cannot find it. Solved in the development copy. Thanks! Akim
Re: AC_CHECK_TYPE search locations
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Tomas> For example, the new ISO C 9X standard have uint16_t in Tomas> stdint.h, included in inttypes.h but not in sys/types.h. Thus, Tomas> AC_CHECK_TYPE cannot find it. Akim> Solved in the development copy. Thanks! BTW, should we put stdint.h or inttypes.h into the default includes? Where can the std be found to know who they are? Akim
Re: Integrating the macros of the archive?
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Olly> The archive would be even more useful if there was a clear Olly> pointer to it in the autoconf documentation. A quick grep Olly> through all files for `autoconf-archive' (part of the URL) turns Olly> up nothing... Akim> That's correct. It's on the TODO list of Autoconf, as is Akim> updating the sourceware page. Tom> I think if we're going to mention it from the docs then we have Tom> to move it to a GNU server. ??? Pardon ??? We cannot point to a non FSF server from within a GNU documentation?
Re: xemacs configure script doesn't have AC_DEFINE
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: Paul> In the current autoconf draft, @BKL@ and @BKR@ expand to left Paul> and right brackets; that should get you want you want. (Those Paul> names should get changed to @LBK@ and @RBK@, since differences Paul> in similar names should appear first, not last.) I'm very OK with changing them. I buy any suggestion of names. Currently there are four guys: s/@BKL@/[/g s/@BKR@/]/g s/@DLR@/$/g s/@PND@/#/g Paul> Perhaps you missed the earlier discussion about quoting on the Paul> autoconf mailing list. Yep, Martin, you should try to look for it in the archive. Anyway, a major rewriting of the documentation wrt quoting is needed, so some day, you'll *have* to read it ;) Paul> My own feeling is that the quoting rules in autoconf should be Paul> cleaned up even more than the current draft cleans them up, and Paul> then documented cleanly; but the consensus was to keep things Paul> irregular, murky, and undocumented in the interest of backward Paul> compatibility, and to defer further cleanups until later, in Paul> order to get something out of the door sooner. This is OK with Paul> me, but I don't want excessive backward compatibility concerns Paul> to stymie even the modest progress that's been made so far. I don't think we disagree Paul. We do want to fix the quoting issues, but, although I share much of your feelings wrt the level of compatibility we should aim to, we will probably do it via another set of correctly quoted macros. I.e., people will have to get used to no longer using AC_TRY and the like, but AC__. Currently, I'm thinking of AC_COMPILE_IF(PROGRAM, TRUE, FALSE) AC_CPP_IF(TEXT, TRUE, FALSE) etc. Akim
Re: xemacs configure script doesn't have AC_DEFINE
| >>>>> "AD" == Akim Demaille <[EMAIL PROTECTED]> writes:
| AD> So I pulled out the definition of the macro out of AC_OUTPUT, removed
| AD> the useless (or have I missed something) changequote (changequote is
| AD> *hell*), and it works.
|
| AD> dnl CPP_MAKEFILE(CPPFLAGS,filename)
| AD> define([CPP_MAKEFILE],
| AD> [echo creating $dir/[$2]
| AD> $CPP -I. -I${top_srcdir}/src [$1] junk.c \
| AD> dnl Delete line directives inserted by $CPP
| AD> | sed -e 's/^\#.*//'\
| AD> dnl Delete spurious blanks inserted by $CPP
| AD> -e 's/^[[ TAB][ TAB]]*$//'\
| AD> -e 's/^ /TAB/' \
| AD> dnl Delete blank lines
| AD> | sed -n -e '/^..*$/p' \
| AD> dnl Restore lines quoted above to original contents.
| AD> | sed '/^\"/ {
| AD> s/\\\([\"]\)/\1/g
| AD> s/^[[ TAB]]*\"//
| AD> s/\"[[ TAB]]*$//
| AD> }' > Makefile.new
| AD> chmod 444 Makefile.new
| AD> mv -f Makefile.new [$2]
| AD> ])dnl CPP_MAKEFILE
|
| Well, TAB is a macro defined to you-know-what, and I know of no way to
| quote a non-paired quote character, so [ TAB] cannot be properly
| expanded without changequote. Of course, we could use a real tab
| character in the source instead of TAB, but that would be less
| readable.
OK, I thought TAB was handle by sed somewhere, as @BKL@ mentioned by
Paul.
So indeed you need a changequote because you want both 1. literal [],
2. macro expansion.
But then, what is the point of 2.? Why don't you just use a literal
tab? Then, what i wrote is fine.
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/^[[ ][ ]]*$//'\
-e 's/^ / /' \
dnl Delete blank lines
| sed -n -e '/^..*$/p'\
dnl Restore lines quoted above to original contents.
| sed '/^\"/ {
s/\\\([\"]\)/\1/g
s/^[[ ]]*\"//
s/\"[[ ]]*$//
}' > Makefile.new
chmod 444 Makefile.new
mv -f Makefile.new [$2]
])dnl CPP_MAKEFILE
BTW, your quoting is not homogeneous with that used in Autoconf. The
rule is now one level of [] for each evaluation, ie. each pair of ().
In particular in the macro above, no single occurrence of $1/$2 should
be quoted.
*Yes* it means that that if you want to use a macro name as $1 it must
be quoted twice at the top level. But that's the price the pay for
uniformity. Double-quoting macros are a pain.
| Regarding your comment about defining a macro inside AC_OUTPUT: it's a
| general principle of good software engineering to define everything as
| close to its use and in as small a scope as possible. So logically,
| if it's only used in AC_OUTPUT, what better place to define it?
In m4/cpp-makefile.m4. Defining macros in configure.in is not a good
idea IMHO. Yet as an argument of another macro, this is sadism :)
Akim
Re: [BUG] AC_OUTPUT has wildly different semantics
> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: Martin> Notice that AC_DEFINE seems to get undefined because of its Martin> appearance in a _comment_ in AC_OUTPUT. Bizarre! No, you are abused by the error message. The message is triggered because autoconf.sh saw something which looks very much like a macro in configure (the output), via an egrep A[CHM]_. And then it reports to you what it saw pretending it was undefined. This example will make it clear to you: /tmp % echo "AC_INIT\n[AC_INIT]" > configure.in nostromo 9:20 /tmp % autoconf nostromo 9:21 autoconf: Undefined macros: configure.in:1:AC_INIT configure.in:2:[AC_INIT] You'll also note it thinks the first occurrence is undefined, which is dead wrong, it has been expanded. But when it browsed configure for unexpanded macros, it found AC_INIT, since the user does not care where AC_INIT appears in the output, but wants to know where it appeared in the input, it grepped AC_INIT in configure.in, hence the message you read. In your case, since the arguments of AC_OUTPUT were quoted, the unexpanded macro name triggered the problem. I'll look into the details of your bug report, thanks. Akim
Re: [BUG] AC_INIT_NOTICE legal notice mixed with code
| AC_INIT_NOTICE claims: | # Generated automatically using Autoconf version ]AC_ACVERSION[ | # Copyright (C) 1992, 93, 94, 95, 96, 98, 99, 2000 | # Free Software Foundation, Inc. | # | # This configure script is free software; the Free Software Foundation | # gives unlimited permission to copy, distribute and modify it. | | The configure script consists of pieces copyrighted by the FSF and | other pieces copyrighted by the author of configure.in, who may or may | not be the FSF. Autoconf has no way of knowing what the licensing | conditions of configure.in are, or who the authors are. All it can | say is that the portions of the configure script that are part of the | autoconf package have unlimited permission to copy, distribute and | modify. | | As it currently stands, a configure.in script which is merely GPLed | would be legally _required_ to redefine AC_INIT_NOTICE. | | (Forgive me for being pedantic, but I've learned from rms) Aah, now you're talking like a real XEmacs guy :) I share your opinion, but I don't feel I am competent to decide anything about this. I'd like that people who know, talk. We also need to take into account what we know will be possible from the FSF, and what will never be. I CCed to you François, because I would like to have your opinion too. | Which makes it tougher to portably incorporate the variable | definitions in AC_INIT_NOTICE: | | ac_arg_with_help= | ac_arg_enable_help= | | ... | | More generally, the initial copyright notice should be separated | logically from the initial variable initialization. Try to think | about some other mechanism to include default variable values. I agree. | Probably you have some reason for why ac_arg_with_help and friends | cannot be initialized in AC_INIT_PARSE_ARGS, for example, where other | variables are initialized. It is true it makes our life easier like this. We can introduce a Copyright diversion, where you could easily append your notices. Would that be enough? | One way to allow separate overrides is: | | AC_DEFUN(AC_PACKAGE_COPYRIGHT_NOTICE,[]) dnl override me | | AC_DEFUN(AC_FSF_COPYRIGHT_NOTICE, | [# Generated automatically using Autoconf version ]AC_ACVERSION[ | # Copyright (C) 1992, 93, 94, 95, 96, 98, 99, 2000 | # Free Software Foundation, Inc. | # | dnl must be a better way to say that... | # The portions of this configure script generated by autoconf are | # free software; the Free Software Foundation gives unlimited | # permission to copy, distribute and modify them. | ] | | | AC_DEFUN(AC_INIT_NOTICE, | [AC_FSF_COPYRIGHT_NOTICE | AC_PACKAGE_COPYRIGHT_NOTICE | AC_INIT_DEFAULT_VARIABLE_VALUES | ] | | although I would still look for a better place to initialize | variables than AC_INIT_NOTICE Akim
Re: passing command-line switches to compiler
> "CyberPsychotic" == CyberPsychotic <[EMAIL PROTECTED]> writes: CyberPsychotic> ~ : ~ : - Macro: AC_CHECK_DECL (SYMBOL, CyberPsychotic> [ACTION-IF-FOUND], ~ : [ACTION-IF-NOT-FOUND], CyberPsychotic> [INCLUDES]) CyberPsychotic> This one sounds exactly what I am looking for, but I This is exactly the same as what Ian does. Well, a few difference, but the same idea: we just need to know if the symbol is an r-value. CyberPsychotic> am using autoconf 1.4.1 package (shipped with CyberPsychotic> r.h. 6.0) and this macro isn't defined there, starting Can you tell me who packaged Autoconf 2.14.1 (I guess that's what you meant). CyberPsychotic> sourceware.cygnus.com and ftp.gnu.org which used to CyberPsychotic> distribute autoconf in past and they both have the CyberPsychotic> tarballs of Jan. 16, 1999 as most recent ones. if CyberPsychotic> there was any development of autoconf package since CyberPsychotic> that time, it's definitely not the latest snapshot :) Huh? There are beta Autoconf somewhere? Akim
Re: passing command-line switches to compiler
Changequotebusters!
If there's something strange in your neighborhood
Who you gonna call?
Quotebusters!
If there's something weird and it don't look good
Who you gonna call?
Quotebusters!
I ain't afraid of no quote
I ain't afraid of no quote
If you're seeing things running through your head
Who can you call?
Quotebusters!
An invisible man sleeping in your bed
Oh, who you gonna call?
Quotebusters!
I ain't afraid of no quote
I ain't afraid of no quote
Who you gonna call?
Quotebusters!
If you're all alone, pick up the phone
And call
Quotebusters!
I ain't afraid of no quote
I hear it likes the girls
I ain't afraid of no quote
Yeah, yeah, yeah, yeah
Who you gonna call?
Quotebusters!
If you've had a dose of a freaky quote
You'd better call
Quotebusters!
Let me tell you something
Bustin' makes me feel good
I ain't afraid of no quote
I ain't afraid of no quote
Don't get caught alone, oh no
Quotebusters!
When it comes through your door
Unless you just want some more
I think you better call
Quotebusters!
Ow!
Who you gonna call
Quotebusters!
{Repeat to fade}
| One problem with a "provide decl" check is that different systems need
| different declarations for the same function.
|
| This isn't good, but it's reality.
|
| As a worst case, I remember versions of IRIX that declared main() in a
| unique way; If main was declared with a normal prototype, the code would
| not compile.
|
| While it's no fun, the NTP configure.in does things like this:
|
| case "$target" in
| changequote(<<, >>)dnl
| *-*-osf[45]*)
| changequote([, ])dnl
Kill the changequotes and use
*-*-osf[[45]]*)
| AC_DEFINE(DECL_PLOCK_0)
| AC_DEFINE(DECL_STIME_1)
| ;;
| *-*-riscos4*)
| AC_DEFINE(DECL_ADJTIME_0)
| AC_DEFINE(DECL_BZERO_0)
| AC_DEFINE(DECL_IOCTL_0)
| AC_DEFINE(DECL_IPC_0)
| AC_DEFINE(DECL_MEMMOVE_0)
| ...
|
| acconfig.h has things like:
|
| /* setitimer()? */
| #undef DECL_SETITIMER_0
|
| /* setpriority()? */
| #undef DECL_SETPRIORITY_0
| #undef DECL_SETPRIORITY_1
|
| and one of the distribution headers contains lines like:
|
| #ifdef DECL_SETPRIORITY_0
| extern int setpriority P((int, int, int));
| #endif
| #ifdef DECL_SETPRIORITY_1
| extern int setpriority P((int, id_t, int));
| #endif
|
| H
|
|
Re: bug in tests/Makefile.am
> "Patrick" == Patrick Tullmann <[EMAIL PROTECTED]> writes: Patrick> The 'testsuite' target in tests/Makefile.am uses 'm4' in its Patrick> rules where it should use '$(M4)'. Patrick> This is in today's CVS snapshot. Thanks, I'll fix it soon. Akim
Re: passing command-line switches to compiler
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: Harlan> In others, we have found that including some of these headers Harlan> causes problems on other systems, and it's just too difficult Harlan> for me to track these interdependency problems down (we only Harlan> have a half-dozen or so different platforms available to the Harlan> UDel NTP testing flock). This is typically something which should be solved in the future with autosystem + system.h used as default include, because you are going to test what you really use. Akim
Re: xemacs configure script doesn't have AC_DEFINE
> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: Martin> I agree that the level of quoting in all autoconf macros Martin> should be consistent. This may be worth breaking Martin> compatibility with current configure.in's. But incompatible Martin> changes should be reserved for major version changes like 3.0. You're talking of extreme situations. Most packages use literals as argument to AC_OUTPUT, and this is what I am concentrating on. I still have to check your report in details though. AD> Defining macros in configure.in is not a good idea IMHO. Yet as AD> an argument of another macro, this is sadism :) Martin> This would not be the case if m4/autoconf was reasonable. Martin> Many macro calls contain "code" as an argument. That code can Martin> in turn contain m4 macro calls. So why not also `define'? Martin> But this is just philosophy. Agreed. I could not come with unbeatable arguments to prove you're wrong, it's only a feeling, but a strong one. configure.in is addressing an issue which should be almost entirely declarative, and let it be only for this reason, facts and rules should be separated. Martin> I realize the real world of autoconf is already horribly ugly, Naaah, it has its own esthetics, which is very much like modern art, indeed :) Martin> and you have to make engineering solutions that work, never Martin> mind the esthetics. We are improving this factor. Some day your configure.in will be beautiful :) Martin> And I'm willing to make reasonable changes to my configure.in Martin> to incorporate improvements in autoconf. Thanks. Conversely, we will certainly adopt many of your specificities, so in the medium term, we will come up with better Autoconves and Xemacs-configure :) Akim
Re: [BUG] AC_OUTPUT has wildly different semantics
>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: >>>>> "AD" == Akim Demaille <[EMAIL PROTECTED]> writes: >>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes: Martin> Notice that AC_DEFINE seems to get undefined because of its Martin> appearance in a _comment_ in AC_OUTPUT. Bizarre! AD> No, you are abused by the error message. The message is triggered AD> because autoconf.sh saw something which looks very much like a AD> macro in configure (the output), via an egrep A[CHM]_. And then AD> it reports to you what it saw pretending it was undefined. Martin> I don't know how hard it would be to implement, but it would Martin> be better to search for Martin> \bAC_ Martin> since you currently get hits on XAC_DEF I do think that indeed there was no \b because doing this portably is a pain. But anyway we grew used to this, and have found some advantages, such as your present case. If your macro is named XE_AC_CHANGE_COMPLETELY_THE_INTERNALS_OF_AUTOCONF and it is not expanded, then Autoconf will issue a complaint (with a `T', it's the noun, not the verb :). With your change, you'll know nothing. Martin> Even better would be to look for exact symbols in the output Martin> that have a definition, so the word AC_ in the output would Martin> generate no error message, while AC_DEFINE would. s/DEFINE/DEFUN/, don't you? Martin> And of course, you should only report hits corresponding to Martin> the original source files. Once tracing works, it might be doable, but currently it's overkill. Akim
Autoconf --trace
Hi,
I have spent some time on the tracing issue in Autoconf, and I have
promising results, but there are a few things on which I would like
advises, comments etc.
If people are interested to toy with it, it is attached below. You
have to configure it as if it were autoconf, i.e.
./config.status --file autotrace:autoconf.sh.traces
chmod +x autotrace
(it is a proto autoconf, not a different prog, you can name it
autoconf if you trust me :-).
My first question is related to what we want to trace. I find it
extremely useful to be able to trace autoconf.m4, eg the AC_DEFUNs:
~ace % ./autotrace --trace 'AC_DEFUN:$1' nostromo 13:10
AC_INIT_NOTICE
AC_PREFIX_DEFAULT
AC_INIT_PARSE_ARGS
AC_INIT_BINSH
AC_INIT
CUT
but most of the use will be on user's configure.in only. Should we
introduce a switch which allows to trace on or both?
Second, it works extremely well when you specify a finite list of args
to list:
~ace % ./autotrace --trace 'AC_OUTPUT:$f:$l:$1' nostromo 13:14
configure.in:45:acversion.m4 Makefile m4/Makefile man/Makefile doc/Makefile
tests/Makefile tests/atconfig
arg, there's a new line in there. Let's make sure we can track it:
~ace % ./autotrace --trace 'AC_OUTPUT:$f:$l:[$1]'nostromo 13:15
configure.in:45:[acversion.m4 Makefile m4/Makefile man/Makefile doc/Makefile
tests/Makefile tests/atconfig]
No particular reason for []
Or one could fill up a more or less Perl structure:
~ace % ./autotrace --trace 'AC_SUBST:ac_subst{"$1"} = "$f:$l"' nostromo 13:16
ac_subst{"ECHO_C"} = "configure.in:2"
ac_subst{"ECHO_N"} = "configure.in:2"
ac_subst{"ECHO_T"} = "configure.in:2"
ac_subst{"SHELL"} = "configure.in:2"
ac_subst{"CFLAGS"} = "configure.in:2"
ac_subst{"CPPFLAGS"} = "configure.in:2"
ac_subst{"CXXFLAGS"} = "configure.in:2"
ac_subst{"FFLAGS"} = "configure.in:2"
ac_subst{"DEFS"} = "configure.in:2"
what should make automake much easier (I don't know actual, just a
thought).
Now my problem is with $@:
~ace % ./autotrace --trace 'AC_SUBST:$@' nostromo 13:18
[configure.in],[2],[1],[ECHO_C]
[configure.in],[2],[1],[ECHO_N]
[configure.in],[2],[1],[ECHO_T]
[configure.in],[2],[1],[SHELL]
[configure.in],[2],[1],[CFLAGS]
[configure.in],[2],[1],[CPPFLAGS]
[configure.in],[2],[1],[CXXFLAGS]
[configure.in],[2],[1],[FFLAGS]
[configure.in],[2],[1],[DEFS]
[configure.in],[2],[1],[LDFLAGS]
[configure.in],[2],[1],[LIBS]
[configure.in],[2],[1],[exec_prefix]
As you can see, my technical trick which consists in giving file,
lineno and depth to the tracing macro is visible. In order to
avoid that there are macro expansions performed on the arguments, I
did quote twice, which means I can't just
`s/$@/shift(shift(shift($@)))/' and have the right thing happen:
~ace % ./autotrace --trace 'AC_SUBST:shift(shift(shift($@)))'nostromo 13:19
shift(shift(shift([configure.in],[2],[1],[ECHO_C])))
shift(shift(shift([configure.in],[2],[1],[ECHO_N])))
shift(shift(shift([configure.in],[2],[1],[ECHO_T])))
Also, I see no immediate means to specify another technique to
separate $@ than [], [], no means to :.:.:.: as above.
Is this a limitation with which we can live?
Are there any suggestions?
Akim
PS/ Yes, there's a small bug which I observed here but not at home:
here all my traces were preceded with two white lines (which I removed
from the message). It will be fixed.
#! @SHELL@
# autoconf -- create `configure' using m4 macros
# Copyright (C) 1992, 93, 94, 96, 99, 2000 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
# 02111-1307, USA.
# If given no args, create `configure' from template file `configure.in'.
# With one arg, create a configure script on standard output from
# the given template file.
me=`echo "$0" | sed -e 's,.*/,,'`
usage="\
Usage: autoconf [OPTION] ... [TEMPLATE-FILE]
Generate a configuration script from a TEMPLATE-FILE if given, or
\`configure.in' by default. Output is sent to the standard output if
TEMPLATE-FILE is given, else into \`configure'.
If the option \`--trace' is used, no configuration script is created.
-h, --help print this help, then exit
--version print version number, then exit
-m, --macrodir=DIR directory storing Autoconf's macro files
-l, --localdir=DIR directory storing the \`aclocal.m4' file
Re: @BKL@, @BKR@, etc.
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: Paul> Here's an idea: why don't we borrow symbols from the C standard? Man, I'm really surprised. I well remember, in a thread on the metric system, you said (almost word by word), that `we will probably come to metric system, but we, American, are never going to come to trigraphs' :) :). Paul> The C Standard has the digraphs <: for [, :> for ], and %: for Paul> #. C doesn't have a digraph for $, but I would suggest S|, as Paul> the idea seems to be "mentally overprint the characters to get Paul> an approximation to the symbol". So we could have this: Paul> s/@<:@/[/g s/@:>@/]/g s/@S|@/$/g s/@%:@/#/g Can we consider these guys are unlikely enough to avoid using @@? Paul> An advantage of this approach is that it doesn't usurp the Paul> user's name space the way that @BKL@ etc. do. Absolutely. I like this idea. Akim
Re: passing command-line switches to compiler
| > | changequote(<<, >>)dnl | > | *-*-osf[45]*) | > | changequote([, ])dnl | | Akim> Kill the changequotes and use | Akim>*-*-osf[[45]]*) | | I usually recommend *against* this, on the grounds that it is too | subtle. Well, there are other writings such as: [ *-*-osf[45]*)] or [*-*-osf[45]*]) but changequote should be banished from our community. Akim
Re: Autoconf --trace
Yeehaa, Yahoo, Yipee and the like! Well, there are some significant steps forward since yesterday :) Gosh, it feels good when m4 finally agrees to do what you wanted to :-) I have implemented support for $.@, which is [$1].[$2]. etc. (`.' is the separator, defaults to comma), and for $.*, which is smash($1).smash($2). etc., where `.' defaults to `:', and `smash' singles out all the white spaces. If you required no tracing format, you get `$f:$l:$n:$*', i.e., for instance: ~fu % ~ace/autotrace -m ~ace --trace AC_DEFINE ./aclocal.m4:1694:AC_DEFINE:AFS:1:Define if you have the Andrew File System. configure.in:12:AC_DEFINE:_GNU_SOURCE configure.in:22:AC_DEFINE:_ALL_SOURCE configure.in:23:AC_DEFINE:_POSIX_SOURCE:1:Define if you need to in order for `stat' and other things to work. or even: ~fu % ~ace/autotrace -m ~ace --trace 'AC_OUTPUT:With quotes: $@ without: $*' With quotes: [Makefile doc/Makefile intl/Makefile lib/Makefile man/Makefile m4/Makefile po/Makefile.in src/Makefile tests/Makefile tests/chmod/Makefile tests/cp/Makefile tests/dd/Makefile tests/dircolors/Makefile tests/install/Makefile tests/ln/Makefile tests/ls/Makefile tests/ls-2/Makefile tests/mkdir/Makefile tests/mv/Makefile tests/rm/Makefile tests/rmdir/Makefile tests/shred/Makefile tests/touch/Makefile ] without: Makefile doc/Makefile intl/Makefile lib/Makefile man/Makefile m4/Makefile po/Makefile.in src/Makefile tests/Makefile tests/chmod/Makefile tests/cp/Makefile tests/dd/Makefile tests/dircolors/Makefile tests/install/Makefile tests/ln/Makefile tests/ls/Makefile tests/ls-2/Makefile tests/mkdir/Makefile tests/mv/Makefile tests/rm/Makefile tests/rmdir/Makefile tests/shred/Makefile tests/touch/Makefile worse yet: | /tmp % cat foo | define([foo]) | foo([several | | | lines]) | | foo([a\ | big\ | token]) | /tmp % ~ace/autotrace --trace foo -m ~ace foo | foo:5:foo:several lines | foo:9:foo:abigtoken Bwahaha :) So I think we will be able to start using this in Automake, no? Well, of course there are problems. The first one being that if you trace an m4 builtin, weird things happen. This can be solved by undefining them. Akim PS/ Beware there is a literal ^Q in it, which you need if you want this to work properly. BTW, is it normal that bash does not split around ^A? I found nothing like this in the doc: | ~ace % cat -v /tmp/ifs | list="a^Qb" | IFS="^Q" | for i in $list | do | echo $i | done | | list="a^Ab" | IFS="^A" | for i in $list | do | echo $i | done | ~ace % bash /tmp/ifs | /tmp/ifs: /tmp/ifs: cannot execute binary file Naah, come on, it is not binary! | ~ace % cat -v /tmp/ifs | #! /bin/sh | | list="a^Qb" | IFS="^Q" | for i in $list | do | echo $i | done | | list="a^Ab" | IFS="^A" | for i in $list | do | echo $i | done | ~ace % bash /tmp/ifs | a | b | ab while zsh (with emulate sh) splits it properly. GNU bash, version 2.04.0(1)-beta5 (i386-pc-linux-gnu) Copyright 1999 Free Software Foundation, Inc. #! @SHELL@ # autoconf -- create `configure' using m4 macros # Copyright (C) 1992, 93, 94, 96, 99, 2000 Free Software Foundation, Inc. # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA # 02111-1307, USA. # If given no args, create `configure' from template file `configure.in'. # With one arg, create a configure script on standard output from # the given template file. me=`echo "$0" | sed -e 's,.*/,,'` usage="\ Usage: autoconf [OPTION] ... [TEMPLATE-FILE] Generate a configuration script from a TEMPLATE-FILE if given, or \`configure.in' by default. Output is sent to the standard output if TEMPLATE-FILE is given, else into \`configure'. If the option \`--trace' is used, no configuration script is created. -h, --help print this help, then exit -V, --version print version number, then exit -d, --debug don't remove temporary files -m, --macrodir=DIR directory storing Autoconf's macro files -l, --localdir=DIR directory storing the \`aclocal.m4' file -t, --trace=MACRO report the list of ca
