Hi,
In SR-145, Max Howell said he was writing up a proposal to do this on the
clang side of things. It's the right way to do this, but it's going to take
a while. For now, there's basically nothing we can do. I agree that the pr
should be merged temporarily while clang does their thing.
Dan
···
On Sun, Jan 3, 2016 at 6:10 AM Drew Crawford via swift-build-dev < swift-build-dev@swift.org> wrote:
I've noticed that this failed PR:
https://github.com/apple/swift-package-manager/pull/75
Provides either a solution or a workaround for all of these open bugs:
* [SR-397] Linux - module using <dispatch/dispatch.h> does not compile cleanly with "swift build" · Issue #5437 · apple/swift-package-manager · GitHub
* [SR-415] blocks support in external c libraries disabled · Issue #5436 · apple/swift-package-manager · GitHub (possible dupe of SR-397)
* [SR-235] The package manager fails to link C static libraries · Issue #5439 · apple/swift-package-manager · GitHub
* [SR-145] Need a way to add include paths in modulemap · Issue #42767 · apple/swift · GitHub
* [SR-83] Can't link to UUID library · Issue #5334 · apple/swift-package-manager · GitHub
Can we resurrect this PR, possibly with a deprecation warning discouraging
the feature's use, so as to mitigate fully 20% of the open SwiftPM bugs?
I understand the motivation why not to have this feature, but I think it
may provide an effective bandaid while we are focusing on other things
(testing).
_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev
--
Dan Appel
I agree that the pr should be merged temporarily while clang does their thing.
I have PRed this as #107 <https://github.com/apple/swift-package-manager/pull/107>\.
