Re: [boost] The problems with Boost development

Subject: Re: [boost] The problems with Boost development
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-03-24 13:25:01

Dave Abrahams wrote:
> Robert Ramey <ramey <at> rrsd.com> writes:
>
>> I can't figure
>> out how other authors run all the tests in their particular libraries
>> prior to checking in or how users verify that any particular
>> library works in their environment without some sort of tool
>> such as this.
>
> I just run bjam (from within emacs using `M-x compile RET bjam RET').
> At the end it tells me if there were failures.  If there were, I hit
> f4 (which I've bound to "show me the next error") and go look at the
> problem.  It brings me right to the source line in question and
> highlights the error, right there in the program I use to edit code.
> I find that much easier
> than trying to deal with it through a web interface.  I guess it never
> occurred to me what a PITA this must be fore people who don't have
> something similar set up!

Actually this is an entirely different problem - with an entirely different
solution.  What I do is the following:

* I use msvc 7.1 for my "default" development platform.
* I have a VCIDE "project" for each serialization library (narrow and wide 
characters),
a project for each test, and a project for each demo. Each test project has
a "after build" command which runs the test any time it is rebuilt.
* I have a VCIDE "solution" which contains all of the above projects.
* I also have some "configurations" for switching build types to dll, static 
lib,
debug, release, etc.

So here's my work flow.

a) User reports a problem with small example
b) I paste his source into a special project I have for this purpose 
(test_zmisc).
c) I build the test_zmisc project.  If it fails to build with a compile 
error, I can
jump right to the code and address it - this includes code in other projects
such as libraries.
d) I use the MSVC debugger (the gold standard in my opinion)  to trace 
through
and discover the problem.
e) I tweak code in headers/libraries until I think i've addressed the 
problem.

Now, I want to re-run ALL the tests so that I'm not playing whack-a-mole.

For THIS I use library_test (.sh or bat) to update my giant test results
table.  I can't imagine doing this by running bjam for each combination
of compiler, and build variant.  It seems that it's either that or just 
check-in
the changes and watch the trunk tests.  The latter doesn't provide the
instant gratification that I require.

When my table is updated, I can click to see the messages associated with
any failure.  Then I go back to my MSVC environment to described above.

To my mind, there is no feature of this procedure that I think I can
do without.  I can't see how anyone can do this kind of work without
these components:

* IDE to build, test and debug particular tests (I would guess EMACS 
fullfills this need)
* The ability to run a large number of tests in one's local environment and 
permit
the browsing of results.

How do people do this later task without something like library_test?  What 
do
other people do instead?

Just so you can see what I'm talking about, here is sample output from 
library_test. 
http://www.rrsd.com/software_development/boost/library_status.html

Robert Ramey

>
> not-an-editor-but-an-operating-system-ly y'rs
> Dave
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost