Issue 78837 - Infering a %-target can make dmake think this target exists already
Summary: Infering a %-target can make dmake think this target exists already
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: dmake (show other issues)
Version: current
Hardware: All All
: P2 Trivial (vote)
Target Milestone: ---
Assignee: hjs
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-24 18:33 UTC by quetschke
Modified: 2013-08-07 15:34 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Logfile illustrating the problem (32.21 KB, patch)
2007-06-24 22:49 UTC, quetschke 		no flags Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description quetschke 2007-06-24 18:33:16 UTC 
I found this while chasing issue 78506. It seems that when a %-target is infered
the internal representation already gets a file date assigned even though the
target is not yet build. If this target is than used as a prerequisite for
another target that is started later it assumes that the prerequisite exists.
This is most likely to happen in parallel builds, because in a sequential build
an infered target is likely to be build immediately.

I don't have a reduced testcase, but it is easy to reproduce with
desktop/zipintro from SRC680_m216. The attached logfile was generated with:

$ rm -rf wntmsci10.pro zipintro/delzip; cd zipintro
$ dmake -vcdfimrw -m -P2

If one follows dev_intro.zip one sees:

...
dmake:  Time stamp of [../wntmsci10.pro/bin/dev_intro.zip] is 0
...
e target 1182703364.140 last_target
dmake:  Infering prerequisite(s) and recipe for [../wntmsci10.pro/bin/dev/intro.zip]
dmake:  Trying prerequisite [../wntmsci10.pro/bin/dev_intro.zip] for
[../wntmsci10.pro/bin/dev/intro.zip]
...
dmake:  Infering prerequisite(s) and recipe for [ALLTAR]
dmake:  Time stamp of [ALLTAR] is 0
dmake:  Time stamp of [../wntmsci10.pro/bin/dev_intro.zip] is 1182703364
...
... Oops!! It is not build yet and has a timestamp?!
...
dmake:  Time stamp of [../wntmsci10.pro/bin/dev/intro.zip] is 0
dmake:  >>>> Making [../wntmsci10.pro/bin/dev/intro.zip]
s target 1182703364.155 ../wntmsci10.pro/bin/dev/intro.zip
dmake:  Updating [../wntmsci10.pro/bin/dev/intro.zip], (1182703364 > 0)
mkdir ../wntmsci10.pro/bin/dev/
cp ../wntmsci10.pro/bin/dev_intro.zip ../wntmsci10.pro/bin/dev/intro.zip

Boom!

This might actually be related to issue 69462.
Comment 1 quetschke 2007-06-24 22:49:55 UTC 
Created attachment 46218 [details]
Logfile illustrating the problem
Comment 2 quetschke 2007-07-25 05:10:39 UTC 
The issue is really fixed by issue 69462. This is a testcase for this problem:

- - - -
SHELL*:=/bin/sh
SHELLFLAGS*:=-ce

%.aaa : %.bbb
	@echo building $@

%.bbb :
	@echo building $@
	@sleep 1
	@echo finished $@


all : aaa.aaa
	touch $@
	@echo Done
- - - -

$ rm aaa.* ; touch aaa.aaa ; dmake.exe -rf makefile.mk

Before the fix aaa.bbb is never build.
Comment 3 quetschke 2007-07-28 03:13:06 UTC 
Committed the testcase to dmake411
Comment 4 quetschke 2007-07-28 03:16:15 UTC 
@ause: Please verify that the testcase works.
Comment 5 hjs 2007-09-26 14:36:22 UTC 
testcase works
Comment 6 hjs 2007-12-21 13:55:44 UTC 
dmake 4.11 is in use now