gnustep-dev
[Top][All Lists]
Advanced

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

Re: Release Aug 28


From: Nicola Pero
Subject: Re: Release Aug 28
Date: Wed, 25 Aug 2004 00:37:10 +0100 (BST)

> I tried to explain in my last mail, why I think the names GNUstep is
> using for the build and runtime environment are inconsistent with the
> ones used by autoconf and that at least for the build process we need to
> stick with the autoconf ones. You seem to disagree on this and I would
> at least like to understand your point. Searching for which_lib based on
> the machine type we are building on is something that looks rather
> natural to me.

When you run ./configure on gnustep-make, you have:

 * a build machine.  This is the machine where you build gnustep-make.  
For example, the machine on which you compile which_lib.c.

 * a host machine.  This is the machine where you run gnustep-make.  For
example, the machine on which you run which_lib.

 * a target machine.  This is the machine for which gnustep-make will be
generating exectuables.  For example, the gnustep-make system (including
which_lib) will be working to generate executables that run on that
machine.

The GNUSTEP_BUILD_* (this is a hypothetical set of variables, as they
don't exist), GNUSTEP_HOST_*, GNUSTEP_TARGET_* variables by definition are
set to those.  We control them, we decide what they mean, and they are
*defined* to be those (this decision was taken many years ago, we've just
inherited a whole system built with that convention).

>From this it does follow that which_lib should be run on GNUSTEP_HOST_XXX.  
I can't see how you can possibly disagree.  In fact, I can't see how your
patch which looks for which_lib in a directory keyed on GNUSTEP_BUILD_CPU
could possibly work, given that GNUSTEP_BUILD_CPU doesn't exist as
variable and is not defined anywhere.

But I understand what you are saying that the current gnustep is broken
with respect to cross-compilation, and that it just doesn't work.  So it
needs fixing.

I've explained how the GNUSTEP_HOST_* and GNUSTEP_TARGET_* variables are 
defined.  Maybe the confusion is about the relationship between the 
./configure --host / --built switches of packages different from 
gnustep-make and those GNUSTEP_HOST/GNUSTEP_TARGET variables, so let me go 
over it.

Now the way this mapping could work is not necessarily unique (we defined
the GNUSTEP_* variables ourselves).  We have a well defined convention; I
suspect you've got another different (equivalent)  convention in mind; let
me explain what I mean by that.

I explained what the current definition of the GNUSTEP_* variables is.

Now if you have gnustep-make installed on your system, and you are now
configuring gnustep-base on top of that, the relationship between the
gnustep-base's ./configure switches and the GNUSTEP_* variables is tricky.

The --build option of gnustep-base specifies the machine on which you
build gnustep-base.  That is the machine on which you run gnustep-make,
which means gnustep-base's --build option should map to GNUSTEP_HOST_*.  
The --host option of gnustep-base specifies the machine on which you run
gnustep-base; that's the machine which gnustep-make is targetting as
result of compilation/building, meaning gnustep-base's --host option
should map to GNUSTEP_TARGET_*.  The --target option of gnustep-base is
irrelevant because gnustep-base is not a cross-compiler; if it was a
cross-compiler, then you would need to have something in your
package/source code which is changed by that option, but it doesn't affect
the way gnustep-make works and builds packages, which is why it doesn't
have a corresponding GNUSTEP_* variable.

Now I understand that you are instead expecting --build to map to
GNUSTEP_BUILD_*, which is probably why you think this convention is wrong;  
in fact this different mapping wouldn't change that much because if you
were doing that mapping for gnustep-base, you would be breaking the same
mapping for gnustep-make :-)  If we'd change the convention so that
gnustep-base's --build switch maps to GNUSTEP_BUILD_*; that would maybe
"fix" gnustep-base ./configure/GNUSTEP_* mappings, but would then break
gnustep-make's one, because then gnustep-make's --build switch would map
to ... nothing, while gnustep-make's --host switch would map to
GNUSTEP_BUILD_* ... which would be confusing in another sense.

You either have gnustep-make's ./configure --host flag map to
GNUSTEP_HOST_* or you have gnustep-base's ./configure --host flag map to
GNUSTEP_HOST_*, but you can't have them both work that way at the same
time (because gnustep-make's ./configure --host flag is necessarily going
to be the same as gnustep-base's ./configure --build flag!), if you are
going to have one weird/unexpected mapping anyway, we better keep the
convention that we have else we'd be breaking a few kilolines of
GNUmakefiles around the globe without gaining that much.

In other words, I appreciate why you are confused :-) but I'd recommend 
sticking to the convention we have else we'd be breaking zillions of 
makefiles without gaining that much.

The convention we have is that GNUSTEP_BUILD_*, GNUSTEP_HOST_*,
GNUSTEP_TARGET_* refer to the build/host/target from the point of view of
gnustep-make.  That is, the machine on which you build gnustep-make is the
GNUSTEP_BUILD_*, the machine on which you run gnustep-make is the
GNUSTEP_HOST_*, the machine for which you are compiling is the
GNUSTEP_TARGET_*.

When you are building any package on top of gnustep-make, you need to map
the ./configure flags so that --build is mapped onto GNUSTEP_HOST_*,
--host is mapped onto GNUSTEP_TARGET_*, and --target is only used if
you're building a cross-compiler or a cross-building system, in which case
it is mapped onto ... whatever variables/flags/configs your own code is 
using to know for which machine it is generating output.

Hopefully that's not too confusing if we make sure it's all very well 
documented and all ./configure scripts are fixed/updated to work in this 
way.

At least I hope that's the problem you're having. :-)

But if you are expecting which_lib to be in a GNUSTEP_BUILD_* directory,
that might be because you're misinterpreting the --build flag somewhere.

Keep in mind that you can't use the same set of --build --host --target
flags for gnustep-make and gnustep-base.  That makes no sense.  As
explained before, the --host used for gnustep-make should be the --build
for gnustep-base, and the --target used for gnustep-make should be the
--host for gnustep-base.  The --target of gnustep-base instead doesn't
count, and the --build of gnustep-make is fixed on the machine where you
start the whole process.  Actually, the ./configure script for 
gnustep-base could automatically pick up the --build to be GNUSTEP_HOST_* 
if set, and the --host to be GNUSTEP_TARGET_* if set.


> In the last few days I looked at the crosscompile instructions of 
> various software packages. Most of them used --host=XXX-YY to specify 
> the computer, where the application will later be run on.

That's exactly what you should do, I certainly agree.

But --host=XX-YY should internally map to GNUSTEP_HOST_* when you
./configure gnustep-make, and to GNUSTEP_TARGET_* when you ./configure
another package (such as gnustep-base) built on top of gnustep-make.

That's how the GNUSTEP_* variables are defined.  Someone before us defined
them and established the convention, which is used consistently everywhere
in gnustep-make and in external makefiles out of our control, so we'll
have to keep it.  What we can do is to document it properly, state it as a
rule to go from autoconf ./configure flags to GNUSTEP_* variables, etc
etc.

Thanks for looking into this, I'd like to get a cross-compiler system at
some point and then I could help with the details, anyway my main worry at
this stage was just explaining the philosophy of gnustep-make and what the
GNUSTEP_* variables are for.

I hope you at least get my point now, sorry if I was obscure before.

Tanks





reply via email to

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