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

[Daniel Dunbar]

> On Feb 25, 2016, at 9:12 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> Oops, review period is over but I guess I should still respond.
> 
>> On Feb 19, 2016, at 8:27 , Daniel Dunbar <daniel_dunbar at apple.com <mailto:daniel_dunbar at apple.com>> wrote:
>> 
>> On Feb 18, 2016, at 1:26 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 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.
> 
> Yeah, that was the concern. I'd expect ROOT/src/include to be private headers and ROOT/include to be public headers. But I agree there's not much to do about it.
> 
>> 
>>> 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?
> 
> I don't actually see how you can do #1 correctly if you were to install the package. (Then again, we don't know how to do top-level headers correctly either if you were to install the package, because we don't know how to add to the /usr/include module map.)
> 
> I think I'd just limit it to "we only generate a module map if you have exactly one subdirectory", and wait to see what feature requests come in, i.e. how people are actually structuring their modules.

Agreed.

I've these changes in this PR:
  https://github.com/apple/swift-evolution/pull/173

 - Daniel

> 
> Jordan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160225/0785e9cc/attachment.html>