Confused by unsafe flags being disallowed in dependencies

I'm continuing a discussion from https://github.com/apple/swift-package-manager/pull/1884 with @SDGGiesbrecht in the forums to stop polluting the PR.

Background: I'm using some experimental or advanced compiler flags in a multi-package setting, and was surprised that that PR seemed to block support for that.

I was using: .package(url: ..., .branch("experimental_branch")) when I ran into this issue, so perhaps this is just a bug? If so, I'm happy to contribute a fix that allows .branch to work.

2 Likes

This was part of the target-specific build settings proposal, see: https://github.com/apple/swift-evolution/blob/master/proposals/0238-package-manager-build-settings.md#unsafe-flags-all

The initial proposal did have an escape hatch which would bypass this limitation by using a command-line flag (something like --allow-unsafe-flags-in-dependencies). However, we decided to revisit this topic at a later point. I am not sure if using a command-line flag is the best idea. Maybe we should provide a API in the manifest file that allows you explicitly opt-in into using a package with unsafe flags. It'd be great if you wanted to explore this and come up with a proposal.

That said, I do think that this limitation doesn't make sense for local/branch-based package dependencies and I am planning to work on a patch to lift this limitation for those cases. Filed: https://bugs.swift.org/browse/SR-11225

2 Likes

Sounds good. Once you have the mechanism to allow unsafe, if necessary, we just need a bool attached to the Package.Dependency.Requirement for .rangeItem and .exact telling if it allows unsafe or not.

Seems like .exact("v1.0.0").allowUnsafeFlags() would be best, but that doesn't quite work.
However, .exactWithUnsafeFlags("v1.0.0") could work?

The pull request lifting the (accidental?) restriction from local and branch dependencies is here if you want to track its progress, @pschuh.

3 Likes
Terms of Service

Privacy Policy

Cookie Policy