[CMake] Get SwiftCore building with the new build system #77403
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This patch gets the LLVM Support object files building.
etcwilde
requested review from
drodriguez,
compnerd,
mikeash,
shahmishal and
justice-adams-apple
|
@swift-ci please smoke test |
|
Linux test failure: |
|
We'll need to update our CMake version |
mikeash
approved these changes
Nov 5, 2024
| # functionality. When building the demangling library, the macro should be set | ||
| # to 0 or 1 to indicate the presence of the crashreporter. | ||
| # When building the runtime library, the existence of the macro indicates the | ||
| # presence of the crashreporter. |
There was a problem hiding this comment.
Can we set it to 1 when enabled and un-set it when disabled? That should work for both.
There was a problem hiding this comment.
As far as I can tell, C/C++ defines it so that if a -DFOO is passed without a value, it's given the value of 1, and #if FOO will see undefined an 0 the same way. We might be able to get away with just setting it. I'll have to compare the symbol lists though.
| @@ -0,0 +1 @@ | |||
| __SIZEOF_POINTER__ | |||
There was a problem hiding this comment.
Should this be gitignored? Looks like PlatformInfo.cmake writes this when it's needed. Or maybe PlatformInfo.cmake doesn't need to write it.
There was a problem hiding this comment.
This file is explicitly used in PlatformInfo.cmake below.
There was a problem hiding this comment.
Right, but it's also created there:
file(WRITE ${CMAKE_BINARY_DIR}/cmake/CompilerChecks/ptr_size "__SIZEOF_POINTER__")
set(size_check_command ${CMAKE_C_COMPILER} -x c -P -E -o - ${CMAKE_BINARY_DIR}/cmake/CompilerChecks/ptr_size)
I'm thinking it should be committed, or written when needed, but probably not both.
There was a problem hiding this comment.
Yeah, this file isn't necessary. Since we have C enabled, I can probably just use CMAKE_SIZEOF_VOID_P and skip this. I was having some issues with it before where it was empty/wrong with older versions of CMake, but it looks like it's behaving correctly now.
drodriguez
reviewed
Nov 6, 2024
compnerd
reviewed
Nov 6, 2024
| @@ -0,0 +1,41 @@ | |||
| # FIXME: Refactor demangling library so that we aren't pulling sources from | |||
There was a problem hiding this comment.
Can we reference a swiftlang/swift issue here?
There was a problem hiding this comment.
I'll add it in a separate PR, but here's the issue: #77462
etcwilde
force-pushed
the
ewilde/stdlib-rebuild-swiftcore
branch
2 times, most recently
from
23f8201 to
02280ba
Compare
|
@swift-ci please test |
compnerd
reviewed
Nov 7, 2024
Getting the runtime libraries building, while also ironing out more of the macro definitions and flags.
Adding stdlib stubs library, which uses gyb and requires knowing about some of the platform info. The stubs library pulls in several headers from the compiler repository. We should probably clean that up, but not right now. I've made a note of it.
This patch hooks up the swiftCore library build and gets it installing. This means that we have library evolution hooked up and vector types. Building it dynamically found that we had duplicate symbols, so fixed the swiftDemanglingCR library. Needed to hook up the availability macros. The flag configuration is for macOS, so we'll need to go through and figure out what it should look like for the other platforms too.
This patch makes it simpler to setup reasonable defaults for a given platform. The standard library has many knobs for configuration purposes. This is great for providing cache files to configure specific builds, but the build system should still generally work if someone runs a minimal CMake invocation against the build without futzing with various options.
Setting `SWIFT_ENABLE_NEW_RUNTIME_BUILD` to `ON` will build and run the new standard library build in addition to using the old build. This is primarily for basic smoke testing at the moment. Once we're confident, we can start running tests against the stdlib built with the new build system. The mechanism will build the stdlib for each of the same platforms that the old build system would build for, but emitting a separate build directory with a separate CMake invocation for each configuration. This will use the just-built compiler if the compiler was not cross-compiled. If the compiler were cross-compiled, it will use the compiler from the toolchain that is known to work on the builder.
Moving the rest of the references to the compiler source directory to
use the `SwiftCore_SWIFTC_SOURCE_DIR` variable instead of
`${PROJECT_SOURCE_DIR}/../../`.
Fixing some of the comments in DefaultSettings.cmake and PlatformInfo.cmake. I haven't added any vendor cache files yet, so the comment doesn't point anywhere. Also fixing the reference to the location of the clang resource headers in PlatformInfo.cmake.
This patch causes the convenient flow to automatically populate the sources into the new runtime directory layout. This is run at build-time so that it repopulates on each build. Since the resync script uses `COPY_IF_DIFFERENT`, only files that change in the main source directory are copied over, so incremental builds should still work. Fixed a small bug in the resync script to ensure that it creates the subdirectories in the right places.
De-duping some of the definitions. We can pass most of the definitions to both the Swift and C/C++ compilers in the same form if we don't assign anything. C/C++ will set the macro value to `1` if there is no `=` as part of the definition, and `#if` recognizes a non-existent macro to be false. With this logic, we can unify some of these.
etcwilde
force-pushed
the
ewilde/stdlib-rebuild-swiftcore
branch
from
02280ba to
dad1ea8
Compare
|
@swift-ci please smoke test |
This patch cleans up the handling of WMO-forcing in the workaround file. `-wmo` is passed in each of the link jobs in the non-CMP0157-enabled configuration to keep it matching the behavior of the CMP0157-enabled builds. This also moves the commentary about num-threads and WMO to the top of the file to make it clearer what is going on. Ideally the file wouldn't have to exist, but it does. The file also contains the target install-name fix that landed in CMake 3.29.8 and CMake 3.30.2, so earlier versions of CMake 3.29 will work with this build as well.
The SwiftCore_SWIFTC_CLANGIMPORTER_RESOURCE_DIR is not being used so I'm deleting it for now. This means we only grab the target info once.
|
@swift-ci please smoke test |
|
@swift-ci please test Linux |
compnerd
approved these changes
Nov 7, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR gets us up to SwiftCore building with the new build system.
I've wired it into the existing build and am enabling building with it in the Linux smoke-tests to keep things going. We are not currently running or installing the built code though.
rdar://139221398