RE: gnustep-base: cross compiler help

[Nicola Pero]

> I have configured and installed gnustep-make with mingw32 support.
>
> Using:
> ../gnustep-base-1.15.2/configure 
> --with-default-config=/usr/GNUstep/Local/Configuration/GNUstep.conf 
> --host=i586-mingw32

Your configure arguments look consistent with the GNU terminology, but 
gnustep-base's
configure doesn't seem to work that way ... the --host parameter is ignored, and
only the --target parameter is parsed/used.

So at the moment you probably need to use

../gnustep-base-1.15.2/configure --target=i586-mingw32

According to standard autoconf/GNU practice, that's wrong; --target is only used
for compilers or software that is used to build other software; for "normal" 
software
such as gnustep-base only --build and --host are relevant.

The reason we historically use --target is probably to make it consistent with 
'make 
target=i586-mingw32' and similar that is currently required to cross-compile 
software 
when using gnustep-make.  But that is again not what standard autoconf/GNU 
practice
would suggest; it would seem more natural to use 'make host=i586-mingw32' if you
are specifying that you want to cross-compile software that needs to run on
i586-mingw32! ;-)

And then, we use 'make target=i586-mingw32' because that is consistent with the
terminology used internally in gnustep-make and in gnustep-make's configure - 
gnustep-make *is* special because it's a software used to build other software, 
so
to configure a cross-compiling gnustep-make you would use ./configure 
--target=i586-mingw32.  It's easy to understand that that is required, since
./configure --host=i586-mingw32 means another thing (it means building a 
gnustep-make
that runs on i586-mingw and compiles for i586-mingw32, which is not a 
cross-compiler).
So the --target=xxx is important in gnustep-make (actually, essential, since it
controls cross-compilation) so we store/propagate that variable everywhere - but
unfortunately, historically, we do that using the same name ('target') which is 
why 
it then becomes natural to use 'target' as in 'make target=i586-mingw32' etc.

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. :-)

'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. :-(

'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. :-/

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. 
:-)

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