We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 209 - Xcode project issues
Summary: Xcode project issues
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: build (show other bugs)
Version: HG 1.2
Hardware: PowerPC Mac OS X (All)
: P2 blocker
Assignee: Eric wing
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-01 05:18 UTC by Christian Walther
Modified: 2006-05-09 21:45 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Walther 2006-05-01 05:18:07 UTC 
The SDL Xcode project from revision 2302 needs the following tweaks to work properly:

- include/SDL_config.h is missing. I solved that by doing 'ln -s SDL_config.h.default SDL_config.h'. This should probably be done in a shell script build phase in Xcode, something like this:

------
# Make sure that include/SDL_config.h is a symlink to SDL_config.h.default.
# If it exists and is not a symlink, it was probably generated by configure and we move it aside.
if [ ! -L ../../include/SDL_config.h ]; then
	if [ -e ../../include/SDL_config.h ]; then
		mv ../../include/SDL_config.h ../../include/SDL_config.h.generated
	fi
	ln -s SDL_config.h.default ../../include/SDL_config.h
fi
------

Note that Xcode resolves symlinks when copying the headers into the built framework, so what ends up in the framework is actually a copy of SDL_config.h.default, not a symlink to a non-existing file.

- src/loadso/macosx/SDL_sysloadso.c needs to be added to the Xcode project. Depending on the configuration defines in SDL_config_macosx.h, it is used on PPC (for 10.2 compatibility), on i386 src/loadso/dlopen/SDL_sysloadso.c is used. However, having both files leads to weird errors: even though only the contents of one of them get compiled, the linker complains about duplicate symbols. It seems that Xcode tries to compile both source files into the same object file (interestingly, it adds some suffix to the file name that looks like it was meant for disambiguation, but it is the same suffix in both cases), which somehow messes it up (I'd expect the second just to overwrite the first, but apparently not...). Everything works when I rename one of the SDL_sysloadso.c files, but that's probably not an option. I'm not sure what to do about this - any ideas? Only include src/loadso/macosx/SDL_sysloadso.c in the project and have it #include src/loadso/dlopen/SDL_sysloadso.c if SDL_LOADSO_DLOPEN is set, maybe?

- The "Framework without X11 Stuff" target looks for its Info.plist at an absolute path on Eric's HD. The "Info.plist File" build setting needs to be set to "Info-Framework copy.plist". Or, better, give that file a more descriptive name, like "Info-Framework-NoX11.plist". Or, even better, use the same "Info-Framework.plist" that is used for the normal framework and remove Info-Framework copy.plist - the two files are identical.

- In that Info.plist, the version number should be updated to 1.2.10.

- I noticed that the Development configuration also builds for both architectures, is this intentional? Usually, the Architectures setting is set to $(NATIVE_ARCH) in Development configurations.

- By the way, should the Xcode stuff still be kept in a tarball now that we're on Subversion, or should we move it directly into the repository? (I don't really care, I can think of reasons for either.)
Comment 1 Eric wing 2006-05-09 21:45:06 UTC 
- Okay, added a new shell script phase for the suggested script.

- Yeah, Xcode currently has no ability to pick and choose files for different arch's within the same target. This bit us for the asm stuff too early on. Apple's official coined response seems to be to use #defines to control this somewhat as you suggested. I looked into this specific issue about including both files and saw additional weird things. (Sometimes both versions would be built for one architecture causing multiple defines, other times neither version built causing undefined symbols. I filed a formal bug report with Apple (4542369). In the meantime, the quick fix is to do what you suggested and in the
macosx/SDL_sysloadso.c, do:
#ifdef SDL_LOADSO_DLOPEN
#include "../dlopen/SDL_sysloadso.c"
#else
//#ifdef SDL_LOADSO_DLCOMPAT

- Okay. The path name has been fighting me. I'm not sure why. I clear it to just a file name and at some point it reverts to an absolute path. I think its fixed now, but you should double check. Renaming from Info-Framework.plist is good. I was being lazy. I'm hesitant to reuse the info-plist. I've gotten into trouble with that before. I started modifying one and forgot it was shared by several dozen other things. So I renamed it to Info-FrameworkNoX11.plist.

- I bumped up the version number to 1.2.10. From past experience, I thought this would cause programs built against older SDL versions to abort when run against the new framework, but I must be misremembering as it seems to work okay.

- Building a Universal Binary in the Debug version is somewhat arbitrary on my part. The thing is that I was trying to get somebody to test on Intel for me so it was easier to build and send the Universal version to the other person. Furthermore, as we've already seen once on the mailing list, there will be people who build a framework on one architecture and will be confused when it doesn't build or run on the other. I think this will preempt the question entirely. You're right that generally, the debug version is set to $(NATIVE_ARCH), but I think that is mainly because of the compile time and the file size. SDL is fairly small and quick to build so I don't think building it as a UB for development is much of a problem. (For OpenSceneGraph which eats up over a gigabyte of disk in the debug form and takes many hours to build, I leave the debug stuff set to $(NATIVE_ARCH).)

- I can see it either way. I'm pretty indifferent to this. I would say be consistent though. What ever you do for the other projects (Visual Studio, KDevelop, etc), you probably should do the same thing with Xcode.

FYI, there are some warnings caused by the semi-recent modifications to SDLMain.m. I recommend these be cleaned up.