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

[Erik Paulson <epaulson@xxxxxxxxxxx>]

On Mon, Jul 30, 2007 at 03:39:05PM -0500, Matthew Farrellee wrote:
> I set #define WANT_QUILL NO in my site.def to a very recent (today) 
> checkout of Condor's trunk, and my build fails.
> 
> I understand from Erik that quill has been integrated into parts of 
> Condor, but should it really be required? And is it really "quill" that 
> is required?
> 

At a high level, no, it shouldn't have been - the parts that are "required"
should have been moved into c++_util.  

Can I ask why you want to set WANT_QUILL to be NO? My guess is that you 
really want something else. Here are a couple of reasons why one might
set feature to WANT_x NO.

1. The feature relies on an external that for whatever reason you don't want
to include.
2. That feature doesn't compile/work on a particular platform, even if all the 
externals work.
3. Just don't want to support that particular feature.
4. Slim down the build/tarballs

If I had to guess what you're trying to do, it's that you don't want to
force a dependency on PostgreSQL, not that you don't want to compile the 
Quill code. (Though it's not clear how useful Quill would be without at
least one database)

There are a couple of things I've been thinking about turning off in my
RPM for my next version:
1. Getting rid of the PVM shadow, so I don't have to compile and rely on
old, custom patched PVM
2. The standard universe, so I don't have to rely on a glibc that is a huge
pain to compile anywhere
3. The checkpoint server, because it's totally hated. 
4. The grid universe, because the GSI libraries are huge. 

Without these, I think Condor would be a pretty standard piece of code, that
only uses very common libraries (PCRE, OpenSSL, Krb5, zlib) but still
does what 90% of sites want it to do. It'd be nice if I could just turn off
the libraries I don't want to support, and have the features that need them 
automatically turn off, but that's probably a long way away.

> I went ahead and started a patch to make WANT_QUILL NO work. Below is a 
> patch to src/Imakefile so that a Condor build does not attempt to 
> compile quill code. I found that patching just Imakefiles is not enough 
> as pieces of quill code are not wrapped with "#if WANT_QUILL", e.g. 
> src/condor_schedd.C:355 references a variable prevLHF, which does not 
> defined via scheduler.h unless WANT_QUILL is YES.
> 
> Do those who know about Quill think the patch below should do the trick?

Does this work with schedd.V7, which uses the Quill parser?

> 
> Conditionally Compiling Code:
> When it comes to externals, it seems we have a number of different ways 
> of deciding if code should be compiled. There are a number of 
> WANT_/USE_/HAS_/HAVE_/DOES_ options (I understand many are *OLD*) in 
> different configuration files (site.def, <platform>.cf, 
> configure.cf.in/externals.cf.in), and little consistency as to what 
> should be used for new code. Speaking with Derek I've been told that 
> code should be conditionally compiled by HAVE_EXT_'s, but I've seen 
> recent code additions (including my proposed patch below) checking for 
> WANT_'s. Do people find that HAVE_EXT_'s are not good enough? Maybe 
> quill is a good example of this since it can work with multiple 
> databases (i.e. #if WANT_QUILL (above) vs #if HAVE_EXT_POSTGRESQL).
> 
> Testing of Conditional Compiled Code:
> Given the complexity of the build system Condor probably isn't ever 
> compiled WANT_QUILL NO and WANT_QUILL YES (or WANT_PCRE NO/YES for that 
> matter), is it? Do people think it would be beneficial to have a more 
> complete builds, and would you be willing to help untangle the web of 
> how Condor's features map to externals (and to platforms)?
> 

Eventually I would be :)

> Adding New Externals:
> New externals, it seems that when new externals are added to 
> externals.cf.in there is little consistency on testing for HAS_EXTERNALS 
> or HAVE_EXT_, or if either of those should be checked. Again, is this 
> because people don't know what the "right" thing is to do now, or is the 
> right thing not expressive enough?

I don't think it's really clear how it's supposed to work. I like the idea of
just using HAVE_EXT_<foo>, combined with a real --with-foo and --without-foo
from autoconf, and getting rid of the HAVE && WANT tests. I think turning 
off externals is better than turning off "features."

-Erik