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?





Erik Paulson wrote:
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.

The point isn't really about disabling Quill but rather the broken nature of how we disable things or even identify what to disable. Quill is just a good example because it embodies a number of problems I've run into when building Condor, and it is sufficiently complex (multiple DBMS back-ends) to make it interesting.


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.

You forgot to mention PoastgreSQL as a very common library. Also, you can't do OpenSSL without Globus (joy), yet.


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?

I do not know. I figured some Quill developers that know where are the Quill code is would be able to tell us.


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

You would be fine changing most all your #if WANT_QUILL tests to #if HAVE_EXT_POSTGRESQL? Surely not, since you can use Oracle. Does Quill add anything to Condor if there is no DB back-end? Could we remove all #if WANT_QUILL tests and just have more specific #if HAVE_EXT_POSTGRESQL or #if HAVE_EXT_ORACLE, where relevant?


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

Anyone else interested?


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

Well, turning off an external essentially means turning off a feature in many cases. Quill is a notable exception. This confusion between features and externals needs to be more clearly understood. Was the WANT/HAVE work an effort to clarify features (WANT) and externals (HAVE)?

As for being clear, if Derek is configure God, then everyone should be using HAVE_EXT_.


matt

-Erik