[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: using boost headers

On Sat, 18 Aug 2007 15:24:32 -0500 (CDT)
Carlo Segre <segre@iit.edu> wrote:

> > Potential problems:
> > 1. file collisions. Make sure the internal versions are installed as
> > package-specific libraries, NOT into /usr/lib/ directly.
> The boost libraries are simply includes, no binary libraries are included. 
> It is reallly not a "library" in the traditional sense.

So one issue is build-time collisions. What happens if someone wants to
build your unpatched package (outside a chroot) and they have the
Debian headers installed?

> > 2. Wasted archive space - your packages simply duplicate existing
> > archive code.
> >
> That is true although until now I have not wanted to alter the original 
> tarball just not use the included headers.

Then you have a bad situation where the definitions in the headers get
out of sync with the libraries being called (as these are external).
There are quite enough problems with library transitions without
complicating things like that.

What are the consequences of using the external headers vs the internal
headers? What parts of the package benefit from the internal

> > 4. The most important reason: The copy of the boost libraries in your
> > internal code is NEVER going to get the level of inspection and testing
> > conferred upon the standalone package. Your code will stagnate, it will
> > harbour bugs fixed in the external version. In short, it will suffer
> > bit rot. This should be avoided at ALL costs.
> Agreed but again, they are includes and so will only influence the 
> binary of this particular package.  In some senses it is analogous to the 
> author rewriting functions and putting them in his code instead of using 
> someone else's.

OK, take a different example:

libglib2.0-0 includes time and date handling that is not 64bit-safe (on
32bit systems, glib2 will overrun in 2038) so in libqof1 (which depends
on libglib2.0-0), I reimplemented the functions to be 64bit-safe on all
platforms. I now have an added maintenance burden of testing and
checking that changes to glib2.0 in future don't conflict with my
re-implementations. I handle this with a test case upstream and by
making my versions quite clearly different (and explicitly supporting
conversions to and from the glib2 types within the ranges that are
compatible). The easier option would have been to just let my code fail
on 32bit systems after 2038 or wait for glib2 to fix that issue (it's
not just an issue of whether  32bit is still around in 2038 - we may all
be using 128bit chips in our mobile communication devices by then. The
problem is that my code is used in financial programs and supports
financial forecasts like the ability to calculate mortgages and other
long term investments that could fall over as soon as 2013, i.e. 6
years from now). Somehow, I suspect that a LOT of 32bit hardware will
still be in use in 6 years, especially embedded stuff. Heck, some of
that is still 8 or 16bit.

This is what I meant - if you can demonstrate some reason, as above,
that makes it a better idea to use the internal code than to use the
external code, I'd be happy.

What are the differences between the two sets of headers? How will you
reconcile differences in future?

If the external headers change in areas *other than* the ones that
benefit the package (e.g. when glib2 fixes other bugs that are not
re-implemented in my code), how easy is it to merge the changes?

> This is the thing aobut boost, it is not a library but basically a set of 
> functions taht gets included in your program. 

Those functions have to live somewhere. Headers are useless without
a .c/.cpp file somewhere.

> I am far from a C++ expert 
> but this seems to me to be not as clear cut a situation as a binary 
> library or even Perl modules, where it is very clear cut that the Debian 
> package is the right way to go.

Whatever is defined, declared or configured via the headers has to
actually be called from one binary location and be executed using
binary instructions that exist in memory, somewhere. Headers are not
compiled so there has to be some C++ somewhere, in a boost library or a
standard library, that is being called via the headers in your package
and those calls will be changed by the definitions in the headers
(otherwise, why worry about the changes at all?).

Changes in the external library will change the external headers and
when that involves an API transition, your internal headers will be out
of sync. That means a FTBFS bug or a series of nasty seg fault bugs.


Neil Williams

Attachment: pgpHbKmeXZhd9.pgp
Description: PGP signature

Reply to: