Open awvwgk opened 2 years ago
I think the answer is: no.
The wrapper requires its own source files that are present in the repository. It is thus required to have these sources when building the wrapper. This means all source files of the entire project exist at the build time of the wrapper. We have not added a mechanism to build just the wrapper from "new" sources, while using an "old" installation for the libraries/executable.
I think this is what what you are asking for, right?
For some context, I'm trying to build Python bindings with multiple versions of Python and want to reduce the overhead from compiling the C++ part over and over again. Having just the C++ library installed first and than compile the Python bindings for several Python versions against the "old" library would be very useful.
Ohh. then this may be all you need:
cmake -DSCINE_BUILD_PYTHON_BINDINGS=ON -DPYTHON_EXECUTABLE=/usr/bin/python3.9 ..
make install
cmake -DSCINE_BUILD_PYTHON_BINDINGS=ON -DPYTHON_EXECUTABLE=/usr/bin/python3.8 ..
make install
...
You should be able to just reconfigure cmake, not needing to rebuild the other targets. (I have not tested this, but it may work.)
This still has the overhead of installing the main library every time, but it hopefully builds it only once.
I think I could solve this by introducing a new switch to skip the build of the library
scine/utilities
scine/sparrow
I have tested the above codes, both versions, yours and mine work.
While I understand the usage of your flag in the use case that you describe I am unsure if it is clean to just add it.
The ImportXYZ
statements are not versioned, as in, they return any version there is on the system.
I think for this behavior it would be best if there was a tight version check, making sure that the wrapper actually does what it is intended to do.
For now this issue will stay open, I have not staged that patch for the next release.
I'm currently using this setup to build the Python bindings for scine/utilities
in https://github.com/conda-forge/staged-recipes/pull/18482. The version is currently only pinned to an upper bound using the major version as constraint, but I can make the version pin exact if this is preferred.
To clarify:
I was talking about the import in your patch.
if(NOT SCINE_SKIP_LIBRARY)
[...]
else()
include(ImportSparrow)
import_sparrow()
endif()
with this it is possible to have version 3.0.0 installed on a system, but to try and build the version 4.0.0 bindings against it. This is something that I think is unclean.
If you generate the same possible problem in the conda dependency resolution, then yes I would advise to fix the wrapper version to be the same as the library version.
I made the version constraint exact to ensure it always matches inside the conda build and environment. This should ensure my little hack for splitting the C++ and Python part of the library will be compatible.
Is there a possibility to build the Python bindings against an existing installation of sparrow?