Steve Hay <[EMAIL PROTECTED]> writes: >>This is another of those historical things. When there are no dependancies >>some makes run the rule. Easiest fix is not to lie to make - it must depend >>on something >> >OK, that might explain why running "dmake ..\one.txt" always runs the >rule (the ..\one.txt target has no dependencies, so the rule is always >run). But it doesn't explain why running "dmake all" re-creates >..\one.txt every time: the 'all' target does have a dependency (namely, >..\one.txt), and that is up-to-date, so I wouldn't expect that >dependency to be made.
But make applies its up-to-date-ness rules recursively. So it finds it can make one.txt and so applies its rules to that it has no dependancies so _this_ make rebuilds it. > >>(even if as in the pseudo example it is Makefile itself and >>cmd.exe or whatever does echo. >> >>In the UNIDATAFILES case then presumably they depend on mktables >>and possibly $(MINIPERL) >> >The pseudo target (which I called make_unidatafiles) does already depend >on ..\lib\unicore\mktables and $(MINIPERL) (and $(CONFIGPM) as well), so >I'm still confused what's going on here. > >I'm now wodering if it is something to do with relative paths. Ah - do the paths have '/' or '\' in them? Try the other ... Another possibility is that dmake's 'cd' isn't where it should be for it to find the relative file. >If I >change the example above to this: > >FILE = one.txt >all : $(FILE) >$(FILE) : > echo One>one.txt > >then running "dmake all" does what I would expect -- it creates one.txt >if and only if it doesn't already exist. (And, in fact, running "dmake >one.txt" says one.txt is up-to-date, so perhaps it doesn't mind that >one.txt has no dependents after all...) > >What do I need to do to fix the relative-path example above, and, >indeed, Perl's win32/makefile.mk? > >- 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.
