Nathan A. Smith wrote:
On Sun, 2006-09-17 at 04:34 -0700, Brandon J. Van Every wrote:Brandon J. Van Every wrote:My CMakeLists.txt for the Chicken Scheme project has lots of examples of ADD_CUSTOM_COMMAND to drive a language (Scheme) that is not C/C++. That might be useful to you. A development snapshot is available at http://www.call-with-current-continuation.org/index.html If it doesn't build for you - and I suspect that likely, as we've fixed a number of bugs since that snapshot - e-mail me if you want a more current distribution.A new snapshot was recently released, incorporating the bugfixes. It should build just fine. http://www.call-with-current-continuation.org/chicken-2.432.tar.gzThanks a lot for the example, It really cleared up most things. I just have one question though. do all ADD_CUSTOM commands get run in-source? No, your default working directory is your CMAKE_CURRENT_BINARY_DIR. That's why I often haven't qualified the actual COMMAND. Sometimes I do though. In particular, for tools that you generate in the course of your build, you're going to need things like GET_TARGET_PROPERTY(CHICKEN_BOOT_EXE chicken-boot LOCATION). Different platforms will have different generated directories; for instance, Microsoft Visual Studio will create Debug and Release directories. So, you can't hardwire the directory of a generated tool, as it can change. The reason I ask, CMAKE_CURRENT_BINARY_DIR == CMAKE_CURRENT_SOURCE_DIR which isn't what I want.... Well if you don't want that, build out-of-source. Realize this is the user's choice, however. You can make errors by assuming things will always be built in-source, and you can make errors by assuming things will always be built out-of-source. That said, I think everyone should canonically design for out-of-source, as that's what you'll have the most trouble with. Cheers, Brandon Van Every |
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake