Re: [boost] Fw: Interlibrary version cchecking

Subject: Re: [boost] Fw: Interlibrary version cchecking
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-10-18 17:45:08

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.
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.

>> 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.

>>> 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.  I wouldn't have to scatther
#ifdef/... all over the place.  As soon as I include a header that's too old
it fails in exactly the right place.  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.

RObert Ramey