Suppose I've got a cross-platform C++ library, let's call it ylib. My primary development platform is Linux. I'd like ylib to be buildable by MSVC (2008, 2010, 11, etc).
What's the best way to do this? Do I generate .vcproj files? If so, how? Ideally I'd be able to generate them without using Windows myself. No extra dependencies should be required for Windows.
Multiple variants should be build: debug dll, debug lib, release dll, release lib with dynamic runtime and release lib with static runtime.
You could use cmake for your build scripts. Cmake has the ability to generate visual studio project files from the cmake build scripts. So you'd just need to distribute your cmake files, then individual people using windows could generate MSVC project files from that.
Though as pointed out in the comments, it'd be difficult to guarantee that you could actually build your project under visual studio without trying it out yourself.
EDIT: Though I've just realized that you requested no extra dependencies on linux, which this would not solve. Unless you generated the vcproj files yourself using cmake, and distributed them. But personally I think it'd be better to just have the cmake dependency. It's freely available, and easy to install.
This also has the advantage of supporting whatever version of visual studio your end user happens to have, without the need for distributing several different formats.
You just need to understand the format of vcproj files and then write them - they are simply XML.
I don't know how well MSFT document the settings (not very if history is a guide) - so for simple projects I would just create a project in MSVC and look at what it writes.
Alternatively you could just use cmake which already does this.
Related
The problem:
I'm writing an SDK that is primarily C++. The source code will be licensed to developers who pay for it, and the output libraries and include headers will be free for public usage. The SDK will target a plethora of platforms including Windows, Xbox, Playstation, Android, iOS, Mac OS X, and Linux. I'm a kind of guy who mostly likes Visual Studio and usually develops software using Windows machines. In the last few years, Visual Studio has made this quite a lot easier than it used to, where I have a mostly clear path to target all the previously mentioned platforms using a Visual Studio set of project files as the source of truth that brings all my source code files together... except for Mac OS X, unfortunately. Visual Studio is able to build executable code for iOS and Linux by remotely interfacing with a Mac or Linux box respectively for compilation and debugging, which is really quite cool, but for some reason Mac OS X as a target is left out here. Additionally I'm well aware that there are plenty of other professional developers out there that don't write code on Windows machines, nor do they have any interest in buying a commercial license for Visual Studio.
The question:
Since C++ still does not yet have a build system standard, and may not ever, how do I maintain a single source of truth that maintains the build configurations for all my source files targeting so many different platforms while simultaneously minimizing the barrier to entry of supporting software developer clients who need to build, run, and debug my source code?
Possible answers I'm aware of:
A) Visual Studio projects remain the source of truth from which any other C++ project types (such as Android Studio, XCode, and .make files) are derived. I'm aware of tools that can convert VS to .make and the like, but haven't actually tried them yet (my source code base is starting to get somewhat large already). Or I could just bite the bullet and write them by hand and try to keep them all in sync.
B) CMake. Sigh. So frustrating that it's very popular, and seems to exactly solve my issues, but it has its own set of problems that seem to be deal-breakers. For starters, once you go in on CMake, you pretty much can't come back. Using Visual Studio and property sheets, I've been able to tweak my build configurations with properties that are mostly inherited and rarely duplicated across projects and configurations. As far as I can see, CMake doesn't care about respecting such things, and for common properties, it just duplicates them on all vcxproj files. To make matters worse, all file paths it generates in the output projects are absolute, not relative, and to top it all off, it forces anyone else who builds your code to use CMake, disallowing distribution of the project build files it creates without it. Also, does this even work for game consoles? Last I checked I couldn't find a reasonable way of supporting them without hacking the source code.
C) Roll my own script that's similar to CMake, but allows redistribution of its output projects, and supports all the platforms I need. It goes without saying that this would consume a lot of dev time.
Any other options I'm missing here? Your input is greatly appreciated.
I agree with the comments from #Scheff and #arrowd. Use CMake. I have built and deployed software to multiple platforms and CMake is the best, though not perfect, solution I have found for building C++ code.
I have not had to hack the cmake code to get it to work on various platforms.
Do not worry about properties being duplicated in vcxproj files. With CMake the build language is in the CMakeLists.txt file(s). The vcxproj files are generated code. As long as you are do not have redundant cmake logic, you should not care about replicated properties in the generated vcxproj files. Similarly, you should not care that the generated vcxproj files have absolute paths; you do not reuse the vcxproj files you reuse the CMakeLists.txt files and regenerate vcxproj files for each new platform or build.
Use the top-level CMakeLists.txt to define the properties that are common to all targets. Then in individual target(s) CMakeLists.txt files use target properties to tweak builds of specific targets. In my experience the replication of properties in the generated files helps because they make the builds more consistent; I am able to minimize replication in the source CMake logic.
Various IDEs (VS 2017, CLion, QtCreator) can use cmake based projects directly.
There is nothing cmake specific about the generated artifacts. The headers, libraries (and dlls), and executables of our SDK are standalone artifacts. Yes, cmake can make it easier for your SDK users but using CMake in your SDK will not force your customers to use CMake.
Have you tried CMake and not been able to use it? Or are you looking for something better? There are certainly multiple C++ build systems, but despite its shortcomings I believe CMake is the best one available right now.
I was always using Windows, have very limited Linux experience.
My Visual Studio solution contains 5 C++ projects - 4 of them are static libs, and one is main application (that use these static libs), I want to move it to Ubuntu.
I do not use any windows specific code, so with minor changes I should be abble to compile under Linux.
How to do this? What exactly software should I use under Linux? What should I do with static libs, should I keep using static libs in Linux? How to convert Visual Studio solution to something Linux-like?
upd what if I just download Eclipse in Linux and then file by file, project by project, recreate and copy everything from VC++ to Eclipse? this should work, isn't it? I have just 100-200 files so it's possible to do this by hand.
I can think of two reasonable options. The first one is to create a makefile that will compile everything for you. There was once a utility called Make It So that did this automatically. Their page specifies compatibility with Visual Studio 2010, it might work with Visual Studio 2012 as well.
You can also use cmake. It's a bit more involving to get right, but the end result will be the ability to compile your code more or less anywhere.
Use xbuild? So if you install Mono, then you have xbuild which is the OSS version of msbuild. You can just build your .sln file by something like "xbuild solution.sln"
Clion can generate cmake file automatically for .sln project under linux.
If your code is not dependant on any Window specific library then you can use make the utility to make any lib, bin.
You can also provide different rules to link your library based on your specific requirement. You can also link third party library using Make utility.
i have source code of vc++ project. Now I am using linux.
i know how compile a single file .cpp not a whole project. So how to compile a VC project using g++ ?
A slight advantage of Makefiles would be possible integration with autotools (cough - It might prove handy to get the starting point for feature macros).[2]
There is a tool as part of winemaker that is EXCEEDINGLY helpful with fixing up a source tree that was assuming case insensitive names to work on a case-sensitive filesystem. (_it was intended mainly in order to build against winelib but that is not required)
If you want to keep using windows API's for some parts of the code, you can consider compiling with winelib (and use winegcc, producing WIN32 executables; I'm not sure whether this is what you want)
[2]: SCons is a very nice tool though
First step would be to generate Makefile out of vcproj file.
There are (obviously) some tools for that:
http://www.codeproject.com/KB/cross-platform/sln2mak.aspx
There is no easy way to do it. As others have suggested you can figure out how the build process works for this project (maybe by reading the build output in VS) and recreate that using your favorite linux build tool (scons, cmake, autotools etc.). The alternative is to use a converter tool. Aside from the below mentioned sln2mak, there is also winemaker. The docs for winemaker have a lot of old info like most linux tools docs but it can convert a .sln to a makefile. I am not sure about newer vs .sln files.
I have checked in buid directory and have not found makefile there. How does Visual Studio 2008 buid the project? Does it use makefile?
The NMAKE utility has been distributed with Visual C++ since back when it was called Microsoft C/C++ Optimizing Compiler, and is very similar to Unix make. Previous versions of the IDE actually used NMAKE makefiles, but this isn't true anymore. You can write NMAKE makefiles yourself if you want, but it sounds like you want to know what the IDE does.
Starting with VS2010, the build system changes to MSBUILD, which bertelmonster mentioned. But not in VS2008.
In VC++ 6.0, C++ projects have their own build engine integrated into msdev.exe.
In VS2002 - VS2008, it's a separate tool, VCBUILD. But you can still invoke it via the main IDE, devenv.exe, see the /BUILD option, and devenv is the best way if you have inter-project dependencies in your solution.
VS9 doesn't use makefiles by default the way Linux-flavored IDEs might. Instead, VisualStudio uses 'solution' and 'project' files. A Project file (*.vcproj for C/C++ projects) is basically a replacement for makefiles, and contains instructions, compiler directives, flags and everything else needed to compile a single 'project'. In this parlance, a project is a single output file, such as an EXE or DLL. But this same mechanism can be used to produce any kind of output, including TLBs, text files, widgets and ice cream cones (if your machine has the capable hardware :) )
A 'solution' is a collection of projects, and the solution file (*.sln) contains lists of projects needed to build an entire application suite, typically. It also contains dependancy information, so that the projects are built in the correct orders.
Solution and project files are human-readable text, but in the VS world you would virtually never want to edit these files yourself the way you would tweak a makefile by hand. Instead, you would use the IDE to change compiler flags, preprocessor directives, output directories, and all the rest.
That is how VS works by default, but VS is also capable of using makefiles in much the same way as Linux-flavored IDEs. It still uses solution files in this case, so you can mix projects that use makefiles with projects that use project files within the same solution. The VS IDE is actually quite powerful in this regard, and gives you the ability to do pretty much whatever you want. This power however comes with a price -- with so many features and capabilities available in the IDE, it can be rather complex and takes what you might think is an unwarranted ammount of user brainpower to fully understand.
If you want to create a makefile project, you can do so by doing File>New>Project... and then selecting Makefile Project from the main Visual C++ list of project templates.
I want to get started using Boost. I'm programming a C++ program in Visual Studio (obviously on a Windows machine).
Boost's Getting Started Guide says:
The easiest way to get a copy of Boost is to use an installer. The Boost website version of this Getting Started guide will have undated information on installers as they become available, or see Boost downloads or the installer provided by BoostPro Computing. We especially recommend using an installer if you use Microsoft Visual Studio, because the installer can download and install precompiled library binaries, saving you the trouble of building them yourself.
I'm a little unsure if I want to follow this advice, or just download and build everything myself. Potential problems that I see with an installer are:
Things are no longer self-contained (i.e. every team member has to install Boost, then configure Visual Studio to recognize it).
I can't keep Boost under source control (I would ideally like it to be soure files in my source control like everything else). (Edit: Judging by the comments, it looks like boost is kinda large (as in 5 GB!), so obviously I'd need to keep only parts of it under source control).
So my question is, am I just being paranoid and should go the installer route, or am I correct and should build it myself? If anyone has any experience working with Boost and Visual Studio, I'd appreciate if they could share their views on this (and if it should be to build it myself, any tips would also be appreciated, for example should I only copy every file that I actually use? etc.).
Note:
A few similar questions on StackOverflow, but which didn't ask this explicitly, make me think that I shouldn't use the installer, which is why I'm asking it explicitly here. For reference, these are the questions:
Boost linking, Visual Studio & version control
Including Relevant Boost Libraries with C++ Source (Using Visual Studio)
A good way to make sure everyone has everything configured properly is to use svn externals. You can create something like /trunk/boost1.35 and then you can point to that with an svn external.
That way as new versions of boost come out, you can just repoint your svn external to /trunk/boost1.40
In your repository, your svn external points to that svn folder within your repository. Example /depends/boost
We personally keep the boost header files under source control as described but keep the libs as a zip that we require everyone to download. We have an environment variable something like the following BOOST_LIB and we point that to the current boost library directory.
I recommend using the installer.
Building it yourself is not hard. Here is the procedure:
Download boost into C:\Program Files\boost\boost_1_40_0
Open the command prompt and change your current directory to the Boost root directory
bootstrap
.\bjam
The library binaries are now sprinkled through the folders under
C:\Program Files\boost\boost_1_40_0\bin.v2
Find the required libraries and copy them to
C:\Program Files\boost\boost_1_40_0\lib
( Do not confuse folders called lib and libs! )
However, this is slow enough and just complicated enough, especially the last step, that you and everyone else will probably screw something up once in a while, resulting in a waste of many hours sorting out mysterious build errors - this is my experience anyway.
I have built Boost under Windows. Its "bjam" installation tool auto-detects MSVC and uses it for compiling; I wouldn't have any reservations against building yourself. It's only marginally more difficult than "./configure && make && make install", really.
Building yourself could even be necessary, because the Boost libs available online do not include ICU (Unicode) support, e.g. for the boost_regex lib.
Things are no longer self-contained (i.e. every team member has to install Boost, then configure Visual Studio to recognize it).
I can't keep Boost under source control (I would ideally like it to be soure files in my source control like everything else).
Before you put Boost under source control, keep in mind that the compiled libraries take up several gigabytes. (my Boost folder is around 5GB) It might be worth just letting everyone install Boost for themselves.
Apart from this, the installer should work fine, but compiling it yourself is really trivial as well.
Boost installs into version-specific folders by default (both if you compile it yourself and if you use the installer), so it's easy enough to have multiple versions installed side by side. So if your team upgrades Boost to a new version, you could simply change the include path in the .sln or .vsprops files to make the compiler search for the new version -- if a coworker hasn't installed the right version, he just won't be able to build (which might be preferable to silently building with an old version)
One other thing to consider is whether you need all or part of boost. What we do here is put the source in version control and create a single wrapper project for the libraries that we actually want to use. The individual libraries are written cleanly enough to make it a matter of just dropping all the cpp files into a new visual studio project. You might need to set up the top level configuration header (I think I set this as a forced include) and the whole thing built very easily. Add this project as a dependency in your solution and it means you can keep all the binaries out of the SCM and also ensure that everyone is always up-to-date.
Much of boost is headers-only anyway so you may find that there's only a handful of libraries that you'd want to build. This approach makes it easier for you to match your VS project settings too.
We actually create our own installer, with just the parts of Boost that we use in our jobs, and give that out to the IT folks to install on developer machines. We also keep that copy of boost in revision control, so we can track dependencies between it and the rest of our system properly, and build it ourselves.
I suppose work-wise this is the worst of both worlds. But it does give us the maximum control.
Several points NOT to keep it under source control:
Boost is huge.
Compilation is non-trivial (esp. for several configurations)
Compilation is long (you don't want every developer to do it)
I personally would not bother building it myself - on Linux, for instance I always use the distribution provided package.
I'd use the installer, unless you need to customize the build flags. It's much easier, and building boost (at least the last time I did it) wasn't the clearest process. There's nothing stopping you from downloading the source that matches the version of boost that the installer gives you, and putting that in version control. This is the approach I've used in the past for other libraries (nss, iplanet sdk) and it's worked well.
I would recommend to run bootstrap.bat first - it will build bjam.exe and then
bjam --stagedir="c:\Program Files\Boost" --build-type=complete --toolset=msvc-9.0 --with-regex --with-date_time --with-thread --with-signals --with-system --with-filesystem --with-program_options stage
bjam --stagedir="c:\Program Files\Boost" --build-type=complete --toolset=msvc-10.0 --with-regex --with-date_time --with-thread --with-signals --with-system --with-filesystem --with-program_options stage
..
You just need to specify the correct toolset. It will put all binaries to the ..\lib folder.
I'd say, just make Boost installation as prerequisite for your project. The manual installation takes just few minutes with one-time small number of steps. Most large size complex project, eventually end up taking up dependency on Boost so its not unusual to make it prerequisite. Of course, it's trivial to automate it. The advantages are:
You don't add giant Boost distribution in your repo
You don't have to cherry-pick what you use
Other projects can share the installation
One-time setup also takes care of building header+cpp libraries
For Visual Studio 2015 and latest Boost version, here are the step-by-step instructions we follow for our team:
https://stackoverflow.com/a/39628306/207661