Am 07.12.2012 09:52, schrieb Trevor Davel (Twylite):
> 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:
> 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.
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
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).