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
Yes, that's "industry standard" practice.
> I don't remember where I saw it, but I believe it was something like
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk