• Create Account

## CMake (some random questions)

3 replies to this topic

### #1TheComet  Members

2672
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.)?

"I would try to find halo source code by bungie best fps engine ever created, u see why call of duty loses speed due to its detail." -- GettingNifty

### #2Mnemotic  Members

356
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

1608
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  Members

2672
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)

"I would try to find halo source code by bungie best fps engine ever created, u see why call of duty loses speed due to its detail." -- GettingNifty