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.
>
>
* Morten
| It was also mentioned on the list a while ago (by yours truly) how the
| _AC_EXEEXT macro has a circular dependency: _AC_EXEEXT uses
| AC_LINK_IFELSE which uses $ac_exeext which is found by _AC_EXEEXT.
* Akim
| AFAICS you still have this problem: you use AC_LINK_IFELSE. You
| shouldn'
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
| It was also mentioned on the list a while ago (by yours truly) how the
| _AC_EXEEXT macro has a circular dependency: _AC_EXEEXT uses
| AC_LINK_IFELSE which uses $ac_exeext which is found by _AC_EXEEXT.
AFAICS you still have this problem: you use AC_LINK_IFELSE. You
shouldn't, rather, see how
Hi,
this issue was touched upon earlier today: how the _AC_EXEEXT macro
does host-checking for Cygwin|Mingw|EMXOS2 when deciding the value of
$ac_exeext (which seems like an ugly mismatch with standard Autoconf
policy of checking for _features_ to me).
It was also mentioned on the list a while a
> "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
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> To be strict, the testsuite doesn't guarantee it because macros
Pavel> can expand differently dependent e.g. on the number of
Pavel> arguments.
I agree.
Pavel> Anyway, I agree with your decision.
I agree too :)
Pavel> I can, b
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
20 matches
Mail list logo
