dempseyatgithub/buildsettingextractor

Extracts the build settings of an Xcode project into xcconfig build configuration files.

buildsettingextractor's Issues

Remove Spaces in xcconfig file names

My target is named "Foo Bar iOS". I'd like my .xcconfig files to be named "Foo-Bar-iOS".

Consider supporting a platform/sdk-level set of xcconfig files for cross-platform projects

At the moment BSE performs all of its consolidation on the same 'level'. Common settings across multiple build settings at the project or target level are consolidated into a shared setting.

In a project created with targets for a single platform sdk, the project usually contains some consolidated platform-specific settings (such as SDKROOT).

For a project with targets for multiple platforms, it likely makes sense to have common settings for all targets using the same sdk separated out per platform.

This would generate a set of xcconfig files for each platform. (one per build style + shared).
Each target build style xcconfig file would import the platform build style xcconfig file for the appropriate platform.

Add option to put config files from same target into subfolder

This was suggested by PR #10. The notion is that instead of dumping all of the config files into one directory, that subfolders be created per target. Something like:

Config
     Target
          Target-Debug.xcconfig
          Target-Release.xcconfig
          Target-Shared.xcconfig
     TargetTest
          TargetTest-Debug.xcconfig
          TargetTest-Release.xcconfig
          TargetTest-Shared.xcconfig

Probably would still include the target name in the file name though, to make it easy to identify when selecting or when viewing just the file name in Xcode without the context of its containing folder.

Support new Xcode 6.3 compatible project format.

Enable code signing in preparation of releasing a compiled version of app.

Need a way to keep private build settings like team ID private, but easily usable, while still allowing the open source project to compile without those settings or without a team.

Select project from Open panel to extract

Sometimes choosing from Open panel can be more convenient than drag and drop.

Alert user if project file has no build settings

Consider alerting the user if a project file has no build settings. They may have already extracted the build settings to xcconfig files, for instance. Do not generate a set of empty config files in this case.

Consider some kind of build setting diffing between project files.

Ironically, would probably not take xcconfig files into account, at least not at first, but would try to see differences in two targets, trying at least to resolve project and target level settings to see where target settings differed.

Enable sandboxing in preparation of releasing a compiled version of app

Although not required to release a compiled version of the app, BuildSettingExtractor does access the network or need most entitlements except for read/write access to user selected files and directories and world-readable directories.

So, will enable sandboxing for BulidSettingExtractor.

Crash on 10.9

Looks like the symbol QOS_CLASS_USER_INITIATED was introduced in 10.10, but the project has a deployment target of 10.9.

Running on 10.9 therefore crashes.

