Re: Cross-compiling & distributing Tools

[Michael Hopkins]

On 6/6/06 17:04, "Nicola Pero" <address@hidden> wrote:

> Thanks ... I'll try to give summary answers to your questions
> 
I appreciate it.

> 
>> ***************************************************************************
>> 1) Cross-compiling without headaches - supposedly one of the main reasons
>> for gnustep-make.
>> ***************************************************************************
> 
> Cross-compiling was never really tested or used (in recent times), so I
> would expect not to work out of the box.  It might not be difficult to get
> it to work, but it requires someone to spend time working on it.
> 
What aspects of it do you think need addressing?  Is there some
documentation on the current approach and its' state of completion?

Taking, for example, one further platform - Mingw32 cross-compilation from
native linux amd64 to the Win32 platform.  I guess there are a number of
#ifdef's and type definition macros in Foundation as well as different
include files/libraries to link, but not knowing my way around the
GNUstep/gstep-make territory I wouldn't really know where to start.

For example, with my own makefile setup it's just a case of calling a
different compiler tool (which knows where all its' own standard libraries
are) and supplying paths and link options for the relevant platform-specific
libraries that I have built myself.

> What does work nicely though is writing code once, and compile it on
> different machines / architectures.
> 
> So an alternative you can have is ... develop on your Mac OS X machines
> (compiling using gnustep in apple-apple-apple mode, or gnu-gnu-nil I
> suppose).  Commit results to a CVS/SVN repository of your own.
> 
I do develop on OS X, but using X Code and their native Foundation to keep
things simple.  I am assuming (probably naively - 'hoping' is probably a
better word...) that the Foundation API is almost identical between OS X &
GNUstep.

> Have a separate Linux machine that gets the code from the same CVS/SVN
> repository.  To test the new code, get it from CVS/SVN, compile and
> install here, and test.
> 
Already do this though not formally from a CVS repository. I really should
get around to that sometime - I'm sure it's worth setting up properly as the
code base gets bigger.

> Have a separate Windows machine that gets the code from the same CVS/SVN
> repository.  Get the new code, compile and install here, and test.
> 
No Windows machines available with GNUstep/msys etc but not impossible to
set it up.

> This requires you to have 3 machines (Mac OS X, Linux, and Windows), but I
> expect you want to test your software on all the three systems anyway ;-)
> 
I just like the idea of doing it all from my server and applying the
original cross-compilation idea because it is so elegant!  Avoiding Windows
altogether is also a nice idea.  The only reason I am targeting Win32 is for
my clients.

> 
>> Target=amd64 ->
>>  CC = /usr/bin/gcc
>>  CFLAGS = -march=athlon64 -mtune=athlon64 -m64 ...
>> 
>> Target=linux32 ->
>>  CC = /usr/bin/gcc
>>  CFLAGS = -march=pentium4 -mtune=pentium4 -m32 ...
>> 
>> Target=win32 ->
>>  CC = /usr/bin/i586-mingw32msvc-gcc
>>  CFLAGS = -march=pentium4 -mtune=pentium4  ...
> 
> If you need to set special CFLAGS for different cpus (for math
> optimizations), you may write your own makefile fragment and include it
> everywhere.
> 
> I'll use 'michael' as your project name to make an example
> 
> The makefile fragment could do something like
> 
> ifeq ($(MICHAEL_TARGET), amd64)
>   ADDITIONAL_CFLAGS += -march=athlon64 -mtune=athlon64 -m64
> else 
>   ifeq ($(MICHAEL_TARGET), linux32)
>     ADDITIONAL_CFLAGS += <linux 32 flags>
>   else
>     ifeq ($(MICHAEL_TARGET), win32)
>       ADDITIONAL_CFLAGS += <win32 flags>
>     endif
>   endif
> endif
> 
> put that into michael.make at the top-level of your directory, and include
> it in all makefiles as in
> 
> include $(GNUSTEP_MAKEFILES)/common.make
> 
> TOOL_NAME = ...
> bla bla bla
> 
> include ../../../../michael.make
> include $(GNUSTEP_MAKEFILES)/tool.make
>   
> Then you compile on different machines using
> 
> make MICHAEL_TARGET=amd64
> 
> if you omit MICHAEL_TARGET you get the unoptimized version.  If you
> include a valid MICHAEL_TARGET your flags get used.
> 
OK - that all seems very straightforward.  Could probably be automated with
the different target platform in cross-compilation mode too I suspect.
 
