MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007870CMakeCMakepublic2008-10-28 09:012016-06-10 14:30
ReporterKenneth Boyd 
Assigned ToBill Hoffman 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0007870: What files do I need to adjust to make CMake 2.6.2 bootstrap on MingW32?
DescriptionBoth the bootstrapped, and cmake.org-provided binaries for Windows, catastrophically fail to create CMakefiles on my system.
* GNU make 3.81
* GCC: MingW32 4.2.1, installed by tarballs to c:\MingW32 (gcc is at c:\MingW32\bin\gcc.exe, etc.). Non-development utilities are installed by tarballs to c:\ (so bash is at c:\bin\bash.exe, etc.)

The bootstrap fails with:
====
 process_begin: CreateProcess(NULL,
 /C/MingWin.aux/cmake-2.6.2/Bootstrap.cmk/cmake.exe -E cmake_progress_report
 /C/MingWin.aux/cmake-2.6.2/CMakeFiles/CMakeTmp/CMakeFiles 1, ...) failed.

 make (e=3): The system cannot find the path specified.
====
The prebuilt binary simply refuses to create the CMakefile outright. Experimentation shows that acceptable paths would be in an MSYS CMakefile, but the presence of \bin\sh blocks selection of the MSYS project type.

Attaching Build.txt (complete log of running the bootstrap script, and some other things) just in case something obvious is there.

Again, I'd like to know which files would be expected to need patching to make bootstrap work.
Steps To Reproduce
Additional InformationThe problem exists for all of 2.6.0, 2.6.1, 2.6.2. I just have managed to rearrange things recently so that I will have time to work on patching this. (If I get some help on where to look, as it's clear it will take at least a week to decipher where the problem is on my own.)

The Windows binary is incorrectly selecting a Cygwin project. Trying to override to MSYS doesn't work, according to CMake (in both command-line and GUI modes), because I have the MingW32 prebuilt sh on my path. As might be expected, CygWin paths are useless under MingW32.

Description and attachment copied from the initial post to the CMake mailing list on Oct. 26 2008.
TagsNo tags attached.
Relationships
Attached Filestxt Build.txt (17,115) 2008-10-28 09:01
https://public.kitware.com/Bug/file/1808/Build.txt
Issue History
Date ModifiedUsernameFieldChange
2008-10-28 09:01Kenneth BoydNew Issue
2008-10-28 09:01Kenneth BoydFile Added: Build.txt
2008-10-28 09:48Bill HoffmanNote Added: 0013957
2008-10-28 10:17Kenneth BoydNote Added: 0013958
2008-10-28 10:23Kenneth BoydNote Edited: 0013958
2008-10-28 13:19Kenneth BoydNote Added: 0013959
2008-10-28 20:09Kenneth BoydNote Added: 0013962
2008-10-28 20:32Bill HoffmanNote Added: 0013963
2008-10-28 20:32Bill HoffmanStatusnew => assigned
2008-10-28 20:32Bill HoffmanAssigned To => Bill Hoffman
2008-10-28 21:25Kenneth BoydNote Added: 0013964
2009-03-28 09:01Bill HoffmanNote Added: 0015829
2009-03-28 13:44Kenneth BoydNote Added: 0015830
2016-06-10 14:27Kitware RobotNote Added: 0041459
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0013957)
Bill Hoffman   
2008-10-28 09:48   
Just use a CMake binary from www.cmake.org to create the build files for CMake. The bootstrap script only works on Unix and OSX.
(0013958)
Kenneth Boyd   
2008-10-28 10:17   
(edited on: 2008-10-28 10:23)
As stated in the original post:
The windows binary fails for exactly the same reason when trying to build CMake: it refuses to allow a manual override of the project type to MSYS, because I have [edit: MingW32's] sh (bash) on my path.

My most reasonable option for using CMake, is to bootstrap.

The bootstrap process itself is working perfectly, as the local build of CMake behaves identically to the prebuilt Windows binary. I just want to know which source/configuration files are likely to be breaking both CMake binaries (local and prebuilt).
(0013959)
Kenneth Boyd   
2008-10-28 13:19   
If I'm fortunate, the problem should be entirely externally configured.

It looks like the MingW project type is intentionally broken on the assumption that MingW sh can't handle windows file paths (which is not true for 3.1): http://www.cmake.org/Wiki/CMake_MinGW_Compiler_Issues [^] .

As MingW sh 3.1 can't handle CygWin paths, MSYS dies. So it looks like I need a new project type MingW-with-sh .
(0013962)
Kenneth Boyd   
2008-10-28 20:09   
I haven't traced down the platform detection problems. After stripping down CMakeMinGWFindMake.cmake to

FIND_PROGRAM(CMAKE_MAKE_PROGRAM make.exe )
FIND_PROGRAM(CMAKE_SH sh.exe )

CMake was able to build CMake with project type override to the modified MinGW .

Obviously, this can't be folded into upstream.
(0013963)
Bill Hoffman   
2008-10-28 20:32   
OK, I am still a bit lost as to what your actual goal is? If you manage to build cmake with bootstrap under mingw, then you should have a CMake that is pretty much exactly the same as the regular windows binary of CMake. So, it won't do anything different for you.

What are you trying to build?

What if you just build "Unix Makefiles" with the regular windows binary?
(0013964)
Kenneth Boyd   
2008-10-28 21:25   
One of the open-source projects I'm tracking is evaluating whether to switch from autoconf to CMake. At minimum, I want to verify that this transition won't lock me out of the project. Using CMake to build CMake is an a priori reasonable check of this. (Done: critically breaking the MinGW environment sanity checks "works").

At this point, fixing bootstrap appears to be a matter of creating an additional project type and having autodetection correctly select it. This should also fix autodetection on my system for pre-built Windows CMake. Whether this could be folded back into CMake, depends on whether we can avoid breaking any of the currently supported platforms' autodetection.

Now that I know which directory is the correct "source directory", "Unix Makefiles" does create a makefile by default (unlike MSYS and default MinGW). make still fails for both in-source and out-of-source builds. E.g.:

C:\MingWin.aux\cmake-2.6.2\Source>make
make[2]: *** [Source/kwsys/CMakeFiles/cmsysProcessFwd9x.dir/depend] Error 1
make[1]: *** [Source/kwsys/CMakeFiles/cmsysProcessFwd9x.dir/all] Error 2
make: *** [all] Error 2
(0015829)
Bill Hoffman   
2009-03-28 09:01   
OK, so the problem is that you have make.exe instead of mingw32-make.exe. I still don't see why you need CMake built by the mingw compiler?? We have dashboards that build mingw and msys code every night..

http://www.cdash.org/CDash/viewNotes.php?buildid=300845 [^]
http://www.cdash.org/CDash/viewNotes.php?buildid=300421 [^]


CMake is bootstrapped with the windows binary CMake.
(0015830)
Kenneth Boyd   
2009-03-28 13:44   
make.exe instead of mingw32-make.exe: actually, I build GNU make from source as make.exe. The from-source make tends to not break outside autoconf'ed and command-line projects as much as the pre-built MingW32 make, so I don't use the prebuilt MingW32 make at all.

CMake is the first project in about a decade, where this interacted badly with the stock distribution.

At this point:
* I normally would use the provided binary CMake when I intend to use CMake, as the problem is entirely in the configuration files. I just have to patch the configuration files so that project type forcing works. I really do appreciate the effort the CMake dev team puts into proper regression testing, etc.
* Asking CMake to build CMake on my system, is a good way to check that the default configuration works on my system. I'd do the same for *any* build system at the first sign of breakage.
* I really don't have a good visual on how the autodetection should work to discriminate my system from the more traditional things. I haven't checked whether there's a summary flowchart of the project type detections already "out there" (say, the wiki); I think I'd need something like that before proposing intelligent changes.

It certainly would have reduced my frustration level (to the point of not wanting to file a bug report) if there had been a "Trust Me" project type. Just entering what already works and having CMake use that, would have been very nice.
(0041459)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.