Open ax3l opened 6 years ago
Probably. Indeed, it is also the right time to do so as we just updated everything to modern cmake.
xtl 0.4.0 xtensor 0.15.0 (but I would recommend 0.15.1)
Regarding pybind11, we have been conservative about updating it as there has been some breakages between 2.0 and 2.1... We should probably test the latest versions as they come out.
Regarding pybind11
, the upcoming 2.3.0
release looks very promising as well: the descriptions can now fully be build in C++11 mode (previously only in C++14 compiles and otherwise generated at runtime).
Nevertheless, 2.2.2 is only 4 days old, so there might be some time until it gets a version assigned.
@ax3l Just a question about the indirect dependency, if C depends on B that depends on A, don't we have to do find_package(A)
in the CMakeLists.txt of C?
In the case of the xtensor
's stack I thought that we could remove the find_package
because the headers are all in the same directory (that is, %PREFIX%/include); besides, I remember experiencing complaints about headers not found in such a configuration (but that was for another project), that were solved by adding the find_package(A)
. But I migh have missed something in the CmakeLists.txt of B
and A
.
Asked differently, is it possible with cmake to handle transitive dependencies without find_package
for the inderect dependencies, and this whatever the location of the headers is?
Just a question about the indirect dependency, if C depends on B that depends on A, don't we have to do find_package(A) in the CMakeLists.txt of C?
With modern CMake one can finally forget about this and only account for the dependencies one faces directly. This was always especially troublesome for header-only libs, since we as developers had to explain users "you only depend on B but... you don't know that... but B depends on A so you depend on B and A at compile time".
Asked differently, is it possible with cmake to handle transitive dependencies without find_package for the inderect dependencies, and this whatever the location of the headers is?
Yes, that's exactly it. Just expose these indirect dependencies properly as PUBLIC
dependencies to B when "building" and installing B and its config package. and they (A) will be forwarded to any CMake target that will then depend on B.
side note: but in the case of xtensor-python
you don't depend solely indirect on xtl
but also directly on xtl
: https://github.com/QuantStack/xtensor-python/blob/0.17.0/include/xtensor-python/pycontainer.hpp#L34
But xsimd
is such a solely indirect dependency via xtensor
.
@ax3l thank you for the clarification! I agree with you, xtensor-python
directly depends on xtl
, this question was meant to improve my cmake skill ;)
Well, I was just thinking loud as well to verify I got the dependencies right ;)
Hi,
we should improve the way we are currently looking for xtensor-python dependencies:
I think we could add the following:
find_package
callnumpy
is a direct dependency, it's not documented; which version range is known to work?xtl
is not only an indirect dependency ofxtensor
(which would mean we can remove thefind_package
and take automatically addedPUBLIC
dependency of thextensor
dependency) but also a direct dependency used inxtensor-python
code: expose it in the readme with its version range as well