FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

LacaK wrote:

> And second question: if I supply project files for MS VC 2010, do you 
> include them in FreeTDS sources as next alternative to msvc6 project
> files ?

Will you support it?  

If you join the project and that's something you want to work with, OK,
else no thanks.  If you don't mind, though, I'd like to explain why.  

I understand the attraction of Microsoft's dev tools; they make one of the
better debuggers I've ever used, and the class browser has gone from
pathetic to pretty nifty in only 10 years.  Although is truly ridiculous
that in 2010 we can't get a list of functions that call a function or of
places where a variable is written to.  

> (msvc6 project files can not be opened in VC 2010)

Each version of their tools invents an incompatible "project file" format,
making it a time sink and a distraction.  When it works, it works great,
but when it doesn't work, it's almost impossible to support because so
much information is trapped in the GUI.  

To repeat something I've said before: creating an MS VS xx project for
FreeTDS falls under Know Thy Tools.  For the experienced developer, it's
child's play.  Really!  Anyone who's ported VMS or Unix code to Windows
knows the drill.  Anyone who hasn't, must learn; if they find it daunting,
they'll soon discover that's the least of their difficulties.  

What we do here on this list is develop the FreeTDS libraries.  We strive
to write portable code that can be compiled anywhere, that connects to any
server, that works as advertised conformant with the vendors'
specifications.  We include documentation and utilities intended to make
using FreeTDS as convenient and pleasant as possible.  We do it for fun. 
It'd better be fun, because it takes a lot of time.  

Tool and environment issues are definitely less fun.  Autoconf takes care
of everything except Windows, even AIX, even OS X.  To make Windows
development about as easy, I wrote the Nmakefile, which I'm happy to
support or apply patches to.  Every version of VC++ I can think of
supported a "makefile project" that the Nmakefile could be dropped into.  

The Nmakefile also has the salient benefit of being readable.  Anyone who
wants to know how all the pieces link together can, given time and
patience, read it to find out.  Anyone who does so will become a better
programmer and even perhaps one day contribute to the project.  The person
who requires a push-button eyes-closed just-make-it-work-for-me
wrapped-in-ribbon project file will never do either of those things.  Him
I can't help.  

I've been writing Windows code on and off since version 1.0.3, in 1985. 
(It came on 360 KB floppies with 3 3-ring binders for manuals, and a
canvas bag to hold them. It supported CGA: 4 colors, 640x200.  Debugging
was done via the serial port on an AMD3.)  We'll be moving to Windows7 at
my place employ Real Soon Now, and to 64-bit workstations, running FreeTDS
x64 db-lib.  (And, yes, we've got project files going back 10 years and
more in our source control system, not that they're any use!)

In all those years, I can't think of one time I solved a compile/link
problem over the phone or by email.  It always involves going over to the
person's desk and tracking it down.  Which is fine, for work.  But not for
fun, and not feasible if the desk in question is more than a few hundred
feet away.  

Thanks for listening.  

Regards, 

--jkl