<div dir="ltr"><div>Hey Jake,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">For things like the SDK version and compiler version especially, delete (reset) the setting rather than attempting to select a default -- for most settings that&#39;s what you want. I vaguely remember Xcode labeling the Base SDK selections in a misleading way in some older versions.</span></blockquote><div><br></div><div>Ah, I wasn&#39;t aware of that. Thanks, I&#39;ve fixed it according to your recommendations.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">Unfortunately Xcode has no user-level settings for things like this.</span><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">However, here&#39;s an idea: the build settings should default to Developer ID Application. Then update your self-signed certificate instructions to generate a certificate named with the same naming format as Apple&#39;s, like &quot;Developer ID Application: Bob Jones&quot;. Then you can select the standard Developer ID Application setting in Xcode and it should be transparent for those who have real Apple certificates and those who have self-signed ones. Disclaimer: I haven&#39;t tested this, but it would seem to be the most convenient solution for everyone.</span></blockquote><div><br></div><div>That&#39;s an interesting approach. I may have to investigate that later. Currently the plan is to develop a script to automatically create a self-signed code-signing certificate at build time. I recently just pushed up a build script (gen_cert.sh) that does just that, though it&#39;s still doesn&#39;t code sign properly for some reason or another. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">First of all, you should move all of the build settings into xcconfig files so they aren&#39;t duplicated in so many different places. This makes them a lot easier to manage and especially easier to version control.</span><br style="font-size:12.8000001907349px"><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">It looks like there are still some instances of GCC_ENABLE_OBJC_GC in the project settings, under the User-Defined section. Remove that and GC should go away. You can also remove GCC_MODEL_TUNING, ZERO_LINK, PREBINDING... none of those are used anymore either.</span></blockquote><div><br></div><div>Ah, yeah, I believe I&#39;m working in XCode 3.2 compatibility mode, so updating that would probably be a solid idea. As for the &quot;GCC_ENABLE_OBJC_GC&quot;, that should be set to &quot;unsupported&quot;, which, AFAIK, should disable all GC. I&#39;ll be investigating a bit further, though.</div><div><br></div><div>Thanks again for the help!,</div><div>-Kyle </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 20, 2015 at 10:18 PM, Jake Petroules <span dir="ltr">&lt;<a href="mailto:jake.petroules@petroules.com" target="_blank">jake.petroules@petroules.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
&gt;&gt; 4. Don&#39;t use specific versions of OS X SDKs. Have all targets always use the<br>
&gt;&gt; latest OS X SDK available on the build machine.<br>
&gt;<br>
&gt; AFAIK that was done on purpose. To create binaries/app bundles compatible even<br>
&gt; with older versions.<br>
<br>
</span>So many people are confused by this. :) That&#39;s what the deployment target is for, not the SDK version.<br>
<span class=""><br>
<br>
&gt; On Jul 20, 2015, at 6:57 PM, Kyle Sammons &lt;<a href="mailto:ksammons@macports.org">ksammons@macports.org</a>&gt; wrote:<br>
&gt;<br>
&gt; 1. It shouldn&#39;t be using GC. I&#39;ve used the convert-to-ARC tool in XCode, and have even disabled the use of GC in the options. However, it appears as though on 10.10 it&#39;ll using GC rather than ARC, and I have no clue why.<br>
<br>
</span>First of all, you should move all of the build settings into xcconfig files so they aren&#39;t duplicated in so many different places. This makes them a lot easier to manage and especially easier to version control.<br>
<br>
It looks like there are still some instances of GCC_ENABLE_OBJC_GC in the project settings, under the User-Defined section. Remove that and GC should go away. You can also remove GCC_MODEL_TUNING, ZERO_LINK, PREBINDING... none of those are used anymore either.<br>
<br>
I&#39;d send you some patches for this stuff but SVN discourages me. :)<br>
<span class=""><br>
&gt; 2. Pallet currently is hooked up to use BetterAuthorizationSampleLib, however the last time that was used is in 10.5. Currently that doesn&#39;t work on modern versions of OS X, so I&#39;ve disabled it. And, as authorization is required for some MacPorts actions, you need to run Pallet with SuperUser privileges. This is only a temporary fix, as I&#39;ll be replacing it with more modern authorization library soon.<br>
<br>
</span>Ah, cool. I saw an SMJobBlessHelper stub in there so I hoped this was the case.<br>
<span class=""><br>
&gt; 3. Certificates are needed for modern day authorization libraries (SMJobBless, for example) for code-signing purposes. Until I come up with a better way to work around that (without having to pay an exorbitant amount of money to Apple), you have to create your own certificate.<br>
<br>
</span>Unfortunately Xcode has no user-level settings for things like this.<br>
<br>
However, here&#39;s an idea: the build settings should default to Developer ID Application. Then update your self-signed certificate instructions to generate a certificate named with the same naming format as Apple&#39;s, like &quot;Developer ID Application: Bob Jones&quot;. Then you can select the standard Developer ID Application setting in Xcode and it should be transparent for those who have real Apple certificates and those who have self-signed ones. Disclaimer: I haven&#39;t tested this, but it would seem to be the most convenient solution for everyone.<br>
<span class=""><br>
&gt; 4. I actually set all settings in XCode for Pallet and the MacPorts_Framework to use generalized settings (default compiler, highest available SDK, etc.), but for some reason most of my settings on 10.9 aren&#39;t transferring over to 10.10. Odd.<br>
<br>
<br>
</span>For things like the SDK version and compiler version especially, delete (reset) the setting rather than attempting to select a default -- for most settings that&#39;s what you want. I vaguely remember Xcode labeling the Base SDK selections in a misleading way in some older versions.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Jake Petroules - jake.petroules at <a href="http://petroules.com" rel="noreferrer" target="_blank">petroules.com</a><br>
<br>
</font></span></blockquote></div><br></div>