xUnique – Regenerate Xcode projects on any machine
github.com
github.com
Add a .gitattributes file to the root of your project with the following line:
*.pbxproj binary merge=union
Very occasionally you will get duplicate items but Xcode then warns you can take approbate action.
[1] I started using this approach a couple years ago after finding this:
http://stackoverflow.com/questions/12909222/tell-git-to-trea...
xUnique makes these UUIDS unique for everyone in the project. So there should be no conflicts theoretically.
You could eliminate all the file references if you simply codified some conventions on project directory structure. Conventions that people are almost certainly following anyway.
I think the merge conflicts are all due to Xcode not using real directories on disk, which means it has to maintain the directory structures in project file.
I was suggesting that Xcode should use real directories on disk.
Seems, though, that we humans are infinitely packaging things, at least in the OS space. There are a nearly insurmountable number of ways of setting something up so the computer can execute something for us. Tree-structures, package formats, .desktop files, and all of these things .. its an infinite taxonomy.
Personally, I yearn for a very smart OS which boots straight to console, and yet then implements everything - everything, desktop, games, etc. - in a single language context. In a lab full of beagleboards and arduinos and so on, the desire is to reduce the language-load on the smaller machines. I think that a single-language, wide-open, for these platforms would make for a new OS opportunity.
Not much of a jump from booting a working kernel+load81 "./main.lua" to a new directory structure to follow. :)
Second, you don't have to worry; you can quite easily port and maintain a cross-platform solution if you treat Xcode as the third-class tool it is: xcodebuild, and its all you need. Use it to build, only. So, for example, a C++ app which carries along its own well maintained source code, can quite easily be 'plugged in' to an XCode app and delivered on the platform. Fortunately, their fancy features are easily glommed .. at least, for now.
Anyway .. The Issue, of course, is API and Framework usage. If you avoid the tweaking of things by Apple, and use known standards bravely (i.e. avoid their candy, "use GL for everything"), you can treat Apples' platforms as a build target, and it works. Take for example: games, game engines, etc.
But of course, if you take the Apple Way (tm) and get the hooks into you about their IDE, delivering Apple-only/-specific style Apps with their GUi-based development .. and face it, its quite comfortable right now to just do "Apple-mostly" development .. thats a different story.
Xcode requires a bit of push and shove, to maintain different build products. Use it (Xcode, specifically, I mean) only to configure the Build product - which after all, is not a bad thing to also do manually alongside the automated build-server directives ..