1. 22 Apr, 2016 7 commits
  2. 21 Apr, 2016 2 commits
    • Drew's avatar
      Merge pull request #84 from AnarchyTools/plugins · dfe27232
      Drew authored
      Add plugin support
      dfe27232
    • Drew's avatar
      Change to `.attool` · 5180ad67
      Drew authored
      @owensd convinced me that `plugin` is the wrong name.  We should call
      @them Custom Tools, with an extension `.attool`.  This emphasizes that
      @they are written for AT and provides something to google.
      5180ad67
  3. 20 Apr, 2016 2 commits
  4. 19 Apr, 2016 3 commits
    • Drew's avatar
      Merge pull request #78 from AnarchyTools/bad-diagnostic · fe2e626a
      Drew authored
      Replace bad diagnostic
      fe2e626a
    • Drew's avatar
      Add plugin support · ecca2810
      Drew authored
      We're supposed to be building simple, hackable tools but atbuild is
      becoming more of a monolithic tool.  This patch aims to change that.
      
      There are many reasons some feature should not be included in core:
      
      1.  Core needs to be minimal so we can bootstrap it on new platforms;
          every new feature is a new burden
      
      2.  Core needs to be x-platform but many features do not
          (see: xcode-emit, packageframework)
      
      3.  Features may want different release frequency (see: xcode-emit) or
          don't want to coordinate with atbuild
      
      4.  Features may be "not part of AnarchyTools" (Caroline) but still
          commonly used together
      
      5.  I'm annoyed at upstream over the static linking issue, and thinking
          of ways to keep us from being that point of central failure that annoys
          somebody else someday
      
      Therefore, we introduce the world's simplest plugin system designed to
      move code out of core, or keep code out of core that doesn't need to be.
      
      xcode-emit and Caroline will consume this API.  packageframework is a
      good candidate for a plugin that might be moved out from core.
      
      Documentation to follow
      ecca2810
    • Drew's avatar
      Merge pull request #80 from AnarchyTools/system-exit · e1a5541d
      Drew authored
      Don't print stack trace for user-visible subcommand errors
      e1a5541d
  5. 18 Apr, 2016 2 commits
  6. 16 Apr, 2016 4 commits
  7. 15 Apr, 2016 12 commits
    • Drew's avatar
      Add NSFileManager again · ad1fb94c
      Drew authored
      ad1fb94c
    • Drew's avatar
      Add NSFileManager again · 1d34f85e
      Drew authored
      1d34f85e
    • Drew's avatar
      Resolve required overlays bug · e6c1b805
      Drew authored
      Resolve #66
      e6c1b805
    • 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
      Bump version 0.9.0 · 5090df20
      Drew authored
      5090df20
    • Drew's avatar
      Merge branch 'swift3-parameter-renaming' · aced9d16
      Drew authored
      Thanks to @dunkelstern for his assistance with this.
      It required a few minor tweaks.
      aced9d16
    • Drew's avatar
    • Drew's avatar
      5224abc6
    • Drew's avatar
      Swift 3 renaming is now slightly different · 3bfb43b7
      Drew authored
      3bfb43b7
    • Drew's avatar
      Update atpkg · b3372a27
      Drew authored
      b3372a27
  8. 14 Apr, 2016 1 commit
  9. 12 Apr, 2016 1 commit
  10. 11 Apr, 2016 2 commits
  11. 09 Apr, 2016 3 commits
  12. 07 Apr, 2016 1 commit
    • 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