FreeTDS Development Group

["Craig A. Berry" <craigberry AT mac.com>]

At 10:20 AM +0100 12/20/05, ZIGLIO, Frediano, VF-IT wrote:
> >
>> Craig A. Berry wrote:
>> > --- include/replacements.h;-0   Fri Jul  8 03:22:52 2005
>> > +++ include/replacements.h      Sun Dec 18 16:13:06 2005
>> > @@ -53,8 +53,8 @@
>> >   char *strtok_r(char *str, const char *sep, char **lasts);
>> >   #endif /* !HAVE_STRTOK_R */
>> >
>> > -#if !HAVE_READPASSPHRASE
>> > -# include <../src/replacements/readpassphrase.h>
>> > +#ifndef HAVE_READPASSPHRASE
>> > +# include "readpassphrase.h"
>> >   #else
>> >   # include <readpassphrase.h>
>> >   #endif
>> > [end of patch]
>> >
>> > and then add whatever -I directives are necessary to make
>> the include
>> > file findable. (The easy way to do the latter, of course,
>> would be to
>> > simply move it from src/replacments to include/).
>> >
>> > Does this make sense?
>>
>> Hi Craig,
>>
>> At first blush, yes. 
>>
>> I'm a little puzzled why the tree information is a problem.  In Unix
>> environments, you'd have a hard time getting the build to work if you
> > disturb the relationship between include/ and src/. 

The places  where a replacement readpassphrase() is most likely to be
needed are least likely to be Unix environments (though I don't know
if the FreeBSD implementation currently supplied will work on
non-unixen -- I'm using my own implementation but would like to make
use of the real header if possible).

In my VMS build environment, I do not descend into the various
directories during the build, and there is no "relationship between
include/ and src/" other than what I supply explicitly by the moral
equivalent of adding -I switches to the compiler flags.  Changing
how that works would be a major undertaking.  I would like to simply
add another include directory to the flags and be on my way, but the
presence of an explicit relative path prevents that.

> > Moving the replacement code to include/ is a big deal because
>> it affects
>> CVS.  I could look at ways to have the autotools copy the
>> replacement code
>> to include/replacements/ at build time.  Then the source would say
>>
>>      # include "replacements/readpassphrase.h"
>>
>> which is at least intuitive. 
>>
>
>IMHO I would prefer a cp/cvs add new/cvs remove old/cvs commit instead.
>Or perhaps another option is to add src to include path and use #include
><replacements/readpassphrase.h>.

It seems like adding an include path might be the least pain for the
committers, though I would prefer to see no directory information at
all in the #include directive.  And I think we want double quotes
rather than angle brackets in order to search locally defined paths
first, though that search order may not be universal.

>However I don't understand the reason
>to change this include, just to quote original message
>
>> The other issue is that it seems to me
>>
>> # include <../src/replacements/readpassphrase.h>
>>
>> has far too much information hard-coded about where the include file
>is
>> found and what directory I happen to be in when I'm compiling.
>
>specially "... it that it seems ..." why "it seems" and not "it is" ??
>And also "has too much information hard-coded" ... well, it the include
>works I don't see any problems... header is "private" (not installed) so
>if FreeTDS compile is not a problem.

The absence of compile errors on one platform is not proof of good
coding practices.  Whenever I stumble across a portability issue, I
try to think of what dependencies can be eliminated and describe the
problem in general terms rather than just saying "it doesn't compile
in my environment."  One of the general principles here is that
everything between angle brackets or double quotes in an #include
directive is implementation defined.  The more information you have
in there, the more likely you are to come across a C implementation
that interprets it differently from yours.  The other general
principle, and the one that is tripping me up, is that where things
are in relation to each other during the build is information that
belongs in the build facilities, not in the source code.  Had that
been done from the outset here, we would not even be having this
discussion.
-- 
________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser