<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Feb 18, 2016, at 1:26 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="">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.<br class=""></div></div></blockquote><div><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class="">I agree, I will amend the proposal to add this.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">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.<br class=""></div></div></blockquote><div><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class="">Agreed.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">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.<br class=""></div></div></blockquote><div><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class="">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?</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class=""><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class="">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.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">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.<br class=""></div></div></blockquote><div><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class="">Good point, this is something I didn't fully work out. I see a couple options here:</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class=""><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class="">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.</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class=""><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class="">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.</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class=""><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class="">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.</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class=""><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class="">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.</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class=""><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class="">My temptation is to start with #1 and refine if it appears useful. What do you think?</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class=""><br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif;" class=""> - Daniel</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class="">Jordan<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Feb 16, 2016, at 18:12, Rick Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hello Swift community,<br class=""><br class="">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:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md</a><br class=""><br class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class="">or, if you would like to keep your feedback private, directly to the review manager.<br class=""><br class="">What goes into a review?<br class=""><br class="">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:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* What is your evaluation of the proposal?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Does this proposal fit well with the feel and direction of the Swift Package Manager?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* If you have you used other package managers with a similar feature, how do you feel that this proposal compares to those?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""><br class="">More information about the Swift evolution process is available at<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://github.com/apple/swift-evolution/blob/master/process.md<br class=""><br class="">Thank you,<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Rick<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> Review Manager<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>