FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

I think it's just grouchiness :-) ...

My proposal achieves that separation by providing two different
system-dependent configuration headers.  tds_sysdep_private.h.in will
contain those elements only needed at library build time.
tds_sysdep_public.h.in will contain items that may be needed by headers that
user programs might pull in.

For example, a DB-Library program is going to need to know what a DBINT is.
Our sybdb.h typedefs it as a TDS_INT.  The definition of a TDS_INT is
curently produced by an autoconf substitution on @int@, which used to be
done in tds.h.in but after freddy77's change last night is being done right
now in tds_configs.h.in.  My proposal is that this substitution would be
done in tds_sysdep_public.h.in, on a type name one level more abstract than
TDS_INT... perhaps tds_int32_type or something like that.  Then tds.h would
just "typedef tds_int32_type TDS_INT;".

Now consider the type definition of CLOSESOCKET() in src/tds/util.c.  This
is a system-dependent piece of information that a person doing a port by
hand might need to provide.  Isolating this in tds_sysdep_private.h.in
(along with READ() from read.c and WRITE() from write.c, which will be
renamed to READSOCKET() and WRITESOCKET()) means that a porter needs to just
fill out this template with system-dependent infromation to complete a port
(at least in most cases).

It would be great if we could do this all in one file, but we have no
business polluting user programs compiled against FreeTDS with definitions
like CLOSESOCKET(), which apply only to library internals.

The names aren't going to win any beauty contests, but they aren't so bad.
The "tds_" prefix should be fairly self-explanatory.  "sysdep" indicates
precisely and concisely that these files contain system-dependent
information (there's a lot of prior art in the freeware arena, where you
will often find "sysdep.h" or "sysdep.c" files used in porting the program.
After the advent of autoconf these became less popular, but at one time they
were all the rage).  I considered having "tds_sysdep.h" and
"tds_sysdep_private.h", but I liked the idea of using "_public" for its
obvious distinction against "_private", and also because it closely
parallels the usage of Sybase headers like "cspublic.h".

What we're accomplishing at the end of the day is the isolation of the
majority of our system-dependent configuration information into as few
places as possible.  These files will contain *only* system-dependent
information.  A person doing a port without the aid of autoconf can merely
fill in the blanks, and submit the filled-in copy for inclusion in the tree.
The build script would just do something like "cp tds_sysdep_private.h.win32
tds_sysdep_private.h ; cp tds_sysdep_public.h.win32 tds_sysdep_public.h".
Most importantly, we don't have to worry about screwing up the win32 port
every time we touch tds.h.in, which is the situation we would have if we
maintained the "easy-to-grasp" old way of doing things.

I don't really think this is a distortion in any real sense.  I view it as a
cleansing of the code base; all the ugly system-dependent porting details
will be stored in a pair of headers and a couple of replacement functions.
Autoconf magic (and a little bit of work on the part of people doing manual
ports) will handle all the messy details.  The fact that this will also make
a win32 port cleaner and more maintainable is just a pleasant side effect,
as far as I'm concerned.

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu]
Sent: Friday, October 11, 2002 11:58 PM
To: TDS Development Group
Subject: [freetds] RE: tds_config.h.in


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

---
You are currently subscribed to freetds as: [Nicholas_Castellano AT acml.com]
To unsubscribe, forward this message to
$subst('Email.Unsub')


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.