[swift-build-dev] Allowing further module organization

[Drew Crawford]

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

To follow up on this point, I currently have a library that lives in a *git* submodule.  Since git, it must live in its own folder.

Now, you may say: obviously, this should be a separate swift module! After all I call it a "library", store it in a separate folder, and even track it in its own repository.  Making it a module would promote good architecture, strong organizational principles, separation of concerns, [insert your favorite code hygiene argument here], case closed, right?

Plot twist: it's a copy protection library.  It is a hard requirement that the library be as tightly integrated with the code it is protecting as is possible  (e.g. linked into the same target).  A dylib where somebody can swap it out defeats the purpose.

None of this is presently contemplated by SwiftPM's filesystem-based builds.  Is this problem a corner case?  Maybe?  But it is a "corner case" that affects probably half the closed projects I work on.  So half the closed codebases I work on can never be packaged with SwiftPM, by design.

I empathize with the desire to "tighten the rules" in response to complexity.  But realistically, I'm not going to look at SwiftPM's rules and decide, shrug, I guess I don't need copy protection anymore.  I will decide I don't need SwiftPM instead.

That really worries me.