2009/11/7 Sisyphus <sisyphus1@[...].au> :
>  Hi,
> 
>  In the win32/makefile.mk, pertaining to the building of perl with 64-bit
>  Microsoft compilers (in particular "Microsoft Platform SDK for Windows
>  Server 2003 R2"), we have:
> 
>  .IF "$(WIN64)" == "define"
>  LIBBASEFILES    = $(LIBBASEFILES) bufferoverflowU.lib
>  .ENDIF
> 
>  With nmake there's no problem with that but, to dmake, that middle line is
>  an error because of the circularity regarding LIBBASEFILES. (Sorry, I've
>  lost the exact error message, though I can easily re-create it if that's
>  important.)
> 
>  Is there a simple way of rewriting that middle line that both keeps dmake
>  happy && has the desired effect ?

Yes, use +=, as is used elsewhere already.

I'd commit it now, but by ssh doesn't seem to be working...


>  Two other things come to mind:
> 
>  1) Why do we try to retain support for MS compilers in the makefile.mk ?
>  Since those compilers ship with nmake, wouldn't it make sense to decree that
>  the makefile.mk is for dmake only ? ... and decree that the MS compilers use
>  nmake and the win32/Makefile exclusively ? (Maybe not ... I've heard a
>  rumour that perl supports TIMTOWTDI :-)

No particular reason that I'm aware of, unless it's that some of the
free MS compilers perhaps didn't come with an nmake? Not sure, but it
doesn't normally cause much maintenance overhead.


> 
>  2) Should the win32 makefile(s) be rewritten to cater for the possibility
>  that the MS compiler being used to build perl does *not* necessarily require
>  a link to bufferoverflowU.lib ? (For some 64-bit MS compilers attempting to
>  link to bufferoverflowU.lib is a fatal error, as that library does not exist
>  for them.)

Sounds like they should, yes.