View Issue Details [ Jump to Notes ] [ Print ]
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.
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.
Attached Filestxt file icon Build.txt [^] (17,115 bytes) 2008-10-28 09:01 [Show Content]

 Relationships

  Notes
(0013957)
Bill Hoffman (manager)
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 (reporter)
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 (reporter)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2008-10-28 09:01 Kenneth Boyd New Issue
2008-10-28 09:01 Kenneth Boyd File Added: Build.txt
2008-10-28 09:48 Bill Hoffman Note Added: 0013957
2008-10-28 10:17 Kenneth Boyd Note Added: 0013958
2008-10-28 10:23 Kenneth Boyd Note Edited: 0013958
2008-10-28 13:19 Kenneth Boyd Note Added: 0013959
2008-10-28 20:09 Kenneth Boyd Note Added: 0013962
2008-10-28 20:32 Bill Hoffman Note Added: 0013963
2008-10-28 20:32 Bill Hoffman Status new => assigned
2008-10-28 20:32 Bill Hoffman Assigned To => Bill Hoffman
2008-10-28 21:25 Kenneth Boyd Note Added: 0013964
2009-03-28 09:01 Bill Hoffman Note Added: 0015829
2009-03-28 13:44 Kenneth Boyd Note Added: 0015830
2016-06-10 14:27 Kitware Robot Note Added: 0041459
2016-06-10 14:27 Kitware Robot Status assigned => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:30 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team