{dblib,odbc}/unittests/common.h: Allow FREETDS_SRCDIR overrides.

[ucko]

Split from #555.

[freddy77]

Why do you want to override it? The idea is that you can override FREETDS_TOPDIR.

[ucko]

Layout differences -- we have, e.g., src/dbapi/driver/ftds14/freetds/dblib, so adjusting FREETDS_TOPDIR is insufficient because it's expected to have e.g. src/dblib as a subpath.

[freddy77]

How can the layout be different if they are in the source path which should be from FreeTDS repository or from tarball?

[ucko]

I've been making formal layout changes in the course of embedding into the NCBI C++ Toolkit's top-level include and src subtrees. If you'd rather not support such rearrangement, I can continue carrying the patch locally, but it is small and safe.

[freddy77]

Which build system do you use? I personally never liked these macros anyway... I was trying to find a better alternative, like, if was possible, to remove them entirely in some way.
What we need is the source directory, so we can find additional files. FreeTDS uses Autoconf and CMake (and some Vms files I don't use much); Autoconf uses relative directory for __FILE__, CMake uses absolute ones for __FILE__ (Vms I thing current directory so even less issues). In theory from common.c of each test directory we could compute the source directory (either relative or absolute).

[ucko]

Looking relative to __FILE__ wouldn't fully work for us either, sorry -- long story short, we use a mix of setups and keep things simple for tests by arranging to let them find (copies of) any needed data (as listed in their [C]Makefiles) in their current directories. (Our shim config.h defines FREETDS_SRCDIR to "." accordingly.)

We've historically used an Autoconf-based setup with central Makefile templates, coupled with a tool that generates Visual Studio and Xcode projects on the basis of template parameters, and are now migrating to CMake, which can generate such projects natively. Our traditional Autoconf setup arranges to use absolute paths, but the traditional VS and Xcode setups use relative paths that aren't consistent with how we run tests -- the Xcode paths are uniformly relative to the .xcodeproj folder's parent, and the VS paths would need another two leading ..s. (Traditional VS and Xcode builds run tests from a dedicated subtree akin to CTest's Testing.) We could perhaps arrange to use absolute paths everywhere, but our CI setup commonly has separate jobs for compilation and testing, where sources aren't available at all when running tests and might not be reasonably possible to supply at their original locations.

[freddy77]

In the meantime merged, maybe I'll find a better way to remove that definition.
One option could be having the build system copy data files inside destination directory too.

[ucko]

Thanks!