Le 22 juil. 2010 à 18:57, Christiaan Hofman a écrit : On Jul 22, 2010, at 14:43, Guillaume Billard wrote: Le 22 juil. 2010 à 11:03, Christiaan Hofman a écrit :
On Jul 22, 2010, at 9:44, Guillaume Billard wrote:
Le 21 juil. 2010 à 18:53, Christiaan Hofman a écrit :
On Jul 21, 2010, at 15:16, Guillaume Billard wrote:
Hello,
I'd like to set different build paths depending on the architecture being built, eg. for SYMROOT ("Build Products Path"):
.../Bin/MacIntel32/<BuildConfiguration>/ for a i386-only build
.../Bin/MacIntel64/<BuildConfiguration>/ for a x86_64-only build
.../Bin/MacIntel/<BuildConfiguration>/ for a i386 + x86_64 build
But the "Add Build Setting Condition" feature is greyed out for all "Build Locations" in Xcode 3.2.2. These are common locations, regardless of the active architecture or the combination of available architectures.
If I build i386 only, then switch to x86_64, a new build will overwrite the products inside this common location.
Is there a workaround? If not, will this be possible in Xcode 4? Should I file a feature request?
Thanks.
Guillaume
Having a build location depending on the arch does not make any sense, because they may, and generally are, combined in a single universal binary. So I would not even see any reasonable condition on which this could depend. So it should therefore be clear that this can't and won't be supported.
The only way I can imagine how this could work (and that already works as it is) is to have different custom build configurations for the one-arch-only builds.
Christiaan
Our application is downloaded from the web and run inside a browser plugin. We need to reduce the download time as much as possible. So we'd rather have the user download 32-bit-only binaries when the app is run from a 32-bit browser, and download 64-bit-only binaries when the app is run from a 64-bit browser.
Because we generate our Xcode projects from a single file and maintain only this file, we could indeed have different custom build configurations, or different projects. Or add a "Run Script Build Phase" to copy the output binaries to a specific location, to avoid overwriting them in the common build location. But none of these seem as practical as a build location depending on the arch.
I hope it makes sense now!
Guillaume
The proper way to do this is to use different build configs. You're building different variants of your app, and that's what build configs are meant for.
AFAICS Xcode does not even have a real way to build only a single arch, other than through setting this in build configs. The active architecture setting is meant for debugging only (see also the note for the "Build Active Architecture Only" build setting). I don't see any other way. If you use this for building a release build, you're abusing Xcode and you should not expect any further support from it.
And I fail to see why choosing a different build config is less practical than choosing a different active architecture.
Christiaan
You're right, once the build configs are set up, it makes no difference. It's setting up the configs that will be less practical, in our case only. I thought that I shouldn't duplicate build configs because: - The overview drop-down allows to switch build configs but also to switch archs for the same build config.
No, as I said it allows to change the active arch, which not the same as the arch of the build product (it's the arch that's being run). - I reckon most of the settings for a 32-bit build config will be identical to the settings for a 64-bit build config.
The way to handle this is through .xcconfig files. - If there are minor differences, Xcode allows a number of settings to have different values depending on the active arch.
That's the arch in the universal binary, not as in different products. If you use separate configs this is even simpler and more transparent IMHO. In the end I think I won't duplicate build configs and use lipo as Jason suggested when we need a "reduced" release build.
I would call that hackish. Usually it is best to use a program (like xcode) in the way it is designed, in this case it certainly would be through build configs. Always, when you don't follow this rule you may face different problems, for instance when Apple will make changes/improvements, or when you want to add a dependency, or something like that. Of course it's your call whether you want to open yourself up for such potential problems. Just my opinion. During development, the fact that you had to rebuild your product when switching back and forth between 32 and 64 builds surprised me at first. But it's only the link step, and if for instance your day-to-day build is 32 bits, and you check the 64 bits build from time to time, any fix you have to make for the 64 bits version implies a rebuild of the 32 bits build when switching back to it anyway.
Well, if you really build only one arch then it certainly would not be just the link phase, as you'd have a different binary. Also, Xcode would not know whether any change is a change "for the 64 bits version". I'm not sure this last sentence is very clear...
Anyway, thank you both!
Guillaume
Ok, I think I finally get it. :) Let's try: - There should be one build config per product, right? - So if you're developing a universal binary, you wouldn't duplicate build configs to test the different architectures in your universal binary? - But as you explained, you would duplicate them if you need to distribute two versions of the same app, ie two products.
We may also have a "standalone" version of our app, ie not attached to a web browser, which would be a universal binary. So that should be 3 build configs. That leads to a side question, as you mentioned dependencies. Our app has a Windows version. Dependencies are located this way under source control: - ExternalLibs/Windows32/Debug/... - ExternalLibs/Windows32/Release/... - ExternalLibs/Windows64/Debug/... - ExternalLibs/Windows64/Release/... Until now we have located Mac dependencies the same way: - ExternalLibs/MacIntel32/Debug/... - ExternalLibs/MacIntel32/Release/... Now that we introduce 64-bit builds into the mix, it makes sense to have our dependencies as universal binaries, instead of separate dependencies for each architecture, right? And if there's a library we depend on that we don't have the source for, and that is available as separate versions, we can use lipo to merge them into a single library. This way all 3 build configs can have the same dependencies. Or am I wrong again?
Thanks. |