<div dir="ltr">+1 to Daniel's last comment. My biggest issue with SwiftPM usability right now is the lack of two related things:<br><div><br></div><div>(1) Pure Swift submodules</div><div>(2) Inability to organize source files in any way other than module membership</div><div><br></div><div>I'm working on a library that is more of a suite of related-but-also-separable feature sets. In a hypothetical pure Swift submodule world, I could make each feature a submodule of the main library: MyLibrary.Feature1, MyLibrary.Feature2, etc., and express any dependencies between them (maybe ML.Feature3 depends on ML.Feature2). Without that, the closest thing I can achieve is to make each one its own module, using underscore delimited names like MyLibrary_Feature1, which is unappealing.</div><div><br></div><div>So, to avoid those issues, I resigned to making the entire library one module, but then I have to merge all of the source files across all features into a single folder. Xcode groups make this manageable in the IDE, but my flattened source control view is much harder to manage.</div><div><br></div><div>In my particular use case, I believe pure Swift submodules would be a better answer, but I imagine that there are others who would rather be able to use folders for file organization only within the same module and providing a choice to users to make both possible would increase the complexity of the manifest and the PM implementation.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 19, 2016 at 12:53 PM Daniel Dunbar via swift-build-dev <<a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Just to make sure I understand, the idea here is that<div><br></div><div><br></div><div>- Sources</div><div>- Sources/A</div><div>- Sources/A/B</div><div>- Sources/A/C</div><div><br></div><div>produces two modules, B & C, because A has no sources in it directly (following the convention for Sources/ itself)?</div><div><br></div><div>Following the SwiftPM example, why do you want BuildNode and BuildDescription to be separate modules?</div><div><br></div><div>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><div style="word-wrap:break-word"><div><br></div><div> - Daniel</div></div><div style="word-wrap:break-word"><div><br><div><blockquote type="cite"><div>On Apr 19, 2016, at 12:42 PM, Max Howell via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word">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><br></div><div><div>- Sources</div><div> - Build</div></div><div><br></div><div>Build is a module, but really I’d like:</div><div><br></div><div>- Sources</div><div> - Build</div><div> - BuildNode</div><div> - BuildDescription</div><div><br></div><div>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><br></div><div>I’d like to propose some method to allow further organization, but without ruining our existing rules.</div><div><br></div><div>I’d also like to propose tightening up our rules a little.</div><div><br></div><div>—————————</div><div><br></div><div>One clear way to accomplish the first goal is to extend the rules and say empty folders are not considered modules.</div><div><br></div><div>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><br></div><div>For example:</div><div><br></div><div>- Foo</div><div><div> - Sources</div><div> - Bar</div></div><div> - main.swift</div><div><br></div><div>Will build a single executable called `Bar`. However if one accidentally creates a new swift file:</div><div><br></div><div><div>- Foo</div><div><div> - Sources</div><div> - baz.swift</div><div> - Bar</div></div><div> - main.swift</div></div><div><br></div><div>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><br></div><div>To prevent these transformations we could just tighten up our rules.</div><div><br></div><div>If one browses swift packages online there is a clear preference towards a root `Sources` directory.</div><div><br></div><div>Thus I propose we only allow</div><div><br></div><div><ul><li>A Sources directory with sub folders for modules</li><li>A Sources directory with sources directly in the Sources directory and NO sub folders</li></ul><div><br></div></div><div>Any other options become errors.</div><div><br></div><div>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><br></div><div>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><br></div><div>However this prohibits eg:</div><div><br></div><div>- NetEngine/</div><div> - CommonCode.swift</div><div> - HTTP/</div><div> - foo.swift</div><div> - HTTPS/</div><div> - bar.swift</div><div><br></div><div>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><br></div><div>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><br></div><div>Max</div></div>_______________________________________________<br>swift-build-dev mailing list<br><a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
swift-build-dev mailing list<br>
<a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br>
</blockquote></div>