Re: Xcode 4 Release Builds
Re: Xcode 4 Release Builds
- Subject: Re: Xcode 4 Release Builds
- From: Brock Brandenberg <email@hidden>
- Date: Thu, 21 Jul 2011 14:40:28 -0500
Hi Fritz.
>> Try setting SYMROOT to "$(PROJECT_DIR)/build" under the build locations section of the project or target build settings (as appropriate for your product). This will cause your executables to be written into a build folder inside your project folder, the same old familiar place as Xcode3 wrote them. Make sure you set the combined setting and not the individual release and debug variants because they will automatically append "Release" and "Debug" to the SYMROOT path for you when you build. The new "derived data" will still be buried in your ~/Library/Developer folder, but at least you'll have your executables in the place you want them.
>>
>> You should be able to do a simple build (command-B) with a scheme that has "run" set to release and have a complete product sitting in your ...build/Release folder.
>
> I am bemused at the thought that
>
> * resetting a build location (and not with the UI provided for the purpose, but with a relatively-hidden build setting),
> * modifying the source-control ignore files,
> * respecifying the build configuration with every build, and
> * rummaging through a product-files directory
>
> is simpler than using the UI provided for the purpose. Click the Share… button, ask for an app, and save the thing wherever you please — is that hard?
There's more to the derived data and build locations than you may have encountered so far, depending on the types of products you develop. In Xcode3 we didn't have the "derived data" concept that was introduced in Xcode4, we simply had the "build" folder that was placed inside your project folder by default (at "$(PROJECT_DIR)/build"), and it contained all the indexes, object files and final products for each and all of your build variants. You could change this build folder location by using the provided UI, and that would set a user-specific SYMROOT value that would redirect all of your build indexes, object files and final products to the folder of your choosing. Again, this SYMROOT setting would be user-specific and it was stored within your .pbxuser file inside your project. Give this project to someone else and they would not see your custom build product location if you had changed it in the provided UI. You would have had to change the SYMROOT setting in the project or target build settings for it to be global for all users.
Now in Xcode4, Apple has added several new layers of complexity to the build products folder, now making it a derived data folder. The build products are located within this new derived data path, which by default is buried deep in your now-hidden library folder. As you mention, you can change the derived data locations using the provided UI in Xcode4 both at the global preferences level and at the project settings level, but therein lies a catch… If you had specified a custom build products location in Xcode3, that value was user-specific and is not accessible in Xcode4 in any way that I have been able to discover (bug ID 9214793). The value is reflected in the project-level SYMROOT build setting, but it is not editable. You can try, but you will find that the value reverts once you try and save it. You can override the value at the target level, but then you can't correct it and get the build products back into the derived data folder without constructing an inherited build setting string (which I have yet to figure out). You have to re-open the project in Xcode3 and delete the user-specific setting using Xcode3's UI, which btw is now a pain since Xcode3 is not installable under Lion (you have to have had a previous installation and upgraded your system to still be able to use Xcode3). Or you have to edit the .pbxuser file by hand and erase the setting.
Now to the point… If you build command-line tools and expect to fopen() and fread() from the current working directory, that directory used to be conveniently located in your project folder just a couple of folders down. You could find the folder easily and add some data files to it, then run your executable, let it fopen() and fread() and life would be good. Now, that working directory folder is buried deep in your now-hidden library folder where it is difficult to access, plus there's no reason to go through an archive process and an extraction process just get at your executable if all you need to do is build and then open the folder to access your executable. It's a level of added work that's distracting and unnecessary for simple tools. However, this may only apply to someone building simple command-line tools and not someone doing a more complicated Cocoa build for the AppStore where archiving is really necessary and is made much easier now by Xcode4. As always, your mileage may vary so don't expect a one-size fits all solution.
So it's a user preference to use the various available preferences and build settings to get the behavior that he/she wants. In my case, I choose to have my derived products go one place, and have my executables go another more accessible place. Michael may be better served by using the derived data location and setting it in the global prefs or project settings, but it's always good to know what the system is doing with these settings so that you can direct things as you wish. And in cases like the UI bug that I (and probably others) got hit with, it helps to know what actual settings and values are causing the problem.
Brock Brandenberg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden