On Mon, Aug 13, 2007 at 08:33:15PM -0500, Matthew Farrellee wrote:
I don't think so. I'm working with the current idea that everything
should be enabled, if it can be. There is also a mechanism to say
certain things MUST be enabled -- configure blows up in your face is
something that MUST be enabled cannot be. Presumably when a release is
being made, or maybe even a nightly build, you could say that everything
MUST be enabled. The exact mechanism for that is up for debate. It is
implemented statically right now, but really should not be.
So there are three sets entites we can control during the compilation of
Condor:
1) Hard required entities, like PCRE.
Hard means in all cases this feature must be enabled and if not
enablable, then it is an error and Condor will not build.
2) Soft required entites, like Kerberos.
Soft means you can turn it off and on, but we try very, very hard to have
it be on for an official release of Condor. Many of our features are of
this variety and this is extremely useful for porting work. It is often
the case people will accept a crippled clipped port because it doesn't
use a feature someone doesn't care about.
3) Truely optional features, like classad functions.
There could be argument that should the conditions exist that these may
be turned on, they should be, and we use runtime configuration file entries
to enable/diable them.
So, a "config file" like this:
DEFAULT ON HARD PCRE
DEFAULT ON SOFT KERBEROS
DISABLE KERBEROS m/some regex against a config.guess-like os,arch ident str/
DEFAULT OFF OPTIONAL CLASSAD_FUNCTIONS
could start to describe under the usual conditions we want something turned on
or not.
Then, we just need one flag which says:
--make-soft-into-hard
Which turns all soft requirements into hard requirements, except leving
out the manually disabled features on the correct architectures.
