I want to build many c++ projects in Windows 7,
however building them one by one seems fantastic.
Then, I thought to write NMAKE file manually and run some script,
but it seems also troublesome because I have to write many NMAKE files.
So I want to know is it possible to generate NMAKE file automatically from Visual Studio 2010.
Starting with Visual Studio 2002, there is no longer a way to export your VC++ project files to a Makefile. (That option existed up until VC++ 6.0 but was removed.)
As of VS 2010, the build process for VC++ projects is the same as any other projects: there is a solution file and a set of project files, both of which are recognized by MSBuild as inputs. MSBuild take care of the dependency resolution, build ordering, etc.
The only significant feature that you lose building inside the IDE is parallel builds. If that's your concern, you can run the msbuild command on your solution file and pass in the /m parameter to specify how many simultaneous builds it should attempt.
As far as I know, no one has built any kind of tool or plug-in to parse the .vcxproj files and spit out a makefile, though the file format is pretty well documented XML, so you could always write one yourself. Otherwise, if you really need makefiles for some reason, you'll have to craft them by hand.
You can use MSBuild to build a Visual Studio solution or project from the command line.
Convert it to CMake https://stackoverflow.com/a/9387350/525578
Generate using NMake or Jom generator of the CMake
Related
I have a project which is just C99 code built from a powershell build script. I call clang.exe and pass the compiler flags and input files manually.
I would like to know what is the best and simplest way to handle Windows specific dependencies such as user32.lib and kernel32.lib. For now I just put them all in a folder that I include in the project to make sure that they are present and the build succeeds. The problem with that approach is that they are big files and I would prefer to point the compiler to the libraries already on the system.
I don't want to require the user to have visual studio installed, but of course they need to have the windows sdk installed.
TL;DR: what is the best way to handle external dependencies in C++ Visual Studio projects in the context of source control? Ideally I want other people/devices to be able to just clone my repository, open the .sln file with Visual Studio 2019 and press F5 to compile without having to modify the compilation links for external libraries etc. each time a new clone is made.
I want to use an external library (GLFW, https://github.com/glfw/glfw) in a C++ Project in a Visual Studio 2019 Solution, and I want the project to be easily sharable via Git, both for other devices and other people.
There seems to be a few different approaches to handling this:
Download the binaries and simply store them in my external/glfw folder. This makes linking and including easy. The downside is that this requires manual updates and I would prefer to not redistribute someone else's binaries.
Use Git submodules/subtree to include the glfw source code in my external/glfw folder. My problem here is that I don't know of an easy way to compile the glfw source code as part of my Visual Studio build process since glfw uses CMake, and it doesn't seem to be possible to add a CMake project to a Visual Studio Solution unless the entire solution uses CMake which I want to avoid.
Make a separate repository just for compiling the external libraries. This repository would exist merely to compile external libraries, and the main repository would then use git submodules/subtree to fetch the appropriate binaries/libraries into external/glfw. The problem with this approach is that the overhead of managing a separate repository just for the purpose of compiling external libraries seems excessive.
Approach 2 holds the most appeal as it is simple yet flexible, however, I have been unable to make it work in Visual Studio since I can't seem to add a CMake Project to an existing solution. Is there a way to compile external CMake projects when needed, and have that script automatically execute when I press F5 in Visual Studio?
I'd suggest what you seem to have partially deduced. Instead of using your existing Visual Studio project/solution directly, convert your build to CMake and use a submodule.
Converting basically entails writing a CMakeLists.txt file with your build instructions, and you'll have one line in there that makes it traverse into the submodule. When you run CMake, it'll configure your code as well as the submodule, and generate a Visual Studio project that compiles and links both.
Added bonus is your code will be one step closer to being cross-platform too, since CMake will just as easily generate build systems for Mac, WSL, Linux, etc.
I work with the same Visual Studio projects on multiple computers (work/home) using Dropbox to sync between the two. Because VS creates some extra large files, I used to remove the following before uploading to Dropbox:
Files = .pdb, sdf, .ilk .exe .tmp
Folders = ipch/, Release/, Debug/, GeneratedFiles/
Everything worked fine in the past, however, some problems have now risen.
I receive the following errors:
Moc'ing CodeInterface.h...
1> The system cannot find the path specified.
1> Moc'ing ThreadWorker.h...
1> The system cannot find the path specified.
1> Rcc'ing StreamAnalyser.qrc...
1> The system cannot find the path specified.
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 3.
So, I think I may have to create a new Visual Studio project and import the classes manually. So my question are:
Best practices for working with projects on different computers?
What files can be deleted (for uploading to Dropbox)?
Does Visual Studio have some sort of 'global settings' (or something similar to 'workspace' used with Eclipse)? How do I set these settings to prevent trouble when working on different computers?
Thanks!
I am not familiar with dropbox so I can't speak for what you do currently
What I like to do is to use a distributed versioning system (I use git) to look after the source code only. I use a .gitignore file to not version any object code and visual studio project files and the like. I can then clone these projects (with their versioning) easily across to any computer I like - including test branches that I might idly play with when coming home on the train on my laptop.
In my experience visual studio project files are a pain because different versions do not play nicely with eachother (1 computer has vs2005 and another has vs2008). To overcome this problem I like to use cmake as my build system (I include these in my git repository too). Cmake is a 'meta-build system', in that it generates the visual studio, or eclipse, or autotools make files for you, and then you do the native build in VS or Eclipse or with make.
Using these two packages together means that you can copy properly versioned controlled source code between any computer (including linux, mac and windows) and then build the source code natively on that computer, using whatever IDE you have installed on that computer.
"moc" is a Qt executable that pre-processes .h files. It's invoked by the MSVS build system. However, if it would be missing, you'd get the "The system cannot find the path specified." error after "Moc'ing CodeInterface.h".
My bet therefore is that MSVS can't find your Qt implementation. I'm not entirely surprised; the Qt4 build system and its integration with MSVS didn't strike me as very robust ir reliable when I tried to install it recently.
I would recomend you use svn with anksvn. Subversion is built to manage working on diffrent computers and has the added bonus of version controll.
In your case, you may delete files but not directories, i.e. GeneratedFiles\Debug and \Release should stay. If you look onto your h files, they do moc-ing and uic-ing as custom build step, and there is no path checking code in that events.
"$(QTDIR)\bin\moc.exe" -DQT_NO_QT_INCLUDE_WARN -DUNICODE -DWIN32 -DQT_THREAD_SUPPORT -DQT_CORE_LIB -DQT_NETWORK_LIB -DJSBRIDGEAPI_LIB -D_WINDLL -I".\GeneratedFiles\." -I"$(QTDIR)\include\." -I".\GeneratedFiles\$(ConfigurationName)\." -I".\." -I"$(QTDIR)\include\QtCore\." -I"$(QTDIR)\include\QtNetwork\." -I"$(QTDIR)\include\QtWebKit\." ".\apisignalemitter.h" -o ".\GeneratedFiles\$(ConfigurationName)\moc_apisignalemitter.cpp"
So - adding dirs .\GeneratedFiles\$(ConfigurationName)\ may solve your problem.
Also, check if $(QTDIR) defined.
UPD - make sure you have QT installed on both machines in some place
I'm usually using SVN for version control and a qmake pro file for project settings. You can use qmake to create a Visual Studio project file from the pro file and work with Visual Studio, or create Makefiles and other project files on Windows, Linux and Mac, so it's a quite portable solution.
I'm working on a little game called freegemas, it's an open source version of the classic Bejeweled written in C++ and using gosu as the graphic API. I've been developing it under Ubuntu Linux as usual, but the other day I wanted to give it a try and I compiled it on Windows using Visual Studio 2005 (which I had never used before). The program worked flawlessly.
To compile it on Windows I manually copied all the source and header files to a new project on MSVC, but I would like to adapt the SVN so I don't have to recreate the project every time I want to compile it.
Therefore, the question would be: What's the best way of organizing the svn so I can have, on the one hand, a Makefile to compile the project in Linux, and, on the other side, the MSVC project's files? Right now I've got a simple folder called trunk with all header, source and resource files on it.
I've never used Visual Studio before, so I don't know which files are the most important either. Maybe some of those files are auto-generated and do not need to be svn-versioned.
Thanks in advance.
You could just keep the project files in a seperate directory "winbuild" or similar. Still, to maintain them would require manual interaction (ie adding every new file manually). The only files you would need to upload to svn are the *.vcproj (for MSVC 2005/2008) and *.vcxproj (MSVC 2010).
Alternatively, you could opt for a cross-platform solution like CMake, which could generate makefiles and Visual Studio project files from a common CMakeLists.txt, which is the only "project file" that would have to be maintained (instead of your makefile). Especially for a simple (?) project like yours (some headers+sources). There would be no need to include any makefiles or vcproj files at all, just the CMakelists.txt file would suffice.
There are others like CMake (SCons, boost.jam, jam, premake, etc.)
It should be feasable, but requires some testing and trial-and-error.
I heard a lot about makefiles and how they simplify the compilation process. I'm using VS2008. Can somebody please suggest some online references or books where I can find out more about how to deal with them?
The Microsoft Program Maintenance Utility (NMAKE.EXE) is a tool that builds projects based on commands contained in a description file.
NMAKE Reference
A UNIX guy probably told you that. :)
You can use makefiles in VS, but when you do it bypasses all the built-in functionality in MSVC's IDE. Makefiles are basically the reinterpret_cast of the builder. IMO the simplest thing is just to use Solutions.
To answer the specific questions...
I'm using VS2008. Can somebody please suggest some online references
or books where I can find out more about how to deal with them?
This link will give you a good introduction into Makefiles by mapping it with Visual Studio.
Introduction to Makefiles for Visual Studio developers
I heard a lot about makefiles and how they simplify the compilation
process.
Makefiles are powerful and flexible but may not be the best solution to simplify the process. Consider CMake which abstracts the build process well which is explained in this link.
CMake for Visual Studio Developers
I actually use a makefile to build any dependencies needed before invoking devenv to build a particular project as in the following:
debug: coratools_debug
devenv coralib.vcproj /build debug
coratools_debug: nothing
cd ../coratools
nmake debug
cd $(MAKEDIR)
You can also use the msbuild tool to do the same thing:
debug: coratools_debug
msbuild coralib.vcxproj /p:Configuration=debug
coratools_debug: nothing
cd ../coratools
nmake debug
cd $(MAKEDIR)
In my opinion, this is much easier than trying to figure out the overly complicated visual studio project management scheme.
The VS equivalent of a makefile is a "Solution" (over-simplified, I know).
To summarize with a complete solution...
There are 2 options:
Use NMAKE from the Developer Command Prompt for Visual Studio
The shortcut exists in your Start Menu. Look inside the makefile to see if there are any 'setup' actions. Actions appear as the first word before a colon. Typically, all good makefiles have an "all" action so you can type: NMAKE all
Create a Solution and Project Files for each binary.
Most well designed open source solutions provide a makefile with a setup action to generate Visual Studio Project Files for you so look for those first in your Makefile.
Otherwise you need to drag and drop each file or group of files and folders into each New Project you create within Visual Studio.
Hope this helps.
Makefiles and build files are about automating your build. If you use a script like MSBuild or NAnt, you can build your project or solution directly from command line. This in turn makes it possible to automate the build, have it run by a build server.
Besides building your solution it is typical that a build script includes task to run unit tests, report code coverage and complexity and more.
If you are asking about actual command line makefiles then you can export a makefile, or you can call MSBuild on a solution file from the command line. What exactly do you want to do with the makefile?
You can do a search on SO for MSBuild for more details.