The renaming of --localdir to --prepend-include is annoying when trying to keep a configure.in compatible between 2.13 and more modern versions. To make it less painful, I patched in some backwards compatibility to my local version of autoconf-2.57. Seems to work fine for me.
--- autoconf.in-original Tue Nov 5 08:16:59 2002 +++ autoconf.in Tue Apr 15 14:23:43 2003 @@ -194,7 +194,9 @@ --prepend-include=* | -B?* | \ --warnings=* | -W?* ) AUTOM4TE="$AUTOM4TE $1"; shift ;; - + --localdir=* ) + AUTOM4TE="$AUTOM4TE --prepend-include=${1:11}" ; shift ;; + # Options with separated arg passed as is to autom4te. --include | -I | \ --prepend-include | -B | \ @@ -202,7 +204,11 @@ test $# = 1 && eval "$exit_missing_arg" AUTOM4TE="$AUTOM4TE $option $2" shift 2 ;; - + --localdir ) + test $# = 1 && eval "$exit_missing_arg" + AUTOM4TE="$AUTOM4TE --prepend-include $2" + shift 2 ;; + --trace=* | -t?* ) traces="$traces --trace='"`echo "$optarg" | sed "s/'/'\\\\''/g"`"'" shift ;;
Regards, /Niels
Maybe we should make a meta-autoconf, something that detects the autoconf version and generates the proper configure.in. :-)
/ Mirar
Previous text:
2003-04-22 10:13: Subject: --localdir backwards compatibility
The renaming of --localdir to --prepend-include is annoying when trying to keep a configure.in compatible between 2.13 and more modern versions. To make it less painful, I patched in some backwards compatibility to my local version of autoconf-2.57. Seems to work fine for me.
--- autoconf.in-original Tue Nov 5 08:16:59 2002 +++ autoconf.in Tue Apr 15 14:23:43 2003 @@ -194,7 +194,9 @@ --prepend-include=* | -B?* | \ --warnings=* | -W?* ) AUTOM4TE="$AUTOM4TE $1"; shift ;;
- --localdir=* )
AUTOM4TE="$AUTOM4TE --prepend-include=${1:11}" ; shift ;;- # Options with separated arg passed as is to autom4te. --include | -I | \ --prepend-include | -B | \
@@ -202,7 +204,11 @@ test $# = 1 && eval "$exit_missing_arg" AUTOM4TE="$AUTOM4TE $option $2" shift 2 ;;
- --localdir )
test $# = 1 && eval "$exit_missing_arg"AUTOM4TE="$AUTOM4TE --prepend-include $2"shift 2 ;;- --trace=* | -t?* ) traces="$traces --trace='"`echo "$optarg" | sed
"s/'/'\\\\''/g"`"'" shift ;;
Regards, /Niels
/ Brevbäraren
We might as well include a supported version of autoconf then.
/ Peter Bortas
Previous text:
2003-04-22 13:17: Subject: --localdir backwards compatibility
Maybe we should make a meta-autoconf, something that detects the autoconf version and generates the proper configure.in. :-)
/ Mirar
You mean, we can require a specific autoconf version for people who uses the CVS tree to compile their Pike? The Pike distributions hopefully doesn't need autoconf, and I don't feel like we ought to put autoconf in our CVS.
Many Linux'es has a meta-autoconf that automatically selects 2.13 or 2.5x autoconfs depending on how configure.in/configure.ac look like anyway, so it shouldn't be a big problem.
/ Mirar
Previous text:
2003-04-22 13:20: Subject: --localdir backwards compatibility
We might as well include a supported version of autoconf then.
/ Peter Bortas
No, we don't require it, we plain include it in CVS and make the makefiles use it.
½ :-)
/ Peter Bortas
Previous text:
2003-04-22 13:23: Subject: --localdir backwards compatibility
You mean, we can require a specific autoconf version for people who uses the CVS tree to compile their Pike? The Pike distributions hopefully doesn't need autoconf, and I don't feel like we ought to put autoconf in our CVS.
Many Linux'es has a meta-autoconf that automatically selects 2.13 or 2.5x autoconfs depending on how configure.in/configure.ac look like anyway, so it shouldn't be a big problem.
/ Mirar
I've thought about doing that, sometimes when I wait for configure to finish, an autoconf that gives two outputs: one that could be run by Pike, and one that could be run by /bin/sh. The Pike version could be run if there is a pike installed on the system, with much better caches and data handling = way faster.
/ Mirar
Previous text:
2003-04-23 09:33: Subject: --localdir backwards compatibility
We better write our own Autoconf in Pike!
/ Marcus Agehall (Trådlös)
Do we really need autoconf for the Pike-version? Couldn't it just feed of the configure.in files?
/ Marcus Agehall (Trådlös)
Previous text:
2003-04-23 12:17: Subject: --localdir backwards compatibility
I've thought about doing that, sometimes when I wait for configure to finish, an autoconf that gives two outputs: one that could be run by Pike, and one that could be run by /bin/sh. The Pike version could be run if there is a pike installed on the system, with much better caches and data handling = way faster.
/ Mirar
|The renaming of --localdir to --prepend-include is annoying when |trying to keep a configure.in compatible between 2.13 and more modern |versions. To make it less painful, I patched in some backwards |compatibility to my local version of autoconf-2.57. Seems to work fine |for me.
Please, drop 2.13, as it is too buggy, and trying to maintain compatibility with it is the worse that could happen to your scripts.
| |--- autoconf.in-original Tue Nov 5 08:16:59 2002 |+++ autoconf.in Tue Apr 15 14:23:43 2003 |@@ -194,7 +194,9 @@ | --prepend-include=* | -B?* | \ | --warnings=* | -W?* ) | AUTOM4TE="$AUTOM4TE $1"; shift ;; |- |+ --localdir=* ) |+ AUTOM4TE="$AUTOM4TE --prepend-include=${1:11}" ; shift ;;
I do not believe this would be portable anyway.
Akim Demaille akim@epita.fr writes:
Please, drop 2.13, as it is too buggy, and trying to maintain compatibility with it is the worse that could happen to your scripts.
Well, there's a lot of nifty stuff in the latest autoconf that I like, but there are also some more controversial things (like the perl/autom4te stuff, not using config.cache by default, and it seems to be an order of magnitude slower than autoconf-2.13). I use and require the latest autoconf for my own projects, but I don't think autoconf-2.13 is going to disappear soon.
So for me, the problem is that I want to have 2.57 installed on my machine, and still be able to do development on projects, like pike, that prefer to use autoconf-2.13 or autoconf-2.52. And that *works*, I've noticed *no* problems with, except for the annoying renaming of --localdir.
I'm actually considering getting the latest pre-autom4te version of autoconf (2.52?), and see if I can put it together with the m4 files of the latest autoconf release. ;-)
Regards, /Niels
Niels> Akim Demaille akim@epita.fr writes:
Please, drop 2.13, as it is too buggy, and trying to maintain compatibility with it is the worse that could happen to your scripts.
Niels> Well, there's a lot of nifty stuff in the latest autoconf that I like, Niels> but there are also some more controversial things (like the Niels> perl/autom4te stuff, not using config.cache by default, and it seems Niels> to be an order of magnitude slower than autoconf-2.13). I use and Niels> require the latest autoconf for my own projects, but I don't think Niels> autoconf-2.13 is going to disappear soon.
Slowness is relative: the more you run it, the less it is, precisely thanks to the cache. That's a dramatic speed up when using autoheader and/or automake.
Still, 2.57 lets you disable the generation of that cache file.
How about writing our own autoconf in Pike and drop autoconf totally? All versions of autoconf seems to have issues.
As long as there is a ./configure generated...
/ Mirar
Previous text:
2003-05-04 13:20: Subject: Re: --localdir backwards compatibility
|The renaming of --localdir to --prepend-include is annoying when |trying to keep a configure.in compatible between 2.13 and more modern |versions. To make it less painful, I patched in some backwards |compatibility to my local version of autoconf-2.57. Seems to work fine |for me.
Please, drop 2.13, as it is too buggy, and trying to maintain compatibility with it is the worse that could happen to your scripts.
| |--- autoconf.in-original Tue Nov 5 08:16:59 2002 |+++ autoconf.in Tue Apr 15 14:23:43 2003 |@@ -194,7 +194,9 @@ | --prepend-include=* | -B?* | \ | --warnings=* | -W?* ) | AUTOM4TE="$AUTOM4TE $1"; shift ;; |- |+ --localdir=* ) |+ AUTOM4TE="$AUTOM4TE --prepend-include=${1:11}" ; shift ;;
I do not believe this would be portable anyway.
/ Brevbäraren
This has been proposed several times. I'm OK with it. Someone must however do the actual implementation...
/ Martin Nilsson (lambda)
Previous text:
2003-05-04 13:32: Subject: Re: --localdir backwards compatibility
How about writing our own autoconf in Pike and drop autoconf totally? All versions of autoconf seems to have issues.
As long as there is a ./configure generated...
/ Mirar
I wouldn't like to put any effort into that; the available pike hacker resources are preciously small anyway and would be better spent elsewhere. I think it's better to keep 2.13 compatibility until the issues with the later autoconfs have been settled and then switch. At least Debian has a separate autoconf 2.13 package nowadays to cope with this situation.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-04 13:32: Subject: Re: --localdir backwards compatibility
How about writing our own autoconf in Pike and drop autoconf totally? All versions of autoconf seems to have issues.
As long as there is a ./configure generated...
/ Mirar
To me, m4 seems like a reasonable tool for the job. All I want is (i) get rid of perl and autom4te, (ii) use a decent module system (say, autoload macros from aclocal.d and $prefix/somewhere/aclocal), (iii) get rid of autoheader, just let autoconf write config.h.in fragments to three diversions and dump them to a file at the end.
(Automake is a different story, but it's even more off-topic in this forum).
/ Niels Möller (med röd bil)
Previous text:
2003-05-04 13:32: Subject: Re: --localdir backwards compatibility
How about writing our own autoconf in Pike and drop autoconf totally? All versions of autoconf seems to have issues.
As long as there is a ./configure generated...
/ Mirar
well, if something is replaced to help pike, then i'd prefer it to be in the language that everyone here uses: pike.
that way we get more people who will be able to look and poke at it, and fix bugs.
greetings, martin.
Sure, if you only want new configure stuff for pike. You'd have a hard time to sell it to projects that don't altready use pike.
I (personally) don't find that project terribly interesting, and I kind-of doubt anyone is willing to maintain that.
On the other hand, an improved autoconf (with the perl dependency removed) sounds like something I could use for any project.
/ Niels Möller (med röd bil)
Previous text:
2003-05-13 14:26: Subject: Re: --localdir backwards compatibility
well, if something is replaced to help pike, then i'd prefer it to be in the language that everyone here uses: pike.
that way we get more people who will be able to look and poke at it, and fix bugs.
greetings, martin.
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Akim Demaille -
Marcus Agehall (Tr�dl�s) ＠ Pike (-) developers forum -
Martin Baehr -
Martin Nilsson (lambda) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Niels M�ller (med r�d bil) ＠ Pike (-) developers forum
-
nisse＠lysator.liu.se -
Peter Bortas ＠ Pike developers forum