To get from C++ sourcecode to a binary module, the process is roughly as follows:
set_of_source_files[a.cpp, b.cpp, ...] // conceptually, it doesn't matter where these are
||
|| Compiler <- [compiler_settings]
\/
set_of_object_files
||
|| Linker <- [linker_settings]
\/
binary module (dynamic library or executable)
Now, I know Visual Studio projects, they
Define a set of source files (directory structure and layout basically doesn't matter / is defined inside the project file)
Define the compiler settings for all (optionally each) of the source files
Define the linker settings
Define where to put generated output files
I don't know cmake, but apparently(?), the info one configures with cmake differs slightly from the info one puts into vc[x]proj files.
Is a "cmake configuration" just a differently formatted "vcproj file" or is there a conceptual difference? (Except for the obvious one (I assume) that the info I put into a cmake configuration is platform independent.)
An alternative twist to this question would be to answer -- in the context of above -- why/if(?) one would switch to cmake when only compiling for Windows with Visual-C++.
Cmake is a cross-platform make -- it starts from a set of source files and a relatively abstract set of directions about what to do with them. Based on those, it generates a set of platform-specific files. If you specify Windows/Visual Studio as the target, it can/will generate a vx[x]proj file for you to use.
Even if you're only using Visual C++ on Windows, it's possible you could benefit from cmake. The obvious possibility would be if you want to target a number of different versions of Visual Studio, and be able to directly generate the correct files for each, instead of generating files for the oldest version you want to support, and then depend on Visual Studio's upgrade feature to convert those to the target version.
Based on my experience with VS's upgrade capability (not particularly great), I'd say that could/would be a reasonable and valid use.
Related
I've defined a CMakeLists.txt file for my project which works correctly.
I use the CMake GUI for generating a Visual Studio Project, and I ask to build the binaries (CMAke cache and other stuff) in the folder Build which is in the same folder where CMakeLists.txt is.
I was able to specify where the executable and the libraries have to be created.
Is there a way to specify also where the Visual Studio Solution file has to be created? I would like to have it in the root directory, but at the same time I don't want to have also all the other files that CMake creates in the Build directory.
CMake creates the Project I defined in CMakeLists.txt but also two other projects: ALL_BUILD and ZERO_CHECK. What's their utility?
I was able to avoid the creation of ZERO_CHECK by using the command set_property(GLOBAL PROPERTY USE_FOLDERS On).
Is there a way for avoiding also the creation of ALL_BUILD?
It seems you only switched to CMake very recently, as exactly those questions also popped into my head when I first started using CMake. Let's address them in the order you posted them:
I use the CMake GUI for generating a Visual Studio Project, and I ask
to build the binaries (CMAke cache and other stuff) in the folder
Build which is in the same folder where CMakeLists.txt is.
Don't. Always do an out-of-source build with CMake. I know, it feels weird when you do it the first time, but trust me: Once you get used to it, you'll never want to go back.
Besides the fact that using source control becomes so much more convenient when code and build files are properly separated, this also allows to build separate distinct build configurations from the same source tree at the same time.
Is there a way to specify also where the Visual Studio Solution file has to be created?
You really shouldn't care.
I see why you do feel that you need full control over how the solution and project files get created, but you really don't. Simply specify the target for the solution as the origin of your out-of-source build and forget about all the other files that are generated. You don't need to worry, and you don't want to worry - this is exactly the kind of stuff that CMake is supposed to take care of for you.
Ask yourself: What would you gain if you could handpick the location of every project file? Nothing, because chances are, you will never touch them anyways. CMake is your sole master now...
CMake creates the Project I defined in CMakeLists.txt but also two
other projects: ALL_BUILD and ZERO_CHECK. What's their utility? I was
able to avoid the creation of ZERO_CHECK by using the command
set_property(GLOBAL PROPERTY USE_FOLDERS On). Is there a way for
avoiding also the creation of ALL_BUILD?
Again, you really shouldn't care. CMake defines a couple of dummy projects which are very useful for certain internal voodoo that you don't want to worry about. They look weird at first, but you'll get used to their sight faster than you think. Just don't try to throw them out, as it won't work properly.
If their sight really annoys you that much, consider moving them to a folder inside the solution so that you don't have to look at them all the time.
Bottom line: CMake feels different than a handcrafted VS solution in a couple of ways. This takes some getting used to, but is ultimately a much less painful experience than one might fear.
You don't always have a choice about what your environment requires. Visual Studio's GitHub integration requires that the solution file exists in source control and is at the root of the source tree. It's a documented limitation.
The best I was able to come up with is adding this bit to CMakeList.txt:
# The solution file isn't generated until after this script finishes,
# which means that:
# - it might not exist (if this is the first run)
# - you need to run cmake twice to ensure any new solution was copied
set(sln_binpath ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.sln)
if(EXISTS ${sln_binpath})
# Load solution file from bin-dir and change the relative references to
# project files so that the in memory copy is as if it had been built in
# the source dir.
file(RELATIVE_PATH prefix
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR})
file(READ ${sln_binpath} sln_content)
string(REGEX REPLACE
"\"([^\"]+).vcxproj\""
"\"${prefix}/\\1.vcxproj\""
sln_content
"${sln_content}")
# Compare the updated contents with the existing source path sln, if it
# exists and is the same we don't want to disturb VS by touching it.
set(sln_srcpath ${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.sln)
set(old_content "")
if(EXISTS ${sln_srcpath})
file(READ ${sln_srcpath} old_content)
endif()
if(NOT old_content STREQUAL sln_content)
file(WRITE ${sln_srcpath} ${sln_content})
endif()
endif()
What would be helpful is if cmake had a way to run post generation scripts, but I couldn't find one.
Other ideas that didn't work out:
wrap cmake inside a script that does the same thing, but:
telling users to run a seperate script isn't simpler than saying to run cmake twice. Especially since needing to run cmake twice isn't a foreign concept.
put it in a pre-build step, but
building is common and changing the build is rare
changing the solution from builds inside the IDE makes it do... things
use add_subdirectory because that's suppose to finish first
it appeared to make the vcxproj's immediately, but not the sln until later, but I didn't try as hard because this adds a bunch of additional clutter I didn't want - so maybe this can be made to work
I'm trying to get the compilation args for each compilation unit so I can create the "compilation_commands.json" for my vcxproj that can be used with clang's libTooling.
The libTooling tutorial suggests using a CompilationDatabase to provide the compilation args for all the cpp files in a project. The tutorial shows that CMake can generate the compilation_commands.json for CMake based projects.
Since clang can be put into "MSVC mode" via clang.exe --driver-mode=cl or clang-cl.exe my thought was if I could get the compilation args for each cpp file in my VS2012 project I can create the compilation_commands.json for a vcxproj.
However I'm having trouble finding APIs in the VS2012 SDK that walks a vcxproj and retrieves the compilation args for each compilation unit. Can someone point me towards the right APIs?
I know this is really old, but the question is still relevant, so for those still looking for an answer, I managed to finally do this recently using this little VS extension.
Just install it and a new 'Sourcetrail' menu will appear, with a 'Create Compilation Database' entry (I found Intellisense needs to be enabled for it to be clickable). That will let you customize what to include and generate a compile_commands.json that you can use with other clang-based tools, etc.
It is a DIY job. The VS IDE projects have properties for each .cpp file. By selecting a .cpp, then right-click -> Properties -> Config properties -> C/C++ -> Command-Line you have the options required to compile that specific file. The 64 dollar question is how to do it for every file in the project / solution. The answer is not trivial, but it is doable. At least I did it on VS 2010 and I'm pretty sure it works on VS 2012/3
The secret lies with what is called VCEngine. It is a tool that evaluates all the properties or the files in the project. So the real problem is how to evaluate the property "Command Line" for each file. You need to iterate through all the .cpp files and call VCProject's Evaluate method for the "Command Line" property.
The simplest way I think you can do it is to write a plugin for the VS IDE and thus gain access to the VCEngine instance. There are plenty of examples of how to do that. Be aware that the VCEngine is version dependent.
Anywhay, for projects/solutions with thousands of .cpp files, you need to automate the compilation database creation.
When I'll have time I will put the solution on github
You may be interested in reading this
compile_commands.json for Windows/MSVC
You can try to parse the CL.command.* files in the intermediate directories.
https://gist.github.com/Trass3r/f3fbe6807d28106e917368c33abf45d4
NOTE: This question is not about MFC/CRT DLL linking with/without .manifest file, avoiding manifest-lookup (i.e. force load from current path), VC redist installation and similar issues.
I have set of DLLs, which is used by different applications. These applications and the DLL have some product version (like 7.0, 8.0 etc). To summarize, let me use one DLL, and two applications.
App.exe depends on Core.DLL
GoodApp.exe also depends on Core.DLL
App.EXE of version 7.0 would need Core.DLL of version 7.0. Similary, GoodApp of version X, would need DLL of version X.
Since DLL is to be shared by different applications, I have put the DLL into some common path. This avoids DLL to be pasted on all paths. Some \SharedDLL path is setup for this. And (assume), I have set up PATH variable for this.
So, when any of application would load, OS will simply load the Core.DLL from this common path.
All fine. But what if App.exe is 64-bit/Debug, or other configuration? The common-DLL path cannot have all DLLs (32/64, Debug/Release). On the similar lines, App.exe of version Y, cannot use Core.DLL of version X (It is not that X>Y, or Y>X, but just that X!=Y, and App of X version cannot use DLL of version Y).
In short, App-32bit-Release-VersionX, would need exactly DLL-32bit-Release-VersionX, and nothing else! Since DLL name is same, I cannot put them into one common path. And since, there are dozens of applications (and DLLs too!) that depends on Core.DLL, I just don't want to waste space and time for copying the DLL into EXE's path.
Yes, I use post-build-setup to copy the DLL into all paths, appropriately. This solves time, but waste space. And if new application comes in, PBS must be modified to copy to that new path also.
Question is: How to utilizie the .manifest feature, used by Windows/MFC/CRT DLLs? They do utilize WinSxS folder for such thing.
Maybe this will help you:
How to: Embed a Manifest Inside a C/C++ Application,
Manifest Generation in Visual Studio
Working with Visual Studios C++ manifest files
Also follow the links in those pages
I'm developing application for GNU/Linux using gcc 4 and cmake to manage compilation process. I found that is has no problems when there are two files with the same name but in other directory and namespace like this:
.
|-- gfx
| |-- Object.cpp
| `-- Object.h
`-- logic
|-- Object.cpp
`-- Object.h
First Object class is in Gfx namespace and second in Logic namespace.
Then I've tried to compile this project using Visual C++ 2008 Express Edition. Linker threw several errors about non-existing implementation of Gfx::Object class. After few checks I found out that:
Visual C++ is tracking two of Object.cpp files
When change occurs in first or second file the recompilation of Object unit is queued
It always recompile only the second Object.cpp regardless of which file was actually modified
I also found out that Visual C++ don't allow to create two classes with same name.
Is there a solution for this? I don't really want to refactor quite big part of code.
Both Object.cpp files will be compiled to Object.obj. Into the same directory. In other words, the last one that is compiled will overwrite the Object.obj of the first one. Yes, the linker isn't going to be thrilled by that, you'll get multiply defined symbols since it links the same Object.obj file twice.
The fix is easy, right-click one of the Object.cpp files, Properties, C/C++, Output Files. Change the Object File Name from $(IntDir)\ to, say, $(IntDir)\$(InputName)2.obj
The problem is that by default VC++2008 places all the object files into a single output folder, so the existence of the first object.obj file satisfies the dependency for the second so it is not compiled; and even if it were, it would overwrite the first one.
What you need to be able to do is make the intermediate directory setting dependent in the file being compiled. However I have tried setting it to $(InputDir) and various other combinations, but could not succeed in achieving a configuration that works, although it may be possible. The available macros are documented here.
Failing that you could use a "makefile" project, and manage the build with make, nmake, or cmake or whatever, since there is nothing fundamentally wrong with what you are doing (even if it is ill-advised), it is just that it is not easily supported by the IDE.
This has already been answered, but I also want to add Visual Studio 2010 will automatically put the two .obj files into different directories if there is a conflict, based on my experience with Beta 2.
EDIT: Uh oh, this is wrong! The real answer is that CMake was automatically doing this for me.
The accepted solution is not optimal because it does not scale.
In Visual Studio 2010, I set
Properties -> C/C++ -> Output Files -> Output File Name
to
V:\%(Directory)$(PlatformName)_$(ConfigurationName)_%(Filename).obj
for OBJ files to end up next to the sources assuming the project lies on drive V (no idea whether there is a macro for it, yet).
Not optimal, either - but at least I can easily fork subsystems of many source files without getting tenosynovitis.
By the way: $(InputDir) refers to the solution/project directory and will cause the same problem in another directory.
I come from a Java background, and the shop where I currently work refuses to use anything other than MS VC++ to build their legacy project. They don't appear to use any standards for setting up their build environment other than just building it using VS2005 and clicking the compile button.
I was wondering if there was anything closer to what Java had for instance:
A build tool like ANT or Maven
A directory structure that makes sense containing
src - Place for all my source files .c/.cpp/.h
lib - A place for any libraries that might be used in the project (.dll, .lib)
dist - A place for the output executable/distribution of the project
resources - A place for any images/sounds/text files that might be included in the project.
build.xml - Some sort of a build file (my guess would be something like ./configure or MAKEFILE)
Or am I asking too much from a C++ build environment? Is it just always as chaotic as the people in my shop make it out to be? I really have a hard time believing that considering the success of so many C++ projects on the internet.
It sounds like you have good intentions - coming form a non MSVC world I can see your points.
If I were in y our shoes I would definitely make a command line/automated build/build server.
You can use MSBuild for this - and hudson has a plugin for this. I usually have a "Build" directory near the root of the projects that contains scripts/etc that will call the appropriate MSBuild/.sln files.
The "makefiles" for Visual Studio are .sln and .vcproj files. You can call those with msbuild from the command line. You can also export a makefile (I think that is still an option) from within the IDE that you can run. I don;t recommend going that route though other than trying it out and seeing what is output - since that is what you are familiar with.
Both the vcproj and sln files are human readable - go through them - it will give you some useful information.
I would also agree that having a distributon directory is good - for building an installer/etc after the build. Copy all the needed binaries there - either in postbuild steps or in another script/etc.
Let us know what you end up doing.
I have one other piece of advice:
UPGRADE to VC/Dev studio 2008 or 2010. ASAP
MSVC does not impose any directory structure on you. There are some defaults, as mentioned above for the Debug and Release directories, for example, but even these can be overridden on a per-project basis. Use whatever directory structure makes sense to you.
Visual Studio does provide command line support if you don't want to use the IDE. See This MSDN Article for more information.
You can setup a proper build environment using Visual Studio (and for solutions with more than one project, you should), and there are a number of environment variables to use in the project configuration to set so that output files and intermediate files go to different folders than those defined by default.
In our large VS solution, we use e.g. obj/$(ProjectName)/$(ConfigurationName) as intermediate directory and bin/$(ConfigurationName) as output directory in all sub-projects.
All these things must be enforced by the user, and it seems that no single recommendation/best practice has evolved.
The standardized stuff:
The build tool: Visual Studio (doesn't need an extra product)
Build file: *.sln / *.vcproj (*.vbproj for Visual Basic, etc)
Directory structure: "Debug" and "Release" directories for the output binaries.
The rest isn't so much "chaotic" as "doesn't really matter". "Chaotic" suggests that it changes all the time, but in reality you just pick one for a project and stick with it. Companies may have internal standards across projects. It just doesn't matter enough to bother standardizing across companies. C++ is a complex language anyway; anyone with sufficient IQ to read C++ can deal with reasonable variation. The difference between \lib\ and \Library\ won't stop them.