I was trying to install libcurl libraries on my remote desktop following the steps mentioned in this post : How do you properly install libcurl for use in visual studio 2017?
But when I was running this command line nmake /f Makefile.vc mode=static , I was getting this error :
make-3.80:*** No rule to make target '/NOLOGO'. Stop
This error was coming from this line in Makefile.vc :
#$(MAKE) /NOLOGO /F MakefileBuild.vc
After googling about the issue and going through the Visual studio documentation , I found that /NOLOGO is just an option , but somehow was being treated as a file (as can be seen from the above error).
So I tried to follow the same steps on my local machine , and I was able to install libcurl libraries.
Then I tried to see what $(MAKE) evaluates to on my local machine and on my remote desktop and I found the following:
On my local machine ,
$MAKE is "C:\ProgramFiles(x86)\MicrosoftVisualStudio\2017\Professional\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86\nmake.exe"
On my remote desktop , $MAKE is make-3.80
Can anyone suggest as to what could be the issue here ? (In both cases I am running the same command using nmake )
According to the documentation, environment variables have precedence over built-in ones:
If a macro has multiple definitions, NMAKE uses the highest-precedence definition. The following list shows the order of precedence, from highest to lowest:
A macro defined on the command line
A macro defined in a makefile or include file
An inherited environment-variable macro
A macro defined in the Tools.ini file
A predefined macro, such as CC and AS
When MAKE environment variable is defined, it will take over built-in value.
Actually the remote desktop had a MAKE environment variable set to make-3.80 , and this was actually causing make to be executed instead of nmake. Deleting the environment variable I was successfully able to build the libraries.
Related
I just switched to CodeLite for C++ development.
I followed the QuickStart guide and created a simple console executable (g++), and when setting up a new project, you can choose the Build System, which offers the options
Default
CMake
GNU makefile onestep build
NMakefile for MSVC toolset
If I choose "CMake", and leave everything else the way it is, I get my usual hello world code in main.cpp.
Now I want to build it. I execute CMake, which produces a makefile, and then execute "Build" (by pressing F7 or via the menu). That does not work:
C:\Windows\system32\cmd.exe /C cd "\\"C\Users\Username\Documents\CodeLite\WorkspaceName\cmake-build-Debug"\ProjectName" && C:/mingw/mingw64/bin/mingw32-make.exe -j4 SHELL=cmd.exe -e
"\\C\Users\Username\Documents\CodeLite\WorkspaceName\cmake-build-Debug\ProjectName"
CMD unterst_tzt keine UNC-Pfade als aktuelles Verzeichnis.
====0 errors, 0 warnings====
The last line says it does not support UNC paths. Not sure whether that's the problem, but anyway, nothing actually gets built.
However, if I simply open a command line in the cmake-build-Debug\ProjectName\ directory, I can execute "make" and my executable is built properly.
Now my question is: Why does CodeLite not build my project? This does not seem to work as intended. I did not change any settings and my project is a clean default, but yet, I have to build it manually.
If I simply choose "Default" instead of "CMake", it gets build, by the way.
A path in UNC (universal naming convention) has \\ before the host name and then the drive, directory, ... letters.
The path "\\C\Users\Username\Documents\CodeLite\WorkspaceName\cmake-build-Debug\ProjectName" does not look like a proper (UNC or other) path. Was it written this way by the CodeLite build system or did you need to do this manuully?
The form "C:\Users\Username\Documents\CodeLite\WorkspaceName\cmake-build-Debug\ProjectName" (or "C:\Windows\Users\ ...") should work on your system.
I recently installed vs15 - preview (Stripped down version of visual studio 2015).
I am able to compile C/C++ sources from inside the IDE, but I am not able to compile with the command line interface cl.exe. It can't find the c stdlib headers. I tried to use vcvars32.bat to set the proper reg values but seemingly it cant find the "Common Tools Folder".
"ERROR: Cannot determine the location of the VS Common Tools folder."
The script uses the env. variable "%VS150COMNTOOLS%".
If I try to run "cd %VS150COMNTOOLS%" from the cmd line, it can't find the path, so this seems to be the main problem.
How can manually set %VS150COMNTOOLS% to the right path? how can I set the cmd linker settings manually (Without telling the cl.exe every time I call it)?
Okay, I solved it by adding the path to the include directories and lib directories to the env. variables as "INCLUDE", "LIB". It works now, whyever the script was not able to set those values properly. I am not fluent in reading .bat let away writing in, I assume the directory structure, which is different for the vs15 preview when compared to the full version, had not been adapted yet.
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
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 have some demos that I downloaded and they come with a Makefile.win and a Makefile.sgi. How can I run these in Windows to compile the demos?
You can install GNU make with chocolatey, a well-maintained package manager, which will add make to the global path and runs on all CLIs (powershell, git bash, cmd, etc…) saving you a ton of time in both maintenance and initial setup to get make running.
Install the chocolatey package manager for Windows
compatible to Windows 7+ / Windows Server 2003+
Run choco install make
I am not affiliated with choco, but I highly recommend it, so far it has never let me down and I do have a talent for breaking software unintentionally.
If you have Visual Studio, run the Visual Studio Command prompt from the Start menu, change to the directory containing Makefile.win and type this:
nmake -f Makefile.win
You can also use the normal command prompt and run vsvars32.bat (c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools for VS2008). This will set up the environment to run nmake and find the compiler tools.
Check out GnuWin's make (for windows), which provides a native port for Windows (without requiring a full runtime environment like Cygwin)
If you have winget, you can install via the CLI like this:
winget install GnuWin32.Make
Also, be sure to add the install path to your system PATH:
C:\Program Files (x86)\GnuWin32\bin
Check out cygwin, a Unix alike environment for Windows
Here is my quick and temporary way to run a Makefile
download make from SourceForge: gnuwin32
install it
go to the install folder
C:\Program Files (x86)\GnuWin32\bin
copy the all files in the bin to the folder that contains Makefile
libiconv2.dll libintl3.dll make.exe
open the cmd (you can do it with right click with shift) in the folder that contains Makefile and run
make.exe
done.
Plus, you can add arguments after the command, such as
make.exe skel
If you install Cygwin. Make sure to select make in the installer. You can then run the following command provided you have a Makefile.
make -f Makefile
https://cygwin.com/install.html
I use MinGW tool set which provides mingw32-make build tool, if you have it in your PATH system variables, in Windows Command Prompt just go into the directory containing the files and type this command:
mingw32-make -f Makefile.win
and it's done.
I tried all of the above. What helps me:
Download the mingw-get.
Setup it.
Add something like this C:\MinGW\bin to environment variables.
Launch (!important) git bash. Power shell, developer vs cmd, system cmd etc didn't help.
Type mingw-get into the command line.
After type mingw-get install mingw32-make.
Done! Now You might be able to use make-commands from any folder that contains Makefile.
With Visual Studio 2017 I had to add this folder to my Windows 10 path env variable:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64
There's also HostX86
If it is a "NMake Makefile", that is to say the syntax and command is compatible with NMake, it will work natively on Windows. Usually Makefile.win (the .win suffix) indicates it's a makefile compatible with Windows NMake. So you could try nmake -f Makefile.win.
Often standard Linux Makefiles are provided and NMake looks promising. However, the following link takes a simple Linux Makefile and explains some fundamental issues that one may encounter. It also suggests a few alternatives to handling Linux Makefiles on Windows.
Makefiles in Windows
Firstly, add path of visual studio common tools (c:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools) into the system path. To learn how to add a path into system path, please check this website:
http://www.computerhope.com/issues/ch000549.htm. You just need to this once.
After that, whenever you need, open a command line and execute vsvars32.bat to add all required visual studio tools' paths into the system path.
Then, you can call nmake -f makefile.mak
PS: Path of visual studio common tools might be different in your system. Please change it accordingly.
I tried with cygwin & gnuwin, and didn't worked for me, I guess because the makefile used mainly specific linux code.
What it worked was use Ubuntu Bash for Windows 10. This is a Marvel if you come from MAC as it is my case:
To install the Ubuntu Bash: https://itsfoss.com/install-bash-on-windows/
Once in the console, to install make simply type "make" and it gives the instructions to download it.
Extras:
Useful enable copy / paste on bash: Copy Paste in Bash on Ubuntu on Windows
In my case the make called Maven, so I have to install it as well: https://askubuntu.com/questions/722993/unable-to-locate-package-maven
To access windows filesystem C: drive, for example: "cd /mnt/c/"
Hope it helps
Install msys2 with make dependency add both to PATH variable.
(The second option is GNU ToolChain for Windows. MinGW version has already mingw32-make included.)
Install Git Bash. Run mingw32-make from Git Bash.
If you have already installed the Windows GNU compiler (MinGW) from MSYS2 then make command comes pre-installed as wingw32-make. Always match cmake makefile generation with the correct make command. Mixing these generate problems.
MinGW makefile generation with MinGW make command
Visual Studio makefile generation with VS equivalent make command
And this is always possible as long as you have the source code. Just delete old build directory and start over by specifying this time the right parameter in cmake ,e.g.
mkdir build
cd build
cmake -G "MinGW MakeFiles" path/to/src/whereCMakeLists.txtInstructionsAre
mingw32-make
myProject.exe # RUN
I have encountered issues during compilation where multiple make commands interact. To prevent this just edit/remove the environmental variables that lead to different make commands. For example to prevent conflicts with mingw, keep only C:\msys64\mingw64\bin but remove C:\msys64\usr\bin. That other path contains the msys make and as I said you do not want to combine make commands during compilation.
Download from https://sourceforge.net/projects/gnuwin32/
Set the variable path in advance setting for recognize in command prompt (C:\Program Files (x86)\GnuWin32\bin)
So if you're using Vscode and Mingw then you should first make sure that the bin folder of the mingw is included in the environment path and it is preferred to change the mingw32-make.exe to make to ease the task and then create a makefile
and include this code in it .
all:
gcc -o filename filename.c
./filename
Then save the makefile and open Vscode Code terminal and write make. Then makefile will get executed.
I am assuming you added mingw32/bin is added to environment variables else please add it and I am assuming it as gcc compiler and you have mingw installer.
First step: download mingw32-make.exe from mingw installer, or please check mingw/bin folder first whether mingw32-make.exe exists or not, else than install it, rename it to make.exe.
After renaming it to make.exe, just go and run this command in the directory where makefile is located. Instead of renaming it you can directly run it as mingw32-make.
After all, a command is just exe file or a software, we use its name to execute the software, we call it as command.
For me installing ubuntu WSL on windows was the best option, that is the best tool for compiling makefile on windows. One thousand is better than Cygwin64, because to compile a makefile you will need another package and compile software like maybe gfortran, netcdf, etc, ect, in ubuntu WSL you can install all of these packages very easily and quickly ;)
The procedure I followed is;
I installed Gnuwin32's make using the installable.
Added the "make" path to the environmental variable PATH.
Verified the installation using "make --version"
Go to http://gnuwin32.sourceforge.net/packages/make.htm and download make-3.81.exe, install and add to Windows path.
May be it can work.
pip install Makefile