Re: Long builds and dependency checking

[Jens Schweikhardt]

On Thu, Jul 26, 2001 at 04:55:24PM +0000, Bhatt, Milan C wrote:
# Alright I can see more clearly now what you're talking about, but it
# wouldn't work for my problem.
# 
# Here's an example of what I'm doing:
# 
# a : b c
#       @command
# 
# If start 'gmake a' at 1pm and 'a' has not yet been created, gmake will of
# course execute the command.
# Now let's assume that the command takes 2 hours to execute before it creates
# the target.  So the file 'a'
# will be created with a timestamp of 3:00pm when it is written out to disk.
# 
# My problem is, what if in between that time either file 'b' or 'c' are
# modified?  If 'b' was modified at 2:00pm,
# then the target 'a' would never be rebuilt because a has a timestamp of
# 3:00pm and 'b' has a timestamp of 2pm. Therefore
# to gmake 'a' is already up to date and doesn't need to be created.

Ah, now I understand better.

Unfortunately, make is not designed to deal with modifications of
prerequisites during a build. You would have to perform to such
detection by use of commands, which you already do. I think the
technical term here is a race condition -- the outcome depends
on the order of certain events.

My strategy would be to avoid race conditions alltogether in your build.
E.g. if you have a large source tree where some files may change because
of other people's asynchronous modifications, why not copy the tree
to a private directory and then run the build on a stable source tree?
This is easy if you use CVS or something similar.

Regards,

        Jens
-- 
Jens Schweikhardt  http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)