Re: Autoconf --trace
On Tue, Mar 07, 2000 at 11:50:46AM +0100, Akim Demaille wrote: : | eval set $list : | while test $# -gt 0; do : | echo $1 : | shift : | done : : Excellent, thanks! I think this is the best means to handle the list : here. The most elegant solution I found (can't give it a rest already! ;) is: eval set $list for elt in "$@"; do echo $elt done So there. Now you won't get any more suggestions from me :) Lars J
Re: Fix some tests to be g++ >= 2.95 safe
I'm OK with this patch. I'll apply the changes for the headers at checkin if Franz doesn't have time to. One yes is still expected. Akim
Re: Fix some tests to be g++ >= 2.95 safe
On Mar 8, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> I'm OK with this patch.
Ditto.
> One yes is still expected.
You got it :-)
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Fix some tests to be g++ >= 2.95 safe
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> You got it :-) Well, finally I have a little problem: when you look at the full context, there is already unistd.h above. I moved the #include block which was discussed above the GETPAGESIZE one (originally it was below), but I still wonder what we should do: #include #include #include #if HAVE_STDLIB_H # include #else char *malloc (); #endif #if HAVE_UNISTD_H # include #endif #if HAVE_SYS_STAT_H # include #endif /* This mess was copied from the GNU getpagesize.h. */ #if !HAVE_GETPAGESIZE # if HAVE_UNISTD_H # include # endif /* Assume that all systems that can run configure have sys/param.h. */ # if !HAVE_SYS_PARAM_H # define HAVE_SYS_PARAM_H 1 # endif # ifdef _SC_PAGESIZE # define getpagesize() sysconf(_SC_PAGESIZE) # else /* no _SC_PAGESIZE */ # if HAVE_SYS_PARAM_H # include # ifdef EXEC_PAGESIZE #define getpagesize() EXEC_PAGESIZE # else /* no EXEC_PAGESIZE */ #ifdef NBPG # define getpagesize() NBPG * CLSIZE # ifndef CLSIZE # define CLSIZE 1 # endif /* no CLSIZE */ #else /* no NBPG */ # ifdef NBPC # define getpagesize() NBPC # else /* no NBPC */ # ifdef PAGESIZE # define getpagesize() PAGESIZE # endif /* PAGESIZE */ # endif /* no NBPC */ #endif /* no NBPG */ # endif /* no EXEC_PAGESIZE */ # else /* no HAVE_SYS_PARAM_H */ # define getpagesize() 8192 /* punt totally */ # endif /* no HAVE_SYS_PARAM_H */ # endif /* no _SC_PAGESIZE */ #endif /* no HAVE_GETPAGESIZE */ I suggest to simply remove the second inclusion of unistd.h. Akim
Re: Fix some tests to be g++ >= 2.95 safe
On Mar 8, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> I suggest to simply remove the second inclusion of unistd.h.
Agreed.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Autoconf --trace
| On Tue, Mar 07, 2000 at 11:50:46AM +0100, Akim Demaille wrote: | : | eval set $list | : | while test $# -gt 0; do | : | echo $1 | : | shift | : | done | : | : Excellent, thanks! I think this is the best means to handle the list | : here. | | The most elegant solution I found (can't give it a rest already! ;) is: | | eval set $list | for elt in "$@"; do | echo $elt | done | | So there. Now you won't get any more suggestions from me :) I agree, this is perfect. Now the question is, do we want to pollute autoconf.sh, a maintainer tool, with portability issues? If yes, we need to eval set dummy $list shift for elt in "$@"; do echo $elt done to be sure that if $list comes with `-e' first, set won't understand it. If we expect a good shell, then eval set -- $list for elt in "$@"; do echo $elt done is fine. Akim
Re: Autoconf --trace
On Mar 8, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Now the question is, do we want to pollute
> autoconf.sh, a maintainer tool, with portability issues?
Yes, at least in this case.
> If yes, we need to
> eval set dummy $list
> shift
So be it. It's simple enough.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Autoconf --trace
On Wed, Mar 08, 2000 at 11:09:07AM +0100, Akim Demaille wrote: : | eval set $list : | for elt in "$@"; do : | echo $elt : | done : | : | So there. Now you won't get any more suggestions from me :) : : I agree, this is perfect. Actually, I was informed by John W. Eaton through private email that the 'in "$@"' part is the default and can therefore be dropped. My opinion on this (which is influenced by my personal sh-scripting conventions) is that "for elt; do" is a bit less readable than the full thing. : If we expect a good shell, then : eval set -- $list : is fine. I think the dummy-approach is safest. I didn't look into which context this was to be used in, but I'd probably name it _ac_dummy or something like that... Lars J
Re: Autoconf --trace
On Mar 8, 2000, "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 08, 2000 at 11:09:07AM +0100, Akim Demaille wrote:
> : | eval set $list
> : | for elt in "$@"; do
> : | echo $elt
> : | done
> : |
> : | So there. Now you won't get any more suggestions from me :)
> :
> : I agree, this is perfect.
> Actually, I was informed by John W. Eaton through private email that
> the 'in "$@"' part is the default and can therefore be dropped.
Yep, as long as you move the `do' to the next line. Some shells can't
parse `for elt; do' :-(
> My opinion on this (which is influenced by my personal sh-scripting
> conventions) is that "for elt; do" is a bit less readable than the
> full thing.
ACtually, to be fully equivalent to `for elt \n do', you must write:
for elt in ${1+"$@"}; do
Some shells will expand "$@" to "" even if $# = 0.
But then, this doesn't apply here, since we know we've got at least
one argument.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Enjoy Guaraná
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: Autoconf --trace
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: Lars> Actually, I was informed by John W. Eaton through private email Lars> that the 'in "$@"' part is the default and can therefore be Lars> dropped. My opinion on this (which is influenced by my personal Lars> sh-scripting conventions) is that "for elt; do" is a bit less Lars> readable than the full thing. It is true, but I don't think you can portably leave the do on the same line, you have to: for arg do done but this may be an hallucination of my memory. Akim Lars> : If we expect a good shell, then : eval set -- $list : is fine. Lars> I think the dummy-approach is safest. I didn't look into which Lars> context this was to be used in, but I'd probably name it Lars> _ac_dummy or something like that... `dummy' is just a string here, there is no problems. And it's an idiom, we should keep it as is (I have a friend who, when he was a student in physics, loved to name `n' or `i' the reals, `x' the integers, \gamma a force, `V' for pressure and the like :) Akim
Re: Autoconf --trace
On Wed, Mar 08, 2000 at 11:31:27AM +0100, Akim Demaille wrote:
: Lars> I think the dummy-approach is safest. I didn't look into which
: Lars> context this was to be used in, but I'd probably name it
: Lars> _ac_dummy or something like that...
:
: `dummy' is just a string here, there is no problems. And it's an
As I said, I don't know the context. If it's argument parsing we're
talking about, I could be insane enough to have "dummy" as an option
for some --with-* value.
You can 'shift' out the dummy at once, though, and leave out the case for
it (I assume you'll have a switch/case inside the for loop), but then
you must use the ${1+"$@"} approach.
Lars J
Re: Autoconf --trace
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> You can 'shift' out the dummy at once, though, and leave out the
Lars> case for it (I assume you'll have a switch/case inside the for
Lars> loop), but then you must use the ${1+"$@"} approach.
That's what I meant, dummy could be anything but a string starting
with a dash:
eval set dummy $list
shift # pop dummy now
for elt
do
echo $elt
done
Akim
Re: Autoconf --trace
> > > "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: > > Lars> Actually, I was informed by John W. Eaton through private email > Lars> that the 'in "$@"' part is the default and can therefore be > Lars> dropped. My opinion on this (which is influenced by my personal > Lars> sh-scripting conventions) is that "for elt; do" is a bit less > Lars> readable than the full thing. > > It is true, but I don't think you can portably leave the do on the > same line, you have to: > > for arg > do > > done > > but this may be an hallucination of my memory. I've been burned with this, too - noticed it because one of the existing autoconf boilerplates expands into an empty list. (offhand I don't recall if it was a vendor system or one of the bash implementations that breaks, but since it's in a harmless place in autoconf, the error doesn't cause the script to stop, hence it's not normally noticed unless you happen to be tracing). -- Thomas E. Dickey [EMAIL PROTECTED] http://www.clark.net/pub/dickey
PACKAGE and VERSION
I would like to suggest again something which has been rejected the first time... I would like Autoconf to know PACKAGE and VERSION too. Of course it is not essential to it as it is for Automake, but I would like it for several small issues, each time for esthetic purposes. 1. It would allow to have configure --version and config.status --version which state some information about the project. I find this much more beautiful :) 2. It would allow to dump it into config.log (don't laugh, I've already received wrong config.logs :) 3. It would allow to solve parts of the wishes for a deep --help: each --help section coming from a nested package come start with a label stating where it comes from. 4. Plenty of other uses, I'm sure. If the answer is yes, what is the interface you'd suggest? AC_PACKAGE(Autoconf, 2.14a)? I'd like to avoid the Automake third arg trick to disable AC_DEFINE, there are probably more esthetic means to achieve this. Akim
Re: problem configuring a2ps 4.13 w/ autoconf 2.14a on IRIX 5.3
> "Ralf" == Ralf Fassel <[EMAIL PROTECTED]> writes: Ralf> I have GNU m4 1.4 installed at this machine, would that be ok? Fine! Ralf> I'll give it a try. Results tomorrow :-) Fine too :) | In fact I think it is enough to | | | : t | | s%#undef FOO$%#define FOO 1%;t t | | s%#undef DIRECTORY_SEPARATOR$%#define DIRECTORY_SEPARATOR '/'%;t t | | s%#undef [a-zA-Z_][a-zA-Z_0-9]*%/* & */% | | this is the approach taken in the a2ps and Autoconf I just gave. I | like it better, it is less hacky. Ralf> Yes, this works too, but is has the potential danger of an Ralf> endless loop if the replacement triggers another match (eg: add Ralf> `;t t' to the last line, too). Oh, yes, yes, that's why I had changed it :( This is no risk with #undef -> #define, but there is that danger with #define templates. 2000-02-10 Akim Demaille <[EMAIL PROTECTED]> Honor properly the `#define' config.h.in templates. Test it. * acgeneral.m4 (AC_OUTPUT_HEADERS): Renamed as... (_AC_OUTPUT_HEADERS): this. All callers changed. Don't mess with changequote, just quote properly. Bug 1. Because of the `#' in `ac_dA', the quotes <<>> were not removed, and therefore the sed script contained `<>' instead of `define'. Now that the block is properly quoted, there is no need to quote `define'. Bug 2. Once a `#define' substitution performed, we were branching to the top of the sed script (`t top'). This resulted in an endless substitution of `#define foo 1' to `#define foo 1'. Branching is not enough: you also have to fetch the next input line, i.e., use `t' instead of `t t' in ac_dD, and don't output `: top' in `config.defines'. Though it was correct for `#undef' templates, just apply the same transformation to `ac_uD' and `config.undefs'. Bug 3. Don't try to preserve what was behind the value in the template, since on #define NAME "bar baz" it leads to #define NAME 1 baz" Now `ac_dB' catches everything behind the NAME (making sure there is at least a space) and `ac_dC' only outputs a space. * tests/torture.m4: Check that various forms of `#define' header templates are properly handled. Heck, I hate those #define templates. Can't we get rid of them? They're only leading to complications. Yes, it is not 100% compatible with previous Autoconves, but they are a real pain, they force us to have twice the needed code. `autoheader' can be used to guarantee the user has proper #undef templates. I moved this to autoconf@ so that this can be debated (again). Akim
Re: PACKAGE and VERSION
Hello! > I would like Autoconf to know PACKAGE and VERSION too. Of course it > is not essential to it as it is for Automake, but I would like it for > several small issues, each time for esthetic purposes. > > 3. It would allow to solve parts of the wishes for a deep --help: each >--help section coming from a nested package come start with a label >stating where it comes from. Great idea! This is really important. We need to be able to specify the scope of options, e.g. ./configure PACKAGE1:--enable-debug PACKAGE2:--disable-debug > If the answer is yes, what is the interface you'd suggest? > > AC_PACKAGE(Autoconf, 2.14a)? Probably Ok. > I'd like to avoid the Automake third arg trick to disable AC_DEFINE, > there are probably more esthetic means to achieve this. Could you please explain why you don't like it and what you propose? Pavel
