Derek Wright wrote:
On Jul 31, 2007, at 9:51 AM, Erik Paulson wrote:In Quill's case, we're at least part of the way to having a C++ class that is abstract from any database. I doubt this actually works, but the idea would be that if HAVE_EXT_POSTGRES and HAVE_EXT_ORACLE are both NO, then all of Quill still compiles, it just doesn't do anything useful. Very few places would have to be wrapped in HAVE_EXT_ORACLE/POSTGRES.Quill is a good example for all sorts of reasons...In this case, if you don't have either DB backend, there's no sense bloating our binaries with code that "doesn't do anything useful". It'd be better to just not compile that code at all if you have no intention (or ability) to use it.
So, on to the discussion of features and requirements in source code.Should configure discovered properties of a system (i.e. HAVE_LIBPQ or HAVE_DLOPEN) be used to conditionally compile code, or should a higher level notion of a feature (i.e. ENABLE_QUILL or ENABLE_CLASSAD_FUNCTIONS) be used?
For Quill, it seems pretty clear that properties should be used, especially because Quill can use one property (HAVE_ORACLE_OCI) if another (HAVE_LIBPQ) is not present. However, for something like user-defined ClassAd function, it is more beneficial to use the notion of a feature (ENABLE_CLASSAD_FUNCTIONS), because they really need not only HAVE_DLOPEN but also HAVE_DLFCN_H.
The simplicity of using features (ENABLE_CLASSAD_FUNCTIONS) is probably what has slowly moved the Condor code base into the state it is in today, where the properties required for features are not always understood (or even known), and sometimes features are improperly employed.
The use of features to conditionally compile code seems like mostly a convenience/shortcut and I'd propose using only properties. Features are then just a set of required properties defined in configure. If a property is missing (HAVE_DLOPEN) a feature cannot be enabled (ENABLE_CLASSAD_FUNCTIONS). This would keep the knowledge of a feature's requirements in a single location. It would be possible for the code implementing a feature to get out of sync with the list of its requirements in configure, but at least the code would not improperly depend on the feature (ENABLE_CLASSAD_FUNCTIONS).
Thoughts?
matt
P.S. -
Consider this scenario for the user-defined ClassAd functions:
File A:
#ifdef HAVE_DLOPEN
// code that uses dlopen
#endif
File B:
#ifdef HAVE_DLFCN_H
#include <dlfcn.h>
#endif
Should the code in file A be compiled in !defined(HAVE_DLFCN_H)? Should
HAVE_DLFCN_H or HAVE_DLOPEN be used in all cases? Is it fine to use them
separately (to cover when it is possible to have dlopen without dlfcn.h)?