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

[Matthew Farrellee <matt@xxxxxxxxxxx>]

Erik Paulson wrote:
> On Tue, Jul 31, 2007 at 12:28:20PM -0700, Derek Wright wrote:

> > Ideally...
> >
> > A) Each conditional feature knew what externals it depends on.   
> > Features can be enabled or disabled with --enable-<foo>.  We have  
> > reasonable defaults for what features are enabled if you don't  
> > specify anything to configure.
>
> This goes back to my earlier question - are we backing away from the 
> "reasonable default" is everything, and counting on the NMI glue to ask
> for everything?

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.

Some possibilities:
 1) A single --require-everything flag that forces all --enables to 
have their requirements satisfied, with an explicit --disables being 
able to  override this requirement.
 2) Only force a feature's requirements to be satisfied if --enable is 
provided for that feature.
 3) Have a hard-coded decision about what features are required 
expressed in the configure script itself.
 4) Others?

Really these possibilities are far from exclusive. (2) should really 
always be the semantics of --enable. (1) is nice because it means only 
having to remember what must be disabled on a given platform. (3) seems 
like a bad idea at first, ewe "hard-coded," but really is how it seems, 
to me, an autoconf script should work. For instance, when stating that 
PCRE should be tested for you also state that it is required, which it 
is, without it Condor doesn't compile.

Thoughts?


> > B) Each external could be --with-<foo> to supply a path, --without- 
> > <foo> to disable, or left off to use the default external in the  
> > externals directory.
> >
> > C) configure would be smart enough to figure out if you requested  
> > features that need externals that you don't have, and blow up in your  
> > face about it.
> >
> > D) otherwise, we only check for and build externals that are required  
> > by the currently enabled features for a given build.  so, if you say  
> > "--disable-quill" and quill is the only thing that introduces a pgsql  
> > or oracle dependency, we just assume --without-pgsql and --without- 
> > oracle and don't build either external.
>
> What if we took out the automatic "build any needed externals" step, and
> instead was more like every other piece of software out there, which 
> assumes that dependencies are managed by another (possibly/hopefully)
> smarter tool than configure? If Condor ever gets in Fedora, presumably the
> bulk of the externals it uses will be the Fedora-versions of krb, openssl, 
> postgresql, PCRE, etc.

Well, this will definitely be possibly, if it is used outside of a 
Fedora package is up to condor-team.

Don't forget pvm is packaged, ha!

Best,


matt

> Maybe the externals build step would be better handled by either the NMI
> glue, some sort of DAG in NMI, or just a way tricked out version of 
> new_workspace.
>
>
> -Erik
>
> _______________________________________________
> Condor-devel mailing list
> Condor-devel@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/condor-devel