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.
Related
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.
Let's assume my program needs several DLL's to work. I should provide that DLLs to the user in my distribution. For now I need QtCore4.DLL, QtGui4.DLL, msvcp90.DLL, msvcr90.DLL, mylib.DLL, Kernel32.DLL...
Would be nice if CMake could get full list of DLLs (or .SO) files. Then I would remove items like "Kernel32.DLL" from that list and copy the DLLs to my distribution.
I can't guarantee the next build will be done on the same version of the Visual Studio, so hard-coding paths like "C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT" or "E:\Qt\4.6.3" is not good for searching for the DLLs.
Thank you!
You can use Dependency Walker on windows (or the cmd-line dumpbin tool from visual studio). However this is not really a CMake solution and there is not really standard solution with Cmake.
There is, however, the InstallRequiredSystemLibraries module, which you can use to get the system dlls (msvc[r|p]90.dll with msvc and mingw10.dll with mingw).
As suggested by Andre there is InstallRequiredSystemLibraries for finding/installing the correct C/C++ runtime. There is also BundleUtilities that can be used to find the other dependencies of your application, library and/or plugins.
It can never pick things up like runtime loaded plugins, but you can add them along with the library directories that should be used. In the most recent versions of CMake quite a few improvements have been made to make BundleUtilities more reliable on all platforms.
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'm facing this problem. So, I need to build the support libraries (zlib, libtiff, libpng, libxml2, libiconv) with "Multithreaded DLL" (/MD) & "Multithreaded DLL Debug" (/MDd) run-time options. But the problem is there is no direct way . I mean there is no *.sln / *.vcproj file which I can open in Visual C++ and build it.
I'm aware with the GNU build system:
$./configure --with-all-sorts-of-required-switches
$./make
$./make install
During my search I've encountered with something called CMake which generates *.vcproj & *.sln file but for that CMakeLists.txt is required. Not all projects provide CMakeLists.txt.
I've never compiled anything from Visual C++ Command Line.
Generally most projects provide makefile. Now how do I generate *.vcproj / *.sln from this?
Can I compile with mingw-make of MinGW?
If I can, how do I set different options ("Multi-Threaded"(/MT), "Multi-Threaded Debug"(/MTd), "Multi-Threaded DLL"(/MD), "Multi-Threaded DLL Debug"(/MDd)) for run-time libraries?
I don't know what other ways are available. Please throw some light on this.
I believe all those projects include a .vcproj file (open/build in VC) and/or VC makefile (build with nmake).
You can just create a new project in Visual Studio and add the existing .cpp files to it.
Note that for several of the GNU libraries you've mentioned, you might have difficulty getting them to build on Microsoft Visual Studio's compiler, because as far as I know they are not shy about using GCC extensions in such programs.
Most projects work, when you create an empty Win32 project and drag all files into that.
Then change the output paths and maybe click throught several options.
You can create wrapper scripts for the compiler+linker to call the VC compiler and give them to configure by ./configure CC=my-visual-c-script CXX=my-visual-c++-script. I hacked the compile script distributed with automake to do this thing. Note that automake calls the compiler also to link, so the wrapper must decide if it must call the compiler or the linker.