I'm trying to run cmake in Visual Studio 10, for esys-particle-win.
My path to cmake:C:\Program Files (x86)\CMake 2.8\bin\cmake.exe
My path to esys-particle-win:C:\esys-particle-win\trunk\buildvs2010\mkvs10.bat
The commands I'm typing in the administrator command prompt of Visual Studio 2010 are:
cd c:\esys-particle-win\trunk\buildvs2010
mkvs10.bat
and I'm getting this error:
'cmake' is not recognized as an internal or external command
contents of mkvs10.bat:
cmake .. -G "Visual Studio 10" -G "NMake Makefiles"
could anyone tell me where I am wrong?. I don't know computer programming. I followed the instructions mentioned in section 2.3.1 of this site: `
https://launchpadlibrarian.net/139659869/esys-particle-win-%28v2.1%29-build-instructions.pdf
`
Any help would be greatly appreciated, Thank you.
The error message means it cannot find cmake.
You can add its location to your path from the prompt like this:
set PATH="C:\Program Files (x86)\CMake 2.8\bin\";%PATH%
As #doctorlove mentioned above, the error message means it cannont find Cmake.
Note that quotes aren't needed in PATH environmental variables on Windows. So the above example on Windows would look like:
set PATH=C:\Program Files (x86)\CMake 2.8\bin\;%PATH%
I had the same issue, and resolved it in this post.
note that if you installed cmake via chocolatey, you may have neglected to add the argument --installargs 'ADD_CMAKE_TO_PATH=System'. If you've already choco-installed cmake without that argument, re-installing via --force won't respect the new argument: you'll need to uninstall and then install. specifically choco install cmake --installargs 'ADD_CMAKE_TO_PATH=System'
I had the same problem since I intalled CMake in D:\Program Files , I fixed it by manually adding a path variable.
Open control panel
Go to System and Security then go to System.
How it looks like in after step 2
Here Select advanced System settings, a dialogue box will appear.
The dialogue box
Now go to Environment Variables.
Now select path and then click on edit
After the 4th Step
Here add a new path at the bottom of many pre existing paths.
In my case i installed CMake in D:\Program Files\
So I need to add path D:\Program Files\CMake\bin. You should copy the path to your CMake folder and add \bin at the end.
Now open you have to restart command prompt to see the changes.
I found the CMake to be:
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin
I added it to the User PATH as described above, by hrithik singla, and node-gyp worked, specifically "npm install". I expect it will change again in the future. So the way I found it was by having Windows Explorer search "C:\Program Files (x86)\Microsoft Visual Studio\2019" and then dig through the results for the CMake path. Probably, other development tools will install CMake to different folders.
I'm trying to build a project with my recently downloaded Visual Studio Community 2017, but had no CMake on my path.
It did not help, even after I had gained VCVars: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
Instead of separately installing a copy that might work with these answers, although I'm not sure it would have the generators I need(?), I found one in the installation directory, which had a different path than what was in the guide I was using.
Here is my invocation line: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -G "Visual Studio 15 2017" -DCMAKE_BUILD_TYPE=%CMAKE_BUILD_TYPE% ..
There are a few issues that can cause this. And it's mostly windows related. This is more on the cmake side of things, but it addresses a few windows specific problems you may encounter using CMake with Windows. This is fresh in my head, and this popped up, so I'll drop this here. Here we go.
1. CMake will separate a variable to list if there are spaces in the path.
If you are calling another instance of CMake from within CMake, Sending a Program Files path will slice those strings, and divide your variable into a 3 item list. The spaces will be replace by a semicolon divider.
set(CMAKE_EXE C:\Program Files (x86)\CMake\bin\cmake.exe)
"C:\Program;Files;(x86)\CMake\bin\cmake.exe <- CMAKE_EXE is now a 3 item list separated by ; "
list(LENGTH ${CMAKE_EXE} count)
message("CMAKE_EXE has ${count} items") "-> displays 3"
On Windows, All path variables should be enclosed in quotations to infer that they are 1 single string variable. Not just for cmake, but for batch scripting, basic command line etc.
set(CMAKE_EXE "C:/Program Files (x86)/CMake/bin/cmake.exe")
Now, any time you reference CMAKE_EXE you'll need to always keep it enclosed in quotations, becuase cmake WILL break it to a list again otherwise.
execute_command(COMMAND cmd /c ${CMAKE_EXE} -P myScript.cmake) <-- BAD
execute_command(COMMAND cmd /c "${CMAKE_EXE}" -P myScript.cmake) <- GOOD
Just get in the habit of always putting quotations around paths you reference.
2. Stay away from the Windows back slashes!.
Windows uses back slashes by default for it's path divider, which are escape sequences in most coding languages, including CMake. Just send windows / forward slashes instead. This eliminates any headaches you'll have with doubling up escape characters in string literals to match the path. \
And remember, windows is always gonna try to give you paths in \ format. Windows likes backslashes in certain places like environment paths, and settings files, while cmake likes forward slashes. You need at some point to convert between the different formats.
Use something like this to convert the path to be more cross platform compatible. You can replace "in place" on your existing variable.
"CMAKE_EXE = C:\Program Files (x86)\CMake\bin\cmake.exe <- value before"
string(REPLACE "\\" "/" CMAKE_EXE "${CMAKE_EXE}") "<- notice the quotes again"
"CMAKE_EXE = C:/Program Files (x86)/CMake/bin/cmake.exe <- value after"
Take a look at these CMake functions designed to do path conversions.
https://cmake.org/cmake/help/latest/command/file.html#to-native-path
3. Sometimes, Windows interprets unquoted paths as 8.3SFN (8DOT3) format
8.3 filename
Back in the days of MSDOS and Windows 95, we dealt with the FAT file system and 8.3Short Filenames. The command prompt could not work with more than 8 character filenames so we needed a way to access long windows filenames before quotation string support. 8 characters + 3 for the extension. And most systems still support 8.3 today. Here's an example.
C:\Program Files\Windows\System32\Calc.exe <- \Program Files\ is 13 characters
in order to CD into this path without quotes, you have to use the short path. like so.
CD C:\Progra~1\Windows\System32\Calc.exe <-- *Progra~1 is 8 characters, 1st occurrence.*
You just break the File or Folder name down to 6 characters, plus ~n (n=occurrence)
If we had a C:\Program Files (x86) path then, like we do today, it would be the 2nd path who's first 6 characters matched, and both exceeded 8 characters.
C:\Program Files becomes -> C:\Progra~1\
C:\Program Files (x86) becomes -> C:\Progra~2\
C:\MyLongFilename.txt becomes -> C:\MyLong~1\
Whenever I am having trouble accessing the full length file system through software that is unable to send escape sequences or quotations, some other kind of limitation, I have to resort to using the 8.3 short filename to access certain paths. On some Windows boxes, quotes won't even work and it will be some LONG process to enable them on the host machine. This makes for a good workaround when that happens.
Getting the short path (via sending to command prompt)
C:\ for %A in ("C:\Program Files (x86)\CMake\bin\cmake.exe") do #echo %~sA
will produce C:\Progra~1 for you to use
Or, get the short path by sending the path as an argument to a batch file.
::getShortPath.bat
#ECHO OFF
echo %~s1
USE:-> getShortPath.bat "C:\Program Files (x86)\CMake\bin\cmake.exe"
To wrap this up, here are three examples of what could be happening in the background behind CMake when a windows path is not resolving.
Not using quotations around the path
Using quotes works. But sometimes you can lose your quotes if the stdio >> runs through more than one process. In which case you'll need to send them in as escape sequences "\"C:/Program Files (x86)/CMake/bin/cmake.exe\""
4. Paths and Command Line Arguments need to be separate variable or instances from each other.
When sending arguments from CMake, you DO want them to be separate variables from the path variable. Set(CMAKE_EXE "C:\Program Files (x86)\CMake\bin\cmake.exe --version") will not work. Only paths and arguments with spaces in them need to be wrapped in quotes.
set(CMAKE_EXE "C:\Program Files (x86)\CMake\bin\cmake.exe" --version --trace "C:\My Soure Dir")
Putting it all together
If anyone is having problems with Windows/CMake paths like I was in the past, Study this code thoroughly until you completely understand it. All of the quotation placements. When you understanding what's quoted and what's not, and why, it should help a lot in the long run.
set(CMAKE_EXE "C:\Program Files (x86)\CMake\cmake.exe" CACHE INTERNAL "") <- make it a global variable.
set(ARGUMENTS --version --trace)
set(MyStringWithQuotesIncluded "\"This String wants it's quotes included\"")
set(MyCMakeLists "C:\MyApp\ProjectDirectory")
set(BuildHere "C:\MyBuilds\MyOSProject\bin")
set(FULL_COMMAND "${CMAKE_EXE}" ${ARGUMENTS} -DSTRING_VARIABLE="${MyStringWithQuotesIncluded}" -S "${MyCMakeLists}" -B "${BuildHere}")
execute_command(COMMAND cmd /c ${FULL_COMMAND} WORKING_DIRECTORY "${BuildHere}")
I had loads of issues working with windows paths through layers of CMake when I first started out. I hope this can help someone avoid all of that in the future.
Step 0: Install CMAKE
Make sure you have CMAKE installed on Windows:
https://cmake.org/download/
The installer will ask you if you want it to automatically set the PATH variable for you.
set the path to C:\Program Files\CMake\bin
Related
First off I would like to say I've seen the previous questions on this site, I've tried every solution but none fit my use case or solves my problem.
I am having trouble with the g++ complier being recognized, I've included this path:
C:\Program Files (x86)\mingw-w64\i686-7.2.0-posix-dwarf-rt_v5-rev1\mingw32\bin\g++.exe
which is where the current version of mingw is located (recently downloaded). I've also tried other options like changing the path to gcc.exe, and just regular bin. Someone please provide a detailed solution to this problem.
Other things i have tried and looked at closely would be:
http://stephencoakley.com/2015/01/21/guide-setting-up-a-simple-c-development-environment-on-windows
seeing as though I'm working through sublime text 3
Another thing Ive tried:
Ive tried to copy and paste the path into cmd and run it , but i find this error code:
C:\Users\Kxrk>C:\Program Files (x86)\mingw-w64\i686-7.2.0-posix-dwarf-rt_v5-rev1\mingw32\bin\g++.exe
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
So seeing that, i tried another way , and that is to drag the file and drop it into cmd and get this :
C:\Users\Kxrk>C:\Program Files (x86)\mingw-w64\i686-7.2.0-posix-dwarf-rt_v5-rev1\mingw32\bin\g++.exe
g++.exe: fatal error no input files
compilation terminated
when u drag and drop the file it has double quotes around it , so i tried editing the path to contain double quotes around it and the path automaticlly changes back after saving.
This was very simple , it was one of those weird cases.
To solve my problem what i did was:
1: uninstall , the current version of the mingw compiler , because i felt as though the one i had was corrupt in a way.
2:Redownloaded it the compiler from the website http://www.mingw.org/
3: set up the new Environmental variable where i save it , witch was C:\MinGW\bin
I had to install g++ from the command line(cmd ,command prompt)
by using this command mingw-get install g++witch is located inside bin on default
now i created one more directory in the environmental variables , C:\MinGW\bin\g++.exe
6.Now everything works , and is normal
If you are trying to run the compiler from the command line then you have to put double quotes around the path, because the path contains two whitespaces (this is the reason for the first error).
The reason for second error is that you didn't specify which C++ program you want to compile. You have to append the filename of your C++ input file to your command:
C:\Users\Kxrk>"C:\Program Files (x86)\mingw-w64\i686-7.2.0-posix-dwarf-rt_v5-rev1\mingw32\bin\g++.exe" program.cpp
See Barmak Shemiranis answer if don't want to enter the full path all the time. After that you can just use this:
C:\Users\Kxrk>g++ program.cpp
You have to use quotation marks around the path so that is treated as a single path:
c:\>"c:\program files\path\g++.exe"
A better way is to set the environment variables. Open Environment variables windows (in Windows 10 you can type in "environment variables" in search box) or right click on "Computer" in desktop, open "Advanced System Settings" and find the button for "Environment variables"
Go to your command propmpt, type set path, it will show list of directories, copy them,
Now type set path=<data you copied> and then add a semicolon and possible directory to g++ usually C:\MinGW\bin
Environment: windows 10, VS2013.
I have a C++ app, using Poco framework (Poco 1.7.6) and I need to launch some batch files. It works without problem, but for a particular script, and I can't figure out the reason.
This particular script is as follows (let's call it buildMySolution.bat):
set BUILD_DIR=%~dp0
call "C:\Program Files(x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat"
msbuild /p:Platform=%~1 /p:Configuration=%~2 %BUILD_DIR%\Mysolution.sln
As you can see the batch file simply compiles a VS2013 solution. Needless to say that this simple batch works perfectly well if launched from command line.
The problem is that this batch is in drive D: (in D:\DevRoot\build\MySolution) and when launched from my app (in D:\ drive as well), I get a "cannot find the path" on the second line.
I tried several modifications in the batch: like forcing C: or cd /D C: ... it can go to C: but not further, it refuses to cd to the directory containing vcvarsall.bat (again, I know the path is correct as the very same script executes fine from command line). It has however no problem coming back to initial directory through a cd /D %BUILD_DIR%.
To launch the script from my C++ app, I use this:
Poco::ProcessHandle handleBuild = Poco::Process::launch(path_to_script, argsBuild);
handleBuild.wait();
The Poco launch is just a thin wrapper around CreateProcessA(), I don't see anything special in their code (Poco Process.cpp).
I tried as well to specify the working directory to be the directory containing vcvarsall.bat, but then CreateProcess fails.
I just found a solution: I changed the line (in the batch buildMySolution.bat):
call "C:\Program Files(x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat"
to:
call C:\PROGRA~2\micros~1.0\vc\vcvarsall.bat
Believe it or not: using DOS names and removing quotes makes it work!!!
Bug or feature, I'm not sure...
I am trying to set up and run LibreCAD and I am following their Build From Source Guide.
At some point, and after installing QT and boost, I reach the step where it says this:
To change these default settings you have to create the file
scripts/custom-windows.bat and overwrite the different settings
without effect to the SCM (git). Example for
scripts/custom-windows.bat:
set Qt_DIR=C:\Qt\5.4
set NSIS_DIR=C:\PROGRA~2\NSIS
set MINGW_VER=mingw491_32
So I created a custom-windows.bat file and overwrote the settings. Now, and since I am working on 64 bit Windows, They are saying that I need to do this:
There are issues with the NSIS_DIR path on 64 Bit Windows. When NSIS
is installed in the Program Files (x86) folder and NSIS_DIR is added
to the PATH, something goes wrong in the build process.
In this case use the command dir /X \ and get an output like this:
09/02/2014 09:50 PM <DIR> PROGRA~1 Program Files
10/27/2014 12:33 PM <DIR> PROGRA~2 Program Files (x86)
08/16/2014 10:49 PM <DIR> Qt
But what does that mean? "..use the command dir /X \ and get the output.." Where and how? Appreciate it if anyone could tell me how to solve that.
Open up a command prompt and literally type dir /X \. The output will show the mapping between the short folder names and the long ones.
Your goal is to use the correct short form representation for Program Files (x86) in NSIS_DIR, since it's not always PROGRA~2. It can vary from filesystem to filesystem, based on the history of the filesystem.
i have a problem with VS2008 Pre build command.
I need to compile a lot of XSLT style sheets and generate a common assembly, i use xsltc.exe but the command string is too long for command prompt.
I tried to use also a .bat file, i use the xsltc.exe command in the best way for save some character, like using "\c" instead of "\class", but the problem still remains.
Do you have any suggestion to solve this problem? please note that i can't install on my machine additional tools.
Thank You All!
Can you post the full command you're trying to run?
If you are trying to feed the compiler with whole path names to the stylesheets, would it perhaps help to, in the batch file, cd to the directory containing your stylesheets and then run the following command?
c:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\xsltc /out:MyAssembly stylesheet1.xsl stylesheet2.xsl stylesheet3.xsl [...]
i.e. for example:
cd c:\My\Stylesheets
c:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\xsltc /out:MyAssembly stylesheet1.xsl stylesheet2.xsl stylesheet3.xsl ...
instead of:
xsltc /out:c:\My\Stylesheets\MyAssembly c:\My\Stylesheets\stylesheet1.xsl c:\My\Stylesheets\stylesheet2.xsl c:\My\Stylesheets\stylesheet3.xsl [...]
I have not worked with xsltc (and you haven't provided enough information) so please excuse any formal flaws.
How can a batch file lists itself in the startup list of Windows???
It doesn't matter if it goes from the registry or not.
IF with the registry, please give also the command to DELETE the registry entry.
This should work under all versions from ME to 7 please.
Otherwise just XP/Vista/7.
Thanks.
Not sure i understand you, but if what you want is an easy way to execute a command/batch on startup, why not just put it in the All Users\Startup folder?
To do so programatically would just mean copying a file to that directory.
For example, in Windows Vista, the full path of that directory is:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
(you can use replace the beginning of the line with %ProgramData% or %AllUsers%\ProgramData to make it more global - such as when Windows is installed on D:).
I do not use windows7 (might get a check at the beta shortly), but I think the correct place will always be better taken from the registry, because of the Windows versions being localized. My own version of C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup here looks more like "C:\Documents and Settings\All Users\Menu Démarrer\Programmes\Démarrage" (from XP, of course)
-10 for programmers using hard-coded directory names (yes, some installers will create english/different language directories at installation).
-1 for Microsoft localising directory names...
Anyhow here is a snipet for this, valid for XP at least:
commonstartup.cmd
#echo off
for /F "tokens=3 delims= " %%k in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" /v "Common Startup"^| findstr /i /c:"Common Startup"') do set StartUp=%%k
echo StartUp="%StartUp%"
___Notes_____
1: Because reg.exe from Windows2000 and XP have different command arguments, maybe the W7 one has changed too so test it before set and forget.
2: To get a list of all the system directories, issue the command: reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" and read the lines. You might want to change the "Common Startup" for something else, if things are so different with W7.
3: There is also a personal/user list within HKEY_CURRENT_USER if you want this to be usable by some users only.
xcopy C:\Users\NAME\Desktop\Batch.bat C:\ProgramData\Microsoft\Windows\"Start Menu"\Programs\StartUp /O /X /E /H /K
is the correct command for windows 10. simply change the the second path to your version, and remember whenever there is a space, place a " before the word before the space, and after the word after it.
however, it MUST be opened in administrator, so after some research, i found that a batch file could be used to start a different batch file and run it in administrative mode:
runas /user:administrator C:\data\mybatchfile.bat
that should work!