How to get a literal #undef into config.h

2005-10-24 Thread Brian
I need to get #undef KEY into config.h, but even with AH_VERBATIM or AH_BOTTOM autoheader turns it into #define KEY 1. I understand why - these are only passed into config.h.in , but I don't see a way around it. While i'm at it, is it necessary to have -DHAVE_CONFIG_H? Not that

Re: empty `for' loop in shell

2005-10-24 Thread Ralf Corsepius
On Mon, 2005-10-24 at 15:28 +0200, Stepan Kasal wrote: > Hi, > is it true that > > a= ; for f in $a; do ... done > > is not interpreted correctly by some shells? Yes. > Or is it only a myth? AFAICT, it's not a myth. IIRC, Solaris' /bin/sh exposes this behavior. Also, I recall autoconf

Re: AC_PROG_CC_C_O doesn't work with VC++

2005-10-24 Thread Paul Eggert
Stepan Kasal <[EMAIL PROTECTED]> writes: > A question: is there any reason to use rm -f conftst2.* > instead of rm -f conftst2.$ac_objext > Is there any C, Fortran, or F77 compiler which could create other > conftst2.* files if it receives -o conftst2.$ac_objext ? Quite possibly, yes. But why

Re: AC_FOREACH public?

2005-10-24 Thread Allan Clark
Stepan Kasal wrote: Hello, On Mon, Oct 24, 2005 at 02:30:25PM +0200, Ralf Wildenhues wrote: Being deprecated is different that being removed, and as such it would be good to have a reference to AC_FOREACH in the eventual documentation of m4_foreach and others, with the info that AC_FOREACH i

Re: compile with VC++

2005-10-24 Thread Harald Dunkel
Hi Stepan, Stepan Kasal wrote: > > I looked at /usr/share/automake-1.9/compile and I cannot understand > how this could happen. > I think that the parametr to compile should look like > some/path/main.c > which becomes cfile, and then cofile is assigned as > > cofile=`echo "$cfile" | sed -

Re: [OT] reply-to (was: AC_FOREACH public?)

2005-10-24 Thread Andreas Schwab
Keith MARSHALL <[EMAIL PROTECTED]> writes: > Great. You still have that choice, even if the "Reply-to" header points > back to the list: > > . Reply to the address in the "Reply-to" header, for a list reply; This is an open list. You'll remove anyone from the thread who is not subscribed to th

Re: empty `for' loop in shell

2005-10-24 Thread Keith MARSHALL
Stepan Kasal wrote: > is it true that > >a= ; for f in $a; do ... done > > is not interpreted correctly by some shells? There was some discussion on a related problem, on one of the MinGW fora, a couple of months back. In a *Makefile* LIST = some-target: for i in ${LIST}; \

Re: Autoconf "languages"

2005-10-24 Thread Ralf Wildenhues
Hi Keith, * Keith MARSHALL wrote on Mon, Oct 24, 2005 at 04:09:45PM CEST: > Ralf Wildenhues wrote, quoting me: > >> Why would anyone want to do so anyway? If I want to write a shell > >> script, other than as a configure script, it's *much* more logical > >> and convenient for me to just write di

Re: compile with VC++ (was: AC_PROG_CC_C_O doesn't work with VC++)

2005-10-24 Thread Keith MARSHALL
Stepan Kasal wrote: > I think that the parametr to compile should look like >some/path/main.c > which becomes cfile, and then cofile is assigned as... Just guessing, but with cl.exe being Bill's C compiler, it probably doesn't understand `some/path/main.c' as a path name; (it will

Re: AC_FOREACH public?

