[swift-corelibs-dev] libdispatch import order / nondeterminism
David P Grove
groved at us.ibm.com
Thu Feb 11 10:02:29 CST 2016
I've done some exploring this morning (see branch ). It improves
things, but I'm hoping we can do better, which is why there isn't a PR yet.
The branch does two things:
(a) Add a configure option to cause "make install" to install into a
directory structure that matches the one used for a Swift installable
package instead of its default structure.
(b) Some cleanup of how module.map is generated and where it is
installed normally based on this email chain.
Part (a) seems to be working fine. I want to do one more test-build of
Swift from scratch to make sure, but yesterday I was getting a Swift build
where the resulting swiftc could successfully fully import Dispatch without
any extra command line arguments.
Part (b) isn't any worse and maybe is marginally better, but is not really
doing what we want. In particular, with no extra command line arguments,
swiftc seems to be finding the module.map file and importing the C header
files, but it isn't finding Dispatch.swiftmodule. As a result,
dispatch_group_async (for example) is available to the Swift program, but
DISPATCH_QUEUE_CONCURRENT is not.
If I give swiftc -I/usr/local/include/dispatch then it finds
Dispatch.swiftmodule and DISPATCH_QUEUE_CONCURRENT is available.
Giving -Xcc -fmodule-module-map=<file> does not help;
DISPATCH_QUEUE_CONCURRENT is not available.
In a "normal" install we get in PREFIX (/usr/local by default).
*.h from dispatch directory
*.h from os directory
I've tried putting Dispatch.swiftmodule in a variety of places in
the /usr/include tree (lib, lib/x86_64), but none of them seem to help.
Any thoughts on other things to try before submitting a PR?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-corelibs-dev