Skip to content

Add an option to specify the install prefix for CoreFoundation depend… #106

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

Merged
merged 1 commit into from
May 16, 2016

Conversation

bryanpkc
Copy link
Contributor

…encies.

Currently, swift-corelibs-xctest will fail to build if build-script option --install-prefix is set to use a location other than /usr. This is because build_script.py assumes that the CoreFoundation libraries can always be found under $foundation_build_dir/usr/lib/swift. This patch adds a new option to the Python script, to allow the top-level build-script to pass the correct prefix to the swift-corelibs-xctest build.

@briancroom
Copy link
Contributor

Cool, this seems to make sense. I find it a little strange that the installation prefix affects the layout of Foundation's build products directory, but I see that it does indeed work that way.

Could you rebase this please? Sorry, I merged another PR which also had build script changes.

"--foundation-install-prefix",
help="Path to the installation location for swift-corelibs-foundation "
"build products; CoreFoundation dependencies are expected to be "
"found under $foundation_build_dir/$foundation_install_prefix.",
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it'd be nice to include in the description what the default value is. For example, the --lit argument does this: "'%(default)s' by default.".

@bryanpkc bryanpkc force-pushed the core-foundation-prefix branch from a217df7 to 36b2ef3 Compare May 11, 2016 18:22
@bryanpkc
Copy link
Contributor Author

@briancroom Thanks, I have rebased the patch.

@modocache Thank you for the suggestion. I have updated the help message to make it indicate the default value and look more consistent with the other messages.

@briancroom
Copy link
Contributor

@swift-ci please test

@briancroom
Copy link
Contributor

CI seems unwilling to accept a request from me for this PR for whatever reason. The changes LGTM, but I'm unable to try it out myself right now and don't want to hit merge without seeing it actually execute. I'll try to give it a go tomorrow unless @modocache or someone else do so first.

@modocache
Copy link
Contributor

@swift-ci please test

@modocache
Copy link
Contributor

Swift CI appears to be a very fickle creature. It was listening to me just two hours ago...

@modocache
Copy link
Contributor

@swift-ci please test

@modocache
Copy link
Contributor

So strange! It listened to me just a minute ago. @shahmishal, do you have any idea why @swift-ci is choosing when to obey orders?

inline_space_odyssey

Seriously, though, perhaps it has something to do with who submitted the pull request? I've noticed "@swift-ci please test" works for my own pull requests, but not this one.

@bryanpkc
Copy link
Contributor Author

Maybe it has to do with the repo being owned by an organization rather than a personal account? If that's the case, I can move the branch to a personal repo. But that would be sad because I have a bunch of other pull requests in the same boat.

@briancroom
Copy link
Contributor

Ok this checks out locally for me. I'm going to pull the trigger on it now.

@briancroom briancroom merged commit 2ce4b57 into swiftlang:master May 16, 2016
@modocache
Copy link
Contributor

Great, thanks!

I only just noticed this is related to the swiftlang/swift#2541. Great work!! 💯

@bryanpkc
Copy link
Contributor Author

Thanks @briancroom!

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.

3 participants