I am creating and building a c++ project using cmake from scratch.
The executable requires command line arguments.
I am specifying them in Visual studio.
Is it possible to specify them by default when cmake builds the project (in my CmakeLists.txt for example) ?
So that I (or others) won't need to specify these arguments each time I build the project for the first time (I would want to just run the project without worrying about that but still can change them in visual studio of course if needed) ?
If you are using CMake 3.13 and above you can add the VS_DEBUGGER_COMMAND_ARGUMENTS property to your executable target in order specify those arguments.
Related
CMake is a build system generator supporting different build systems and environments like make, visual studio, code-blocks, eclipse-cdt, etc...
To generate a project, you can use the -G option to specify the project generator.
Is there an option, are there any projects, or is it possible to write a generator that creates batch files calling cl.exe so I don't have to open visual studio every time?
CMake is able to invoke the build tool (MSBuild in this case) by itself, using the --build option. See this question for more details.
I have a CMake project. It is a crossplatform project developed by a team of developers. Visual Studio and other make files are inside version control for library release and external developers.
Each time a file is added we need to recompile all project files for all platforms. How do I force CMake to generate new project files for all systems at once (if possible from inside CMakeLists.txt, not as command line arguments)?
I think it doesn't make sense for this to be possible within the CMakeLists.txt file. CMake is a makefile generator. Everything in the CMakeLists.txt file is configuring the makefile, and it can also be repurposed to make project files.
If the CMakeLists.txt file could also request to generate a different kind of makefile... it would be different from every other command in the CMakeLists.txt file in that it isn't describing the currently selected makefile.
If I were you I would just make a shell script, or a simple makefile, separate from CMake, which rebuilds each of the project files, by invoking CMake from command line with appropriate parameters.
Is the goal of the versioned CMake produced build scripts to not force developers to install CMake?
In any case: it's best to use the right tool for the right job. CMake is for producing build-files and the little scripting necessary to do so. Use a scripting environment (Bash, cmd.exe) to run CMake as necessary for all your platforms.
This keeps the CMake files clean (and readable, CMake scripting is hard to read) and provides clean separation of concerns.
i am try to do some GUI stuff and i want to setup wxWidget for visual studio 2005 on windows 7. I read may tutorial and help in last few days but all of them are showing different ways. and none of them work for me. in include c:/wxWidgets-2.9.4/include and /lib directories to visual studio but still it showing wx/setup.h not found.
can any one please give a tutorial for setup wxWidget from scratch.(from downloading required packages to full working example). because i am also confuse which one i should download, they provide many zip forders.
#tinman's recipe allows you to build eveything, but it takes a long time.
A simpler recipe, which only builds the necessary library:
Do the installation using the setup package.
Find the microsoft visual studio build folder. On my installation this is C:\wxWidgets-2.9.n\build\msw
Find the solution for your version of visual studio ( e.g. wx_vc8.sln ) and open it.
Select the configuration you intend to use when building your applications. ( e.g. DLL Release )
Build the solution.
Done. It should take about five minutes on any reasonably powerful machine.
The reason there are many zip archives is that from 2.9 onwards they are providing pre-built binary packages for each MSVC version. I have never used these so I cannot comment on those, but they might save you a lot of time building the sources and give you an official library.
I have used the MSW setup package and built from source. This is what I do and it works well for me (except I currently use wx292, VS2008 and Windows 7).
Download the wxWidgets 2.9.4 MSW setup package.
Install it. I assume it will create a directory in c:\wxWidgets-2.9.4.
Create a batch file c:\wxwidgets-2.9.4\build.bat with the following contents. You should replace myvendor with your name so it is clear that it is not an official wxWidgets library build (it will be put in the filenames, so avoid spaces).
#echo off
PUSHD build\msw
call :make
cd ..\..\samples
call :make
cd ..\demos
call :make
cd ..\utils
call :make
POPD
GOTO :EOF
#REM Perform builds with all desired configurations
:make
#REM x86 debug & release multiple DLLs Unicode
nmake -f makefile.vc MONOLITHIC=0 SHARED=1 UNICODE=1 BUILD=debug VENDOR=myvendor
nmake -f makefile.vc MONOLITHIC=0 SHARED=1 UNICODE=1 BUILD=release VENDOR=myvendor
#REM x86 debug & release multiple static libs Unicode
nmake -f makefile.vc MONOLITHIC=0 SHARED=0 UNICODE=1 BUILD=debug VENDOR=myvendor
nmake -f makefile.vc MONOLITHIC=0 SHARED=0 UNICODE=1 BUILD=release VENDOR=myvendor
Open a Visual Studio 2005 command prompt from the Start Menu. This will set up the path to your compiler and libraries correctly.
Change directory to wxWidgets: cd c:\wxWidgets-2.9.4.
Run the build.bat
It should complete after a few hours depending on your computer specifications, or you can REM out the builds for the samples, utils and demos to reduce the time (thanks #ravenspoint). You can also see the examples in c:\wxWidgets-2.9.4\samples and get the Visual Studio project settings from the sample projects to use in your own projects (for example C:\wxWidgets-2.9.4\samples\dialogs\dialogs_vc8.vcproj).
After building the library you will end up with some additional directories under C:\wxWidgets-2.9.4\lib which contains the built libraries, dlls and any build specific headers for that variant. The following directories are created from the builds in my batch script and are tagged with the toolset (vc for Visual C in this case, but could be version specific, e.g. vc80 or a fixed version depending on your build settings) and the type of library. msw in the directory and filenames means MicroSoft Windows. u in the directory and filenames means Unicode. d at the end of directory and filenames means Debug.
C:\wxWidgets-2.9.4\lib\vc_lib: Visual C (vc) Static library (lib) versions of wxWidgets
C:\wxWidgets-2.9.4\lib\vc_lib\mwsu: MicroSoft Windows Unicode specific files
C:\wxWidgets-2.9.4\lib\vc_lib\mwsud: MicroSoft Windows Unicode Debug specific files
Also contains a mixture of static libraries for release and debug
C:\wxWidgets-2.9.4\lib\vc_dll: Visual C (vc) DLL (dll) versions of wxWidgets
C:\wxWidgets-2.9.4\dll\vc_lib\mwsu: MicroSoft Windows Unicode specific files
C:\wxWidgets-2.9.4\dll\vc_lib\mwsud: MicroSoft Windows Unicode Debug specific files
Also contains a mixture of DLLs and import libraries for release and debug
In order to use the newly built libraries in your own projects you can follow these steps (I use VS2008 so some of the configuration names might be slightly different):
When you create a new project you need to go to the project properties.
Under Configuration properties -> General -> Environment add the following (so your application can find the DLLs) if you are using the DLLs:
PATH=C:\wxWidgets-2.9.4\lib\vc_dll
Under C/C++ -> General -> Additional Include Directories you need to add the wxWidgets includes in the following order:
"C:\wxWidgets-2.9.4\include\msvc"
"C:\wxWidgets-2.9.4\include"
The reason for including directory 1 first is that there is a wx\setup.h in that directory. When you include that it tries to determine what compiler, type of library (static or DLL), whether you are using Unicode or not and whether it is debug or release and it automatically includes the correct real wx/setup.h from the one of the subdirectories of C:\wxWidgets-2.9.4\lib.
You then need to go to C/C++ -> Preprocessor -> Preprocessor Definitions and add the following lines:
__WXMSW__
If you want to use the DLL version of wxWidgets instead of the static library you need to add the following line:
WXUSINGDLL
Under Linker -> General -> Additional Linker Directories you need to add the following path if you are using the static libraries:
"C:\wxWidgets-2.9.4\lib\vc_lib"
Or the following path if you are using the DLLs:
"C:\wxWidgets-2.9.4\lib\vc_dll"
In Linker -> Input -> Additional Dependancies you will probably need to add at least the following:
comctl32.lib rpcrt4.lib
And under Resources -> General -> Additional Include Directories you will need to add the following path:
C:\wxWidgets-2.9.4\include
for around 5 consecutive days i have been trying to set up my computer with the c++ environment for programming with libraries such as sdl,glm,opengl. its important for us to be able to run it on unix machines on presentations so im running with cmake.
i finally got it to work with the cmake-gui, i wont even bother trying anymore with any IDE.
i specified my folder project and where to build the binaries, i got a folder "CMakeFiles" along with a txt "CMakeCache", a CMAKE file "cmake_install.cmake" and a file "Makefile". also in my folder "CMakeFiles" there are lots of other folders such as "CMakeTmp", "CompilerIdC", "CompilerIdCXX etc" and in both folders "Compiler*" has each an .exe which doesnt work! so where is my wanted executable?
i opened cmd and navigated to my folder and tried to write "make" as we are supposed to do according to the intruction. alas, it didnt work very well. hoping you could share your wisdom and help a newbie like me!
so what exactly is needed for compiling projects containing additional libraries? so far i have a compiler, Mingw32, the latest CMake and using the cmake-gui for extracting the binaries but gets makefiles.
EDIT:
hrrm. is it only me who gets these kind of problems? i can add that i have look thorough about 10 tutorials and 90% of the steps are similar (if compiling with VS which i tried at first):
Download latest SDL
Make a folder on e.g C:\SDL with two folders, include and lib
Copy the libs and includes from the downloaded SDL
Make new VS project, open VC++ directories and add lib/incl folder on e.g C:\SDL
Add to linker SDL.lib and SDLmain.lib (i made sure they got linked, no problem here)
Change system to WINDOWS (optional if you dont want two windows)
Added include to "additional libraries"
Put the SDL.dll file (which i got from the latest SDL) in my C:\windows\system32(64SysWoW)
and also in my project file.
so what i am actually looking for is gettning the CMake to work, since it generates and builds sources successfully (with the gui) and i feel im closing in. do i need to add any additional libraries from sdl to my compiler mingw32 and/or cmake?
if you run cmake by command:
cmake -G "Visual Studio 14 Win64" path\to\source\dir
you need to run this command to continue(in Visual Studio Command Prompt):
msbuild Project.sln
either if you run cmake:
cmake -G "NMake Makefiles" path\to\source\dir
you need to run this cmd to continue(in Visual Studio Command Prompt):
nmake
You were almost there with Visual Studio. Select Visual Studio as target. Open the generated project in Visual Studio, build it. (just like you alread did). Then, instead of trying to run BUILD_ALL, run a real project that creates an executable, it should also be in that list. Just right click it and 'play' it.
If you still get errors, post them in detail including what you did before the error. Note: a carefully configured cross platform CMake project (aka the CMakeLists.txt) should not require any fiddling with VC++ directories. It should work automagically, especially with well known libs such as SDL.
If I understood it correctly you want to use CMake in your project. I'm using CMake in all my projects. I won't give you exact step-by-step howto, since I use Arch Linux but I used it in Windows 7 too.
To make CMake find the libraries, it is often needed to set up the CMAKE_PREFIX_PATH environment variable so it points to the directories where dependencies of your project are installed.
Set you PATH environment varible so you can invoke you compiler and make just by calling by calling eg. make. I think you need to do than manually for Mingw32, for Visual Studio you can use the "Visual Studio Command Propt" which has these variables already set.
Run CMake with desired generator. To select the generator from command line use the -G switch. You will probably use one of the following (the ... means other options you want to pass to cmake)
For GNU make used in MinGW use cmake -G "MinGW Makefiles" ...
For NMake from visual studio use cmake -G "NMake Makefiles" ...
It is also possible to create a Visual Studio project but I do not recommend it, since it quite difficult to set up automatic builds then. I also had some problems with dependencies when I tried to use VS project.
change directory to your build directory (ie. the one where you called cmake, it contains the CMakeCache file) and run make or nmake
Quoting from "CMake support in Visual Studio":
Visual Studio 2017 introduces built-in support for handling CMake projects. This makes it a lot simpler to develop C++ projects built with CMake without the need to generate VS projects and solutions from the command line. This post gives you an overview of the CMake support, how to easily get started and stay productive in Visual Studio.
I'm using CMake version 2.8 on WinXP SP3. Whenever i run my CMakeLists script by default CMake use Visual Studio 10 compiler. I've tried to do:
SET( CMAKE_CXX_COMPILER "C:/MinGW/bin/g++" )
without success. How can i set MinGW as my default compiler so that i do not have to worry about setting compiler in the CMakeLists?
CMake 3.15 or later supports overriding the default generator by setting the environment variable CMAKE_GENERATOR.
E.g., using PowerShell, set the environment variable in the following way to make MinGW the default generator:
$Env:CMAKE_GENERATOR = 'MinGW Makefiles'
For older CMake versions (< 3.15), CMake uses the newest Visual Studio installation as default generator, unless the generator is explicitly specified upon invoking CMake. This behavior is hard coded and cannot be changed.
As a work-around you can use a batch wrapper script titled cmake.cmd with the following contents:
#cmake.exe -G "MinGW Makefiles" %*
The script should be placed in a directory on the system PATH and should take precedence over the CMake executable cmake.exe.
The script invokes cmake.exe with MinGW as a generator and forwards all other parameters to it.
You only have to set the toolchain/output format once, typically you'd do this upon running cmake for the first time:
cmake -G "MinGW Makefiles" .
Instead of the dot you can use your own parameters (if any) and/or the path to the source.
As an alternative, especially when you're new to CMake, use the GUI version under windows (run cmake-gui without parameters instead of cmake).
Once opened, set your paths and click on "Configure". If there's no compiler set, it will ask you to pick one (otherwise you have to clear the cache to make it reappear).
Updated configuration values will appear in red and it will also allow you to select files and paths using the common Windows dialog boxes.
Once configuration is complete and without errors you can hit "generate" to create your makefiles or project files. To update these later on, you can use cmake-gui again or just use the usual command line version cmake.
With CMake version 3.15 or later, you can set the CMAKE_GENERATOR environment variable to specify the default generator to be used on your system.