>  
>> Along with other supporting library & include makefiles this works well and
>> finds requirements/installs products correctly.
>> 
>> Now - how to do this with GNUstep make?
> 
> The library/compiler/headers/etc. should be dealt with by gnustep-make.
> 
> Cross-compilation won't work though so you have to use different machines
> as explained above.
> 
I would be happy to try and help make it work if someone could explain the
issues/provide some documentation etc and it wasn't a huge task.

> 
>> OK, so this describes how to configure and build gnustep-make for multiple
>> targets.  Two questions arise from this:
>> 
>> 1) Is there a standard way of specifying targets?  When I tried it on our
>> server the config files variously talked about x86_64-pc-linux-gnu,
>> x86_64-linux-gnu, x86_64-unknown-linux-gnu...
>> 
>> [...]
>> 
>> This process appears to set up relevant directories within
>> /usr/lib/GNUstep/
> 
> As I said above, I doubt cross-compiling will work out of the box.  I'm
> almost certain it won't.
> 
OK - but the directories are setup so there is obviously some strategy in
place or planned?

> 
>> 2) Does 'multi-target' actually work reliably & transparently in practice or
>> is it an aspiration?  It is certainly an excellent idea.  Also, what is the
>> correct syntax?
>> 
>>  make static=yes shared=no --target=x86_64-linux-gnu
> 
> ... but multi-target should probably work well. :-)
> 
> ... used to be actively enabled for everyone until a few years ago.
> 
You may need to explain exactly what you mean by multi-target.
  
> 
>> If it's not yet production quality then maybe it would be feasible to
>> adapt the pmake scripts that we use at the moment to take over the work
>> of gnustep-make.  I am assuming that it would just need some header and
>> library paths and include/link directives - maybe also some macro
>> definitions.  Are these requirements documented anywhere?
> 
> Not really, but you can see what gnustep-make does by doing
> 
> make messages=yes
> 
> copy the flags and here you go.
>  
>  
OK - maybe that is another option then.


>> ***************************************************************************
>> 2) Distributing tools without headaches - packaging everything as
>> statically-linked applications without the need for GNUstep directory
>> structure/shared libs/GNUstep.sh
>> ***************************************************************************
>> 
>> 1) Building libraries and tools with static linkage.
>> This is meant to be as easy as:
>> 
>>  make static=yes shared=no
>> 
>> But when we have tried that it doesn't always seem to work.
> 
> Yup.  This needs testing / might need more work.  Used to work some years
> ago, not sure if it still does!
> 
> 
I am starting to see a pattern here I think..   :o)

How actively is GNUstep developed at the moment?


>> 2) Avoiding the GNUstep directory structure and the loading of shared
>> libs/resources.
> 
> There is no fundamental problem in avoiding the GNUstep directory
> structure, but the transition hasn't been completed yet, so there might
> not be ready-to-use flags, you might have to tweak things around manually.
> 
> If you're willing to write your own makefile code, you can probably do it
> - just take gnustep-base resources, put them into a directory, static link
> everything into your tool, bundle things around manually and you should be
> able to create a tool + resource dir that you can ship standalone.
>  
Can someone point me to a list of the resources that I would need to make
this work on e.g. Win32?

Also, it would be very helpful to know which of the Foundation objects work
100% on Win32 and which need work.  Thinking about it, knowing which of them
work 100% on native linux amd64 would be great too!

> 
>> 3) The need for GNUstep runtime e.g. gdomap, gdnc, Obj-C runtime?
>> 
>> I am not sure what is required here and whether it is started automatically.
>> For instance, which NS* objects require gdomap or gdnc?  Do they start them
>> if they aren't running already?  Is the Objective-C runtime compiled into
>> the Tool automatically or does it depend on linkage options?  There may be
>> other issues of which we are not aware.
> 
> Ideally, with static=yes, libobjc would be linked into the tool.  I
> believe gdomap and gdnc should not be started if not needed.
> 
OK good - sounds like 3 less things to worry about.

> I hope this quick overview helps.  Of course there is a lot to do.
> 
Yes it has.

> I'm sorry I can't help you in detail with all the steps, but if you
> work/use this, you may want to feed something back when you attack each of
> the problems ... eg, if you investigate/fix static=yes, it would be
> fantastic if you could feed us back the fixes :-)
> 
I'm very happy to help if it means I could code in Objective-C on OS X and
then re-compile on linux amd64 natively (for running fast) and with mingw32
(for clients who are stuck with Windoze) with zero or very few issues - and
then package tools simply i.e. one directory that contains the necessary
libaries/resources/files along with my tools.

I would certainly need more guidance and some documentation to be effective
though.

> Thanks
> 
> PS: I suggest breaking down questions into smaller emails ... more likely
> that someone will answer it.
> 
OK will do that next time.

Thanks a lot for your time.

Michael