• Create Account

Banner advertising on our site currently available from just $5! # CMake (some random questions) 3 replies to this topic ### #1TheComet Crossbones+ - Reputation: 1905 Like 0Likes Like Posted 15 August 2014 - 11:02 AM Assume the following project tree for all of my questions: some_project ├── another_library │ ├── CMakeLists.txt │ ├── include │ │ └── another_library │ │ └── another_library.hpp │ └── src │ └── another_library.cpp ├── app │ ├── CMakeLists.txt │ ├── include │ │ └── app │ └── src │ └── main.cpp ├── CMakeLists.txt └── library ├── CMakeLists.txt ├── include │ └── library │ └── library.hpp └── src └── library.cpp Where app is an executable and depends on the shared object another_library and another_library depends on another shared object library. Question 1 Since another_library needs to include header files from library, is it ok for another_library/CMakeLists.txt to include the directories by using the following? include_directories ("${CMAKE_SOURCE_DIR}/library/include")

It feels a little wrong to be assuming things about where the top library folder is placed. Moving it to another location (in a subdirectory somewhere for example) would mean having to edit another_library/CMakeLists.txt to include the new location of library.

Question 2

app is the executable, and I've seen a lot of people configure their executable directly in the top level CMakeLists.txt rather than doing it in app/CMakeListst.txt. What are the pros/cons of either technique?

Question 3

How and were do I install resource files (such as images, config files, etc.)?

YOUR_OPINION >/dev/null

### #2Mnemotic  Members   -  Reputation: 340

Like
1Likes
Like

Posted 15 August 2014 - 12:18 PM

1. You're the boss of your project directory structure! It is what you say it is, and therefore there are no assumptions made. If you insist on future-proofing, you can define a variable in the top-level CMakeLists.txt that would hold the include directory for library. Then use it in another_library CMakeList.txt.
2. Do whatever makes the overall structure clearer to you. I have no opinion either way.
3. On Linux: probaby under /usr/shared/app or /usr/local/shared/app. On Windows: in the installation directory. I haven't the foggiest about OSX.

HTH

### #3l0calh05t  Members   -  Reputation: 915

Like
1Likes
Like

Posted 15 August 2014 - 01:14 PM

1. Does another_library use library? You should consider using target_include_directories instead of include_directories
2. I typically use a CMakeLists.txt for each target. This is advantageous should you at some point decide to make the projects individually buildable (I usually have a cmake_minimum_required() and project() in every target-CMakeLists)
3. As Mnemotic said. OSX uses so called App Bundles afaik, which is similar to the windows solution, but packaged in a zip.

### #4TheComet  Crossbones+   -  Reputation: 1905

Like
0Likes
Like

Posted 15 August 2014 - 04:17 PM

Ah, target_include_libraries is exactly what I need for question 1, thanks!

I really need to get a mac so I understand how to build things for it. I've no experience whatsoever, I only know it is somewhat similar to Linux (it is BSD after all)

YOUR_OPINION >/dev/null

PARTNERS