From: Harald O. <har...@el...> - 2012-12-07 09:07:15
|
Am 07.12.2012 09:52, schrieb Trevor Davel (Twylite): > 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. Trevor, thank you for the information and the work. I personally whant to help to get tcl8.6.0 released. Thats why I work on the test in the build environment. The IMHO function for the build people is, that a "make test" on tcl just runs all tests of all bundled packages. I will not try CMake, as it will not bring us further to the aim. I thought, CMake will use anything existant and there is no additional work needed... There should be a general decision like: 1) we use CMAKE and MSVC++ 6,7,8,9,10 (any set of them) 2) we use NMAKE and MSVC++ 6,7,8,9,10 (any set of them) 3) we use cygwin/msys make and MSVC++ 6,7,8,9,10 (any set of them) 4) we don't use MSVC and only gcc My personal experience is, that the msvc and Makefile.vc results are just good, specially in result size (factor 3 compared to mingw). This might be due to the fact, that the c runtime dll is not linked statically as it is always present. This is a +MSVC reason for me. If we don't have any active experts with Makefile.vc left, we should perhaps go to solution 3 (which I never tried). Thank you, Harald |