[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Time stamp resolution
From: |
Jason Pearce |
Subject: |
Time stamp resolution |
Date: |
Mon, 24 Jan 2005 20:12:27 +0000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 |
I am having problems with a build system based on Make. It is quite a
complex issue but I have traced it to what I believe to be a time stamp
issue. I would really appreciate some help.
I think the heart of my question is:
Is it safe to assume that two files, generated in sequential order, will
always have increasing time stamps?
For example:
> touch file1; touch file2
Can I then rely on (time stamp of file1) < (time stamp of file2)?
The background details are as follows.
I am compiling VHDL. I have a script which generates the dependencies
for each VHDL compile, generating a fragment file vhdldep.mak with the
rules in it. But some of my sources are generated, so the compilation
gets done in 2 steps.
> make sources
> make top_entity
The target top_entity comes from the makefile fragment, it is the top
level test bench which is the result of compiling one of the generated
sources. (A simplified Makefile is at the bottom of this mail).
The first call to make generates an incomplete vhdldep.mak file because
the generated sources have not been generated yet! As that make session
runs, the sources get generated and on the next call of make, the
freshly generated source files (should) trigger vhdldep.mak to be
regenerated, now in a complete form.
(Aside - I don't know how to do this in one step, I think Make will only
create its dependency tree once per run).
Now this all works perfectly well under Cygwin (and I am completely
confident it the generated dependencies are correct). But on a HP box
and a Linux machine the rebuild of vhdldep.mak is not getting triggered.
It seems to be caused by "identical" time stamps on my generated sources
and vhdldep.mak. Touching any source or uncommenting the sleep command
within the rules for vhdldep.mak makes the problem disappear. I get the
same behavior on network and local disks.
So I am now unsure whether I should be checking the time/file system
configuration of my Linux and HP boxes, or if I am simply relying on
something I can not - that sequentially generated files will always have
a monotonically increasing time stamps.
Regards,
Jason
VHDL_SOURCES := $(wildcard *.vhd)
vhdldep.mak : ${VHDL_SOURCES}
perl vhdldep.pl -t mak ${VHDL_SOURCES} > vhdldep.makfail
# sleep 1
/bin/mv vhdldep.makfail vhdldep.mak
include vhdldep.mak
sources:: generated1.vhd
generated1.vhd : generated1.vhd.m4
m4 generated1.vhd.m4 > generated1.vhd.fail
/bin/mv generated1.vhd.fail generated1.vhd
sources:: generated2.vhd
generated2.vhd : generated1.vhd.m4
m4 generated2.vhd.m4 > generated2.vhd.fail
/bin/mv generated2.vhd.fail generated2.vhd
- Time stamp resolution,
Jason Pearce <=