[BuildTools] Proposal: XXX_SVN_REV change from quoted string to numeric

[Ted Ralphs]

On Thu, Sep 2, 2010 at 1:37 PM, Lou Hafer <lou at cs.sfu.ca> wrote:

>> But I'm not so sure that this will be useful for him, because changes to
>> old stables will also bump up the XXX_SVN_REV, ...
>
>    True.  It's not a panacea. But within any of trunk, stable, or release, it's
> monotonically increasing. So within trunk,
> #if CLP_SVN_REV >= 42
>    // use new infeasible ray   (good guess  :-)
> #endif
> should work even if the revision number is bumped due to changes in a stable
> branch. Similarly within a given stable or release.
>
>> Apart from the above, having the revision number not quoted is a good
>> thing, I believe.
>
>        I'll take that as a vote in favour of making SVN_REV numeric.  Seems
> like a good idea independent of whether it's a full solution for the problem at
> hand.

I've thought about it and I don't really see a problem with this. Makes sense.

>> One could make XXX_VERSION unquoted and define an XXX_VERSION_QUOTED for
>> convenience ...

Probably not necessary, but we could think about it.

>        I guess I'd like to see how the whole libtool versioning thing develops
> before committing to this. In theory, the libtool version string should be more
> accurate, but perhaps harder to parse?

I think the libtool versioning is a red herring for this discussion.
First, it will only ever apply to releases, so it is not a solution
for referring to versions of trunk and stable. Second, I don't think
we will ever want to refer to the libtool version number in this way
anyhow. It's meant for the linker to figure out what version to link
to, not really for humans. I think it is typical to have a
human-parsable version string separate from the libtool version. So I
would say go ahead with this. Don't worry about the libtool versioning
stuff.

Cheers,

Ted
-- 
Dr. Ted Ralphs
Associate Professor, Lehigh University
(610) 628-1280
ted 'at' lehigh 'dot' edu
coral.ie.lehigh.edu/~ted