XCode has Build for Running/Testing/Profiling but also "Build". Does this build based on your last selection Run/Test/Profile, or does it default to one of them?
Xcode always uses the Run setup when building.
You can easily verify that it's not your latest selection: Choose "Build For Profiling", and you will see a Release-{platformname} folder in Build/Products within your derived data directory. Choose "Build" afterwards, and Xcode will not overwrite the Release-{platformname} directory but create another directory for Debug builds. This works under the assumption that you haven't changed the default schemes, which use Debug builds for the Run setup and Release builds for the Profile setup.
Likewise, you can change the Run setup to use the Release configuration, and when you simply build, you will see Release-{platformname} folders in the derived data directory.
The platform (name) is determined by your current selection:
Related
I have a git repository for a project with a .teamcity folder in it containing versioned teamcity settings. Assuming I have deleted this project from the teamcity server (by first disabling versioned settings and then deleting the project) how can I re-import it?
The use case here is being able to create a new project using a template generator, e.g. yeoman or dotnet new, and be able to import that easily into a parent TeamCity project.
Our current teamcity version is: TeamCity Enterprise 10.0.4 (build 42538), so things may have improved in later versions.
So I think I have figured this out, these are the steps that worked for me.
Create a new project, making sure the Project ID is set correctly
Add a VCS root pointing to your repo that contains your project
Enable versioned settings making sure to select use settings from VCS and choosing the Kotlin settings format
Select "Import settings from VCS" when prompted
In more detail...
Make sure the Project ID for your project matches what you have in your .teamcity file
For example if your .teamcity file contains .teamcity\MyAwesomeProject, then you need to make sure your Project ID in teamcity is set to MyAwesomeProject.
use settings from VCS
If you don't tell TeamCity to use the vcs settings by default then it will do what it usually does and start checking things into source control for you.
For reasons beyond my control, I am using Xcode 3 and attempting to build a crude Audio Unit effect. While setting up the configuration for my project, I tried to set up a 'Copy Files' build phase in order to have the Component Manager be able to find my unit. When I dragged the Unit's component into the new Copy Files build phase and tried to to build the project, I am getting the follow error:
Check Dependencies: Product depends on itself. THis target might include it's own product.
I tried deleting the component file from my Copy Files build phase, and I was able to build the project successfully, however when I run auval -a in the terminal, the Component Manager does not find my effect unit.
How can i fix this?... is it even fixable in Xcode 3?
To accomplish build and install in one build invocation, you can either
a) create a separate target which defines the AU as a dependency and performs the copy (and any other post-build steps)
or b) set the INSTALL_PATH to the components directory and touch the AU as the last build step
It seems that XCode always builds both Debug anв Release configurations (see screenshot attached). I can't untoggle "Profile" option. I need to build Debug version only in 95% of my time. How can I save time by not building Release version every time I press "Build"?
By default, XCode practically always build for Debug, in Release XCode build only when you select from menu Archive or to Profile (shortcut cmd+I) and you see this because when selected you see XCode build your project.
The tab you selected just shows the target(s) (MagicCards1 here) that will be built for each action (Run, Profile, Archive...).
Only one build will be made with the appropriate build configuration (Debug, Release, ...) for any given action: your screenshot shows that the 'Debug' configuration will be used to build your target when you run your project, leading me to think that Xcode already does what you're expecting (and that it'll only compile the source files that changed since the last build).
You can try to compare Debug and Release builds made from scratch by cleaning (Shift+Cmd+K) and building (Cmd+R) with different build configurations in the scheme's Run settings.
You should also check if 'Build Active Architecture Only' is set to Yes and if 'Analyze during Build' is set to No in your Build Settings:
You may also want to watch this WWDC 2013 video: Xcode Core Concepts 401. Schemes are covered around the 44'-mark.
https://developer.apple.com/videos/wwdc/2013/?include=401#401
The tile basically says it all.
I'm developing a mac app which has the normal app target, but also has two more command-line tool targets whose products are copied to the app when building. I remember seeing somewhere that the "Skip install" was important in these cases, but I remember nothing of what I read, so this might be incorrect.
Anyway, I just wanted to know what this option affects.
I believe this only matters when you're developing for the App Store. If you archive your app target and this includes building other targets (command line tools, static libraries, ...), all the targets' products are copied into the archive, unless SKIP_INSTALL is set to YES.
You can verify this: Archive your application, find the archive in the Organizer, Option-Click --> "Show in Finder", go into the archive (Option-Click --> "Show Package Contents"), and in /Products you will find multiple files/folders. However, App Store builds only allow one product within the Products directory. Xcode warns you about this if you "Validate" your archived app in the Organizer:
When you set SKIP_INSTALL=NO (which is the default), the build target will be installed to $(DSTROOT)$(INSTALL_PATH) during the build phase. Setting SKIP_INSTALL=YES causes the target to be built but not installed.
Setting SKIP_INSTALL=YES can be useful for static archives (libsomething.a) that will be later linked into other targets or bundles that will be installed by another target's copy-files build phase.
Skip Install (SKIP_INSTALL)
In case with archive
xcodebuild archive SKIP_INSTALL=NO
NO - allows to put data into <some_path>/<some_name>.xcarchive/Products or install a framework in archive
I have an Xcode project (A) referencing another project (B). By default (as far as I understand it) Xcode will implicitly build the configuration for the B dependency that matches the configuration of the A's target (e.g., "Debug"). But what if I want, say, A to build as "Debug" and the B to build as "Release"? How would I go about specifying that in Xcode?
I don't know of any easy approach, but you can brute-force it by calling xcodebuild directly for the dependency with a "Run Script" build phase.
I know it was just an example, but if your real goal is that the sub-project be a Release (no symbols) build, then you may have a better experience by just building the sub-project into a library or framework and checking the resulting binary into your version control system. Whenever I have a piece of the system that seldom changes and that I don't want debug symbols for, I go ahead and build it as a static library and check it in. I often go ahead and move the code elsewhere as well (with a README file with the .a that says where the code is and how it was built). This saves time on both build and checkout and is invaluable for large projects in my experience.
This might help: if the configuration of the project A is not found, Xcode will build Release config as a fallback (or maybe the first config of the list).
Then you can "force" the link using this tip: Xcode custom build configuration causes "library/file not found" for static libraries
Yes, this is not naturally supported by Xcode; when you build a target, it builds one configuration of itself and of all dependent targets.
The workaround, as Rob mentioned, is to have a dependent target that's an Aggregate Target type that comprises a single Run Script build phase, which simply invokes xcodebuild -configuration Release (or whatever).
You can specify the default 'fallback' configuration in the project info.
Change from:
Use 'Release' for command-line builds.
to:
Use 'Debug' for command-line builds.
And default will be 'Debug'.
Diffs of project file: