INTERFACE_LINK_LIBRARIES in cmake-generated targets.cmake #194
Comments
smanders
pushed a commit
that referenced
this issue
Jun 12, 2018
* use Boost::<C> targets from FindBoost.cmake instead of Boost_LIBRARIES from find_package * Boost_LIBRARIES introduces hard-coded absolute paths and wrecks havoc on cmake-generated targets.cmake files see issue #194
smanders
pushed a commit
that referenced
this issue
Jun 13, 2018
issue #197 (comment) * wxcmakeover for MSW build (wxcmake31.patch), including NAMESPACE wx:: (which also effects non-MSW) * set_target_properties INTERFACE_LINK_LIBRARIES to build up wx library dependency graph, including gtk and system libs issue #194 * no longer using wxWidgets_LIBRARIES from find_package/FindwxWidgets.cmake * using wx::<C> targets from add_library with IMPORTED and IMPORTED_LOCATION issue #183 (comment) * removed include of the wxWidgets use file * there is still a question of whether wxWidgets_CXX_FLAGS (-pthread on linux) is needed
|
I believe this issue is complete with the commits referenced above - if not, other commits will also reference this issue... |
|
additional system libraries are needed for wxWidgets |
smanders
pushed a commit
that referenced
this issue
Jun 20, 2018
* still not sure if we need to add wxWidgets_CXX_FLAGS (-pthread) to CMAKE_CXX_FLAGS * https://stackoverflow.com/questions/2127797/significance-of-pthread-flag-when-compiling * holding off, hoping we don't have to modify global CMAKE_CXX_FLAGS - cmake is ready to go, just commented-out * see issue #194 (comment)
|
links with info on last commit (see details) regarding |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
externpro has several projects that aren't built via cmake on linux with gcc: boost, wxWidgets, fftw to name a few
we have another externpro-like project that builds internal/proprietary projects which we call internpro
internpro has projects that are built via cmake and depend on boost and wxWidgets
the problem is that the
BOOST_LIBRARIESandWXWIDGETS_LIBRARIESreturned from their use scripts are hard-coded absolute paths, specific to the system internpro is built on -- and so the cmake-generated targets.cmake files from these projects that depend on boost and wx haveINTERFACE_LINK_LIBRARIESlike the following:set_target_properties(mbview PROPERTIES
INTERFACE_LINK_LIBRARIES "-L/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib;-pthread;/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib/libwx_gtk3u_aui-3.1.a;/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib/libwx_gtk3u_propgrid-3.1.a;/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib/libwx_gtk3u_richtext-3.1.a;/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib/libwx_gtk3u_gl-3.1.a;/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib/libwx_baseu_net-3.1.a;/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib/libwx_gtk3u_html-3.1.a;/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib/libwx_gtk3u_adv-3.1.a;/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib/libwx_gtk3u_core-3.1.a;/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib/libwx_baseu_xml-3.1.a;/home/smanders/src/externpro/_bld/externpro_18.04.1-4-g6159bb8-gcc640-64/lib/libwx_baseu-3.1.a;-lGL;-lGLU;-lgthread-2.0;-lX11;-lXxf86vm;-lSM;-lgtk-3;-lgdk-3;-lpangocairo-1.0;-lpango-1.0;-latk-1.0;-lcairo-gobject;-lcairo;-lgdk_pixbuf-2.0;-lgio-2.0;-lgobject-2.0;-lglib-2.0;-lwxregexu-3.1;-lwxexpat-3.1;-lwxtiff-3.1;-lwxjpeg-3.1;-lwxpng-3.1;-lwxzlib-3.1;-ldl;-lm"
)
I've been working around this by clearing
INTERFACE_LINK_LIBRARIESof any externpro libraries and setting it to the internal libraries it depends on, for example the palam library mb depends on async (another palam library) and boost (from externpro), so I set it to only show it depends on async:most of the time the linking has worked out and these externpro library dependencies are in the link line in an order that works and things have just worked
except when they didn't... for example I found that I had to add the wx libraries back in the palam use script for mbview:
recently a new unit test for a Scheduler library was being developed which depends on the palam async library - and there is a link error (Debug build):
what you can see from the link line is that the boost libraries are there, the async library is there - but the boost libraries come first - and the link error is from the palam async library complaining that it's missing some boost things:
perhaps there are some hacks to put on top of the hacks to solve link issues like this...
but the real solution, to me, is to stop clearing out the
INTERFACE_LINK_LIBRARIESand figure out a way to not have hard-coded, absolute, build-system-specific paths in the targets.cmake filesThe text was updated successfully, but these errors were encountered: