[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cross-compiling & distributing Tools

From: Michael Hopkins
Subject: Re: Cross-compiling & distributing Tools
Date: Sat, 10 Jun 2006 01:17:08 +0100
User-agent: Microsoft-Entourage/

On 6/6/06 17:04, in article
address@hidden, "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 &

> 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

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



        _/    _/   _/_/_/             Hopkins Research Ltd
       _/    _/   _/    _/
      _/_/_/_/   _/_/_/          http://www.hopkins-research.com/
     _/    _/   _/   _/
    _/    _/   _/     _/               'touch the future'

reply via email to

[Prev in Thread] Current Thread [Next in Thread]