Skip to content

[Static SDK] Disable assertions in the Swift build.#557

Open
al45tair wants to merge 1 commit into
swiftlang:mainfrom
al45tair:eng/PR-177470294
Open

[Static SDK] Disable assertions in the Swift build.#557
al45tair wants to merge 1 commit into
swiftlang:mainfrom
al45tair:eng/PR-177470294

Conversation

@al45tair

Copy link
Copy Markdown
Contributor

We were inadvertently building with assertions enabled. Turn them off for better performance.

rdar://177470294

We were inadvertently building with assertions enabled.  Turn them
off for better performance.

rdar://177470294
@al45tair

Copy link
Copy Markdown
Contributor Author

Note: this also bumps the Static SDK version to 0.1.1; any scripts that hard-code the version number will need to change.

@al45tair

Copy link
Copy Markdown
Contributor Author

(Build failure is nothing to do with this PR.)

SWIFT_SOURCE_ROOT="${source_dir}/swift-project" \
SWIFT_BUILD_ROOT="${build_dir}/swift" \
run ${source_dir}/swift-project/swift/utils/build-script -r \
run ${source_dir}/swift-project/swift/utils/build-script -r -A \

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We should create a preset

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We could do that, but then the build settings for the SDK are separate from the SDK's own build script, and then we have a versioning problem, since we could update the build settings and end up with a build of the Static SDK with the same version number as another build, but that's built with different build settings.

This wouldn't be a problem if the build scripts lived in the Swift repo rather than the swift-docker repo. Do we want to do that instead?

declare_package mimalloc "mimalloc" "MIT" "https://microsoft.github.io/mimalloc/"

# Parse command line arguments
static_linux_sdk_version=0.1.0

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Feel free to ping me when this lands and I'll make sure the mainline CI job is updated to build the correct version

@shahmishal shahmishal May 26, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Can we drop the version? It creates more work for no added value.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

+1

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It creates more work for no added value.

How are people to know whether (for instance) they've got a build of the Static SDK with this fix if we don't version it?

Equally, if we update the dependencies, how do they know they've got a version with the updated dependencies? (I guess for this they could check the SBOM, since we do have one).

We could drop the version from the filename maybe? That does make life harder for people though, if they care about some specific change we make, since Swift SDKs don't have a version field or any way to ask SwiftPM to tell you what version you have.

(Maybe that should be the ask? Add a version field to the Swift SDK support in SwiftPM, and list the version when you do swift sdk list?)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Or maybe we could update the CI script to look for a file with any version number as the output, and if it needs the version number for some reason then extract it from the filename?

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.

4 participants