the way dblib references include files

Now that snapshots are working again and all the cool kids are  
actually using FreeTDS on VMS in the real world, I thought I should  
update my build procedures to make sure everything is looking good for  
the VMS build in the current development stream.  I'm currently  
falling down on:

#include <../../include/sybfront.h>
.^
%CC-F-NOINCLFILEF, Cannot find file <../../include/sybfront.h>  
specified in #include directive.
at line number 48 in file D0: 
[craig.FREETDS-0_83_DEV_20090313.SRC.DBLIB]BCP.C;1

Which is a result of a fairly recent change that switched a bunch of  
the includes from the form:

#include "sybfront.h"

to

#include <../../include/sybfront.h>

The full change is here:

<http://freetds.cvs.sourceforge.net/viewvc/freetds/freetds/src/dblib/dblib.c?view=diff&r1=1.337&r2=1.338 
 >

Before I bang my head against this any more, I wonder if anyone can  
tell me the rationale for this change.  The Makefile adds -I$ 
(top_srcdir)/include to AM_CPPFLAGS, so it doesn't seem like the hard- 
coded relative path in the #include should be necessary.

The VMS build does not use the Makefile.* files, but rather a  
descrip.mms derived from vms/descrip_mms.template.  It doesn't descend  
into the subdirectories to build but does it all from the top level.   
So you could argue it serves me right for doing things differently,  
but I would argue that the less the .c and .h files know about the  
build environment, the more portable you'll be.  I could look into  
changing the VMS build to descend into subdirectories if there's a  
really good reason, but that would be a pretty major rewrite that I'd  
prefer not to do if there are reasonable alternatives.

________________________________________
Craig A. Berry
mailto:[email protected]

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