[CMake] Question regarding project structure

[David Aldrich]

Thanks Michael

David

> -----Original Message-----
> From: Michael Wild [mailto:themiwi at gmail.com]
> Sent: 16 September 2010 12:21
> To: David Aldrich
> Cc: David Cole; cmake at cmake.org
> Subject: Re: [CMake] Question regarding project structure
> 
> 
> 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_O
> > UTPUT_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_RUN
> > TIME_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+FkN6HRUneeEXa
> JdAcTHag+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