Boost logo

Boost-Build :

Subject: [Boost-build] Failing dependency_test.py test.
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-07-15 18:19:30


   Hi.

> -d+12 is helpful for this kind of thing.
> It sounds like there could be some kind of spurious dependency.

   Yeah, almost lost my eyesight staring at the -d+3 & -d+12 output
trying to reason out what is going on.

   My current guess is that there is a problem with generators
generating multiple targets from a single one and how Boost Jam/Build
deduces those targets should be rebuilt.

   I've attached the simplest possible test I've managed to reproduce
the problem with. The test passes (most often) if you set the sleep
delay used in that test to 0. However, the test fails every time if you
set it to 2 seconds.

   Updating Boost Jam to support more precise timestamps also makes it
fail every time - even with the sleep delay set to 0.

   If you or someone else could take a look - I'd be grateful... I hope
to have the time to look into it again tomorrow or a bit later during
the week...

>> Btw. I'm still not positive, but I think there might be a potential
>> problem in that dependency_test.py test (and possibly others using the
>> same implementation pattern) that is causing it fail sporadically with
>> the current implementation but is uncovered completely by using a finer
>> timestamp resolution. It creates CPP & H targets from a FOO target in
>> its foo.foo rule instead of the foo.foo action. That causes those
>> targets to be created every time instead of 'only when needed'.
>
> The print module creates proper updating actions.
> It doesn't write the files immediately.

   Thanks for the tip. I did not really look into how it does its magic,
but I can see it does not take the information about whether it needs to
actually touch its file based on whether it is older than its source, so
I'm guessing it does the rebuild every time. I'll look into this more
when I get the time next.

   Best regards,
     Jurko Gospodnetić




Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk