On 2010-06-10 16:20-0400 David Cole wrote:

On Thu, Jun 10, 2010 at 4:17 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
wrote:
      On 2010-04-09 12:17-0400 David Cole wrote:

            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'...

            Thanks to Clinton Stimpson for the patch.


            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
            http://bugs.winehq.org/show_bug.cgi?id=22286 when
            using cmake under a
            wine/msys/mingw installation on a Linux box. Thanks
            to Clinton Stimpson for
            preparing the patch."

            /cvsroot/KWSys/KWSys/SystemTools.cxx,v  <-- 
            SystemTools.cxx
            new revision: 1.257; previous revision: 1.256


Hi David:

Sorry for the long delay in responding to you.  I am just now
restarting
testing of MinGW (4.5.0) and CMake-2.8.1 under Wine (1.1.42).

I did find the patch at the "patch" link accessible from
http://cmake.org/gitweb?p=cmake.git;a=commit;h=018c13ff73d9b7b151cb77f7adcb
bb7be27f49d3

I notice the following result after applying the patch

softw...@raven> find -print0 -type f |xargs -0 grep -l shortPath
./Source/kwsys/SystemTools.cxx

Further investigation indicates bool SystemTools::GetShortPath is
defined
that appears to be unused anywhere else in the source tree now that
the
patch has been applied.  Therefore, shouldn't that method be removed?


kwsys code is shared among many, many projects. It appears in way more than
just CMake. So removing a function from any of its interfaces is really
probably not a very good idea. :-)

I didn't realize external projects used parts of CMake source code, but
your point is well taken in that case.

That leads to the obvious next question of why aren't those externally used
parts of CMake source code built as a library rather than (presumably)
repeating the compilation for every external project that needs to use the
source code for CMake?  I guess it wouldn't matter much for just a few such
external projects, but you say there are many.

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
__________________________
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to