CMake fails after downloading source tree from www.fltk.org

[ManoloFLTK]

When the FLTK source tree is downloaded from the "download" section of www.fltk.org,
rather than from its github git repo, CMake building fails with

fatal: not a git repository: '/home/xxxx/fltk-1.4.x/.git'

CMake Error at documentation/CMakeLists.txt:53 (string):
  string sub-command REPLACE requires at least four arguments.

The error disappears if OPTION_BUILD_HTML_DOCUMENTATION which is on by default is turned off.

The error comes from documentation/CMakeLists.txt executing command
git --git-dir=${CMAKE_SOURCE_DIR}/.git rev-parse --short=10 HEAD
which fails if ${CMAKE_SOURCE_DIR} is not a git repo.

@Albrecht-S : That could be fixed by setting the default value of this option according to whether the source tree contains a .git directory, or by replacing the output of the git command by something else. What do you think ?

[Albrecht-S]

@ManoloFLTK Thanks for finding and reporting this. I would not want to change the default of OPTION_BUILD_HTML_DOCUMENTATION and this wouldn't help anyway if someone really wanted to build the docs from a tarball. I added the git revision to the docs (html + pdf) because I found this to be essential to see from which FLTK version (git commit) the docs have been created.

However we must take into account if the current source directory is a git repository or not and I believe the best choice would be to create a file with the git commit hash when we build the tarball so we can access this file rather than using git directly. I'll check how to do this.

Do you agree with this approach?

[ManoloFLTK]

Yes. Putting the git commit hash in the tarball would be perfect.

[Albrecht-S]

FTR: commit 5646522 fixes two special cases where either doxygen or git were executed even if the source tree was not a git working copy and/or doxygen would be invoked although it was not found or not in the current PATH.

This is not yet a complete solution for this issue but it should prevent hard build errors.

@ManoloFLTK Writing the current git revision to a file during tarball creation will be done in a later commit. I'm thus leaving this issue open for now.