On 01/04/2016 06:52 PM, Michael Scott wrote:
> To round off the -W options functionality, I've implemented the -Werror 
> and -Wno-error set of options for the two current types of messages, dev 
> and deprecated. This includes updating the QT GUI to include new options 
> for controlling this functionality.

Thanks.  I'd first like to resolve the discussion below because it may
affect the first patch.

> The third patch is not for new functionality, but addresses two small 
> inconsistencies relating to dev and deprecated messages functionality, 
> it's not needed at the end of the day but I thought it would be good to 
> make the code consistent while I was in the area.

Most of that change appears to be just the number of spaces after a
period.  I prefer two which is why the original message was that way.

> Lastly I'm also looking at changing all the current usages of the 
> cmake::IssueMessage command, where the message type is dev warning. To 
> check if the warning got upgraded to an error (by checking if the error 
> state has been signalled with the cmSystemTools class), and change the 
> return value of the calling function for example. I think this was 
> discussed previously, however I think this might not be the right change 
> to make. There's quite a few instances of the above code and changing 
> them all is dangerous I imagine where I don't know exactly what all of 
> the callers are generally doing and should be doing. It also implies an 
> undocumented rule that future users of the above functionality should 
> also do this check, which doesn't sound like a good idea to me.  What 
> are your thoughts on this last point?

IIRC we previously concluded that the individual callers don't have to
deal with the message type change so long as the overall process exits
with an error.  Is this currently achieved by the patch?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Reply via email to