Re: Release Aug 28

[Fred Kiefer]

Nicola Pero wrote:

> > You suggest to build make by specifing:
> >
> > ./configure --build=ix86-linux --host=ix86-linux --target=arm-linux 
> > --disable-flattened
> >
> > This results in the ix86 executables to be installed in the directory 
> > System/Makefiles/arm/linux-gnu/. Not sure if this is the intended 
> > behaviour, but this surely removes the need to change common.make. Here 
> > I wanted to change the path for which_lib from HOST to BUILD, otherwise 
> > an unusable executable would be found. But now with an ix86 executable 
> > in the ARM directory things work.
>
>
> Thanks - your explanation is quite good here - in fact having now looked
> at the code, I think it's quite easy to see what is happening:
>
> In GNUstep.sh.in, we have - 
>
>  address@hidden@
>  address@hidden@
>  address@hidden@
>  address@hidden@
>
> which is setting GNUSTEP_HOST to the argument of the --target configure
> flag of gnustep-make.
>
> I think we agree that that is wrong (let me know if not, so we discuss
> that issue first).
>
> Because of this wrong assignment of GNUSTEP_HOST to the --target,
> GNUSTEP_HOST ends up being arm instead of being ix86 ... which doesn't
> make sense, does it ?
>
> Then of course the executable for ix86 ends up in the arm directory, which
> is non-sensical, and stuff stops working.
>
> I'd like to change it so that GNUSTEP_HOST is set to the --host flag of
> configure.  Presumably people didn't notice this bug because they were
> always using the same --host/--target ?

Yes exactly, I still think that I have been the only one doing almost 
cross compilation with GNUstep when I used MinGW on top of Cygwin. But 
here it was not that important to get things completly right, as the 
machine could run both executbales anyway.

> Anyone has an explanation of why GNUSTEP_HOST is set to the --target
> rather than the --host ?  It doens't seem to make that much sense, just
> think that if multi-platform is enabled, GNUstep.sh will set GNUSTEP_HOST
> to whatever machine it's running on (not to whatever machine it's
> compiling for, that's definitely the target set of variables).  I might 
> have introduced this confusion myself in the past, probably just 
> reproducing some existing confusion.
>
> Anyway I think that's wrong, and should be fixed.
>
> But I'm a bit conscious we might we breaking cross-compiling scripts or
> existing setups big time with this change, so while it looks like we want
> to make it then update any documentation if we might have where different
> flags in the doc, probably this should be postponed to after the release.
>
> Any comments ?

As you said it never worked with HOST!=TARGET, so I would not expect 
there is anything to break. What willbe important is to document the way 
we now expect cross compilation should be handled.

> Thanks for your time, very good comments, apologies if I sounded unfair,
> hopefully we're at least getting somewhere with this discussion, which is
> what really matters :-)

No need to thank me, I want to see this working. So I have some interest 
here, while you spend your time without reward. Lets go ahead, GNUstep 
by GNUstep.