LV - 2009-10-28 07:50:11

I don't notice this bug, listed 2762041 , in the list above. Is it too hard, or deemed harmless enough, to not make it into the next release?

dkf - 2009-10-28 10:27:52

It's not too hard, and there's no reason at all to not fix it; we're just not currently planning to block the release until it is fixed. In fact, of the ones above some are probably not release blockers either, and shouldn't be prio9. From the perspective of the roadmap, it is the blocking issues that are critical...

LV - 2009-10-28 12:34:37

Okay, that makes sense. I just was uncertain how the determination of where the bug fixes stop and the release happens worked. Thanks DKF!

dkf - 2009-10-28 17:42:00

Sometimes prio9 bugs come and get fixed so fast they don't have time to show up here (as this list is manually maintained). For example issue#2888044 came and went too fast for me to note...

thomasmenez - 2009-11-30 13:29:00

Why not add SF queries links to have up-to-date bug lists ? And get rid of those 'manually maintained' tables...

Oustanding Tcl prio 9 open bugs

Oustanding Tk prio 9 open bugs

Note : I had to tweak SF URLs a bit (I actually removed the brackets) as this Wiki page was unable to display them correctly. Fortunately, those tweaked SF links still work that way.

dkf - 2009-11-30 08:50:29

The links in the summary table are live, and have been for a while. Or at least they work for me. Part of my reasoning for listing them here is as part of a "naming and shaming" exercise. It helped prompt me to nail a lot of the bugs that had been assigned to myself ...

Martyn Smith - 2010-03-27 10:00:55 Donal is there any particular reason why Schelte Bron's File selection dialog for Tile could not be used as the replacement for tk_getOpenFile, I use is in a few applications and have not had any problems so far ?

Maybe the license is not compatible it says # Copyright (C) Schelte Bron. Freely redistributable. And there does not seem to be a specific license file.

dkf - 2010-03-27 10:53:44

Quite apart from the fact that I'm not keen on having directories separate, I'd like to be able to do things like having a details view so that I can do things like sorting by file mtime.

I'm also taking the opportunity to work on changing the previously-existing megawidgets used to implement the dialog into more robust things. Who knows, the framework that comes out of that might be properly published in 8.7...

Martyn Smith - 2010-03-27 18:55 Have you looked at the little tool menu, I unselected 'Separate Folders' and then selected 'Detailed View' the sort/reverse sort by date and folders first options are also available. It only seems to be missing the click on the titles to change the sort order. Maybe treeview would look good here.

Schelte Bron - 2010-06-10 The license was just slapped on there as suggested by Joe English. Any license that makes it fit for inclusion in Tk is fine with me. I sent the code to Joe for exactly that purpose in the first place.

At the time I started writing the dialogs, ttk::treeview still had several serious shortcomings, especially on unix/linux. That has improved by now, so probably the code could be simplified and/or functionality enhanced by using ttk::treeview.

RLH - 2011-05-31 In a very real sense, does anybody really follow this?

DKF 2011-06-01: Not really. :-(

witek 2012-01-26 it seems 8.6 is approaching asymptotically and never really comes.

APE 2012-03-27 : Did you notice that the 8.6 development started nearly 4 years ago ? It could be great if we can have an update of the schedule to know when it will be available. Thanks !

MG Are there any recent 8.6 Tclkits available? I found a "tclkit86b1.2.exe" for Windows, but it predates the feature I wanted 8.6 for (native/built-in IPv6 support), and I can't find anything more recent. Not sure if anyone is actually building them while 8.6 is still in beta, but if so I'd be very grateful for a link (for Windows and Linux, ideally). Thanks. :)

RLE (2011-06-01) Tclkit Kitgen Build System will build 8.6 Tclkits, but I don't know if the version it builds includes what you desire. On Linux it works quite well, I built some 8.6 tclkits with it a month or so ago and it worked fine once I updated a couple URL's in the script that had changed (unless that has been fixed now). There is also Building Tclkit with kitgen on Windows but I have no input on how well that works as I avoid windows myself.

APN Check out http://www.rkeene.org/devel/kitcreator/kitbuild/nightly/ from Roy Keene for daily builds on multiple platforms.

MG Awesome, thanks for the quick responses, guys.

LV The tip at https://www.tcl-lang.org/cgi-bin/tct/tip/311 only covers changes through 2010 releases of 8.6. Have any additional tips been implemented in 8.6 since that time? Has there been any discussion regarding freezing features for 8.6.0 and releasing it and doing subsequent work against 8.6.1 and beyond?

DKF: Since it is manually-maintained, it only gets changed occasionally.

HaO: 2012-12-06 Donald Porter posted on MS VC++ build using win/Makefile.vc on the tdbc-devel list:

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.

HaO: 2012-12-07 Twylite gave on tdbc-devel those two contributions, one to enlight cmake and one to compare build methods:

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.

and a reply to me:

> 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.

2013-03-28: Twylite gave a pointer on clt to his CMAKE TCL 8.6 make files: http://dev.crypt.co.za/coffee/index