xcode project patches

[demonburrito]

Apologies if this is already documented somewhere and I just missed it.

I would like to know what the procedure is for submitting patches for the xcode project. The patches would mostly be for the "custom scripts", which are otherwise ordinary sh scripts, except that they are named by xcode with some kind of hash and organized in an xml file. I see lots of "the xcode project will need to be updated" notes in the svn history, so I'm wondering what the policy is.

Backstory: I've always had to hack on the scripts to get it to build on my mostly normal mac. I'm guessing that the problems are unnoticed because the maintainers rarely build it from scratch, or are using a different sh.

The fixes are very simple if you'd rather I just explain it, though; just a couple of rules of thumb to make the shell scripts more portable, and a change to make sure svn 1.4+ is in the path before trying to get queso.

[cybersphinx]

I would like to know what the procedure is for submitting patches for the xcode project.

Like any other patch, put them in a ticket. I don't know how readable that XML is (or patches for it), an extra explanation will probably help.

[demonburrito]

Readable XML?

Thanks for the quick reply. Xcode is such a pain... Hopefully the patches will ease some of that for you guys.

[cybersphinx]

Urgh. If I've understood that correctly, project.pbxproj is the file containing those scripts (and it's... whatever, but not XML) in one single line. I guess an explanation what exactly was changed in the scripts will be very welcome.

[demonburrito]

Oops, I was wrong... I was thinking of the plists, I guess.

But yeah, very diff unfriendly.

[Zarel]

That's strange. I'm currently building on XCode 3.2 with no changes whatsoever. There was one change needed to get it compatible with Snow Leopard, but I already committed that change...

[demonburrito]

It could be that I'm totally wrong about this, but there are a couple of things that I always have to fix. This is on a Leopard (10.5. box, xcode 3.1.2.

The first is to change all of the

Code: Select all

if [ -e $VAR ]

to

Code: Select all

if [ -e "$VAR"]

The second is to change the

Code: Select all

$*

to

Code: Select all

"$@"

(quoted)

The third is (was) to make sure that a more recent svn than 1.3 (which the mac came with) is in the path.

The last is to kill the "Copy Game Data" script on the warzone target, and move it manually... This is also a shell expansion syntax issue, but I didn't debug it (too lazy, but would for the patch).

I've been hacking on Warzone since around ~2.1, and I have never had an uneventful build. Unless I'm totally wrong, the first two changes are good practice anyway for portable scripts.

[cybersphinx]

Yes, the first two changes look ok (maybe the effect is only noticeable when the source path has spaces or something like that), the third also sounds like a good idea. Those all look like things that are no problem if the system is already set up correctly.

[demonburrito]

You are correct about paths with spaces.

The third one in particular is a giant pain in the ass if you don't know what happened... The script creates the queso directory, then svn echoes an unhelpful error message, then the second time around (even after a clean) the script just checks for the existence of the directory, which is empty. Hilarity ensues.

Those all look like things that are no problem if the system is already set up correctly.

Not sure what you mean by system and set up correctly, but...

If you take a look at this sticky viewtopic.php?f=6&t=2969, Zarel describes the mac build process as having "too many unspeakable horrors for me to undergo more than once in a long while", and that things go okay as long as something doesn't go wrong, and if it something goes wrong you're "on your own". Imho, it's little things like this that make it a painful experience, and they're all very easy fixes.

[Zarel]

Ah, yes, that explains a lot. I usually don't put spaces in my directories, so I didn't come across that issue. I'll commit those when I can.

[Zarel]

If you take a look at this sticky viewtopic.php?f=6&t=2969, Zarel describes the mac build process as having "too many unspeakable horrors for me to undergo more than once in a long while", and that things go okay as long as something doesn't go wrong, and if it something goes wrong you're "on your own". Imho, it's little things like this that make it a painful experience, and they're all very easy fixes.

Hey, hey, I describe a lot of perfectly reasonable things as "eldritch horrors". Right now, the Xcode project works beautifully. It may be difficult to maintain, but for the purposes of compiling, I don't have to do any hacking at all; just use xcodebuild or double-click on the project file and hit the Build button.

The first is to change all of the if [ -e $VAR ] to if [ -e "$VAR"]

The second is to change the $* to "$@" (quoted)

Done.

The third is (was) to make sure that a more recent svn than 1.3 (which the mac came with) is in the path.

??? I don't know what this is asking. dak180, do you have any idea?

The last is to kill the "Copy Game Data" script on the warzone target, and move it manually... This is also a shell expansion syntax issue, but I didn't debug it (too lazy, but would for the patch).

It works fine for me... I'm not removing it. dak180, if you can rewrite it, that'd be great, but if you can't improve it, don't touch it.