Re: FreeTDS 0.82 no longer has tds.h installed?
"James K. Lowden" <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
Dossy Shiobara wrote: > I'm looking to update the AOLserver nsfreetds database driver with the > latest FreeTDS 0.82. I grabbed RC4, compiled and installed it ... and > discovered it no longer includes tds.h in the installation path? > > Is this intentional? Yes. We stopped building libtds as a shared library in June 2006, and neither it nor its header files are installed. Supporting it as a shared library was unproductive and contrary to the goal of providing high quality client libraries. > I'd really like to continue using the TDS API That's no problem; it's an LGPL project. All you need to do is copy the header files. You might want to maintain your own makefiles that build libtds as a shared object and install it. I'm on record many times over, but I'll say it again: there's no such thing as "the TDS API". There's a motley collection of functions used by the client libraries. We are slowly rationalizing them whenever they get too baroque. The real problem for anyone using them isn't so much that things won't compile from version to version, but that the calling semantics change in subtle ways as our understanding of the protocol and client libraries grows. (libtds is best thought of as a marshalling library of TDS packets. The interface ought to be put/get by packet type, plus some utility functions for data conversion and state transition, and low-level read/write network layer. I don't see that happening, though, unless someone expresses interest.) Both FreeTDS and the AOLserver project would be better off if AOLserver used a client library instead. Concerns about efficiency are misplaced: db-lib (e.g.) does hardly anything more than what your own application must do to use libtds. It makes no extra buffer copies, wastes very little motion. My criticism isn't intended as unfriendly. Having written to the TDS layer years ago, you'd naturally rather maintain that than re-write everything to one of the client libraries. I just wouldn't want anyone to get the impression it was a good idea then or now. With kind regards, --jkl