FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> > From: ZIGLIO, Frediano, VF-IT
> > Sent: Tuesday, December 20, 2005 11:08 AM
> > 
> > Well, not using directory informations on #include was one of the
> > suggestions on portability on "C++ Manuale di Stile" (Carlo Pescio
> > "C++ Style Manual"), a very good book. The main reason why
> > readpassphrase.h is in src/replacement is that it was on the same
> > directory (I copied from a BSD style source, see license inside).
> > I added #include in replacements.h after cvs commit so I decided
> > to use relative include.  This also assure that we use our version
> > instead of possible system one (or that it do not compile...). A
> > simple way to solve all issues can be - move
> > src/replacements/readpassphrase.h to include/tds_readpassphrase.h
> > - do adjustment for correct inclusion (include/replacements.h,
> > src/replacements/readpassphrase.c) Does this solution make all
> > happy ?
> 
> [The priority of search order for include paths ("" vs. <>)  
> is part of
> the C standard.] 
> 
> I think it's OK to have *some* path information.  The Open 
> Group defines
> some include headers as being in sys/
> (http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/ty
> pes.h.html
> ).  
> 
> I also think it's a good idea to have include files in one place and
> source in another, if the include is to be shared.  If the include is
> not to be used elsewhere -- i.e. the .h file is only for one 
> file or for
> files in only one directory -- then it should stay with the 
> files(s) and
> 
> 
>       #include "foo.h" 
> 
> will work fine.  
> 
> In our case, rather than: 
> 
>       $ mv src/replacements/readpassphrase.h \
>               include/tds_readpassphrase.h
> 
> I prefer: 
> 
>       $ mkdir include/replacements
>       $ mv src/replacements/readpassphrase.h \
>               include/replacements
> and
>       #include <replacements/readpassphrase.h> 
> 
> because it makes clear that our readpassphrase is a replacement, not a
> specialized enhancement.  Also, it has appealing parallelism:
> 
>       src/replacements/*.c
>       include/replacements/*.h 
> 
> How does that sound?  
> 

We all agree, committed

freddy77