--- Bernard Dautrevaux <[EMAIL PROTECTED]> wrote:
>
> Just to verify: You're talking of recognizing MinGW as a BUILD system, not
> HOST, aren't you? uname will only give information about the BUILD system,
> so if we plan to configure using a cross-compiler, uname will do no good :-)
>
AFAICT,
> -Original Message-
> From: Earnie Boyd [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 27, 2000 6:24 PM
> To: Akim Demaille; Alexandre Oliva
> Cc: Morten Eriksen; [EMAIL PROTECTED]
> Subject: Re: AC_PROG_CC not working
>
>
> --- Akim Demaille <[EMAIL
--- Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> So I am back to something I raised some time ago: why the heck do we
> have to compile to recognize Mingw etc.? Can't we just uname? While
> anti-Autoconf (and btw, frankly, compiling __MINGW32__ makes no big
> difference to me), it seems better
On Wed, Oct 11, 2000 at 10:16:07AM +0200, Akim Demaille wrote:
> > "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
>
> Gary> Actually, cvs libtool is still much happier with autoconf-2.13
> Gary> than cvs autoconf =(O| I am hoping that a 2.50 compatible
> Gary> libtool-1.4 won't be too f
Hello, Earnie!
On Wed, 11 Oct 2000, Earnie Boyd wrote:
> --- Pavel Roskin <[EMAIL PROTECTED]> wrote:
> >
> > Since EXEEXT="" makes "cp" fail it's not a good choice. So instead of
> > doing "test contest -ef contest.exe" do "cp contest contest.ac_" and
> > reverse the logic (i.e. if "cp" fails w
* Pavel Roskin
| Since EXEEXT="" makes "cp" fail it's not a good choice. So instead
| of doing "test contest -ef contest.exe" do "cp contest contest.ac_"
| and reverse the logic (i.e. if "cp" fails we use ".exe")
Well, I don't think this is such a good idea. What if the Cygwin port
of ``cp'' is s
--- Pavel Roskin <[EMAIL PROTECTED]> wrote:
>
> Since EXEEXT="" makes "cp" fail it's not a good choice. So instead of
> doing "test contest -ef contest.exe" do "cp contest contest.ac_" and
> reverse the logic (i.e. if "cp" fails we use ".exe")
>
This sounds good, but you'd have to test for the
Hello, Peter!
> This equivalency only affects stat() and the PATH search of the shell. So
> you can write makefiles like this:
>
> fooprog: $(OBJS)
> $(CC) -o $@ $^
>
> install: fooprog
> $(INSTALL) fooprog$(EXEEXT) $(bindir)
>
> and they will work. But it probably doesn't in gen
Hello, Peter!
> One real example is PostgreSQL on AIX, where you need to use xlc instead
> of whatever else configure might think. (AC_PROG_CC_STDC is less than
> ideal for related reasons.) I still want to check for gcc first, though,
> so I'd use AC_PROG_CC([gcc xlc cc]). Then we have older
Morten Eriksen writes:
> (So, in the Cygwin case it doesn't really matter whether you set the
> executable suffix to ".exe" or "", I guess.)
This equivalency only affects stat() and the PATH search of the shell. So
you can write makefiles like this:
fooprog: $(OBJS)
$(CC) -o $@ $^
ins
--- Pavel Roskin <[EMAIL PROTECTED]> wrote:
> Hello, Morten!
>
> > Not really, no. For instance, Cygwin does this funny thing where they
> > map all files named ``something.exe'' to also match any inquires to a
> > file named ``something''.
>
> Why do you want to set ac_exeext to ".exe" then? Wh
Hello, Morten!
> Not really, no. For instance, Cygwin does this funny thing where they
> map all files named ``something.exe'' to also match any inquires to a
> file named ``something''.
Why do you want to set ac_exeext to ".exe" then? Why bother if Cygwin did
everything to hide this complexity
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> [...] I mean if you do cc conftest.c -o conftest, and afterwards
> there is no file "conftest", but there is a file "conftest.exe" that
> wasn't there before, that should be pretty conclusive, no?
Not really, no. For instance, Cygwin does this funny
Akim Demaille writes:
> So I am back to something I raised some time ago: why the heck do we
> have to compile to recognize Mingw etc.? Can't we just uname? While
> anti-Autoconf (and btw, frankly, compiling __MINGW32__ makes no big
> difference to me), it seems better in that, for instance, it
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Actually, cvs libtool is still much happier with autoconf-2.13
Gary> than cvs autoconf =(O| I am hoping that a 2.50 compatible
Gary> libtool-1.4 won't be too far behind the autoconf release...
What's wrong? How does it happen? Wh
On Tue, Oct 10, 2000 at 06:30:54PM +0200, Akim Demaille wrote:
> > "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> Bob> Please take a moment to release stable and compatible versions of
> Bob> Autoconf, Automake, and Libtool so that there is a new baseline
> Bob> for us users.
>
>
Pavel Roskin writes:
> > Peter> This feature is extremely useful, because the default list is
> > Peter> pretty useless for some platforms and packages.
>
> Peter, it is extremely important that you give some real examples here.
One real example is PostgreSQL on AIX, where you need to use xlc i
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Akim> I think we will never stop having problem with this feature :(
Pavel> Don't be pessimistic. We haven't tried it hard yet.
You're not a Jedi yet, soon you'll be attracted by the dark side.
Then you'll be a real Autoconf maintainer :
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> Please take a moment to release stable and compatible versions of
Bob> Autoconf, Automake, and Libtool so that there is a new baseline
Bob> for us users.
Rest reassured: we don't plan to release a buggy Autoconf. Libtool is
in go
Hello, Akim and others!
> >> Anyway, I am still against the possibility to specify a list of
> >> compilers for AC_PROG_CC, CXX etc. I think we will never stop
> >> having problem with this feature :(
Don't be pessimistic. We haven't tried it hard yet.
> Peter> This feature is extremely useful
On 10 Oct 2000, Akim Demaille wrote:
>
> I don't know. To be honest, I'm starting to despair: there are way
> too many things that need to be completely redesigned in Autoconf, but
> *we can't wait*. 2.50 is already significantly superior to 2.13, and
> we need to stop somewhere. We need to st
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> I don't much care how many features you add if the old
Thomas> configure.in scripts do not work properly. (When is 2.49b
Thomas> coming out so we can see if some of the bugs are fixed?)
It should happen RSN. The problem is t
On 10 Oct 2000, Akim Demaille wrote:
> > "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes:
> I don't know. To be honest, I'm starting to despair: there are way
> too many things that need to be completely redesigned in Autoconf, but
> *we can't wait*. 2.50 is already significantly supe
| configure.in:
| ...
| : ${CC-my_super_script_CC}
Sorry, I meant:
: ${CC=my_super_script_CC}
| AC_PROG_CC
> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes:
Morten> One argument for using the output of uname in some form
Morten> instead of the current scheme is that the Cygwin test (at
Morten> least) will fail if not using GCC as the compiler. I'm using
Morten> MSVC++ cl.exe now, and the Cy
> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes:
Morten> The particular challenge I just bumped into is how to let
Morten> Autoconf configure know about a "self-made compiler", in the
Morten> sense that I have written a wrapper script around the MSVC++
Morten> cl.exe compiler (to let
Akim Demaille <[EMAIL PROTECTED]> writes:
> So I am back to something I raised some time ago: why the heck do we
> have to compile to recognize Mingw etc.? Can't we just uname?
I'll second that notion. :^)
One argument for using the output of uname in some form instead of the
current scheme is
Akim Demaille <[EMAIL PROTECTED]> writes:
> Really, giving a list of compilers seems bad to me. It should be
> the same list for everybody, i.e., let's fix the Autoconf builtin
> list if its wrong, but let's not go for various flavors of
> configure.
A few days ago I would have agreed with you
The problem is that:
/tmp % ace --trace AC_PROG_CC
autoconf: warning: --macrodir is obsolete, use --autoconf-dir
configure.in:2:AC_PROG_CC:foo bar supercompiler
configure.in:2:AC_PROG_CC:
someone is requiring AC_PROG_CC *inside* the AC_PROG_CC itself. But
since AC_PROG_CC (the first one) is in
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Oct 9, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Currently I can't think of any good one. In addition, I now think
>> it is now feasible to merge *_CPP in *_CC as I first thought, not
>> without revamping a lo
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Akim Demaille writes:
>> Anyway, I am still against the possibility to specify a list of
>> compilers for AC_PROG_CC, CXX etc. I think we will never stop
>> having problem with this feature :(
Peter> This feature is extremely
On Oct 9, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Currently I can't think of any good one. In addition, I now think it
> is now feasible to merge *_CPP in *_CC as I first thought, not without
> revamping a lot of code which is a big no before 2.50.
How hard do you think it would be to
Akim Demaille writes:
> Anyway, I am still against the possibility to specify a list of
> compilers for AC_PROG_CC, CXX etc. I think we will never stop having
> problem with this feature :(
This feature is extremely useful, because the default list is pretty
useless for some platforms and packa
| The obvious reason for this behavior is that AC_PROG_CC requires
| AC_PROG_CPP to run before the AC_PROG_CC macro body. This will then
| pick up the gcc compiler (if present) and then use the cached value
| for CC, no matter which compilers we specify for AC_PROG_CC.
|
| Any suggestions on how
Hi,
I don't see the expected behavior from the AC_PROG_CC macro. This
configure.in file:
-->8>8>8>8>8>8>8>8>8--
AC_INIT(configure.in)
AC_PROG_CC(foo bar supercompiler)
AC_OUTPUT()
-->8>8>8>8>8>8>8>8>8--
..will generate this outpu
35 matches
Mail list logo
