Draft Proposal: Target Specific Build Settings


(Tony Allevato) #42

What about uncheckedFlags? In other words, SwiftPM merely appends them to the command line without checking that they are compatible with other build settings.


(Ben Langmuir) #43

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?


(Pedro José Pereira Vieito) #44

+1 to uncheckedFlags, it is clear and avoids collision with Swift memory safety concept.


(Ankit Aggarwal) #45

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.


(Ankit Aggarwal) #46

uncheckedFlags sounds good at first but doesn't give a vibe that there might be some big caveat to it.


(Pedro José Pereira Vieito) #47

What about uncheckedFlags + Swift PM throwing some explicit warning before building the project?


(Ankit Aggarwal) #48

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.


(Ankit Aggarwal) #49

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.


(Ben Langmuir) #50

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.


(Ankit Aggarwal) #51

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.


(Boris Buegling) #52

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.


SE-0238: Package Manager Target Specific Build Settings
(Ben Langmuir) #53

Opting-in per dependency would be fine with me.


(Ryan Walklin) #54

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.