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: Mon, 28 Nov 2011 09:53:17 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Mark Brand schrieb:
> >>In other words, I think that our BUILD variable would
> >>introduce an indirection which makes things less
> >>transparent without providing any real benefit.
> 
> I couldn't quite bring myself to call config.guess
> '$(TARGET)-config.guess' since that seems to me to suggest that it
> guesses about the target. I also like the uncluttered look of
> "--build='$(BUILD)'" in the .mk files. Maybe it's just me. If you
> want to change it, I'll defer to your judgment and won't be
> offended.

This is not just a matter of taste, I think that using
$(BUILD) in this way is even dangerous. It suggests that
$(BUILD) is some pre-set variable that won't change over
time, but this isn't true! (see below)

$(BUILD) would _only_ make sense if we ship our own config.guess
with mingw-cross-env. This would ensure that

    1) $(BUILD) is always set and can be use anywhere.

    2) $(BUILD) won't change (slightly) over time after
       installing a new binutils/gcc version.

As of now, none of those properties are ensured. Which is
perfectly okay! I like your approach of taking config.guess
from binutils or gcc instead of shipping our own version.

But in that case it we should hide that fact, or we'll
introduct race conditions where this works today and fails
tomorrow.

> I would also point out that it's already the case that usr/bin is
> supposed to be first in the PATH when using mingw-cross-env. This
> directory is already a sort of namespace for our config.guess.

I fully agree. I think I was be overly cautious. Prefixing
config.guess will cause more confusion than clarity. So I'm
opting for:

    --build="`config.guess`"

which makes clear that (1) this might not be a constant, and
(2) that the build depends on config.guess, and should thus
only be used when it is clear that binutils/gcc are installed.

> >Also, a variable in the main Makefile won't be initialised since the
> >script won't exist when it's first called.
>
> This doesn't seem to be a problem in practice. You should probably
> double check this in case I am misunderstanding something.

You are currently depending on the fact that the main Makefile
uses a recursive $(MAKE) call to itself.

As soon as we change this for whatever reason, running "make clean; make"
will re-introduce the subtle issues where wine confuses the cross-
detection.

In other words, you are depending on the fact that $(BUILD) is
re-evaluated before every build, which currently happens only by
accident (because of the recursive $(MAKE) call).

> >>>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.
> 
> Following Tony's suggestion, I went ahead and installed this too,
> even though we don't use it yet.

I'm fine with that, but we shouldn't put too many scripts into
<mce>/usr/bin/. :-)

> I don't mean at all to cut off discussion about this, but I thought
> it would be nice to see how well it works.

Your work is very appreciated, and I'm glad this works so well!

However, the $(BUILD) construction is brittle and hides important
dependencies. That's why I'm replacing this with a more obvious
construct that is less likely to introduce subtle bugs in the future:

http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/edbbb34baf47


Greets,
Volker

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



reply via email to

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