Skip to content

[SR-6829] Add "DEBUG" to Xcode debug configuration #1518

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Mar 21, 2018
Merged

[SR-6829] Add "DEBUG" to Xcode debug configuration #1518

merged 8 commits into from
Mar 21, 2018

Conversation

krzyzanowskim
Copy link
Contributor

@krzyzanowskim krzyzanowskim commented Mar 4, 2018

https://bugs.swift.org/browse/SR-6829

  • Add "DEBUG" to SWIFT_ACTIVE_COMPILATION_CONDITIONS for generated Xcode project.

The additional changes allows to set the values on the model level, rather than on the project generation level, like I tried here: 9082167

Copy link
Contributor

@aciidgh aciidgh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot! This looks good, I left some minor comments. Please also add a basic unit test.

@@ -164,6 +164,7 @@ func xcodeProject(
projectSettings.debug.GCC_OPTIMIZATION_LEVEL = "0"
projectSettings.debug.ONLY_ACTIVE_ARCH = "YES"
projectSettings.debug.SWIFT_OPTIMIZATION_LEVEL = "-Onone"
projectSettings.debug.SWIFT_ACTIVE_COMPILATION_CONDITIONS += ["DEBUG"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add this define in SwiftPM's build system too. This can go somewhere around here https://github.com/apple/swift-package-manager/blob/master/Sources/Build/BuildPlan.swift#L306

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be:

projectSettings.debug.SWIFT_ACTIVE_COMPILATION_CONDITIONS = ["$(inherited)", "DEBUG"]

Copy link
Contributor Author

@krzyzanowskim krzyzanowskim Mar 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the $(inherited) applies to the OTHER_SWIFT_FLAGS too?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should move -DXcode from OTHER_SWIFT_FLAGS to this build setting but that is orthogonal to this PR.

@@ -431,7 +431,11 @@ fileprivate func combineBuildSettingsPropertyLists(
// FIXME: We should resolve `$(inherited)` here. The way this works is
// that occurrences of `$(inherited)` in the overlay are replaced with
// the overlaid value in the base.
resultDict[name] = value
if let prevValue = resultDict[name] {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this shouldn't be needed if we use $(inherited) in the target specific build settings. See comment below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The FIXME's says $(inherited) doesn't work. This change makes a step in that direction though so the values are combined rather than replaced.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if we should be resolving build settings that come from project settings. But I've not really worked in this area much. @abertelrud should be able to explain!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, for now, lets leave this area unchanged as using $(inherited) seems like the right solution.

Copy link
Contributor Author

@krzyzanowskim krzyzanowskim Mar 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe. The story behind this change is here: 9082167

although we "combine" common and debug BuildSettings, it's not really combined, it's replaced.

I'll revert this.

@krzyzanowskim
Copy link
Contributor Author

@aciidb0mb3r thanks! feedback adressed. back to you.

@@ -574,6 +574,34 @@ public enum PropertyList {
case string(String)
case array([PropertyList])
case dictionary([String: PropertyList])

static func + (lhs: PropertyList, rhs: PropertyList) -> PropertyList {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is no longer required, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no longer. I still think the serialization FIXME should be addressed, but agree it's not necessarily with this PR

switch buildParameters.configuration {
case .debug:
compilationConditions += ["-DDEBUG"]
default:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of default, can you add the explicit .release case? This is helpful when we're adding new cases to the enum. The compiler will produce an error and we will be forced to rethink this switch case.


switch buildParameters.configuration {
case .debug:
compilationConditions += ["-DDEBUG"]
Copy link
Contributor

@aciidgh aciidgh Mar 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I wonder if we should also add this define to C language targets. /cc @ddunbar

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tha makes sense. Should go to the GCC_PREPROCESSOR_DEFINITIONS (that's where the Xcode put it for newly created projects)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

along with the -DSWIFT_PACKAGE=1 or... is it set already?

@krzyzanowskim
Copy link
Contributor Author

@aciidb0mb3r thank! back to you.

@@ -162,8 +162,10 @@ func xcodeProject(
projectSettings.debug.DEBUG_INFORMATION_FORMAT = "dwarf"
projectSettings.debug.ENABLE_NS_ASSERTIONS = "YES"
projectSettings.debug.GCC_OPTIMIZATION_LEVEL = "0"
projectSettings.debug.GCC_PREPROCESSOR_DEFINITIONS = ["DEBUG=1", "$(inherited)"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be projectSettings.debug.GCC_PREPROCESSOR_DEFINITIONS = ["$(inherited)", "DEBUG=1"]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I KNOW. but... it's the other way around in the newly created Xcode project.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷‍♂️okay then


switch buildParameters.configuration {
case .debug:
compilationConditions += ["-DDEBUG"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aciidgh
Copy link
Contributor

aciidgh commented Mar 20, 2018

@swift-ci please smoke test

@aciidgh
Copy link
Contributor

aciidgh commented Mar 21, 2018

Failures look related

@krzyzanowskim
Copy link
Contributor Author

@swift-ci please smoke test

1 similar comment
@aciidgh
Copy link
Contributor

aciidgh commented Mar 21, 2018

@swift-ci please smoke test

@aciidgh
Copy link
Contributor

aciidgh commented Mar 21, 2018

@swift-ci please smoke test linux

@aciidgh
Copy link
Contributor

aciidgh commented Mar 21, 2018

@swift-ci please smoke test Linux

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants