[cmake-developers] Keeping unit tests useful and splitting feature support from platform support

Rolf Eike Beer eike at sf-mail.de
Mon Oct 17 02:35:37 EDT 2011


Am Montag, 17. Oktober 2011, 01:24:59 schrieb Stephen Kelly:
> Rolf Eike Beer wrote:
> > Stephen Kelly wrote:
> >> What I'd like to see is a distinction of feature support from platform
> >> support. In my case, I care about writing some features in cmake, but
> >> I
> >> don't care about watcom, GCC 3.3.1 etc. What I'd like to do is make
> >> sure
> >> my feature works on some 'reference platforms', which could be
> >> anything
> >> 'non- ancient', and fixing it on the ancient ones would become
> >> not-my-problem.
> > 
> > I find this all natural (but it's not my decision).
> 
> I'm not sure what this statement means.

That I'm not in the position of making any CMake project decisions.

> > On the other hand we
> > have some other features (like e.g. the source_group stuff) that depend
> > on generators and compilers.
> > 
> > One thing that I would only call "fallout" of such a thing, but that I
> > would love to see is a way to get the compiler version for the currently
> > active (C, C++, Fortran, ASM) compilers. That would probably help with
> > your use case, too, when you can determine the version and show a
> > sensible error message if the compiler version is too old.

> Yes, while a way to get the cross-compiler compiler version would be a step
> in the right direction, it might not help in the case of features written in
> C++, as you have no opportunity to run platform checks to enable features
> at all.

My idea would have been that you test your thing on as many compilers as 
possible. Then you could put an error/warning into your CMake module stating 
"You are using g++ 3.3 which does not support features needed for export 
headers" and disable whatever the module would have done.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20111017/bd1a974b/attachment.sig>


More information about the cmake-developers mailing list