Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMakeLists linking boost_filesystem not portable #14

Open
5cript opened this issue Sep 30, 2018 · 5 comments
Open

CMakeLists linking boost_filesystem not portable #14

5cript opened this issue Sep 30, 2018 · 5 comments

Comments

@5cript
Copy link

5cript commented Sep 30, 2018

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
Copy link
Author

5cript commented Sep 30, 2018

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
Copy link
Owner

qPCR4vir commented Oct 1, 2018

Thank you!
Yes, I see... it was a long serie of testing: 19b3584
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
Copy link
Author

5cript commented Oct 3, 2018

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
Copy link
Owner

qPCR4vir commented Oct 3, 2018

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 cnjinhao/nana#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
Copy link
Author

5cript commented Oct 8, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants