Apache OpenOffice (AOO) Bugzilla – Issue 43077
Backwards-compatibility issue with mktmp
Last modified: 2013-08-07 15:34:52 UTC
I have an existing makefile.mk for a project that I'm involved in which has long been working with dmake 4.1. I've just tried upgrading to dmake 4.3, and I now find that something doesn't work. I've reduced the problem to the following sample makefile.mk: .USESHELL : FOO = C:\foo BAR = $(FOO:s,\,\\,) all : @echo FOO=$(FOO) @echo BAR=$(BAR) @type $(mktmp $(FOO)) @type $(mktmp $(BAR)) Running this under dmake 4.1 produces this output: FOO=C:\foo BAR=C:\\foo C:♀ooC:\foo As you can see, outputting data containing backslashes to a mktmp file doesn't work unless the backslashes are doubled-up first. My real makefile.mk therefore employs exactly that strategy -- doubling-up the backslashes. However, running the above under dmake 4.3 (current CVS version) produces this: FOO=C:\foo BAR=C:\\foo C:\foo C:\\foo Now we see that outputting single backslashes works fine, so doubling them up actually results in double backslashes in the mktmp file. I have two questions about this change in behaviour: 1. Is it deliberate? It looks like a fix for a bug in dmake 4.1, but I couldn't see any mention of it in the NEWS file, so perhaps the change was not intended and is hence actually a bug in dmake 4.3? 2. If it is deliberate, then what should I do in my makefile.mk so that it can output data containing backslashes to a mktmp file in such a way that it works with both dmake 4.1 and dmake 4.3? Thanks, - Steve
I take over. @shay: I assume you are taking about a native W32 dmake.exe or is it a cygwin build dmake.exe? Or both?
Hmm, I tried your example file with the cygwin build dmake.exe for 4.1 and 4.3. (I don't have access to a MSVC build version right now) For cygwin ( and I assume all *nix like variants dmake behaves like your 4.3 results. Additionally there is no special treatment for \ as escaping character in dmake, if you ask $(mktmp ..) to write a \ it should do that. So the bug got fixed accidentally ;) in the meantime. If you want to rely on the bug that \\ gets converted to \ for mktemp you can use something like this: .IF "$(MAKEVERSION)" == "4.10" BAR = $(FOO:s,\,\\,) .ELSE BAR = $(FOO) .ENDIF Please note that 4.1 PL0 identifies itself as 4.10. I will write something in the NEWS file of the next dmake version about this the fixed mktmp behaviour.
It is just the native Win32 dmake.exe that I was referring to. I haven't tried a Cygwin version myself, and the particular makefile.mk that I originally found the problem with is only used on native Win32 anyway. The 4.1 version that I was using is actually a binary build created by a Perl developer which is avilable from here: ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/G/GS/GSAR/dmake-4.1pl1-win32.zip This is slightly modified compared to a standard 4.1. The patch that was applied to it (mostly to fix build errors) is available from the same location (and is in the ZIP file itself too). I don't believe that the changes made are responsible for changing the mktmp behaviour, but it would be great if you could verify that. (I don't know where to get the original 4.1 sources from to try it myself.) Anyway, the MAKEVERSION trick works fine, so I think I can live with it. The new behaviour certainly seems more sensible than the old. Thanks, - Steve
Steve, I close this issue as invalid because even the old dmake versions, build with a MS C compiler don't show the problem you described. I tried the dmake from the cws "OpenOffice_1_1" build with .NET C++ 2003 (it identifies itself as: "Version 4.10, PL 0" and it still shows the correct behavior with: C:\foo C:\\foo Nevertheless, I can reproduce your problem with the dmake.exe from ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/G/GS/GSAR/dmake-4.1pl1-win32.zip the CPAN download, but that version is build with Borland C++. So the problem occurs only with an ancient version and only for a binary found on the web, therefore IMHO invalid.
OK, I'm quite happy that this is not seen as an "issue" with the current dmake, but I have one more question regarding this. Given that the problem I have experienced with the CPAN build of dmake-4.1 is apparently due to it having been built with Borland C++ rather than MS VC++, how do I now create a makefile.mk that will work with them both? The previous suggestion was to use the MAKEVERSION macro to distinguish between 4.1 and 4.3, but 4.1 works just like 4.3 when built with MS VC++, so that technique is no good any more. - Steve
I did not try to compile the sourcecode from that CPAN archive, it might be that that version would show the problem also with other compilers. The real problem is that since dmake was imported into the cvs (long before OOo ever existed) quite a lot of bugs were fixed, but noone bothered to update the version, or document what was fixed. I somehow adopted dmake and bumped the version to 4.3, all prior versions identify themself as 4.1 (4.10 PL0) :(. The NEWS file you see in the 4.3 version was done by cvs archeologie, there might be other fixes that are not mentioned. To your problem. Just test if the bug is there or not (or tell them to update to 4.3). Something like this (untested): .IF "$(shell +type $(mktmp \\))"=="\\" BAR=$(FOO) .ELSE BAR=$(FOO:s,\,\\,) .ENDIF
c