Re: [Tcl-tdbc] 8.5.6 support (Patrick Dunnigan)

[Twylite <tw...@cr...>]

Hi,
>> For VC 2005+ you need to deploy using Private Assemblies or get the 
>> user to install the VC redistributable package.  In this case a 
>> better alternative may be to statically link to the runtime libs -- 
>> this has an impact on startup time and memory consumption, but gets 
>> around the problem of the target computer not having the right 
>> libraries.
>
> The static link also requires you to get your database vendor to
> make static-link-compatible libraries. I don't know anyone who's
> successfully build the MySQL libs that way. I usually address the
This is somewhat dependent on the third-party API.
If you create a DLL that is statically linked to the VC runtime libs, 
which in turn loads a DLL that is dynamically linked to the runtime 
libs, there is generally no problem unless you move Win32 objects or 
handles across that boundary (e.g. allocate memory in one and free it in 
another).  You face a similar problem if you're building with MSVC2008 
against vendor libs that were built with MSVC2005 (or with another 
compiler, for that matter).
I've downloaded the 1.0b10 sources to do some fiddling.
>> Yes, supporting the VS compiles is horribly painful.  With Tcl.  I 
>> say "with Tcl" because my company works extensively with C/C++ 
>> sources that cross-compile on multiple platforms (Win32, Linux, 
>> Solaris, and three embedded platforms), and the Windows builds are 
>> amongst the easiest.  Tcl's makefiles by comparison are an exercise 
>> in complexity, and have the side-effect of marginalizing Windows 
>> developers (you can't exploit the MSVC tools when you're working with 
>> a makefile rather than a dsp/vcproj).
> And you can't use a .dsp/vcproj anywhere but Visual Studio. Who's 
> marginalizing whom?
I wasn't suggesting only having .dsps ;p  See below.
> Anyway, just putting that out there, it seemed relevant to this 
> discussion.  If you're interesting in trying CMake for Tcl extensions 
> and TDBC drivers let me know and I can give you a hand getting 
> something working.
>
> CMake is useful, but also involves getting downstream distributors
> tooled up for it. (ActiveState at the very least!) I'd switch in
> a heartbeat if I didn't want so much to stay compatible with the
> way that Andreas does things. (I don't lobby very hard for CMake
> because of a perceived conflict of interest. I work at GE Research,
> where CMake was invented.)
I don't know how Andreas does things, but I'm very keen to see CMake 
adopted as the official build support **for WIN32**.  I can't see a move 
away from autoconf on other platforms, and with Tcl's broad availability 
on different platforms such a move may not even be desirable.  However a 
move away from the current hand-crafted makefiles for MSVC would 
certainly be welcome, and I think that CMake fits the bill.
 From my playing with CMake so far, I'm pretty sure it can replace 
anything the current makefile.vc can do, in a far more supportable 
fashion, in a way that allows extensions to keep their build processes 
up to date with the core, and in a way that supports MSVC project files 
(not just makefiles) so that Win32 developers can make better use of 
their development tools.  What, that's my humble opinion at least, and 
what the COFFEE project is all about.

Regards,
Twylite