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?