FreeTDS Development Group

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

On Fri, 11 Oct 2002 14:34:57 +0200, "Jonas Benjaminsson"
<jonas.benjaminsson AT infogate.se> wrote:
> :: > Yes, but how should that file be included in the CVS so
> :: > that other people don't have to write their own?

> :: I'd use a src/win32 directory... with some project file/makefile
> 
> Agree, and a include/win32 perhaps, the problem with not using the
> same file as for the Unix flavors is that when the Unix files are
> modified the win32 file tend to be forgotten.
> Therefor I would like to see that as much as possible is handled
> by using #ifdef in the Unix files.

Hej Jonas! 

Could you update us on what you and Magnus are doing?  I was to make it as
easy for you as I can, and some things we're doing, or could be doing,
could affect you.  

BTW, what version of the source tree are you working from?  It's changing
very fast, and it would be good if you're using anoncvs to keep the tree
up to date.  

Originally, you had said you wanted to generate DLLs with the autotools
and gcc.  I take it my message was discouraging, and you've now decided to
use VC++?  That's fine; it just introduces different wrinkles. 

I've written more Windows code than I should probably admit to here, but
I've never done much Windows-Unix integration.  I've been thinking about
how to use VC++ to generate DLLs, and I have a few ideas I'd like to
bounce off you, if you don't mind.  

I'm pretty sure cygwin and the autotools, and even the "configure" script
are no use to you, right?  Because configure has to use the compiler to
determine what substitutions to make for things like "@int@", and I don't
think it can get that information from VC.  (Of course, it could get it
from gcc, and gcc could build your .o files, but you'd lose VC's very nice
debugging environment.  

Without cygwin, we're left with two problems (apart from porting the
code).  First is what to do about autoconf's substitution fuctionality
(e.g. @int@).  Second is what to do about the lack of a Makefile (because
configure generates the Makefiles).  

Taking the second thing first, you've probably already created a few .dsp
files and one .dsw file.  Each API library will become a DLL; libtds could
be static or dynamic.  That doesn't seem too bad.  

That leaves the substitutions, the generation of tds.h from tds.h.in.  One
approach would be to create your own tds.win32.h containing manual
substitutions (by you).  Something somewhere has to rename it to tds.h
before compilation, unless every source code module is to contain #ifdef
win32 #include tds.win32.h #else ....   I'm sure this is what Nick is
addressing with tds_sysdep_public.h.  

My only good idea is to use VC's "pre-build script" feature.  I could
provide you with a perl script that makes the appropriate substitutions
and generates a tds.h.in (et. al.) on the fly.  In effect, it would be a
specialized autoconf, limited to a single architecture and compiler (and
project).  You would put "perl scriptname" in the "pre-build script" field
of the project's build options, and voila! get exactly the definitions
(and dependencies) you need.  

My script would:

        Search the tree for .h.in files.
        Check their dates against the corresponding .h files
        Generate if necessary

How does that sound?  As I see it, this means we don't need to rearrange
our header files, and you get a functional replacement for ./configure.  

Regards, 

--jkl