[swift-build-dev] Allowing further module organization

[Tony Allevato]

+1 to Daniel's last comment. My biggest issue with SwiftPM usability right
now is the lack of two related things:

(1) Pure Swift submodules
(2) Inability to organize source files in any way other than module
membership

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.

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.

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.


On Tue, Apr 19, 2016 at 12:53 PM Daniel Dunbar via swift-build-dev <
swift-build-dev at swift.org> wrote:

> 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
>
>
> _______________________________________________
> 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/8f53dfc8/attachment.html>