Include system information in CMake output

[hperrey]

Detailed system information in the CMake output could make it easier to identify the cause of a problem from bug reports by users or other developers.

[hperrey]

Some ideas for information that would be useful:

• if on Linux: some of the output of lsb_release -a
• if on *nix: some of the output of uname -a
• CMake version
• git version (?)
• checksum of last git commit (?)
• Compiler version (always, even if already cached by CMake)
• ROOT version (always)
• libFTDI/libFTD2XX versions

[ursl]

Hi Hanno,

the version of the checked out code must be part of the dump that cmake
produces (imvho).

If possible, also whether the following packages are installed:

• glibc-devel.i_, libc6-dev-i_, glibc-devel-*
• g++-multilib, libstdc++-devel.i*

and what the value of the env vars

• LIBRARY_PATH
• C_INCLUDE_PATH
• CPLUS_INCLUDE_PATH

is (or better yet: the complete result of printenv). (see e.g.
http://stackoverflow.com/questions/7412548/gnu-stubs-32-h-no-such-file-or-directorywhich
I found useful)

Also: is it possible to skip producing the documentation targets if no
LaTeX is installed and just finish the Makefiles nevertheless? I realized
that I cannot even compile anything without LaTeX installed (without
mutilating the CMAKE file).
I think that there will be lab computers where no LaTeX/doxygen is or needs
to be installed.

Cheers,
--U.

On Wed, Jan 15, 2014 at 1:05 PM, hperrey notifications@github.com wrote:

Some ideas for information that would be useful:

• if on Linux: some of the output of lsb_release -a
• if on *nix: some of the output of uname -a
• CMake version
• git version (?)
• checksum of last git commit (?)
• Compiler version (always, even if already cached by CMake)
• ROOT version (always)
• libFTDI/libFTD2XX versions

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/31#issuecomment-32355858
.

[simonspa]

last git commit is already printed:

-- Determined API version v0.0.2+1~g651a6e7.

which means it is 1 commit after the tag v0.0.2, and that commit has the hash being 651a6e7 - pointing directly to the commit checked out last.

However, this is only updated when running cmake .., not after git pull; make install;.

[simonspa]

concerning caching: I wouldn't fight with CMake's cache but tell the users to do

cd build/
rm -rf *
cmake ..

before even attempting to ask any question. Because not having a clean build folder is 80% of the failures already.

[simonspa]

Most other information we can select from the list here:
http://cmake.org/Wiki/CMake_Useful_Variables#System_.26_Compiler_Information

...and just print them.

[hperrey]

Most of the really useful information is now in the CMake output; I would prefer not to include e.g. environment variables as this would seriously blow up the amount of console output and would make it more difficult to spot errors/warnings.
The presence of devel packages should already be checked by CMake (or we need to add those checks, but that is not part of this particular issue imho).
I will close this issue now -- please reopen if you think some important information is still missing from the output.

[frmeier]

Came to my mind while chatting with Urs at coffee: git version and checksum of last git commit will likely not be available if somebody installs the software downloading a tarball from github (an option users later will liekly do who don't want to use git for whatever reason). Should this case be handled somehow or not?

[hperrey]

Simon's CMake code takes care of that: if the .git directory is missing (as it would be when installed via tar ball) the version string in the CMake file is used instead.

[simonspa]

Yes. So the only thing we have to think of is to update that version number once we tag a new release. I just realize that I already forgot that for v0.2.0 - sorry...

[simonspa]

Done, bumper version to v0.2.1 and update CMakeLists.txt acordingly. New tag there.

[frmeier]

Perfect. Thanks.