1. 22 Apr, 2016 3 commits
  2. 15 Apr, 2016 5 commits
    • Drew's avatar
      Replace bad diagnostic · aa38f859
      Drew authored
      Fixes #65
      aa38f859
    • 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
      etc.
      
      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.
      9ecf5b64
    • Drew's avatar
      Don't print stack trace for user-visible subcommand errors · ff977925
      Drew authored
      Per #72, these are not useful
      
      Resolve #72
      ff977925
    • Drew's avatar
      5224abc6
    • Drew's avatar
      Swift 3 renaming is now slightly different · 3bfb43b7
      Drew authored
      3bfb43b7
  3. 14 Apr, 2016 1 commit
  4. 07 Apr, 2016 3 commits
    • Drew's avatar
      Toolchain support · 0c1ba2e6
      Drew authored
      This allows atbuild to use a different toolchain other than the one we
      use to develop atbuild (weekly snapshot).
      
      In particular, this allows you to use "released swift" "xcode swift" or
      any other kind of 2.2 Swift.
      
      Documentation PR to follow.
      
      Edited README to discuss atbuild options.
      
      Resolves #58 to my satisfaction.
      0c1ba2e6
    • Drew's avatar
      Remove print · 87a90096
      Drew authored
      It is a stupid print and it deserves to die
      87a90096
    • Drew's avatar
      Implement packageFramework, a framework packaging tool · c449e5c3
      Drew authored
      This allows Mac frameworks to be built directly from atbuild.
      c449e5c3
  5. 28 Mar, 2016 1 commit
  6. 19 Mar, 2016 1 commit
  7. 04 Mar, 2016 1 commit
    • Drew's avatar
      Support whole-module-optimization · eadeb144
      Drew authored
      Due to SR-881, whole-module-optimization is more complicated than simply
      adding it to compile options.
      
      As a workaround, we compile twice.
      eadeb144
  8. 07 Feb, 2016 1 commit
  9. 06 Feb, 2016 1 commit
  10. 04 Feb, 2016 3 commits
    • Drew's avatar
      Remove unneeded import. · 61e7e2a7
      Drew authored
      This import is no longer required in snapshot
      
      swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a
      
      due to a closed upstream bug I filed.
      61e7e2a7
    • Drew's avatar
      Ignore tool keys when warning from atllbuild · 6c86e64e
      Drew authored
      Previously, atllbuild would emit some spurious warnings when a tool key
      was used such as `overlays`.  We now ignore all tool keys.
      6c86e64e
    • Drew's avatar
      Umbrella headers v2 · 587894a9
      Drew authored
      We now include the synthesized module map in our build products.  To
      support this, a new `:modulemap "synthesized"` directive is available
      (and must be used if `umbrella-header` is used.)  We could potentially
      have other modulemap modes besides synthesized (explicit, for example).
      
      We use one modulemap privately as part of the build process (to store
      the umbrella header) and a different one publicly (which doesn't have
      the umbrella header).
      
      This is (surprisingly!) totally legal under the Clang module map
      specification.
      http://clang.llvm.org/docs/Modules.html#private-module-map-files
      
      > However, in some cases, the presence or absence of particular headers is used to distinguish between the “public” and “private” APIs of a particular library. For example, a library may contain the headers Foo.h and Foo_Private.h, providing public and private APIs, respectively. Additionally, Foo_Private.h may only be available on some versions of library, and absent in others. One cannot easily express this with a single module map file in the library:
      
      ```
      module Foo {
        header "Foo.h"
      
        explicit module Private {
          header "Foo_Private.h"
        }
      }
      ```
      
      > because the header Foo_Private.h won’t always be available. The module
      > map file could be customized based on whether Foo_Private.h is
      > available or not, but doing so requires custom build machinery.
      
      We are the custom build machinery of which the clattner foretold.
      
      Note that (some) Swift engineers claim this is dangerous, but it works,
      is compliant with the Clang specification, and the tests pass.
      
      I should probably also document one other thing that I found diagnosing
      why the previous approach didn't work.  A "swiftmodule" (which nobody
      seems to understand) actually (sometimes) functions as an overlay for a
      Clang module.  See e.g.
      https://github.com/apple/swift/blob/1b2288fa96e4d531956bc690e64616afc2fb3333/include/swift/Serialization/Validation.h#L41
      
      What happen is that if you compile with -import-underlying-module (which
      we do in the umbrella case) the swift module that gets built is a
      "overlay" that points to some underlying clang module, see here:
      https://twitter.com/drewcrawford/status/694995772148846592.  Then at
      import time somebody goes looking for that underlying module (e.g.
      modulemap) in addition to the .swiftmodule.
      
      However there is no reason (as far as Clang is concerned) why the
      modulemap it finds at runtime may not be totally different than the
      modulemap we used at compile time, so that's what we do.
      587894a9
  11. 02 Feb, 2016 6 commits
  12. 01 Feb, 2016 3 commits
    • Drew's avatar
      Add `publishProduct` atllbuild option · 0b8b3339
      Drew authored
      This allows a build.atpkg to export its products into a user-visible directory.
      
      I'm not totally sure this is the right design, but it does resolve #17.
      0b8b3339
    • Drew's avatar
      Add atbuild "user paths". · b1fc7420
      Drew authored
      This patch adds a "user path" which is global to an entire buildchain
      and allows tasks to progressively build up contents that are somewhat
      arbitrary.
      
      In particular, this is useful for AnarchyDispatch.  If we have
      a/b/AnarchyDispatch, then AnarchyDispatch can install itself to the
      ATBUILD_USER_PATH and be visible to both a and b.  Then we can inject
      includeWithUser: ["AnarchyDispatch"] in an overlay and everything "just
      works".
      b1fc7420
    • Drew's avatar
      Update to new API to atpkg · 777f7d08
      Drew authored
      777f7d08
  13. 27 Jan, 2016 1 commit
  14. 19 Jan, 2016 3 commits
  15. 18 Jan, 2016 2 commits
  16. 17 Jan, 2016 3 commits
    • Drew's avatar
      Linux port · 10896a07
      Drew authored
      10896a07
    • Drew's avatar
      Override swiftC from .atpkg · 573176c4
      Drew authored
      We need this to bootstrap a linux build on OSX.
      573176c4
    • Drew's avatar
      Support for importing remote tasks from another file · 7f624456
      Drew authored
      We have to be careful about how these paths work; because when you
      import a new file it is as if your working directory changes.  To
      support this, we add a new `importedPath` property to Task that contains
      the path where the task is imported (whether local or remote).  This
      property is documented to include a trailing slash to avoid various
      problems involving relative paths.
      
      We also fix #20 by moving to `collectSources` implemented in atpkg
      instead of atllbuild.
      7f624456
  17. 16 Jan, 2016 1 commit
  18. 15 Jan, 2016 1 commit