I would second this, I have been manually removing the CMAKE_INTDIR by hand, I'm not sure why it's even there for C++ compiles. I prefer my compile lines as clean and simple as possible and I don't use this compile line define anywhere. If I want a compile line define to indicate what CMAKE_INT does I can add it myself very easily but I don't see any easy way to make it not added of to remove it. Which segways me into
1) Does the patch you mention remove all the C++ defines from the midl command line? To my mind the defines you would want for IDL and C++ are pretty orthoginal so why force one on the other 2) Is there a general standard way to change the default flags you get for the compile line. As a for instance on a VS 10 debug build you get -RTC1 added which causes, amongst other things run time checking of undefined variable. This is toxic at run time for Boost which uses undefined variables for their types not their values so you get a runtime exception and I'm not man enough to attempt to play in the Boost code base. The only way I managed to get this flag changed, after various failed attempts at regex replacment of CMAKE variable and other Web suggested things, to the less problematic -RTCs was do download the source code replace RTC1 wherever I found it and build my own patched version. This seems a bit extreme. If someone know standard way of changing the default compile line switches for a given project, in other words not not by modifying you standard cmake install, can it be added to the FAQ/Wiki? Thanks On Thu, Nov 11, 2010 at 11:52 PM, Tony Bridges <abrid...@rim.com> wrote: > Hi David, > > 0008165 - vs2005 midl chokes on CMAKE_INTDIR (also 2008) > http://public.kitware.com/Bug/view.php?id=8165 > > I would love to see a fix for 0008165 in the next version. > > Each new version we pick up, I have to reapply Robert Lenhardt's patch and > rebuild. > http://public.kitware.com/Bug/file_download.php?file_id=1887&type=bug > The change is simple and isolated, from what I can see. > > Thanks! > /t > > > -----Original Message----- > From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of > David Cole > Sent: Wednesday, November 10, 2010 12:53 PM > To: Adam J Richardson > Cc: cmake@cmake.org > Subject: Re: [CMake] Bug fix requests for the *next* release of CMake... > > On Fri, Nov 5, 2010 at 6:29 AM, Adam J Richardson <fat...@crackmonkey.us> > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi David, >> >>> Replies requested. >> >> CMake is already pretty awesome from my POV, but since you ask... >> >>> Replies on this thread should just be a collector for bug numbers. >> >> Afraid I don't have a bug number, but I can explain quickly. >> >>> If you have a particular issue that you think should be fixed for >>> inclusion in 2.8.4, please bring it up now. >> >> Could you guys have a chat with the Boost guys and fix the "future >> safety" of FindBoost.cmake somehow? Fiddling with ADDITIONAL_VERSIONS >> is really a pain on a build farm. >> >> Oh, and include Mateusz Loskot's FindODBC.cmake in the release? > > To include a new module in CMake, we need a module maintainer for it, as > outlined here: > http://www.cmake.org/Wiki/CMake:Module_Maintainers > > So unless there is a volunteer for FindODBC, it will not be in CMake. > > Let me know if you or somebody you know wants to be that volunteer. > > > David > > >> >> Thanks, >> Adam J Richardson >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >> >> iEYEARECAAYFAkzT3GwACgkQSUH6dLOqvqlyOQCfaC2+BL+jkULzetoh3bduWoHU >> tmMAniddpSiMW4KpeRjpS0me9C+3RNjm >> =4TE7 >> -----END PGP SIGNATURE----- >> > _______________________________________________ > 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 > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > 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
