1. 02 Aug, 2016 1 commit
    • Drew's avatar
      Update to swift preview 3 · e4524c67
      Drew authored
      * We can't use system anymore in preview 3.  This introduces a lot of issues around envrionment variables, which can't be listed in swift :-(.  So we no longer inherit environment variables, we only set the ones we set.
          * We do pass on PWD and PATH, because otherwise that would be terrible
      * Toolchain is now a part of platform config instead of something we pass around by hand.
      * We now detect xcode 7 / 8 depending on whether we're using a toolchain installed to Xcode.app or Xcode-beta.app.  That's still not right, but fuck it.
      e4524c67
  2. 08 Jul, 2016 1 commit
    • Drew's avatar
      Update bootstraps · 245e0e78
      Drew authored
      Add `atbuild bootstrap` task to update all bootstraps
      245e0e78
  3. 21 May, 2016 1 commit
    • Drew's avatar
      Implement configurations · b2ba7bbe
      Drew authored
      This implements, more or less, the scaffolding described in #36.  This commit does not actually make tools behave differently in any configuration (so this is mostly a placebo) but after this, tools can adjust their behavior.
      
      Notable additions/departures from the original proposal include:
      
      * Support for "custom" configurations outside the built-in set
      * The addition of `test` and `bench` as built-in configurations, since 2/2 developers use them
      * Internal API has new "helper" methods for common "tool questions" (should we optimize, are we testing, etc.)  Ideally, custom configurations could indicate their own values for these questions, although that's outside the scope of this patch.
      
      Doc PR to follow.
      b2ba7bbe
  4. 28 Apr, 2016 1 commit
    • Drew's avatar
      Add atbin support · 1c22e037
      Drew authored
      atbin is a proposed binary interchange format for atbuild and the
      broader AT ecosystem.
      
      atbuild has a weakly standardized input format: `build.atpkg`.  But what
      does atbuild, um, actually build?  What's the output format?
      
      There is no weak standard here, or even a convention.  It may build an
      executable, a static library, or a dynamic one, or even a framework; it
      may emit swiftmodule and swiftdoc files, or not.  A modulemap may or may
      not be part of the build products and clients may or may not need it in
      their search paths.
      
      The uncertainty here complicates interoperability.  atpm should download
      binary libraries, but what actually lives in that tarball?  Some random
      dylibs we found in `.atllbuild/products`?
      
      How do we build libraries for "fat" archs (like iOS, with 4 sub-archs)?
      How would we write an `atinstall` tool that installs/updates
      atpm/atbuild (or makes homebrew packages out of them)?
      
      atbin proposes to answer these questions, providing a simple, portable,
      hackable binary interchange format for all platforms and all AT
      projects.
      
      An `atbin` is a folder that ends in `.atbin`.  It contains, at least, a
      `built.atpkg` file.
      
      `built.atpkg` is clojure syntax identical to the more familiar
      `build.atpkg`.  You can include tasks or w/e in there, although why
      would want to, I'm not totally sure (this is Anarchy Tools though,
      knock yourself out.)  However, the important bit is this:
      
      ```clojure
      (package
          :name "foo"
          :payload "libFoo.a"
          :platforms ["ios-x86_64" "ios-i386"]
          :type "static-library"
      )
      ```
      
      (Other fields could also be present, this is not a complete enumeration)
      
      This `.atbin` folder will then contain:
      
      * `libFoo.a`, a fat library for the indicated platforms
      * (optional) a `ios-x86_64.swiftmodule` and `ios-i386.swiftmodule` file
      * (optional) a `ios-x86_64.swiftdoc` and `ios-i386.swiftdoc` file
      * (optional) a `module.modulemap` file
      
      You can, of course, build an `.atbin` by hand from existing binaries you
      found lying around your disk.  And we may eventually ship an `atbin`
      packager for Xcode or SwiftPM projects.
      
      However more practically, we introduce a new tool, `packageatbin`, which
      packages an `atbin` payload from atllbuild.
      
      ```clojure
      :package {
         :tool "packageatbin"
      
         ;; Generate a mypayload.atbin
         :name "mypayload"
      
         ;; When used with the new --platform ios, will build a fat binary for all iOS platforms.
         ;; Alternatively specific platforms can be listed here
         :platforms ["all"]
      
         ;; The atllbuild task to package.
         ;; Special logic will re-run this task for each platform and merge the resulting output.
         :atllbuild-task "myatllbuildtask"
      }
      ```
      
      The obvious application is as an interchange format for prebuilt
      `atllbuild` dependencies.  Presently, `atllbuild` can link with the
      output of any dependent atllbuild task, but if a library wasn't produced
      by a dependent task as part of the current build (but was say produced
      on a different computer a month ago) there's no "obvious" way to link to
      it.  This PR does not actually include any of that tooling, but it would
      be a straightforward extension of this work.
      
      An second application is the building of fat files.  Currently, there is
      no mechanism to build a "fat" library or binary in atbuild, or even to
      specify that we want one.  Under this PR, we can do it.
      
      A third application is a distribution format for executables.  If an
      `.atbin` contains an `executable`, `atpm` (or hypothetical `atinstall`)
      could install/update/administrate that executable similar to `homebrew`
      or `apt`, and keep all your buildtools (or other random crap) up to
      date.  We would need to extend this with version fields and whatnot, but
      again, it's straightforward.
      
      An fourth application, and my real motivation, is as an intermediate
      binary representation.  An `atbin` can be "downcast" with another tool
      to a platform-native format like `deb`, `bottle`, or `Framework`.  This
      would allow us to cut debs, rpms, and framework releases with
      appropriate AT tools.
      
      One alternative is to adopt an existing "standard", like Framework, for
      this purpose.  Indeed, `atbuild` currently produces frameworks on OSX.
      
      There are some complexities of extending frameworks to this case.  For
      one, the Framework implementation is warty and involves a lot of
      symlinks and things like codesigning.  We don't currently maintain that
      code for Linux hosts, nor is the standard especially sensible for Linux,
      as it relies on plists and choices basically unpopular on that platform.
      
      For another, frameworks are not really built to house static library or
      executable payloads, which are important to atbuild.  There are air-
      quote "obvious" ways to extend to nontraditional payloads, but IMO this
      is more confusing than it is helpful.  An explicit step to "cast down"
      your atbin to a framework lets us check that your framework will
      actually make sense to the likes of Xcode.
      
      For a third, it's unclear what platform some random Framework is built
      for, and what architectures it supports.  You can find out by scripting
      out to platform-specific tools, but it's not portable.
      
      Another alternative is to support multiple payloads/libraries in a
      single atbin, "one atbin to rule them all".  However I don't see what we
      accomplish there that we don't accomplish with multiple atbins, except
      specification complexity.  So let's not do that, at least not initially.
      
      `packageatbin` is included in core primarily because it needs tight,
      source-level integration with atllbuild.  In addition to peeking at the
      atllbuild options it needs to run the atllbuild task several times in
      order to produce fat binaries, which means it has to work around the
      usual dependency pruning logic.  For that reason it can't be sensibly
      implemented via the current custom tool API.
      1c22e037
  5. 25 Apr, 2016 1 commit
  6. 24 Apr, 2016 4 commits
  7. 22 Apr, 2016 2 commits
  8. 21 Apr, 2016 1 commit
    • 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
  9. 19 Apr, 2016 1 commit
    • 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
  10. 07 Apr, 2016 3 commits
    • Drew's avatar
      Implement packageFramework, a framework packaging tool · c449e5c3
      Drew authored
      This allows Mac frameworks to be built directly from atbuild.
      c449e5c3
    • Drew's avatar
      Allow variable expansion for shell tool · 409cc69b
      Drew authored
      This allows the execution of a shell tool with the "collected sources"
      of another task.
      
      The intent here is to allow the creation of arbitrary tasks that accept
      source files as arguments. xcode-emit is an obvious candidate, and
      would allow it to break its dependence on atpkg, which it only uses for
      this single feature.
      
      There are other obvious programs that we might want to call with "all
      sources" (e.g. preprocessors, etc.) and they may not want to take a
      dependency on atpkg either.
      
      See https://github.com/AnarchyTools/atpkg/pull/23
      409cc69b
    • Drew's avatar
      Update to atpkg/master · ac691a13
      Drew authored
      Bootstrap
      ac691a13
  11. 09 Feb, 2016 1 commit
  12. 02 Feb, 2016 1 commit
    • Drew's avatar
      Update atpkg · 7b3eccc4
      Drew authored
      We need a new bootstrap as well
      7b3eccc4
  13. 18 Jan, 2016 1 commit
  14. 17 Jan, 2016 5 commits
    • Drew's avatar
      Update OSX bootstrap phase · 9b8fccd9
      Drew authored
      9b8fccd9
    • 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
      Linux-based bootstrap · f387c817
      Drew authored
      f387c817
    • 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
  15. 16 Jan, 2016 6 commits
    • Drew's avatar
      Restore bootstrap behavior · d3d3ff34
      Drew authored
      d3d3ff34
    • Drew's avatar
      Manually unbricking the build · 284531fc
      Drew authored
      284531fc
    • Drew's avatar
      Bootstrap script should stop on error · 4358d16b
      Drew authored
      Sadly, this has been masking build breakages for awhile
      4358d16b
    • Drew's avatar
      Preliminary configuration support · 2292f34f
      Drew authored
      Close #2
      2292f34f
    • Drew's avatar
      Restore bootstrap · 932df14e
      Drew authored
      Okay, I understand the desire to do this, but we can't.  Not yet.  Open
      an issue.
      
      The behavior we need is that we don't have to manually muck around with
      the bootstrap files when we organize the repository.  We can actually
      generate them from a (working) atbuild, check them into source control,
      and then bootstrap can use them without any atbuild installed.
      
      The catch is, they need to talk to the .atllbuild directory, not some
      other .bootstrap directory.
      
      To get the latter behavior, open an issue and I can add support for this
      in atllbuild.
      
      This commit restores the behavior where we can generate the bootstrap
      files from a working atbuild again, so we don't have to edit them by
      hand.
      932df14e
    • David Owens II's avatar
      Significant refactoring to support the new atpkg format. · 0476fc3c
      David Owens II authored
      The bootstrap scripts were also updated to build the entire product properly into libs; no more compiler flags.
      Project structure simplified to at* for each of our targets.
      The YAML parser completely removed.
      0476fc3c