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

[Matthew Farrellee <matt@xxxxxxxxxxx>]

Peter Keller wrote:
> 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.

I must disagree. I think we should have 3 kinds of symbols: properties 
of the system, features used configuration, and property-aggregates. 
Properties are things like HAVE_DLOPEN and HAVE_DLFCN_H; Features are 
things like ENABLE_CLASSAD_FUNCTIONS; and Aggregates are logical 
concatenations of Properties, to be used only when absolutely necessary. 
It would seem that your example above would need an aggregate, but I'd 
argue it doesn't because the code that needs dlopen should check for 
HAVE_DLOPEN while the code needing dlfcn.h should check for 
HAVE_DLFCN_H. The code should not care if it has one and not the other, 
because maybe sometimes HAVE_DLFCN_H won't be needed, and in the case of 
HAVE_DLFCN_H without HAVE_DLOPEN we'd just be doing an extra #include. 
If that extra #include ends up being an issue, symbol bloat?, then 
something could be done, but that's unlikely.


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

This is an interesting point, and I don't have a solution to it if 
properties are used for ifdef's in the code.


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

Something similar to identifying what pieces of the code are involved in 
a given feature, or something similar to the complex ifdef above? At 
least in the example above I don't think it has to be so complex.


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

Yeah, that would be part of the configure system, but would be 
independent of the code. Code would never check for a feature, it would 
just check for properties it needs to compile/work.

Anyone else have thoughts?


matt

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