Feature request: Add Microsoft Visual Studio generators

[kevemueller]

cmake4eclipse enforces the use of the -G switch to specify generators, but does not list all supported generators. On the Windows platform cmake supports the different flavours of Microsoft Visual Studio. Please add them to the dropdown list that selects the generator.

[15knots]

If you already use Visual Studio, why do you need Eclipse to generate build scripts for Visual Studio? AFAIK VS has built-in cmake support.

See issue #53.

[15knots]

cmake4eclipse enforces the use of the -G switch to specify generators, but does not list all supported generators

That`s by intent. Cmake4eclipse is there to automatically generate and run build-scripts, but not to just tell cmake to generate IDE project files. Reasons to not let cmake generate IDE project files include:

1. Bad user experience; when the project builds: Eclipse currently cannot build for example VS solution files. Or Kdevelop projects. Or Codeblocks, CodeLite, Kate, Sublime Text 2.
2. Confusing to Eclipse users: Why does the plugin show an option to generate an Eclipse CDT project, if the project is already there?
3. Impossible to maintain for me (linux box) to be up to date with with the IDE project generators cmake provides on the platforms it supports.
4. Put Eclipse users on the wrong track. At least the project generators Eclipse CDT4 - * are badly outdated. They produce projects for CDT 4 Makefiles, where the current version of CDT (9.3) does not even offer a wizard to create those kind of projects. And a lot of users on the CDT 4 Makefiles-tracks come here and raise (irrelevant) issues.

[kevemueller]

I agree that the CDT or other IDE generators should NOT be included. Eclipse can build a CMAKE generated VS solution file. In fact the workflow is very similar to the standard "make" workflow.

cmake -G "Visual Studio 15 2017" will generate the *.sln Solution file -- consider this your Makefile. CDT using the external builder cmake --build . --target will build that Solution file -- this is your invocation of Make.

I cam currently building projects inside CDT using this approach. I need to point cmake buildfile generation invocation to a batch file that replaces the generator string sent by cmake4eclipse - this is ugly.

I do not see how adding an option to a dropdown increases your maintenance.

If you do not want to endorse using this path, please consider making the dropdown editable, so people can at their own risk fiddle with the cmake invocation.

[15knots]

Eclipse can build a CMAKE generated VS solution file. In fact the workflow is very similar to the standard "make" workflow.

Sorry, I wasn`t aware that VS solution files also serve as build-scripts. Please provide some more information to implement this:

1. What is the name of the tool that runs the build-script?
2. What is the commandline option that makes the tool ignore errors? (E.g. make uses -k.)
3. What is the name of the generated solution file?
4. Does the tool need extra commandline arguments, for example to disable printing of product banners?

As I am on a Linux box, you will have to test a preview if the implementation is finished.

[kevemueller]

Thanks for following up on this. ad 1/ the build script is run by cmake itself. the command line is cmake --build . --config [Release|Debug] --target [targetname] -- [tooloptions] see https://cmake.org/cmake/help/v3.10/manual/cmake.1.html#build-tool-mode cmake will invoke the underlying build tool for you. The target switch is not needed. If left blank the ALL_BUILD target is built. If specified as all the build will fail, there is no all target in the project. The target all is added by the CDT template project, it should be removed/empty. This works for all generators, i.e. it is safe to invoke make|ninja|... like this as well, I would make this the default string for the external build command. Note that the configuration must be passed into the build regardless of the configuration used when initializing the build. If not specified Debug will be built, even if Release was specified when initializing the build. Note that --config can be passed to make and ninja as well, these tools ignore it. For the Visual Studio generators cmake invokes MsBuild to handle the build process.

ad 2/ I have not found a switch that triggers make -k behavior, but the default behavior of MsBuild is to keep going and build subsequent stages if they do not depend on the failed stage. To disable make -k behavior you need to provide /property:StopOnFirstFailure=true to the process, e.g. cmake --build . --config Release -- /property:StopOnFirstFailure Adding a superfluous -k switch will fail the execution.

