Re: command dependencies broken

[Johan Holmberg]

On Mon, 29 Jul 2002, Timothee Besset wrote:
>
> Yes, it is an important issue obviously. But to me it doesn't look at bad
> as you make it appear in your example. Basically I don't have 'chained'
> dependencies, i.e. it's always a C file modified that leads to rebuilding
> a .so or binary target.
>

I realize that different people have been bitten by the bugs(s?) in
2.3.0 (and later) in different ways. But I still maintain that the
bug I have been tallking about is *fatal*.

I don't think it has anything to do with "chaining".

Cons 2.3.0 (and later) seems to think that a target is up-to-date
if it has been built *once*. You can do whatever you want with a
target after it has been  built: as long as the file exist it is
considered  up-to-date. Isn't that serious ???

( I guess the reason not everyone notice this problem immediately
  is that as long as Cons itself is the only program that initiates
  changes to derived files, one may not notice any difference.

  But one of the good things about Cons is it's accurate
  dependency analysis. That accuracy is *gone* in 2.3.0 (and later).

  A comparision (simplified):

      Tool                    up-to-date when
      ----                    ---------------
      make                    target has "newer" timestamp

      Cons                    target has same dependency-signature
                              and same timestamp as last time

      Cons 2.3.0 (and later)  target has same dependency-signature
                              and exist !!!!!!!!!!!!!!!!!

)

> The bug seems to happen on intermediate dependencies. In my case, hell
> breaks loose with the Install and InstallAs methods. Sometimes it will
> just decide that it's no need to rebuild the thing because it decides sort
> of that the InstallAs object is present and doing just fine.
>

Can this be the same problem that I describe above ?

/johan