Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!

We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.

CMake (some random questions)

  • You cannot reply to this topic
3 replies to this topic

#1 TheComet   Crossbones+   -  Reputation: 1618


Posted 15 August 2014 - 11:02 AM

Assume the following project tree for all of my questions:

├── 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


#2 Mnemotic   Members   -  Reputation: 340


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.


#3 l0calh05t   Members   -  Reputation: 771


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.

#4 TheComet   Crossbones+   -  Reputation: 1618


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