Getting OS identification data: Design discussion
As recommended in !6356 (closed) let's discuss this here. My 5¢...
I prefer the CMake module vs cmake_host_system_information
:
-
it's transparent -- i.e., anyone familiar w/ CMake syntax (all devs who use it for their project w/ whatever languages), may see the logic inside (and possible offer an MR) -- he does not need to download CMake sources and understand C++ (if implemented as a part of
cmake_host_system_information
) -
it's much easier to extend (via MR) than C++ code. And I think it gonna be extended for other OSes or older Linux distros (pre-os-release) w/ heuristics ala "parsing"
/etc/debian-release
,/etc/redhat-release
and others. Moreover, I'd rather like to have a user-defined hook to call if the shipped module can't get any information, so users may have a workaround (their custom detection function(s)) for "unknown" distros/OSes while MR is not released.
Although small, it's not zero, and we've had some complaints about the runtime of CMake on tiny projects. Every bit of work we can avoid helps.
- being a separate module, it's up to the project's dev when to
include()
it (and have overhead) OK, this is the same forcmake_host_system_information
:)
What other reasons (in addition to #18979) to have this functionality:
- personally I use it also to form "native" package names (siffixes) for my projects. Example,
-0xenial1.<arch>.deb
(Ubuntu) or.el7.<arch>.rpm
(RHEL/CentOS), ... BTW, it'll be nice to extendCPackRPM
andCPackDeb
to do that withRPM-DEFAULTS
/DEB-DEFAULTS
filename "templates" ;-)