Provide way to pass env-vars from bat-file to cmake process (for nmake)

[kutschkem]

This is a...

• Bug Report
• Enhancement Request

Brief Description

For my nmake to work, I had to make sure to call vcvars32.bat before cmake. However I found no way to do this other than writing a wrapper batch script around cmake.

(If Bug Report) Brief Summary

What I tried:

1. Prepending the call to the build command in Preferences -> C/C++ Build -> Builder settings. This did not work as the command is not used for the cmake call.
2. Using it as pre-build step in Preferences -> C/C++ Build -> Settings -> Build steps. This did not lead to the batch file being called before cmake.
3. Prepend the call to Preferences -> C/C++ Build -> CMake -> OS Host override -> Windows -> CMake Executable. Didn't work because the entry is parsed as one command instead of allowing arbitrary shell script statements.

In the end I wrote a batch script that called vcvars32 and then passed the arguments to cmake, and used that as cmake executable.

What is the expected behavior?

One of the methods above should have allowed to call the script before cmake is executed to populate environment variables - or another method should exist that allows this.

What behavior are you observing?

cmake seems to be the first thing to be called in the build and no way exists to define a "pre-cmake" step.

Provide the steps to reproduce the issue, if applicable:

(If Enhancement Request) Describe it.

Add a "pre-cmake" step.

Useful Information

cmake4eclipse verssion: 1.10.3
Which OS do you use: Windows 7
Cmake version: 3.10.0

[15knots]

Calling vcvars32.bat from Eclipse won't help, a sub-process cannot set environment variables for its parent process (Eclipse in this case).
You will have to stay with your existing cmake-wrapper or write a similar wrapper which start Eclipse.

[15knots]

One possible solution could be to call cmake in a sub-shell, and run vcvars32.bat in the same shell before.
But that might fail when cmake is called from the makefile once a CMakeLists.txt was changed.

[kutschkem]

Shouldn't 3. work if the commands were not passed to the shell in one string but split?

[15knots]

Splitting the string at whitespaces? Then nobody will be able to add a path to cmake with white spaces, e.g c:\program files\cmake\...

[kutschkem]

Using a tokenizer should work, but that would mean "just" putting in a path with whitespaces wouldn't work anymore, they would have to be surrounded by quotation marks. (java.io.StreamTokenizer should work, I think)

[15knots]

The path-to-cmake should just hold what its label suggests, adding some token parsing would just confuse useres.

But I could think of an extra option 'run with environment script' which could allow to run a single batch file in the same shell prior to cmake.

[15knots]

What is your experience with your wrapper script that calls vcvars32 prior to cmake?
Does it work when cmake is called from the makefile? You will need to edit a CMakeLists.txt and run a build to provoke that.

If that does not cause any issues, I could implement the solution proposed in #91 (comment).
.

[kutschkem]

I understand the question to be:

1. generate NMake Makefile with the wrapper script
2. build using nmake, not by calling cmake --build with the script
3. check that 2. is succesful

I will test that as soon as possible and let you know the results. My hope would be that all necessary information from the vcvars finds its way in the Makefile, but that needs to be tested for sure.

[15knots]

No, even simpler: With your wrapper script in place,

• run the build once to let the wrapper script generate the makefiles (but you did that already)
• edit one of your cmakelists.txt and run the build again.

The second build should trigger some makefile rules that invoke cmake from nmake in order to re-generate the makefiles (at least, this is the case with unix makefiles). The cmake process in this case is run without your wrapper script and does not have the environment vars that come from vcvars32. If cmake runs without errors here, we're fine.

[kutschkem]

OK that is simpler, I will try that.

[kutschkem]

No it does not work. I tested this by explicitly setting an environment variable in the wrapper script and reading it in the CMakeLists.txt. The first run picks up the variable, the second one does not.

[15knots]

Of course it will not work if you explicitly require a new env-var. But that is a different use case.
Does it work if you, for example, add an add_exxecutable()?

[kutschkem]

Next test, I did:

1. build with wrapper script in place
2. change CMakeLists.txt to trigger cmake to run
3. build again - works as expected
4. change cmake executable to use the system one - builds as in 3.
5. remove CMakeCache.txt to trigger cmake to run again - build is unsuccessful

The issue, I think, is that what is not working is the compiler test - it tries to link against libs from the Windows SDK when trying to compile its "simple program", and only afterwards sets the necessary variables to do what the build takes. I think my environment variable test shows that the build can't be depending on the environment variables, somewhere cmake is setting the include paths.

Another test I did was setting the INCLUDE and LIB environment variables to the necessary directories for the Windows SDK - the build without the wrapper script worked fine. So somewhere CMake is keeping the IncludeDirectories and Libpath directories, the rest of the environment doesn't seem to matter. I do not know where it is that this information is kept.

[kutschkem]

By the way, when I change the cmake command, it does not force a cmake rerun, I think that is probably a bug.

[kutschkem]

I think I fixed my problem, but it is debatable how nice it is. I call the script and read out the environment variables it sets.

For INCLUDE:

execute_process(COMMAND $ENV{VS140COMNTOOLS}/VsDevCmd.bat && set include OUTPUT_VARIABLE WINDOWSSDK_INCLUDE_DIRS)
string(REPLACE "\\" "/" WINDOWSSDK_INCLUDE_DIRS "${WINDOWSSDK_INCLUDE_DIRS}")
string(REPLACE "INCLUDE=" "" WINDOWSSDK_INCLUDE_DIRS "${WINDOWSSDK_INCLUDE_DIRS}")
message(STATUS "Found the following VS140 include directories: ${WINDOWSSDK_INCLUDE_DIRS}")

And then the same for LIB. I put this all in a find_package script and then use it like any other library. Not really nice, but better than a wrapper script in my opinion.