[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:13:58 +0100 |
User-agent: |
Microsoft-Entourage/11.2.3.060209 |
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