| %% Akim Demaille <[EMAIL PROTECTED]> writes:
| ad> aclocal is to be run twice: one first time to make sure all the
| ad> macros that might be used are imported, so that, for instance, if
| ad> you use PDS_USUAL_STUFF which includes an invocation of
| ad> AM_GNU_GETTEXT, or AC_PROG_LIBTO
In message <[EMAIL PROTECTED]>
"John W. Eaton" <[EMAIL PROTECTED]> wrote:
> What is the right way to use autoconf to determine the compiler and
> system characteristics for tools that are written in C and must be run
> as part of a larger build that is cross compiled?
>
> For example,
Stewart Brodie <[EMAIL PROTECTED]> writes:
|> This is the approach that I have taken:
|>
|> AC_MSG_NOTICE([configuring the tools for *native* builds])
|> cd tools && \
|> ./configure --build=$build_alias --host=$build_alias --target=$host_alias
Note that this does not work if $srcdir != $buildd
In message <[EMAIL PROTECTED]>
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Stewart Brodie <[EMAIL PROTECTED]> writes:
>
> |> This is the approach that I have taken:
> |>
> |> AC_MSG_NOTICE([configuring the tools for *native* builds])
> |> cd tools && \
> |> ./configure --build=$build_
Ok thanks !!
:)
__
Boîte aux lettres - Lycos - http://www.lycos.fr
On Tue, Oct 08, 2002 at 10:11:28AM +0100, Stewart Brodie wrote:
> In message <[EMAIL PROTECTED]>
> "John W. Eaton" <[EMAIL PROTECTED]> wrote:
> > If necessary, I could put these tools in a separate directory with an
> > independent configure script, but then what is the correct way to te
On Tue, Oct 08, 2002 at 01:30:37PM -0400, Thomas E. Dickey wrote:
> Deliberately introducing design incompatibilities simply encourages people
> to use other tools.
Then why's MS Office so popular? :-)
Seriously, so can failing to introduce them, if the price of
compatibility is to avoid making
Hi,
I can't build 2.54 or the current cvs on i686-pc-linux-gnu or
sparc-sun-solaris2.8. The make error reported is
../../tests/autom4te\
--language=m4sugar \
--freeze\
--output=m4sugar.m4f
/home/na
On Tue, 8 Oct 2002, Eric Siegerman wrote:
> On Tue, Oct 08, 2002 at 01:30:37PM -0400, Thomas E. Dickey wrote:
> > Deliberately introducing design incompatibilities simply encourages people
> > to use other tools.
>
> Then why's MS Office so popular? :-)
not with me (I figure that it's popular be
> From: Nathan Sidwell <[EMAIL PROTECTED]>
> Date: Tue, 08 Oct 2002 20:45:02 +0100
> oo, I just found it. If you have POSIXLY_CORRECT set, you get the
> problem
POSIXLY_CORRECT breaks a lot of things, unfortunately. I installed
the following patches to work around your particular problem, and o
We sorely need a libtool 1.4.3 -- autoconf is consistently being blamed for
its brokenness and in general its portability is flaky on some systems (like
Darwin).
I don't have the time and knowledge to propose myself for libtool
maintainership, but I can trust people that do have this knowledge an
Wouldn't it be better to get libtool 1.5 out the door? The resources
required to achieve a releasable product are similar and CVS libtool
already contains most of the fixes that would go into a 1.4.3.
Bob
On Tue, 8 Oct 2002, Bonzini wrote:
> We sorely need a libtool 1.4.3 -- autoconf is consis
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> Wouldn't it be better to get libtool 1.5 out the door? The
Bob> resources required to achieve a releasable product are similar
Bob> and CVS libtool already contains most of the fixes that would go
Bob> into a 1.4.3.
There is one bi
On 8 Oct 2002, Akim Demaille wrote:
>
> There is one big question which must be answered first: will it have
> to be Autoconf 2.13 compatible?
>
> I *strongly* suggest that it must not. It should AC_PREREQ 2.54
> immediately. Then, I'm fine with checking the M4 code and making it
> up to date.
Bob Friesenhahn writes:
> On 8 Oct 2002, Akim Demaille wrote:
> >
> > There is one big question which must be answered first: will it have
> > to be Autoconf 2.13 compatible?
> >
> > I *strongly* suggest that it must not. It should AC_PREREQ 2.54
> > immediately. Then, I'm fine with checking the
Bob Friesenhahn wrote:
> On 8 Oct 2002, Akim Demaille wrote:
>
>>There is one big question which must be answered first: will it have
>>to be Autoconf 2.13 compatible?
>>
>>I *strongly* suggest that it must not. It should AC_PREREQ 2.54
>>immediately. Then, I'm fine with checking the M4 code an
Lars Hecking wrote:
> Bob Friesenhahn writes:
>
>>On 8 Oct 2002, Akim Demaille wrote:
>>
>>>There is one big question which must be answered first: will it have
>>>to be Autoconf 2.13 compatible?
>>>
>>>I *strongly* suggest that it must not. It should AC_PREREQ 2.54
>>>immediately. Then, I'm fi
> > There is one big question which must be answered first: will it have
> > to be Autoconf 2.13 compatible?
We use it for the PHP project (>80k lines configure script),
because 2.5x is 5 to 6 times slower and contains a
dependency-ignorant cache system.
So, please don't create i
Earnie Boyd <[EMAIL PROTECTED]> writes:
> Two wrongs a right does not make. I.E.: I believe it wrong for any
> maintainter to not move forward with the current versions of autotools
> regardless of the maintainer's reasons for not doing so.
That comes across as pretty arrogant.
autoconf 2.5x w
On Tue, 8 Oct 2002, Bob Friesenhahn wrote:
> On 8 Oct 2002, Akim Demaille wrote:
> >
> > There is one big question which must be answered first: will it have
> > to be Autoconf 2.13 compatible?
> >
> > I *strongly* suggest that it must not. It should AC_PREREQ 2.54
> > immediately. Then, I'm fi
On Tue, 8 Oct 2002, Earnie Boyd wrote:
> FWIR, Akim and other developers tried hard to maintain [back|bug]ward
> compatibility. But, some of the incompatibility was ill formed autoconf
> syntax so that incompatibility wasn't maintained and instead a better
> parser was put into place.
not at al
On Tue, 8 Oct 2002, Lars Hecking wrote:
> Bob Friesenhahn writes:
> > On 8 Oct 2002, Akim Demaille wrote:
> > >
> > > There is one big question which must be answered first: will it have
> > > to be Autoconf 2.13 compatible?
> > >
> > > I *strongly* suggest that it must not. It should AC_PREREQ
On Tue, 8 Oct 2002, Thomas E. Dickey wrote:
> > > I agree. I can't imagine why anyone would want to use an antique
> > > version of Autoconf which dates from 1996.
> >
> > Because it works? In any case, it's the respective maintainer's choice.
> >
> > Making autoconf incompatible with previous
Hello, Russ!
I'm the one who suggested the version 2.50 when it was discussed whether
the next version should be 2.14, 2.15 or 3.0. The reason was because
there was some incompatibility, but not significant to justify the major
number change.
It is possible to write configure.in compatible with
Libtool-ers;
I think this issue simply becomes mired by stacking up on either side of
a "for/against" line.
Previously, it was mentioned that certain troublesome source trees be
used as litmus tests for automake or autoconf changes; the same may hold
true now for libtool. Brief summary: if you
On Tue, Oct 08, 2002 at 11:36:40AM -0500, Bob Friesenhahn wrote:
> On 8 Oct 2002, Akim Demaille wrote:
> > There is one big question which must be answered first: will it have
> > to be Autoconf 2.13 compatible?
> >
> > I *strongly* suggest that it must not. It should AC_PREREQ 2.54
> > immediate
> I developed/maintain the configure script for ImageMagick. While the
> total lines in the generated configure script is meaningless, it is
> less than 1/2 of what you report for PHP, and PHP's configure script
> is 4-8X larger than typical configure scripts for other large packages
> (e.g. 4X l
Hello!
> People who stick to the 2.13 guns can stick to the libtool
> 1.3.3/whatever guns. I see no reason why *new* code (third-party
> packages) should require a *new* libtool but an *old* autoconf. And the
> argument that "2.13 works" doesn't fly by me: "so does 1.4.2" (or
> whatever the las
[Cc line trimmed]
> me too! :)
I think we have heard all arguments by now. There is no need
to reiterate them.
Whatever the outcome of this thread might be -- I hope those
who work on libtool will continue to provide a toolkit which
is suitable for all of us -- develop
Ok,
So a 1.4.3 version is desired, that's established.
The million-dollar question is:
Does current branch-1-4 Libtool do the trick?
If so, then a roll out could be done within the week.
Robert
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL:
30 matches
Mail list logo
