mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] Specifying --build (was: make curl fails)


From: Volker Grabsch
Subject: Re: [Mingw-cross-env-list] Specifying --build (was: make curl fails)
Date: Sat, 26 Nov 2011 23:28:08 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Tony Theodore schrieb:
> On 27 November 2011 07:26, Mark Brand <address@hidden> wrote:
> >> Shall we just install the config.guess from gcc to
> >> <mcedir>/usr/bin/config.guess and add the following to the main
> >> Makefile?:
> >>
> >>    BUILD      := $(shell $(PWD)/usr/bin/config.guess)
> >
> > This better I think:
> >
> >    BUILD      := $(shell $(PREFIX)/bin/config.guess)

This is better, but I still think that

     --build=`$(TARGET)-config.guess`

is more clear than our new variable

     --build=$(BUILD)

In other words, I think that our BUILD variable would
introduce an indirection which makes things less
transparent without providing any real benefit.

In the tutorial, we should mention something like this:

    ./configure ... --build=`i686-pc-mingw32-config.guess`

> This seems ideal, gcc is the "perfect" source for config.guess, if a
> platform isn't recognised by gcc, we can't do much with it!

Agreed.

> I think it's safe to put this is in $(PREFIX)/bin, even without a
> prefix, this script is always appropriate to run on the build machine.

I'd still like to prefix those. Not because it is mingw32
specific, but because it is created by out toolchain!

Imagine other scripts would override our config.guess with
a new (or even an older) version -- this would cry for trouble.
Note that we also prefix tools like "strip" or "strings",
although those are usually platform independent.

> There's another script, config.sub. I'm not sure what it does, but it
> seems to be a complement to config.guess. I imagine that if we install
> them in the same place, all will be fine.

Would you mind investigating further in how far those
two scripts are connected. Also, do we really need a
system-wide config.sub, or are the local versions of the
respective packages sufficient if we already provide the
--build option to ./configure?


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---



reply via email to

[Prev in Thread] Current Thread [Next in Thread]