[boost] Re: Cvs tag dependency

From: Larry Evans (cppljevans_at_[hidden])
Date: 2004-06-30 14:20:22

On 06/30/2004 01:08 PM, Rozental, Gennadiy wrote:
[snip]
> Example3:
> 
> Jamfile
> -------
> 
> exe my_test : ...sources... <tag:1_30_0>...abc.h
> 
> Here I know my code works with that version of header file I want to use it
> specifically.
> 
> And so on.
> 
> This feature could allow us to:
> 
> 1. Test development branches for regressions 
> 2 .Test new features before moving it in cvs HEAD
> 3. Depend on stable version of dependency, without need to keep up with
> changes in it.
> 4. Test development version Boost.Test with stable version of it
> e.t.c
> 
> I am sure it's not easy to do. But may be it worth a shot.
> 

I've had a similar problem where I frequently try different versions of 
files, get the exe to run, then make several changes and get the exe to 
work, etc.  I would like to be able to revert to all the files which the
exe depended on at a specific date.  The way I've done it is to keep the 
dependencies for each "version" of the exe I might want to revert to.
The dependencies are kept in:

   <toplevel>/release/<how>/<what>/my_test.release.log

where:
   <toplevel> is similar to the boost build directory
   <how> is a subpath encoding which compiler and options are used,
      e.g. intel/debug
   <what> is a subpath encoding what is being created, e.g.
      libs/managed_ptr/test
   and the my_test.release.log records all dependencies and the
      versions used to create the exe.  For example:

1.1 ./boost/managed_ptr/auto_overhead.hpp
1.2 ./boost/managed_ptr/basis_specializer.hpp
1.9 ./boost/managed_ptr/cycle_basis_mgr.hpp
1.25 ./boost/managed_ptr/managed_ptr_ctor_forwarder.hpp
1.5 ./boost/managed_ptr/marg_ostream_refcnt_overhead_ptr.hpp
1.4 ./boost/managed_ptr/optimally_inherit.hpp

The release.logs are versioned just like any file; hence,
instead of remembering which tag to specify for each file, you
could just specify which version of the release.log you wanted to
use.

Of course this would require reworking for use with bjam, since bjam
uses a completely different method for recording <how> and <what>, but
the idea that might be useful to you in bjam is the release.log.
I was actually thinking about doing something in bjam --v2 to emulate
this since I've often felt the need.  Would this satisfy your needs?