stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: _RWSTD_VER value on trunk
Date Wed, 19 Dec 2007 05:16:50 GMT
Travis Vitek wrote:
> Martin Sebor wrote:
>> Travis Vitek wrote:
>>> Martin Sebor wrote:
>>>> This has been bugging me -- when someone checks out trunk, does a build
>>>> and sends
>>>> us build results, we have no way of telling that the build results are,
>>>> in
>>>> fact, for trunk and
>>>> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is
>>>> the same. I
>>>> think we should change it so that the value is unique for each branch,
>>>> or
>>>> at least distinct
>>>> from any release.
>>>> Any suggestions for what would be a good value?
>>> Martin,
>>> If all you care about is detecting what branch the results are for, why
>>> can't we just dump $HeadURL$ of the GNUmakefile to the top of the build
>>> results?
>> Yes, I think that's what Mark meant. I like the idea I just wasn't
>> sure I wasn't missing some downside since we'd be taking the macro
>> out of $TOPDIR/include/rw/_config.h and moving it to the generated
>> config header in $BUILDDIR. I.e., it won't be possible to grep for
>> the macro in the freshly downloaded/extracted sources to find the
>> version -- see my comments below:
>> But unless someone does come up with a problem I'll go ahead and
>> cook up something along these lines.
>> Martin
> I think you are taking this a bit further than I am talking about. In your
> original post you say we don't really have no way to tell which branch the
> user did their build from. I'm saying just add a target to the GNUmakefile
> that dumps the expanded $HeadURL$ string, and then use it in the build
> process.

We also need to #define the _RWSTD_VER macro so that users can use it
in preprocessor conditionals. But the idea is essentially the same:
GNUmakefile.cfg would take the value of $HeadURL$, extract the part
that contains the version if it's there or "trunk," and append the
result to the generate config.h in the form of a couple of macro
#definitions, one for _RWSTD_VER and one for _RWSTD_VER_STR (in
addition to using it in the name of the [shared] library). Or is
this not what you're talking about?

> It sounds like you are trying to establish a strict mapping between the
> library version and where the sources are kept in subversion.

That's right. The version reported by a checkout of branches/4.2.x
would be "4.2.x" (and _RWSTD_VER & 0xff00 would have to be something
like 0xff00, to borrow Andrew's convention). Which would reinforce
the guideline that a branch should never be released (tags are).

The version reported by a checkout of tags/4.2.1 would be 4.2.1.

> What do other
> subversion projects do about this?

Good question! Let's find out. I know gcc uses macros defined in
its makefiles but I don't know how the macro values are derived.

> It seems that this wouldn't be a problem if we had a 4.2.1 branch and we
> could 'encourage' users to leave the intermediate branches [the ones used
> for merging] alone.

Exactly. Except it's not called a branch but a tag.


View raw message