[CMake] emitting CMakeLists.txt for TRY_COMPILE considered harmful
Summary: emitting a CMakeLists.txt is never parallel with standard
coding practices in the toplevel CMakeLists.txt. At a minimum, this
causes programmers to do everything 2 different ways. In the likely
case, the emission fails because it is fragile as quotes are consumed.
These kinds of problems can easily chew up a programmer's entire day, as
I did today.
I need to test whether Darcs source control commands actually work in
build environments. It's dicey under Windows because there's no Cygwin
version of Darcs, just a Windows native version. That would seem good
for Windows people, but the Windows Command Prompt, Cygwin shell, MSYS
shell, and the Visual Studio shell are all distinct build environments.
They don't share the same search paths, and they don't understand each
other's path conventions. So, aiming the right path at the right shell
and tool is highly problematical.
I have working code for this problem, targeted at CMake 2.4.3. In that
version, I simply ducked all the problems. I used WORKING_DIRECTORY as
much as possible so that I wouldn't have to use the Darcs
--repodir=E:\devel\src\chicken command option. I resorted to such
workarounds after 3 days of head scratching. The head scratching did
have a productive outcome, however: Brad implemented the VERBATIM
feature in reaction to my problem. Unfortunately, then I went into
survival mode and was unable to allocate time to trying out VERBATIM
while CMake 2.4.4 was still in beta.
Come CMake 2.4.4, I thought I would give VERBATIM a whirl. Oddly, I was
unable to get it to do anything constructive. I started having success
when I abandoned it, at least at the level of my topmost
CMakeLists.txt. Code like the following works fine:
# NATIVE_PATH reverses slashes and adds quotes for Windows
NATIVE_PATH(Chicken_SOURCE_DIR NATIVE_CHICKEN_SOURCE_DIR)
NATIVE_PATH(CHANGELOG_FILE NATIVE_CHANGELOG_FILE)
ADD_CUSTOM_TARGET(darcs-changelog ALL
COMMENT Generating ${NATIVE_CHANGELOG_FILE} from Darcs repository.
COMMAND ${DARCS_EXE} changes
--repodir=${NATIVE_CHICKEN_SOURCE_DIR} ${NATIVE_CHANGELOG_FILE}
)
But I cannot, for the life of me, emit similar code via a FILE(WRITE ...).
SOME_HAIRY_PATH(Chicken_SOURCE_DIR REPO)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/try-darcs/CMakeLists.txt
PROJECT(try-darcs)
ADD_CUSTOM_TARGET(try
COMMAND ${DARCS_EXE} changes --repodir=${REPO} --last=0
)
)
It doesn't matter what function I write for SOME_HAIRY_PATH. Doesn't
matter whether I add quotes, a level of escapes, more backslashes, less
backslashes, anything, everything, nothing. The problem is, the act of
emitting a file in and of itself consumes quotes. I should have strings
like --repodir=\E:\devel\src\chicken\ in the above example. But that
doesn't work because the single \ are interpreted as escapes for
letters, giving CMake parse errors.
--repodir=\E:\\devel\\src\\chicken\ writes out to the file and doesn't
generate parse errors, but the \\ aren't transformed into \, they stay
as \\. So Darcs barfs on them.
VERBATIM didn't seem to solve this. Did I miss how it was supposed to
be used? Or was FILE(WRITE ...) consumption not considered?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Makefile modification
Repost: Hi, Bill! I'm try to use CMake with Code Warrior for Nitendo DS. It seems that CW uses standard make-files. But in project makefile must be included two files There are: include$(NITROSDK_ROOT)/build/buildtools/commondefs include$(NITROSDK_ROOT)/build/buildtools/modulerules Why does the project need those files? I would not expect them to be compatible with the rest of the cmake makefiles. What is in them that you need to do? First file contains various settings for this platform. Compiler name, compiler path, libraries for linker and so on. I'm beginner in working with makefiles. But I believe second file contains some targets and settings for source files. These files also #include another files for various configurations -- Ilya Shvetsov (mailto:[EMAIL PROTECTED]) Programmer KranX Productions (http://kranx.com/) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Retrieve all directories?
Hello, is it in any way possible to retrieve the list of directories within a given directory and store it into a variable? I'm looking for something like FILE(GLOB ... ) or FILE(GLOB_RECURSE...) that collects directory names instead of files. Thanks in advance Timo ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Makefile modification
Ilya Shvetsov wrote: Repost: Hi, Bill! I'm try to use CMake with Code Warrior for Nitendo DS. It seems that CW uses standard make-files. But in project makefile must be included two files There are: include$(NITROSDK_ROOT)/build/buildtools/commondefs include$(NITROSDK_ROOT)/build/buildtools/modulerules Why does the project need those files? I would not expect them to be compatible with the rest of the cmake makefiles. What is in them that you need to do? First file contains various settings for this platform. Compiler name, compiler path, libraries for linker and so on. I'm beginner in working with makefiles. But I believe second file contains some targets and settings for source files. These files also #include another files for various configurations Well, cmake should do all of that for you, set the compiler path and libraries. You really can not just mix makefiles like that. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Simple file copy
Thanks a lot! But the name CONFIGURE_FILE suggest it happens before the build. Is that so? I need to copy lib files after build! -Regards Martin L Martin L, Software Engineer / Architect (see also www.doxys.org) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Noulard Sent: 20. november 2006 19:29 To: CMake ML Subject: Re: [CMake] Simple file copy CONFIGURE_FILE(InputFile OutputFile COPYONLY) 2006/11/20, Martin Lütken [EMAIL PROTECTED]: Is it possible to simply copy files in cmake ? Or do I need to make a custom command? -Martin L Martin L, Software Engineer / Architect (see also www.doxys.org) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.D. Yamokoski Sent: 20. november 2006 15:53 To: cmake@cmake.org Subject: [CMake] Problem with Debug target options in VS8 Greetings, First I just want to say that I am a new cmake user and I am loving it! Great stuff! On to my issue, I apologize if this is a known issue or posted before, but I have had some trouble with with Cmake and VS8. The error I get is that cmake generates two incompatible compiler options for the Debug target of a certain open source library. Specifically, VS complains: cl : Command line error D8016 : '/O2' and '/RTC1' command-line options are incompatible I know what those options are and why they are incompatible but what I don't know is whether this is a cmake problem or an issue with this project's cmake files. I have already talked to the developers of the library I am trying to compile. They state that they only ever set CMAKE_BUILD_TYPE to 'Debug' for Windows but certainly don't set any flags anywhere. For the time being, I have circumvented the problem by changing my target to a Release build. But I would like to find out how to turn off code optimization for the Debug build. Best regards, J.D. Yamokoski ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: RE: [CMake] Simple file copy
Original-Nachricht
Datum: Wed, 22 Nov 2006 15:22:53 +0100
Von: Martin Lütken [EMAIL PROTECTED]
An: Eric Noulard [EMAIL PROTECTED], CMake ML cmake@cmake.org
Betreff: RE: [CMake] Simple file copy
Thanks a lot!
But the name CONFIGURE_FILE suggest it happens before the build.
Is that so? I need to copy lib files after build!
Does INSTALL(FILES ... ) do what you want ?
You could also do ADD_CUSTOM_TARGET( ... POST_BUILD ${CMAKE_COMMAND} -E copy
...)
Bye
Alex
--
Ein Herz für Kinder - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Finding out the Endianness of a system at CMake config time
I have recently joined a project where I am to do some coding. The code base is cross platform HPC type code and the original coders have defined their own little/big endian #defines (L_ENDIAN B_ENDIAN). They pass this into the compiler via -DL_ENDIAN during compiles. Is there a way to automatically have cmake figure this out for me? Right now I have an OPTION() clause in my CMakeLists.txt file to select the right value.. which is stupid and error prone but it worked to boot strap the process for the moment. Any hints would be appreciated.. -- Mike Jackson Senior Research Engineer Innovative Management Technology Services ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Brandon J. Van Every wrote: If you macrotize all the CMake code out of existence, then people have to dig through your code and documentation to understand what's going on. If people need help with what's going on, they have to ask you, because nobody else in the CMake community knows what's going on. This makes you a single point of failure for other people's projects; many people won't use stuff if there's only 1 guy who supports it. And? of course I know that. I didn't do it for fun, I've created all these macros because I need a build system as simple as possible with high level functionnalities and I think it can help people to switch to CMake if parts of it was integrated Why do I need something like this? OpenWengo integrates FFmpeg, cURL, OpenSSL, LibGaim, GLib, Boost, PortAudio, Qt4, TinyXML, oSIP, oRTP, eXosip + all the OS specific libs: DirectX, V4L, XVideo, ALSA, OSS, QuickTime... + in some extend IAXClient, Java libs, Objective-C, XUL/XPCOM... + of course we have a lot of internal libraries In the future we will integrate even more stuff: VNC, libjingle, GTK+... And everything should compile and work under Windows (MSVC), Linux (GCC) and MacOSX (GCC) We have more than 100 CMakeLists.txt and for now we have 2 build system: CMake + SCons (an extended version by us). In the past we were using QMake aswell. A clean checkout from the trunk is more than 200MB and something like 10 people fulltime are working on it... This is an improvement over CMake so don't you think there might be some nice ideas and improvements that can be added to CMake? -- Tanguy Krotoff [EMAIL PROTECTED] http://openwengo.org ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMake 2.4.4 available for download
Hello all,
I guess there has been a change in the interpretation of optimized and
debug libraries used in the TARGET_LINK_LIBRARIES command.
In 2.4.3 the following line successfully produced a link to the Qt
libraries:
TARGET_LINK_LIBRARIES(JCore optimized ${QT_QT_LIBRARY} debug
${QT_QT_LIBRARY_DEBUG})
It still does on my windows system. But on Unix it links to _both_ libraries
resulting in the following entry to build.make:
---
...
# External object files for target JCore
JCore_EXTERNAL_OBJECTS =
...
framework/JCore/libJCore.so: .../libqt-mt.so
framework/JCore/libJCore.so: .../libqt-mtd.so
framework/JCore/libJCore.so: framework/JCore/CMakeFiles/JCore.dir/build.make
...
---
With cmake 2.4.3 build.make does not even have any line that includes
libqt-mt.so like with 2.4.4 above.
If making the target JCore make issues a warning like this:
... no rule to make target '.../libqt-mtd.so' required by '.../libJCore.so'
What could have caused this wrong behaviour? Can it be fixed quickly? If
not, is there a work-around?
It does link correctly if I do not differentiate between optimized- and
debug-libs like this:
TARGET_LINK_LIBRARIES(JCore ${QT_QT_LIBRARY})
Cheers
Marco
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Finding out the Endianness of a system at CMake config time
May be you could use TRY_RUN to detect endianity
with something like:
TRY_RUN(
ENDIANESS_RESULT
ENDIANESS_COMPILE
/tmp/
${CMAKE_CURRENT_SOURCE_DIR}/make/endianess.c
OUTPUT_VARIABLE ENDIANESS_OUT
)
MESSAGE(STATUS ENDIANITY is :${ENDIANESS_OUT})
endianess.c is attached.
The trouble I have is that I expected to have
my endianess program output in ${ENDIANESS_OUT}
but I get too much including
compilation process ouput.
-- ENDIANITY is :gmake[1]: Entering directory `/tmp/CMakeFiles/CMakeTmp'
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
gmake[2]: Entering directory `/tmp/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /tmp/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object
CMakeFiles/cmTryCompileExec.dir/home/noularde/TSP/tsp_all/tsp/src/util/libutil/endianess.o
/usr/bin/gcc -o
CMakeFiles/cmTryCompileExec.dir/home/noularde/TSP/tsp_all/tsp/src/util/libutil/endianess.o
-c /home/noularde/TSP/tsp_all/tsp/src/util/libutil/endianess.c
Linking C executable cmTryCompileExec
/usr/bin/cmake -P CMakeFiles/cmTryCompileExec.dir/cmake_clean_target.cmake
/usr/bin/gcc -fPIC
CMakeFiles/cmTryCompileExec.dir/home/noularde/TSP/tsp_all/tsp/src/util/libutil/endianess.o
-o cmTryCompileExec -rdynamic
gmake[2]: Leaving directory `/tmp/CMakeFiles/CMakeTmp'
gmake[1]: Leaving directory `/tmp/CMakeFiles/CMakeTmp'
LITTLE_ENDIAN
I have played with STRING(REFEX MATCH ...)
with no success.
I never use TRY_RUN but now that I have tried it I wonder
how to use it if I am not able to separate compile output
from RUN output?
2006/11/22, Mike Jackson [EMAIL PROTECTED]:
I have recently joined a project where I am to do some coding. The code base
is cross platform HPC type code and the original coders have defined their
own little/big endian #defines (L_ENDIAN B_ENDIAN). They pass this into
the compiler via -DL_ENDIAN during compiles.
Is there a way to automatically have cmake figure this out for me? Right now
I have an OPTION() clause in my CMakeLists.txt file to select the right
value.. which is stupid and error prone but it worked to boot strap the
process for the moment.
Any hints would be appreciated..
--
Mike Jackson Senior Research Engineer
Innovative Management Technology Services
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Erk
#include stdio.h
int
main(int argc, char** argv) {
int i = 0;
((char*)i)[0] = 1;
if (1 == i) {
printf(LITTLE_ENDIAN\n);
} else {
printf(BIG_ENDIAN\n);
}
}
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Simple file copy
Martin Lütken wrote:
Thanks a lot!
But the name CONFIGURE_FILE suggest it happens before the build.
Is that so? I need to copy lib files after build!
I didn't really understand the rest of the post; perhaps some context
got snipped. Going by the subject line, I think what you want is an
ADD_CUSTOM_COMMAND or ADD_CUSTOM_TARGET containing:
COMMAND ${CMAKE_COMMAND} -E copy myfile mydestination
or perhaps
COMMAND ${CMAKE_COMMAND -E copy_if_different in-file out-file
You can type cmake -E on the command line to learn what all the -E
options are. The -E option is in the documentation, but the things you
can do with -E are not. I filed this as bug #3778; it has been assigned
to someone, but nothing has happened on it yet. I'll ping the bug since
this came up on the list.
It's also possible that what you really want are INSTALL commands,
depending on what you want to do. Read the docs for those.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Finding out the Endianness of a system at CMake config time
Eric Noulard wrote:
May be you could use TRY_RUN to detect endianity
with something like:
TRY_RUN(
ENDIANESS_RESULT
ENDIANESS_COMPILE
/tmp/
${CMAKE_CURRENT_SOURCE_DIR}/make/endianess.c
OUTPUT_VARIABLE ENDIANESS_OUT
)
MESSAGE(STATUS ENDIANITY is :${ENDIANESS_OUT})
endianess.c is attached.
The trouble I have is that I expected to have
my endianess program output in ${ENDIANESS_OUT}
but I get too much including
compilation process ouput.
The format is:
TRY_RUN(RUN_RESULT_VAR COMPILE_RESULT_VAR
bindir srcfile CMAKE_FLAGS Flags
COMPILE_DEFINITIONS flags
OUTPUT_VARIABLE var
ARGS arg1 arg2..
Write a test called IsBigEndian.c. When run, have it return either 0 or
1. Get the result with RUN_RESULT_VAR. Use it and be happy. Caveat: 0
is typically regarded as a *success* code when running a system tool, so
go over your bit twiddling convention carefully. I can't remember what
I did in Chicken's StackGrowsDownward.c, only that Felix caught me doing
it backwards and I was surprised.
Use COMPILER_RESULT_VAR to make sure your code actually worked, and
throw errors if it doesn't. Your code should always compile; this would
be a strange / severe / exceptional error.
OUTPUT_VARIABLE isn't useful for this kind of problem. It gives you all
the stdout stuff and you don't want that.
A complete working example of this kind of code is available in the
Chicken CMake build. Search CMakeLists.txt for STACK_GROWS_DOWNWARD.
http://www.call-with-current-continuation.org . I think I'll document
it more, so that the return code conventions are less confusing.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake 2.4.4 available for download
wedekind wrote:
Hello all,
I guess there has been a change in the interpretation of optimized and
debug libraries used in the TARGET_LINK_LIBRARIES command.
In 2.4.3 the following line successfully produced a link to the Qt
libraries:
TARGET_LINK_LIBRARIES(JCore optimized ${QT_QT_LIBRARY} debug
${QT_QT_LIBRARY_DEBUG})
It still does on my windows system. But on Unix it links to _both_ libraries
resulting in the following entry to build.make:
---
...
# External object files for target JCore
JCore_EXTERNAL_OBJECTS =
...
framework/JCore/libJCore.so: .../libqt-mt.so
framework/JCore/libJCore.so: .../libqt-mtd.so
framework/JCore/libJCore.so: framework/JCore/CMakeFiles/JCore.dir/build.make
...
---
With cmake 2.4.3 build.make does not even have any line that includes
libqt-mt.so like with 2.4.4 above.
If making the target JCore make issues a warning like this:
... no rule to make target '.../libqt-mtd.so' required by '.../libJCore.so'
What could have caused this wrong behaviour? Can it be fixed quickly? If
not, is there a work-around?
It does link correctly if I do not differentiate between optimized- and
debug-libs like this:
TARGET_LINK_LIBRARIES(JCore ${QT_QT_LIBRARY})
There was a change What version of QT are you using? Also, what
FindQt are you using?
What is the value of QT_QT_LIBRARY?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Finding out the Endianness of a system at CMake config time
On 2006-11-22 19:00, Eric Noulard said: Sorry for my dummy answer: 1) There is a TestBigEndian.cmake already shipped with CMake (as of 2.4.3) 2) I should have checked ENDIANESS_RESULT and not ENDIANESS_OUT At the risk of repeating myself... :) Remember that using TRY_COMPILE/TRY_RUN or any method that runs code on the build machine breaks cross-compilation. Notably, if you want to build a Universal Binary for Mac OS X, you guarantee that it will not work on one architecture. Maybe it's not important for some people, but it's good to be aware of it. Since a compiler knows what CPU it is compiling for (by definition), I think a better solution, in general, is to query the compiler. gcc for example always #defines __BIG_ENDIAN__ or __LITTLE_ENDIAN__ as appropriate. Other compilers probably do likewise, but I am not aware of a compiler independent way to determine this, which is very unfortunate. Also, with posix, there are APIs like ntohl() that always do the right thing. On some systems, sys/param.h indicates endianness. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Finding out the Endianness of a system at CMake config time
Sean McBride wrote: On 2006-11-22 19:00, Eric Noulard said: Sorry for my dummy answer: 1) There is a TestBigEndian.cmake already shipped with CMake (as of 2.4.3) 2) I should have checked ENDIANESS_RESULT and not ENDIANESS_OUT At the risk of repeating myself... :) Remember that using TRY_COMPILE/TRY_RUN or any method that runs code on the build machine breaks cross-compilation. Notably, if you want to build a Universal Binary for Mac OS X, you guarantee that it will not work on one architecture. Maybe it's not important for some people, but it's good to be aware of it. Since a compiler knows what CPU it is compiling for (by definition), I think a better solution, in general, is to query the compiler. gcc for example always #defines __BIG_ENDIAN__ or __LITTLE_ENDIAN__ as appropriate. Other compilers probably do likewise, but I am not aware of a compiler independent way to determine this, which is very unfortunate. Also, with posix, there are APIs like ntohl() that always do the right thing. On some systems, sys/param.h indicates endianness. The test itself is not so bad, and autoconf does tests like this as well. The problem is that gcc may define this stuff, but if you are going to work with any compiler, there is no standard for it. When cross compiling all try-runs should be invalidated, and the build system should get the answer some other way.However, TRY_COMPILE is always safe. It either compiles or it does not, it does not break anything with cross compiling. It is when you run things that you can get into trouble. For the mac, I would recommend a try_run, but then adding a special bit of ifdef MAC stuff to the configured .h file. #cmakedefine CMAKE_WORDS_BIGENDIAN #ifdef MAC #ifndef __BIG_ENDIAN__ #undef CMAKE_WORDS_BIGENDIAN #endif // end if big endian #endif // end if mac ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] first argument to qt_wrap_cpp() and qt_wrap_ui() unused ?
Hi, it seems to me the first argument to both qt_wrap_cpp() and qt_wrap_ui(), i.e. the project argument, is unused. I don't see any effect if I change it to something arbitrary, and from looking at the sources it also not used at all. Am I right with this ? If so, can you please mention this in the documentation ? Bye Alex -- Ein Herz für Kinder - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht! ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: emitting CMakeLists.txt for TRY_COMPILE considered harmful
Maybe the following is a better explanation of the pitfalls of emitting
a CMakeLists.txt.
This is taken from the current Chicken CMake build.
# CHANGELOG #
# A distribution archive (aka a tarball) will have ChangeLog already.
# A Darcs repository tree will not, however. We have to generate it.
#
# Note that as of Nov. 22nd, 2006, a Darcs package that understands
# Cygwin paths is not readily available. It is possible to compile
# Darcs from Haskell sources, but that requires GHC, which can be
# difficult to get working. The upshot is it's a PITA to access
# Darcs from Cygwin and hence to create a ChangeLog. It's possible,
# but one has to proceed carefully.
#
# Different shells can cause Darcs to fail. For instance, running a
# Windows native Darcs under a Cygwin shell can fail, because the
# Windows native Darcs doesn't understand Cygwin paths. A workaround
# is to avoid issuing any Cygwin path to Darcs, and instead use a
# WORKING_DIRECTORY, so that CMake handles some of its own paths and
# not Darcs.
#
# In principle, if we need to use a Darcs command, we should test
# whether Darcs is available and actually works. In practice, writing
# reliable tool tests in CMake 2.4.4 is painful.
#
# You cannot use EXECUTE_PROCESS to write a tool test. It executes in
# CMake's environment, not the actual build environment. For instance,
# let's say Darcs is available at the Windows command prompt.
# EXECUTE_PROCESS will say it works. However, it won't actually work
# under Visual Studio, because VS doesn't typically receive all the paths
# that the command prompt does.
#
# To write a tool test, Kitware expects one to emit a trivial CMakeLists.txt
# to a temporary subdirectory, and then TRY_COMPILE it. In practice, this
# approach is exceedingly fragile, due to quote consumption problems with
# FILE(WRITE ...) and with shells.
#
# What's really needed is an entirely different / better mechanism for
# tool testing. Something that's exactly parallel to the code we'd
# write here at the toplevel, so that there are no weird extraneous
# considerations.
SET(CHANGELOG_FILE -NOTFOUND)
IF(EXISTS ${Chicken_SOURCE_DIR}/_darcs)
FIND_PROGRAM(DARCS_EXE darcs)
IF(DARCS_EXE)
FILE(REMOVE_RECURSE ${CMAKE_CURRENT_BINARY_DIR}/try-darcs)
# Note the need to escape any quotes that are part of the file output.
# I cannot figure out how to get code emitted in a file to quote
properly.
# Consequently, we use a WORKING_DIRECTORY to duck the issue.
#
# Note that the \${DARCS_EXE}\ quotes are necessary here, even though
# they are not generally necessary in the toplevel CMakeLists.txt, i.e.
# this file you're reading now. At this level, whitespace is
escaped, i.e.
# ${DARCS_EXE} = E:/Program\ Files/darcsdir-w32
# But once emitted, the whitespace escapes are lost. We get
# ${DARCS_EXE} = E:/Program Files/darcsdir-w32
# and of course Cygwin dies, as E:/Program isn't a valid command.
#
# Possibly this emission code should be replaced with a CONFIGURE_FILE
# template. Or else substitutions should be performed with
# STRING(CONFIGURE ...). Anything to get the quote / escape problems
# under control.
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/try-darcs/CMakeLists.txt
PROJECT(try-darcs)
ADD_CUSTOM_TARGET(try
WORKING_DIRECTORY \${Chicken_SOURCE_DIR}\
COMMAND \${DARCS_EXE}\ changes --last=0
)
)
TRY_COMPILE(DARCS_WORKS
${CMAKE_CURRENT_BINARY_DIR}/try-darcs
${CMAKE_CURRENT_BINARY_DIR}/try-darcs
try-darcs try
)
IF(DARCS_WORKS)
SET(CHANGELOG_FILE ${CMAKE_CURRENT_BINARY_DIR}/ChangeLog)
# Custom commands have the format:
#
# COMMAND command1 [args...]
#
# command1 has to be a CMake path. This is not documented in
CMake 2.4.4.
# Think of command1 as receiving special interpretation and not
really
# being a custom command, i.e. you're not free to do what you like.
#
# Also, if command1 is an absolute pathname, it must have whitespace
# handled properly. The results of CMake Find* commands always have
# whitespace handled properly, but if you're homebrewing your own
# pathnames, be careful.
#
# Other path statements in [args...] need to be paths that your
# tool understands. This means you'll need native paths, unless your
# tool happens to like CMake paths.
#
# As of November 22, 2006, there is no Cygwin version of Darcs.
# Instead, one typically has a Windows native version of
# Darcs running under a Cygwin shell. This Windows native Darcs
# does not understand Cygwin paths, i.e.
--repodir=/cygdrive/c/whatever
# will fail.
#
# Ideally, we'd complete the implementation of WINDOWS_PATH and
