[CMake] Question regarding project structure

Michael Wild themiwi at gmail.com
Thu Sep 16 07:20:52 EDT 2010


On 16. Sep, 2010, at 13:14 , David Aldrich wrote:

> 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?

Only the top-level project generates a cache.

> 
> 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?

Don't put a project command in the library CMakeLists.txt files then, so they are unusable on their own.

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

HTH

Michael

> 
> 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.
> _______________________________________________
> Powered by 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

--
There is always a well-known solution to every human problem -- neat, plausible, and wrong.
H. L. Mencken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100916/9c27f3fa/attachment.pgp>


More information about the CMake mailing list