will break msvc builds. in general it is better to rely on cmake to do the compiler abstraction. most of the sc/cmake codebase could be drastically simplified (reducing the maintenance overhead in the long term) by dropping support for ancient cmake versions.

Oops - now fixed with a check, thanks.

Your point about the more modern approach is good - but we can't do that in the 3.7 branch, it would be a massive disruption. It'd be good to do that in the master branch. (For clarity: I'm proposing this for the 3.7 branch here, because it's 3.7.x that is currently failing to build on some debian systems.)

@danstowell pretty ancient: https://cmake.org/cmake/help/v2.8.10/cmake.html#prop_tgt:POSITION_INDEPENDENT_CODE

Ah Tim thank you! And sorry - I had assumed that it couldn't possibly be pre-3.0. Given your comments, would I be right to believe that the linux check is not needed if doing it that way?

@danstowell exacly: it will set compiler-specific flags according to the intended semantics (also in this case, the flag is not really linux-specific, but gcc-specific).
fwiw, the more recent the cmake version will get, the more one can specify on a semantic level instead of adding command-line flags. usually i recommend the latest version as people usually have better things to do than checking which parts are supported and which not.

fwiw, if debian ships ancient cmake versions, it would not be totally absurd to bundle a recent cmake with sc and build it in a bootstrap step (boost does this with it's own build-tool boost.build for example).

Thanks. No, debian is fine - not too ancient - what I meant is that we don't want to do anything to the 3.7 branch that changes the minimum required cmake version for sc