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 <[EMAIL PROTECTED]> 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.
