From: Harald O. <har...@el...> - 2012-12-05 16:07:57
|
This checkin: http://core.tcl.tk/tdbc/info/7f5817340f of branch td-win-tea of tdbc on core.tcl.tk does the following steps for tcl8.6.0 bundling using the msvc++ compiler and Makefile.vc: - tdbc: - Install development files - tdbc::odbc - Builds standalone and when bundled - Test invokation works. For me, only sqlite worked due to missing odbc drivers. There are some test errors which might be addressed later. I tested both on a total checkout and when I copied both Makefiles into the tcl8.6.0rc2 tree. I suppose, the tdbc::odbc makefile may be used as a starting point for mysql and postgresql Harald |
From: Donald G P. <don...@ni...> - 2012-12-06 16:07:52
|
On 12/05/2012 11:08 AM, Harald Oehlmann wrote: > This checkin: > > http://core.tcl.tk/tdbc/info/7f5817340f > > of branch td-win-tea of tdbc on core.tcl.tk > does the following steps for tcl8.6.0 bundling using the msvc++ compiler > and Makefile.vc: > > - tdbc: > - Install development files > - tdbc::odbc > - Builds standalone and when bundled > - Test invokation works. > For me, only sqlite worked due to missing odbc drivers. > There are some test errors which might be addressed later. > > I tested both on a total checkout and when I copied both Makefiles into > the tcl8.6.0rc2 tree. I merged these patches into the trunks of tdbc and tdbcodbc. > I suppose, the tdbc::odbc makefile may be used as a starting point for > mysql and postgresql I'm working on that. As I go I notice that tdbcodbc/win/makefile.vc is using the directory names under tcl/pkgs/ to find things. We want to avoid that. Maybe how the Makefile.in handles things can be copied? I'm going ahead with what you've given, since fragile support is better than no support at all. At least I think so for now. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Harald O. <har...@el...> - 2012-12-06 16:30:41
Attachments:
tdbcConfig.sh
|
Am 06.12.2012 17:07, schrieb Donald G Porter: > I merged these patches into the trunks of tdbc and tdbcodbc. Thank you ! > I'm working on that. Thank you very much for that. There is much room for improvement... > As I go I notice that tdbcodbc/win/makefile.vc > is using the directory names under tcl/pkgs/ to find things. We want > to avoid that. Maybe how the Makefile.in handles things can be copied? The makefile tests the two different positions for TDBC (bundled/standalone). As I understood, tdbc and drivers will be separated (and will propably have different versions). There are separated repos now... I suppose, the best would be to access the tdbcConfig.sh file. The tdbcConfig.sh has two remaining issues: TDBC_BUILD_LIBRARY_PATH : slash/backslash issue (hardcoded in template) TDBC_BUILD_STUB_LIB_SPEC, TDBC_BUILD_STUB_LIB_PATH : relative paths A current tdbcConfig.sh is attached. I have no idea how Makefile.in works at this point. I only found some variables which come from tdbcConfig.sh. I suppose, it relies on the fact that tdbc is installed and thus the include files and stub is in the tcl place (which is not the case in the bundled build). > I'm going ahead with what you've given, since fragile support is better > than no support at all. At least I think so for now. I agree. Lets start... Harald |
From: Donald G P. <don...@ni...> - 2012-12-06 16:52:35
|
On 12/05/2012 11:08 AM, Harald Oehlmann wrote: > I suppose, the tdbc::odbc makefile may be used as a starting point for > mysql and postgresql It appears to me that your `make test` targets are not robust to paths that contain spaces. You'll want to make use of [list ...] quoting when constructing the [package ifneeded] scripts. Another possibility is copying what tdbcsqlite3 MSVC support has done, which apparently doesn't need the -load option support to get `make test` to work? I'm going to copy/modify what you have now. When you fix tdbcodbc, please copy your fix over to the other drivers too. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Harald O. <har...@el...> - 2012-12-06 17:03:14
|
Am 06.12.2012 17:52, schrieb Donald G Porter: > It appears to me that your `make test` targets are not robust to paths > that contain spaces. You'll want to make use of [list ...] quoting when > constructing the [package ifneeded] scripts. Another possibility is > copying what tdbcsqlite3 MSVC support has done, which apparently doesn't > need the -load option support to get `make test` to work? Thank you. I am aware of this as I have thrown out the list commands. I took the code in "Makefile.in" and the existing code and fiddled until it worked. I have replaced the list commands by hardcoded curly braces which should lead to the same result. I have tried it without the load command and I failed. Are you shure, the SQLite tests work with MSVC ? > I'm going to copy/modify what you have now. When you fix tdbcodbc, > please copy your fix over to the other drivers too. The current state is the best I could give. It is far away from good but, at least, it works in some cases... I hope, someone else could care... Harald |
From: Donald G P. <don...@ni...> - 2012-12-06 17:30:35
|
On 12/06/2012 12:03 PM, Harald Oehlmann wrote: > Am 06.12.2012 17:52, schrieb Donald G Porter: >> It appears to me that your `make test` targets are not robust to paths >> that contain spaces. You'll want to make use of [list ...] quoting when >> constructing the [package ifneeded] scripts. Another possibility is >> copying what tdbcsqlite3 MSVC support has done, which apparently doesn't >> need the -load option support to get `make test` to work? > > Thank you. I am aware of this as I have thrown out the list commands. > I took the code in "Makefile.in" and the existing code and fiddled until > it worked. > I have replaced the list commands by hardcoded curly braces which should > lead to the same result. Dear God no. If that worked, you'd see Tcl scripts using it, instead of [list ...]. Non-broken ones I mean. > I have tried it without the load command and I failed. > Are you shure, the SQLite tests work with MSVC ? > >> I'm going to copy/modify what you have now. When you fix tdbcodbc, >> please copy your fix over to the other drivers too. > > The current state is the best I could give. > It is far away from good but, at least, it works in some cases... > I hope, someone else could care... Empirically you and Jos Decoster are the only folks who complain about ability to build using MSVC (maybe Twylite too?). I imagine your voices represent multitudes, but still those are the only folks I have evidence for caring about nmake builds. FWIW, I have "negative" care for them. They cause a whole lot of trouble for me getting releases done. I have no reasonable way to test them. Their presence always adds at least an additional RC round if not two or three. I'd be overjoyed to see them tossed overboard. 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. Perhaps with 8.6.0 made real by a release, the other crowds who care about nmake builds may show up. We'll see. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 07:47:39
|
Hi, On 2012/12/06 07:29 PM, Donald G Porter wrote: > Empirically you and Jos Decoster are the only folks who complain about > ability to build using MSVC (maybe Twylite too?). I imagine your > voices represent multitudes, but still those are the only folks I have > evidence for caring about nmake builds. 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. > 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. I can live with this. I don't test in the build/test environment anyway, because it gives a false sense of security. Tests need to be executed using the final installed configuration, and preferably on a system without MSVC installed. This way you get to confirm that you included the correct C runtime in your install, that DLLs and packages can be located correctly, and that core functionality can be reasonable expected to work in a production environment. Regards, Twylite |
From: Harald O. <har...@el...> - 2012-12-07 08:22:48
|
Am 07.12.2012 08:47, schrieb Trevor Davel (Twylite):> Hi, > > On 2012/12/06 07:29 PM, Donald G Porter wrote: >> Empirically you and Jos Decoster are the only folks who complain about >> ability to build using MSVC (maybe Twylite too?). I imagine your >> voices represent multitudes, but still those are the only folks I have >> evidence for caring about nmake builds. > 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 ? > >> 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. > I can live with this. I don't test in the build/test environment > anyway, because it gives a false sense of security. Tests need to be > executed using the final installed configuration, and preferably on a > system without MSVC installed. This way you get to confirm that you > included the correct C runtime in your install, that DLLs and packages > can be located correctly, and that core functionality can be reasonable > expected to work in a production environment. 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. 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). Harald |
From: Jos D. <jos...@gm...> - 2012-12-07 08:37:44
|
On Fri, Dec 7, 2012 at 9:23 AM, Harald Oehlmann <har...@el... > wrote: > > How does the CMAKE build work ? > Should we pass from nmake to cmake ? > > If Tcl would build on all platforms with cmake, I'd agree to let the nmake build go. Otherwise cmake would be yet another build method. |
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 |
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 |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 09:15:20
|
Hi, On 2012/12/07 10:37 AM, Jos Decoster wrote: > On Fri, Dec 7, 2012 at 9:23 AM, Harald Oehlmann > <har...@el... <mailto:har...@el...>> wrote: > > > How does the CMAKE build work ? > Should we pass from nmake to cmake ? > > If Tcl would build on all platforms with cmake, I'd agree to let the > nmake build go. Otherwise cmake would be yet another build method. I'd really like to convince you that CMake should replace NMake for Windows only (thus not 'another'). A cross-platform cmake build by comparison would be 'another' build method to maintain, because I can't see everyone agreeing to drop autoconf. I've looked at the work that Clifford Yapp has done on a cross-platform CMake build (http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2011/CliffordYapp/tcltk_cmake_paper.pdf) and it's really good, but it tries to shoehorn the Windows build into a Unix model, and in doing so it reproduces a bunch of the complexity and problems of the current (autoconf + NMake) approach. The build - and particularly the install - needs of Windows are different from *nix. You _can_ support both in one build system, but when you do you end up complicating the *nix build and getting an un-Windowsy result on Windows. You also end up with frequent breaks of the Windows build when developers on a *nix platform make non-trivial updates to the build files (and that's a problem in Tcl where there are relatively few developers building on Windows). The main reason why I started work on a CMake build was to be able to build Tcl extensions. Tcl went through about a four-year period of chronic build failures on Windows (from 2007 to 2011 I could not once check out HEAD/trunk from Tcl, Tk, Itcl, Thread and get a successful build+install using NMake), and many other extensions had woefully out of date NMake support (or none at all). I'm no stranger to NMake, but getting an extension building and installing with it is not a task for the faint of heart. Even maintaining an NMake build over time is tricky. I wanted something that I could easily use to get extensions building, and that would be easy for a non-Windows developer to set up (with a high chance of success). That is why Coffee (my CMake builds) focuses on _really simply_ CMakefiles and targets Windows only. The CMakefile feels more like a config.in than a Makefile.in. You can't achieve that level of simplicity in a cross-platform build. TL;DR: replace NMake with CMake, then we have the same number of supported build methods, but the build is easier to maintain on Windows and supports more compliers. Regards, Twylite |
From: Harald O. <har...@el...> - 2012-12-07 09:30:37
|
Am 07.12.2012 10:14, schrieb Trevor Davel (Twylite): > TL;DR: replace NMake with CMake, then we have the same number of > supported build methods, but the build is easier to maintain on Windows > and supports more compliers. I am not at all against CMake. I just want: - have a 100% relyable windows build - get tcl 8.6.0 out (help mainly Donald) If I can contribute to any of those aims, and if CMake would help, I am ready. Trevor, if you could refine my nmake test target I would be happy. As you see, Donald was not so satisfyed by my work here and I am at my end... Sometimes, the hard way must be gone, sorry... Thank you, Harald |
From: Jos D. <jos...@gm...> - 2012-12-07 09:23:43
|
Hi Trevor, I can see your point now about the cmake. I'll give it a try. You are right the nmake build is a hard to fight monster, any replacement making that simpler is a good thing. Would building static tclsh and libs be possible in the cmake you're planning? Jos. On Fri, Dec 7, 2012 at 10:14 AM, Trevor Davel (Twylite) <tw...@cr... > wrote: > Hi, > > > On 2012/12/07 10:37 AM, Jos Decoster wrote: > > On Fri, Dec 7, 2012 at 9:23 AM, Harald Oehlmann < > har...@el...> wrote: > >> >> How does the CMAKE build work ? >> Should we pass from nmake to cmake ? >> >> If Tcl would build on all platforms with cmake, I'd agree to let the > nmake build go. Otherwise cmake would be yet another build method. > > I'd really like to convince you that CMake should replace NMake for > Windows only (thus not 'another'). > > A cross-platform cmake build by comparison would be 'another' build method > to maintain, because I can't see everyone agreeing to drop autoconf. > > I've looked at the work that Clifford Yapp has done on a cross-platform > CMake build ( > http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2011/CliffordYapp/tcltk_cmake_paper.pdf) > and it's really good, but it tries to shoehorn the Windows build into a > Unix model, and in doing so it reproduces a bunch of the complexity and > problems of the current (autoconf + NMake) approach. > > The build - and particularly the install - needs of Windows are different > from *nix. You _can_ support both in one build system, but when you do you > end up complicating the *nix build and getting an un-Windowsy result on > Windows. You also end up with frequent breaks of the Windows build when > developers on a *nix platform make non-trivial updates to the build files > (and that's a problem in Tcl where there are relatively few developers > building on Windows). > > The main reason why I started work on a CMake build was to be able to > build Tcl extensions. Tcl went through about a four-year period of chronic > build failures on Windows (from 2007 to 2011 I could not once check out > HEAD/trunk from Tcl, Tk, Itcl, Thread and get a successful build+install > using NMake), and many other extensions had woefully out of date NMake > support (or none at all). I'm no stranger to NMake, but getting an > extension building and installing with it is not a task for the faint of > heart. Even maintaining an NMake build over time is tricky. > > I wanted something that I could easily use to get extensions building, and > that would be easy for a non-Windows developer to set up (with a high > chance of success). That is why Coffee (my CMake builds) focuses on > _really simply_ CMakefiles and targets Windows only. The CMakefile feels > more like a config.in than a Makefile.in. You can't achieve that level > of simplicity in a cross-platform build. > > TL;DR: replace NMake with CMake, then we have the same number of supported > build methods, but the build is easier to maintain on Windows and supports > more compliers. > > Regards, > Twylite > > |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 09:37:59
|
Hi, On 2012/12/07 11:23 AM, Jos Decoster wrote: > I can see your point now about the cmake. I'll give it a try. You are > right the nmake build is a hard to fight monster, any replacement > making that simpler is a good thing. > > Would building static tclsh and libs be possible in the cmake you're > planning? Yes. I think it works right now if you build with BUILD_SHARED_LIBS=OFF, although I haven't tested that recently. e.g. cmake .. -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=%CD%\..\INSTALL Regards, Twylite |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 09:25:20
|
Hi, On 2012/12/07 11:07 AM, Harald Oehlmann wrote: > 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 agree with that approach, which is why I contributed the attempt at a makefile.vc for tdbcodbc. I would like to see a move to CMake in the longer term, but it won't help towards an 8.6.0 release. > There should be a general decision like: > 1) we use CMAKE and MSVC++ 6,7,8,9,10 (any set of them) Yes. In fact the CMake team made specific changes to support the path quoting needed for pkgConfig defines passed in from the build file, which require some really weird quoting in MSVC 6 and 8 project files. > 2) we use NMAKE and MSVC++ 6,7,8,9,10 (any set of them) What we have now. Painful to maintain, and doesn't allow Windows users to work in the MSVC IDE, use interactive debugging, use third-party memory checking tools, etc. > 3) we use cygwin/msys make and MSVC++ 6,7,8,9,10 (any set of them) Over the past couple of years the msys installer has been broken on and off for months. It is not acceptable to rely on a technology that is not itself reliable. Using msys also means requiring Windows developers to learn how to use a *nix shell prompt, maintain builds using autoconf (which is itself a black art), and not use the MSVC IDE and its facilities (as mentioned above). In short it's just keeps Windows as a second-class environment for Tcl development. Regards, Twylite |
From: Harald O. <har...@el...> - 2012-12-07 09:38:19
|
Am 07.12.2012 10:24, schrieb Trevor Davel (Twylite): > Hi, > > On 2012/12/07 11:07 AM, Harald Oehlmann wrote: >> 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 agree with that approach, which is why I contributed the attempt at a > makefile.vc for tdbcodbc. I would like to see a move to CMake in the > longer term, but it won't help towards an 8.6.0 release. > >> There should be a general decision like: >> 1) we use CMAKE and MSVC++ 6,7,8,9,10 (any set of them) > Yes. In fact the CMake team made specific changes to support the path > quoting needed for pkgConfig defines passed in from the build file, > which require some really weird quoting in MSVC 6 and 8 project files. > >> 2) we use NMAKE and MSVC++ 6,7,8,9,10 (any set of them) > What we have now. Painful to maintain, and doesn't allow Windows users > to work in the MSVC IDE, use interactive debugging, use third-party > memory checking tools, etc. > >> 3) we use cygwin/msys make and MSVC++ 6,7,8,9,10 (any set of them) > Over the past couple of years the msys installer has been broken on and > off for months. It is not acceptable to rely on a technology that is > not itself reliable. Using msys also means requiring Windows developers > to learn how to use a *nix shell prompt, maintain builds using autoconf > (which is itself a black art), and not use the MSVC IDE and its > facilities (as mentioned above). In short it's just keeps Windows as a > second-class environment for Tcl development. Thank you for the valueable summary. I agree and have put it on http://wiki.tcl.tk/20966 Harald |
From: Donald G P. <don...@ni...> - 2012-12-07 14:46:03
|
>> 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. > I can live with this. Ok, I was unaware that this is a documented and accepted limitation of the nmake builds. Apologies for not having that cultural awareness. I've heard it said that the surest way to produce stress is to demand responsibility without conferring authority. That's how I feel with the whole nmake business. I'm expected to make a Tcl release that has nmake builds working, but I'm unable to test that myself, and only minimally able to contribute to the task. I don't feel I have the power to command anybody to do it either. (hmmm... maybe now Jos as part of TCT hazing?) To make matters worse, there's a clear expectation that the bundled packages have nmake builds working too. And that's more than a blind maintenance task. That's adding something which hasn't been there before at all. And something which the upstreams have no interest in. So I'm grateful to the few interested souls who've made sure we make progress and deliver something. And forgive me when I get frustrated when I see those folks appear to give up and dump the problem back on me. Hey this is getting done for you, you know? I am not seriously considering actually disposing of the nmake system. That was not a plan, that was an expression of how I feel. All that said, I think the nmake improvements are in a state to put out RC3 and see what more testing can tell us. Hopefully soon, if we can get Bug 3588687 to come to a resolution. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-07 15:13:21
|
Hi, On 2012/12/07 04:45 PM, Donald G Porter wrote: >>> 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. > Ok, I was unaware that this is a documented and accepted limitation > of the nmake builds. Apologies for not having that cultural awareness. To clarify: I can't speak for other developers, but building in paths that have spaces in them is always a pain, and I don't know anyone who does it. The tests should run against an installed Tcl+extensions that is in a path with spaces in it, but I wouldn't expect 'nmake test' to do so. > I am not seriously considering actually disposing of the nmake system. > That was not a plan, that was an expression of how I feel. I think it does warrant serious discussion. The main stumbling point seems to be what to replace it with. If the Windows-based developers could agree on an approach, I think we would have a solution. > All that said, I think the nmake improvements are in a state to put > out RC3 and see what more testing can tell us. Hopefully soon, if > we can get Bug 3588687 to come to a resolution. I've just (this afternoon) done trunk builds of Tcl, Tk, Thread, Itcl, Tdbc, TdbcOdbc, and TdbcSqlite3 (build env is Windows 7 64-bit, building 32-bit binary using MSVC 10). All build and install cleanly, and all packages/extensions load into the installed interp. I haven't run tests yet, but I can confirm that tdbcodbc 'nmake test' doesn't work (it assumes that tdbc.tcl is in the same directory as the tdbc DLL, which isn't a valid assumption in the build environment). I'm not going to try and fix this - there are assumptions layered on assumptions about the locations of different bits. I can run tests/all.tcl through the installed tclsh.exe and get no failure against the Jet database. > To make matters worse, there's a clear expectation that the bundled > packages have nmake builds working too. And that's more than a blind > maintenance task. That's adding something which hasn't been there > before at all. And something which the upstreams have no interest in. Mmm. So as it turns out Sqlite3 (as opposed to tdbc::sqlite3) doesn't have a functional makefile.vc ... which makes building an entire Tcl distribution with Sqlite support using MSVC && !msys rather challenging. Regards, Twylite |
From: Donald G P. <don...@ni...> - 2012-12-07 15:29:15
|
On 12/07/2012 10:25 AM, Jos Decoster wrote: > Back in august, I used the attached makefile.vc <http://makefile.vc>, > nmakehlp.c and rules.vc <http://rules.vc> to build sqlite3 as a packages > with Tcl. I did not take care of getting those files in the sqlite3 repo. If they are not in 8.6.0rc2, then I botched something making the release I think. Will take care when generating rc3 to check. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Harald O. <har...@el...> - 2012-12-07 15:58:03
|
Am 07.12.2012 16:29, schrieb Donald G Porter:> On 12/07/2012 10:25 AM, Jos Decoster wrote: >> Back in august, I used the attached makefile.vc <http://makefile.vc>, >> nmakehlp.c and rules.vc <http://rules.vc> to build sqlite3 as a packages >> with Tcl. I did not take care of getting those files in the sqlite3 repo. > > If they are not in 8.6.0rc2, then I botched something making the > release I think. Will take care when generating rc3 to check. I can also confirm that the sqlite makefile.vc works in the bundled tcl8.6.0rc0-rc2. Jan Nijtmans has fixed an issue in msvchelp.c for that too. There are just no test cases so "make test" prints an error (which is IMHO ok). Donald, sorry for your experience. I can only say that I try what I can (what is the same for you). Thank you for that! Harald |