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.
Related
I have the following folder structure for a VS2019 solution/project:
Solution_folder\
my_solution.sln
cpp_project\
my_cpp_project.vcproj
ifort_project\
my_ifort_project.vfproj
...
...
and I want to build specific projects from this solution using the command prompt.
Following the answer here, as well as the MS docs guidance
I tried the following:
devenv %path_to_sln_folder%\my_solution.sln /build Release /project .\ifort_project\my_ifort_project.vfproj /projectconfig Release
Also tried other variations according to the documentation (eg reference the name of the project only or pass the absolute path of the project). However, I always get the following error:
The operation could not be completed
Use:
devenv [solutionfile | projectfile | folder | anyfile.ext] [switches]
The first argument for devenv is usually a solution file, project file or a folder.
You can also use any other file as the first argument if you want to have the
file open automatically in an editor. When you enter a project file, the IDE
looks for an .sln file with the same base name as the project file in the
parent directory for the project file. If no such .sln file exists, then the
IDE looks for a single .sln file that references the project. If no such single
.sln file exists, then the IDE creates an unsaved solution with a default .sln
file name that has the same base name as the project file.
Command line builds:
devenv solutionfile.sln /build [ solutionconfig ] [ /project projectnameorfile [
/projectconfig name ] ]
Available command line switches:
/Build Builds the solution or project with the specified solution
configuration. For example "Debug". If multiple platforms
are possible, the configuration name must be enclosed in quotes
and contain platform name. For example: "Debug|Win32".
/Clean Deletes build outputs.
/Command Starts the IDE and executes the command.
/Deploy Builds and then deploys the specified build configuration.
/DoNotLoadProjects Opens the specified solution without loading any projects.
/Edit Opens the specified files in a running instance of this
application. If there are no running instances, it will
start a new instance with a simplified window layout.
/LCID Sets the default language in the IDE for the UI.
/Log Logs IDE activity to the specified file for troubleshooting.
/NoVSIP Disables the VSIP developer's license key for VSIP testing.
/Out Appends the build log to a specified file.
/Project Specifies the project to build, clean, or deploy.
Must be used with /Build, /Rebuild, /Clean, or /Deploy.
/ProjectConfig Overrides the project configuration specified in the solution
configuration. For example "Debug". If multiple platforms are
possible, the configuration name must be enclosed in quotes
and contain platform name. For example: "Debug|Win32".
Must be used with /Project.
/Rebuild Cleans and then builds the solution or project with the
specified configuration.
/ResetSettings Restores the IDE's default settings, optionally resets to
the specified VSSettings file.
/ResetSkipPkgs Clears all SkipLoading tags added to VSPackages.
/Run Compiles and runs the specified solution.
/RunExit Compiles and runs the specified solution then closes the IDE.
/SafeMode Launches the IDE in safe mode loading minimal windows.
/Upgrade Upgrades the project or the solution and all projects in it.
A backup of these files will be created as appropriate. Please
see Help on 'Visual Studio Conversion Wizard' for more
information on the backup process.
Product-specific switches:
/debugexe Open the specified executable to be debugged. The remainder of
the command line is passed to this executable as its arguments.
/diff Compares two files. Takes four parameters:
SourceFile, TargetFile, SourceDisplayName(optional),
TargetDisplayName(optional)
/TfsLink Opens Team Explorer and launches a viewer for the
provided artifact URI if one is registered.
/useenv Use PATH, INCLUDE, LIBPATH, and LIB environment variables
instead of IDE paths for VC++ builds.
To attach the debugger from the command line, use:
VsJITDebugger.exe -p <pid>
I must say that just by removing the part from /project onwards, the build starts ok and finishes without errors, but it is not what I want.
It strikes me as odd, as I believe I'm following the documentation correctly, yet the error message suggests I don't? Also, it doesn't seem to be solution- or project-specific as it's happening with other solutions/projects.
Am I missing anything obvious here?
Thanks
I am starting out with F# and trying to get it to work with Sublime Text 3 with a package, https://github.com/fsharp/sublime-fsharp-package. After installing the package using Package Control, I see F# appear as an available language to use in Sublime Text's bottom bar, and syntax highlighting appears to work more or less, from what I can tell, but the build system for F# fails to appear as it should.
So, trying to fix things, I run "build.sh install" and get an error, "Cannot open assembly '.paket/paket.bootstrapper.exe': No such file or directory." I am sort of stuck. Many thanks for any help.
From the comments you've made, you appear to be a little unfamiliar with the Unix underpinnings of OS X. I'll explain those first, then I'll suggest something for you to try that may fix your problem.
Technically, files or directories whose name starts with . are not "reserved for the system" as you put it; they're hidden. Now, it's true that Finder won't allow you to create files or directories whose name starts with ., because Apple didn't want to have to field all the tech-support calls from people who didn't know about the hidden-files feature: "I named my file ... more important stuff for work and now it's gone! Help!!!" But if you're in the Terminal app, then you can easily create files or directories with . as their first letter: mkdir .foo should work. You won't see it when you do ls, but ls -a (a for "all") will show you all files, including hidden files. And you can also do cd .foo and create files inside the hidden .foo directory -- and while the .foo folder won't show up in Finder, it will be perfectly accessible in the Terminal, and to any F# programs you might write.
So when you say that you cloned https://github.com/fsprojects/Paket but it failed to include the .github and .paket directories, I think you just don't know how to see them. You can't see them in the Finder (well, you can if you jump through a couple of hoops but I don't think it's worth the effort), but you can see them with ls -a. Just open your terminal, run cd /Users/Username/Paket, and then run ls -a and I think you'll see that the .paket and .github directories were indeed created by your git clone command.
So what you should probably try is this:
Go to https://github.com/fsprojects/Paket/releases/latest
Download the paket.bootstrapper.exe and paket.exe files. Put them in /Users/Username/Downloads (or wherever the default OS X Downloads directory is if it's different -- just as long as it's somewhere where you can find them easily).
Open the Terminal app.
Go to the directory where you've unpacked the Sublime Text 3 package. I.e., in the Terminal app, run cd /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master.
Run ls -a and see if there's a .paket directory.
If it does not exist, run mkdir .paket.
Now do cd .paket so you're in the hidden .paket directory under sublime-fsharp-package-master.
Now do ls and see if there's a paket.bootstrapper.exe file.
If it doesn't exist, then copy in the .exe files you downloaded earlier:
cp /Users/Username/Downloads/paket.bootstrapper.exe .
cp /Users/Username/Downloads/paket.exe .
Important: Now do cd .. to go back up to the /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master/ directory.
Now instead of running /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master/build.sh install, try running it as ./build.sh install. (And also try ./build.sh Install, since I'm pretty sure the capital I is necessary).
(BTW, If you're not familiar with the syntax that I used in steps 9, 10 and 11, where I used a single . or two dots .. in commands, those are a long-standing Unix idiom: . means "the current directory", and .. means "the parent directory".)
I just looked at the build.sh script that you've been running, and it seems to assume that you've done a cd into the package's base directory (the sublime-fsharp-package-master directory) before running the script. So that could explain why it was failing: you were running it from a different directory, rather than doing a cd first. Hence why I marked step 10 as important: I think that was the root cause of the problem.
https://github.com/ninja-build/ninja/releases
I have downloaded the ninja-win.zip folder and extracted it. When I open it, there is a single .exe file in the entire folder. When I double click it a cmd window flashes for a split second. I have also tried running it as administrator, but the same thing happens. What I don't understand is, what am I expected to do with this .exe file?
You must open a terminal (cmd.exe on Windows) and type something like ninja -f /path/to/buld/file. You may also wish to modify the PATH environment variable so that Windows knows where to find the Ninja executable, depending on your setup.
You can simple download ninja.exe file from this Link
https://github.com/ninja-build/ninja/releases
After that you just have to add the path to your ninja.exe file to your windows environment variables and then you can use ninja commands from anywhere in windows.
1. Open cmd in your Project Directory
2. There are guides on the internet on where to save the Ninja.exe so that it'll be callable in Cmd without specifying directory. Either follow them or:
i, Specify Directory when Calling Ninja. Putting "ninja" in Cmd actually calls Ninja.exe and is the same as something like "C:\users\user1\downloads\Ninja". or:
ii, Save Ninja.exe in the same directory as Project.
3. proceed with rest of the command.
Therefore the Final Command would be:
"C:\users\user\downloads\Ninja.exe" -f "D:\Projects\Project1"
I am writing a small shell script that launches a program in my wine directory.
My challenge is that I have installed this on multiple machines, some with 64
and some with 32 bit, some with English and some with Norwegian locals.
the name of the program files directory in $HOME/.wine/drive_c can thus change
from Program Files, Program Files (x86), programfiler etc..
The bash line I have so far is this:
(cd $HOME/.wine/drive_c/[Pp]rogram*/... ; wine ...)
However, the [Pp]rogram* line does not work, does anyone have a good suggestion?
That should work just fine, but since you will have both Program Files and Program Files (x86) on 64 bit installations this will always expand to Program Files which might be wrong in your case.
I would use the following to dynamically determine the correct path:
look_for='My Program/myprogram.exe'
for dir in "$HOME"/.wine/drive_c/[Pp]rogram*[Ff]*/; do
if [ -e "${dir}${look_for}" ]; then
cd "${dir}"
wine [...]
exit $?
fi
done
This loops over all possible "program files" directories and checks if the file/directory specified in $look_for exists underneath it. If it does, it takes the directory component of $look_for, cds into it and runs wine from there.
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