[ef4]

This is a nice band-aid. But really this problem is a symptom of Xcode putting way too much redundant information in this file in the first place. It's configuration over convention.

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.

[seganw]

Sorry, @ef4, my English is not very good, I do not quite understand "You could eliminate all the file references if you simply codified some conventions on project directory structure", could you please explain a little bit?

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.

[ibisum]

First, XCode's build system can at times, not always, deliver total interference in platform portability. You are using a tool designed to lock-in to the platform. There is little use for XCodes' huge taxonomy, but for XCode.

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 ..

[ef4]

I think we're agreeing.

I was suggesting that Xcode should use real directories on disk.

[ibisum]

Personally I agree with your statement, there is a lot about the build structure that can just be held standardly on already-working systems .. its nice to have for example, the known debian/ tree structures, etc. 'make dirs'/&etc.

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. :)