autoheader question

$ autoheader --version Autoconf version 2.13 One thing I can't seem to figure out: if acconfig.h exists, is autoheader supposed to add all its contents to config.h.in? And if this doesn't happen, is there a way to find out why?

Re: autoheader question

On Apr 25, 2000, Lars Hecking <[EMAIL PROTECTED]> wrote: > One thing I can't seem to figure out: if acconfig.h exists, is > autoheader supposed to add all its contents to config.h.in? Yup > And if this doesn't happen, is there a way to find out why? Run it with `sh -x'. -- Alexandre Oliva

Re: autoheader question

Perhaps this is a stupid question, but did you remember to add the following to the top of your configure.in file? I made a simmilar mistake when writing my configure.in. AC_CONFIG_HEADER(config.h) Mo Dejong Red Hat Inc. On Tue, 25 Apr 2000, Lars Hecking wrote: > > $ autoheader --version > Au

Re: autoheader question

> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On Apr 25, 2000, Lars Hecking <[EMAIL PROTECTED]> wrote: >> One thing I can't seem to figure out: if acconfig.h exists, is >> autoheader supposed to add all its contents to config.h.in? Alexandre> Yup Hm, I might be ove

Re: Is this a bug in autoconf? (patch included)

> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: >> Moin moin! Ralf> It's a common greeting phrase used in North German dialects, Ralf> literally "Morning, Morning", meaning "Good Morning, Good Ralf> Morning", pronounced similar to the English word "coin". OK, thanks! Bye bye

Re: autoheader question

On Apr 25, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On Apr 25, 2000, Lars Hecking <[EMAIL PROTECTED]> wrote: >>> One thing I can't seem to figure out: if acconfig.h exists, is >>> autoheader supposed to add all its

Re: Is this a bug in autoconf? (patch included)

> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> I don't know if this justifies additional coding. It's up to Pavel> you. Well, I hear you Pavel. I'm going to rewrite my patch, and submit it. It will try to warn when --host, --build or --target is used when it is not supposed t

Re: Is this a bug in autoconf? (patch included)

> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes: Peter> Akim Demaille writes: >> This is why I would like to reiterate a proposal I made: get rid of >> AC_CANONICAL_{BUILD, TARGET, HOST}, and provide only >> AC_CANONICAL_SYSTEM. Peter> I don't think this buys anything. Well, it si

Re: Is this a bug in autoconf? (patch included)

> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: Ian> By the way, people talk about AC_CANONICAL_TARGET and Ian> AC_CANONICAL_BUILD, but in earlier years those were never Ian> documented. The only documented macros were AC_CANONICAL_HOST Ian> (only used by programs which cared about t

Re: Is this a bug in autoconf? (patch included)

> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> How about adopting this into autoconf? Ralf> I like the idea of having autoconf support for Ralf> --enable-targets="...". Why not, if people think there is a need for this. It's good that Autoconf promotes uniformization across p

Re: Is this a bug in autoconf? (patch included)

> Peter> If you want to make a change I'd claim that it would be much > Peter> more logical to get rid of AC_CANONICAL_SYSTEM instead and let > Peter> people explicitly call CANONICAL_{HOST|BUILD} if they want > Peter> information about the host or build system, whyever they would > Peter> need

Re: autoheader question

> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: One thing I can't seem to figure out: if acconfig.h exists, is autoheader supposed to add all its contents to config.h.in? Alexandre> Yup >> Hm, I might be over picky, but I would have answered no. >> autoheader 2.13 is

Re: Is this a bug in autoconf? (patch included)

Akim Demaille wrote: > > > "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: > > Pavel> I don't know if this justifies additional coding. It's up to > Pavel> you. > > Well, I hear you Pavel. I'm going to rewrite my patch, and submit > it. It will try to warn when --host, --build or --ta

Re: Is this a bug in autoconf? (patch included)

> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: Mo> Why don't we just merge the AC_CANONICAL_BUILD macro into the Mo> AC_CANONICAL_HOST macro and not print out the --build option. The Mo> --host option would still be used to give the cross triple and the Mo> --target option would not showup i

Re: autoheader question

> Hm, I might be over picky, but I would have answered no. autoheader > 2.13 is including all the paragraphs which are related to something > which is AC_DEFINE'd, which is not necessarily all the content of > acconfig.h. What about AC_DEFINE_UNQUOTED? And, shouldn't autoheader check aclocal.m

Re: autoheader question

> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes: >> Hm, I might be over picky, but I would have answered no. >> autoheader 2.13 is including all the paragraphs which are related >> to something which is AC_DEFINE'd, which is not necessarily all the >> content of acconfig.h. Lars> What a

Re: Is this a bug in autoconf? (patch included)

> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: >> Well, I hear you Pavel. I'm going to rewrite my patch, and submit >> it. It will try to warn when --host, --build or --target is used >> when it is not supposed to be. Ralf> I hope you consider that passing all three (including --t

RE: Is this a bug in autoconf? (patch included)

> -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 25, 2000 1:57 PM > To: Akim Demaille > Cc: Peter Eisentraut; Pavel Roskin; [EMAIL PROTECTED]; Autoconf > List > Subject: Re: Is this a bug in autoconf? (patch included) > > > > Peter> If you want to

Re: Is this a bug in autoconf? (patch included)

Hello! On Tue, 25 Apr 2000, Mo DeJong wrote: > I am still confused about what situation would actually > call for AC_CANONICAL_BUILD without also calling > AC_CANONICAL_HOST? Also, wouldn't I always need to call > AC_CANONICAL_BUILD when I was using AC_CANONICAL_HOST? You need AC_CANONICAL_BUIL

Re: autoheader question

> > Hm, I might be over picky, but I would have answered no. autoheader > > 2.13 is including all the paragraphs which are related to something > > which is AC_DEFINE'd, which is not necessarily all the content of > > acconfig.h. > > What about AC_DEFINE_UNQUOTED? And, shouldn't autoheader

Re: Is this a bug in autoconf? (patch included)

On Tue, 25 Apr 2000, Pavel Roskin wrote: > Hello! > > On Tue, 25 Apr 2000, Mo DeJong wrote: > > > I am still confused about what situation would actually > > call for AC_CANONICAL_BUILD without also calling > > AC_CANONICAL_HOST? Also, wouldn't I always need to call > > AC_CANONICAL_BUILD when

Re: Is this a bug in autoconf? (patch included)

Pavel Roskin wrote: > > Hello! > > On Tue, 25 Apr 2000, Mo DeJong wrote: > > > I was under the impression that the whole point of > > the --host flag was to tell autoconf that > > $host != $build and is therefore a cross compile. > > Absolutely no. You can cross-compile even packages that kno

Revamping AC_CANONICAL_*

New thread because it's getting hard to understand the chronology of the various comments :) Akim> I don't think dying is right: up to now the tradition in Akim> Autoconf has always been ignore what could make sense in another Akim> ./configure even if not the current one. Well, I implemented a

Re: backward compatibility (WAS: Re: Is this a bug in autoconf? (patch included))

--- Akim Demaille <[EMAIL PROTECTED]> wrote: -8<- > > We have to keep AC_CAN_SYS for backward compatibility. > -8<- I see this backward compatibility brought up quite often. Is there/should there be a switch to allow/disallow the deprecated macros? I would think that the deprecated macros wou

Re: Is this a bug in autoconf? (patch included)

Akim> 1. we add diversions which makes it possible to specify some Akim>processing of the options, and we don't support --target etc. by Akim>default. Akim> 2. when AC_CAN_TARGET is called, a variable is set very high in Akim>configure which tells the options handling machinery that -

Re: autoheader question

> "T" == T E Dickey <[EMAIL PROTECTED]> writes: T> the point would be to reduce effort (it appears that autoheader T> doesn't achieve that end) :P :) The problem was that Lars was AC_DEFINE($var), which unfortunately is not extensible in 2.13. It is now, and autoheader, IMHO, achieves tha

Re: Is this a bug in autoconf? (patch included)

--- Ralf Corsepius <[EMAIL PROTECTED]> wrote: -8<- > > IMHO, cross-compilation should be defined as build!=host. > This make logical sense build!=host indicates cross-compilation. = --- Earnie Boyd: __Cygwin: POSIX on Windows__ Cygwin Newbies:

Re: Is this a bug in autoconf? (patch included)

Hello, Ralf! > How about (under linux): > ./configure --build=i386-pc-linux-gnu --host=i386-pc-linux-gnulibc1 > > This definitely is cross-compilation (incompatible toolchains and > libraries, libc6 files under /usr, libc5 files under > /usr/i386-pc-linux-gnulibc1), but executables will run and

Re: autoheader question

> The problem was that Lars was AC_DEFINE($var), which unfortunately > is not extensible in 2.13. It is now, and autoheader, IMHO, achieves > that end for both the maintainer, *and* the end user. I personally > consider it is a requirement that all the #undef templates be > documented/described

Re: autoheader question

| > The problem was that Lars was AC_DEFINE($var), which unfortunately | > is not extensible in 2.13. It is now, and autoheader, IMHO, achieves | > that end for both the maintainer, *and* the end user. I personally | > consider it is a requirement that all the #undef templates be | > documented

Re: backward compatibility (WAS: Re: Is this a bug in autoconf? (patch included))

> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes: Earnie> --- Akim Demaille <[EMAIL PROTECTED]> wrote: -8<- >> We have to keep AC_CAN_SYS for backward compatibility. >> Earnie> -8<- Earnie> I see this backward compatibility brought up quite often. Is Earnie> there/should there be a sw

Re: Is this a bug in autoconf? (patch included)

> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Akim> 1. we add diversions which makes it possible to specify some Akim> processing of the options, and we don't support --target etc. by Akim> default. Akim> 2. when AC_CAN_TARGET is called, a variable is set very high in Akim> configure whi

Re: Is this a bug in autoconf? (patch included)

Akim Demaille wrote: > > > "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: > > >> Well, I hear you Pavel. I'm going to rewrite my patch, and submit > >> it. It will try to warn when --host, --build or --target is used > >> when it is not supposed to be. > > Ralf> I hope you consider

Re: Is this a bug in autoconf? (patch included)

From: Akim Demaille <[EMAIL PROTECTED]> Date: 25 Apr 2000 13:23:24 +0200 I don't think dying is right: up to now the tradition in Autoconf has always been ignore what could make sense in another ./configure even if not the current one. But I do understand that the present case

Re: Is this a bug in autoconf? (patch included)

> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: >> I am still confused about what situation would actually call for >> AC_CANONICAL_BUILD without also calling AC_CANONICAL_HOST? Also, >> wouldn't I always need to call AC_CANONICAL_BUILD when I was using >> AC_CANONICAL_HOST? Pavel> You

Re: Is this a bug in autoconf? (patch included)

Akim> But if it does make sense, if it does happen that people have a Akim> single deep configuration tree and they do want to --target it Akim> even though it makes no sense for some sub packages, then I'll Akim> s/AC_MSG_ERROR/AC_MSG_WARNING/ my patch. Akim> Still, for my own education, I would

Re: Is this a bug in autoconf? (patch included)

Hello, Akim! > Pavel> You need AC_CANONICAL_BUILD when I meant "you need to use results of AC_CANONICAL_BUILD, i.e. $build_os, $build_alias etc. in configure.in only in those rare situations" > Pavel, I'm lost again. No, you aren't :-) > It has been chosen that (?+ means defaults to) > > 1.

Re: Is this a bug in autoconf? (patch included)

> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Akim> Still, for my own education, I would like to be taught why it Akim> would make sense. Tom> Locally we put everything into a single tree, which you can Tom> configure with one command. This is really handy if we want to, Tom> say, ship

Re: Is this a bug in autoconf? (patch included)

Hello! > Ian and you do agree on this point. In fact, much of this thread is > precisely on this point. Pavel says, IIUC, that it does do harm to > some people to use --target when they meant something else. I > understand now why it would be wrong to issue an error for this issue. I don't in

Re: Is this a bug in autoconf? (patch included)

From: Akim Demaille <[EMAIL PROTECTED]> Date: 25 Apr 2000 18:56:57 +0200 Tom> However, "make" doesn't use --target. Still, it gets passed in Tom> by the top-level configure. I understand this, although I'd understand better with --host. So actually what you are teaching me is

Re: Is this a bug in autoconf? (patch included)

Date: Tue, 25 Apr 2000 16:30:50 +0200 From: Ralf Corsepius <[EMAIL PROTECTED]> > Autoconf defines cross-compiling as the situation when you cannot run > executables that you compile. I.e. Which is a fault, IMHO. I think that is reasonable. autoconf should also conclude that it is

Re: Revamping AC_CANONICAL_*

From: Akim Demaille <[EMAIL PROTECTED]> Date: 25 Apr 2000 16:34:11 +0200 Akim> I don't think dying is right: up to now the tradition in Akim> Autoconf has always been ignore what could make sense in another Akim> ./configure even if not the current one. Well, I implemented a dy

Re: Is this a bug in autoconf? (patch included)

Date: Tue, 25 Apr 2000 07:19:32 -0700 (PDT) From: Mo DeJong <[EMAIL PROTECTED]> Ok, I see your point about using AC_CANONICAL_BUILD, but is there any reason that someone would want to use AC_CANONICAL_HOST without having it AC_REQUIRE() AC_CANONICAL_BUILD? If $host defaults to $bu

Re: Revamping AC_CANONICAL_*

> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: Ian> Dying is definitely wrong. I am also inclined to vote against Ian> warnings. OK, then here is my revamped revamping. It does not include your suggestion for host != build => cross-compiling yet. I'd rather have this as a separat

Re: Is this a bug in autoconf? (patch included)

From: Akim Demaille <[EMAIL PROTECTED]> Date: 25 Apr 2000 18:05:03 +0200 The patch I submitted does what you don't it to do. This is because I thought that never ever there would be a deep configuration using --target, and with package that don't support it inside. I did so, b

Re: Is this a bug in autoconf? (patch included)

Date: Tue, 25 Apr 2000 11:26:24 -0400 (EDT) From: Pavel Roskin <[EMAIL PROTECTED]> > How about (under linux): > ./configure --build=i386-pc-linux-gnu --host=i386-pc-linux-gnulibc1 > > This definitely is cross-compilation (incompatible toolchains and > libraries, libc6 files

Re: Revamping AC_CANONICAL_*

On 25 Apr 2000, Akim Demaille wrote: > > "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > Ian> Dying is definitely wrong. I am also inclined to vote against > Ian> warnings. > > OK, then here is my revamped revamping. It does not include your > suggestion for host != build => cro

Re: Is this a bug in autoconf? (patch included)

Hello, Ian! >If you can run tests and intermediate programs, why should configure >forbid you doing that? Or maybe I don't understand what consequences >should cross-compiling have apart from that? > > Because if you run tests and intermediate programs, you are testing > the wrong sy

Re: Revamping AC_CANONICAL_*

On Apr 25, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote: > Akim, I was with you up until this one. Why would you want to remove the > --host option? I don't think that's what he's suggesting. I think he's suggesting to remove the use of `./configure TRIPLET' as equivalent to `./configure --host=TR

