• Drew's avatar
    Add proper platform support · 9ecf5b64
    Drew authored
    Related to #36
    Presently, we tend to enable platform-specific config with an overlay.
    There are a variety of problems identified with this approach:
    1.  There is no convention for which overlay to use for platform-
    specific config.  This complicates the ecosystem.
    2.  In general, a program is always compiled "for some platform" but in
    practice a user may forget the necessary overlay.  `require-overlays`
    can catch this misconfig, but A) it has to be opted into in the atpkg,
    and B) there is no good way to default to the running platform, which is
    the sane behavior.
    3.  Currently, tools tend to conditionally-compile platform-specific
    code.  The effect of this is to complicate bootstrapping, as a Linux
    binary *cannot* perform some OSX behavior (and vice versa) because the
    necessary code is not present in the executable.
    4.  This is not scaleable to cross-compilation (iOS for example is
    Coming Soon but can't be supported in this architecture)
    To work around these problems, we introduce a `Platform` enum, to
    replace `PlatformPaths`.  `Platform` is a runtime technology, allowing
    for a Linux binary to reason about what the behavior would be on OSX
    Internally, we have three "platforms":
    * `hostPlatform`, the platform on which `atbuild` is currently executing
    * `targetPlatform`, the platform for which we are compiling. By default
       this is the `hostPlatform`
    * `buildPlatform`, the platform where `swift-build-tool` will run.
       This is usually the `hostPlatform`, but if we are bootstrapping it
       is the `targetPlatform` instead.
    The user can override the `targetPlatform` by the use of `--platform
    foo`.  `linux` and `osx` are supported.  `mac` is supported as an alias
    of `osx`.
    The primary effect of a platform is to scope tool-specific behavior
    (e.g., target=OSX uses the OSX SDK, host=Linux uses a linux path for the
    toolchain, etc).
    In addition to the tool-specific behavior, we enable overlays for the
    target platform:
    * `atbuild.platform.linux` on Linux
    * `atbuild.platform.osx` and `atbuild.platform.mac` on OSX
    This allows packages to reliably perform per-platform configuration in
    the overlays.  Critically, some platform overlay is reliably active, so
    users in most cases will not have to `--use-overlay` to get proper
    platform behavior.
    DEPRECATION WARNING: We believe the `swiftc-path` key is no longer
    required, as the functionality used can be achieved either by
    `--toolchain` or `--platform`.  Therefore, I'm adding a warning to users
    that we intend to remove it and to try these features instead.
    We need to put out a release with these features (and the warning)
    before I'm happy to remove it.  In particular, we use it inside
    atbuild/atpkg, and removing it immediately would break bootstrapping, so
    let's give it a little time before we tear it out.  We should remove it
    from the documentation though.
main.swift 80 Bytes