| Running autoheader in . | WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' | WARNING: and `config.h.top', to define templates for `config.h.in' | WARNING: is deprecated and discouraged. | | WARNING: Using the third argument of `AC_DEFINE' and | WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without | WARNING: `acconfig.h': | | WARNING: AC_DEFINE([NEED_MAIN], 1, | WARNING: [Define if a function `main' is needed.]) | | WARNING: More sophisticated templates can also be produced, see the | WARNING: documentation.
Anything we should do anything about?
Using the new template system would probably be nice, but a bit of work. Mostly cut'n'paste though. You want to do it?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-09 09:51: Subject: autoheader
| Running autoheader in . | WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' | WARNING: and `config.h.top', to define templates for `config.h.in' | WARNING: is deprecated and discouraged. | | WARNING: Using the third argument of `AC_DEFINE' and | WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without | WARNING: `acconfig.h': | | WARNING: AC_DEFINE([NEED_MAIN], 1, | WARNING: [Define if a function `main' is needed.]) | | WARNING: More sophisticated templates can also be produced, see the | WARNING: documentation.
Anything we should do anything about?
/ Mirar
Would that make it incomatible with 2.13?
I rather see a system that finds and uses autoconf-2.13, actually. I'm not too fond of the modern autoconf's.
/ Mirar
Previous text:
2003-01-09 13:40: Subject: autoheader
Using the new template system would probably be nice, but a bit of work. Mostly cut'n'paste though. You want to do it?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Would that make it incomatible with 2.13?
Probably. I don't see a problem with that though.
I rather see a system that finds and uses autoconf-2.13, actually. I'm not too fond of the modern autoconf's.
Why?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-09 13:48: Subject: autoheader
Would that make it incomatible with 2.13?
I rather see a system that finds and uses autoconf-2.13, actually. I'm not too fond of the modern autoconf's.
/ Mirar
I don't like the idea of incompatible changes in a computer language. Autoconf is used like a language. If it were a new language, say "autoconf3", or autodetected so it always used the correct backwards compatible version, I wouldn't mind.
/ Mirar
Previous text:
2003-01-09 13:50: Subject: autoheader
Would that make it incomatible with 2.13?
Probably. I don't see a problem with that though.
I rather see a system that finds and uses autoconf-2.13, actually. I'm not too fond of the modern autoconf's.
Why?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
But you don't object to using the language "autoconf2.50" per se? It shouldn't be too much trouble to make run_autoconf check whether the binary "autoconf" implements the language "autoconf2.50" or not, and bail out if it doesn't. Other packages tend to do this.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-09 13:53: Subject: autoheader
I don't like the idea of incompatible changes in a computer language. Autoconf is used like a language. If it were a new language, say "autoconf3", or autodetected so it always used the correct backwards compatible version, I wouldn't mind.
/ Mirar
We could even look for a "autoconf2" binary, to allow both to be installed at the same time if someone so wishes.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-09 14:12: Subject: autoheader
But you don't object to using the language "autoconf2.50" per se? It shouldn't be too much trouble to make run_autoconf check whether the binary "autoconf" implements the language "autoconf2.50" or not, and bail out if it doesn't. Other packages tend to do this.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
No, I don't mind the new ideas. It's only the enforcing and version confusion. It's also very hard to use autoconf to find the correct autoconf version, so you're back at /bin/sh stuff.
On my system, I have:
autoconf -> ../lib/autoconf/ac-wrapper.pl autoconf-2.13 autoconf-2.53a autoconf-2.54
It might or might not be a standard, but it should be possible to let run_autoconfig (and configure for Makefile) to check for autoconf-<correct version>.
"autoconf" is a perl script. I haven't investigated it further.
/ Mirar
Previous text:
2003-01-09 14:12: Subject: autoheader
But you don't object to using the language "autoconf2.50" per se? It shouldn't be too much trouble to make run_autoconf check whether the binary "autoconf" implements the language "autoconf2.50" or not, and bail out if it doesn't. Other packages tend to do this.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
The Makefile should probably invoke the run_autoconf script, for simplicity and consistency.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-09 14:40: Subject: autoheader
No, I don't mind the new ideas. It's only the enforcing and version confusion. It's also very hard to use autoconf to find the correct autoconf version, so you're back at /bin/sh stuff.
On my system, I have:
autoconf -> ../lib/autoconf/ac-wrapper.pl autoconf-2.13 autoconf-2.53a autoconf-2.54
It might or might not be a standard, but it should be possible to let run_autoconfig (and configure for Makefile) to check for autoconf-<correct version>.
"autoconf" is a perl script. I haven't investigated it further.
/ Mirar
Mandrake has a wrapper too:
# Executes the correct autoconf version. # # - defaults to autoconf-2.13 # - runs autoconf-2.5x if it exists and... # - envvar WANT_AUTOCONF_2_5 is set to `1' # -or- # - configure.ac is present # -or- # - `configure.in' contains AC_PREREQ and the value's 3 first letters # are stringwise greater than '2.1' # -or- # - `configure' is already present and was generated by autoconf greater than '2.1' # -or- # - `Makefile.in' was generated by automake-1.6 or superior, which specificall y needs autoconf-2.5x
/ David Hedbor
Previous text:
2003-01-09 14:40: Subject: autoheader
No, I don't mind the new ideas. It's only the enforcing and version confusion. It's also very hard to use autoconf to find the correct autoconf version, so you're back at /bin/sh stuff.
On my system, I have:
autoconf -> ../lib/autoconf/ac-wrapper.pl autoconf-2.13 autoconf-2.53a autoconf-2.54
It might or might not be a standard, but it should be possible to let run_autoconfig (and configure for Makefile) to check for autoconf-<correct version>.
"autoconf" is a perl script. I haven't investigated it further.
/ Mirar
Well, for one we can name the file configure.ac rather than configure.in. That'll cause immediate breakage if you use autoconf 2.13 or older and would also indicate immediately to the compiling party that autoconf 2.5x is needed (also I think many distributions have wrapper scripts that automatically use the right autoconf version if it sees .ac rather than .in).
/ David Hedbor
Previous text:
2003-01-09 14:12: Subject: autoheader
But you don't object to using the language "autoconf2.50" per se? It shouldn't be too much trouble to make run_autoconf check whether the binary "autoconf" implements the language "autoconf2.50" or not, and bail out if it doesn't. Other packages tend to do this.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
A cp in the repository combined with a cvs remove is a workable substitute.
/ Martin Nilsson (Åskblod)
Previous text:
2003-01-09 20:27: Subject: autoheader
From the comments from the wrapper script you included in your other post, it looks like AC_PREREQ might do the trick as well. Renames are not handled well by CVS... :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Indeed. I can't speak for other such scripts however. :)
/ David Hedbor
Previous text:
2003-01-09 20:27: Subject: autoheader
From the comments from the wrapper script you included in your other post, it looks like AC_PREREQ might do the trick as well. Renames are not handled well by CVS... :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
pike-devel@lists.lysator.liu.se
-
David Hedbor ＠ Pike developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (�skblod) ＠ Pike (-) developers forum
-
Mirar ＠ Pike developers forum