<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Building the Build System &#8211; Part 1 &#8211; Abandoning the Build Panel</title>
	<atom:link href="http://robnapier.net/blog/build-system-1-build-panel-360/feed" rel="self" type="application/rss+xml" />
	<link>http://robnapier.net/blog/build-system-1-build-panel-360</link>
	<description>Mac and iPhone, on the brain</description>
	<lastBuildDate>Tue, 17 Aug 2010 20:33:18 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Rob Napier</title>
		<link>http://robnapier.net/blog/build-system-1-build-panel-360/comment-page-1#comment-1875</link>
		<dc:creator>Rob Napier</dc:creator>
		<pubDate>Fri, 09 Jul 2010 12:46:24 +0000</pubDate>
		<guid isPermaLink="false">http://robnapier.net/blog/?p=360#comment-1875</guid>
		<description>&lt;p&gt;Thanks for the tip. The SDK is one of the few things I recommend setting outside of the xcconfig files. I set it in the General pane (rather than the build pane, though doing so updates the build pane). It seems to be used by a lot of things in Xcode.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Thanks for the tip. The SDK is one of the few things I recommend setting outside of the xcconfig files. I set it in the General pane (rather than the build pane, though doing so updates the build pane). It seems to be used by a lot of things in Xcode.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: clozach</title>
		<link>http://robnapier.net/blog/build-system-1-build-panel-360/comment-page-1#comment-1871</link>
		<dc:creator>clozach</dc:creator>
		<pubDate>Fri, 09 Jul 2010 05:07:08 +0000</pubDate>
		<guid isPermaLink="false">http://robnapier.net/blog/?p=360#comment-1871</guid>
		<description>&lt;p&gt;This is awesome...great to actually have this info humanely accessible to version control! One caveat worth appending to your instructions: Xcode 3.2.3 appears to have a bug whereby the option to select between Device and Simulator disappears from the &quot;Overview&quot; target menu if you delete &#039;Base SDK&#039; (i.e., SDKROOT) from the project info&#039;s Build settings.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>This is awesome&#8230;great to actually have this info humanely accessible to version control! One caveat worth appending to your instructions: Xcode 3.2.3 appears to have a bug whereby the option to select between Device and Simulator disappears from the &#8220;Overview&#8221; target menu if you delete &#8216;Base SDK&#8217; (i.e., SDKROOT) from the project info&#8217;s Build settings.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: ramzez</title>
		<link>http://robnapier.net/blog/build-system-1-build-panel-360/comment-page-1#comment-306</link>
		<dc:creator>ramzez</dc:creator>
		<pubDate>Sat, 03 Oct 2009 20:26:42 +0000</pubDate>
		<guid isPermaLink="false">http://robnapier.net/blog/?p=360#comment-306</guid>
		<description>&lt;p&gt;Yeah that&#039;s an interesting approach and unbelievable short comming of IDE, if i have time i would have a look at it. Interstingly all other platforms we work with don&#039;t have such limitation. I just used bugreports to ask for Parent-Child relationship as a new Feature.&lt;/p&gt;

&lt;p&gt;Thank you very much for your help and time!&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Yeah that&#8217;s an interesting approach and unbelievable short comming of IDE, if i have time i would have a look at it. Interstingly all other platforms we work with don&#8217;t have such limitation. I just used bugreports to ask for Parent-Child relationship as a new Feature.</p>

<p>Thank you very much for your help and time!</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Napier</title>
		<link>http://robnapier.net/blog/build-system-1-build-panel-360/comment-page-1#comment-305</link>
		<dc:creator>Rob Napier</dc:creator>
		<pubDate>Sat, 03 Oct 2009 20:17:57 +0000</pubDate>
		<guid isPermaLink="false">http://robnapier.net/blog/?p=360#comment-305</guid>
		<description>&lt;p&gt;&lt;a href=&quot;#comment-302&quot; rel=&quot;nofollow&quot;&gt;@ramzez&lt;/a&gt; You can&#039;t define Configuration in the xcconfig, because the appropriate xcconfig file is chosen by the Configuration.&lt;/p&gt;

