Nick Ing-Simmons wrote:
>Nicholas Clark <[EMAIL PROTECTED]> writes:
>
>
>>On Wed, Jun 02, 2004 at 01:46:09PM +0100, Nick Ing-Simmons wrote:
>>
>>
>>
>>>The way to do it is nominate one of UNIDATAFILES (ideally the last one
>>>written) as _the_ dependancy. (I don't see a definition of UNIDATAFILES
>>>in your patch)
>>>
>>>
>>While this would work, I'm not keen on this because
>>
>>1: It would force the name of the file to be hard coded in a second place in
>> the makefile
>>
>>
>
>One can play silly b****s like
>
>UNIDATAFILE = File1
>UNIDATAFILES = $(UNIDATAFILE) File2 ... File6
>
Then you have the 'all' target dependent on UNIDATAFILE, which could
easily look like a typo -- 'all' really depends on all the UNIDATAFILES,
so I like it better if it says so.
>>>Or invent a pseudo target thus:
>>>
>>>$(UNIDATAFILES) : unidataready
>>># Nothing here - the nothing happens 7 times ...
>>>
>>>unidataready : $(MINIPERL) $(CONFIGPM) ..\lib\unicore\mktables
>>> cd ..\lib\unicore && ..\$(MINIPERL) -I.. mktables
>>>
>>>
>>I like this better.
>>
Me too. It puts the silly buggering about bit right where the problem
is instead of moving it to elsewhere in the makefile, so it's clearer
what it's being done for.
However, this solution still has a problem: when running "dmake test"
(after a successful "dmake"), the mktables program now gets run again!
Why is that? I've attached a patch so you can see what I've done. As I
see it, test depends on test-prep, which depends on all, which depends
on $(UNIDATAFILES), but that is up-to-date so why is it getting made
again? All the files listed in $(UNIDATAFILES) have been created and
have the correct mtime.
I tried explicitly "making" one of the $(UNIDATAFILES) and found it does
the same:
C:\Temp\perl-5.9.x\win32>dir ..\lib\unicore\Canonical.pl
File Not Found
C:\Temp\perl-5.9.x\win32>dmake ..\lib\unicore\Canonical.pl
cd ..\lib\unicore && ..\..\miniperl.exe -I.. mktables
C:\Temp\perl-5.9.x\win32>dir ..\lib\unicore\Canonical.pl
03/06/2004 11:59 20,338 Canonical.pl
C:\Temp\perl-5.9.x\win32>dmake ..\lib\unicore\Canonical.pl
cd ..\lib\unicore && ..\..\miniperl.exe -I.. mktables
Another joyful quirk of dmake, I guess. The following makefile
reproduces the problem:
FILE = ..\one.txt
all : $(FILE)
$(FILE) :
cd .. && echo One>one.txt
If I run "dmake ..\one.txt" from C:\Temp then C:\one.txt gets created,
but when I re-run the same command it runs the rule again, re-creating
C:\one.txt! Needless to say nmake and GNU make both say ..\one.txt is
up-to-date. I'm beginning to not like dmake very much.
Do any cunning solutions spring to mind for this one?
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of Radan Computational Ltd. The
recipient(s) of this message should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused by any virus transmitted
by this email.
--- win32/makefile.mk.orig 2004-06-01 15:52:55.000000000 +0100
+++ win32/makefile.mk 2004-06-03 10:10:02.777436500 +0100
@@ -1290,7 +1290,12 @@
$(MINIPERL) -I..\lib ..\splittree.pl "../LIB" $(AUTODIR)
$(RCOPY) ..\lib $(INST_LIB)\*.*
-$(UNIDATAFILES) : $(MINIPERL) $(CONFIGPM) ..\lib\unicore\mktables
+# Move the rule for making $(UNIDATAFILES) into a separate target and leave the
+# actual rule here blank because dmake runs the rule here once for each of the
+# files listed in $(UNIDATAFILES)
+$(UNIDATAFILES) : make_unidatafiles
+
+make_unidatafiles : $(MINIPERL) $(CONFIGPM) ..\lib\unicore\mktables
cd ..\lib\unicore && \
..\$(MINIPERL) -I.. mktables
