The library mylib consists of the library proper, in directory lib/, and a test suite, in directory test/. It is completely under CMake control:
mylib/CMakeLists.txt:
...
add_subdirectory(lib)
add_subdirectory(test)
...
mylib/lib/CMakeLists.txt:
...
add_library(my_lib ${src_files})
...
mylib/test/CMakeLists.txt:
...
add_executable(mytest mytest.c)
target_link_libraries(mytest mylib)
Build steps are:
mkdir build
cd build
cmake ..
make
ctest # or make test
make install
Works under Linux, stable since many years. Under Windows10 though, a message window pops up, entitled "mytest.exe - System error": "The code execution cannot proceed because mylib.dll was not found. Reinstalling the program may fix this problem."
No, installing (rather than reinstalling) would not be a good solution: I need to first test the library before I install it (btw: this excludes most solutions proposed in response to somewhat similar questions).
Isn't CMake supposed to work cross-platform? What is the minimally invasive adjustment to make the above build steps work under Windows?
The right way of doing this on Windows is to populate the PATH environment variable for the test run:
set_tests_properties(your_test_name
PROPERTIES
ENVIRONMENT PATH="path-containing-your-dll")
I believe you can use generator expression if path-containing-your-dll is a function of an artifact that you generate in your build.
Cherry on top: since cmake 3.13, the variable VS_DEBUGGER_ENVIRONMENT can also be set on the target for having a nice debugging behaviour inside Visual Studio (eg. being able to debug the application directly from Visual instead of going through ctest).
I have a python build script I'm using to build a number of projects that are configured via CMake on windows. Previously, we used MSVC to build these projects, and everything was fine. I want to try to incorporate ICC into the build now, via these python scripts. I can choose the native compiler directly in the UI if necessary, but I'd rather do everything programmatically.
Problem is, it's failing with either syntax errors, or just not paying attention to the cmake options.
I can set:
"CMAKE_CXX_COMPILER:PATH":"C:/Program Files (x86)/Intel/Composer XE 2013/bin/intel64/icl.exe",
"CMAKE_C_COMPILER:PATH":"C:/Program Files (x86)/Intel/Composer XE 2013/bin/intel64/icl.exe"
And that's part of a cmakeItems array that's then fed into the generation:
generate(x86Generator, cmakeItems, osName, buildTarget)
where the other options are set via command line switches (for x86generator and buildTarget) or by default (ie, osName is detected in the script itself).
Before trying anything, I'm running this from a command line prompt where I've run
iclvars intel64
in the icc bin directory to ensure that all of the icc variables are properly configured, and I can type icl on the command line and confirm that it's in the path.
Running the above means that the C compiler remains the default msvc compiler.
I've also tried running:
set(CMAKE_C_COMPILER_INIT icl)
set(CMAKE_CXX_COMPILER_INIT icl)
but that's giving me a syntax error on the icl portion. I thought that maybe it's a path issue, but doing:
set(CMAKE_C_COMPILER_INIT "C:\Program Files (x86)\Intel\Composer XE 2013\bin\intel64\icl")
set(CMAKE_CXX_COMPILER_INIT "C:\Program Files (x86)\Intel\Composer XE 2013\bin\intel64\icl")
is also giving me a syntax error.
So how can I programmatically set the C/CXX compiler from a python script calling cmake?
On the command line you specify the compiler via the environment variables CC and CXX. I'ld guess you need to properly prepare the envornment of the cmake command and you should not change CMakeLists.txt internals.
E.g.
import subprocess
subprocess.Popen('CC=%s CXX=%s cmake ../path/to/src' %('icc','icpc'))
The answer is:
ICC does not work with CMake on Windows, so don't bother.
http://www.cmake.org/Bug/view.php?id=6929
Much better to run it with some form of visual studio compiler and then mess about with icprojconverter:
http://software.intel.com/en-us/articles/ICProjConvert100
Upon finishing a COBOL program, how do I compile it into an executable file that may be run on other PCs? I'm using OpenCOBOL via cygwin.
Check out this getting started page from the user manual for OpenCOBOL:
But in case the link is broken, just do this:
$ cobc -x hello.cob
$ ./hello
cobc is the compiler. hello.cob is the source file. The output is simply the file hello which can be run by calling ./hello. The -x option is necessary to build an executable.
However, with all compiled programs, it is compiled for the machine is was built on. It will work on machine with similar architectures, but you don't true cross-platform ability unless you're using an interpreted language like Python or Java.
If you compile with Cygwin, the target computers also need Cygwin, or in particular the cygwin dynamic libraries along with the OpenCOBOL runtimes.
Many times, you can also compile under MinGW, which lessens the dependencies, but also lessens the available POSIX features.
Easiest path, install OpenCOBOL and Cygwin on the target machines, and you'll be good to go, otherwise you'll need to produce release packages with all the dependencies and instructions for PATH settings.
I have reached the end of my rope with CMake; it has so much potential, but I cannot seem to make it find the basic system tools (i.e. make) in order to function.
SYMPTOMS
CMake and the CMake GUI produce the following (after deleting the CMakeCache.txt file):
Processing top-level CMakelists.txt for project swb
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".
CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
I am focusing on finding make in this question, however, I've also had many of the same issues with CMake failing to find libraries and other utility files (linker, nm, ar, etc.). The techniques I list below seem to enable CMake to find these files when running under Linux.
SYSTEM
Windows 7 (64-bit); multiple versions of MinGW (32-bit/64-bit); Cmake 2.8.4;
NONSTANDARD install location for MinGW (c:/MinGW-32 ).
THINGS I HAVE TRIED
CMakelists.txt contains SET( CMAKE_MAKE_PROGRAM c:/MinGW-32/bin/make.exe FORCE ) within the first 10 lines of the file.
Previous versions of CMakelists.txt contained:
find_program(CMAKE_MAKE_PROGRAM
NAMES make
make.exe
DOC "Find a suitable make program for building under Windows/MinGW"
HINTS c:/MinGW-32/bin )
Set CMAKE_MAKE_PROGRAM in a cmd.exe environment variable prior to running either CMake or CMake-GUI.
Use of a "toolchain" file which identifies CMAKE_MAKE_PROGRAM as well as CMAKE_C_COMPILER, etc.
ONE THING THAT HAS WORKED
CMake will successfully create build files IF I use the GUI to populate the CMAKE_MAKE_PROGRAM variable ("C:/MinGW-32/bin/make.exe").
QUESTION(S)
I can get CMake to work if I identify the name of the make program via the GUI. How does one enable CMake to find my make program without user intervention with the Windows 7 (64-bit) / MinGW combination?
I have two suggestions:
Do you have make in your %PATH% environment variable? On my system, I need to add %MINGW_DIR%\bin to %PATH%.
Do you have make installed? Depending on your mingw installation, it can be a separate package.
Last resort: Can you pass the full path to make on the commandline? cmake -D"CMAKE_MAKE_PROGRAM:PATH=C:/MinGW-32/bin/make.exe" ..\Source
In the GUI, select the "Advanced" checkbox. It should now show several entries below. Rename your mingw32-make.exe file to make.exe (you can just make a copy) and set the CMAKE_MAKE_PROGRAM filepath variable to the location of said file.
On ubuntu, i think I was missing the compiler. Fixed with:
sudo apt install build-essential
I’ve just solved the same problem. I had MinGW with GCC and G++ installed but not make. This command helped me:
mingw-get.exe install mingw32-make
After running it, clear CMake cache (delete the CMakeCache.txt file in the CMake's working directory) and run CMake again.
Previous answers suggested (re)installing or configuring CMake, they all did not help.
Previously MinGW's compilation of Make used the filename mingw32-make.exe and now it is make.exe. Most suggested ways to configure CMake to use the other file dont work.
Just copy make.exe and rename the copy mingw32-make.exe.
I have tried to install the missing packages. Installing the toolchain and restarting CLion solved all in my case:
pacman -S mingw-w64-x86_64-cmake mingw-w64-x86_64-extra-cmake-modules
pacman -S mingw-w64-x86_64-make
pacman -S mingw-w64-x86_64-gdb
pacman -S mingw-w64-x86_64-toolchain
Recently i had the same problem (Compiling OpenCV with CMake and Qt/MinGW on WIN764)
And I think I solve this including on my environment variable PATH (through Control Panel\All Control Panel Items\System\Advanced Sytem Settings) with the %MINGW_DIR%\bin and %CMAKE_DIR%/bin
Furthermore, I installed cmake2.8 on an easy directory (without blanks on it)
I had the exact same problem when I tried to compile OpenCV with Qt Creator (MinGW) to build the .a static library files.
For those that installed Qt 5.2.1 for Windows 32-bit (MinGW 4.8, OpenGL, 634 MB), this problem can be fixed if you add the following to the system's environment variable Path:
C:\Qt\Qt5.2.0\Tools\mingw48_32\bin
I had the same problem.
Installed mingw using the installer provided at http://tdm-gcc.tdragon.net/ . It adds the correct environment variables to path when installing mingw (No need to edit the path variable manually).
That did the trick for me.
Well, if it is useful, I have had several problems with cmake, including this one. They all disappeared when I fix the global variable (in my case the MinGW Codeblocks) PATH in the system. When the codeblocks install is not in default, and for some unknow reason, this global variable does not point to the right place. Check if the path of Codeblocks or MinGW are correct:
Right click on "My Computer"> Properties> Advanced Properties or Advanced> Environment Variables> to Change the PATH variable
It worked for me;)
I had the same problem and specified CMAKE_MAKE_PROGRAM in a toolchain file, cmake didn't find it. Then I tried adding -D CMAKE_MAKE_PROGRAM=... in the command-line, then it worked. Then I tried changing the generator from "MinGW Makefiles" to "Unix Makefiles" and removed the -D CMAKE_MAKE_PROGRAM from the command-line, and then it worked also!
So for some reason when the generator is set to "MinGW Makefiles" then the CMAKE_MAKE_PROGRAM setting in the toolchain file is not effective, but for the "Unix Makefiles" generator it is.
It seems everybody has different solution. I solved my problem like:
When I install 64bit mingw it installed itself to : "C:\Program Files\mingw-w64\x86_64-5.1.0-posix-seh-rt_v4-rev0\mingw64\bin"
Eventhough mingw-make.exe was under the path above, one invalid charecter or long path name confused CMake. I try to add path to environment path, try to give CMAKE as paramater it didn't work for me .
Finally I moved complex path of mingw-w64 to "C:/mingw64", than set the environment path, restarted CMake. Problem solved for me .
I had the same problem which is solved using the following:
Try to rename all the folders to not to be more than 8 characters and without spaces.
It also happens when I just want to compile opencv2.3.2 with mingw32 (in tdm-gcc suites). Often when I install the tdm-gcc, I would like to rename the mingw32-make.exe to make.exe. And I thinks this could be the question. If cmake is asked to generated a MinGW Makefiles, It would try to find ming32-make.exe instead of make.exe. So I copy the make.exe to mingw32-make.exe and reconfigure in Cmake-gui. Finally it works! So I'd like to advise to find whether
you have mingw32-make.exe or not to solve this question.
I tried to use CMake to build GammaRay for Qt on Windows with mingw. So, I had the Qt installed. And I had the same problem as other users here.
The approach that worked for me is launching cmake-gui from Qt build prompt (a shortcut created by Qt installer in "Start Menu\All programs\Qt{QT_VERSION}" folder).
I had to add the follow lines to my windows path to fix this. CMAKE should set the correct paths on install otherwise as long as you check the box. This is likely to be a different solution depending on the myriad of versions that are possible to install.
C:\msys64\mingw32\bin
C:\msys64\mingw64\bin
I am doing C development using Netbeans on OS X and my project fails to build, stating "...this installation of Open MPI was not compiled with Fortran 90 support"
I have installed a newer gcc and Open MPI (along side the default versions), and I can build using them via make on a command line. This leads me to believe that Netbeans is using the default Open MPI installation (which did not have fortran support). If I am correct, how do I get it to use the new installation? I told Netbeans about the other compilers via the Tool Collection Manager (File->Project Properties->Build->Tool Collection->[...]). However, I do not know of a way to tell it about Open MPI.
I have a working solution. This solution exists in two parts.
1) I reran configure on the command line for my project and specified full paths for MPICC and MPIFC. This solved the problem of getting Netbeans to use the right mpicc compiler. However, it created another issue: the mpif90 wrapper could not find gfortran.
2) I altered the 'GUI environment' PATH variable to put gfortran in my path using the /etc/launchd.conf method found here (http://stackoverflow.com/questions/135688/setting-environment-variables-in-os-x).
After a reboot, Netbeans compiles my project. So, I'm claiming success.