(I thought I should get a build warning for things like this. Filed rdar://20137077.)

Either bump the build target to 10.10 or conditionally use one symbol or the other.

Enable hardened runtime in preparation of notarization

In preparation of notarization and providing a version of BuildSettingExtractor that is already built, enable the hardened runtime which is / will be a notarization requirement.

Add missing setting info for SWIFT_COMPILATION_MODE

Xcode provides no quick help for this setting in Xcode 9.4.1. Possibly there is a description that can be found / used in Xcode 10.

I believe these settings change in Swift 4.2, so don't want to add bad information. Need to investigate.

Update app for Mojave Dark Mode

Make sure the app looks and works fine in macOS 10.14 Dark Mode.

The only custom control is the view the DragFileView.

At the very least, the color of the view will probably need to update when in Dark Mode.

Note the current color is a less saturated, lighter blue than the system control color.
Consider using similarly adjusted colors for the new system accent colors.

Consider adding link to build setting documentation that Xcode now adds to its config file header comment

Would need to double check that the URL is valid over time - Apple docs have a habit of dead links.

Gracefully handle if Xcode is not installed in Applications folder

Currently we just don't find any build setting descriptions and fail silently.

If the user has preference checked to include descriptions, should probably alert them that the app can't find them.

Related to #20, since Xcode or a beta might be installed somewhere else.

Define a real error domain constant

Have been using the bundle identifier as the error domain. Possibly would want to change since the errors are not necessarily app-specific (could also be returned in a command-line tool, for instance.)

App crashes on extraction error

Was presenting error on background thread.
Don't do that.

Use Xcode-beta for build setting info

Currently build setting info is gleaned only from Xcode. Xcode-beta installs are ignored.

Should use Xcode-beta if it is a later version than the installed Xcode version or if it is the only version of Xcode installed.

Move version check error to NSError category.

The version check error is currently created inline which makes the core logic of the method harder to follow. Move creation to the NSError category in Constants+Categories.m file.

On one spot in the code inexplicably uses return instead of newline to separate lines.

Should just use newline.

Will need to stop hardcoding path to Xcode in macOS Catalina

Need to investigate the right thing to do.

Possibly able to address Issue #31 at the same time.

Update for Xcode 9.3 project file format

A very cursory test seemed to work as expected. Do a little more testing and roll a new version.

Add a mechanism to handle old/deprecated build setting info files

Sometimes a new version of Xcode removes a build setting info file that we have listed as one we should read.

Need a mechanism to be able to still look for them for Xcode versions where they are still present, but not look for them on later Xcode versions.

Decide how to handle build setting info that is in Markdown format

This relates to #28.

It looks like more of these are being formatted with some Markdown. Backstopping is one possible approach, doing some rudimentary parsing is another. Possibly maintaining own set of build setting info strings is another.

Consider generating a TargetName-Version.xcconfig file

In Xcode 11, the two Info.plist entries that change with each release are now automatically switched to two build settings.

Since those two settings change with each release, it may make sense to split them out into their own xcconfig file so they are easier to find / edit.

Likely would be something like the TargetName-Shared.xcconfig file would import a TargetName-Version.xcconfig file.

Possibly this would just complicate things more than it needs to.

Consider either adding a command line tool or splitting out into a framework

Pull request #15 proposes factoring the extractor pieces into a separate framework. My comments there describe my initial thoughts about that.

It may keep the complexity of the project reduced by adding a command line tool target to the project itself - providing the desired functionality of a command-line tool without the overhead of maintaining a separate framework for a small number of files.

Add test to make sure we are able to read all subpaths

In the past, if a build setting info subpath could not be found or loaded, BSE would log and move on.

Ideally, we would always find all listed subpaths.

This issue is to add a test to load subpaths and report failure if one or more subpaths can not be loaded.

This is related to #38.

Stop using precompiled headers

Clang modules have been turned on for the project for a long while. Remove the .pch file and remove build settings for precompiled headers.

Have BuildSettingExtractor class return an NSError

Currently the BuildSettingExtractor class uses -[NSApp presentError:] to present errors to the user.

It would be better for that class to have no AppKit dependencies so it could be better used as part of a command line tool.

Also -presentError: presents a modal alert as a separate window. It would be a better user experience to present it as an alert sheet on the main app window.

Thank-You for this tool & one question

In my Shared.config file I see this:
...
// Provisioning Profile
// The UUID of a valid provisioning profile. A missing or invalid profile will cause a build error.

PROVISIONING_PROFILE =
...
this is what my build panel looks like:

Should I be concerned?

Thanks Again

Consider adding override settings for build setting info

There may be cases where BSE needs to override any settings found in Xcode. A few current examples:

• The SWIFT_VERSION setting has a name but an empty description. I believe any backstop would be overridden by the blank description.

• The Xcode naming of SWIFT_COMPILATION_MODE is just 'Compilation Mode'. A more clear name in an xcconfig file would be 'Swift Compilation Mode'. An override could substitute that in.

• Markdown or Markdown-ish formatting It looks like some build settings in Xcode, like SWIFT_COMPILATION_MODE are starting to use Markdown for the description string. I'd prefer not to have to add a whole Markdown parser to BSE for that purpose. An override setting would give an opportunity to format the string so it looks better in an xcconfig file

Testing: Possibly store the original string value along with the overridden value, so a test can be written to alert if the original string value changes in Xcode, in case the description changes or is improved.

Replace use of NSError error recovery mechanism to validate destination folder

Currently using an open panel delegate to validate the destination folder and using the NSError error recovery mechanism to recover if the user chooses to overwrite files.

This does not work well with sandboxing turned on and the out-of-process open panel is used.

Have not tested yet this on Catalina, but this validation may throw an exception because the out-of-process open panel is always used.

Moving to a mechanism where the user chooses a directory and then validation occurs with an alert being presented if needed allowing the user to cancel or replace the found files.

SWIFT_COMPILATION_MODE setting is going into SWIFT_OPTIMIZATION_LEVEL

Extractor did not write the SWIFT_COMPILATION_MODE into the config file. It appears it appended the setting to the SWIFT_OPTIMIZATION_LEVEL setting.

Here's an excerpt:

// Swift Optimization Level
// 
// * *None:* Compile without any optimization. [-Onone]
// * *Optimize for Speed:* [-O]
// * *Optimize for Size:* [-Osize]
// * *Whole Module Optimization:* [-O -whole-module-optimization]

SWIFT_OPTIMIZATION_LEVEL = -Owholemodule

Add a way to 'wildcard' a subpath for build setting info files

The path with the LLVM build setting help changes with the LLVM version. Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/Clang LLVM 1.0.xcplugin/Contents/Resources/English.lproj/Apple LLVM 9.0.strings

The path is always the same.

Add a way to wildcard at least this file so the plist does not need to be updated so frequently.

Use GitHub release feature to host binary

Instead of having to build the app.

Don't crash when an xcspec cannot be found

When reading a strings file, we just fail silently with a nil if the file cannot be found.

When reading an xcspec file, we crash. This can happen if no version of Xcode is installed in the Applications folder. Fixing this crash but will have a follow on bug to deal with that more explicitly.

Xcode 11 support

The latest version of BuildSettingExtractor can not extract the build settings from an Xcode 11 project file. Please add support for it.

Do final release before needing to build on macOS 10.14 to build cleanly

Do final release with 10.9 deployment target

Over abundance of blank lines

There seems to be 3 blank lines between each setting in the generated .xcconfig files. Would be nice to collapse them down to 1.

Move NSError creation methods to an NSError category

Move NSError creation methods to an NSError category. Centralizes creation in the category and simplifies the BuildSettingExtractor.m file.

output file naming collision

Let me first tell a story. When I was 7, I'd go to Wal-Mart and play The Legend of Zelda, a game like I'd never seen before, while my mom shopped. I saved up my allowance for an excruciatingly long time and finally walked out of Wal-Mart one day the proud owner of the golden cartridge. I turned on the game and named my character "LINK", because that's his name. Then everything went all screwy. None of the dungeons were where they were supposed to be. The instruction booklet didn't help. Not even the Zelda issue of Nintendo Power could help me. I eventually deleted the character out of frustration and made a new character, and eventually I name it "MIKE", and everything was back to normal. When I finished the game, I found out about the second quest, where all the positions are jumbled, and eventually I found out that naming your character "LINK" is a shortcut to the second quest.

Photo montage several decades to today. I'm converting my project "Beam" with this wonderful tool you've written. In it's Preferences, I change the Output Filenames > Project name: to "Beam", of course, because that's the project's name. The main Target is also named "Beam". Later, as I began removing build settings from the pbxproj, I realized BuildSettingsExtractor hadn't created a set of xcconfigs at the Project level. So I dove in to figure out the problem and eventually it hit me that I have this problem with naming all the things literally.

In short, for a Target named "Project" or in the case that the user changes the Output Filenames > Project name: such that it collides with a Target name–and I'd reckon a vast majority of projects have an identically-named Target–one or the other set of xcconfigs will silently clobber the previously written set. This will be especially confusing for people who are new to xcconfigs and their relation to the build system. Those of us with a literal naming complex could use all the help we can get, I mean, a notice that something has gone awry.

Consider choosing which instance of Xcode in file system to use for setting info

Currently the version of Xcode at /Applications/Xcode is searched for build setting info strings. Consider allowing the user to choose another version of Xcode instead, or possibly looking at multiple versions automatically to find missing info values.

Consider some way of handling build setting changes over time (extracting modern settings from older project)

This issue is related to issue #33, where a setting is now obsolete and is now represented by two settings. The old setting is still allowed by Xcode to be in the project file, but in the interface it appears as two settings.

I'm reluctant to change build settings from what is present in the original project file, but there might be some way to alert the user that they may want to move to more up-to-date settings. Possibly a set of notes that is generated alongside the xcconfig files, a FAQ as part of the ReadMe or some other mechanism. Or possibly suggesting, for older projects, to create a new project, run BSE on both, and compare build settings to see if any seem unused or very different in a brand new project.

Support Xcode 8 project file format

Support Xcode 8 project file format.

Update for Xcode 10.0 project file format

Add missing setting info for deployment target and HiDPI settings

Haven't been able to locate where Xcode is getting its names / descriptions from for non-Mac deployment version settings and a Mac-only setting about combining HiDPI images.

Add these to the set of backstop values.

Move to @import statements

Although clang modules will import modules when #include and #import statements are encountered, move to @import statements to be more explicit.

Move AppKit-dependent category methods to separate file

The BuildSettingExtractor class should not depend on AppKit, but it currently pulls in AppKit through an import of the Constants+Categories.h header.

Move app-specific constants and AppKit-dependent categories to a new .h/.m file.

Consider hoisting common target settings to the project level

At the moment BSE performs all of its consolidation on the same 'level'. Common settings across multiple build settings at the project or target level are consolidated into a shared setting.

If there are common settings across multiple targets, they do not get hoisted to the project level.

For a more complex project, that may be desirable.

Make new build setting info file loading test pass

Adjust the BuildSettingInfoSubpaths.plist file to incorporate new deprecated file support and combine related files into a single subpath array.