[CMake] Question regarding project structure

David Aldrich David.Aldrich at EU.NEC.COM
Thu Sep 16 07:14:57 EDT 2010


Hi David

Thanks very much - I will give that a try. By the way, we are building on Linux only.

If I specify compiler flags in my top level CMakeLists file, I guess that the lower level ones will inherit those settings and store them in their local caches. Then a lower level CMake may be performed manually and still inherit those settings. But this would require the top-level CMakeLists file to have been executed at some point previously. Am I correct?

We store our code in svn. Followiing a clean checkout of the code, is there a way that I can ensure that a developer has executed the top level makefile before attempting to invoke individual library makefiles, so that he can be sure that he has the correct compiler flags?

(We achieved this previously by including a top-level settings file in each makefile).

Best regards

David

From: David Cole [mailto:david.cole at kitware.com]
Sent: 16 September 2010 11:58
To: David Aldrich
Cc: cmake at cmake.org
Subject: Re: [CMake] Question regarding project structure

On Thu, Sep 16, 2010 at 6:45 AM, David Aldrich <David.Aldrich at eu.nec.com<mailto:David.Aldrich at eu.nec.com>> wrote:
Hi

I have now successfully configured CMakeLists files to create some of our static and dynamic libraries using CMake.  I would now like some advice on how to configure these separate build files as a single project.

Here's what our current folder structure is like:

Trunk ------- Kernel      <==== a static library containing main()
        |
        |--- DynLibs     <==== containg multiple folders containing
        |                      proprietary source code, each folder
        |                      builds one shared library
        |
        |--- MyExe       <==== contains top-level makefile that
                               a) links Kernel static library into an .exe
                               b) calls makefiles for the dynamic libraries

This structure may not be ideal from a CMake standpoint, but I would like to maintain it to ease the transition from pure gnu make to CMake.

CMake is flexible about where source files are located. This structure looks perfectly reasonable.


What would I need to put in the top-level CMakeLists file (MyExe/CMakeLists.txt) to reference the other CMakeLists files?

Something like this should work:

cmake_minimum_required(VERSION 2.8)
project(MyExe)

add_subdirectory(../Kernel Kernel)
add_subdirectory(../DynLibs DynLibs)

add_executable(MyExe exe.cxx)
target_link_libraries(MyExe Kernel)


If your DynLibs build dll files on Windows, the easiest way to get them to load into the exe is to use the RUNTIME_OUTPUT_DIRECTORY target property. (Just put the exe and the dlls all in the same folder with each other...)
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:RUNTIME_OUTPUT_DIRECTORY

Or just once in your top level CMakeLists, the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_RUNTIME_OUTPUT_DIRECTORY



Should each CMakeLists file have its own Project name, or should they all be the same?

Only the top one *needs* a project command, but if you do have project commands in your other CMakeLists.txt files, they should definitely each be unique.


Any advice would be much appreciated.

Best regards

David
_______________________________________________
Powered by www.kitware.com<http://www.kitware.com>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


HTH,
David C.



Click here<https://www.mailcontrol.com/sr/NU6aVxvGVgvTndxI!oX7Uv3k+FkN6HRUneeEXaJdAcTHag+0Uqgm21LO1pIkrfrEk+T08o1InrG6Rmyxrg+4Pw==> to report this email as spam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100916/1edc97bf/attachment-0001.htm>


More information about the CMake mailing list