[swift-build-dev] Allowing further module organization

[David Owens II]

> On Apr 20, 2016, at 8:52 AM, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
>> Indeed, my proposal is basically saying: modules should be small. But maybe this is too much.
> 
> I don't think I am comfortable with that assumption, currently.
> 
> In particular, module subdivision and visibility have substantial impact on performance (e.g., whole-module optimization), and performance sensitive clients are likely to want to put critical functionality in the same module even if it may be conceptually encapsulated. Modules are also very important for the Swift ABI resiliency model, which will encourage the same behavior.
> 
> Right now, for better or worse, modules are very similar to traditional libraries or frameworks, and not just because that is how we typically build them. It makes sense for a large project to subdivide code into modules along the same boundaries that would be done for those, which is typically fairly large.

I read this proposal as an official way to push micro-frameworks into Swift. I don't know if that's the intention, but if so, I'm strongly against that. Daniel laid out some of the reasons why above.

In general though, I'd like to see proposals for SwiftPM moving towards the direction to allow people to structure their code how they want to or how they need instead of trying to come up with a convention to solve everyone's use cases. 

For example, some of us layout our code like this:

src/
  component/
    subcomponent/
      win32/
      linux/
      droid/
      ios/
      macos/
   ...

For some projects, I only want to ship a single module for `component`. For other projects, I may want to actually ship both `component` and `subcomponent` as separate modules. Just provide me with the tools to tell you what to build.

-David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160420/e953e651/attachment.html>