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 Tue, Jul 31, 2007 at 12:28:20PM -0700, 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.
> 

The question then becomes is it worth putting the effort in to the build
system to support automatically turning off the Quill build when there are
no databases enabled? We've already done the work to support turning off
at least one database, and it wouldn't be much more work to support turning
off the other database. Is having no database a common enough case to
support fully turning everything off, or is it OK just to leave in some 
stubs? 

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

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

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