Gurusamy Sarathy wrote: >On Mon, 21 Feb 2005 09:30:41 GMT, Steve Hay wrote: > > >>Gurusamy Sarathy wrote: >> >> >>>Isn't this a "bug" in whatever diddles Config.pm, config.h, et al? >>>It seems like the paths should get normalized by the tools regardless >>>of what the user/makefiles happened to pass in. >>> >>> >>I couldn't disagree with that, but its no good having, say, configpm >>apply File::Spec->canonpath() to all the Config.pm option values because >> >> >[...] > >FWIW, I didn't mean to suggest applying it to every value, >just the ones that are supposed to have file paths in them. > >If it is practical to make makefile.mk do the right thing, >that would be great. > I believe it is possible.
The dmake guy has concluded that the dmake in your CPAN dir probably behaves the way that it does simply because it was built with Borland C++. He tried building an old 4.1 with VC++ and found that it worked OK (i.e. the same as my 4.3 build). I don't think the changes that you made had any effect, so it must just be down to the compiler. That means that testing $(MAKEVERSION) to decide how to proceed won't work, but he suggested the following neat trick which looks at what the dmake in hand actually does and acts accordingly: .IF "$(shell +type $(mktmp \\))"=="\\" BAR=$(FOO) .ELSE BAR=$(FOO:s,\,\\,) .ENDIF I'm just testing this out now with the old and the new dmake's. If it works out OK then I'll commit the attached patch. - 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.
==== //depot/perl/win32/makefile.mk#285 - C:\p5p\bleadperl\win32\makefile.mk ==== @@ -259,11 +259,11 @@ BUILDOPT += -DPERL_DEBUGGING_MSTATS .ENDIF -.IF "$(USE_IMP_SYS)$(USE_MULTI)" == "defineundef" +.IF "$(USE_IMP_SYS) $(USE_MULTI)" == "define undef" USE_MULTI != define .ENDIF -.IF "$(USE_ITHREADS)$(USE_MULTI)" == "defineundef" +.IF "$(USE_ITHREADS) $(USE_MULTI)" == "define undef" USE_MULTI != define .ENDIF @@ -537,6 +537,17 @@ #################### do not edit below this line ####################### ############# NO USER-SERVICEABLE PARTS BEYOND THIS POINT ############## +# Some dmake's built with Borland C++, including Sarathy's one at: +# http://search.cpan.org/CPAN/authors/id/G/GS/GSAR/dmake-4.1pl1-win32.zip +# require backslashes to be doubled-up when written to $(mktmp) files. +# Other dmake's do not require this and would actually output a double +# backslash if they were doubled-up. +.IF "$(shell type $(mktmp \\))"=="\\" +B=\\ +.ELSE +B=\\\ +.ENDIF + o *= .obj a *= .lib @@ -836,8 +847,8 @@ # -- BKS 10-17-1999 CFG_VARS = \ INST_DRV=$(INST_DRV) ~ \ - INST_TOP=$(INST_TOP:s/\/\\/) ~ \ - INST_VER=$(INST_VER:s/\/\\/) ~ \ + INST_TOP=$(INST_TOP:s,\,$B,) ~ \ + INST_VER=$(INST_VER:s,\,$B,) ~ \ INST_ARCH=$(INST_ARCH) ~ \ archname=$(ARCHNAME) ~ \ cc=$(CC) ~ \ @@ -847,9 +858,9 @@ d_crypt=$(D_CRYPT) ~ \ d_mymalloc=$(PERL_MALLOC) ~ \ libs=$(LIBFILES:f) ~ \ - incpath=$(CCINCDIR:s/\/\\/) ~ \ + incpath=$(CCINCDIR:s,\,$B,) ~ \ libperl=$(PERLIMPLIB:f) ~ \ - libpth=$(CCLIBDIR:s/\/\\/);$(EXTRALIBDIRS:s/\/\\/) ~ \ + libpth=$(CCLIBDIR:s,\,$B,);$(EXTRALIBDIRS:s,\,$B,) ~ \ libc=$(LIBC) ~ \ make=dmake ~ \ _o=$(o) ~ \ @@ -862,7 +873,7 @@ usemultiplicity=$(USE_MULTI) ~ \ useperlio=$(USE_PERLIO) ~ \ uselargefiles=$(USE_LARGE_FILES) ~ \ - LINK_FLAGS=$(LINK_FLAGS:s/\/\\/) ~ \ + LINK_FLAGS=$(LINK_FLAGS:s,\,$B,) ~ \ optimize=$(OPTIMIZE) #
