RE: Long builds and dependency checking

[Bhatt, Milan C]

I would like to avoid this problem, but its impossible since some of these
builds take several hours and perhaps even days.  During the build time,
users have to make changes to the prerequisites files as they become
necessary.  It would be messy to have a separate area for builds and a
separate area for where changes can be made since you'd have a replication
data in different places which can get very confusing as the project gets
large.

The solution I had before to this problem was the following:

-----------------------------------------
B := tmp/
 
target1 : $(B)a.txt
    @ls > target1
 
$(B)a.txt : a.txt
    @touch $(B)a.txt
 
In this solution the target is dependant on an intermediate file and its
prerequisite is the actual prerequisite we want.  Therefore whenever the
target is being recreated, the intermediate file  $(B)a.txt will have the
time stamp of when the build began.  Whenever the actual source file a.txt
changes, it will make $(B)a.txt out of date and forcing the recompilation of
the target 'target1'

------------------------------------------

I showed this solution in my previous mail, but it just requires a lot extra
files.  The only other solution I can think of is that immediately after the
build command has completed, you can do a 'foreach' over each of the
prerequisites, checking to see if any of them have a more recent timestamp
than at the beginning of the build.  If any of the prerequisites have more
recent timestamps, then you could 'touch' any prerequisite with the current
timestamp.

So next time the user enters 'gmake', it will re-build the particular
target.

It would be nice if this was a future feature in gmake though :)

Thanks,
Milan
 

-----Original Message-----
From: Jens Schweikhardt [mailto:address@hidden
Sent: Friday, July 27, 2001 12:56 AM
To: Bhatt, Milan C
Cc: address@hidden
Subject: Re: Long builds and dependency checking


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)