|
|
Boost Testing : |
Subject: Re: [Boost-testing] Trunk testing (general) and MSVC11
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2012-08-27 17:19:42
On Mon, Aug 27, 2012 at 9:48 AM, Christoph Macheiner
<christoph.macheiner_at_[hidden]> wrote:
> "Eric Niebler" <eric_at_[hidden]> wrote in message
> news:50392710.5070707_at_boostpro.com...
>> On 8/24/2012 1:00 PM, Steven Watanabe wrote:
>>> On 08/24/2012 12:39 PM, Eric Niebler wrote:
>>>> I'm guessing
>>>> most of the space is debug information. Is there a way to turn that off?
>>>
>>> Add <debug-symbols>off to the requirements.
>>
>> Done. Thanks, Steven. test_actions.obj alone goes from 63Mb to 12Mb.
>> Many of the other .obj files are also dramatically smaller. This easily
>> outweighs the extra build of the test framework that it requires, which
>> only takes up 22Mb.
>
> Imho, <debug-symbols>off is not the solution to this issue. There is a
> "RmTemps" jam rule that is called after each test, but it only deletes the
> .exe, and leaves the rest of the build output (why it is done like this I
> have no clue). I'd say everything should be built with debug-symbols (to be
> able to debug failures),
Building with debug symbols only makes sense for "run" (i.e. not even
run-fail) tests as those are the only ones one would care about having
a stack-trace.
> and the RmTemps rule should probably delete the
> complete build output on success, and leave everything in case of a failure.
I don't remember the exact implementation, since I only wrote a small
part of this feature, but something like that is what should already
be happening.
> Of course, this might require more changes other than to the RmTemps rule
> alone (and I have no idea how to achieve this). Anybody know how to do this?
All the changes should happen to the testing rules. In particular how
it marks temporaries. It's not particularly hard to mark things as
temporary. But it is hard to make sure one has a sufficient trail from
the sources to the test result artefacts. Because if one doesn't all
you will end up doing is running extra test when the sources don't
really change. Of course that's if you are running incremental
testing. If you are doing full fresh testing runs it doesn't really
matter. And if that's the case you might as well implement the
cleaning out of disk space by adding a post tesitng command that
delete the "bin*" directory after uploading the results.
> This would reduce the disk usage to "almost nothing", during the run as well
> as afterwards.
>
> Also useful would be not to do a svn checkout but a svn export in case I
> don't plan to commit any changes (which most probably is the default). This
> would save half the disk space of the sources (and also time, given Windows'
> filesystem (un)performance). I could do this on my own and run
> with --have-source, but it's easy to implement in regression.py and I don't
> know what other side-effects the --have-source switch has (if any).
I would advise against doing export.. It would definitely same you
disk space. But it would be a serious drag on the servers to have to
fetch the entire source tree each time. And might not even work as it
likely would time out at some point as the server has some serious
limits to reduce svn/web-server contention.
-- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo