Re: Once more cross compilation

[Nicola Pero]

> > Btw, if you are using HOST=arm, then why not using BUILD=arm as well?
> >
> > To use gnustep-make on arm (which is what HOST=arm means), you need a
> > plethora of tools, including make, shells, compilers. linkers.  At which
> > point you might as well build it directly on arm (BUILD=arm), since those
> > tools are exactly what you need to build it.
> 
> That's the point of crosscompilation. You use a system (e.g. desktop with
> x86) for development to compile code for another architecture which lacks
> a convenient way to do development on (like an embedded system or a
> handheld with ARM, or Windows for that matter if you happen to prefer
> using Unix :-). Of course you need the whole toolchain compiled with the
> appropriate TARGET or --target for this.

Yes, -- good point -- what I really wanted to say is just that I think the
Zaurus is running a full Linux o/s and I was thinking maybe you can
telnet/ssh into it from the desktop and work from there ... if that is
possible, it would be quite a nice/simple way of doing things.

 
> > If you are cross compiling with BUILD, HOST and TARGET, you would build
> > gnustep-make on BUILD, configured to run on HOST (which might or might not
> > be the same as BUILD), configured to compile stuff for TARGET (which might
> > or might not be the same as HOST).
> >
> > Then, the libobjc flags should be the ones required by the compiler on
> > HOST to produce ObjC stuff for TARGET.  The which_lib.c executables should
> > be compiled to run on HOST (which might be different from the local BUILD
> > system).  All look ups in makefiles etc looking for scripts or tools used
> > to build should be done so that they run on HOST, because you are supposed
> > to run gnustep-make on HOST.
> >
> > BUILD is only used while doing a ./configure or make/make install of
> > gnustep-make itself, and never again; when you run gnustep-make, that will
> > happen on HOST (by definition of BUILD and HOST) -- after you have
> > manually (presumably) copied the gnustep-make installation from BUILD onto
> > HOST.
> 
> What if I compile gnustep-make with HOST=x86, TARGET=arm and try to
> crosscompile another package with it. Then I should compile the other
> package with HOST=arm. Does this conflict with the usage of this variable
> in gnustep-make?

(this question is about compiling a crosscompiler using a crosscompiling
gnustep-make)

No, you shouldn't have a conflict, well, assuming the package is
reasonably intelligent to use non-conflicting variable names and to be
aware of gnustep-make's own variable names. :-)

gnustep-make uses variable names like GNUSTEP_HOST_CPU,
GNUSTEP_TARGET_CPU.  If you are using gnustep-make to compile a compiler
package for language XX which has his own HOST/TARGET (different from
gnustep-make's ones), you presumably configure the HOST/TARGET when you
configure your compiler package; of course you need your compiler package 
to use different build/host/target variable names.

By the way, there would be a relationship between your compiler's
variables and gnustep-make's ones ... Your compiler's build platform will
be GNUSTEP_HOST_* (that is because the system where you run gnustep-make
is the system where you build your compiler), your compiler's host
platform will be GNUSTEP_TARGET_* (that is because the system where you
run the compiler is the system where you run applications created with
gnustep-make), and your compiler's target platform ... well you have to
configure that into the compiler - this has nothing to do with
gnustep-make.

Thanks for your comments