[swift-build-dev] Allowing further module organization

[Daniel Dunbar]

Just to make sure I understand, the idea here is that


- Sources
- Sources/A
- Sources/A/B
- Sources/A/C

produces two modules, B & C, because A has no sources in it directly (following the convention for Sources/ itself)?

Following the SwiftPM example, why do you want BuildNode and BuildDescription to be separate modules?

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?

 - Daniel

> On Apr 19, 2016, at 12:42 PM, Max Howell via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
> 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:
> 
> - Sources
>     - Build
> 
> Build is a module, but really I’d like:
> 
> - Sources
>     - Build
>         - BuildNode
>         - BuildDescription
> 
> 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*.
> 
> I’d like to propose some method to allow further organization, but without ruining our existing rules.
> 
> I’d also like to propose tightening up our rules a little.
> 
> —————————
> 
> One clear way to accomplish the first goal is to extend the rules and say empty folders are not considered modules.
> 
> 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.
> 
> For example:
> 
> - Foo
>     - Sources
>         - Bar
>             - main.swift
> 
> Will build a single executable called `Bar`. However if one accidentally creates a new swift file:
> 
> - Foo
>     - Sources
>         - baz.swift
>         - Bar
>             - main.swift
> 
> 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).
> 
> To prevent these transformations we could just tighten up our rules.
> 
> If one browses swift packages online there is a clear preference towards a root `Sources` directory.
> 
> Thus I propose we only allow
> 
> A Sources directory with sub folders for modules
> A Sources directory with sources directly in the Sources directory and NO sub folders
> 
> Any other options become errors.
> 
> 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.
> 
> Modules have internal accessibility modifiers that allow powerful architectural designs. Modules have a defined public interface that maps onto folder organizational practices better than 
> 
> However this prohibits eg:
> 
> - NetEngine/
>     - CommonCode.swift
>     - HTTP/
>         - foo.swift
>     - HTTPS/
>         - bar.swift
> 
> 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.
> 
> 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.
> 
> Max
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160419/7a74a961/attachment.html>