HTCondor Project List Archives



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-devel] What does Condor _really_ depend on?



On Mon, Aug 13, 2007 at 09:18:02PM -0500, Matthew Farrellee wrote:
> 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?

After thinking carefully about it. I think the lower level things
like HAVE_LIBDL, HAVE_DLOPEN should be aggregated into something like
ENABLE_CLASSAD_FUNCTIONS.

This is because on different machines, it might require different lowlevel
details configure figures out to determine if the feature is turned on
or off.

For example, for one architecture HAVE_DLOPEN and HAVE_DCFCN_H both must
be defined for user defined functions to be available, but for linux it
might simply be that HAVE_DLOPEN is enough.

This makes complex boolean expressions in *each* place you'd want to use that
feature.

/* or whatever layer this ends up making the most sense in */
#if (defined(LINUX) && defined(HAVE_DLOPEN)) ||
	(defined(Solaris) && (defined(HAVE_DLOPEN) && defined(HAVE_DLFCN_H)))
#define ENABLE_CLASSAD_FUNCTIONS YES
#else
#define ENABLE_CLASSAD_FUNCTIONS NO
#endif

Then that would catch all wierd combinations you get in the lowlevel
details to the determination that you should be using classad functions.

Also, if you had something like ENABLE_CLASSAD_FUNCTIONS in the source
code, then a developer can easily check all of the places in the code that
functionality touches without haveing to remember the low level details
(which cuold has been used for other features in other ways and now you
have to try and determine of a use of the lowlevel detail constituted
the use of the feature).

I had to do something similar for the debug symbols featuer in Condor.
There are something like 5 low level details that must conspire to
allow the debug symbols to be generated. Most of that though ended up
in configure.ac.

> 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.

This can be fixed by having a "conceptual barrier" point in our build
system.  Menaing a file where specifically the low level pieces are
aggregated into the feature definition. One place to find it, one place
to understand what goes into a feature.

> 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.

This is exactly what I mean. I agree with this.

-pete