Jump to content

  • Log In with Google      Sign In   
  • Create Account

CMake (some random questions)

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

#1 TheComet   Members   -  Reputation: 1585

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


Sponsor:

#2 Mnemotic   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



#3 l0calh05t   Members   -  Reputation: 741

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.


#4 TheComet   Members   -  Reputation: 1585

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