Re: Is this a bug in autoconf? (patch included)

Date: Tue, 25 Apr 2000 16:47:12 -0400 (EDT) From: Pavel Roskin <[EMAIL PROTECTED]> Tests normally don't require running programs. I completely agree. But the gap between ``normally don't'' and ``never'' is large. If you expect broken behaviour you should always test at runtime, unl

Re: Is this a bug in autoconf? (patch included)

On Apr 25, 2000, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > What does --cross add that we don't already have? The only point I see about it is that it *forces* configure to think it's being cross-compiled. So, even if an executable appears to run, GCC won't assume it's not cross-compiling.

Re: Is this a bug in autoconf? (patch included)

From: Alexandre Oliva <[EMAIL PROTECTED]> Date: 25 Apr 2000 18:31:45 -0300 On Apr 25, 2000, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > What does --cross add that we don't already have? The only point I see about it is that it *forces* configure to think it's being cross-com

So it seems like AC_C_BIGENDIAN is broken for cross case

When running a simple configure.in script that uses AC_C_BIGENDIAN I get the following error. checking whether the C++ compiler (i386-mingw32msvc-c++ ) works... yes checking whether the C++ compiler (i386-mingw32msvc-c++ ) is a cross-compiler... yes ... checking whether byte ordering is big

Re: So it seems like AC_C_BIGENDIAN is broken for cross case

