-
Notifications
You must be signed in to change notification settings - Fork 704
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
also install Python bindings for recent Ninja easyconfigs #16025
also install Python bindings for recent Ninja easyconfigs #16025
Conversation
('CMake', '3.20.1'), | ||
('scikit-build', '0.15.0'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also really concerned we are building in some circular dependency hell here, the extra (build)dependencies really worries me for a build tool.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ninja already depends on Python
, and scikit-build
sits directly on top of Python, so I don't see room for introducing a circular dependency?
} | ||
|
||
exts_list = [ | ||
('ninja', '1.10.2.3', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as i could tell pypi "sources" aren't actually new code compared to the Ninja source tarball itself, just structured different + perhaps some autogenerated stuff (i think?), but, this approach worries me in 2 ways;
- these version don't match with the easyconfig version, i think we should definitely do that
- the python package also installs the bin/ninja binary (i think, at least, pip install ninja installs a bin/ninja). So i guess this is overwriting the one we just built?
so, perhaps we could opt to just use the pypi source? or, if possible, generate the python package from the original source?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no 1.10.1.x versions of scikit-build, so can't "match" with Ninja 1.10.1...
I should look into the bin/ninja
part, that may be a problem I overlooked indeed.
The sources for the ninja
Python package are in https://github.com/scikit-build/ninja-python-distributions .
That mentions that the wheels include an actual ninja
binary, but I'm not sure that's also the case when building from source...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the bin/ninja
that comes with the Python package is a light wrapper on top of the actual ninja
binary (it's equivalent to the ninja
function in https://github.com/scikit-build/ninja-python-distributions/blob/master/src/ninja/__init__.py)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sources for the ninja Python package are in https://github.com/scikit-build/ninja-python-distributions .
That mentions that the wheels include an actual ninja binary, but I'm not sure that's also the case when building from source...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the
bin/ninja
that comes with the Python package is a light wrapper on top of the actualninja
binary (it's equivalent to theninja
function in https://github.com/scikit-build/ninja-python-distributions/blob/master/src/ninja/__init__.py)
hm, it seems there are two ninja
s (?) https://github.com/scikit-build/ninja-python-distributions/blob/450d8bb0dc375a536ee2a12eacca0d263dae3be2/CMakeLists.txt#L155-L156
Test report by @boegel |
Also installing the
|
(created using
eb --new-pr
)requires: