Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use the toolchain's clang when building libdispatch #2951

Merged
merged 1 commit into from Jun 21, 2016
Merged

use the toolchain's clang when building libdispatch #2951

merged 1 commit into from Jun 21, 2016

Conversation

dgrove-oss
Copy link
Contributor

@dgrove-oss dgrove-oss commented Jun 8, 2016

What's in this pull request?

As discussed offline with @MadCoder, we now want to be sure that we are using the clang from the toolchain that is being built to compile libdispatch. This pull request changes the invocation of libdispatch's configure script from build-script-impl to pass down the location of clang in the CC and CXX environment variables.

Resolved bug number: (SR-)

None.


Before merging this pull request to apple/swift repository:

  • Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform Comment
All supported platforms @swift-ci Please smoke test
All supported platforms @swift-ci Please smoke test and merge
OS X platform @swift-ci Please smoke test OS X platform
Linux platform @swift-ci Please smoke test Linux platform

Validation Testing

Platform Comment
All supported platforms @swift-ci Please test
All supported platforms @swift-ci Please test and merge
OS X platform @swift-ci Please test OS X platform
OS X platform @swift-ci Please benchmark
Linux platform @swift-ci Please test Linux platform

Lint Testing

Language Comment
Python @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

Use the clang that is part of the toolchain being built
when building libdispatch to ensure getting the appropriate
version of clang.

Also pass through SWIFTC_BIN to the configure command to
prepare for a cleanup of the libdispatch side of the build process.

Use the clang that is part of the toolchain being built
when building libdispatch to ensure getting the appropriate
version of clang.

Also pass through SWIFTC_BIN to the configure command to
prepare for a cleanup of the libdispatch side of the build process.
call "${LIBDISPATCH_SOURCE_DIR}"/configure --prefix="$(get_host_install_destdir ${host})$(get_host_install_prefix ${host})" --with-swift-toolchain="${SWIFT_BUILD_PATH}"
call env CC="${LLVM_BIN}/clang" CCX="${LLVM_BIN}/clang" SWIFTC="${SWIFTC_BIN}" \
"${LIBDISPATCH_SOURCE_DIR}"/configure --with-swift-toolchain="${SWIFT_BUILD_PATH}" \
--prefix="$(get_host_install_destdir ${host})$(get_host_install_prefix ${host})"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is libdispatch looking for executables in SWIFT_BUILD_PATH (i.e. --with-swift-toolchain) or just the standard library? If executables, it should switch to using $(build_directory ${LOCAL_HOST} swift). I didn't know how this was used when factoring in cross-compiling support, but it seems like something we could fix here if it's not already correct. We might not be able to execute things from SWIFT_BUILD_PATH, but we should set the swift compiler's -resource-dir to $(build_directory ${host} swift)/lib/swift at any rate.

@dgrove-oss
Copy link
Contributor Author

It's looking for the swiftc executable. I'm planning on reworking the libdispatch build so that it will find swiftc from the SWIFTC environment variable instead (like it does CC and CXX), but it will take a couple of steps since first I need to define SWIFTC here, then I need to change the libdispatch configure script to look for the SWIFTC environment variable, then I can get rid of the toolchain argument in build-script-impl

@karwa
Copy link
Contributor

karwa commented Jun 8, 2016

ok, thanks. We'd still need to set the compiler's resource-dir, sdk (sysroot) and toolchain/linker. We don't have anything in the build-script for those last two yet, but resource-dir should be the SWIFT_BUILD_DIR/lib/swift. That will help the native swift compiler find the standard library for whichever target it's building for.

This is actually something we really need to improve for the target libraries (Foundation, XCTest and libdispatch).

@jrose-apple
Copy link
Contributor

I would expect the resource-dir and linker to be inferred correctly for non-cross-compilation, and I think it's okay to get cross-compilation in as a follow-up change.

@gribozavr
Copy link
Collaborator

As discussed offline with @MadCoder, we now want to be sure that we are using the clang from the toolchain that is being built to compile libdispatch.

Sorry, but what is the motivation behind this? The toolchain that we are building does not include clang. It is true that the binary is built by default, but that's only because it would be more work for the build scripts to disable building it. We are not using, testing or shipping the clang binary that we are compiling as a part of the build process.

@dgrove-oss
Copy link
Contributor Author

dgrove-oss commented Jun 9, 2016

The motivation is to get control over the version of clang that is used to compile libdispatch's C sources to avoid having to ifdef around usage of compiler intrinsics and builtins that are available in clang-3.9 but not in earlier versions. Ubuntu 15.10 has clang 3.6 by default; 16.04 has clang 3.8.

Note that a few lines above this change, the same thing is already being done when building Foundation. I understand the point about the built clang not being tested, but if that is a blocking problem for this change, the usage by foundation's build is also an issue.

@gribozavr
Copy link
Collaborator

the usage by foundation's build is also an issue

I think it is.

@jrose-apple
Copy link
Contributor

We already have to use the just-built Clang to build our runtime, right? How is this any different?

@gottesmm
Copy link
Member

gottesmm commented Jun 9, 2016

On Jun 9, 2016, at 9:31 AM, Jordan Rose notifications@github.com wrote:

We already have to use the just-built Clang to build our runtime, right?

By default, we always use the host now. But, when John lands the calling convention stuff, that change will be required.
How is this any different?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #2951 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAee32PxmmbFum8oz48FI5ryk5gkdntQks5qKD_tgaJpZM4IxN1A.

@gribozavr
Copy link
Collaborator

How is this any different?

This change greatly expands the extent to which we will be using the compiler which we are not qualifying.

@jrose-apple
Copy link
Contributor

That seems silly to me. We rely on most of Clang and all of LLVM to compile Swift things. If Clang is busted in pretty much any way, the Swift side will have the same problem.

@parkera
Copy link
Member

parkera commented Jun 20, 2016

We need this change to be merged in order to build libdispatch.

@parkera
Copy link
Member

parkera commented Jun 20, 2016

Although this shouldn't affect current projects, I'm kicking off a test run.

@parkera
Copy link
Member

parkera commented Jun 20, 2016

@swift-ci please test

@dgrove-oss
Copy link
Contributor Author

dgrove-oss commented Jun 21, 2016

I took a quick look at the Linux failure and I can't see how a change to the compiler that is used to build dispatch (which is not used for anything) could cause a swiftpm test to fail. Transient / latent failure?

@parkera
Copy link
Member

parkera commented Jun 21, 2016

Yah that's a different bug. I'm merging this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants