[CMake] Changing the the current generator in CMake GUI

Fri Jan 15 19:19:17 EST 2016

Well, CMAKE is the thing that is conflating this idea of a "generator" (which is clearly a concept in CMAKE's own domain of "build configuration generator") with the idea of "platform" or "architecture" (which is a concept in the domain of certain kinds of build tools, such as a C compiler.) It would be healthier if platform/arch were broken out as a separate item in CMAKE, i.e. CMAKE recognizes that some build tools have this concept, but is (possibly) agnostic about how it is represented. I assume that it is not really possible to do so in the config files that drive CMAKE at present, only because I have never seen it done and did not find it when I went looking. Instead, that information is scattered across several files in the CMakeFiles folder.

Thank you for the hints and examples about using batch files. I may try to implement that scheme for building support libraries that come dependent on CMake. But I don't believe that I will ever use CMake for any product I am in control of, mainly because I have seen what an unmaintainable mess it creates for project files. And at least partly as a result, since there is no direct comprehension on the part of the developer/maintainer as to the project file structure, it becomes impossible to adequately manage that structure, so making large-scale improvements is nearly impossible without starting over from scratch. In addition, the build process becomes way inefficient. For example, once when I was really at loose ends due to a management blow-up, I reworked the build system for HDF5 on Visual Studio so it had "normal" project files that could be used to build for various platforms and configurations. The resulting build time was cut by a factor of 5, plus it became much easier (for me anyways) to be able to do things like change the output file names based on platform, something I have so far found impossible to do with CMake. [Once again, it really has no concept of this.]
I would do the same thing for OpenCV, but it is ten times worse than HDF5 in this regard. For instance, apparently project files are modified <i>as part of the MSVS build process</i>, so that Visual Studio always complains about project files needing to be reloaded after a build. This is a recipe for mysterious bugs that you will never be able to fix.

I have created/maintained multi-platform projects, and I find that the effort needed to produce efficient, readable makefiles for each platform is worth it. Once done, I can change the platform or the library type or similar parameters by changing one switch in each platform's makefile. Plus there are fewer gotchas at runtime, as not querying the build environment for every build ensures more consistent behavior in the binaries I am going to distribute.

Thanks again to all for the comments on this thread. It is good to know that development continues on this tool. At some point, it may become more interesting for me.

From: J Decker [via CMake] [mailto:ml-node+s3232098n7592504h60 at n2.nabble.com]
Sent: Friday, January 15, 2016 1:10 PM
To: Morris Maynard <morris at maynidea.com>
Subject: Re: Changing the the current generator in CMake GUI

On Fri, Jan 15, 2016 at 8:26 AM, mozzis <[hidden email]</user/SendEmail.jtp?type=node&node=7592504&i=0>> 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<http://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<http://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

________________________________
If you reply to this email, your message will be added to the discussion below:
http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592504.html
To unsubscribe from Changing the the current generator in CMake GUI, click here<http://cmake.3232098.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7587876&code=bW9ycmlzQG1heW5pZGVhLmNvbXw3NTg3ODc2fC0yMTQ2NDMyNDU5>.
NAML<http://cmake.3232098.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

--
View this message in context: http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592509.html
Sent from the CMake mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160115/c7d31032/attachment-0001.html>