[swift-build-dev] Allowing further module organization

[Max Howell]

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