2005-10-24 Thread Stepan Kasal
Hello, On Mon, Oct 24, 2005 at 02:30:25PM +0200, Ralf Wildenhues wrote: > Being deprecated is different that being removed, and as such it would > be good to have a reference to AC_FOREACH in the eventual documentation > of m4_foreach and others, with the info that AC_FOREACH is deprecated > (and

compile with VC++ (was: AC_PROG_CC_C_O doesn't work with VC++)

2005-10-24 Thread Stepan Kasal
Hello, [ let's move to automake@gnu.org ] On Mon, Oct 24, 2005 at 04:20:44PM +0200, Harald Dunkel wrote: > I think I found the problem. The compile script says at the > end > : > if test -f "$cofile"; then > mv "$cofile" "$ofile" > elif test -f "${cofile}bj"; then >

Re: AC_PROG_CC_C_O doesn't work with VC++

2005-10-24 Thread Harald Dunkel
Hi folks, Ralf Wildenhues wrote: > Hi Harald, > > * Harald Dunkel wrote on Mon, Oct 24, 2005 at 02:19:53PM CEST: > >>I tried the previous patch you had sent some time ago (the >>version with 'conf$[$]'). But this didn't work for Bill's >>cl.exe. The generated Makefile still uses -c and -o on the

Re: Autoconf "languages" (was: AC_FOREACH public?)

2005-10-24 Thread Keith MARSHALL
Ralf Wildenhues wrote, quoting me: >> Why would anyone want to do so anyway? If I want to write a shell >> script, other than as a configure script, it's *much* more logical >> and convenient for me to just write directly as such, in the shell's >> own native language. > > Those who don't use M4SH

Re: Autoconf "languages" (was: AC_FOREACH public?)

2005-10-24 Thread Peter Breitenlohner
On Mon, 24 Oct 2005, Ralf Wildenhues wrote: * Keith Marshall wrote on Sat, Oct 22, 2005 at 01:32:46AM CEST: On Friday 21 October 2005 10:42 pm, Alexandre Duret-Lutz wrote: But you are only using the top of the iceberg. ?Other people benefit from this clear layering. When another user use `au

empty `for' loop in shell

2005-10-24 Thread Stepan Kasal
Hi, is it true that a= ; for f in $a; do ... done is not interpreted correctly by some shells? Or is it only a myth? Autoconf contains workarounds for this bug, but the manual doesn't seem to mention it. Have a nice day, Stepan ___

Autoconf "languages" (was: AC_FOREACH public?)

2005-10-24 Thread Ralf Wildenhues
Hi Keith, * Keith Marshall wrote on Sat, Oct 22, 2005 at 01:32:46AM CEST: > On Friday 21 October 2005 10:42 pm, Alexandre Duret-Lutz wrote: > > > > But you are only using the top of the iceberg.  Other people > > benefit from this clear layering. > > > > When another user use `autom4te --lang=M4sh

Re: AC_PROG_CC_C_O doesn't work with VC++

2005-10-24 Thread Ralf Wildenhues
Hi Harald, * Harald Dunkel wrote on Mon, Oct 24, 2005 at 02:19:53PM CEST: > > I tried the previous patch you had sent some time ago (the > version with 'conf$[$]'). But this didn't work for Bill's > cl.exe. The generated Makefile still uses -c and -o on the same > command line. I had verified tha

Re: AC_FOREACH public?

2005-10-24 Thread Ralf Wildenhues
Hi Keith, * Keith MARSHALL wrote on Mon, Oct 24, 2005 at 11:58:38AM CEST: > >> But "Reply-to-All" is *not* the most appropriate solution -- > >> it's what I used here, so *you* can have *two* copies of this > >> message. > > > > Personally, I configure my mailreader to discard duplicates. > > Gre

Re: AC_PROG_CC_C_O doesn't work with VC++

2005-10-24 Thread Harald Dunkel
Hi Stepan, Stepan Kasal wrote: > Hello Harald, > > On Mon, Oct 24, 2005 at 10:35:25AM +0200, Harald Dunkel wrote: > >>It seems that this patch is still not in CVS. And since the >>suggested workaround doesn't workaround I am stuck :-(. > > > I apologize. I have committed a patch which should

Re: AC_PROG_CC_C_O doesn't work with VC++

2005-10-24 Thread Stepan Kasal
Hello Harald, On Mon, Oct 24, 2005 at 10:35:25AM +0200, Harald Dunkel wrote: > It seems that this patch is still not in CVS. And since the > suggested workaround doesn't workaround I am stuck :-(. I apologize. I have committed a patch which should fix your problem. (Attached.) A question: is th

Re: [OT] reply-to (was: AC_FOREACH public?)

2005-10-24 Thread Keith MARSHALL
Allan Clark wrote, quoting me: >> But "Reply-to-All" is *not* the most appropriate solution -- it's what >> I used here, so *you* can have *two* copies of this message. > > great. I've got two eyes. These duplicates are statistical noise in > the world of spam... And I'm sure they are extreme

Re: AC_FOREACH public?

2005-10-24 Thread Keith MARSHALL
>> But "Reply-to-All" is *not* the most appropriate solution -- >> it's what I used here, so *you* can have *two* copies of this >> message. > > Personally, I configure my mailreader to discard duplicates. Great, if you aren't compelled, by your corporate IT department, to use an unconfigurable le

Re: AC_PROG_CC_C_O doesn't work with VC++

2005-10-24 Thread Harald Dunkel
Hi folks, Stepan Kasal wrote: > > the patch attached to this mail (relative to current autoconf CVS) > should fix it. > > OK to commit? > It seems that this patch is still not in CVS. And since the suggested workaround doesn't workaround I am stuck :-(. Any help would be highly appreciated.

Re: Funny behavior from autoconf

2005-10-24 Thread Ralf Wildenhues
Hi Brian, [ copying bug-automake on this, it's better suited there; please remove autoconf at gnu.org from followups; thank you ] * Brian Lloyd wrote on Mon, Oct 24, 2005 at 04:44:32AM CEST: > The following Makefile.am does not work as expected. This is a stripped > down version of the complete