develooper Front page | perl.perl5.porters | Postings from November 2007

RE: Building perl on Win32 with dmake-4.11

Thread Previous
From:
Steve Hay
Date:
November 27, 2007 05:09
Subject:
RE: Building perl on Win32 with dmake-4.11
Message ID:
1B32FF956ABF414C9BCE5E487A1497E7E258B5@ukmail02.planit.group
Steve Hay wrote:
> Steve Hay wrote:
>> Rafael Garcia-Suarez wrote:
>>> On 27/11/2007, Steve Hay <SteveHay@planit.com> wrote:
>>>> Yesterday I released a build of the latest version of dmake (4.11)
>>>> to CPAN, and it seems that it generates numerous warnings when
>>>> building perl which previous versions didn't:
>>>> 
>>>> dmake:  Warning: -- Target [config.h] was made but the time stamp
>>>> has not been updated. dmake:  Warning: -- Target [..\perly.c] was
>>>> made but the time stamp has not been updated. dmake:  Warning: --
>>>> Found file corresponding to virtual target [defsubs.h]. dmake:
>>>> Warning: -- Found file corresponding to virtual target [PPPort.pm].
>>>> dmake:  Warning: -- Found file corresponding to virtual target
>>>> [ppport.h]. dmake:  Warning: -- Found file corresponding to virtual
>>>> target [RealPPPort.xs].
>>> 
>>> Sounds noisy -- IIRC those are all generated files, not part of the
>>> common make process. 
>>> 
>>>> dmake:  Warning: -- Found file corresponding to virtual target
>>>> [Errno.pm].
>>> 
>>>> plus warnings like these for each extension that gets built:
>>>> 
>>>> dmake:  Warning: -- Found file corresponding to virtual target
>>>> [..\..\lib\.exists]. dmake:  Warning: -- Found file corresponding
>>>> to virtual target [..\..\lib\auto\Win32CORE\.exists].
>>>> dmake:  Warning: -- Found file corresponding to virtual target
>>>> [blib\bin\.exists]. dmake:  Warning: -- Found file corresponding to
>>>> virtual target [blib\script\.exists]. dmake:  Warning: -- Found
>>>> file corresponding to virtual target [blib\man1\.exists]. dmake:
>>>> Warning: -- Found file corresponding to virtual target
>>>> [blib\man3\.exists]. 
>>>> 
>>>> Are these warnings things that we should be worrying about, or is
>>>> dmake going over the top with all these warnings and should perhaps
>>>> relegate them to verbose mode only?
>>> 
>>> I don't understand what those warnings mean.
>> 
>> Me neither. Here's what the dmake manual says on virtual targets:
>> 
>>   Dmake  allows  to  define  targets  with  the sole purpose to
>>   enforce a dependency chain that are unable to create the  target, 
>>   hence virtual targets.   When  dmake  tries to make a target, but
>>   only finds a target definition without recipe lines, it would
>>   normally issues a "Don't know how to make ..." error message, but
>>   if a target rule is terminated by a semicolon and has no following
>>   recipe lines, or if  it  has  no recipe lines,  but  defines 
>>   prerequisites,  or if the AUGMAKE mode is enabled (see the
>>   COMPATIBILITY section for details), the target is treated as a
>>   virtual target and the error is suppressed. In addition to this,
>>   if the default target does not have recipe lines it is also
>> treated as a vir- tual target. 
>> 
>>   Virtual  targets  should  not  have a corresponding file therefore
>>   they inherit the time of their newest prerequisite if  they  have
>>   prerequi- sites,  otherwise  they  get the current time assigned
>>   when being made. If the virtual target has a corresponding file a
>>   warning is issued, but the  time  stamp of that file is taken into
>>   account. The virtual target uses the time stamp of the
>>   corresponding file if it is newer  than the one determined by the
>> previous rule. 
>> 
>> Do these '.exists' file exist when building on other OSes?
>> 
>> I must admit that I'm somewhat confused as to why dmake thinks, e.g.,
>> ..\..\lib\.exists is a virtual target. The only references to this in
>> the Makefile are as follows (where INST_LIBDIR=..\..\lib and
>> DFSEP=\): 
>> 
>> blibdirs : $(INST_LIBDIR)$(DFSEP).exists
>> $(INST_ARCHLIB)$(DFSEP).exists $(INST_AUTODIR)$(DFSEP).exists
>> $(INST_ARCHAUTODIR)$(DFSEP).exists $(INST_BIN)$(DFSEP).exists
>> $(INST_SCRIPT)$(DFSEP).exists $(INST_MAN1DIR)$(DFSEP).exists
>> $(INST_MAN3DIR)$(DFSEP).exists
>> 
>> $(INST_LIBDIR)$(DFSEP).exists :: Makefile.PL
>> 	$(NOECHO) $(MKPATH) $(INST_LIBDIR)
>> 	$(NOECHO) $(CHMOD) 755 $(INST_LIBDIR)
>> 	$(NOECHO) $(TOUCH) $(INST_LIBDIR)$(DFSEP).exists
>> 
>> The target rule "$(INST_LIBDIR)$(DFSEP).exists" is not terminated by
>> a semicolon, it does have following recipe lines, and (as far as I
>> can tell) AUGMAKE mode is not enabled so is dmake mistaken to treat
>> it as a virtual target in the first place?
>> 
>> I may have to go back to the dmake maintainers on this one...
> 
> Well, it's easily reproducible. This makefile:
> 
> all : exists
> 	@echo Done
> 
> exists ::
> 	@echo here>exists
> 
> emits a warning, while this one doesn't:
> 
> all : exists
> 	@echo Done
> 
> exists :
> 	@echo here>exists
> 
> (they both still create the file 'exists').
> 
> Does that look like a bug in dmake? My understanding of what '::' is
> supposed to do certainly doesn't explain this behaviour. 

I think it must have been a bug that has since been fixed in the current
CVS branch, because rebuilding from scratch with 4.12-cvs I now only get
two warnings from dmake:

dmake:  Warning: -- Target [config.h] was made but the time stamp has
not been updated.
dmake:  Warning: -- Target [..\perly.c] was made but the time stamp has
not been updated.

The first is presumably because config.h is "created" by getting copied
from one of the canned config files (e.g. win32/config_H.vc). Perhaps
config.h should be "touched" after the copy?

Not sure what's going on with perly.c. I thought that was part of the
distro, neither generated nor copied.

(For anyone interested, the dmake issue fixing the bogus warnings is
probably http://www.openoffice.org/issues/show_bug.cgi?id=64572)

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About