In order to prepare for a migration to CMake 3.15 to enable the use of
the new Swift support, we will add a build of CMake for Linux to ease
the transition. This adds CMake to the checkout on Linux.
This commit is not meant to completely test update-checkout, but rather create
some scaffolding for testing update-checkout so we can create starter bugs to
fill out the rest of the functionality. Once we have enough testing in place, we
can start refactoring/simplifying update-checkout.
Design
------
This is just a standard python unittest test suite except that the tests expect
an environment variable (UPDATECHECKOUT_TEST_WORKSPACE_DIR) to be set that
specifies the directory that the unittests have for creating mock git repos
during setup/teardown. lit invokes the test by calling the unittests with the
environment variable set to the appropriate temporary directory.
In this temporary directory, each test creates a pristine set of "fake" remote
repos and a test-config.json file that can be passed to update-checkout to work
with these "fake" remote repos. This allows each test that we write to test
various update-checkout functionalities against a pristime set of git repos. I
choose the git clone test, just b/c it was really simple.
NOTE: One can also run the tests locally using the script
test_update_checkout.sh that uses /tmp/workspace as the workspace directory.
This enables mocking testing to work (otherwise we would create repos in
SWIFT_SOURCE_ROOT). SWIFT_SOURCE_ROOT is the default value so nothing changes
unless one specifies the argument explicitly.
env is not portable in systems that do not have env, like for example Windows. However, passing the environment is supported by shell.run using the env parameter, which should be portable.
For some reason shell.run doesn't merge the environment with the current environment by default, so we do it externally to not modify other possible usages of the function.
Add a tentative branch config for "swift-5.1-branch". Not all of the repos
are branched yet. I went ahead and added a reference to swift-5.1-branch for
the Swift repo, so that I can use this to start pulling together something
with cherry-picks from master-next. (The current master-next branch has
moved past the point where we branched the LLVM repos for swift-5.1-branch,
so we can't just grab a copy of master-next.) I also added a separate config
for "swift-5.1-old-llvm-branch", which will be used temporarily to track the
same Swift content as swift-5.1-branch but still building with the version
of LLVM in swift-5.0-branch.
- Update --reset-to-remote to support tags.
- Add optional platform entry to a repository. This allows specifying
which platforms a repo should be checked out on.
- Uses version 61.1 from ICU Github unicode-org/icu repository.
- Updates mixin_linux_installation to add libicu option.
- Use -j when building libicu.
- When buiding ICU, use --with-library-suffix=swift
This suffixes the ICU symbols with _swift.
The libaries are now named libicuucswift, libicui18nswift
and libicudataswift.
- Add the contents of uconfig.h.prepend into uconfig.h. This avoids
passing the renaming CFLAGS to swift and swift-corelibs-foundation.
Also resolves:
SR-5618: libicu compilation should happen in parallel respecting -j.
The checkout configs included some old dated branches that are no longer
used. They are unlikely to work well anyway because the corresponding
Clang/LLVM branches moved forward independently. Remove those config entries.
Also re-order the 4.0 and 4.1 configs to be consistent.
This makes update_checkout into a true python module that we can add nosetests
for, readme, and also split up without issue into multiple small files.
I also added a small stub test directory and support for running tests for
update_checkout during validation-testing. So once we add some tests, everything
is setup correctly in terms of the swift build for testing purposes.
