Re: [boost] Fw: Interlibrary version cchecking

Subject: Re: [boost] Fw: Interlibrary version cchecking
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-18 18:36:38

At Mon, 18 Oct 2010 13:45:08 -0800,
Robert Ramey wrote:
> 
> David Abrahams wrote:
> > At Mon, 18 Oct 2010 10:29:14 -0800,
> > Robert Ramey wrote:
> >>
> >>> Your scheme seems a lot more complicated than industry standard
> >>> practice, which is to use one or two long integer constants as
> >>> macros (c.f. __GCC_VERSION__ and friends).
> >>
> >> Since I wrote that, I have had occasion to investigate the
> >> versioning scheme suggested for linux shared libraries.  It seems to
> >> me that this proposal is remarkably similar to that used for these
> >> libraries:
> >>
> >> see
> >> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
> >
> > Really?  What parts do you see as similar?  It jumps out at me that
> > your proposal is full of source code and that page doesn't seem to
> > have any recommendations for source code (unless I overlooked them)
> 
> I was referring to the scheme itself - I don't remember where I saw it
> but maybe I cited the wrong page.  ....so files have major and
> minor release.  I think that the major one refers to an api change
> while the minor refers to an implemenation change and/or
> enhancement.

Yes, that's "industry standard" practice.

> I don't remember where I saw it, but I believe it was something like
> this
> http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
> where there are several levels of "versions" so that I can specify
> what level of dependency my code has on other packages.

Sure, I thought everybody was aware of that sort of scheme, and what
you were mostly proposing had to do with how it was expressed in code.

> >> among many others.  My proposal is only an idea and I'm
> >> not prepared to mount a serious defense of it.  But it seems
> >> that something along these lines is going to be necessary.'
> >
> > Yes, something along these lines.  I'm just wondering if you are
> > reinventing tank treads when we already have a perfectly good wheel.
> 
> I hope so, but I'm not seeing it.  The ....so.m.n.o scheme is fine
> as far as it goes - but It doesn't say anything about how it is to
> be enforced at compile/link/runtime.  As far as I can tell,
> dependencies of header only libraries aren't even considered.

So now we're back to expressing it in code.

> >>> That's also useful for > #ifdefing, whereas mpl::int_<>s are not.
> >>
> >> Well, if you want to enhance my proposal to add constants and
> >> have the mpl_<... or static assert  use those constants, that would
> >> be fine with me.
> 
> > Why do you want the mpl_<...> thing in the first place?
> 
> So that immediately when attampting to compile things would crap out
> and not depend on this or that instantiation.  

#defines do that nicely too.

> I wouldn't have to scatther #ifdef/... all over the place.

I don't know what you're talking about.  Wouldn't you just do
something like

  STATIC_ASSERT(LIBFOO_VERSION >= 4001003); // libfoo must be 4.1.3 or later

? I don't see any #ifdefs here.

> As soon as I include a header that's too old
> it fails in exactly the right place.  

Doesn't the above accomplish it?

> If the code isn't recompiled, the construction of the static runtime
> variable should force the system to fail immediately as well rather
> than just running until it fails.  Again - all without having to
> scatter if/else ... all over the place.

I think maybe you're being a bit dramatic about this :-)

The advantage I was citing for a preprocessor #define is that you
*can* use #ifdefs, if and where you need them.  It doesn't mean you
have to.  They do everything your mpl typedefs do, and more.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com