To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=43252
------- Additional comments from [EMAIL PROTECTED] Thu Mar 10 07:31:44 -0800 2005 ------- [Reply to an email, to keep the discussion recorded here.] [EMAIL PROTECTED] wrote: > >What I wrote there is possible, but I looked into methods getting the >absolute path for several OSs. MSVC and Linux are possible, but there >doesn't seem to be a general solution for this problem. I liked your suggestion of setting DMAKEROOT to the directoryname of GetModuleFileName on Win32. I agree that it was better than my suggestion of changing the meaning of MAKECMD. But why are you trying to trying to come up with a general solution to the absolute path problem? I thought it was only Win32 that would be needing it. Other targets using a "configure" approach already have a sensible default for DMAKEROOT. Or are there targets other than Win32 which also don't use "configure"? > >Do you really think it is necessary to introduce the feature that dmake >(only the MSVC version) earches for its startup file in the directory >where its executable lives? And break the cross-platform compatibility? I believe that dmake on Win32 should search for startup files in the startup/ sub-directory of where the executable lives, i.e. that DMAKEROOT should default to that directory. I don't see that this is breaking cross-platform compatibility, because we don't currently have cross-platform compatibility anyway -- all targets currently look for startup files in DMAKEROOT (and this would not be changed), but on targets built via "configure", DMAKEROOT defaults to a compile-time choice of directory, while on Win32 DMAKEROOT currently has no default. All I'm asking is that Win32 gets a sensible default for DMAKEROOT too. The startup/ sub-directory of where the executable is seems like a sensible choice since there is no $prefix directory specified at compile-time. It is also what Perl users of the old 4.10pl1 version are used to ;) > >On could also set the internal DMAKEROOT at compile time like it is done >for the configure based dmake builds. (But not for the MSVC build.) > >Is setting the MAKESTARTUP or DMAKEROOT environment not enough to make >the users happy? ;) No, it isn't. On Unix it's OK because dmake looks for startup files in a sensible place, specified at compile time. You only need to set DMAKEROOT if you want to change the default. But on Win32, dmake currently looks for "\startup.mk", which is absurd. Therefore, users *have* to set DMAKEROOT, which isn't very friendly when (a) the startup files are almost certainly in the startup/ sub-directory of where the executable is, and (b) dmake.exe is perfectly capable of looking there. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