Date: Tue, 25 Apr 2000 14:21:03 -0700 (PDT) From: Mo DeJong <[EMAIL PROTECTED]> When running a simple configure.in script that uses AC_C_BIGENDIAN I get the following error. checking whether the C++ compiler (i386-mingw32msvc-c++ ) works... yes checking whether the C++ compil

Re: Is this a bug in autoconf? (patch included)

On Apr 25, 2000, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >From: Alexandre Oliva <[EMAIL PROTECTED]> >Date: 25 Apr 2000 18:31:45 -0300 >On Apr 25, 2000, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >> What does --cross add that we don't already have? >The only point I see abo

Re: So it seems like AC_C_BIGENDIAN is broken for cross case

Mo DeJong <[EMAIL PROTECTED]> writes: > It seems clear that the AC_TRY_RUN does not have an argument for > the cross compile case. You mean to do something else in that case? > Can we at least get agreement that this AC_C_BIGENDIAN macro is in > fact broken? I think so. But it's really hard to

Re: Is this a bug in autoconf? (patch included)

Hello, Alexandre! > > What does --cross add that we don't already have? > > The only point I see about it is that it *forces* configure to think > it's being cross-compiled. So, even if an executable appears to run, > GCC won't assume it's not cross-compiling. Not only that. My idea was that

