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:[email protected]] > Sent: 16 September 2010 11:58 > To: David Aldrich > Cc: [email protected] > Subject: Re: [CMake] Question regarding project structure > > On Thu, Sep 16, 2010 at 6:45 AM, David Aldrich > <[email protected]<mailto:[email protected]>> 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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ 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
