Hey Jake,
> 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's what you want. I vaguely remember Xcode labeling the Base > SDK selections in a misleading way in some older versions. Ah, I wasn't aware of that. Thanks, I've fixed it according to your recommendations. Unfortunately Xcode has no user-level settings for things like this. > > However, here'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's, like > "Developer ID Application: Bob Jones". 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't tested this, but it would seem to be the most > convenient solution for everyone. That'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's still doesn't code sign properly for some reason or another. First of all, you should move all of the build settings into xcconfig files > so they aren't duplicated in so many different places. This makes them a > lot easier to manage and especially easier to version control. > > 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. Ah, yeah, I believe I'm working in XCode 3.2 compatibility mode, so updating that would probably be a solid idea. As for the "GCC_ENABLE_OBJC_GC", that should be set to "unsupported", which, AFAIK, should disable all GC. I'll be investigating a bit further, though. Thanks again for the help!, -Kyle On Mon, Jul 20, 2015 at 10:18 PM, Jake Petroules < [email protected]> wrote: > > >> 4. Don't use specific versions of OS X SDKs. Have all targets always > use the > >> latest OS X SDK available on the build machine. > > > > AFAIK that was done on purpose. To create binaries/app bundles > compatible even > > with older versions. > > So many people are confused by this. :) That's what the deployment target > is for, not the SDK version. > > > > On Jul 20, 2015, at 6:57 PM, Kyle Sammons <[email protected]> wrote: > > > > 1. It shouldn't be using GC. I'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'll using GC rather than ARC, and I have no clue why. > > First of all, you should move all of the build settings into xcconfig > files so they aren't duplicated in so many different places. This makes > them a lot easier to manage and especially easier to version control. > > 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. > > I'd send you some patches for this stuff but SVN discourages me. :) > > > 2. Pallet currently is hooked up to use BetterAuthorizationSampleLib, > however the last time that was used is in 10.5. Currently that doesn't work > on modern versions of OS X, so I'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'll be replacing it with more > modern authorization library soon. > > Ah, cool. I saw an SMJobBlessHelper stub in there so I hoped this was the > case. > > > 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. > > Unfortunately Xcode has no user-level settings for things like this. > > However, here'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's, like > "Developer ID Application: Bob Jones". 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't tested this, but it would seem to be the most > convenient solution for everyone. > > > 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't transferring over to 10.10. Odd. > > > 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's what you want. I vaguely remember Xcode labeling the Base > SDK selections in a misleading way in some older versions. > -- > Jake Petroules - jake.petroules at petroules.com > >
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
