On Fri, Jan 15, 2016 at 8:26 AM, mozzis <mor...@maynidea.com> wrote: > > Clearly, "can not" is incorrect, since I did. "must be" seems also > incorrect. Changing Generator is not exactly the same idea of what you're doing 1) If you actually chaned from VS 2010 to VS2012 or more radically to MinGW Makefiles and redid the build, you would have only partially correct results. And actually even changing the bitness you already have products built (.obj files) which won't be retriggered to compile to some other flavor since the .obj will aready be newer than the source so you'd have to do a rebuild.
> It seems like the developers don't understand about 32-bit vs. 64-bit > builds, or don't intend for this tool to be used with software that is a > product. Determining that after painstakingly configuring all of the build > options, the user must throw it all away in order to build for the other > "bitness", seems wrong. Almost anyone that is intending to build software > that can be installed (without the end user having to build it from source > every time, that way lies madness) needs to produce a 32-bit and a 64-bit > package these days. > This is 2 different packages, 2 different targets, (4 if you distribute debug versions also). The packing stage will really expect separate targets. However, I solve this by making simple 'makeit.bat' scripts. copy and replace the generator and go. But it also sounds like you're trying to get Cmake to play with existing builds instead of treating cmake as the primary build system. I fought with this a bit and was discusted myself in the lack of conformance to default project $(outputdir)/$(targetname) stuff. Was expecting to use cmake to generate projects I could then maintain as visual studio projects myself. But I was already supporting a Make system for targeting linux/mingw/watcom/lcc.... having bit the bullet and converted exising visual studio projects o cmakelists and migraing to using cmake as a primary tool has made life a lot simpler. I like that I can now just add_subdirectory( ../../../bullet3 Bullet3 ) and then have those libraries available to just specify target_link_libraryes( physics_demo bullet ) or openal or .. Kind of wish the whole world would switch now that cmake is quite mature. (back in version 1.4 something it still seemed insufficient for some things) Yes, you often cannot just build a target and run it (wish it would build into a single solution relative output directory instead of project relative, which would make running in the debugger just so much easier ) BUt I've included INSTALL() rules and just always build the INstall target which only builds the things that have changed and copies only those things to the output, and setup Debugging properties on the install project to launch the thing I want to (I have a core library with a half dozen utilties, and a binaries library that outputs probably some 60 simple tools ) (CMAKE_INSTALL_PREFIX doesn't have to target /program files but rather can just target 'otuput' which is relative to the CMAKE_BINARY_DIR ) for testing/build processes... then Package target (with NSIS Support) is pretty easy to add and get target packages. But I target primarily MinGW, Linux, Android, VS 2015(now) OpenWatcom... each of these has their own additional libraries, and ways of generating code which are in most cases mutually exclusive, so even attempting to change generator in CMakeCache is not even a thought (yes, think I did try to do that at the beginning also) --- one makeit.bat generated by a cmakelists to build all targets --- "c:/tools/unix/cmake/bin/cmake.exe" -G "Visual Studio 14 2015" -T "v140" "M:/sack/cmake_all/.." -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=C:/General/Build/sack-vs14/release_out/core -DBUILD_MONOLITHIC=OFF -DBUILD_EXTRAS=ON -D__NO_ODBC__=0FF -DNEED_FREETYPE=ON -DNEED_JPEG=ON -DNEED_PNG=ON -DNEED_ZLIB=ON c:\tools\unix\cmake\bin\cmake.exe --build . --config "release" --target "INSTALL" -- /m:4 /v:m --- Using the cmake --build unifies having to call MSBuild or Make of MingW32Make or WMake as appropriate for the generator in question.... (although the arguments do change based on the genartor for specifying build-tool specific options like /m:4 or /j 4(make) ) >>CMake creates VS projects that should >>work to build the project that is the goal. I don't understand about >>make and MSVS, CMake can create makefiles or ninja files if that is what >>you are talking about. > > The VC project files produced by the CMAKE system for OpenCV use absolute > paths and use them throughout the project files, rather than defining things > at top-level and then using predetermined macros like $(TargetDir) and > $(TargetName), to say nothing of conveniences like $(PlatformTarget). I > don't really know if that is inherent in how CMAKE generates the project > files or if there is a way to produce more easily maintainable project > files, but every time I have to utilize a project that involves CMAKE I > cringe because of the ugly project files it produces. The makefiles produced > have been the same way, with the same absolute paths occurring over and over > in the file. I do not like this, as it makes the project files/makefiles > difficult to debug or maintain. Having expressed this dislike here, I feel > much better and will probably not think about this much in the future, up > until the point I have to update to a new version of a library such as > OpenCV or HDF5. Then I will cringe; pick through all of the settings and > generate the makefiles/project files again; debug the results for a day or > so until the builds actually, you know, work; and then do my little > edit-and-regenerate trick to build for the other architecture. Because the > design of CMAKE does not recognize that the results of "try-compile" tests > are orthogonal to settings like "build module A" or "build shared > libraries", so that the latter should not depend upon the former. > > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592499.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake