Commit Graph

7 Commits

Author SHA1 Message Date
Artem Chikin
ae2e856f9b Revert "Merge pull request #37114 from apple/revert-36377-NewDriverDefault"
This reverts commit 937e1a365c, reversing
changes made to a5440a8abd.
2021-04-28 15:11:36 -07:00
Artem Chikin
1e44ed00eb Revert "Always build SwiftDriver and use it as default compiler driver" 2021-04-28 11:20:21 -07:00
Artem Chikin
c2dc8e3d07 Always build (and use) the new SwiftDriver as the default compiler driver.
This will make sure that compiler developers are using the new driver when they build the compiler locally and use it.

- Adds a new build-script product category: before_build_script_impl for products we wish to build before the impl products.
- Adds a new EarlySwiftDriver product to that category, which gets built with the host toolchain.
- Adds an escape hatch: --skip-early-swift-driver
- Adjusts the swift CMake configuration with an additional step: swift_create_early_driver_symlinks which (if one was built) creates symlinks in the swift build bin directory to the EarlySwiftDriver swift-driver and swift-help executables.
- Adds a new test subset : only_early_swiftdriver, which will get built into a corresponding CMake test target: check-swift-only_early_swiftdriver-* which runs a small subset of driver-related tests against the Early SwiftDriver.
  - This subset is run always when the compiler itself is tested (--test is specified)
  - With an escape disable-switch: --skip-test-early-swift-driver
  - All tests outside of only_early_swiftdriver are forced to run using the legacy C++ driver (to ensure it gets tested, still).

NOTE: SwiftDriver product (no 'Early') is still the main product used to build the driver for toolchain installation into and for executing the product's own tests. This change does not affect that.
2021-04-26 12:17:32 -07:00
Dario Rexin
bcd6416c89 Revert "[Concurrency] Build C only libdispatch before Swift on non-Darwin pla… (#35738)" (#35789)
This reverts commit 74e59ab77f.
2021-02-05 13:51:39 -08:00
Dario Rexin
74e59ab77f [Concurrency] Build C only libdispatch before Swift on non-Darwin pla… (#35738)
* [Concurrency] Build C only libdispatch before Swift on non-Darwin platforms

_Concurrency depends on libdispatch and since it is not available by
default on non-Darwin platforms, it needs to be built before the Swift
project, so that the dependency can be resolved.

* Fix clibdispatch installation and BuildSystem tests

* Fix build system tests on Darwin and formatting
2021-02-04 17:15:30 -08:00
David Zarzycki
537b103012 [testing] add missing REQUIRES: standalone_build 2020-06-10 05:58:24 -04:00
Michael Gottesman
a313f62522 [build-script] Add option --infer to infer dependencies.
This causes build-script to use the conservative dependency information that I
committed. When one uses this option, it is assumed that one wants to also
install all built products.

Some notes:

1. I included an extra --install-all option so without --infer enabled
   one can enable this sort of install everything that we want to
   build behavior.

2. I added %cmake as a lit variable. I did this so I could specify in
   my build-system unit tests that on Linux they should use the just
   built cmake (if we built cmake due to an old cmake being on the
   system). Otherwise, the build system unit tests took way too
   long. These are meant to be dry-runs, so building this cmake again
   is just wasteful and doesn't make sense.

3. I unified how we handle cmark, llvm, swift with the rest of the
   build products by making them conditional on build_* variables, but
   to preserve current behavior I made it so that they are just
   enabled by default unlike things like
   llbuild/swiftpm/foundation/etc. This was necessary since previously
   we would just pass these flags to build-script-impl and
   build-script didn't know about them. Now I taught build-script
   about them so I can manipulate these skip-build-{cmark,llvm,swift}
   and then just pass them down to build-script-impl if appropriate
   rather than relying on build-script-impl to control if these are
   built.

Once this lands, I think we are at a good enough place with
build-script until we get rid of build-script-impl in terms of high
value QoI that will imnprove productivity. Once build-script-impl is
destroyed, we can start paring back what build-script itself does.
2020-06-09 11:04:43 -07:00