1. 07 Apr, 2016 1 commit
    • 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
  2. 28 Mar, 2016 1 commit
  3. 19 Mar, 2016 1 commit
  4. 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
  5. 06 Feb, 2016 1 commit
    • Drew's avatar
      Mute warnings · b8374eb6
      Drew authored
      Update for atpkg:mute_warnings, which changes the package constructor
      
      We silence certain redundant warnings that are probably useless.
      b8374eb6
  6. 04 Feb, 2016 3 commits
    • 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
      Fix linux build · fa2efa95
      Drew authored
      fa2efa95
    • 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
  7. 02 Feb, 2016 4 commits
    • Drew's avatar
      Warn about invalid package keys · 3320fe4a
      Drew authored
      Merge with atpkg:warn_package
      3320fe4a
    • Drew's avatar
      Add `umbrella-header` to specify umbrella headers · 089ebe8b
      Drew authored
      This is essentially the same as a "bridging" header, except without any
      ObjC (straight C).  Upstream says it "can't be done"; let's see if Linux
      CI likes this implementation.  Take *that*, anonymous compiler engineers.
      
      My motivation for this patch is essentially as a workaround for SR-655.
      
      https://bugs.swift.org/browse/SR-655
      
      That is to say, I want to call some arbitrary C code, but due to that
      bug, I can't hide my C code behind a module / modulemap.
      
      Instead what I can do is just `#include <whatever>` in my umbrella
      header, and then the C imports are available to Swift.
      
      Internally, we emit a modulemap based on the umbrella header and then
      inject some compile flags (notably, `-import-underlying-module`) to make
      it load.  This is the design I reverse-engineered from Xcode.  That
      notwithstanding, it seems to be based entirely on public APIs and I
      guess we'll find out if it works on Linux.
      
      While my motivation is based on C imports, umbrella headers may be
      useful wherever Swift projects are sold.  There are multiple features
      that get unlocked here, including access to the C preprocessor.
      089ebe8b
    • David Owens II's avatar
      d46cecf6
    • Drew's avatar
      Make the "passed successfully" text green. · 0c61b897
      Drew authored
      Our swiftc frontend is typically colored, which draws attention to
      various (expected) compile failures in our test suite.
      
      To fix this, our test suite pass should report green and bold, so I stop
      debugging test failures that aren't failures at all.
      0c61b897
  8. 01 Feb, 2016 4 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
      Allow `-f [file]` to specify a build file · f8e53f6e
      Drew authored
      This allows the building of files other than build.atpkg
      f8e53f6e
    • 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
  9. 27 Jan, 2016 3 commits
  10. 19 Jan, 2016 7 commits
  11. 18 Jan, 2016 2 commits
  12. 14 Jan, 2016 4 commits