[swift-build-dev] Allowing further module organization

[Tony Allevato]

On Tue, Apr 19, 2016 at 1:53 PM Max Howell <max.howell at apple.com> wrote:

> > +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
>
> I would like this too, (could be implemented as some sort of module
> namespacing instead since with Swift modules the final binary can be
> composed of multiple modules so that part is separate), needs buy in from
> Swift core.
>

> > (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.
>
> Seems like ML is its own package? It’s just you would like a namespace
> feature. I certainly relate to the ugliness of a naming prefix. Especially
> with an underscore.
>

Yes, namespaces would solve a lot of problems here that I've currently been
looking to submodules for. Especially if those namespaces had visibility
specifiers and could be easily imported separately into code that depends
on them (i.e., import MyLibrary.Feature2 in a source file without making
all of MyLibrary visible there).

There may still be some details to work out there—if the user only uses one
small feature from the library, would they have to bring along the entire
framework? As opposed to having each feature in its own module, where they
would only bring along that feature's framework (and any of its
dependencies).



> > 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.
>
> You can organize code in modules with subfolders currently:
>
>     Sources/MyLibrary/A/a.swift
>     Sources/MyLibrary/B/b.swift
>     Sources/MyLibrary/c.swift
>
> Will give you one `MyLibrary` module composed of a, b and c.swift.
>
> Or do I misunderstand?
>

I'll have to try that again. The last time I tried organizing things that
way, I ended up with A and B as separate modules; it may have been an early
version of SwiftPM that didn't support it, or it may have been an error on
my part.


> 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.
>
> Long term we need namespaces or submodules I agree.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160419/aefa2f16/attachment.html>