1. 13 Nov, 2016 3 commits
  2. 03 Nov, 2016 4 commits
  3. 23 Oct, 2016 2 commits
  4. 09 Sep, 2016 3 commits
    • Drew's avatar
      Bump version to 1.7.0 · 305e2646
      Drew authored
      305e2646
    • Drew's avatar
      Merge pull request #119 from AnarchyTools/xcode8_gm · 1d9a69c4
      Drew authored
      Support Xcode 8 GM
      1d9a69c4
    • Drew's avatar
      Support Xcode 8 GM · a4d211ee
      Drew authored
      * Drop test coverage for Xcode 7 since it's likely not installed
      * We now pull paths from xcode-select when we don't specify a toolchain which is saner than using hardcoded paths
      * We now more robustly test if a given toolchain is from xcode 7 or not rather than rely on the filename
      * Bootstrap for Xcode 8 installed to Xcode.app
      a4d211ee
  5. 29 Aug, 2016 8 commits
  6. 28 Aug, 2016 1 commit
  7. 18 Aug, 2016 1 commit
  8. 14 Aug, 2016 1 commit
  9. 08 Aug, 2016 1 commit
  10. 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
  11. 15 Jul, 2016 2 commits
  12. 08 Jul, 2016 7 commits
    • Drew's avatar
      Add support for C language to atllbuild · e2fa4f07
      Drew authored
      This PR lets you mix .swift, .h, and .c files all in the same atllbuild task.  It works a lot like Xcode's behavior, if you've used that.
      
      \# Rationale
      
      I feel the need to defend this feature, since I have been previously on the record as saying "the entire value is debatable" (https://www.mail-archive.com/swift-evolution@swift.org/msg01829.html).
      
      There are 5 cases where I think it makes sense to add a little C to your Swift project:
      
      * To use the odd feature Swift doesn't support.  Recently, I needed to call a variadic C function; Swift cannot call them, C is our only hope
      * To work around a Swift compiler bug.  Several of my projects have this case.
      * To repackage an existing Xcode project where somebody used C in it.  I have not investigated and don't want to investigate whether that somebody was sane or insane, but we should at least be able to build their project.
      * To include headers from a system C library.  SwiftPM tries to solve this with module maps, however it doesn't hide the implementation details https://bugs.swift.org/browse/SR-655.  This feature can actually hide them with a few different methods discussed below, which is a clear win.
      * To write Swift bindings for a C library.  This generally involves a little C glue code (such as using a header or something), and for reasons that will become clear, using our C support is better than previous approaches at that problem.
      
      \# Rationale-NOT:
      
      Additional rationale:
      
      * SwiftPM will probably add this eventually
      * per #113, we should be a superset of their functionality
      
      I would like to be very clear about my goals:
      
      * This is really only designed for the case of "need a little C in your Swift project", not anything larger
      * This is not a replacement for e.g. GNU Make or a general-purpose C buildsystem, nor will it become one
      * The preferred mechanism for building a real C library is shelling out to your real C buildsystem
      * Nobody should be repackaging their established C libraries as atllbuild tasks.  atllbuild is designed to build Swift projects, not C projects.
      
      \# Design
      
      * You can now specify `.c` and `.h` files in the sources for atllbuild tasks
          * Also `**.c` and `**.h` just like `**.swift`
          * Like `.swift`, no files are scanned by default, everything is explicit
      * Adding `.c` files causes them to be compiled and linked into the atllbuild task just like swift files
      * Adding `.h` files exposes declarations to Swift.  It works much like a bridging header; put stuff in header files and then Swift code will see it.
          * Your `.h`s can import other `.h`s (from the system, or anywhere else) and you otherwise have access to the complete C preprocessor
      * New atllbuild setting `c-compile-options` specifies compile options for C files.  `compile-options` is ignored for C.
      * C files work as you'd expect, including support for things like configurations, optimization, atbuild preprocessor macros, etc.
      
      \# Linking
      
      The standard `link-options` sets link options for both C and Swift; since they are linked into the same library there is no individual control.  So if you want to link your C (and Swift) code against curl, you could say `:link-options ["-lcurl"]` for example.
      
      The problem with this approach is that everybody who depends on you might also need `-lcurl`.  Traditionally we've solved this with overlays that we expose to callers.
      
      SwiftPM avoids this problem by requiring everyone to create e.g. `CCurl` everywhere: https://github.com/apple/swift-package-manager/blob/master/Documentation/SystemModules.md
      
      And in fact people do: https://github.com/IBM-Swift/CCurl
      
      The problem is now you have to import `CCurl` everywhere (even in files that don't directly use it).  See generally, https://bugs.swift.org/browse/SR-655, https://gist.github.com/briancroom/5d0f1b966fa9ef0ae4950e97f9d76f77
      
      Here is the cool part though.  This PR adds a new option `:module-map-link ["curl"]`.  That will inject a link directive into both the module map we use at buildtime and the one we export e.g. into an atbin.
      
      Emitting that link directive has the effect of injecting `:link-options ["-lcurl"]`.  However, it will *also* inject that link option into any Swift module that imports this one.  The result is that downstream no longer needs to add `:link-options ["-lcurl"]` anymore.
      
      Additonally, since we achieve this in a single module, there is no `CCurl` to import anymore.  The details of linking to the C library are more effectively hidden.
      
      For these reasons, I believe using the C support in this PR is way more effective for writing bindings than any other solution.
      
      \# Known issues
      
      * Using `.h` in `sources` requires a synthesized module map
      * Using `.c` in `sources` is not supported for bitcode
      * Using `module-map-link` requires the module map to be distributed for the link to take effect on downstream; we recommend `packageatbin` for packing build products
      * Currently, swift functions are not "visible" to C code (like they are visible to ObjC from Xcode) although presumably if you had a function, knew its calling convention, and knew its c-name, you could totally call it from C.
      e2fa4f07
    • Drew's avatar
      Use buildbase · db6b092c
      Drew authored
      db6b092c
    • Drew's avatar
      Supress "unknown option module-map" · 8b4959e3
      Drew authored
      8b4959e3
    • Drew's avatar
      Update bootstraps · 245e0e78
      Drew authored
      Add `atbuild bootstrap` task to update all bootstraps
      245e0e78
    • Drew's avatar
      Fix Xcode 8 beta 2 · d1b8e7d1
      Drew authored
      d1b8e7d1
    • Drew's avatar
      link-with => link-with-product · 5cfa21c5
      Drew authored
      5cfa21c5
    • Drew's avatar
      Update atpkg: · cd8f98bc
      Drew authored
      * bugfix related to automatically importing an external dependency with SSH-based URL
      * link-with => link-with-products
      cd8f98bc
  13. 01 Jul, 2016 2 commits
  14. 30 Jun, 2016 4 commits
    • Drew's avatar
      Merge pull request #109 from AnarchyTools/swiftc-path · dc20b2ad
      Drew authored
      Remove atllbuild option swiftc-path
      dc20b2ad
    • Drew's avatar
      Un-deprecate WMO setting · 3c62219a
      Drew authored
      We can't enable WMO for Release on Linux yet, see https://github.com/AnarchyTools/atbuild/issues/110
      3c62219a
    • Drew's avatar
      Add actual effects to the configurations · 8f797026
      Drew authored
      This extends #104 by adding actual effects to the configurations rather than have them be no-ops.
      
      Effects include:
      
      * debug instrumentation (new in this PR), for emitting `-g` (see #73 for an obvious extension)
      * optimization control / WMO control
      * compression level (faster debug atbins)
      * test instrumentation (`-enable-testing`)
      * `#if ATBUILD_RELEASE` etc. from Swift code
      
      There are some deprecations associated with this PR:
      
      * `whole-module-optimization` atllbuild option is now deprecated; use `--configuration release` instead.  There currently is no plan to control these separately, use `--configuration plain` + `:compileOptions ["-O"]` to get optimization without WMO.  Or open a bug to complain about this change.
      * `magic` atllbuild option is now deprecated; to opt out of magic use `--configuration none` instead.
      
      Doc PR to follow.
      
      In addition, CI is now updated to produce release (optimized) builds for atbuild, which significantly optimizes atbuild performance.
      8f797026
    • Drew's avatar
      Remove atllbuild option swiftc-path · 3798f21b
      Drew authored
      This option was deprecated in atbuild 0.9.0.  Use `--toolchain` on the CLI instead.
      
      Users should have had enough time to migrate at this point.
      3798f21b