&lt;p&gt;So in your case, there would probably be a Shared.xcconfig that is shared by every project in the system. Then there would be 20 &quot;configuration&quot; xcconfigs that would #import Shared and would also be shared by every project in the system. At the Project level of every project, you would make 20 configurations, and base them on each of these 20 xcconfig files. That&#039;s a bit complex, I know, and very manual if you have to add a new configuration, but it is the best solution I know of. You can Applescript it, though. Here&#039;s the idea to get you started:&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;&lt;code&gt;tell application &quot;Xcode&quot;
    duplicate build configuration type named &quot;Debug&quot; of first project
    set aConfig to build configuration type named &quot;Debug copy&quot; of first project
    set name of aConfig to &quot;New&quot;
end tell
&lt;/code&gt;&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;Then each project would have its own xcconfig that all configurations are based on at the Target level. At this level, you can do things like:&lt;/p&gt;

&lt;p&gt;GCC_PREPROCESSOR_DEFINITIONS = $(inherited) USE_SPECIAL_CASE2&lt;/p&gt;

&lt;p&gt;Note the use of $(inherited) here; we&#039;re doing it at the Target level, so we want to inherit from the Project level.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p><a href="#comment-302" rel="nofollow">@ramzez</a> You can&#8217;t define Configuration in the xcconfig, because the appropriate xcconfig file is chosen by the Configuration.</p>

<p>So in your case, there would probably be a Shared.xcconfig that is shared by every project in the system. Then there would be 20 &#8220;configuration&#8221; xcconfigs that would #import Shared and would also be shared by every project in the system. At the Project level of every project, you would make 20 configurations, and base them on each of these 20 xcconfig files. That&#8217;s a bit complex, I know, and very manual if you have to add a new configuration, but it is the best solution I know of. You can Applescript it, though. Here&#8217;s the idea to get you started:</p>

<p><pre><code>tell application "Xcode"
    duplicate build configuration type named "Debug" of first project
    set aConfig to build configuration type named "Debug copy" of first project
    set name of aConfig to "New"
end tell
</code></pre></p>

<p>Then each project would have its own xcconfig that all configurations are based on at the Target level. At this level, you can do things like:</p>

<p>GCC_PREPROCESSOR_DEFINITIONS = $(inherited) USE_SPECIAL_CASE2</p>

<p>Note the use of $(inherited) here; we&#8217;re doing it at the Target level, so we want to inherit from the Project level.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: ramzez</title>
		<link>http://robnapier.net/blog/build-system-1-build-panel-360/comment-page-1#comment-303</link>
		<dc:creator>ramzez</dc:creator>
		<pubDate>Sat, 03 Oct 2009 20:00:36 +0000</pubDate>
		<guid isPermaLink="false">http://robnapier.net/blog/?p=360#comment-303</guid>
		<description>&lt;p&gt;&lt;a href=&quot;#comment-301&quot; rel=&quot;nofollow&quot;&gt;@Rob Napier&lt;/a&gt; 
yeah that&#039;s correct, we have 10 Distribution Configuraitons and 10 Adhoc Configurations. I understood your approach and did the same, but then hit the problem described above. It is pity XCode doesn&#039;t have Parent&gt;Child relationship in that case everything would be so perfect.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p><a href="#comment-301" rel="nofollow">@Rob Napier</a> 
yeah that&#8217;s correct, we have 10 Distribution Configuraitons and 10 Adhoc Configurations. I understood your approach and did the same, but then hit the problem described above. It is pity XCode doesn&#8217;t have Parent&gt;Child relationship in that case everything would be so perfect.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: ramzez</title>
		<link>http://robnapier.net/blog/build-system-1-build-panel-360/comment-page-1#comment-302</link>
		<dc:creator>ramzez</dc:creator>
		<pubDate>Sat, 03 Oct 2009 19:53:25 +0000</pubDate>
		<guid isPermaLink="false">http://robnapier.net/blog/?p=360#comment-302</guid>
		<description>&lt;p&gt;&lt;a href=&quot;#comment-300&quot; rel=&quot;nofollow&quot;&gt;@ramzez&lt;/a&gt; 
