-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Package] Fix passing -gline-tables-only when building. #33616
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
Conversation
We should do regardless of whether we run the tests or not. Also, clarify a comment while I'm here.
@swift-ci test |
extra-cmake-options= | ||
-DLLDB_FRAMEWORK_COPY_SWIFT_RESOURCES=0 | ||
-DCMAKE_C_FLAGS="-gline-tables-only" | ||
-DCMAKE_CXX_FLAGS="-gline-tables-only" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks scary to me, but hopefully just because I don't know how to read this .ini file :-)
Can you confirm that this only affects the ci.swift.org downloadable toolchain packages, and no other toolchains?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still want all other toolchains to build with full debug info.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is under
# OS X Package Builders
#===------------------------------------------------------------------------===#
[preset: mixin_osx_package_base]
Mishal, can you confirm it's safe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine because it will help all preset using mixin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just be sure: I'm worried that this will apply to too many presets, not too few.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're uncertain, we should remove this. I can't picture in my mind the whole matrix of interactions with mixin et similia. It's just fundamentally odd this applies only when we don't run tests, so that's the attempt of unifying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I'm curious, what other toolchains you're talking about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adrian is talking about our internal release toolchains. @shahmishal can you confirm whether this is a noop for our internal builds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't use these preset for internal builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is resolved.
We should do regardless of whether we run the tests or not.
Also, clarify a comment while I'm here.