Hi Ruslo,

Sorry for taking so long to respond here.  I've been hoping to find time
to think through the design deeply but I don't know when that may happen.
Here is some more feedback.  I invite others to jump in here.  Without
more interest I'm hesitant to proceed.

On 04/05/2016 02:03 PM, Ruslan Baratov wrote:
> Report an error in case of any type of conflicts.

Yes.

> new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this.

I'd prefer to avoid extra knobs if possible.

> You mean this:
> 
>      compatibility-c++98=off
>      inline=off
>      special-members=off
>      catch-semantic-changed=off
>      covered-switch-default=off
>      inherits-via-dominance=off
>      name-length-exceeded=off
>      padded=off
>      this-used-in-init=off
>      EVERYTHING=on
>      EVERYTHING=error
> 
> versus this one:
> 
>      DISABLE
>        compatibility-c++98
>        inline
>        special-members
>        catch-semantic-changed
>        covered-switch-default
>        inherits-via-dominance
>        name-length-exceeded
>        padded
>        this-used-in-init
>      ENABLE
>        EVERYTHING
>      TREAT_AS_ERROR
>        EVERYTHING

Consider examples where we don't have the full list ahead of time and
are instead appending.  Or, what if we want to check the current property
value to see if some setting is already present?  Compilers use flags like

  -Wxyz -Wno-abc -Whjk=error

and not

  -WDISABLE $w1 $w2 -WENABLE $w3 $w4

so IMO the individual values are easier to reason about.  Also one could
imagine having the value come from a generator expression, e.g.

   foo=$<CONFIG:Debug>

>> I'd like to find another name that captures the idea of enabling most 
>> warnings.
> 
> Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?

I don't think "everything" or "all" has a meaningful implementation
available on all compilers.  I was actually saying the opposite.
We should not try to provide such an abstraction and instead have
one called "most" or "high" or something like that.

-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