Another question , is that possible to define Configuration as part of the xcconfig ?&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p><a href="#comment-300" rel="nofollow">@ramzez</a> 
Another question , is that possible to define Configuration as part of the xcconfig ?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Napier</title>
		<link>http://robnapier.net/blog/build-system-1-build-panel-360/comment-page-1#comment-301</link>
		<dc:creator>Rob Napier</dc:creator>
		<pubDate>Sat, 03 Oct 2009 19:50:11 +0000</pubDate>
		<guid isPermaLink="false">http://robnapier.net/blog/?p=360#comment-301</guid>
		<description>&lt;p&gt;You can&#039;t do if() logic like this on configurations. The only conditionals you can do are architecture, SDK and variant (I&#039;ve never really found a good way to make variant useful).&lt;/p&gt;

&lt;p&gt;The way you create conditionals is to have separate files and base a Configuration off of that file (at the Project or Target level). So rather than having Shared.xcconfig set the macros, you set the macros in adhoc1.xcconfig and #include Shared.xcconfig there to get the rest. You can see an example of this in my template project. I have Shared.xcconfig (which is included by others, but no configuration is based on it), then I have Debug.xcconfig which the Debug Configuration is based on at the Project level, Release.xcconfig which the Release Configuration is based on at the Project level, and Application.xcconfig which all configurations are based on at the Target level. So Shared is read, then either Debug or Release overrides settings in Shared, and finally Application overrides settings in Shared, Debug or Release.&lt;/p&gt;

&lt;p&gt;I&#039;m not certain what &quot;10 Distributions&quot; mean. Do you mean 10 targets, or 10 adhoc configurations and 10 distribution configurations (20 configs in total). If 20 configs, then you&#039;d do exactly as I&#039;ve done, but instead of just 2 (&quot;Debug&quot; and &quot;Release&quot;) you&#039;d have 20.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>You can&#8217;t do if() logic like this on configurations. The only conditionals you can do are architecture, SDK and variant (I&#8217;ve never really found a good way to make variant useful).</p>

<p>The way you create conditionals is to have separate files and base a Configuration off of that file (at the Project or Target level). So rather than having Shared.xcconfig set the macros, you set the macros in adhoc1.xcconfig and #include Shared.xcconfig there to get the rest. You can see an example of this in my template project. I have Shared.xcconfig (which is included by others, but no configuration is based on it), then I have Debug.xcconfig which the Debug Configuration is based on at the Project level, Release.xcconfig which the Release Configuration is based on at the Project level, and Application.xcconfig which all configurations are based on at the Target level. So Shared is read, then either Debug or Release overrides settings in Shared, and finally Application overrides settings in Shared, Debug or Release.</p>

<p>I&#8217;m not certain what &#8220;10 Distributions&#8221; mean. Do you mean 10 targets, or 10 adhoc configurations and 10 distribution configurations (20 configs in total). If 20 configs, then you&#8217;d do exactly as I&#8217;ve done, but instead of just 2 (&#8220;Debug&#8221; and &#8220;Release&#8221;) you&#8217;d have 20.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: ramzez</title>
		<link>http://robnapier.net/blog/build-system-1-build-panel-360/comment-page-1#comment-300</link>
		<dc:creator>ramzez</dc:creator>
		<pubDate>Sat, 03 Oct 2009 19:38:31 +0000</pubDate>
		<guid isPermaLink="false">http://robnapier.net/blog/?p=360#comment-300</guid>
		<description>&lt;p&gt;Right i see, i assumed that it maybe a problem. Is there a way to query what Configuration has been choosen, cause what we have is 10 Adhoc Configuraitons and 10 Distributions, so what i was thinking to make&lt;/p&gt;

