- 29 Aug, 2016 1 commit
-
-
Drew authored
-
- 18 Aug, 2016 1 commit
-
-
Drew authored
-
- 02 Aug, 2016 1 commit
-
-
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.
-
- 15 Jul, 2016 1 commit
-
-
Drew authored
-
- 01 Jul, 2016 1 commit
-
-
Drew authored
-
- 15 Jun, 2016 1 commit
-
-
Drew authored
-
- 21 May, 2016 1 commit
-
-
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.
-
- 18 May, 2016 1 commit
-
-
Drew authored
-
- 12 May, 2016 1 commit
-
-
Drew authored
-
- 11 May, 2016 1 commit
-
-
Drew authored
-
- 10 May, 2016 1 commit
-
-
Drew authored
-
- 28 Apr, 2016 1 commit
-
-
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.
-
- 26 Apr, 2016 1 commit
-
-
Drew authored
-
- 25 Apr, 2016 2 commits
- 22 Apr, 2016 3 commits
-
-
Johannes Schriewer authored
-
Johannes Schriewer authored
-
Johannes Schriewer authored
-
- 15 Apr, 2016 2 commits
-
-
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. -
Drew authored
-
- 14 Apr, 2016 1 commit
-
-
Johannes Schriewer authored
-
- 07 Apr, 2016 1 commit
-
-
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.
-
- 01 Apr, 2016 1 commit
-
-
Johannes Schriewer authored
-
- 28 Mar, 2016 1 commit
-
-
Drew authored
Update to swift-DEVELOPMENT-SNAPSHOT-2016-03-24-a
-
- 19 Mar, 2016 2 commits
- 04 Mar, 2016 2 commits
- 09 Feb, 2016 1 commit
-
-
Drew authored
-
- 07 Feb, 2016 1 commit
-
-
Drew authored
-
- 06 Feb, 2016 3 commits
- 02 Feb, 2016 3 commits
-
-
Drew authored
-
Drew authored
-
David Owens II authored
-
- 01 Feb, 2016 1 commit
-
-
Drew authored
This allows the building of files other than build.atpkg
-
- 28 Jan, 2016 3 commits