Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Xcode 2 project template

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Xcode 2 project template
Thomas Harte
Member #33
April 2000
avatar

Well, I was extrapolating quite a bit from MACOSX_DEPLOYMENT_TARGET=10.3 in the Apple example. Adding the settings as described to the Xcode project definitely does the trick — NSAlert related code fails only if you enable the PPC target for example. So it makes me wonder what Xcode is doing underneath. I'll have to search for some sort of way to make Xcode more verbose in its build steps...

Also, I had a quick bash at making an Xcode project to build Allegro (so that you could also build from source without going near the commandline) but I didn't have a clue what I was doing. And it isn't very important anyway.

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

So it makes me wonder what Xcode is doing underneath. I'll have to search for some sort of way to make Xcode more verbose in its build steps...

It wouldn't surprise me if it is basically doing this for every file:

gcc -c $PPC_OPTIONS source.c -o source_ppc.o
gcc -c $i386_OPTIONS source.c -o source_i386.o
lipo -create source_ppc.o source_i386.o -output source.o
rm source_ppc.o source_i386.o

Quote:

Also, I had a quick bash at making an Xcode project to build Allegro (so that you could also build from source without going near the commandline) but I didn't have a clue what I was doing. And it isn't very important anyway.

I suppose you'd do something like:

http://developer.apple.com/opensource/buildingopensourceuniversal.html

I think a proper XCode project is better than the makefile, but I cannot imagine the developers agreeing to use it exclusively. And maintaining both would be a waste of effort.

~

I altered the makefile slightly to split the i386 and ppc builds into subfolders, and it works out well. The problem is there is a lot of miscellaneous stuff that would need to be worked around. Given the global makefile, I don't know how practical that is.

For instance, if you target the i386 on a PPC, it will end up building helper tools (makedoc) that it cannot run. So the helper tools would obviously have to know to always build the native version.

As it is now, I can do this:

make lib TARGET=i386
make lib TARGET=ppc

and then glue it together by hand to have a proper 10.2 PPC / 10.4 Intel library.

Thomas Harte
Member #33
April 2000
avatar

Quote:

and then glue it together by hand to have a proper 10.2 PPC / 10.4 Intel library.

Could this all be automated? I figure it's better to get something working as soon as possible than to worry about the one-off library compile time and if it's something that fits well with what the core developers already maintain that's even better. I'd like to get a binary installer (Framework + UNIX libs, since you're right that once it's in an installer the end user won't care that much) working as soon as can be, since otherwise 10.2 and 10.3 users are being denied software they could otherwise use.

Evert
Member #794
November 2000
avatar

Quote:

Also, I had a quick bash at making an Xcode project to build Allegro (so that you could also build from source without going near the commandline) but I didn't have a clue what I was doing.

I have no idea how an Xcode project works, but can't you just add the nescessary files to the project (see the makefile.lst for the list of files)?
Actually, that's probably not good enough, since some header files may be generated at compile time... but you can try it out.

Quote:

I think a proper XCode project is better than the makefile, but I cannot imagine the developers agreeing to use it exclusively.

No, but if someone is willing to make one for 4.2.1 (or 4.2.2) I certainly wouldn't object to distributing it with Allegro. I'm not maintaining it though.

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

Could this all be automated?

Not using the method I described above. It would require way too much messing around with the global makefile. Instead, I've created a wrapper shell around gcc. I'll post it once I'm done testing it.

Basically, it would work like this:

ifdef UB
CC=./misc/gccuniwrap.sh
else
CC=gcc
endif

The rest of the makefile.osx stays the same as the 4.2.1 one.

The shell script parses the input and decides if it's linking or compiling and then creates the output file in a three step process: build i386, build ppc, and combine. It's slower than the other way I described because it has to do it on every single file, but I think it's the best way.


Update:

Attached is the shell wrapper. Just place it (with +x permission) in the misc folder and add the following lines to makefile.osx around the CC:

ifdef UB
CC = misc/gcc-osx-uni.sh
else
CC = gcc
endif

You'll get a proper 10.2 PPC/10.4 Intel build by just using the standard makefile commands.


Edit: I'm also thinking that if you wanted to support 10.2, gcc-3.3 would have to be used in the wrapper.

Thomas Harte
Member #33
April 2000
avatar

Quote:

I'm also thinking that if you wanted to support 10.2, gcc-3.3 would have to be used in the wrapper.

What's the latest on this? Do you have an updated wrapper?

Matthew Leverton
Supreme Loser
January 1999
avatar

Yes, although I cannot verify that it actually builds 10.2 compatible binaries. It uses 3.3 for the PPC version, and the default compiler (which obviously needs to be 4.0) for the Intel version.

It's also modified to just assume you want to build a universal file, regardless of which -arch switches are present. I've used the wrapper to build dozens of games and libraries without any problems.

This is also the same method XCode uses. Whenever it compiles a universal build (using the template you created), it compiles and links each file twice.

 1   2 


Go to: