--- 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) |
Hello
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
files.
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
hash.
- 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 http://search.cpan.org/search?dist=Memoize)
So, what do you think of this idea ?
Thanks for your time.
--
address@hidden
--- End Message ---