[Chicken-users] CMakeLists.txt CONFIGURE_FILE bug and paradigm

[Brandon J. Van Every]

The CMakeLists.txt in darcs tries to execute

 CONFIGURE_FILE(csc.scm.in csc.scm)

However, the CMake docs say that the paths for the filenames must be 
absolute.  i.e.

 CONFIGURE_FILE(${Chicken_SOURCE_DIR}/csc.scm.in
   ${Chicken_SOURCE_DIR}/csc.scm)

When an absolute path is not given, csc.scm is not generated.  In turn, 
generation of csc.c fails, which causes the build to fail.  Providing 
the absolute paths fixes the problem.

The CMake philosophy here is to protect the integrity of pathnames in 
header files.  CMake supports "out of directory" builds, and this can 
only be accomplished if (say) config.h files use absolute pathnames.  
Generally speaking, you cannot casually move a CMake build around in a 
file hierarchy either.  Wherever you build it, that's where it has to stay.

As a question of philosophy, you could choose to dump your output to 
${Chicken_SOURCE_DIR}/foo.scm or ${Chicken_BINARY_DIR}/foo.scm.  The 
latter case is more in step with the "out of directory" build 
philosophy, i.e. not touching the contents of the original SRC directory 
at all.  I would recommend switching to this philosophy.  One major 
benefit is it makes it possible to build a lot of different targets on 1 
machine from 1 source pool, i.e. a MinGW build, a VC++ nmake build, a 
VC++ .sln build, etc.  For robust testing this is eventually going to be 
required.  i.e.  There's a limit on how often anyone is going to be 
willing to check all these different builds manually, they're going to 
have to be scripted someday.  CMake provides this multiple build 
directory functionality "for free" as long as one is obeying the paradigm.


Cheers,
Brandon J. Van Every
"The pioneer is the one with the arrows in his back."
                         - anonymous entrepreneur