Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Backwards-compatibility issue with mktmp | ||
---|---|---|---|
Product: | Build Tools | Reporter: | shay <stevehay> |
Component: | dmake | Assignee: | quetschke |
Status: | CLOSED NOT_AN_OOO_ISSUE | QA Contact: | issues@tools <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | hans-joachim.lankenau, issues |
Version: | current | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
shay
2005-02-18 13:44:39 UTC
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 |