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: Tony Theodore
Subject: Re: [Mingw-cross-env-list] Specifying --build (was: make curl fails)
Date: Sun, 27 Nov 2011 05:49:34 +1100

On 27 November 2011 02:28, Mark Brand <address@hidden> wrote:
>>>>   Hint: if you mean to override the result of config.guess, prefer --build
>>>> over
>>>>   --host. In the future, --host will not override the name of the build
>>>> system
>>>>   type. Whenever you specify --host, be sure to specify --build too.
>
>>
>> Sounds like a good idea, we do something similar thing in guile.mk
>> [1]. I wonder if we should abstract --host, --build, and --prefix into
>> a main Makefile variable?
>>
>>
>
> I've tried changing a lot of the package that have the cross_compiling
> hack to use --build. No problems so far. Sometimes the config.guess
> script is in subdir 'build-aux' instead of the top of the package
> tree.
>
> Your idea of arranging this centrally sounds good. I guess it's
> probably okay to run something like 'config.guess' once per
> installation of mingw-cross-env instead of once per package, but I
> wouldn't bet on it yet though. What's your view?

There's always going to be some project that tries to bootstrap itself
by building parsers/compilers/interpreters/generators which will
confound cross-building efforts. That said, my main experience with
config.guess is patching projects [1] to use a more recent version
[2].

Based on that, I'd say that having a canonical "--build" based on a
recent config.guess would remove the need for all those patches (and
bug reports) and possibly remove all "wine sed hacks" (if --build
actually overrides execution logic). At a stretch I'd say that "build"
never makes it's way into config.h and most projects will use compiler
defines over any other detection mechanism.

Having a single "--build" may also help on Mac OSX when the system
compiler defaults change,  but projects don't update their
config.guess (thinking of glib).

> Should we decide to invoke config.guess for each package, is it okay
> to do it like this:
>
>    --build=`./config.guess`
>
> instead of using an absolute path:
>
>    --build=`$(1)/config.guess`
>
> ?

Mmmm, not sure. As you mentioned earlier, config.guess can be in
different places, and both will fail if execute bits aren't set (for
whatever reason). I'd probably keep a recent version in /tools or /src
and invoke it with:

    --build=`sh $(TOP_DIR)/[tools|src]/config.guess`

This could be wrapped in a new Makefile variable:
    --build=... \
    --host=... \
    --prefix=... \
    [--enable-static \]
    [--disable-shared]

Cheers,

Tony

[1] http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/51d315639b69
[2] 
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD



reply via email to

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