Notes |
|
(0033250)
|
Brad King
|
2013-06-07 09:40
|
|
This is a good proposal. Perhaps the command should be called
cmake_host_system_information
because it can only collect information from the host running CMake and can never say anything about a target platform (e.g. during cross compiling).
|
|
|
(0033257)
|
Nils Gladitz
|
2013-06-07 16:55
|
|
I've given the implementation a try and attached a patch.
I only implemented a small subset of the information provided by cmsys::SystemInformation for which I could think of use cases or which didn't already seem to be covered but I guess it could be extended as demand arises. |
|
|
(0033279)
|
Brad King
|
2013-06-13 09:06
|
|
Thanks for working on a patch.
+ " cmake_host_system_information(<key> <variable>)\n"
I'd like to design an API that is more extensible in the future. Perhaps
cmake_host_system_information(RESULT <var> QUERY <key>...)
where <key>... can be zero or more keys whose results will be stored as a list in <var>. Other ideas? |
|
|
(0033280)
|
Nils Gladitz
|
2013-06-13 10:55
|
|
I can't think of a use case for lists and can't think of potential extensions for this but I am not strongly opposed.
What might be convenient for some uses would be a format string or variable substitution scheme similar to configure_file e.g. cmake_host_system_information(RESULT MY_VAR FORMAT "<HOSTNAME> has <NUMBER_OF_PHYSICAL_CORES> physical cores")
Though I could just as well manually concatenate those and would probably prefer to keep the command single purpose. |
|
|
(0033281)
|
Brad King
|
2013-06-13 10:58
|
|
The format mode would be a good candidate for future expansion but need not be implemented now. However, it serves as an example for why we want an extensible interface. |
|
|
(0033313)
|
Nils Gladitz
|
2013-06-14 17:13
|
|
I've uploaded a new patch that should implement the suggested interface. |
|
|
(0033316)
|
Nils Gladitz
|
2013-06-15 01:41
|
|
Updated documentation to match the new interface. |
|
|
(0033323)
|
Brad King
|
2013-06-19 08:50
|
|
|