> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jun 16, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>> There is a case where the new behavior is clearly wrong. That is
>> when --build and --host are both given and they are exactly the
>> same. I have appended a patc
I just noticed that even for a native build, the change to AC_CHECK_TOOLS
will print out a bunch of ugly cached messages.
checking for g++... g++
checking for c++... (cached) g++
checking for gpp... (cached) g++
checking for aCC... (cached) g++
checking for CC... (cached) g++
checking for cxx...
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> And you are rejecting the fact that you don't need to specify
>> --build, you just need --host. This is a huge step backwards!
Alexandre> We may have an `I-know-what-I'm-doing' option, such as
Alexandre> --Host, for example.
I
> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
Earnie> I have yet to do a cross-compile but hope to use Akim's and
Earnie> Mo's patches to do so when I GARTI.
Hm, Get A Ride To It? No, doesn't sound right. The dictionaries of
dict(1) don't seem to know this one.
Akim
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> Well, I was definitely referring to the Cygnus' case, because
>> that's probably the largest trees we will ever find, so that's
>> probably where it is more likely to have momentum (definitely not a
>> critic, just a statement).
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> I just noticed that even for a native build, the change to
Mo> AC_CHECK_TOOLS will print out a bunch of ugly cached messages.
Mo> checking for g++... g++ checking for c++... (cached) g++ checking
Mo> for gpp... (cached) g++ checking for aCC
On 28 Jun 2000, Akim Demaille wrote:
> OK, I see. I was still under the impression that Cygnus was wrapping
> the trees, I had not understood users were likely to assemble trees.
When a user downloads gcc, it already has a configure script
that was generated and checked into the CVS. Besides, h
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> On 28 Jun 2000, Akim Demaille wrote:
>> OK, I see. I was still under the impression that Cygnus was
>> wrapping the trees, I had not understood users were likely to
>> assemble trees.
Mo> When a user downloads gcc, it already has a configu
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> The fixed (quoted) patch. ChangeLog entry:
Lars> 2000-06-27 Lars J. Aas <[EMAIL PROTECTED]>
Lars> * acgeneral.m4: create subdirs, including parent
Lars> directories that don't exist already.
I believe you should write an AC_
On Jun 28, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> OK, I'm ``convinced'' :)
Alexandre> Yahh
> Hey, wait that I send the message before answering! :)
:-D :-D
Thank you.
> But I approve your patch.
Thanks. I won't install it as-is. I'll merge Mo's patch too (since
it would con
On Jun 28, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Now I understand Cygnus does not package forest
Cygnus does. It is GNU that doesn't. So this change is more
important for GNU developers in general than for Cygnus' customers.
I'm sorry I didn't make this clear from the beginning. I
On Jun 28, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Do you think there is really a chance that in a not so distant future,
> in this galaxy, we will reimplement the behavior we have in CVS?
Yep, but not in the next 100 weeks or so :-)
> I fear we will never be able to, for instance beca
On Jun 28, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> Some Cygnite
> Cygnite :) How cute :) Is the `i' as in `night' or `nit'? Hm, I
> guess it is more like `knight' :)
I've always read it as `night', but I'd n
On 28 Jun 2000, Alexandre Oliva wrote:
> On Jun 28, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> > Now I understand Cygnus does not package forest
>
> Cygnus does. It is GNU that doesn't. So this change is more
> important for GNU developers in general than for Cygnus' customers.
> I'm
On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> Sorry, but I just do not see the logic in that argument. If some
> tool has not been updated for 5 years, what are the chances
> someone if going to switch to the new autoconf and expect everything
> to work exactly the same way?
It's the c
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> I too fear we'll never be able to drop the old behavior,
Alexandre> since there are packages out there that haven't had update
Alexandre> releases for 5 years or more. We shouldn't expect such
Alexandre> packages to disa
> It's the converse: tools that configure and build other tools, such as
> RPM, may prefer a consistent interface to build pretty much
> everything, instead of having to customize its behavior for old
> packages. But the importance of the backward-compatible change
> for GNU projects doesn't have
> Wednesday, May 1st 2002 on [EMAIL PROTECTED]
>
> Back-war Killer Oliva
>
> vs
>
> Host-ile Froggy Akim
>
> Will Oliva keep his World Championship title?
An autotools death match? I would buy a TV to see that!
The other
On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> But, there is nothing to update! We have already addressed the
> issue of toplevel configure passing both --build and --host
> down to sub-configures.
Indeed. But there's a lot of documentation to be updated, so that
people will use --buil
On 28 Jun 2000, Alexandre Oliva wrote:
> On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > But, there is nothing to update! We have already addressed the
> > issue of toplevel configure passing both --build and --host
> > down to sub-configures.
>
> Indeed. But there's a lot of docum
On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> If you are talking about our internal cygnus documentaiton,
I am. Or, actually, Angela was :-)
>> And we also have to update the top-level configure to reflect the
>> new semantics of --build and --host.
> Is that the main argument for r
Boy, this is funny. While this whole --host flame was
raging, I came across this note on the mingw mailing
list. This is just further proof that new users do
not understand the old cross compile semantics and
that the docs don't help much.
Mo DeJong
Red Hat Inc
Hi All,
I noticed the other day
Since I don't actually use CVS autoconf anywhere (because of it's
incompatibilities with automake) and don't have it installed, please
test this patch before applying it.
Lars J
2000-06-28 Lars J. Aas <[EMAIL PROTECTED]>
* acgeneral.m4 (AC_SHELL_MKDIR_P): New macro.
(_AC_OU
> > Is that the main argument for reverting back to the old
> > --host semantics?
>
> Nope. There are several arguments. Please read all this thread
> carefully.
I have been following this thread :)
The problem of passing options down to sub configures
is solved by my patch, right?
The only
On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> The problem of passing options down to sub configures
> is solved by my patch, right?
Yep.
> The only other issue is the change that required
> the user to pass --build instead of --host
> when only one is given on the command line.
When
> When --host is given, we should not just assume we've got a cross
> compiler. Instead, we test the compiler we've got, and decide whether
> it's a cross compiler or not.
...
> The only concessions for backward compatibility we're making is that
> --host alone will cause a cross-compilation situ
On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> Why can't we just switch the value of $build over to the output of
> config.guess for the build system when we try to detect a cross
> compiler and the resulting executable can not be run?
Compare the output of `config.guess' with that of
`
On 28 Jun 2000, Alexandre Oliva wrote:
> On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > Why can't we just switch the value of $build over to the output of
> > config.guess for the build system when we try to detect a cross
> > compiler and the resulting executable can not be run?
>
On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> What is wrong with just running config.guess without knowing
> anything about the cross compiler?
People would have set CC=/path/to/cross-compiler, and config.guess
would use it unless CC_FOR_BUILD or HOST_CC are set. There's room for
a lo
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> When --host is given, we should not just assume we've got a
Alexandre> cross compiler. Instead, we test the compiler we've got,
Alexandre> and decide whether it's a cross compiler or not.
This one, I don't get it clea
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> It would be trivial to accomplish that: just remove the
Alexandre> line that sets build_alias=$host_alias from my proposed
Alexandre> patch.
Alexandre> The more I think about it, the more I think it's a good
Alexandre> i
Hi,
with autoconf 2.13, i was able to do the following:
AC_ARG_ENABLE(feature, [ --enable-feature='STRING'],
AC_DEFINE_UNQUOTED(FEATURE,"$enableval"))
and then call configure --enable-feature='Some string\\nWith newlines'
which resulted in a line
#define UNIX_PROMPT "Some string\nWith newl
--- Akim Demaille <[EMAIL PROTECTED]> wrote:
> > "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
>
> Earnie> I have yet to do a cross-compile but hope to use Akim's and
> Earnie> Mo's patches to do so when I GARTI.
>
> Hm, Get A Ride To It? No, doesn't sound right. The dictionaries o
On Jun 28, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Why would someone set host != build
> and not expect cross-compiling?
I'm taking about the case in which build is not specified. In this
case, the user may have meant the old behavior, in which --host would
set the default for build an
On Jun 28, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> It would be trivial to accomplish that: just remove the
Alexandre> line that sets build_alias=$host_alias from my proposed
Alexandre> patch.
> Yes!
But note tha
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> Yes!
Alexandre> But note that cross_compiling=maybe is still necessary.
Gross :)
You know, frankly, I'm just trusting you, I'm dead lost.
Never before the CVS Autoconf cross_compiling revamping, had I
understood the mecha
Is it portable to do
install file1 file2 file3 dir
Or using Autoconf, is is portable to do
${INSTALL_XXX} file1 file2 file3 dir
--
Peter Eisentraut Sernanders väg 10:115
[EMAIL PROTECTED] 75262 Uppsala
http://yi.org/peter-e/Sweden
| Since I don't actually use CVS autoconf anywhere (because of it's
| incompatibilities with automake)
What do you mean?
| and don't have it installed, please
| test this patch before applying it.
OK, I will. I approve this patch, but I will rewrite the while into a
for. I'll write a test t
On Wed, Jun 28, 2000 at 06:48:24PM +0200, Akim Demaille wrote:
: | Since I don't actually use CVS autoconf anywhere (because of it's
: | incompatibilities with automake)
:
: What do you mean?
We use a patched automake-1.4a (2000-05-31), and we use it with a
patched autoconf-2.14.1 (2000-01-13).
> -Original Message-
> From: Akim Demaille [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 28, 2000 6:19 PM
> To: Alexandre Oliva
> Cc: Mo DeJong; [EMAIL PROTECTED]
> Subject: Re: --host => cross breaks GCC builds
>
>
> > "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
On Jun 28, 2000, Bernard Dautrevaux <[EMAIL PROTECTED]> wrote:
> What I do not fully understand is why the patch saying that if --build and
> --host are passed and equal we are not cross compiling and modifying the top
> cygnus configure script to be backward compatible and to pass both --build
>
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> I too fear we'll never be able to drop the old behavior, since there are
> packages out there that haven't had update releases for 5 years or more.
> We shouldn't expect such packages to disappear, so, it would not be
> unreasonable to retain some beh
42 matches
Mail list logo
