Re: Cross-compiling & distributing Tools

[Nicola Pero]

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


> ***************************************************************************
> 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 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.

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.

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.

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 ;-)


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


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

 


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


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

 

> 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.
 
 
> ***************************************************************************
> 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!


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

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


I hope this quick overview helps.  Of course there is a lot to do.

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

Thanks

PS: I suggest breaking down questions into smaller emails ... more likely 
that someone will answer it.

 

For Opera Telecom's latest news click here 
"Opera Telecom – Partner of Vodafone, BT, and 02 – Offices in Australia, 
Ireland, Italy, Kenya, Portugal, South Africa, Spain, Tanzania, UK and USA – 
one-stop shop solution including 3G Video, MMS, SMS, WAP, Web, IVR available 
through Opera’s world-leading Dragon self-service platform." 
This e-mail is intended for the above named only. It may contain private and 
confidential information or material that is privileged. If it has come to you 
in error you must take no action based upon it, nor must you copy or show it to 
anyone. Please return the message immediately to postmaster The validity of any 
pricing information contained herein is 30 days unless otherwise stated. E &OE. 
Standard terms and conditions apply