Open 5cript opened 5 years ago
Oh this was hasty. You already have it setup this way, but why is the line commented out and replaced? I dont unterstand why.
Thank you! Yes, I see... it was a long serie of testing: https://github.com/qPCR4vir/nana-demo/commit/19b358454c359d6e360a96b1bc40f3e486f2b583 Anyway, I would like you to test and give me your opinion on my rerewrite of our CMakeLists:
https://github.com/qPCR4vir/nana-demo/tree/cmake-dev
Which uses:
https://github.com/qPCR4vir/nana/tree/cmake-dev
And the boost related code is: target_link_libraries (nana PUBLIC ${Boost_LIBRARIES})
The main problem was that nana-demo CMakeLists was ugly and a duplication of nana CMakeLists. I'm trying to use "modern" cmake with a target-centric approach. It is working correctly with https://nuwen.net/mingw.html which come with gcc 8.1 and with precompiled Boost. But Im having problems with our Travis-IC: wvl.cpp:(.text+0x3d9): undefined reference to `pthread_create'
make[1]: *** No rule to make target '../nana/cmake-build-/CMakeFiles/nana.dir/all', needed by 'CMakeFiles/screen.dir/all'. Stop.
which has to be related with line 24 in the CMakeLists.txt, which purpose is to find libnana I suppose? I am a bit confused, as the current CMakeLists.txt on branch cmake-dev does not include any boost linking line, or am I doing something totally wrong to what you wanted?
(cloned repo again, and switched to branch cmake-dev, run cmake and build in dir i created "build", turning on boost_filesystem)
Well, I have no idea why this error appear.
You can see it working OK on Ubuntu in Travis, and I'm using CLion 2018.2.1 with cmake 3.12.1 in Windows7 or directly from the cmake gui and it works OK. (see https://github.com/cnjinhao/nana/pull/342 and https://travis-ci.org/qPCR4vir/nana-demo/jobs/436400954)
But in another PC I have CLion 2018.2.2 with the same cmake and I see that error too. My workaround in that PC is to use directly the cmake gui, not CLion. I revised all the setting and could not find anything (I hope it is not that -${CONFIG}
thing, but you can try deleting it).
That line: add_subdirectory(../nana ../nana/cmake-build-${CONFIG} )
don't find libnana, it just include the entire nana-cmake instructions here, adding the target nana
to your (nana-demo) cmake build, so that you can link to it with target_link_libraries(${test} PUBLIC nana)
and don't need to have the binaries with exactly the same compiler options.
Nana don't distributed binaries - you need to compile it yourself, so that if you are using cmake the best way to consume nana is to include it with that line - no need to find it and make sure it is compatible with your compilation.
By using the target nana from cmake directly, you can reuse all the exported dependencies that nana exposes , including boost if you set NANA_CMAKE_BOOST_FILESYSTEM_FORCE
ON. It is "magically" managed by ("modern") cmake - it is supposed to analyze and add all the dependencies.
I see, Wouldn't it be better then to add an option(...) for the ENTIRE nana build directory?
The line where the boost libraries are added is not portable
set(NANA_LINKS "${NANA_LINKS} -lboost_filesystem -lboost_system")
My MSYS2 libraries are suffixed with -mt (multithread build).
rather use cmake utilities such as
or
(untested but should be correct)