2

in my project I am using the header only library rapidjson v1.1.0.

└── my_project
    ├── CMakeLists.txt
    ├── src
    │
    ├── 3rdParty/tiny_dnn (header only)
    │   ├── CMakeLists.txt
    │   ├── src
    │   └── rapidjson_v0.2
    │   
    └── rapidjson_v1.1.0

The problem is now that tiny-dnn has also included rapidjson (but an older version), so while i try to include tiny_dnn in the main CMakeLists.txt like include_directories(${PROJECT_SOURCE_DIR}/3rdParty/tiny_dnn) some conflicts arise from either tiny-dnn searches mine rapidjson or my project searches in tiny-dnn's rapidjson.

my_project CMakeLists.txt

cmake_minimum_required(VERSION 3.9)
project(my_project)

# check the build type and set compiler and linker flags
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

string(TOUPPER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE)
IF(CMAKE_BUILD_TYPE MATCHES DEBUG)
    message("Debug build")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wno-unknown-pragmas -g -O0 -std=c++17 -Ddeveloper_build")
    set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fPIC -g -O0")

ELSEIF(CMAKE_BUILD_TYPE MATCHES RELEASE)
    message("Release build")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wno-unknown-pragmas -O3 -std=c++17")
    set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -O3")

ELSE()
    message(FATAL_ERROR "No build type specified")
ENDIF()

find_package(Boost COMPONENTS system filesystem REQUIRED)
include_directories(${Boost_INCLUDE_DIRS} ${PROJECT_SOURCE_DIR}/3rdParty/tiny-dnn)

file(GLOB_RECURSE SOURCE_FILES src/*.cpp src/*.c)

set(SOURCE_FILES
        ${SOURCE_FILES})

add_executable(my_project ${SOURCE_FILES})
target_link_libraries(my_project ${Boost_LIBRARIES} pthread)
set_target_properties(my_project PROPERTIES SUFFIX ${CMAKE_BUILD_TYPE})

my_project.cpp

#include <tiny_dnn/tiny_dnn.h>
#include <rapidjson/rapidjson.h> // <- usr/local/include/rapidjson

int main(int argc, char **argv)
{
    rapidjson::Document d; // <- uses rapidjson (v0.2) of tiny_dnn/cereal/external/rapidjson but in my project i would use /usr/local/include/rapidjson (v1.0.1)

    return 0;
}
Fohlen
  • 41
  • 1
  • 4
  • is it possible to use one of them (or even both) without `include_directories` but after configuring and installing it in a specific location and using it as a client with `find_package`? – compor Jul 30 '18 at 13:24
  • I'd like to keep the tiny-dnn library as unchanged as possible, so it would be good to get both. In addition, the differences are relatively large so it would be a lot of effort to raise the tiny-dnn rapidjson to v1.1.0. – Fohlen Jul 30 '18 at 14:37
  • Can you please post a minimal related version of your `CMakeLists.txt` and what are the exact errors? (please amend your post, not the comments) – compor Jul 30 '18 at 15:21
  • Thanks for helping. I have added the minimal files. The CMakeLists.txt of tiny-dnn can be viewed under the open source repo. – Fohlen Jul 30 '18 at 17:07
  • and the exact error? – compor Jul 30 '18 at 19:10
  • There is no exact error. I would like to use rapidjson v1.0.1 (which is located in usr/local/include) in the my_project area, while tiny-dnn uses the /cereal/external/rapidjson in the libraray area. – Fohlen Jul 30 '18 at 19:33
  • Errors occures because I cant separate them and the older tiny-dnn rapidjson has different functions as rapidjson v1.0.1. – Fohlen Jul 30 '18 at 19:41
  • Apart from being quite dangerous, I can't see an easy way out of mixing headers of libraries of different versions. Maybe you can isolate your uses of the newer json library into a separate sub-project using the PIMPL idiom and link that to the main target. Moreover, you should use `target_include_directories`, to only affect the includes of the target you're interested in and not all of the targets in your project. Another idea might be to use a different json library for your project. – compor Jul 31 '18 at 08:20
  • Fixed some time ago by manually updating Cereal, where a namespace can be specified for its rapidjson. Thank you for helping @compor – Fohlen Jun 17 '19 at 13:54
  • it might useful to answer to this question with that solution for posterity. I mean, you did finally reply almost a year later, you might as well make this complete :-) – compor Jun 18 '19 at 14:22

1 Answers1

1

In general - don't. Force one client to use higher / better. Even if you walk around those problems, you are likely to violate one definition rule and get segfault later.

kwesolowski
  • 695
  • 8
  • 18