From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 08:53:22
|
Hi, On 2012/12/07 10:23 AM, Harald Oehlmann wrote: > Am 07.12.2012 08:47, schrieb Trevor Davel (Twylite):> Hi, >> Yep, me too ;) But to be honest I'd rather be building with CMake, and >> I don't care much about the ability to build extensions against an >> installed runtime (rather than against sources and binaries in a build >> environment), because that's mostly broken with MSVC anyway. > How does the CMAKE build work ? > Should we pass from nmake to cmake ? I'd love to use CMake rather than NMake for Windows builds. There has been some support and resistance to the idea when I've raised it before, and there has been other work on a cross-platform CMake build. The CMake build (as I have implemented it) uses CMake variables to communicate between the CMakefiles. So once you've built Tcl every subsequent CMakefile in the build knows where to find the Tcl include paths and what libraries or stubs to link against. Once you've build Tdbc every subsequence CMakefile (like the drivers) knows where to find the Tdbc includes and libs. I've set up my CMakefiles to be simple to maintain (even with limited knowledge of CMake), and they have proven remarkably robust in the face of changes to both the Tcl build and the build environment (e.g. the NMake rules.vc must be updated every time a new MSVC is released, and this change must be propagated to all extensions). If you're interested you can find my CMakefiles at http://dev.crypt.co.za/coffee/index (last updated around September, and expecting the old TDBC repository layout). The latest CMakefile for Tcl is here: http://dev.crypt.co.za/coffee/artifact/4fd7782a8d6412a7ef5cb5a1548d501e1b67bbc6 if you want to take a quick look. Oversell warning: don't let anything I've said above lead you to believe that this is a mature solution ;) There is currently no support for testing, there should be more knobs for build configuration, and the 'protocol' for communicating information between CMakefiles needs to be explicitly defined (it's rather ad hoc at the moment). In theory saving parts of the CMake cache into a build configuration file (like tclConfig.sh, but specific to CMake builds) will allow building against an installed Tcl rather than sources+build, but I've never implemented this. >>> If the nmake crowd can live with fragile warnings not to build/test >>> in paths with spaces, I'm not going to more effort to overrule that. > Yes, but this is another purpose. > The test suite will tell you, if you have done something wrong in your > code. Both tests are helpful. I agree, although my work process tends to be different (I directly run 'Debug_VC10\tclsh86t.exe ..\tests\mytest.test' from the command line, rather than 'nmake test'), so I don't miss the functionality; but I understand how other people find it useful. > At least, I tried to get the test suite work in the installation folder, > which tells you, if the build is correct (and stresses your nerves to > make this work). Trick: copy the tcltest.exe to the install folder and run with that ;) To my knowledge all of the problems with testing in the install environment have been ironed out recently. Regards, Twylite |