qPCR4vir / nana-demo

demos and tests for Nana C++ GUI library
https://github.com/cnjinhao/nana
Boost Software License 1.0
68 stars 24 forks source link

CMakeLists linking boost_filesystem not portable #14

Open 5cript opened 5 years ago

5cript commented 5 years ago

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

find_package(Boost COMPONENTS filesystem system)
set(NANA_LINKS "${NANA_LINKS} ${Boost_LIBRARIES}")

or

find_library(BOOST_SYSTEM boost_system)
find_library(BOOST_FILE_SYSTEM boost_filesystem)
set(NANA_LINKS "${NANA_LINKS} ${BOOST_SYSTEM} ${BOOST_FILE_SYSTEM}")

(untested but should be correct)

5cript commented 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.

qPCR4vir commented 5 years ago

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'

5cript commented 5 years ago

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)

qPCR4vir commented 5 years ago

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.

5cript commented 5 years ago

I see, Wouldn't it be better then to add an option(...) for the ENTIRE nana build directory?