On 6/6/06 17:04, "Nicola Pero" <[EMAIL PROTECTED]> 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 _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
