<div class="gmail_quote">On Tue, Apr 6, 2010 at 2:38 AM, Alan W. Irwin <span dir="ltr"><<a href="mailto:irwin@beluga.phys.uvic.ca">irwin@beluga.phys.uvic.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 2010-04-05 19:21-0600 Clinton Stimpson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I've submitted a bug report to the wine bugzilla with a very simple test case (bug #22286). So the bug can be taken care of or discussed over there.<br>
<br>
If anyone needs a workaround until its fixed, just modify kwsys/SystemTools.cxx's PortableGetLongPathName() to use OldWindowsGetLongPath() instead of GetLongPathNameA() from kernel32.dll.<br>
</blockquote>
<br></div>
I managed to bootstrap my way out of this mess for MinGW/MSYS/Wine using<br>
that workaround.<br>
<br>
Here is how.<br>
<br>
I implemented your workaround recommendation using the following trivial<br>
patch to the CMake source code:<br>
<br>
--- SystemTools.cxx_original 2010-04-05 22:03:48.000000000 -0700<br>
+++ SystemTools.cxx 2010-04-05 22:05:38.000000000 -0700<br>
@@ -3114,6 +3114,7 @@<br>
kwsys_stl::string & longPath)<br>
{<br>
HMODULE lh = LoadLibrary("Kernel32.dll");<br>
+ lh = NULL;<br>
if(lh)<br>
{<br>
FARPROC proc = GetProcAddress(lh, "GetLongPathNameA");<br>
<br>
I disabled Fortran in the downloaded Windows binary version of CMake by<br>
moving<br>
cmake-2.8.1-win32-x86/share/cmake-2.8/Modules/CMakeFortranInformation.cmake<br>
<br>
I built and installed CMake from source (with the above patch) using the<br>
downloaded Windows binary cmake app. There were no obvious issues at<br>
all (which is a strong CXX test of CMake under MinGW/MSYS/Wine.)<br>
<br>
That built version of CMake-2.8.1 does not have to have Fortran disabled,<br>
and therefore PLplot builds and tests using C, C++, Fortran 77, and Fortran<br>
95 with no obvious CMake run-time issues (other than the diverted log file<br>
output I have mentioned on the "noisy CMake" thread) or PLplot build or test<br>
issues. That is a strong C, CXX, and Fortran test of CMake under<br>
MinGW/MSYS/Wine. I will be adding Python, Java, and Tcl to<br>
my MinGW/MSYS/Wine tests of PLplot as time permits.<br>
<br>
I have now had a bit of practical experience with the MinGW/MSYS/Wine/CMake<br>
development environment in building both CMake and PLplot (and qhull). With<br>
the above bootstrapped workaround for wine bug 22286, it appears to be fine.<br>
I am still of the opinion that it is going to be a revolutionary combination<br>
since it makes the extremely popular MinGW/MSYS development packages<br>
conveniently available to _all_ developers now for free and with software<br>
freedom regardless of the platform used by those developers.<br>
<br>
Thanks, Clint, for all your practical help getting this development<br>
environment working.<div class="im"><br>
<br>
Alan<br>
__________________________<br>
Alan W. Irwin<br>
<br>
Astronomical research affiliation with Department of Physics and Astronomy,<br>
University of Victoria (<a href="http://astrowww.phys.uvic.ca" target="_blank">astrowww.phys.uvic.ca</a>).<br>
<br>
Programming affiliations with the FreeEOS equation-of-state implementation<br>
for stellar interiors (<a href="http://freeeos.sf.net" target="_blank">freeeos.sf.net</a>); PLplot scientific plotting software<br>
package (<a href="http://plplot.org" target="_blank">plplot.org</a>); the libLASi project (<a href="http://unifont.org/lasi" target="_blank">unifont.org/lasi</a>); the Loads of<br>
Linux Links project (<a href="http://loll.sf.net" target="_blank">loll.sf.net</a>); and the Linux Brochure Project<br>
(<a href="http://lbproject.sf.net" target="_blank">lbproject.sf.net</a>).<br>
__________________________<br>
<br>
Linux-powered Science<br>
__________________________<br>
_______________________________________________<br></div><div><div></div><div class="h5">
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br><br>A "real" fix for this has been committed to the CVS repository for kwsys. The change should appear in the CMake git repository shortly on 'master'...<br><br>Thanks to Clinton Stimpson for the patch.<br>
<br><br>cvs commit -m "Patch to avoid short name usage where possible. Get the actual case spelling of a file name on 'Windows' without converting to short name and back again. Avoids bad behavior reported in <a href="http://bugs.winehq.org/show_bug.cgi?id=22286">http://bugs.winehq.org/show_bug.cgi?id=22286</a> when using cmake under a wine/msys/mingw installation on a Linux box. Thanks to Clinton Stimpson for preparing the patch."<br>
<br>/cvsroot/KWSys/KWSys/SystemTools.cxx,v <-- SystemTools.cxx<br>new revision: 1.257; previous revision: 1.256<br><br>