Re: CMakeLists.txt CONFIGURE_FILE bug and paradigm

Thanks again, I've followed your recommendation.


cheers,
felix

On 12/11/05, Brandon J. Van Every <bvanevery@xxxxxxxxx> wrote:
> 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
>
>
> _______________________________________________
> Chicken-users mailing list
> Chicken-users@xxxxxxxxxx
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>