14:13 < alsc_> I will try again integrating mlpack using the CMakelist in src/ as an external lib today, last time didn’t go that well

14:14 < alsc_> will report the various problems. would be cool if add_subdirectory-> src/mlpack would be enough

14:18 < alsc_> set(BUILD_TESTS OFF CACHE BOOL "Disable mlpack BUILD_TESTS")

14:18 < alsc_> set(BUILD_CLI_EXECUTABLES OFF CACHE BOOL "Disable mlpack BUILD_CLI_EXECUTABLES")

14:18 < alsc_> set(BUILD_PYTHON_BINDINGS OFF CACHE BOOL "Disable mlpack BUILD_PYTHON_BINDINGS")

14:18 < alsc_> ADD_SUBDIRECTORY("${CMAKE_CURRENT_SOURCE_DIR}/thirdparty/mogees-mlpack/")

14:18 < alsc_> this is failing on mlpack/CMakeLists.txt:203

14:19 < alsc_> I guess that I have already my FindArmadillo in my own CmakeModules directory, so I should somehow merge the two

14:19 < alsc_> I’ll try by including directly mlpack/src/mlpack

14:21 < rcurtin> alsc_: I've never tried including mlpack as a CMake submodule... I don't know what would be needed to make that work

14:21 < alsc_> I am trying it… there are a few things that can be improved

14:21 < alsc_> shall I open issues on github?

14:22 < alsc_> 1st thing: options like BUILD_TESTS, BUILD_PYTHON_BINDINGS should have a prefix because for example BUILD_TESTS is conflicting with my other libs :)

14:29 < alsc_> removing my own FindArmadillo.cmake from the including project’s cmakemodules directory seems to be doing good

14:30 < alsc_> this is quite often the case though, that CMAKE_MODULE_PATH for added subdirectories has always been kind of a pain

14:49 < rcurtin> alsc_: hm, I am not sure I want to change the name of the options, because this makes it confusing for an end user who now has to write, e.g., 'cmake -DMLPACK_BUILD_TESTS=ON' or something instead of the simpler 'cmake -DBUILD_TESTS=ON'

14:50 < rcurtin> however... I think it would be reasonable to add another option like 'MLPACK_OPTION_PREFIX_NAMES' or something like this, and then if (MLPACK_OPTION_PREFIX_NAMES) we add the options as MLPACK_BUILD_TESTS, etc.

14:50 < rcurtin> and otherwise we add as it is now

14:50 < rcurtin> what do you think? it's a little bit of complexity but it's the quickest way I can think to solve both problems

15:10 < alsc_> yes…. but I had to give up

15:11 < alsc_> I gave up when I saw that MLPACK_LIBRARIES also include their dependencies

15:11 < alsc_> line 269

15:11 < alsc_> but they aren’t “CACHE” variables

15:12 < alsc_> I don’t want to diverge too much from the master branch and in the end for now it’s just matter of change something + make install

15:13 < alsc_> actually, I could even just set the include paths from my projects directly to the repo without make install, in any case it’s all template stuff so I don’t even have to recompile the lib

15:19 < alsc_> well not true that it’s all templates

15:26 < rcurtin> alsc_: MLPACK_LIBRARIES should include everything that an mlpack program might need to link against

15:27 < rcurtin> I don't have a huge problem changing other parts around if you can help describe what makes your life easier, I just want to try and avoid changing what users actually do to configure and use CMake

15:45 < alsc_> I see. MLPACK_LIBRARIES is empty from a CMakelists that adds mlpack as a subdir

15:46 < rcurtin> it would be easy to make it a CACHE variable so that you could use it from a higher level

15:46 < rcurtin> I'm happy to make that change immediately if it would help you out

15:50 < alsc_> wait I am trying

15:50 < alsc_> so I have set CACHE STRING “”on include and libs variables

15:51 < alsc_> now from my cmakelists I see all the deps but not the mlpack lib, that is if I log the content of ${MLPACK_LIBRARIES} I get

15:51 < alsc_> /usr/local/lib/libarmadillo.dylib/usr/local/lib/libboost_program_options-mt.dylib/usr/local/lib/libboost_unit_test_framework-mt.dylib/usr/local/lib/libboost_serialization-mt.dylib

15:51 < alsc_> making with VERBOSE=1 I see that those libs are ok but it complains about references to mlpack

15:52 < alsc_> ok well I just need to link against the mlpack lib, let me try

15:53 < rcurtin> ah sorry I should have clarified, in line 563 we add "-lmlpack" to MLPACK_LIBRARIES_LIST, but that MLPACK_LIBRARIES_LIST variable is only for what gets output into the generated pkg-config file

15:54 < rcurtin> so MLPACK_LIBRARIES actually includes everything an mlpack program needs *except* -lmlpack

15:56 < alsc_> I added directly mlpack in TARGET_LINK_LIBRARIES

15:56 < alsc_> seems to work now, it’s building mlpack…. let’s see in 15 minutes

16:09 < alsc> one question is: why does it always do this? Moving header files to include/mlpack/

16:10 < alsc> ahhh almost!! all my targets have been built, I just got this in the end

16:10 < alsc> CMake Error at /Users/alex/Documents/development/mogees/mogees-lib2-tools-mlpack/thirdparty/mogees-mlpack/CMake/GeneratePkgConfig.cmake:9 (message):

16:10 < alsc> Cannot open /include/mlpack/core/util/version.hpp to extract version!

16:11 < alsc> maybe we can add an option to avoid building pkgconfig

16:12 < alsc> bbl