Why did we skip point number 4. This was the biggest part of the CMake build system I made for my team. And I believe I borrowed a bit from the boost CMake adaption, so perhaps they have the same problem.
Instead of using a built in feature to accomplish this I have numerous macros and functions which define and accumulate the actual dependencies between libraries and executables. When I say a library depends on another library I need more than a build order and a link option added. I need the include directories too. Ever sense I started working with CMake I've been fighting with its "single top level view of the project." I finally got it so that I each library and executable knew about what it depended on and each could be built stand-alone. I just don't think a large project lends itself to the monolithic CMake approach. Don't get me wrong, I was able to use CMake to solve its own short coming, so I like it, but it's almost like I needed a CMake generator. I almost wrote a python or perl script that would generate the CMake files, because of all the scripting I was doing in CMake. I don't need another scripting language. --- Aaron Wright _______________________________________________ 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