Re: So it seems like AC_C_BIGENDIAN is broken for cross case

Assar Westerlund <[EMAIL PROTECTED]> writes: > Mo DeJong <[EMAIL PROTECTED]> writes: >> Can we at least get agreement that this AC_C_BIGENDIAN macro is in >> fact broken? > I think so. But it's really hard to figure out the endianess of another > machine. The only ways of doing that that I can

Re: Is this a bug in autoconf? (patch included)

Date: Tue, 25 Apr 2000 19:59:51 -0400 (EDT) From: Pavel Roskin <[EMAIL PROTECTED]> > > What does --cross add that we don't already have? > > The only point I see about it is that it *forces* configure to think > it's being cross-compiled. So, even if an executable appears to r

Re: So it seems like AC_C_BIGENDIAN is broken for cross case

It's not pretty, but ntp's configure.in has: case "$host" in $target) AC_C_BIGENDIAN ;; *) case "$target" in i*86-*-vxworks*) # LITTLEENDIAN ;; *-*-vxworks*) AC_DEFINE(WORDS_BIGENDIAN) ;; *) AC_MSG_ERROR(Cross-compiling needs explicit byte

Re: Is this a bug in autoconf? (patch included)

Ian Lance Taylor wrote: > >Date: Tue, 25 Apr 2000 16:30:50 +0200 >From: Ralf Corsepius <[EMAIL PROTECTED]> > >> Autoconf defines cross-compiling as the situation when you cannot run >> executables that you compile. I.e. >Which is a fault, IMHO. > > I think that is reasonable

Re: So it seems like AC_C_BIGENDIAN is broken for cross case

[Problem posed is that autoconf fails when detecting endianness for a cross-compiler.] In GNU PSPP I attempt to detect endianness at my program's runtime for the case of a cross-compiler. This might be reasonable in some other cases, too.

Re: Is this a bug in autoconf? (patch included)

> "cls" == Christopher Seawood <[EMAIL PROTECTED]> writes: cls> In the Mozilla project, I chose to use $host != $target to be cls> indicative of a cross-compiled build. This is already wrong, because target is only meaningful for a compiler or some other part of a toolchain. Mozilla is a so

Re: So it seems like AC_C_BIGENDIAN is broken for cross case

Russ Allbery <[EMAIL PROTECTED]> writes: > I don't remember now where I originally read this (I thought it was in the > autoconf manual, but I can't find it now), but I seem to recall that the > theory behind the autoconf endianness test was that it could fail to > decide and that any program that

Re: So it seems like AC_C_BIGENDIAN is broken for cross case

How would people feel about the following patch? It sort of fixes AC_C_BIGENDIAN in the sense that it no longer errors out. I am not sure how we can detect the system's endian ordering without actually running a program, so this is a tempory suggested fix until a beter one comes along. Index: acl