FreeTDS Development Group

[James K. Lowden <jklowden AT speakeasy.org>]

On Fri, 11 Oct 2002 19:50:22 -0400, "Castellano, Nicholas"
<Nicholas_Castellano AT acml.com> wrote:
> 
> We need to keep elements required at library build time separate from
> elements required at library use time.

I don't really understand how your proposal achieves that end.  

> 
> To implement that, I will do the following:
[...]
> If you dislike this idea, speak soon or forever hold your peace...

Two reactions.   

1.  tds_sysdep_private.h[.in] and tds_sysdep_public.h[.in]
The names are so butt ugly I wouldn't give them to my back-country
cousins.  Or their kids.  :)  

2.  I'm not sure what we're accomplishing at the end of the day.  It seems
to me we're just substituting the preprocessor's macro feature for m4's
(via autoconf).  What difference if tds.h declares something of type @int@
or of type TDS_INT, after all?  

I view tds.h.in -> tds.h as a fairly easy-to-grasp processing model.  I
don't think placing everything autoconf has to deal with in a single file
yields enough "cleanliness" to warrant the complexity of the additional
#include superstructure.  

The whole motivation AIUI was to provide the Win32 port with bona fide
header files, and not confront them with dealing with tds.h.in and such. 
I *applaud* the Win32 porting effort, but I don't want it to distort our
process.  

How do others feel about this?  I'm too tired to know for sure whether I'm
experiencing insight or grouchiness.  

Regards, 

--jkl