qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: C++ logging - anyone heard of pantheios?
Date Wed, 09 May 2007 23:38:12 GMT
Fancy backends?

Its "only" logging - I've found the entire world resolves down to files and
syslog; any fanciness tends to go the way of the dinosaur by being too
complex for joe average </speaking-from-bitter-experience>

With files (pipes) and syslog its amazing what you can do.

I do like the rlog idea -- seems very "dtrace" in its conception.  Cool, but
too cool for its own good?
As you say, thread nastiness may await where a hardware platform cant
replace a function pointer in one atomic memory write.

John

On 08/05/07, Alan Conway <aconway@redhat.com> wrote:
>
> 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.
>
> Cheers,
> Alan.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message