On Fri, Jul 30, 2010 at 12:16 AM, Michael Jackson <mike.jack...@bluequartz.net> wrote: > I am saying that in the past 10 years of programming I found that there > is NO standard, even within an Operating System itself. Some projects like a > combined build of debug and release libraries with a "d" suffix on ALL > platforms (Qt) even though OS X would have then put "_debug". Another > library, ITK, _really_ wants you to have distinct Debug and Release > installation locations. They don't use ANY decorations. Boost, well, they > went slap happy with their decorations and don't follow ANY standard (either > perceived or real). > The point is that if you want to integrate into any of those environments > you better understand _their_ naming conventions, whether those conventions
Why would the naming convention have to match? > integrate with your chosen build environment and whether you are going to > perpetuate someone else's "standard" or not. I'll leave the philosophical > debate for somewhere else. After considering ALL of those factors (plus any > thing else you deem important) then you make your decision about whether or > not to decorate your libraries. Having the choice to do so is what CMake > offers. To YOU, the default (no decorations) is WRONG. To the rest of us, > the default is RIGHT. Why? I'm still waiting for someone to post a reason of why a decorated name is a problem for them. Also waiting on an answer to the code duplication issue. > Your solution is valid. I will give you that. But the Default you propose > is still wrong to the rest of us. If your solution was implemented but had a > default of NO decoration you would still complain. I might complain, but that situation would be better than the current situation. > As it is now CMake offers > the functionality you want. It doesn't. I'd like CMake to generate libs with unique names and it doesn't... Olaf _______________________________________________ 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
