- 22 Apr, 2016 3 commits
-
-
Johannes Schriewer authored
-
Johannes Schriewer authored
-
Johannes Schriewer authored
-
- 21 Apr, 2016 2 commits
- 20 Apr, 2016 2 commits
- 19 Apr, 2016 3 commits
-
-
Drew authored
Replace bad diagnostic
-
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
-
Drew authored
Don't print stack trace for user-visible subcommand errors
-
- 18 Apr, 2016 2 commits
- 16 Apr, 2016 4 commits
- 15 Apr, 2016 12 commits
-
-
Drew authored
-
Drew authored
-
Drew authored
Resolve #66
-
Drew authored
Fixes #65
-
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
Per #72, these are not useful Resolve #72
-
Drew authored
-
Drew authored
Thanks to @dunkelstern for his assistance with this. It required a few minor tweaks.
-
Drew authored
-
Drew authored
-
Drew authored
-
Drew authored
-
- 14 Apr, 2016 1 commit
-
-
Johannes Schriewer authored
-
- 12 Apr, 2016 1 commit
-
-
Drew authored
Toolchain support
-
- 11 Apr, 2016 2 commits
- 09 Apr, 2016 3 commits
- 07 Apr, 2016 5 commits
-
-
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.
-
Drew authored
It was woefully out of date
-
Drew authored
It is a stupid print and it deserves to die
-
Drew authored
This allows Mac frameworks to be built directly from atbuild.
-
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
-