[swift-build-dev] Allowing further module organization

[Max Howell]

> 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)?

Yes.

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

I have enjoyed splitting code out into more encapsulated units. This is one example of that.

> 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?

Indeed, my proposal is basically saying: modules should be small. But maybe this is too much.

There seems to be three options:

1. Leave it as is, subfolders of Sources are modules, subfolders of module folders are organizational.
2. What I propose, where empty folders in Sources indicate organizational folders, you can’t have subfolders to make our rules less “surprising”
3. What I propose, where empty folders indicate organizational folders, but you can have subfolders with source files in modules, this could be “surprising” where adding sources to empty folders completely changes the outputs of a build
4. Some setting in Package.swift that can mark folders as organizational

4 seems more like what you think should be done and that would be fine with me if people don’t think saying: modules should be small is acceptable.

Max