ad 3/ The master makefile, i.e. the solution file is ${PROJECT_NAME}.sln as known by cmake. You do not need to know this name as cmake --build knows it.

ad 4/ There are no command line arguments needed to perform a build. /NOLOGO is added by default already.

Additional notes: Please add the last 2 or 3 versions of Visual Studio, I don't think it makes sense to support older versions. Please add both empty as well as architecture appended versions, i.e. I would expect the dropdown to list

• Visual Studio 15 2017
• Visual Studio 15 2017 Win64
• Visual Studio 15 2017 ARM
• Visual Studio 14 2015
• Visual Studio 14 2015 Win64
• Visual Studio 14 2015 ARM

[15knots]

ad 1/ the build script is run by cmake itself. the command line is cmake --build . --config [Release|Debug] --target [targetname] -- [tooloptions] see https://cmake.org/cmake/help/v3.10/manual/cmake.1.html#build-tool-mode cmake will invoke the underlying build tool for you.

Calling cmake --build will not work, the actual build is started by CDT, which does not allow to add any additional options. The plugin`s Portable Build Runner extracts the value of CMAKE_MAKE_PROGRAM from CMakeLists.txt feeds it to CDT. Also, it does not support to call cmake --build, because it stays compatible with some linux distros that provide only older versions of cmake. These versions do not know the --build option (e.g. RHEL7 still sticks to cmake 2.8.x`)

ad 2/ I have not found a switch that triggers make -k behavior, but the default behavior of MsBuild is to keep going and build subsequent stages if they do not depend on the failed stage.

If MsBuild users are custom with that behavior, I think it would be OK to have keep going as the default for msbuild. But if a Eclipse user will select the keep going option in the CDT UI, msbuild would fail, -k is injected by CDT and I can't stop it.

ad 3/ The master makefile, i.e. the solution file is ${PROJECT_NAME}.sln as known by cmake. You do not need to know this name as cmake --build knows it.

The name of the file has to be known, since a missing file will cause cmake4eclipse to trigger cmake to generate the build scripts, which gives poor performance. Additionally, CDT's API requires to return the name of the main build script. I don't know for what purposes CDT needs the name, but just giving it an arbitrary name would require testing on windos -> will be Your Task.

Did you try the NMAKE generator? AFAIK, it's a MS product delivered with MS studio and it claims to build there projects.

[kevemueller]

