qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: C++ logging - anyone heard of pantheios?
Date Tue, 08 May 2007 15:27:06 GMT
On Mon, 2007-05-07 at 15:09 -0700, Garth J Lancaster wrote:
> Alan Conway-2 wrote:
> > 
> > On Sun, 2007-05-06 at 14:50 -0700, Garth J Lancaster wrote:
> >> 
> >> Alan Conway-2 wrote:
> >> > 
> > 
> > Don't get me wrong - I'm impressed with Pantheios run-time performance
> > and the clever use of string-shims. I will eventually build the
> > performance tests and depeding on how it fares vs. rlog and some
> > thoughts of my own I'll consider it seriously for my project. 
> > 
> > Cheers,
> > Alan.
> > 
> > 
> Cool  .. remember, its only released so far as Beta  ;-)  
> Obviously the number of library-objects it builds at the moment is an issue
> - one that has been discussed with Matthew, and, some consolidation could be
> achieved. 
> You seem very experienced Alan (not blowing smoke) - What would you like to
> see ? - Im not sure it can get down to one library per platform, but there
> may be some better groupings, outside of the 'standard'
> debug/release/single-thread/multi-thread type builds ....

I'd suggest making those type of distinctions build-time descisions,
i.e. pass some flags to indicate what you want, and only generate libs
for that setting. 

Project I'm working on now uses autoconf, it's not my favorite tool and
it's a pain to set up (I had a friendly autoconf expert) but once it's
set up it doesn't take much maintenance. The advantage is it's very
widely used in the open source C/C++ world so lots of people are
familiar with the "./configure; make" routine and the make targets are
standard. So you might have a default build produce non-debug,
thread-safe libs (or whatever you think is the most likely combination
to be deployed) and users can pass flags for other alternatives e.g. if
I want non-threaded and I'm using gcc and want debug info optimized for
gdb I'd do

./configure --without-threads CPPFLAGS=-ggdb ; make

autoconf supports multiple builds with different configurations from the
same source so people who really want to build all the options can do
so. It also tackles many nasty portability problems for you, so you end
up with a single Makefile template and ./configure generates a Makefile
tweaked for the platform you're running on.

There are other similar tools, I've used Imake (and wouldn't recommend
it!) and heard that cmake is more user friendly but no experience.

Then I'd break down libraries by functionality, aiming for a single lib
that does what most people want, and maybe some add-ons for less often
used functionality that's unsuitable for the main lib e.g. because it
has some overhead associated or is incompatible in some way with things
some people might want to do. 

As a user of pantheios I know I'll need syslog and file backends as a
baseline, but I'd like my users to be able to enable additional funky
backends that I may not even know of yet, so being able to load back-end
shared libs dynamically based on some configuration would be very cool.


View raw message