Coda File System

Re: RFC: package checking via pkg-config

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Sun, 20 May 2007 11:59:37 -0400
On Sat, May 19, 2007 at 04:51:07PM +0200, Enrico Weigelt wrote:
> > I think pkg-config is a good thing, however the example you give 
> > is probably the one dependency that is essentially unnecessary. 
> > The only reason for the openssl dependency is for md5 and sha1, 
> > but we've had generic implementations of both of these algorithms 
> > for a long time and those are already used when openssl is not 
> > found by configure.
> 
> So should we drop the openssl dependency completely ? 
> 
> BTW: are these implementations within code or separate libs ?

I think so, the openssl implementation may or may not be faster. The
md5 and sha1 code is conditionally compiled in coda/lib-src/base. Every
Coda binary links against the resulting libbase.a.

> > A more significant change that I have had on my todo list for 
> > a long time is to move the Coda build to automake. 
> 
> What benefits does that bring ? 

First of all it would make all Coda packages use the same build
framework, right now the build instructions for lwp/rpc2/rvm are
slightly different and my packaging scripts need special cases to
handle the Coda build. But more importantly it will force a cleanup of
the build procedure, we can move some more functionality into shared
libraries reducing the size of the binaries. Automake will rebuild and
rerun configure when makefiles or configure changes, we'll get a
correctly working make dist target, as well as make uninstall.

Of course we will lose the client-install/server-install targets, so it
would be benificial to move that decision under a configure option but
that way we can limit what is built when someone only wants to install
only a client or a server.

> > Part of that would also include avoiding the 'copy headers to 
> > coda-obj/include directory' step.
> 
> Isn't that an issue of proper -I flags ?

Yes, but it would require adding quite a few -I flags, so some source
reorganization and possibly moving common support routines off to a
shared library to simplify the build.

Jan
Received on 2007-05-20 12:04:41