On 10/16/2011 02:56 PM, Richard Wackerbarth wrote:
On Oct 16, 2011, at 6:54 AM, Stephen Kelly wrote:
Having so many old platforms and compilers on the dashboard going red with
failure
So, I think I'm talking about two separate issues. One is whether failures
on platforms I don't care about are my responsibility, and the other is
ensuring that unit tests fail when something breaks.
Steve,
This is the "backward compatibility" issue that plagues all projects.
Since CMake is a development tool, you have to consider its audience.
Suppose you generate some "wiz-bang" new feature that only works when the
generator is for the clang compiler and using Xcode.
You decide "It's too much trouble to support Visual Studio" or the gcc 4.0
compiler."
Now as a package developer, I have to choose from the following options:
1) Drop my support for platforms that your feature doesn't support,
2) Avoid using the "wiz-bang" feature, or
3) Avoid CMake entirely
The problem is that I was happy with the feature set of CMake 2.4 and don't "need"
"wiz-bang".
A POLICY can provide notice that "the wiz-bang feature is not supported on this
platform".
But CMake still has to support "the old way".
Adding features that are not supported on ALL supported platforms reduces the
utility of CMake as a viable cross-platform tool.
Adding unsupported features really confuses the definition of CMake. At some point, we
should "bite the bullet", freeze the feature set of CMake and start a new
CMake2 project. In doing so, we can drop all support for certain platforms and the need
to support backward compatibility. But, within each version of the product, all of its
features need to work on all platforms supported by the product.
I think that it is YOUR responsibility to make any new feature work on all
supported platforms.
If you cannot support some particular platform, you can petition the CMake
community to drop support for certain platforms. But it should not be your
unilateral choice to do so.
Richard
Hi Richard,
I'm trying to find a solution to an issue I perceive about unit tests
not counting for much if we only run them when they are testably already
working.
There may be other ways to make that work, but your response indicates
that you strongly think what I proposed is the wrong approach. You might
be right, I don't know.
I came up with this proposal after looking at the Qt approach to
platform support -- They define reference platforms, and if others want
to make Qt work on WinCE for example, they can do that work and be the
experts in it. I don't mean to say that what Qt does will automatically
work for CMake (unlikely in fact). I'm trying to explore options.
All the best,
Steve.
PS, please subscribe to the cmake-developers mailing list. I think your
mails are being held in moderation. At least they don't appear on gmane:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2023
(also your previous mails never made it to the list)
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
