So... no easy answer for this? The only reason I bring this up is that I've looked at the cmake version of boost, and it requires a library of several cmake files full of macros and functions that help get their project organization to work with cmake. I've had to resort to the same kind of thing. ADD_LIBRARY just didn't cut it. I like that cmake allows me to get to the functionality I want, but it seems that it becomes a scripting language at that point, and cmake is certainly not a scripting language. Boost for example has numerous helper functions or macros for using named arguments with macros and functions. (They are all very cleaver and I totally use them in my project.) Another example is that my project has functions and macros for adding the dependencies between libraries, dependencies like include directories, link directories, and link libraries. Is there something on the horizon for CMake to address these issues? Or have they been addressed, but I've missed them?
On a side note, I see questions for this kind of thing all the time on this mailing list. I never see a very good answer. Perhaps a wiki page or a blog could be made covering project organization. It could perhaps cut down on repeat questions. ------------------------------------------------------------- Aaron Wright From: aaron_wri...@selinc.com To: Michael Jackson <mike.jack...@bluequartz.net> Cc: cmake@cmake.org Date: 03/22/2010 07:47 AM Subject: Re: [CMake] Handling library dependencies and minimizing duplicated include_directories Sent by: cmake-boun...@cmake.org You mean in the case of a master CMakelists.txt file I assume? That does work, and I like that functionality. The same kind of thing works for Visual Studio solutions as well. I just don't think this fits the usual paradigm of building my developers and I are used to. For example, if they want to work on a library, they would instinctively go to that library and make a build folder and run CMake. They would not think to go to the top of the directory tree, create a build folder in a location they never make folders or files or do any work, and then progress down the build folder's directory path to the library they want to build. Which is in a completely different location than the source files of the library, which they'll soon be modifying. This would all work though, so it is a valid solution. ------------------------------------------------------------- Aaron Wright From: Michael Jackson <mike.jack...@bluequartz.net> To: aaron_wri...@selinc.com Cc: cmake@cmake.org Date: 03/22/2010 07:32 AM Subject: Re: [CMake] Handling library dependencies and minimizing duplicated include_directories If you are using any of the "Makefile" generators, you can simply drill down into the folder of the library you want to build and issue the "make" command. The library, and anything that it depends on will be built (or rebuilt) accordingly. ___________________________________________________________ Mike Jackson www.bluequartz.net On Mar 22, 2010, at 9:52 AM, aaron_wri...@selinc.com wrote: > I've always been a little confused by FIND_PACKAGE and those "*- > config.cmake" files. So much so that I didn't use them in my build > system at all. The main question I have is that I have several > developers and numerous little and big libraries. Because the whole > project is so big it would be prohibitive for them all to work from > a master CMakeLists.txt file at the top. I want each developer to be > able to go the folder of the library they want to work on today and > start building there. I want all the libraries that library depends > on to be built or rebuilt if anything has changed in addition to > building the current library. > > I've been unable to find a simple solution to this problem using > CMake, which makes me wonder if what I'm doing is off the wall, but > it sounds so normal to me. I see these "*-config.cmake" files but it > seems they are generated from a CMakelist.txt file, which wouldn't > make any sense, because I'm not going to have a developer go to each > dependant library and build it seperately so that the "*- > config.cmake" can be generated so that he can have those variables > back in the library he really wants to build. > > What am I missing? > > ------------------------------------------------------------- > Aaron Wright > > > > From: > Daniel Lidström <daniel.lidst...@sbg.se> > To: > Cc: > <cmake@cmake.org> > Date: > 03/20/2010 01:25 PM > Subject: > Re: [CMake] Handling library dependencies and minimizing > duplicated include_directories > Sent by: > cmake-boun...@cmake.org > > > > > > If the projects UMC3D, GFL etc can be used independently, but > > are all "under your control", then you shouldn't write > > FindUMC3D.cmake, FindGFL.cmake etc files, but create > > UMC3D-config.cmake, GFL-config.cmake etc files instead. Read > > the documentation of the FIND_PACKAGE command, especially the > > paragraphs about the "config mode". You'll also find many > > discussions on this in the archives of this list. > > Thanks a lot for your help Mike! > > Regards, > > Daniel Lidström > Stockholm, Sweden > _______________________________________________ > 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 > > _______________________________________________ > 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 _______________________________________________ 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
_______________________________________________ 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