&lt;p&gt;adhoc1.xconfig which would Configuration 1 be based on, if Configuration is passed to other project, in the shared.xcconfig i may have something like :&lt;/p&gt;

&lt;p&gt;if $(CONFIGURATION) == ADHOC1&lt;/p&gt;

&lt;p&gt;// set macros&lt;/p&gt;

&lt;p&gt;else if&lt;/p&gt;

&lt;p&gt;etc etc, but i am not sure if it is possible to query which configuration has been chosen in xcconfig and set settings dynamically.&lt;/p&gt;

&lt;p&gt;Or maybe you have some other ideas you don&#039;t mind to share?&lt;/p&gt;

&lt;p&gt;thanks a lot.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Right i see, i assumed that it maybe a problem. Is there a way to query what Configuration has been choosen, cause what we have is 10 Adhoc Configuraitons and 10 Distributions, so what i was thinking to make</p>

<p>adhoc1.xconfig which would Configuration 1 be based on, if Configuration is passed to other project, in the shared.xcconfig i may have something like :</p>

<p>if $(CONFIGURATION) == ADHOC1</p>

<p>// set macros</p>

<p>else if</p>

<p>etc etc, but i am not sure if it is possible to query which configuration has been chosen in xcconfig and set settings dynamically.</p>

<p>Or maybe you have some other ideas you don&#8217;t mind to share?</p>

<p>thanks a lot.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Napier</title>
		<link>http://robnapier.net/blog/build-system-1-build-panel-360/comment-page-1#comment-299</link>
		<dc:creator>Rob Napier</dc:creator>
		<pubDate>Sat, 03 Oct 2009 19:03:07 +0000</pubDate>
		<guid isPermaLink="false">http://robnapier.net/blog/?p=360#comment-299</guid>
		<description>&lt;p&gt;First, read over the &lt;a href=&quot;http://developer.apple.com/mac/library/DOCUMENTATION/DeveloperTools/Conceptual/XcodeBuildSystem/300-Build_Settings/bs_build_settings.html#//apple_ref/doc/uid/TP40002691-SW2&quot; rel=&quot;nofollow&quot;&gt;Build Settings&lt;/a&gt; page in the docs to make sure you understand how layering and setting evaluation work. In particular note how you can use both Project-level and Target-level settings to compliment each other.&lt;/p&gt;

&lt;p&gt;More specific to your issue, you almost certainly want to use #include files. So you put the common settings in some SharedLibrary.xcconfig and you then #include that file into each project&#039;s xcconfig. You can overload settings after you&#039;ve done the #include. In the case of GCC_PREPROCESSOR_DEFINITIONS above, make sure that you&#039;ve defined that in something you&#039;ve #included. That would be my suspicion.&lt;/p&gt;

&lt;p&gt;Also, remember $(inherited), which represents the value this variable has based on higher (rather than earlier) levels. What I mean is that if you set VAR to something and then #include that, $(VAR) will give you the value it was given in the earlier #include. If you set VAR at the Project level, then at the Target level $(inherited) will give you the value from the Project level. So often the first setter of VAR at a level should use $(inherited), and later setters should use $(VAR) as their first element.&lt;/p&gt;

&lt;p&gt;Remember that each project compiles independently. What you&#039;ve done in the &quot;parent&quot; project has almost no impact on the &quot;children&quot; projects (there really is no such thing as &quot;parent&quot; and &quot;children&quot; in xcodebuild). I say &quot;almost no impact&quot; because a couple of things are passed down; specifically the SDK and the Configuration. But setting GCC_PREPROCESSOR_DEFINITIONS in one project has no impact at all on other projects. If you want to share a value, you need to hoist that into a separate xcconfig file and #include it into the xcconfig files for each project.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>First, read over the <a href="http://developer.apple.com/mac/library/DOCUMENTATION/DeveloperTools/Conceptual/XcodeBuildSystem/300-Build_Settings/bs_build_settings.html#//apple_ref/doc/uid/TP40002691-SW2" rel="nofollow">Build Settings</a> page in the docs to make sure you understand how layering and setting evaluation work. In particular note how you can use both Project-level and Target-level settings to compliment each other.</p>

