[5522] in Moira
Re: Two patches
daemon@ATHENA.MIT.EDU (Garry P Zacheiss)
Mon Jan 4 13:04:07 2010
From: Garry P Zacheiss <zacheiss@MIT.EDU>
To: Evan Broder <broder@mit.edu>
CC: "moiradev@mit.edu" <moiradev@mit.edu>
Date: Mon, 4 Jan 2010 13:03:50 -0500
Message-ID: <07FBC978-EECD-48A0-9086-BA1033D86184@mit.edu>
In-Reply-To: <178868c41001021533x11666164i1fc8a059779237ef@mail.gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Comments in-line below.
On Jan 2, 2010, at 6:33 PM, Evan Broder wrote:
> Hi -
> I've attached two patches I put together as part of my work on
> MacAthena, and one from Debathena
>
> First, ./configure sets a sysconfdir variable, intended for
> system-wide configuration files (i.e. the configurable version of
> /etc). respect-sysconfdir.diff causes the update_server to respect
> sysconfdir when installing and looking for moira.conf.
>
The Athena 9 build system set sysconfdir to /etc/athena, so this patch ends up setting CONFIG_FILE to /etc/athena/athena/moira.conf in that case. I think it would be more correct for CONFIG_FILE to get set to $(DESTDIR)$(sysconfdir)/moira.conf rather than sticking the random "athena" in there; I don't think the file ending up in /etc is wrong.
> Second, OS X has a bizarro version of com_err. For whatever reason,
> initialize_FOO_error_table() is a NOOP; unless you call
> add_error_table(&et_FOO_error_table) instead, com_err doesn't have
> access to the error tables and you get numeric error messages. Except
> for libkrb5, where you need to build with -framework Kerberos to get
> access to the error tables (but don't need to call add_error_table).
> Like I said, bizarro.
>
Looks good, committed.
> fix-os-x-comerr.diff updates both the build flags and
> initialize_FOO_error_table calls to do the correct thing. Both patches
> will only have any effect if Moira is being built on OS X. (The patch
> to configure.in is based on r23277 I committed to Debathena a while
> back).
>
> Finally, now Moira can be built as a shared library, but it's not
> possible to build additional out-of-tree clients against it, because
> the headers aren't currently installed. I'm particularly interested in
> seeing the headers installed for my Python bindings to libmoira[1],
> which Debathena is hoping to use in a series of more user-friendly
> graphical Moira clients in the near future. install-headers.diff
> installs <moira/moira.h>, <moira/mr_et.h>, <moira/krb_et.h>, and
> <moira/ureg_err.h>. I put them under the moira/ subdirectory to avoid
> any potential conflicts with krb_et.h, but if you'd prefer to see them
> go directly into $(includedir), that's fine with me as well.
>
I dither about this one, not because of the content (putting headers under a moira subdir is fine), but because I'll admit I currently like the fact that there aren't really any clients outside of the canonical source tree. In the specific case you're thinking about, I would be interested in taking well-thought-out python bindings into the tree (to compliment the JNI code that's already there) if you'd be interested in seeing them incorporated; this is likewise true for any additional clients you're considering writing. You should note that ISDA has been working on a new webmoira, so if there's functionality you'd like, I'd also strongly consider seeing if they would include it there rather than writing something standalone.
> As always, please let me know if you have any comments or concerns, or
> if there's anything I can do to improve these patches.
>
> Thanks,
> - Evan
>
> [1] http://github.com/ebroder/python-moira
> <respect-sysconfdir.diff><fix-os-x-comerr.diff><install-headers.diff>
