[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Suggestion about derived files and commands

From: Rajesh Vaidheeswarran
Subject: Fwd: Suggestion about derived files and commands
Date: Thu, 26 Apr 2001 22:39:03 -0400 (EDT)

--- Begin Message --- Subject: Suggestion about derived files and commands Date: 25 Apr 2001 18:34:39 +0200 User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)

I'd like to use Cons to build our product. One drawback I can foresee
right now is that we heavily use -DSOMETHING compilation option to
choose some options of our software.

In some cases, that may be a problem.

Suppose that I have a compilation involving several hundred of C

Then I build the product and test it.

Then I discover a bug and I need to enable some instrumentation code
in the product embedded in #ifdef LAB_TEST ... #ENDIF in 2 or 3 C
files. To do this I'll add '-DLAB_TEST' in the CFLAGS variable used to
create a new cons environment.

So cons will recompile all c files to produce the object files since
the compilation command has changed.

That's fair enough since cons cannot parse the C files to know whether
a derived file is affected by the -DLAB_TEST flag.

But when I remove the -DLAB_TEST flag, cons will rebuild again all
object files. That's may be quite long.

According to the cons man page, the signature of a derived file is
computed from:
- the c files
- all included h files
- the actual compilation command

So, would it be possible (or a good idea) to modify cons so that cons
keeps somewhere a hash for each derived file:
- the key would be made of the signature as explained above
- the value would be made of the signature of the object file.

So that when cons considers to rebuild a derived file, it would:
- compile the expected signature as usual
- check if a key exists in the hash for that expected signature
- if no -> rebuild
- if yes, compute the signature of the current object file (or
  retrieve a stored value) and compare it with the value stored in the
- if the 2 signatures of the object files match -> no rebuild
- if the 2 signatures of the object files don't match -> rebuild

This way, unnecessary rebuild of derived file could be avoided.

In fact, this mechanism is very close to the mechanism used by the
memoize module. (See

So, what do you think of this idea ?

Thanks for your time.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]