|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-05 01:50:08
"Douglas Gregor" <doug.gregor_at_[hidden]> wrote in message
news:0E214EFF-1861-440C-A08F-A76A7B0C0971_at_osl.iu.edu...
>
> On Jun 4, 2007, at 9:05 PM, Gennadiy Rozental wrote:
>
>>
>> "Douglas Gregor" <doug.gregor_at_[hidden]> wrote in message
>> news:6C59A26A-304C-49F8-9559-C0DE31B44163_at_osl.iu.edu...
>>>
>>> On Jun 4, 2007, at 8:37 PM, Gennadiy Rozental wrote:
>>>> "Rene Rivera" <grafikrobot_at_[hidden]> wrote in message
>>>> news:4664AFB4.8050008_at_gmail.com...
>>>>> Because the compiled products, the obj, lib, dll, and exe are
>>>>> huge. They
>>>>> are huge because it's C++ and has a large amount of debugging
>>>>> symbol
>>>>> data, because templates generate log type names.
>>>>
>>>> Why do we keep these once test is completed?
>>>
>>> Because when some small number of files change in Boost, we only want
>>> to rebuild those objects, libraries, and executables that are
>>> actually affected. That's what would give us improved turnaround time
>>> from commit to test results.
>>
>> Umm.. This looks like an area we can enhance. Can't we keep last
>> revision
>> number/last update time along with results?
>
> I don't believe this is possible, and nothing short of an actual,
> working implementation of this idea would convince me otherwise.
> Build/test systems have always worked this way for a very good
> reason: the only way to avoid re-building something when it hasn't
> changed is to keep it around. Most of those intermediate files are
> needed again for minimal rebuilds.
I guess you right. Indeed it's maybe nontrivial. With that in mind we need
to create set of requirements for testing system.
The solution may be in some flexibility. By default we do what we do now (I
still believe 20-30 gigs is not a big deal). We may have to support another
configuration which cleans completely after test is done (essentially
forgetting what was tested) for the system that will run tests by request.
Gennadiy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk