[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Command Dependecies broken
From: |
Steven Allen |
Subject: |
Command Dependecies broken |
Date: |
Wed, 26 Jun 2002 13:41:25 -0400 |
I noticed this bug/feature a year or more ago, and I thought it had been
fixed, but apparently not. This broke sometime after cons 2.2, because this
behaves correctly on cons 2.2 (or at least I think the 2.2 behavior is
correct).
I am running the latest version extracted from cvs on
:pserver:address@hidden:/cvs.
A three line contruct file:
$env = new env();
Command $env "foo.3", "foo.2", "cat foo.2 > foo.3";
Command $env "foo.2", "foo.1", "cat foo.1 > foo.2";
And one source file foo.1 with the number 1 in it (or whatever).
I run cons, and files foo.2 and foo.3 are built as expected. But here's the
"feature", that I guess I understand, but I consider it a bug.
If I then manually "echo asdfadsf > foo.2" and run cons again, I get:
cons: "." is up-to-date.
Even if I specifically try to rebuild foo.2 with "cons foo.2" I get
cons: "." is up-to-date.
Now I could imagine that cons thinks this is a itermediate file and it
doesn't need to be rebuilt, but it really isn't in this case. I couldn't
find anything in the man pages/FAQ stating that intermediate files are not
rebuilt. And if I say "cons foo.2", then it is no longer an intermediate
file... It is a target, and the the target has changed!!!!
Digging through the code, trying to figure this out....
Bet I can get to so far is that cons2.3 now differentiates between a "build
signature" and a "content" signture. The build line doesn't change when a
file gets corrupted, but it's content signature sure does. In cons2.2 the
signature was a combination of both command line and content. Shouldn't
this still be the case?????
At this point I am thrashing so I'll ask for help in solving this.....
SteveA
-----Original Message-----
From: Steven Allen [mailto:address@hidden
Sent: Monday, September 24, 2001 2:12 PM
To: Cons-Discuss
Subject: Cons 2.3 Command dependencies broken?
I downloaded the beta version of 2.3 a week or so ago (finally), and after
some head scratching I discovered a bug in it (I think). I couldn't find
any documentation saying this had changed, and it works fine in 2.2 so I'm
assuming it's a 2.3 bug (since it almost works).
I'm emailing to the list in hopes that someone else has already fixed
this....
Basically, the "Command" targets can't be a hash/list or dependencies are
not calculated correctly. I.E. in 2.2 and 2.3 this works fine, as expected:
Command $env "foo.3", "foo.2", "cat foo.2 > foo.3";
Command $env "foo.2", "foo.1", "cat foo.1 > foo.2";
Any combination of changing foo.1 or foo.2 or foo.3 works as it should.
However this works as expected (i.e. the same as above) in cons 2.2 but NOT
2.3.
Command $env ["foo.3"], "foo.2", "cat foo.2 > foo.3";
Command $env ["foo.2"], "foo.1", "cat foo.1 > foo.2";
I.E change foo.1 and only foo.2 changes. A second run of cons is required
in order to update foo.3.
And yes, adding a Depends command fixes this, but how ugly is that given
there's already a clear dependency list here (the arguments to the
"Command" command).
If you want the test files I used to prove this to myself, email me and I'll
be happy to send them to you...
Steve Allen
_______________________________________________
address@hidden http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/
- Command Dependecies broken,
Steven Allen <=