MantisBT - CMake
View Issue Details
0011366CMakeModulespublic2010-10-26 17:062013-03-04 08:38
Clinton Stimpson 
Clinton Stimpson 
normalminorhave not tried
closedfixed 
 
CMake 2.8.10CMake 2.8.10 
0011366: RelWithDebInfo inconsistent flags
-DNDEBUG is defined for some compilers and not for others when using RelWithDebInfo configuration.

I'm hoping it can be consistent like it is for Release.
No tags attached.
related to 0013496closed Kitware Robot RelWithDebInfo flags still inconsistent with Release flags 
Issue History
2010-10-26 17:06Clinton StimpsonNew Issue
2011-04-05 12:00Juan Jesus Garcia de SoriaNote Added: 0026095
2011-04-05 12:19Juan Jesus Garcia de SoriaNote Edited: 0026095bug_revision_view_page.php?bugnote_id=26095#r290
2012-08-11 11:09David ColeStatusnew => backlog
2012-08-11 11:09David ColeNote Added: 0030247
2012-08-15 22:01Clinton StimpsonAssigned To => Clinton Stimpson
2012-08-15 22:01Clinton StimpsonStatusbacklog => assigned
2012-08-15 22:03Clinton StimpsonNote Added: 0030684
2012-08-15 22:03Clinton StimpsonStatusassigned => resolved
2012-08-15 22:03Clinton StimpsonResolutionopen => fixed
2012-08-29 11:52Brad KingRelationship addedrelated to 0013496
2012-10-24 17:18David ColeFixed in Version => CMake 2.8.10
2012-10-24 17:18David ColeTarget Version => CMake 2.8.10
2013-03-04 08:38Robert MaynardNote Added: 0032480
2013-03-04 08:38Robert MaynardStatusresolved => closed

Notes
(0026095)
Juan Jesus Garcia de Soria   
2011-04-05 12:00   
(edited on: 2011-04-05 12:19)
We've been hit by the assumption that RelWithDebInfo meant the same for Windows and Linux too. It seems it doesn't.

Every UNIX compiler configuration seems to NOT define NDEBUG and use a lower optimization level (-O2 instead of -O3) for RelWithDebInfo, whereas Windows compiler configurations don't seem to do this.

Is there any reason for this? Or is this an oversight?

(0030247)
David Cole   
2012-08-11 11:09   
Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0030684)
Clinton Stimpson   
2012-08-15 22:03   
Fixed

http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=0ddfc51f6a68c61d84b5b4818b32ecbf755a949a [^]
(0032480)
Robert Maynard   
2013-03-04 08:38   
Closing resolved issues that have not been updated in more than 4 months.