[swift-build-dev] [swift-evolution] [Review] SE-0038 Package Manager C Language Target Support

[Daniel Dunbar]

On Feb 18, 2016, at 1:26 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Looks pretty good! My one comment is that I think there should be support for umbrella headers, which allow more control over include order within a module. Maybe it's not strictly necessary, but if someone wants to develop a package that can be used by modular and non-modular build environments, they probably also want a way to keep the behavior as close as possible.

I agree, I will amend the proposal to add this.

> Suggestion: "foo/foo.h" in the include/ folder for "foo" is treated as an umbrella header if present; overriding this requires writing your own module map.

Agreed.

> Having the "include/" folder inside the "src/" folder seems weird to me, but I guess it's the most consistent thing for packages that omit the src/ folder altogether.

Can you elaborate here? Is your concern packages that in traditional UNIX style would have looked something like ROOT/include ROOT/src, and that they are now ROOT/src/include?

I agree that is a little funny. I don't see a great alternative -- we could support ROOT/include and ROOT/src, but that feels odd since as soon as you added a subdirectory to ROOT/src we would start treating them as independent targets. It might be that single-target C packages are useful enough this is worth supporting, but I'm not sure it is worth complicating the conventions for.

> What if there's more than one folder in the include/ folder? How are modules constructed? I wouldn't want "llvm/" and "llvm-c/" to be put in one module.

Good point, this is something I didn't fully work out. I see a couple options here:

1. The primary use for module maps is for C targets being used in Swift. Those targets are encouraged strongly to support the foo/include/foo/*.h convention. We could restrict ourselves to only generating module maps in those situations, and in other situations requiring the library author to provide them.

The use case for allowing arbitrary headers under include/ was intended more at legacy C targets, or very complicated targets, both of which it is maybe reasonable to write module maps by hand.

2. We could define a policy that automatically creates different module maps based on the immediate subdirectory structure of the include dir. So, for the LLVM example, we could synthesize one module map for each of llvm and llvm-c.

This seems like it would work pretty well in practice, but then raises other special case questions: those modules then need distinct module names, derived from the directory name presumably. That works fine, but what if you have headers in foo/include/*.h *and* foo/include/foo/*.h? We would have to disallow that, or merge those two groups of headers into one module map, another annoying special case.

My temptation is to start with #1 and refine if it appears useful. What do you think?

 - Daniel

> 
> Jordan
> 
> 
>> On Feb 16, 2016, at 18:12, Rick Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Hello Swift community,
>> 
>> A review of “Package Manager C Language Target Support” for the Swift Package Manager begins now and runs through Monday, February 22th. The proposal is available here:
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>> 
>> 	https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>> 
>> 	* What is your evaluation of the proposal?
>> 	* Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
>> 	* Does this proposal fit well with the feel and direction of the Swift Package Manager?
>> 	* If you have you used other package managers with a similar feature, how do you feel that this proposal compares to those?
>> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> 	- Rick
>> 	  Review Manager
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160219/a93bd2ba/attachment.html>