[Top][All Lists]

[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 20:49:03 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Tony Theodore schrieb:
> On 27 November 2011 02:28, Mark Brand <address@hidden> wrote:
> > 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`

I like this approach, but I'd put it in a more standard
place under usr/.

We could make this similar to the CMAKE toolchain file.


Or, we could prefix it and install it easily accessible
into PATH:


As a side node, I strongly recommend to use `config.guess`
rather than `sh config.guess`, because we already do
control which shell is used (i.e. bash), while "sh"
points to different shells depending on your system.

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

While I agree that this would save about 3-4 lines
in many src/*.mk files, the downside is that it this
makes it transparent and less obvious which ./configure
options exactly are used. Keep in mind that using
generating too many ./configure options automatically
is what makes other build systems harder to understand
as well as harder to debug.

However, I'd love to hear different opinions on that


Volker Grabsch

reply via email to

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