I have an Objective-C framework that is also distributed as a Swift Package. Recently I updated the Xcode project to pass hardening flags to the C compiler.
As the package maintainer should I also modify package description to use these flags? Or is it something the can be easily done by the package user, therefore it's best to avoid specifying flags that are otherwise non-essesntial to the compilation?
Developers using your package will need to use a script or do extra work, sometimes tedious, to maintain the flags for every build/run of their project(s). IMO, you should not enforce the flags onto every project that use your dependency unless it is a key functionality of it.
A project of mine (swift-intrinsics) doesn't explicitly define the flags in the package but does list them in the README, so it is entirely up to the developer to define what features they want to use. Swift Intrinsics works with architecture flags, but your mileage will vary if you use others.
In your case of hardening flags, I personally would make note of them in the README rather than defining them in the package description, unless you're the only one using the package or you won't maintain the flags for every project that uses it.
So you say that from a user perspective it is much easier to add flags to a particular package dependency than remove or override one supplied by the dependency maintainer?
With the current state of Swift (and SwiftPM), yes.