<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 25, 2016, at 9:12 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Oops, review period is over but I guess I should still respond.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 19, 2016, at 8:27 , Daniel Dunbar <<a href="mailto:daniel_dunbar@apple.com" class="">daniel_dunbar@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">On Feb 18, 2016, at 1:26 PM, Jordan Rose via swift-evolution <</span><a href="mailto:swift-evolution@swift.org" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">swift-evolution@swift.org</a><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">> wrote:</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><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 class=""><br class=""></div><div class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;">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 class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;"><br class=""></div><div class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;">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></div></blockquote><div class=""><br class=""></div><div class="">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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><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 class=""><br class=""></div><div class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;">Good point, this is something I didn't fully work out. I see a couple options here:</div><div class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;"><br class=""></div><div class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;">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 class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;"><br class=""></div><div class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;">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 class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;"><br class=""></div><div class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;">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 class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;"><br class=""></div><div class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;">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 class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;"><br class=""></div><div class="" style="color: rgb(34, 34, 34); font-family: arial, sans-serif;">My temptation is to start with #1 and refine if it appears useful. What do you think?</div></div></div></blockquote><br class=""></div><div class="">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.)</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div>Agreed.</div><div><br class=""></div><div>I've these changes in this PR:</div><div> <a href="https://github.com/apple/swift-evolution/pull/173" class="">https://github.com/apple/swift-evolution/pull/173</a></div><div><br class=""></div><div> - Daniel</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Jordan</div><br class=""></div></div></blockquote></div><br class=""></body></html>