Re: gnustep-base: cross compiler help

[Dennis Leeuw]

Even with --target=i586-mingw32 it stops at exactly the same point.
While building gnustep-objc-1.6.0 works perfectly with:
make target=i586-mingw32

So I suspect it is something in configure. The config.log reports:
configure:16547: result: none
configure:16572: error: Incomplete support for ffi functionality.

Even installing ffcall within the GNUstep directory layout ends with
same story. So something is wrong somewhere... but I can't figure out 
what. Pointers where to look, even the obvious, because I am surely 
overlooking something?

And completely agree with the proposed changes of the variables and the 
use of host=

Thanks (again) ;),

Dennis

Nicola Pero wrote:

> To bring everything in line with the standard GNU/autoconf
> terminology, we probably need to rename a lot of variables inside
> gnustep-make, and then rename all options. :-(
>
> So, to explain, the right thing to do would be:
>
> core/make/configure --build=xxx host=yyy target=zzz


> 'xxx' is only used while building gnustep-make, and it would then be
> thrown away.  Currently, it is in fact thrown away. :-)

This sounds reasonable.

> 'yyy' is the machine that gnustep-make will run on.  This would be
> stored in 'GNUSTEP_BUILD' runtime/shell/makefile variables; because
> when gnustep-make is used to compile, it would be the 'build' machine
> on which the compilation is running.  Currently this is instead
> stored in the 'GNUSTEP_HOST' variables, which is confusing. :-(

Couldn't agree more

> 'zzz' is the machine that executables created by gnustep-make will
> run on.  This would be stored in 'GNUSTEP_HOST'
> runtime/shell/makefile variables; because when gnustep-make is used
> to compile, it would be the 'host' machine on which the compiled
> programs will be running.  Currently this is instead stored in the
> 'GNUSTEP_TARGET' variables, which is confusing. :-/

Yep!

> And then, it would become natural to use 'host=xxx' everywhere, in
> configure and make arguments, to turn on cross-compilation when using
> gnustep-make as a compilation tool.  This is exactly what the
> GNU/autoconf standard interpretation requires. :-)

Yippie, this sounds logical to me!

> To keep things backwards compatible, we could try to detect 'make
> target=xxx', print a warning, and execute it as if 'make host=xxx'
> had been specified; the same for './configure --target=xxx' which
> would temporarily emit a warning and be converted into './configure
> --host=xxx'. :-)
>
> Also, we could set GNUSTEP_TARGET_xxx and other variables to be the
> same as GNUSTEP_HOST_xxx so that old GNUmakefiles will keep working.
> :-)
>
> Comments welcome ;-)
>
> Thanks