<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="">Just to make sure I understand, the idea here is that<div class=""><br class=""></div><div class=""><br class=""></div><div class="">- Sources</div><div class="">- Sources/A</div><div class="">- Sources/A/B</div><div class="">- Sources/A/C</div><div class=""><br class=""></div><div class="">produces two modules, B & C, because A has no sources in it directly (following the convention for Sources/ itself)?</div><div class=""><br class=""></div><div class="">Following the SwiftPM example, why do you want BuildNode and BuildDescription to be separate modules?</div><div class=""><br class=""></div><div class="">The biggest problem I see here is that modules may mean different things to different people, and they have significant semantic meaning (since they change visibility). If I compare to LLVM, for example, the individual equivalent of a "module" is typically quite large. That leads to occasionally wanting to subdivide the sources of the module into subfolders without changing which module they contribute to, which I think this proposal would require?</div><div class=""><br class=""></div><div class=""> - Daniel</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 19, 2016, at 12:42 PM, Max Howell via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">SwiftPM is a pioneer for SwiftPM, and thus we have many modules. For some of these modules I’d like to split them out even more eg:<div class=""><br class=""></div><div class=""><div class="">- Sources</div><div class=""> - Build</div></div><div class=""><br class=""></div><div class="">Build is a module, but really I’d like:</div><div class=""><br class=""></div><div class="">- Sources</div><div class=""> - Build</div><div class=""> - BuildNode</div><div class=""> - BuildDescription</div><div class=""><br class=""></div><div class="">If I do this currently I still will end up with one module: `Build`, this is how the module layout rules that SwiftPM uses work. But instead I’d like Build to be purely an organizational folder and to get two modules *BuildNode* and *BuildDescription*.</div><div class=""><br class=""></div><div class="">I’d like to propose some method to allow further organization, but without ruining our existing rules.</div><div class=""><br class=""></div><div class="">I’d also like to propose tightening up our rules a little.</div><div class=""><br class=""></div><div class="">—————————</div><div class=""><br class=""></div><div class="">One clear way to accomplish the first goal is to extend the rules and say empty folders are not considered modules.</div><div class=""><br class=""></div><div class="">I am unhappy with this however, already there are easy ways to completely transform the build of a package, and the rules we have are somewhat confusing, one can see this in newcomer questions on StackOverflow.</div><div class=""><br class=""></div><div class="">For example:</div><div class=""><br class=""></div><div class="">- Foo</div><div class=""><div class=""> - Sources</div><div class=""> - Bar</div></div><div class=""> - main.swift</div><div class=""><br class=""></div><div class="">Will build a single executable called `Bar`. However if one accidentally creates a new swift file:</div><div class=""><br class=""></div><div class=""><div class="">- Foo</div><div class=""><div class=""> - Sources</div><div class=""> - baz.swift</div><div class=""> - Bar</div></div><div class=""> - main.swift</div></div><div class=""><br class=""></div><div class="">Then you will get a single executable called baz, or more likely a compile error. Diagnosing this is currently an exercise in frustration (though we could improve this with better diagnostics when compiles fail, eg. we could output the modules structure we inferred).</div><div class=""><br class=""></div><div class="">To prevent these transformations we could just tighten up our rules.</div><div class=""><br class=""></div><div class="">If one browses swift packages online there is a clear preference towards a root `Sources` directory.</div><div class=""><br class=""></div><div class="">Thus I propose we only allow</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">A Sources directory with sub folders for modules</li><li class="">A Sources directory with sources directly in the Sources directory and NO sub folders</li></ul><div class=""><br class=""></div></div><div class="">Any other options become errors.</div><div class=""><br class=""></div><div class="">If we then extend the same rules to modules then there will be no surprising behavior. At first I resisted this idea as folders are for organization, however in the new world of SwiftPM *modules* are for organization.</div><div class=""><br class=""></div><div class="">Modules have internal accessibility modifiers that allow powerful architectural designs. Modules have a defined public interface that maps onto folder organizational practices better than </div><div class=""><br class=""></div><div class="">However this prohibits eg:</div><div class=""><br class=""></div><div class="">- NetEngine/</div><div class=""> - CommonCode.swift</div><div class=""> - HTTP/</div><div class=""> - foo.swift</div><div class=""> - HTTPS/</div><div class=""> - bar.swift</div><div class=""><br class=""></div><div class="">And perhaps thus is overly restrictive. Though my argument is that HTTP and HTTPS would be better off being their own modules: it would encourage true encapsulation and a better code architecture.</div><div class=""><br class=""></div><div class="">I am unsure and thus am opening a discussion here. Certainly there are other ways to accomplish the goals here so please let us know what you think a better solution (or not) would be. Thanks for your time.</div><div class=""><br class=""></div><div class="">Max</div></div>_______________________________________________<br class="">swift-build-dev mailing list<br class=""><a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-build-dev<br class=""></div></blockquote></div><br class=""></div></body></html>