On 31. Mar, 2010, at 15:29 , Ruben Van Boxem wrote: > 2010/3/28 Hendrik Sattler <[email protected]> > >> [...] > > > No, because when compiling differently for Debug and Release, you have all >> object files twice. Thus you would enforce one more level of subfolders >> even >> for those that only want one setup. >> There may be a new Generator that does that but it still has to be written >> ;) >> > > I agree the additional subfolder level may be unwanted, that's why I > suggested the debug object file suffix to work around / solve the problem. > IMHO that's a clean way of seperating the debug vs release object files.
I prefer having distinct binary trees. This way I can just "rm -rf" e.g. the debug tree without having to dissect things. Doing multiple configurations without additional subfolders is very difficult to get right, so why not just do it the easy way if there isn't a significant drawback? As you said, most of the time developers use the debug tree anyways, and only once they prepare to ship the product, they will have a release tree around. > And to Eric: I consider an extra script along with CMake's part in this > superfluous. Why can't CMake mimic that behavior and let a user/dev use make > (dist)clean? Implementing distclean to work properly is probably impossible: http://www.cmake.org/Wiki/CMake_FAQ#CMake_does_not_generate_a_.22make_distclean.22_target._Why.3F > And about the multiconfig single build: yes indeed, for larger > projects like WxWidgets or Qt this would be a requirement, as often devs > will develop with a debug build (for obvious reasons) and then use the > release build for their... release. > And yes, the CMAKE_DEBUG_POSTFIX is a good thing and I use it. I'd hate such bloat-ware. What I expect (and what AFAIK all respectable Linux distros do) is to create a binary packages from the release-build (one for the executables, possibly many for the shared libraries), a development package (headers, static libraries, ...), and a package with the debug libraries. Michael _______________________________________________ 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
