[CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine

[Alan W. Irwin]

On 2010-04-05 19:21-0600 Clinton Stimpson wrote:

> 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.
>
> If anyone needs a workaround until its fixed, just modify 
> kwsys/SystemTools.cxx's PortableGetLongPathName() to use 
> OldWindowsGetLongPath() instead of GetLongPathNameA() from kernel32.dll.

I managed to bootstrap my way out of this mess for MinGW/MSYS/Wine using
that workaround.

Here is how.

I implemented your workaround recommendation using the following trivial
patch to the CMake source code:

--- SystemTools.cxx_original	2010-04-05 22:03:48.000000000 -0700
+++ SystemTools.cxx	2010-04-05 22:05:38.000000000 -0700
@@ -3114,6 +3114,7 @@
                              kwsys_stl::string & longPath)
  {
    HMODULE lh = LoadLibrary("Kernel32.dll");
+  lh = NULL;
    if(lh)
      {
      FARPROC proc =  GetProcAddress(lh, "GetLongPathNameA");

I disabled Fortran in the downloaded Windows binary version of CMake by
moving
cmake-2.8.1-win32-x86/share/cmake-2.8/Modules/CMakeFortranInformation.cmake

I built and installed CMake from source (with the above patch) using the
downloaded Windows binary cmake app.  There were no obvious issues at
all (which is a strong CXX test of CMake under MinGW/MSYS/Wine.)

That built version of CMake-2.8.1 does not have to have Fortran disabled,
and therefore PLplot builds and tests using C, C++, Fortran 77, and Fortran
95 with no obvious CMake run-time issues (other than the diverted log file
output I have mentioned on the "noisy CMake" thread) or PLplot build or test
issues. That is a strong C, CXX, and Fortran test of CMake under
MinGW/MSYS/Wine.  I will be adding Python, Java, and Tcl to
my MinGW/MSYS/Wine tests of PLplot as time permits.

I have now had a bit of practical experience with the MinGW/MSYS/Wine/CMake
development environment in building both CMake and PLplot (and qhull). With
the above bootstrapped workaround for wine bug 22286, it appears to be fine.
I am still of the opinion that it is going to be a revolutionary combination
since it makes the extremely popular MinGW/MSYS development packages
conveniently available to _all_ developers now for free and with software
freedom regardless of the platform used by those developers.

Thanks, Clint, for all your practical help getting this development
environment working.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________