Re: [Plib-devel] New CVS of PLIB pre-1.3.1

[Curtis L. O. <cu...@me...>]

Steve,

Is there any way that you can engineer things on the plib end to
generate some sort of helpful error when a current application that is
expecting plib-1.2.x (and doesn't remember to call ulInit() for
instance) suddenly is compiled against plib-1.3.x.  My fear is that 6
months down the line when plib-1.3.x transitions to the stable tree,
I'll have completely forgotten this message and will end up wasting a
lot of time.  :-)

Steve Baker writes:
> I've committed code into the PLIB 1.3 CVS tree that turns the 'UL'
> (Utility Library) from a somewhat invisible header file into something
> that the application code has to be aware of.
> 
> Previously, SSG used the src/util/ul.h header with a rather nasty
> trick to get the non-inlined functions compiled into the SSG library.
> 
> That was necessary for backwards compatibility of application's
> Makefiles.
> 
> Well, it's time to make libplibul.a and plib/ul.h into a 'real'
> utility library.
> 
> So, from the current CVS (which will soon be PLIB 1.3.1) onwards,
> applications must (at the very least) add '-lplibul' to their
> link lines (after all the other plib libraries is best).
> 
> This library will grow to include a number of functions that are
> traditionally Operating System functions - but which wouldn't be
> portable if you called the OS directly.  Other similar utility
> stuff that doesn't obviously belong anywhere else in PLIB will
> end up in libutil.
> 
> So far, there is a simple error handler (which is already in
> use within SSG's file loaders) and a fast, portable realtime
> timer class.
> 
> [ PPE is currently using 'guClock' from the TuxKart sources,
> this class exists in UL - but it's called 'ulClock', it includes
> member functions to set and get the maximum clock delta and has
> Windoze code to cater for systems that don't support the Performance
> Counter - it falls back to using the multimedia timer. ]
> 
> Right now, no PLIB applications will work with this new CVS version.
> 
> That's not a suprise - this is version 1.3.xx and it's expected to
> be unstable, etc.  If you need stability, use PLIB 1.2.0.
> 
> Ideally, one should add code into your configure.in to detect the
> presence of /usr/lib/libplibul.a and to add it to the link line
> if it exists.

Is there a good function in libplibul.a that we can test for?
Autoconf has the AC_CHECK_LIB( lib, function) macro that will test for
a library and add it to the link line if it exists.

> Programs that don't use SSG don't need libplibul - but that will
> certainly change as I use UL's error handler throughout PLIB.
> 
> If you want to call UL functions your code, you should:
> 
> 1)  #include <plib/ul.h>
> 
> 2)  Call 'ulInit()' before any other UL function.
> 
> 3)  Link with -lplibul.a
> 
> I hate non-reverse-compatible changes - but this one was unavoidable.
> We may possible add another PLIB library - for SSG utilities - but
> that will be truly optional.  UL is not because PLIB itself needs
> to use it.
> 
> Windoze users: Please don't get confused and look in the 'src/UL'
> directory for UL source code - that was a mistake that CVS isn't
> capable of fixing.  The correct place for UL code is src/util
> 
> If anyone out there could test ulClock under Windoze - and especially
> on a Windoze machine that *doesn't* have a Performance counter - that
> would be most welcome...I don't know whether the code even compiles
> right now.

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org