<p>More specific to your issue, you almost certainly want to use #include files. So you put the common settings in some SharedLibrary.xcconfig and you then #include that file into each project&#8217;s xcconfig. You can overload settings after you&#8217;ve done the #include. In the case of GCC_PREPROCESSOR_DEFINITIONS above, make sure that you&#8217;ve defined that in something you&#8217;ve #included. That would be my suspicion.</p>

<p>Also, remember $(inherited), which represents the value this variable has based on higher (rather than earlier) levels. What I mean is that if you set VAR to something and then #include that, $(VAR) will give you the value it was given in the earlier #include. If you set VAR at the Project level, then at the Target level $(inherited) will give you the value from the Project level. So often the first setter of VAR at a level should use $(inherited), and later setters should use $(VAR) as their first element.</p>

<p>Remember that each project compiles independently. What you&#8217;ve done in the &#8220;parent&#8221; project has almost no impact on the &#8220;children&#8221; projects (there really is no such thing as &#8220;parent&#8221; and &#8220;children&#8221; in xcodebuild). I say &#8220;almost no impact&#8221; because a couple of things are passed down; specifically the SDK and the Configuration. But setting GCC_PREPROCESSOR_DEFINITIONS in one project has no impact at all on other projects. If you want to share a value, you need to hoist that into a separate xcconfig file and #include it into the xcconfig files for each project.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: ramzez</title>
		<link>http://robnapier.net/blog/build-system-1-build-panel-360/comment-page-1#comment-287</link>
		<dc:creator>ramzez</dc:creator>
		<pubDate>Wed, 30 Sep 2009 20:37:42 +0000</pubDate>
		<guid isPermaLink="false">http://robnapier.net/blog/?p=360#comment-287</guid>
		<description>&lt;p&gt;Here the situation we have and were wondering your advice/opinion, we have a project which uses many libraries and we build multiple configurations (10 for adhoc, 10 for distribution), we have a project which includes the source code for all libararies and then builds each as a static library and links all together, after adding Configuration the project loading and especially switching between Simulator and Device is extremely slow, also accessing any project settings is a hog.&lt;/p&gt;

&lt;p&gt;Static libraries share a lot of the preprocessors, the idea is to decouple static libraries into the different project files and include those in the main project. But here is the Challenge, some libraries require Macros to be set depending on which product we are building. i.e. Configuration A, sets Macro USE_SPECIAL_CASE, which a few static libraries needs to compile with, Configuration B, sets USE_SPECIAL_CASE2 etc.&lt;/p&gt;

&lt;p&gt;We have tried to add GCC_PREPROCESSOR_DEFINITIONS = $(GCC_PREPROCESSOR_DEFINITIONS) USE_SPECIAL_CASE2 but it is not propagated to other projects.&lt;/p&gt;

&lt;p&gt;Thanks for the help.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Here the situation we have and were wondering your advice/opinion, we have a project which uses many libraries and we build multiple configurations (10 for adhoc, 10 for distribution), we have a project which includes the source code for all libararies and then builds each as a static library and links all together, after adding Configuration the project loading and especially switching between Simulator and Device is extremely slow, also accessing any project settings is a hog.</p>

<p>Static libraries share a lot of the preprocessors, the idea is to decouple static libraries into the different project files and include those in the main project. But here is the Challenge, some libraries require Macros to be set depending on which product we are building. i.e. Configuration A, sets Macro USE_SPECIAL_CASE, which a few static libraries needs to compile with, Configuration B, sets USE_SPECIAL_CASE2 etc.</p>

<p>We have tried to add GCC_PREPROCESSOR_DEFINITIONS = $(GCC_PREPROCESSOR_DEFINITIONS) USE_SPECIAL_CASE2 but it is not propagated to other projects.</p>

<p>Thanks for the help.</p>]]></content:encoded>
	</item>
</channel>
</rss>
