[cmake-developers] CMake API for warnings
Brad King
brad.king at kitware.com
Tue Apr 12 14:00:21 EDT 2016
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
More information about the cmake-developers
mailing list