Well, if you're just interested in having one solution that only covers the currently needed libraries from the rest of the source tree, you can have a look at this feature request: http://www.cmake.org/Bug/view.php?id=3218
if you have lib/ a/ b/ c/ exec/ x/ y/ and you do a PROJECT(x) in exec/x/CMakeLists.txt than this patch would generate a .sln file in exec/x that contains only the libraries (and executable) that x really depends on - so if x doesn't depend on a and b, but only on c, a and b would not be in the solution. Cheers, Manuel On 8/12/07, Theodore Omtzigt <[EMAIL PROTECTED]> wrote: > > > > > Dear CMake gurus: > > > > First of all, thank you for creating CMake. After struggling with cross > platform builds for a decade, CMake has solved all my essential requirements > for cross platform Windows/Linux software development. > > > > On to the questions: I have a large and diverse software/hardware tree to > manage (>75 projects of one form or another). I started porting this tree to > CMake from the top down and bringing in one project at a time. The problem I > am now having is that for the Windows .NET IDE side, the .NET solution > becomes hard to comprehend due to its size. Except for a small handful, many > of these projects use only small subsets of the software components in the > tree. The majority of the time these projects can move along without knowing > or interacting much with other projects that do not share their sw > components. So the first question is if there is a way to siphon off a > subset of the build? Given the fact that the build process is defined in a > hierarchy of fixed-name CMakeLists.txt files, I am confused how to 'overlay' > separate build processes to simplify the usage of more isolated projects. > > > > The second question is adjoined: How do I get the test suites to not show up > in the IDE solution but still be run during the RUN_TESTS build? In our > case, all sw components have a test suite associated with them. Right now, > these tests end up as separate projects in the build, and are seriously > cluttering up the solution. Reading the CTest chapter in the book, it states > that building the test programs separately from the main build, it should > become more scalable. It is clear that I am missing something since > excluding them from the build process would imply that there is a secondary > handle of some sort to trigger the testing which is the same problem I am > having as indicated by the first question. > > > > Can anyone enlighten me? I am using cmake 2.6 patch 6 and 7. > > > > Theo > > Stillwater Supercomputing, Inc. > _______________________________________________ > CMake mailing list > [email protected] > http://www.cmake.org/mailman/listinfo/cmake > -- http://klimek.box4.net _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
