I'm trying to compile, on Windows 10, a C++ project that is using C++14 features such as std::make_unique<> and things like that.
I'd like to be able to compile easily in command line, using CMake and make and then be able to run my program from any command line or just by clicking it's executable.
Compiling using Cygwin, even if it's indeed working (I used this tutorial), is not an option since the resulting executable won't be usable outside of the Cygwin environment due to missing DLLs.
I've read about MinGW-w64, but it seems like the latest available version for Windows corresponds to GCC 4.8.3.
Same goes for the MinGW installer mingw-get-setup.exe available here, wich only allows me to install the 4.8.1-4 version.
So I'd like to have a procedure on how to compile a C++14 project using CMake, and that will allow me to launch the executable in the default Windows environment.
Thanks.
Update : Chris Drew commented that I could use the latest Visual Studio version to build my project using the Visual C++ compiler instead of GCC. I detailed the workflow in my answer, but I'm still looking for a "GNU-style" way to compile it.
"GNU-style" : Use the link provided in Tive's comment to install a working GCC 5.1 environment and use the normal cmake . -G"Unix Makefiles" && make commands.
See this answer for more details on both solutions.
Using Visual Studio compiler
Following Chris Drew comment, here's what I did in order to compile using CMake to generate a Visual Studio 2015 solution and compile this solution in command line.
Note that this is not using the GNU toolchain as we won't be using gcc / make but the Visual C++ Compiler.
Creating and moving to a build subdirectory (it's recommended since it will generate a lot of files, instead of just a standard Makefile) :
mkdir build && cd build
Generating the Visual Studio 2015 solution :
cmake . -G"Visual Studio 14 2015"
This will generate several project files including YourProjectName.sln that we will use to build the project using the following command :
msbuild YourProjectName.sln
Note that msbuild was not in my PATH, so I had to provide the complete path to the executable wich was, in my case, C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe.
Using an updated MinGW installer
Tive provided a link to a bundled installer that will automatically install GCC 5.1 on your system, this way you can use the normal GNU toolchain by generating an Unix Makefile, and using the make command.
Note that you will need to edit your PATH manually as the installer is not doing it for you.
Related
Im sorry for the bad title but I just don't know how to put this in the title, so if you do, please remove this line and update the title.
So Im trying to create a portable version of cmake (that doesnt needs admin rights) and I found this but the awnser only helped me getting cmake itself in a different location. Cmake also needs MSVS's (Microsoft Visual Studio's) Cmake tools to get it to work.
My question is where are these tools located, and can I copy them to a USB stick and make it so cmake uses the tools on the usb stick?
I thought that maybe I could make a batch file that sets a local variable to the tools on the usb stick and then start cmake so cmake knows where the tools are located, but I don't know if cmake even uses Environment Variables.
Any help would be greatly appreaciated, thanks
There are multiple points in your question that are unclear.
Portable CMake
With downloading the ZIP file of CMake you already "made CMake portable". Just unzip and run it.
CMake has an internal logic to detect installed Visual Studio versions and the compiler.
CMake Variants
Original
To use CMake with the MSVC compiler (or provided by Visual Studio) you do not need anything special from MSVC/VS. CMake uses the informations of the detected MSVC/Visual Studio to generate the project files, etc.
Visual Studio's CMake Variant
Visual Studio provides a version of CMake upon installation. To use your portable CMake variant you do not need anything from there.
Force a specific VS Generator
If you have only one Visual Studio installed then CMake will use this. If you have multiple Visual Studios installed normally CMake uses the newest one. In case you want to force a specific Version you can specifiy the CMake generator to use cmake-generators.
Another way would be to use the vcvarsall.bat or vsdevcmd.bat to setup the environment for a specific Visual Studio version and run CMake from that environment.
Finally
It is sufficient to have the original CMake release (from the ZIP file) on your USB stick. But it is not possible to provide a portable MSVC (Microsoft Visual Compiler) on your USB stick (as far as I know) as it has to be installed.
I need to build a dependency that uses SCons, and I need to build it with VC++2017, because another dependency I have cannot be built with VC++2019.
SCons successfully detects VC++2019 (v14.2), but not VC++2017 (v14.1):
c:\Python27\Scripts\scons [...] --msvc-version=14.1 [...]
scons: Reading SConscript files ...
scons version: 3.1.1
python version: 2 7 13 'final' 0
scons: warning: VC version 14.1 not installed. C/C++ compilers are most likely not set correctly.
Installed versions are: ['14.2', '14.0', '11.0']
[...]
C++ compiler $CC does not work
I have installed Visual Studio 2019 Enterprise as well as Visual Studio 2019 Build Tools, and for both, I have installed the platform tools / compiler for v14.1 and x86/x64. Compiling with the VC++2017 platform tools works fine in Visual Studio 2019 as well as using MSBuild, so the problem seems to be with SCons only.
How does SCons detect VC++2017 and VC++2019 and where should I start looking for the problem?
(There are old threads about this, but most of them are about people wondering why the "classic" detection/config methods using registry and vcvars.bat no longer work, so these are not helpful)
For current scons, it will believe what it gets back from vswhere.exe for the versions where that tool is considered definitive - 2017 and 2019. You can try seeing what that gives you.
vswhere -products * -property installationPath
That information is used to help locate the desired vars.bat file which imports the seetings needed.
I have found a perfect and simple solution:
Open file MSCommon/vc.py, find line: vc_pdir = os.path.join(vsdir[0], 'VC')
Change [0] to [1]
Re-build, the python will use vs2017
The reason is: if you install multi vs versions, the vsdir[0] is the highest one
Update: This is still (2021-09-16) an issue, and a simple workaround may be this answer - My answer also has a workaround, but it is more complicated and mostly for educational purposes on how recent versions of VC++ compilers can be detected and are (not properly) detected by SCons. You may also want to use my workaround if you are creating a build script for a build server or multiple development machines with varying setups.
The current version of SCons does not support selecting MSVC v14.1 (aka "Visual C++ 2017") if Visual Studio 2019 is installed, but Visual Studio 2017 is not. I confirmed this by looking at the code of SCons (see below).
An alternative approach is to use the --msvc-script option instead of --msvc-version.
In the MSVC installation folder, typically c:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\, you will find a file called vcvarsall.bat. If you run this without arguments, you will see that you can give it arguments for target platform and tools version, e.g.,
vcvarsall.bat x86 10.0.17763.0 -vcvars_ver=14.1
to compile for x86 (32-bit), Windows SDK version 10.0.17763.0 and tools version 14.1 (Visual C++ 2017).
Once you have found a command line for vcvarsall.bat that suits you, put it into a new BAT file that you create, say myvcconfig.bat (You have to use the complete path to vcvarsall.bat), then use the following command-line switch to SCons: --msvc-script=myvcconfig.bat.
*** Notes ***
Some parameters to SCons are redundant and will not work with --msvc-script, for example --32. SCons will tell you about them, so just remove them from the command-line.
The installation path of Visual Studio may be different from the one I provided above. You can find the installation path using Microsoft's own VSWhere tool. See also Locate Visual Studio
Visual Studio 2019 and Visual Studio Build Tools 2019 are separate installations with separate build tools. You can detect and use the vcvarsall.bat files of either ones. For example, if you are setting up a toolchain for a build server, you may want to use Visual Studio Build Tools 2019. If you just want to build one library one time (as in my case), just use the Visual Studio that is installed on your dev machine.
In case you are interested in how SCons detects MSVC and why it doesn't work, you can look at the source code in SCons/Tool/MSCommon/vc.py. You can clone the SCons GIT repository.
UPDATE: The following comment in vc.py (as of 2021-09-16) shows why this is still an issue in SCons and why this workaround is needed if you have both VC2017 and VC2019 compilers installed:
# make sure the cl.exe exists meaning the tool is installed
if ver_num > 14:
# 2017 and newer allowed multiple versions of the VC toolset to be
# installed at the same time. This changes the layout.
# Just get the default tool version for now
#TODO: support setting a specific minor VC version
Direct link (valid at time of writing)
How can I force Cmake to use Visual Studio 2010 for compiling my emscripten projects, and now VS 2015?
I keep running into an issue where cmake says it cannot find the build tools for MSBuild v140. I know it exists though, as the file path is
C:\Program Files (x86)\MSBuild\14.0\Bin
I've even tried setting the path in the Emscripten Command Prompt with
set PATH=C:\Program Files (x86)\MSBuild\14.0\Bin;%PATH%
but the issue still occurs.
If I open this solution in VS 2015, I can see that the configuration is set to Msbuild v 1.40, so I can't wrap my head around why Emscripten says it can't locate it.
The closest thing I could find is in this GitHub bug report on Emscripten.
Any suggestions?
Emscripten in Visual Studio is only supported for VS2010 AFAIK. Personally, I suggest you work with makefiles when generating from CMake. It is much more stable from my experience. The Visual Studio support for Emscripten is not working well, at least for me.
But if you still want to use VS2010, then you have to set the CMake generator to "Visual Studio 10 2010", and then specify the Emscripten toolchain file. You might have to set the CMake platform name to Emscripten, using the -A argument.
cmake.exe -G "Visual Studio 10 2010" -A Emscripten -DCMAKE_TOOLCHAIN_FILE=%EMSCRIPTEN%\cmake\Modules\Platform\Emscripten.cmake
I tried doing this, but each time I did, Emscripten would return a different path to Emscripten.cmake, and say it couldn't find it. Not sure where it was getting this new path from.
Long story short, I realized I installed the web installer for Emscripten installed. So I uninstalled that and instead went with the Full installer, and it all worked well.
Is there anyone who succeed to include libjpeg in some compiler? I tried everything: Dev C++, VS10, CodeBlocks, copy the headers and the lib by hand, add with the linker but nothing. Right now I am really confisued as there is not an official guide on how to compile it in any compiler. I would be really happy if someone could provide a tutorial on how the library can be compiled in any compiler.
Thank you in advance.
To compile libjpeg 9 in Visual Studio 2012, here are the steps (after unzipping the archive file):
Download the file WIN32.MAK (for example, from http://www.bvbcode.com/code/f2kivdrh-395674-down), and place a copy in the root source code directory (possibly C:\jpeg-9, but it depends where you unzipped it). I will refer to this directory as %jpegsrc% from now on. Having this file is important; otherwise step 3 will produce an error.
In the Visual Studio command prompt, open to %jpegsrc%:
cd %jpegsrc%
At the same command prompt, execute the following:
NMAKE /f makefile.vc setup-v10
This will create two Visual Studio 2010 solutions in %jpegsrc%: jpeg.sln and apps.sln.
Open each solution in Visual Studio 2012. Each one will prompt you to update all the projects to 2012 format. Click on “Update.” One time I did it, the prompt did not appear. In case that happens, right-click on the jpeg solution in the Solution Explorer, and choose “Update VC++ projects...,” which will produce the same prompt.
Save and build each solution as normal. (You have to build the jpeg.sln solution before apps.sln, since the latter depends on the former.)
Note: this process should work correctly in Visual Studio 2010, without the updating, but I have not tested it.
Update: This method still works in Visual Studio 2015 for libjpeg-9a.
Here is how I've built libjpeg using MinGW on Windows :
1. Get MinGW with MSYS
I've got a copy from http://sourceforge.net/projects/mingw/.
Quoting from www.mingw.org :
MSYS is a collection of GNU utilities such as bash, make, gawk and grep to allow building of applications and programs which depend on traditionally UNIX tools to be present.
We will need it to run the configure script that comes with libjpeg sources.
2. Get libjpeg sources
From http://www.ijg.org/, take the Unix format package (the Windows one won't work with this procedure). I took the jpeg_8d version.
3. Prepare a building directory
I've made a temporary directory named tmp in D:\, but you could choose whatever suits your needs. The thing that matters is the name of paths in MSYS. As it brings some * Unixity * to Windows, paths cannot be used in their original form.
In a nutshell:
C:\path\to\file becomes /c/path/to/file in MSYS land, an so
D:\tmp becomes /d/tmp.
Decompress the libjpeg sources in D:\tmp, so you have a jpeg-8d directory in there.
Create a jpeg-build directory inside D:\tmp, it will hold the built library.
Now everything is ready for the build.
4. ./configure, make, make install
That is the mantra of building in Unix land. An option should be added to redirect the install process to D:\tmp\jpeg-build.
Run the following commands in an MSYS shell (also named MinGW shell in Windows start menu):
cd /d/tmp/jpeg-8d
./configure --prefix=/d/tmp/jpeg-build
make
make install
As an additional step, you can run make test for safety.
These commands will build both static and shared versions of libjpeg.
5. Take the goods, delete the temporaries
If everything runs fine, you can delete the D:\tmp\jpeg-8d directory, but keep the jpeg-build one. It contains:
an include directory, containing libjpeg headers. You can move them to your compiler's headers directory.
a lib directory, with .a file to pass to the linker. You can move them to your compiler's library directory.
a bin directory, holding the libjpeg shared library libjpeg-8.dll and jpeg tools.
a share directory, containing man pages for the jpeg tools.
You can now build your program and link it against libjpeg by indicating the right include and library paths.
You can find many details about the libjpeg building and installation process in install.txt inside the source package.
I hope this will be useful.
It is really simple to build jpeg.lib with VS10.
First, download the libjpeg source code in zip format. At the time I'm writing this you can find it here.
Then extract the contents of the zip file to your disk.
Then open a VS2010 command prompt shell (or call vcvarsall.bat on any command prompt window), cd to the jpeg source directory (jpeg-8d in the download referenced above) and type the following:
nmake -f makefile.win setup-v10
This will generate two VS2010 solutions, and a bunch of project files. The solutions are:
jpeg.sln, which builds jpeg.lib
apps.sln, which builds the sample applications.
Good luck!
If you don't happen to have Visual Studio 2010 installed, here is what works on Visual Studio 2017:
Basic / Common steps:
Download the latest version of libjpeg from: http://www.ijg.org/ (zip version) and extract it to a folder
Open the "Developer Command Prompt for VS2017"
Change directory (cd) to where you extracted the library source
VS 2017 Approach:
Include the Windows SDK v7.1A directory (required for Win32.Mak by nmake later on) by running: set INCLUDE=%INCLUDE%;c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include
Run nmake /f makefile.win setup-v15 (note the v15 for VS2017 here)
From here on follow what #AthanasiusOfAlex explained to upgrade the Visual Studio 2010 solution to the Visual Studio version you are running. If you want the Debug configuration, follow what #SteveEng explained.
Errors you might stumble across:
If nmake fails and tells you it doesn't know how to make
jconfig.h, manually rename the file jconfig.vc to jconfig.h
If nmake fails and tells you Win32.Mak cannot be found, manually copy it from the SDK dir mentioned in step #4 to the libjpeg source directory. If you don't happen to have that SDK version installed, download the file from a trustworthy resource.
If nmake fails and tells you it doesn't know how to make setup-v15, trial and error your way through starting with setup-v10, setup-v11, etc... These are VS versions and one of them should work as long as you have any VS version later than VS 2008 installed.
Hope this helps people going through similar pain with this.
If you want debug mode as well in MSVC. Follow AthanasiusOfAlex's method, build the release, then:
Right-click on the project and select properties at the very
bottom
Click on configuration manager and on the active solution
configuration drop-down select -new-
Set the name to debug and on
the drop-down select copy configuration settings from release and
click OK
Close the dialog, go to general settings and under Target
Name add a d to the end so it looks like this: $(ProjectName)d
On Whole Program Optimization drop-down select: No Whole Program Optimization
Then click on the C/C++ under configuration properties on the left and on the Debug Information Format drop-down select C7 compatible (/Z7)
Under optimization select disabled and select NO for both Enable Fiber-Safe Optimizations and Whole Program Optimizations
Under preprocessor, preprocessor definitions, click on edit and use the following:
WIN32
_DEBUG
DEBUG
_LIB
_CRT_SECURE_NO_WARNINGS
Under code generation, under runtime library select Multi-threaded Debug DLL (/MDd)
Build and you're done!
This is for VS2019 with version number 16.0
Consider the Visual Studio Version name correctly like this for creating the .sln file.
Product name Code name Version number
Visual Studio 2019 Dev16 16.0
Visual Studio 2017 Dev15 15.0
Visual Studio 2015 Dev14 14.0
Visual Studio 2013 Dev12 12.0
I know how to build boost with the latest visual studio on my machine (this question, for example)
However, I need to build the libs for Visual Studio 2008 (vc9)
I tried using toolset=vc9 but I get problems/no success.
How can I build the libs for vc9?
After I run boostrap I try running
b2 toolset=vc9
but the output is:
C:/Development/boost
50/boost_1_50_0/boost_1_50_0/tools/build/v2/build\toolset.jam:39: in
toolset.using rule vc9.init unknown in module toolset
C:/Development/boost
50/boost_1_50_0/boost_1_50_0/tools/build/v2\build-system.jam:481: in
process-explicit-toolset-requests
C:/Development/boost
50/boost_1_50_0/boost_1_50_0/tools/build/v2\build-system.jam:562: in
load
C:\Development\boost
50\boost_1_50_0\boost_1_50_0\tools\build\v2/kernel\modules.jam:283: in
import
C:\Development\boost
50\boost_1_50_0\boost_1_50_0\tools\build\v2/kernel/bootstrap.jam:142:
in boost-build
C:\Development\boost 50\boost_1_50_0\boost_1_50_0\boost-build.jam:17:
in module scope
toolset=msvc-9.0
I have VS2008-Pro and VS2010-Express installed. The default ran with VS2010. Setting toolset=msvc-9.0 caused the build to run with VS2008. Using Boost 1.51.0.
You'll need to dig into the How-To-Build-Boost documentation, and in particular see this;
but the part you need to specify a particular MSVC version is pointed to here. That suggests creating a user-config.jam, which probably would work, but I created a project-config.jam file instead.
I seem to be able to do this by running the top-level boost build (or meta build) script from different VC command lines. For example to build with VC2012, start a command line with vc 2012 vars. And for 2010, do the same. The automatically generated build scripts seem to do the right thing.
I am sure there are ways to do this by editing the build scripts myself or by setting the toolset, but I had no success with that.