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:
http://www.nabble.com/Re%3A-_RWSTD_VER-value-on-trunk-p14340222.html
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.
Martin
