[GitHub] edisongustavo commented on issue #13400: [MXNET-1229] use OpenBLAS, lapack & OpenCV from conan
edisongustavo commented on issue #13400: [MXNET-1229] use OpenBLAS, lapack &
OpenCV from conan
URL: https://github.com/apache/incubator-mxnet/pull/13400#issuecomment-461412755
@SSE4
Thanks a lot for the responses. I believe then we could move forward by
removing this part of the change from the PR:
```
if(EXISTS ${CMAKE_CURRENT_BINARY_DIR}/conanbuildinfo.cmake)
include(${CMAKE_CURRENT_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup(TARGETS)
message(STATUS "using conan")
endif()
```
and then adding the dependencies in the `conanfile.py`.
What do you think?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] edisongustavo commented on issue #13400: [MXNET-1229] use OpenBLAS, lapack & OpenCV from conan
edisongustavo commented on issue #13400: [MXNET-1229] use OpenBLAS, lapack &
OpenCV from conan
URL: https://github.com/apache/incubator-mxnet/pull/13400#issuecomment-461348850
> 1.there is non-intrusive CMake integration for conan available as well,
check out this article: [conan: transparent CMake
integration](https://blog.conan.io/2018/06/11/Transparent-CMake-Integration.html)
Great! Thanks for the link. I am in favor of using this "Transparent CMake
integration: “cmake_paths” generator". So we could do the dance:
```
$ rm -rf build && mkdir build && cd build
$ conan install ..
$ cmake .. -DCMAKE_BUILD_TYPE=Release
-DCMAKE_TOOLCHAIN_FILE=./conan_paths.cmake
$ cmake --build .
```
This is very similar to what would be the conda dance:
```
$ conda env create -f environment.yml -n mxnet-dependencies
$ conda activate mxnet-dependencies
$ rm -rf build && mkdir build && cd build
$ cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=$CONDA_PREFIX
$ cmake --build .
```
I have some comments and questions about the conan part:
In the blog post it shows the integration using the variables created by
each library (eg: `${CURL_INCLUDE_DIRS}` and `${CURL_LIBRARIES}`). This is the
deprecated way of linking with targets. Using *imported targets* is the
preferred way (if possible) and the CURL example is no exception. You can see
that in the
[FindCURL.cmake](https://github.com/Kitware/CMake/blob/master/Modules/FindCURL.cmake)
file you can use the imported target `CURL::libcurl`, which should take care
of all transitivity and order of linking problems.
Is there something I'm missing here?
> 2. it's still possible to use dependencies provided by operation system
Great! I believe that it could be done if we use conan along the route
specified in my comment above, correct?
> 3. I am not sure about your concern of connection required for conan. I
think it's the same situation for conda, isn't it?
Given that you've sent that blog post it has clarified things for me. My
concern was in the case of conan working only in this "intrusive mode" (where
you have to modify your CMakeLists.txt) so then requiring the internet
connection every time you call cmake. Since we could use the "cmake_paths"
generator then this is not a concern anymore.
A question for you: How easy is it to mirror a conan repository? Or maybe
only mirroring the packages we need. Is that possible?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] edisongustavo commented on issue #13400: [MXNET-1229] use OpenBLAS, lapack & OpenCV from conan
edisongustavo commented on issue #13400: [MXNET-1229] use OpenBLAS, lapack & OpenCV from conan URL: https://github.com/apache/incubator-mxnet/pull/13400#issuecomment-461046247 If we add Conan support like this won't it require a connection to the conan artifacts repository while building? My main issue with Conan is that it "spreads over" your Cmake files (like it did in this case). It looks like it is an "all or nothing" solution. Wwhat would happen if I **do want** to compile against the dependencies of my operating system? Could I do that? # Alternative An alternative to provide all dependencies is to use conda (disclaimer: I'm a big conda fan). If we have a conda-environment file declaring all the dependencies, then the steps would be: ``` $ cd $ conda env create -f environment.yml -n mxnet-compilation-dependencies $ conda activate mxnet-compilation-dependencies $ mkdir build $ cmake -DCMAKE_PREFIX_PATH=$CONDA_PREFIX .. $ make ``` # Cool, but I want Conan! I agree that adding Conan support is important, but let's think about it more thoroughly and not let it "spread over" the cmake files. Let's think more deeply in how to add Conan support into Mxnet. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
