On Nov 21, 2014, at 04:59 , Richard Kennaway <[email protected]> wrote: > > 1. Xcode buries all of its output products deep into ~/Library, in a > directory > > /Users/rk/Library/Developer/Xcode/DerivedData/JAGLib-gncakhledusgpocxerywvbgnnlvc > > (JAGLib is the name of the project.) I need all of the output files, > including the intermediate products, to be at a fixed, known location, in or > alongside the project folder, not put in a place where only Xcode can find > them. I have looked through all of the project settings that I know how to > find, and I have not found whatever setting is responsible for this.
FWIW, the way to control the placement of intermediates is File -> Project/Workspace Settings. (The menu item changes depending on whether the top level “container” is a project or a workspace.) The Locations preferences supplements this by providing defaults. However, there’s something of a philosophical (or religious) issue here. The derived data is Xcode’s *private* cache of intermediate results, and there’s no real guarantee that anything in there is usable** outside the context of the project to which it belongs. In general, starting with Xcode 4, the apparently intended development workflow is to put your related projects into a workspace where one project (the main or app project) contains references to the products of the other projects (libraries and frameworks). It’s also possible to make some projects sub-projects of the main project, though it’s never been entirely clear how this differs from a workspace, or which approach Apple prefers us to use. (Originally it seemed like workspaces were preferred. More recently, sub-projects seem to be getting more emphasis. IAC, as a matter of fact, there is always a workspace used behind the scenes.) Alternatively, you can avoid multi-project workspaces and sub-projects by building each product separately via Product->Archive. That step will either produce (say) a library in a location you specify, or will install it in a standard location. You can then add these products to the project you are working on. (The drawback in this case is that it isn’t configuration dependent. You’ll only have configuration available — typically the release configuration — and debugging in the dependent product may be difficult.) There are certainly situations where neither of these intended workflows matches your expectations, and in those cases you can use Project/Workspace Settings to direct the intermediate products to a folder of your choosing. ** By usable, I mean that the structure of built products may be different from the final product, or that Xcode may use symlinks for things that will ultimately be embedded, or that Xcode may not always re-build some or all of the partial products at times you can predict. We occasionally see posts on this list complaining about this, when developers try to intermediates as finished products.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
