What about uncheckedFlags? In other words, SwiftPM merely appends them to the command line without checking that they are compatible with other build settings.
8 Likes
What does it mean to be ineligible to act as a dependency? Does this mean it will be rejected when I try to resolve the dependency? Will there be ways to opt in to having a dependency with unsafe flags? For example, for a local dependency or one using a .branch dependency?
+1 to uncheckedFlags, it is clear and avoids collision with Swift memory safety concept.
I don't think there is a change of confusion with Swift's memory safety since these APIs are nested under package/target/<tool>Settings.
This is exactly the sense we're going for. Package authors should think twice before using unsafe flags. It is an escape hatch to enable experimentation. You can easily land yourself in trouble and break your build so it is important to communicate that there is a "gotcha" with this API.
uncheckedFlags sounds good at first but doesn't give a vibe that there might be some big caveat to it.
What about uncheckedFlags + Swift PM throwing some explicit warning before building the project?
That depends on implementation but basically it means you won't be able to build your package if you depend on a product from a dependency that product contains unsafe flags.
Yikes, I forgot adding this portion in the draft proposal. unsafeFlags will be supported in local dependencies but not branch or versioned dependencies.
A warning would be annoying. I could be using this in a target that I don't vend as a product or even my test targets.
I think it's unfortunate to prevent this for a branch dependency - a branch dependency on master for example is very similar in spirit to a local dependency.
Alternatively, what about having a command-line flag to swiftpm to say -i-know-what-im-doing-allow-unsafe-flags-in-deps? That would enable using unsafe flags as an escape hatch for things that are safe but haven't been explicitly modeled yet by swiftpm. This would be equivalent to using -Xswift -Xcxx et al, but on a per-target basis. This would be very useful to me for flags that have not been included in this first version of the settings API.
I think that sounds much better. We can have this flag instead of baking in the allowance for certain types of dependencies. I wonder if we should still disallow version-based dependencies from using unsafe flags even with this flag.
1 Like
I think the general idea of an escape hatch is sound, but it needs to be more explicit. Once you are specifying it, any dependency could also publish a new version with unsafe flags without you noticing that it happened. This could be a potential security risk, because you can use flags like -B to run arbitrary code during the build process. I think this would need to be a list of packages which are allowed to use unsafe flags instead.
Opting-in per dependency would be fine with me.
1 Like
So now that this is implemented, what is the recommended way to import a C library header into Swift? I have been using .systemLibrary() but if I now use linkedLibrary() the associated headers for the library I want to use are not imported.