Sharing Engine Code with Mac

#1 I don't know the answers to your questions, but I simply kept track of my source modifications when I made them, and copied and pasted into the appropriate files when I went to the other platform.

However, my guess is that all the platform-specific stuff is in the groups such as "platformMacCarb" and so other stuff, like in the t2d folder, should be platform-independent, so it probably would work to just copy those entire files from platform to platform. One way to find out...

#2 I would recommend using subversion to track any changes that you make to the source between *any* machine. Any time you make a change to the C++ code, you run the risk of incompatibility. You will also need to make sure to update both projects for Visual Studio and XCode as you add in resources (of course).

#3 Working without some form of source control is a disaster waiting to happen. Find something that works for you, and stick with it.

Personally, I use a CVS respository on a Linux fileserver w/ a small RAID array. The CVS tree (formerly) mirrored and duplicated the tags in the GG CVS repository back when that was available to customers. The mechanics of merges and updates within and between platforms has never been a problem for me, and I edit/compile/run on Linux*, OSX, and Win32 platforms.

*I started ignoring TGB a few releases ago when it no longer compiled on Linux.

#4 Hey guys thanks for the responses. I agree that no serious development should be without source control and I use Subversion. What I am interested in is how you guys setup your file structure and projects so that source files are shared across platforms.

Here is an example of what I want to be able to do:
-On my windows machine, I modify a file, say t2dSceneObject.h
-I check this file into the repository
-On my Mac, update to the latest version from the repository
-Open up Xcode and recompile with the new change.
-Open up the TGB Editor and package either the Windows or Mac Version of my game

I want to try to avoid having to open up t2dSceneObject.h in the Mac project and re apply the changes by hand. Ideally, the Mac project would live in the same directory tree as the windows one which would allow the executable to be output to the default location. Then the TGB Editor would be able to build both Windows and Mac projects from a unified location.

I'm trying to keep the number steps required to build and package the Mac version to as little as possible.

#5

Quote: Personally, I use a CVS respository on a Linux fileserver w/ a small RAID array. The CVS tree (formerly) mirrored and duplicated the tags in the GG CVS repository back when that was available to customers. The mechanics of merges and updates within and between platforms has never been a problem for me, and I edit/compile/run on Linux*, OSX, and Win32 platforms.

]

CVS needs to die already. Subversion is a drop-in replacement for CVS but without the catastrophic levels of suck.

Quote:-On my windows machine, I modify a file, say t2dSceneObject.h
-I check this file into the repository
-On my Mac, update to the latest version from the repository
-Open up Xcode and recompile with the new change.
-Open up the TGB Editor and package either the Windows or Mac Version of my game

Uhhuh? This works exactly as described. Are you running into a specific problem?

Gary (-;

#6 Big LOL re:

Quote:...without the catastrophic levels of suck.

... send your intern over and maybe I'll let them upgrade my fileserver. Maybe. :^)

Quote:Open up Xcode and recompile with the new change.

... and if you enable CVS/SVN in Xcode, you can check the status of and update your local files directly from Xcode. It's Nice.

#7 Thanks for the help guys. Judging from your responses it felt like I was missing something obvious and so I went and did some digging. In the end my problem was related to the mac Aliases(shortcuts) not coming across properly after checking them into the repository from the windows build and then grabbing on the mac. The two directories I was having problems with were:

engine/lib/openal/macosx
engine/lib/xiph/macosx

I was able to get these working by copying over the directories from the mac specific install.

Working on the mac has thus far not been productive and fun at all. I am still trying to determine if this is because there is a lack of support and resources or if it's because of my relative inexperience with the mac.

I am still having several issues including:
-How to set which "game" to use when debugging with TGBGame Debug(I suck at Xcode)
-Easy script editing(Torsion please!)
-Script debugging(See above)
-Subversion issues related to hidden .svn folders in the app executable and versioning the executable(I miss TortoiseSVN)

If someone thinks they might be able to help me with these, let me know and I'll give more details.

#8

Quote:-How to set which "game" to use when debugging with TGBGame Debug(I suck at Xcode)

Open the executables group and right click on the executable to which you want to pass stuff, and add stuff in the "arguments" tab

Quote:-Easy script editing(Torsion please!)
-Script debugging(See above)

Or use XCode. There's a torquescript parser thingy in the torque source, IIRC you can install it just by double clicking. Regarding debugging, dunno.

Quote:-Subversion issues related to hidden .svn folders in the app executable and versioning the executable(I miss TortoiseSVN)

Don't put build products into source control. Ever.
For your final product, create a new target that includes the executable from one of the other targets, and add a command-line command to the target that does something like

find your-output-directory -type d -name \.svn -exec rm -rf {} \;

Alternatively you could write a script that does an svn export [instead of checkout] into a fresh directory then builds the product from scratch. You might see that called an "automated build", and it'll make life a lot easier if you get it working.

Gary (-;

#9

Quote:Open the executables group and right click on the executable to which you want to pass stuff, and add stuff in the "arguments" tab

With the default install of TGB on the mac, I right click the executable and Get Info. In the arguments tab, I tried different variations of the following line:
/Applications/TorqueGameBuilder/games/BehaviorPlayground
Unfortunately no success. I know this project works ok as when I put the app in that directory, it runs fine.

Quote:Don't put build products into source control. Ever.
For your final product, create a new target that includes the executable from one of the other targets, and add a command-line command to the target that does something like

As far as versioning the executables, I respectfully disagree. I believe that you should keep versions of the executables in source control, especially the tools. Engine source changes can easily break your game and can prevent the rest of your team from working. Versioned executables and data have many times allowed the artists and designers to revert to a previous version and continue working without waiting for a fix from me. There are also times that you will want to look at your project from a certain time instance. Keeping versions of everything makes this process as simple as syncing to that previous revision and running.

#10

Quote:There are also times that you will want to look at your project from a certain time instance.

's what tags are for [in svn speak]. When it's time to call the current trunk your first beta, svn cp svn://repo/trunk/ svn://repo/tags/game-1.0beta1/

Regarding actually having access to older binaries, we like to just have dated packages in a directory store somewhere. Each build is of the form "productname-platform-isodate.tar.gz" or similar, with an automatically updated symlink "productname-platform-latest.tar.gz" to the latest one. Obviously .tar.gz might be .run, or .exe, or .dmg, or whatever is appropriate, but it gives easy access to all the builds to everyone. We have automated build processes that do all this for us. QA don't need access to source control, they just open the directory and load the -latest one, or can pick and choose previous versions for regression testing.

This is kind of a poor man's version control, I just find putting build products into source control to be a bit.. blah.

I guess this is one of those cases of what works for you :-)

Quote:I know this project works ok as when I put the app in that directory, it runs fine.

Ooooh. You need to set the working directory on your executable, not modify its arguments. Same window, right click on the executable and click "get info", change the "working directory".

Gary (-;