Michael G Schwern wrote: >On Fri, Feb 18, 2005 at 09:23:31AM +0000, Steve Hay wrote: > > >>So the question is: how can we change Perl's win32/makefile.mk so that >>it can work with both dmake 4.1 and dmake 4.3? >> >>If we can't sort this out then there is little point in me putting up >>the new version of dmake. >> >> > >I'd drag the dmake 4.3 guy into this discussion, see if those were intentional >bug fixes or just bugs. > I logged an "issue" on the OpenOffice website:
http://qa.openoffice.org/issues/show_bug.cgi?id=43077 (Not sure if you need a login account to access this link. I had to create one for myself to raise the issue; it's no problem to do, though.) In short, it seems to have been an "accidental fix", so the new behaviour will be staying. The dmake developer suggested the same thing that I see Vadim has also suggested here, namely, using the MAKEVERSION macro to do different things for different versions of dmake. The following makefile.mk works fine with both Sarathy's dmake build and the current dmake 4.3 that I've just built: .USESHELL : FOO = C:\foo .IF "$(MAKEVERSION)" == "4.10" BAR = $(FOO:s,\,\\,) .ELSE BAR = $(FOO) .ENDIF all : @echo BAR=$(BAR) @type $(mktmp $(BAR)) Is it worth fixing Perl's win32/makefile.mk along these lines? If I go ahead and put a new dmake.exe on CPAN the we must fix things to work with it, but I'm a little reluctant to break things for users of Sarathy's dmake. Or should we just demand that users upgrade their dmake's to the new version if they want to build whatever version of Perl gets the fixed 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.
