Bob La Quey wrote:
Do you have some suggestions for "solving the underlying problem of
portability."?
BobLQ "Does not seem easy to me."
Nobody said it was easy. However, there are quite a few things.
First, you structure your code such that changing API calls are isolated
in specific files. Generally through a wrapper layer of your own. Most
C programming *should* be wrapped anyway because it is littered with:
retval = APICall(????);
if (retval == -1) {
/* Do error checking */
}
and that should be wrapped rather than rewritten every single time.
Second, if portability is a requirement, this is one of the few
instances when you need to ask whether it is actually better to write
your own code for small API routines rather than use the native API
calls. Especially if you are using both Windows and Unix where the
library API calls can differ significantly.
Third, one should be testing for major subsystems rather than tiny API
functions. Testing for gtk version X.Y is okay. Testing for the file
<strings.h> for one specific call (strcpy()) is silly. Write that call
into my_strcpy() and test for Windows, Linux, FreeBSD.
Fourth, using *anything* other than configure. The fact that nobody
regenerates configure scripts from scratch combined with stealing some
other project's and tacking on a couple of tests is proof that it is far
too opaque and heavyweight.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
