New python buildsystem #96
Merged
Conversation
This file contains 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
jokva
force-pushed
the
new-python-buildsystem
branch
from
2512cbd to
46dbdc5
Compare
By having this path easily available to parts of the makefiles, which is very useful useful for figuring out dlisio_DIR for build-time exports.
Export the build tree targets (dependencies, dlisio and dlisio-extension). The main motivation is that any language bindings driven by cmake can discover and link against libraries in the build tree. This enables a lot more comfortable development situation, and has little effect on complexity of the makefiles.
jokva
force-pushed
the
new-python-buildsystem
branch
3 times, most recently
from
ef4eac6 to
e5fd587
Compare
Replace the setuptools based build system with scikit-build [1]. Scikit-build is an upstream python-cmake integration package that effectively enables building the extension code with cmake, rather than setuptools. The big problem with setuptools is developer experience, as it's pretty clunky and behaves quite differently from what you would expect with a more sophisticated build system for C++ code. By moving that responsibility to cmake and having skbuild invoke it, the extension code can use all of cmake for defines, compiler flags and even extension specific dependencies, without having to manually do discovery logic and configuration (essentially what cmake already does) in python. The CI definitions have been updated to reflect the changes in behaviour. There is a bug in the current upstream release 0.9.0 that makes appveyor break, but a change [2] is proposed upstream. For now, appveyor uses the jokva/scikit-build fork. For cmake .. && make && make install users, this patch should have little effect, but in all the new build system gives greater opportunity to tune and configure the compilation of the python extension. [1] https://scikit-build.readthedocs.io/en/latest [2] scikit-build/scikit-build#400
jokva
force-pushed
the
new-python-buildsystem
branch
from
e5fd587 to
f17221f
Compare
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.
Replace the setuptools based build system with scikit-build [1].
Scikit-build is an upstream python-cmake integration package that
effectively enables building the extension code with cmake, rather than
setuptools.
The big problem with setuptools is developer experience, as it's pretty
clunky and behaves quite differently from what you would expect with a
more sophisticated build system for C++ code. By moving that
responsibility to cmake and having skbuild invoke it, the extension code
can use all of cmake for defines, compiler flags and even extension
specific dependencies, without having to manually do discovery logic and
configuration (essentially what cmake already does) in python.
The CI definitions have been updated to reflect the changes in
behaviour. There is a bug in the current upstream release 0.9.0 that
makes appveyor break, but a change [2] is proposed upstream. For now,
appveyor uses the jokva/scikit-build fork.
For cmake .. && make && make install users, this patch should have
little effect, but in all the new build system gives greater opportunity
to tune and configure the compilation of the python extension.
[1] https://scikit-build.readthedocs.io/en/latest
[2] scikit-build/scikit-build#400
Closes #46