Re: autoconf option fun
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: >> Yep, I'm in favor of removing all the --a* etc. it makes it >> uselessly ambiguous, and short options are a better means to >> abbreviate. And trying to support exact abbreviations, as is done >> in configure, is an additional tedious maintenance nightmare. Alexandre> Agreed. But beware that this decision goes against the GNU Alexandre> Coding Standards. Yes. It's only for sake of simplicity of the maintenance that I want to avoid this. It's a real nightmare to walk that road, since basically each time you add/remove/alter an option, you have to rethink the whole option processing. Alexandre> I guess we should have an m4sh (or m4sugar?) macro to Alexandre> expand: Alexandre> m4_case_longopt([foo]) Alexandre> to Alexandre> --foo | --fo | --f Alexandre> and Alexandre> m4_case_longoptarg([foo]) Alexandre> to Alexandre> --foo=* | --fo=* | --f=* Yes, that's definitely the plan. In fact, I have even bigger ambitions: some kind of a getopt which would understand by itself that --version and --verbose share a prefix etc. That's one of the reasons why I can't wait for Gary's M4, since I don't believe it is reasonable to try to implement such a getopt in pure M4: a module would be most welcome. AS_GETOPT([help, h], [# do your stuff], [version, V], [echo "$version"; exit], [verbose, v], [verbose=echo], [m4dir, autoconf-dir, macro-dir, m], [m4dir=$[1]] ...)
Re: ac_cv_prog_gcc
| Hello, Akim! | > > $ac_cv_c_compiler_gnu() = yes; | > | > Akim> Heck. Thanks for noticing :( | > | > I'm checking in the fix, thanks! | > | > * aclang.m4 (ac_cv_prog_gcc, ac_cv_prog_gxx, ac_cv_prog_g77): | > Be AU_DEFUN'd, not AU_ALIAS'd. | | I'm afraid you are fixing the symptoms, not the cause. Nope, I was exactly curing the cause. AU_ALIAS aliases an old macro to a new one. In the present case, we are not talking about macros. | For example, AC_CANONICAL_SYSTEM is converted by autoupdate to | | AC_CANONICAL_TARGET([]) | | I understand that the role of autoupdate is to create a script conforming | with the today's guidelines. I don't think that giving an empty argument | to AC_CANONICAL_TARGET is what we recommend users to do. Just some information you might have missed: 2000-11-03 Akim Demaille <[EMAIL PROTECTED]> * acgeneral.m4 (AU_ALIAS): Don't forget to pass the arguments to the new macro... Reported by Ezra Peisach. * tests/semantics.m4 (AC_HAVE_FUNCS): New test. * tests/tools.at (autoupdate): As a benign side effect, updating a macro that takes no argument produces `UPDATED([])', no longer `UPDATED()'. Adjust the test. | The problem appears to be in the definition of AU_DEFUN. It adds | parentheses unconditionally. Maybe we need another AU_DEFUN, without | parentheses? I think you mean AU_ALIAS, not AU_DEFUN? Well, anyway these parens are important, otherwise you just don't pass the arguments from the old macro name to the new one. That's the PR that was filled about AC_HAVE_FUNCS not working.
Re: ac_cv_prog_gcc
| On Nov 7, 2000, Pavel Roskin <[EMAIL PROTECTED]> wrote: | > Hello, Akim! | >> > $ac_cv_c_compiler_gnu() = yes; | >> | Akim> Heck. Thanks for noticing :( | >> | >> I'm checking in the fix, thanks! | >> | >> * aclang.m4 (ac_cv_prog_gcc, ac_cv_prog_gxx, ac_cv_prog_g77): | >> Be AU_DEFUN'd, not AU_ALIAS'd. | | > I'm afraid you are fixing the symptoms, not the cause. | | I agree. When $# is 0, we shouldn't add parentheses. If we do this, we expose ourselves to new problems. Don't forget that these parens are separators, and if we don't force them, we might have unexpected results, hard to track down. For instance if for some reason the user had AC_CANONICAL_SYSTEM([This macro computes $host])(echo "$host) then autoupdate with parens (the current one) will produce AC_CANONICAL_TARGET([])(echo "$host) which is correct, while without parens you'd produce this: AC_CANONICAL_TARGET(echo "$host) which is wrong. This is why it is important to distinguish mappings from macros to macros (AU_ALIAS), from the other kinds of redefinition. Yes, I agree my example is very uncommon and was made to demonstrate my point, but in my M4 experience I have found this problem several times (having a macro understand a pair of parens that was not meant for it just because some () or [] was not separating them. Of course there are several macros invocations in between). So the question, IMHO, is more like should we struggle for AC_CANONICAL_TARGET() instead of AC_CANONICAL_TARGET([])? I don't think so (but it is true I'm never really happy to go and play again with the autoupdate system). It is not bad style to write ([]). I agree in the case of AC_CANONICAL_TARGET it is surprising, but think of all the other macros which do take an optional argument. And also, remember that this pair of parens is added *only* when autoupdate really updates, it will not add them to macro invocations without arguments: | /tmp % cat configure.in | AC_INIT | AC_CANONICAL_SYSTEM | /tmp % $ace/autoupdate -A $ace | autoupdate: `configure.in' is updated | /tmp % cat configure.in | AC_INIT | AC_CANONICAL_TARGET([]) Here it does add the ``parets''. But below, since AC_CANONICAL_TARGET is not AU'ed the three times ```configure.in' is unchanged''. | /tmp % cat configure.in | AC_INIT | AC_CANONICAL_TARGET([]) | /tmp % $ace/autoupdate -A $ace | autoupdate: `configure.in' is unchanged | /tmp % cat configure.in | AC_INIT | AC_CANONICAL_TARGET() | /tmp % $ace/autoupdate -A $ace | autoupdate: `configure.in' is unchanged | /tmp % cat configure.in | AC_INIT | AC_CANONICAL_TARGET | /tmp % $ace/autoupdate -A $ace | autoupdate: `configure.in' is unchanged
Re: Forbidden strings
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> Hello, Akim! >> The one and only approach is the current one. Let's stop >> reinventing the wheel. Pavel> That's probably too stronly worded :-) I agree, and I apologize. >> But what's the point??? Pavel> The point is uniformity. Remember how you were renaming all m4 Pavel> macros so that they would begin with m4. Yep, precisely! Pavel> Autoconf developers may need to distinguish separate componets, Pavel> by for the end user all those m4_ifval, AC_MSG_ERROR and Pavel> AS_EXIT are parts of the same package - Autoconf. If the division was unclear, I'd agree with your point. But here the separation between AU_ and AC_ is clear, between m4_ and AC_ it is too, AH_ shares nothing in common with AS_ etc. Pavel> I'm not going to change your mind. Go ahead if you have a Pavel> strong opinion. I do :) Pavel> Just take my advice. At least once a month take a random big Pavel> package by search on www.freshmeat.net (Lesstif, openssh, Pavel> gnome-libs, whatever) and try to run Autoconf. And then put Pavel> yourself in the position of a guy who knows nothing about our Pavel> changes and wants to upgrade Autoconf. I do that Pavel. I do keep track of how Autoconf behaves with other packages. And my hot tasks when 2.49b or 2.49c is to fetch big packages, and check that it behaves properly. Pavel> If the libtool team couldn't avoid a name that you want to Pavel> reserve it is very likely that someone else will encounter the Pavel> same problem. That's indeed my claim. We must not reserve *any* prefix without giving a means to release our limitation. I am not turning my back to the Libtool team. It is no coincidence that I raised this point (AR_FLAGS): I do check how CVS Autoconf and CVS Libtool behave together. I do work so that they both work perfectly.
Re: 01-ac-lang-compiler-require.patch (Was: CC/CPP/TRY_LINK)
Akim Demaille wrote: > > Thanks for the report, it's a known bug. In fact this bug is not new, > what is new is that the core machinery now correctly catches it. With your patch, it seems to be hidden, but present, again. I.e. your patch solves part of the problem, but another one remains. > The problem is related to the fact that AC_PROG_CC can be expanded > twice, and since the first expansion expands AC_PROG_CPP, the second > expansion of AC_PROG_CC will complain because AC_PROG_CPP was run > beforehand. > > The following patch fixes this issue. There was another obvious > implementation possibility: having AC_LANG_COMPILER(C) provide > AC_PROG_CC, but I think this approach is better. > I can't judge :) The situation appears to have improved, but here remains another, probably related problem w/ cvs-autoconf: 1. Explicit PROG_[CC|CPP] in configure.in: # cat configure.in AC_INIT(hello.c) AM_INIT_AUTOMAKE(foo,1,no) AC_PROG_CC AC_PROG_CPP AC_OUTPUT(Makefile) # ./configure .. checking for gcc... gcc .. checking how to run the C preprocessor... gcc -E checking dependency style of gcc... none checking how to run the C preprocessor... gcc -E .. => CPP being checked twice, but in correct order. AFAIU, this is what you are referring to, above. 2. PROG_[CC|CPP] in external m4-file: # cat configure.in AC_INIT(hello.c) AM_INIT_AUTOMAKE(foo,2,no) MY_PROG_CC AC_OUTPUT(Makefile) # cat acinclude.m4 AC_DEFUN([MY_PROG_CC], [ AC_PROG_CC AC_PROG_CPP ]) # ./configure .. checking how to run the C preprocessor... cc -E checking for gcc... gcc .. checking dependency style of gcc... gcc checking how to run the C preprocessor... cc -E .. => CPP being checked twice, but now the order gets swapped - Ouch :( Though this might seem to be a minor problem at first glance, but this is pretty devastating wrt. cross-compilation: Example 1b: ./configure --build=`config.guess` --host=sh-rtems .. checking for sh-rtems-gcc... sh-rtems-gcc .. checking how to run the C preprocessor... sh-rtems-gcc -E checking dependency style of sh-rtems-gcc... none checking how to run the C preprocessor... sh-rtems-gcc -E .. => Correct cpp being picked up Example 2b: ./configure --build=`config.guess` --host=sh-rtems .. checking how to run the C preprocessor... cc -E checking for sh-rtems-gcc... sh-rtems-gcc .. checking dependency style of sh-rtems-gcc... gcc checking how to run the C preprocessor... cc -E .. => Wrong cpp being picked up. Bummer :) [Using CVS automake and CVS autoconf w/ Akims patch] Ralf -- Ralf Corsepius Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW) Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690 mailto:[EMAIL PROTECTED] FAX: +49/731/501-999 http://www.faw.uni-ulm.de
Re: Forbidden strings
On Wed, Nov 08, 2000 at 11:18:04AM +0100, Akim Demaille wrote: : Pavel> Just take my advice. At least once a month take a random big : Pavel> package by search on www.freshmeat.net (Lesstif, openssh, : Pavel> gnome-libs, whatever) and try to run Autoconf. And then put : Pavel> yourself in the position of a guy who knows nothing about our : Pavel> changes and wants to upgrade Autoconf. : : I do that Pavel. I do keep track of how Autoconf behaves with other : packages. And my hot tasks when 2.49b or 2.49c is to fetch big : packages, and check that it behaves properly. Please check out Guile from CVS - I tried using CVS Autoconf and Automake with their bootstrap a while back (not too long), and failed miserably... :pserver:[EMAIL PROTECTED]:/cvs co guile-core Lars J
Re: ac_cv_prog_gcc
Hello, Akim! > For instance if for some reason the user had > > AC_CANONICAL_SYSTEM([This macro computes $host])(echo "$host) > > then autoupdate with parens (the current one) will produce > > AC_CANONICAL_TARGET([])(echo "$host) > > which is correct, while without parens you'd produce this: > > AC_CANONICAL_TARGET(echo "$host) > > which is wrong. I meant that a macro with arguments should become a macro with arguments. This obviously buries the idea of having two AU_ALIAS'es. On the other hand, a macro with exactly 0 arguments should become a macro with 0 arguments. Macros with 0 arguments don't have parentheses, so it shouldn't be a problem. I'll have a look whether it's possible to implement AU_ALIAS in such way. Regards, Pavel Roskin
AC_LANG: unknown language
Hello, Lars! > Please check out Guile from CVS - I tried using CVS Autoconf and Automake > with their bootstrap a while back (not too long), and failed miserably... Ok, I'm changing the subject line for the obvious reason. It appears that GUILE_NAMED_CHECK_FUNC in aclocal.m4 expects AC_LANG without arguments to expand to the name of the current language: ifelse(AC_LANG, CPLUSPLUS, ... This worked for Autoconf-2.13 but not for the CVS version. This feature is not documented for Autoconf-2.13. Anyway, C++ is called C++, not CPLUSPLUS in the current Autoconf. An undocumented macro AC_LANG_CASE is used to do emit different code dependent on the current language. I cannot find any documented way to do it either in Autoconf-2.13 or in Autoconf-CVS. Neighter can I find any common way. But I didn't try hard. The ChangeLog states that the old AC_LANG was renamed to _AC_LANG_CURRENT and the new AC_LANG was introduced without providing backward compatabitity. The same happened to CPLUSPLUS. Regards, Pavel Roskin
Re: 01-ac-lang-compiler-require.patch (Was: CC/CPP/TRY_LINK)
Hello, Ralf! > checking how to run the C preprocessor... cc -E > checking for sh-rtems-gcc... sh-rtems-gcc It's a separate problem that needs to be addressed before 2.50. AC_PROG_CPP should require AC_PROG_CC. Maybe we should go as far as to make both AC_PROG_CPP and AC_PROG_CC obsolete in favor of AC_LANG(C) By the way, shouldn't we change the syntax of AC_LANG to AC_LANG(C, COMPILERS, ACTION-IF-FOUND, ACTION-IF-NOT-FOUND) and go ahead if no C compiler has been found but ACTION-IF-NOT-FOUND is given? I really hate all those "exit 77" in the autoconf code - it's an attempt to accomodate the testsuite at the expence of the users. Regards, Pavel Roskin
[autoconf] hacking with config.status
I have two problems with running config.status: it's flaky when you change CONFIG_FILES and CONFIG_HEADERS (for instance, instead of deleting the output file on a signal, it deletes all my makefiles) it can't be run concurrently (as in a make -j2). I know how to fix these problems, by modifying the config.status file slightly. Where in autoconf would I look to do this consistently? -- Benoît
Re: [autoconf] hacking with config.status
On Nov 8, 2000, Benoit Hudson <[EMAIL PROTECTED]> wrote:
> Where in autoconf would I look to do this consistently?
In the autoconf CVS tree. I believe both issues have already been
addressed :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
