No subject

  -  the whole CMake test suite is not covering enough use case
     but there is no so much people volunteering for enhancing the test sui=
te

  - There is a a lot of enhancement request for CMake coming
    from the community so CMake urgently need new stringent builtin
    checks in order to avoid the "noise of misusage"
    (no blame to anyone just a feeling from reading the ML)

> Adding new options, new error detections to CMake is great, but
> turning on these new features by default is often a source of issues.
> We cannot control which minor release of CMake a client uses to build
> up an application. Controlling a major version is ok (2.6 vs. 2.8),
> but controlling a patch release is impossible, as CMake gets
> automatically updated in Linux distributions, for example.

In the end, I off course agree with you that one should avoid such
"default new behavior", I think in this case it is
possible so may be switching those warning off by default would
be the way to go for 2.8.4 (my personal opinion though).

>>=A0The idea was to catch misspelled words.
>
> The idea is definitely nice, but why do not turn on this kind of new
> policies on explicit request (either with a new option switch and/or a
> new POLICY statement) as long as CMake does not reach a new major
> milestone?
> Dealing with the constant modifications of CMake options is a tough
> job for a software maintainer, I believe.

Dealing with constant user request is a tough job for developers too,
Just kidding :-]

--=20
Erk
Membre de l'April - =AB promouvoir et d=E9fendre le logiciel libre =BB -
http://www.april.org