View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012936CMakeCMakepublic2012-02-06 00:402016-06-10 14:31
Reportersarnath 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformIntel 64-bitOSMicrosft Windows7 64-bitOS VersionWindows 7
Product VersionCMake 2.8.7 
Target VersionFixed in Version 
Summary0012936: ExternalProject_Add - CMAKE_GENERATOR is not passing "-G" option properly
DescriptionI have 2 CMAKE projects. I want one of them to compile as 64 bit application and other as 32-bit application. The 32-bit app is typically a tool that will be used in generating some sources required for the 64-bit compilation. Thats the scenario we have.
So, in the 64-bit app, i just "ExternalProject_Add" the 32-bit CMAKE project and use an appropriate generator, say "Visual Studio 9 2008", in the CMAKE_GENERATOR argument. I compile the 64-bit app from native x64 visual studio command prompt with "NMake Makefiles" generator - which builds in 64-bit mode.
The CMAKE configuration goes fine. When I do "nmake", I get into errors from devenv command -- resulting from cmake --build of the 32-bit project. devenv reports "Invalid solution configuration".
The reason is that the parent CMAKE passes "-GVisual Studio 9 2008" option to the child CMAKE instead of -G "Visual Studio 9 2008". This results in the child cmake using a bad configuration (instead of debug/release).
Steps To ReproduceUnzip the attached file. IT will create a directory called "cmake_gen_bug".
cd into it.
cd bin
cmake -DCMAKE_VERBOSE_MAKEFILE=on -G "NMake Makefiles" ..
nmake

Additional InformationThis "nmake" would fail with an error message "Invalid solution configuration". It fails regardless of "CMAKE_VERBOSE_MAKEFILE" is ON or OFF. But VERBOSE makefile option will enable us to see what is wrong.
Just browse above the "invalid solution configuration" message to the place where parent "cmake" actually calls the child CMAKE. You can see that it calls the child CMAKE with "-GVisual Studio 9 2008" instead of -G "Visual Studio 9 2008".
TagsNo tags attached.
Attached Fileszip file icon cmake_gen_bug.zip [^] (1,215 bytes) 2012-02-06 00:40
patch file icon 0001-ExternalProject-fix-using-different-generator-for-su.patch [^] (1,361 bytes) 2012-02-06 02:12 [Show Content]

 Relationships

  Notes
(0028485)
sarnath (reporter)
2012-02-06 00:49

The workaround I currently use is to have a "configure.bat" which uses CMAKE internally to configure and then use "cmake --build" as the build command.

So, essentially we are telling CMAKE to build another CMAKE project through CUSTOM commands.... This way, I can workaround the CMAKE bug.. (hopefully thats a bug)
(0028486)
Rolf Eike Beer (developer)
2012-02-06 02:13

Please try the attached patch.
(0028487)
sarnath (reporter)
2012-02-06 02:24

Vow! That was quick!

The patch does fix the "-G" problem.... But I still get "Invalid solution configuration" problem.
The command line that causes this is: "cmake --build . --config ."

I think --config should take either "debug" or "Release" as argument...
I am no cmake expert...In my workaround, I just use "cmake --build ." as the build command. I really dont know what '--config' does.

Thanks for your quick reply! Appreciate your time on this!
(0028520)
David Cole (manager)
2012-02-06 12:03

Eike, thanks for your attempted fix here.

But: both syntaxes work and are acceptable:

  "-GVisual Studio 9 2008"
    and
  "-G" "Visual Studio 9 2008"

The problem is the build step after configuring for a VS generator. If the generators are different between parent project and ExternalProject, then we can't use the logic we use to figure out what configuration to build for VS projects. We use "." for "config" of makefile generators, and are incorrectly generating an NMake style build command for a VS generated project...

The quickest and easiest workaround for you here is to explicitly tell the Visual Studio ExternalProject what to build by using:

  BUILD_COMMAND ${CMAKE_COMMAND} --build . --config Release

(or Debug, if that's the config you are trying to build...)

Or you could do something like:

  set(cfg "Release)
  if(CMAKE_BUILD_TYPE)
    set(cfg "${CMAKE_BUILD_TYPE}")
  endif()
  ...
  BUILD_COMMAND ${CMAKE_COMMAND} --build . --config ${cfg}
(0028521)
sarnath (reporter)
2012-02-07 01:31

Hello David,

Thanks for the workaround. The repro case compiles and builds fine!
I hope this will be fixed in a future version of CMAKE.
Thanks,

Best Regards,
Sarnath
(0030358)
David Cole (manager)
2012-08-11 21:09

Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0041978)
Kitware Robot (administrator)
2016-06-10 14:28

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
2012-02-06 00:40 sarnath New Issue
2012-02-06 00:40 sarnath File Added: cmake_gen_bug.zip
2012-02-06 00:49 sarnath Note Added: 0028485
2012-02-06 02:12 Rolf Eike Beer File Added: 0001-ExternalProject-fix-using-different-generator-for-su.patch
2012-02-06 02:13 Rolf Eike Beer Note Added: 0028486
2012-02-06 02:24 sarnath Note Added: 0028487
2012-02-06 12:03 David Cole Note Added: 0028520
2012-02-07 01:31 sarnath Note Added: 0028521
2012-08-11 21:09 David Cole Status new => backlog
2012-08-11 21:09 David Cole Note Added: 0030358
2016-06-10 14:28 Kitware Robot Note Added: 0041978
2016-06-10 14:28 Kitware Robot Status backlog => resolved
2016-06-10 14:28 Kitware Robot Resolution open => moved
2016-06-10 14:28 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team