[freetds] the way dblib references include files
Craig A. Berry
craigberry at mac.com
Thu Mar 19 08:29:36 EDT 2009
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:craigberry at mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
More information about the FreeTDS
mailing list