I have a fairly large multi-project C++ solution in Visual Studio 2015. Some of the projects compile to static libraries which are used by other projects, and most of them use precompiled headers to speed up compilation. Each project also has multiple build configurations: debug, release, and several testing configurations which always build an executable to run the tests (even if the normal configurations build a static library).
When building debug and release configurations, or when doing a full rebuild, everything works well, but when doing an incremental build of a test configuration for a project that uses another project's static library, I get C2859 errors which cause the build to fail.
For example, let's say I have a project peach which builds a static library, and a project cobbler that relies on peach. The precompiled header for cobbler references only system and external libraries (no headers from inside the solution). cobbler's test configuration references peach.lib. peach.lib is created by peach's release configuration, so I have a solution configuration called cobbler-test which specifies that:
peach uses its release project configuration
cobbler uses its test project configuration.
Building cobbler-test from scratch (or rebuilding it, clean & build, etc) works fine. But if I then modify a source file called crust.cpp in cobbler and try to build, I get this error:
c:\...\cobbler\src\crust.cpp(1): error C2859: C:\...\out\cobbler-test.pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header.
Again, this only happens when referencing a static library from the same solution that was built with a project configuration name different from the current one. With both projects using release or debug, incremental builds work fine.
Having to do a full rebuild every time defeats the purpose of using precompiled headers in the first place. Is there any way to get incremental testing configurations to work without having to resort to creating extra project configurations for every combination of projects?
My current solution to this problem is not to use testing configurations, and to create separate projects for testing projects that generate static libraries. This allows all dependent projects to use the same project configuration and allows the precompiled headers to work their magic without blowing up when doing incremental builds.
While this works fairly well for the static libraries, since they can easily be imported with #pragma comment(lib, ...), it's a bit more problematic for projects that build standalone executables. Thankfully, in my case most of those projects don't have a lot of stuff that needs testing.
Related
Our large C++ solution has a lot of project references between different projects and it seems to cause problems, most commonly it will try to link the wrong version of the dependency e.g. You'll build Project in release and get an error about missing library dependency_d.lib. Especially if you are using multiple build configurations.
Are project references considered bad practice working in C++ and developers should stick with the old way (#include directories and libraries listed in project settings)? Or does this simply suggest they've been set up wrong in our solution?
In our team we use #include despite of using vcpkg for the most libraries.
But you can set up different dependencies for each build configuration (Debug, Release etc.): just select desired Configuration at the top if the Project properties window. Your dependency _d .lib seems to be a Debug library.
I think there are some problems in your config. Also I haven't heard anything about project references are bad practice.
dll project for which i want to create unit tests.
In order to run unit tests i need my test project to compile all dependencies and i don't want to add my cpp files to test project.
The solution is to add lib in references but i have no clue how should i compile my project as both dll and as lib. Is this even possible ? I suggest that could be easy with naked cmake/make.
What i could do is create another project with same files and build it as a .lib. I think this solution is very primitive and it will require me to add .cpp files to projects twice if i ever want to add something new. I would prefer a solution in which i could have only one project in solution and have it build .dll (a main component) and a .lib for UT project reference.
I know i could also make UT load my .dll and have that kind of dynamic linkage, but that would make it harder due the need of creation of dll wrapper to access those functions.
I also considered using batch build and have custom build configuration. But this will require me to batch build every time i want to run UTs. I'd rather have it chose automaticaly. Maybe if i set UT project to be build under custom configuration the dependency will also be build with custom config?
Does Visual Studio 2015 bring any simple solution to this problem?
I have an executable, which supports two rendering backends (GL and D3D), each implemented in a separate static library. I have project configurations permuted on the debug-level (eg. Debug, Release, etc), and the renderer, so the final configurations are (Debug_GL, Debug_D3D, etc.). In my previous question, I learned how to make per-configuration dependencies.
My problem now is that I also have additional static libraries, which are not dependent on the renderer type. When I create the (CMake) project configurations above by setting CMAKE_CONFIGURATION_TYPES, these static library projects also get configurations permuted by the renderer type. I do not want this, because those configurations have separate object/library directories, etc., but they are essentially duplicates.
My main focus is generating for Visual Studio, so ideally the generated solution along with the renderer backend libraries would have the full set of permutations, whereas the non-renderer specific libraries would only have the 'debug-level' configurations. Is this somehow possible with CMake?
Configuration set is global for whole project. Each configuration is built in its own directory. E.g., from the description of LIBRARY_OUTPUT_DIRECTORY property:
This property specifies the directory into which library target files should be built. Multi-configuration generators (VS, Xcode) append a per-configuration subdirectory to the specified directory.
In other words, any target (e.g., library) built within project cannot be shared between different configurations.
If you want some targets have their own configuration set, you should move them into another project. Disadvantage of this approach is that it is difficult to make one project being automatically rebuilt while sources for another project are changed.
I have a solution with many projects.
I Would like to build several projects with multiple configuration settings.
e.g:
ProjectA is set as target framework: 3.5 and platform target x86.
output assembly name is: ProjectA.dll.
I want, when clicking the build button, to build the project in several output files:
ProjectA_3.5_x86.dll - for Target framework 3.5 and platform x86
ProjectA_4.5_x64.dll - ...
This is what buildservers does.
Is there a way to have config file that build operation looks at, and then determine how to build each projects, with different assembly names and different build configurations ?
Thanks !
As far as I know, you can only produce one dll per compile of a project. It sounds like what you would want to do is create different build configurations; which can be done by manually editing the project file or using the configuration manager. You can set up different configurations (3.5 framework, x86 CPU, with an assembly name of xxx.yyy) and then select that configuration when you do a compile. However, it is important to understand that you will have to do multiple compiles on your code, selecting the different configurations, to produce the different dlls. If you have an automated build process, you should be able to just set up the project to compile multiple times and change the configuration name.
I don't understand the difference between these Xcode features.
I'm building and app - but the functionality of the app is being abstracted into libraries (so they can be distributed separately as an "SDK").
So I have a workspace of library projects and the app project. I can add library projects to the app project by doing "link binary with libraries". This gives me a list of .a library projects in the current workspace which I can link to.
I can also add frameworks here.
In the "target dependencies" bit all I can add is other targets in the current project.
What I really want to do is both - I want my app project to build all the other library projects when I build it. I also want to make it verbose what libraries the app (and other libraries) depend on.
So can somebody please explain the difference, and whether what I am doing is the right way to go about it?
Many thanks!
It says here...
Drag your framework product (located in the Products folder) to the existing Link Binary With Libraries build phase of your application
target. This causes the application to link against your framework.
And...
In the General tab of the inspector window, add your framework as a dependency for the application. Adding this dependency causes Xcode to
build the framework target before building the application target.
The build dependency you establish in the application target causes
the framework to be built before the application. This is important
because it guarantees that a built version of your framework will be
available to link against and to embed in the application. Because of
this dependency, you can set the active target of your Xcode project
to your application and leave it there.
So it seems that you're supposed to use both. Seems redundant though, because if you're linking to a framework then its a dependency. I suppose you might want to only link to a library and not build it first. Although Xcode seems to build linked libraries even without them being added to the dependency section. Perhaps that's a result of the "Find Implicit Dependencies" option in a scheme's build settings.
I do something similar and was explicitly setting the 'header search path' and 'library search path' in the final executable target. However this all depended on where the objects were being generated. Initially I had set this to be within the source tree (actually a sibling directory called build), however after changing the location of the Xcode DerivedData directory and telling it to build into that directory, the projects no longer built.
The final solution was simply to remove the explicit setting of the 'header/library search path' and set the target dependencies correctly. This resulted in the project building for debugging and archiving without issue.