[swift-build-dev] More layering changes...

[Daniel Dunbar]

Hi all,

As a heads up, I'm planning on doing some more work on the internal module layering of SwiftPM. The intent is to define a clear conceptual purpose to each of the modules in the layering, so that it is more obvious exactly what the dependencies between modules are, and where new code should go. My current plan is this:

libc, POSIX, Basic, Utility
 - I already sent a mail on the purpose of these, but roughly speaking this is the general "Support" layer.

PackageDescription:
 - This is a special snowflake, it defines the APIs used in the `Package.swift` files and so needs to stay as decoupled as possible

PackageModel (renamed from PackageType):
 - This defines the basic model objects for Packages. The rename is to try and convey the intent more clearly. This module is intended to define "pure" model objects.

PackageLoader
 - This is a new module combining what is currently `Transmute`, the conceptual purpose of which is to take an input Package, apply the convention system and transformations, and output a completed Package (in terms of the same model objects exposed from `PackageModel`).

PackageGraph
 - This is a new module which is intended to export the organized group of packages which together constitute what is needed for the higher level operations. This module will probably export derived data structures on top of the basic model objects, for example target-level dependencies at this point should be fully resolved (and efficiently queryable) and the semantics of the targets should be well defined. This is so that higher level libraries like `Build` or `Xcodeproj` can operate on a model object which describes as fully as possible the semantics of the project.

Build, Xcodeproj
 - These are the "build" implementations we have today.

Tools
 - This is a new high-level module to encapsulate the tooling layers (option parsing, usage, command line diagnostics). We can avoid this if we decide on an implementation of `swift-build` and `swift-test` that just indirects to `swift-package`, in which case this would just be the `swift-package` module for now.

swift-build, swift-test, swift-package
 - These will be thin executables on top of Tools and ultimately everything else, which we will probably move to enclosing in a libSwiftPM DSO, as part of implementing the `swift package` rename proposal.

I'm still sorting out where exactly the (package-level) dependency graph resolution and SCM interactions will all live in this organization, one possibility is that much of that logic lives in its own module, another possibility is that it is built out of much more basic infrastructure and then the high-level plumbing lives at the PackageGraph level.

Feedback welcome!
 - Daniel