I am back on this one, sorry for the delay. With the recent update of yours (grabbing CMAKE_MAKE_PROGRAM from the cache) my workflow stopped working. Please consider that CMAKE_MAKE_PROGRAM is not added by all CMake generators (https://cmake.org/cmake/help/latest/variable/CMAKE_MAKE_PROGRAM.html) -- again it is the Visual Studio Generator which prefers not to add this to the cache. You also seem to depend on extracting CMAKE_MAKE_PROGRAM (and break with hard error) when the user switches off "Use default build command". Please do not try to extract CMAKE_MAKE_PROGRAM if the user prefers to manually provide a build command.

As detailed earlier I consider it way cleaner to rely on cmake --build for the invocation of the build process. This spares you from digging into the cache for CMAKE_MAKE_PROGRAM and a lot of other things. cmake --build is made exactly for that. For old distros shipping old cmake, the user can with ease provide a manual override and just type there "make or ninja".

I understand that you must provide a full command string to CDT. My proposal for this is cmake --build . --config <<CMakeConfig>> --target. With CMakeConfig a property to be set on the CMake/General sheet. CDT will then append the target and the build just flies.

Please note that config is also supported by XCode, so this is no longer a "stupid Windows" but a "non Linux" issue and may be passed to any build tool and ignored.

As of the name of the buildfile, as detailed above the buildfile is called ${PROJECT_NAME}.sln. So you will need to know ${PROJECT_NAME} as known to CMAKE.

I hope this further clarifies this issue and sufficiently outlines that this is a notable feature. Please also consider adding the generators (at least the two without architecture suffix) from above, I will find a way to pass the architecture in a subsequent step.

[15knots]

You also seem to depend on extracting CMAKE_MAKE_PROGRAM (and break with hard error) when the user switches off "Use default build command". Please do not try to extract CMAKE_MAKE_PROGRAM if the user prefers to manually provide a build command.

Yes, that makes sense to me.

As detailed earlier I consider it way cleaner to rely on cmake --build for the invocation of the build process.

I'm aware of that, but cmake --build does not work with cmake 2.8.x. Unfortunately, cmake 2.8.12 is the most recent version that comes packaged for CentOS/RHEL 6/7 and I need cmake4eclipse for exactly that distros.

Please note that config is also supported by XCode, so this is no longer a "stupid Windows" but a "non Linux" issue and may be passed to any build tool and ignored.

Support for OSX can be added when a user asks for it and is willing to test it.

As of the name of the buildfile, as detailed above the buildfile is called ${PROJECT_NAME}.sln. So you will need to know ${PROJECT_NAME} as known to CMAKE.

This might be a chicken-egg problem, if CDT wants the name of the makefile before CMakeCache.txt has been created. But maybe I'm wrong here.

[15knots]

Am Sonntag, 6. Mai 2018, 12:19:23 CEST schrieb Keve Müller:

I am back on this one, sorry for the delay. With the recent update of yours (grabbing CMAKE_MAKE_PROGRAM from the cache) my workflow stopped working.

The plugin always extracted the CMAKE_MAKE_PROGRAM from the cache since its first release in 2013. What change exactly are you referring to?

my workflow stopped working. Please consider that CMAKE_MAKE_PROGRAM is not added by all CMake generators (https://cmake.org/cmake/help/latest/variable/CMAKE_MAKE_PROGRAM.html) --

Yes, I'm aware of that. But the plugin currently needs the CMAKE_MAKE_PROGRAM entry (see below).

again it is the Visual Studio Generator which prefers not to add this to the cache. You also seem to depend on extracting CMAKE_MAKE_PROGRAM (and break with hard error) when the user switches off "Use default build command". Please do not try to extract CMAKE_MAKE_PROGRAM if the user

Any generator that is supported by the plugin sets the CMAKE_MAKE_PROGRAM cache entry. As a result, it is perfectly ok to rely on the cache entry being present. If someone wraps cmake with a script that changes the arguments
actually passed to cmake, it's at her own risk.

prefers to manually provide a build command.

As detailed earlier I consider it way cleaner to rely on cmake --build for the invocation of the build process. This spares you from digging into the cache for CMAKE_MAKE_PROGRAM and a lot of other things. cmake --build is made exactly for that. For old distros shipping old cmake, the user can with ease provide a manual override and just type there "make or ninja".

I am one of those people that use a distro with just cmake 2.8.x. I made the plugin to make my life easier. What you suggest, is to make my life harder.

I understand that you must provide a full command string to CDT. My proposal for this is cmake --build . --config <<CMakeConfig>> --target. With CMakeConfig a property to be set on the CMake/General sheet. CDT will then append the target and the build just flies.

Please note that config is also supported by XCode, so this is no longer a "stupid Windows" but a "non Linux" issue and may be passed to any build tool and ignored.

No, it's an issue with cmake generators that do set CMAKE_MAKE_PROGRAM vs those that not set it. Mingw generator on windows, for example, is no problem.

[kutschkem]

The Visual Studio generator adds MAKECOMMAND to the CMakeCache, maybe that works?

[15knots]

Does VS Generator add this on the initial run of cmake? According to https://cmake.org/cmake/help/latest/variable/CMAKE_MAKE_PROGRAM.html, it does not.

[kutschkem]

I tested with this CMakeLists.txt

project(test C CXX)

and the variable was indeed not set in the cache. Is that an appropriate test?

[15knots]

Am Freitag, 12. Oktober 2018, 16:55:32 CEST schrieb Michael Kutschke:

I tested with this CMakeLists.txt

project(test C CXX)

and the variable was indeed not set in the cache. Is that an appropriate test?

YES. The cache is read by the plugin to get the make tool to invoke.

-- Cd wrttn wtht vwls s mch trsr.