Skip to content

[build support] Generic prefixed binary lookup function in swift_build_support #1586

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

Conversation

harlanhaskins
Copy link
Contributor

What's in this pull request?

A small modification to swift_build_support to allow looking up arbitrary commands like llvm-cov and llvm-profdata alongside clang and clang++.

Resolved bug number: N/A

Will help with SR-237.


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
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
OS X platform @swift-ci Please test OS X platform
Linux platform @swift-ci Please test Linux platform

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

@harlanhaskins harlanhaskins force-pushed the generic-command-lookup branch 2 times, most recently from 951ab5b to 6980ae9 Compare March 8, 2016 23:46
@harlanhaskins harlanhaskins changed the title [build support] Added generic prefixed binary lookup function to swift_build_support [build support] Generic prefixed binary lookup function to swift_build_support Mar 8, 2016
@harlanhaskins harlanhaskins changed the title [build support] Generic prefixed binary lookup function to swift_build_support [build support] Generic prefixed binary lookup function in swift_build_support Mar 8, 2016
@harlanhaskins harlanhaskins force-pushed the generic-command-lookup branch from 6980ae9 to fec3c65 Compare March 9, 2016 00:04
@harlanhaskins
Copy link
Contributor Author

@modocache @gribozavr Thoughts?

@harlanhaskins harlanhaskins force-pushed the generic-command-lookup branch from fec3c65 to 81b6009 Compare March 9, 2016 23:55
@harlanhaskins
Copy link
Contributor Author

Actually, this doesn't take the native llvm/clang tools option into account, regardless. That needs to be addressed.

@harlanhaskins
Copy link
Contributor Author

Any ideas here? The current functions don't take into account NATIVE_[LLVM|CLANG]_TOOLS_PATH, which is pretty important.

Neglecting that, I think this PR is good (and necessary to get coverage working on Linux).

@harlanhaskins harlanhaskins force-pushed the generic-command-lookup branch from 81b6009 to af6f844 Compare March 18, 2016 23:39
@harlanhaskins
Copy link
Contributor Author

@gribozavr How about this?


It requires a 'cc' and 'cxx' tool in its keyword args.
"""
def __init__(self, cc=None, cxx=None, **kwargs):
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry if I'm not picking up on something here, but why provide default arguments for arguments the documentation claims are necessary? If you're looking for the ability to use named arguments like Toolchain(cc="foo", cxx="bar"), you can do that without supplying default arguments in Python.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I figured it was good to express that these arguments are strictly required, though the same could be expressed with

assert(tools.get('cc') is not None)

@modocache
Copy link
Contributor

The commit message claims these changes will allow searching for arbitrary executables besides clang, like llvm-cov. Can you add a test case to prove it?

Modulo comments this looks like a good direction to me! 👍

@harlanhaskins
Copy link
Contributor Author

I can add a test case, but I don't want tests to fail if the tester actually doesn't have the tools installed...

@modocache
Copy link
Contributor

Can we assume that certain tools will always exist on OS X systems? If so you can run them on OS X only, like these are: https://github.com/apple/swift/blob/master/utils/swift_build_support/tests/test_xcrun.py#L18-L20

@harlanhaskins
Copy link
Contributor Author

That's totally doable. IIRC, Xcode includes, at the very least, llvm-profdata, right @gribozavr?

@modocache
Copy link
Contributor

Sure! I also don't think the test has to be for something related to profdata, just something besides Clang that can be found with the new functionality (i.e.: a test that would have failed prior to these changes).

@harlanhaskins
Copy link
Contributor Author

@modocache Thoughts on the extra test?

@modocache
Copy link
Contributor

Looks good to me! @gribozavr could you ask @swift-ci to please test?

@gribozavr
Copy link
Contributor

@swift-ci Please test

@harlanhaskins
Copy link
Contributor Author

Tests pass. @gribozavr Good to merge?

@shahmishal
Copy link
Member

@swift-ci Please python lint

@shahmishal
Copy link
Member

--- Python lint ---
./utils/swift-api-dump.py:98:80: W291 trailing whitespace
./utils/swift-api-dump.py:99:80: E501 line too long (82 > 79 characters)
./utils/swift_build_support/swift_build_support/toolchain.py:2:80: E501 line too long (80 > 79 characters)
./utils/swift_build_support/swift_build_support/toolchain.py:21:1: F401 'collections' imported but unused
./utils/swift_build_support/tests/test_toolchain.py:14:1: I100 Import statements are in the wrong order. import platform

@shahmishal
Copy link
Member

@swift-ci Please python lint

@shahmishal
Copy link
Member

@harlanhaskins Thanks for fixing the python lint errors.

@harlanhaskins
Copy link
Contributor Author

@gribozavr @modocache Think this is good to merge after I rebase?

@gribozavr
Copy link
Contributor

LGTM.

@swift-ci Please test

@harlanhaskins
Copy link
Contributor Author

That test failure is unrelated.

@harlanhaskins harlanhaskins merged commit 55f1bb1 into swiftlang:master Apr 8, 2016
@harlanhaskins harlanhaskins deleted the generic-command-lookup branch April 8, 2016 05:18
@Geforce8472
Copy link

This change seems to leave me unable to build swift on Fedora Linux.

which: no clang-3.8 in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
which: no clang-3.7 in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
which: no clang-3.6 in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
which: no clang-3.5 in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)

./build-script: Can't find clang. Please install clang-3.5 or a later version.
./build-script: command terminated with a non-zero exit status 1, aborting

clang exists in /usr/bin currently version 3.7

return host_toolchain(xcrun_toolchain,
suffixes=['38', '37', '36', '35'])
return host_toolchain(xcrun_toolchain,
suffixes=['-3.8', '-3.7', '-3.6', '-3.5'])
Copy link
Member

Choose a reason for hiding this comment

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

suffixes should contain '', as before

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, you're right. Thanks for catching that! Fixed in master.

@RLovelett
Copy link
Contributor

Unfortunately this PR broke Python 3 support.

$ utils/build-script --release -- --reconfigure
Traceback (most recent call last):
  File "utils/build-script", line 1167, in <module>
    sys.exit(main())
  File "utils/build-script", line 1163, in main
    return main_normal()
  File "utils/build-script", line 1023, in main_normal
    xcrun_toolchain=args.darwin_xcrun_toolchain)
  File "utils/swift_build_support/swift_build_support/toolchain.py", line 124, in host_clang
    suffixes=['-3.8', '-3.7', '-3.6', '-3.5'])
  File "utils/swift_build_support/swift_build_support/toolchain.py", line 101, in host_toolchain
    return _first_common_toolchain(tools, suffixes=suffixes)
  File "utils/swift_build_support/swift_build_support/toolchain.py", line 70, in _first_common_toolchain
    for name, tool in tools.iteritems():
AttributeError: 'dict' object has no attribute 'iteritems'

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.

7 participants