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.
Related
I have two pairs of projects that I develop in NetBeans, both of which have a GUI project, and a library project, where the GUI project depends on the library one. In one of them, NetBeans recognizes that the dependency is local, and indicates as such with an Ma symbol, as seen below, with the dependency project in green:
This provides some nice functionality, most notably that the "Navigate to" (ctrl+click) functionality from the GUI project takes me to the source code in the library project. I also don't have to manually rebuild the library project for the GUI project to pick up any changes.
However, for the other pair of projects, NetBeans will pick up that the dependency is in my local Maven repo, but does not recognize that the source code is a Maven project that it also has open:
I've tried looking through all the right-click menu options, removing and re-adding the dependency from the NetBeans GUI, comparing the pom.xml, comparing nb-actions.xml, and nb-configuration.xml, but cannot find any explanation of why one library is recognized as local, but the other is not. The only information I've found online is at http://wiki.netbeans.org/MavenBestPractices, where it notes:
"Hint: If you open a project that other projects depend on, the icon in other projects changes to a "maven project" icon to denote that the IDE knows about link between the projects. However such a link is only established when the groupId, artifactId and version all match in the dependency and project declaration. Frequently occurring problem is that you change an API signature in your library project, but the application is not picking up. Often it's caused by the fact that the application is using an older version of the library artifact. The artifact icon can help you track down these problems."
However, I've verified that the pom.xml of the GUI project depends on the version being built in the library project, and even made the versions identical between the GUI project and library, and the "maven project" icon still doesn't show up.
Does anyone know how to debug this issue, or if there's a magic setting somewhere that I'm missing for how to make this link work? I've been trying with both NetBeans 8.2 and 8.1, and am compiling with Java 8 for both the successful pair of projects, and the unsuccessful ones.
Revisiting the project a couple years later, I finally figured out a way to get the dependency to connect locally.
Change the artifact ID of the dependency, and update the dependent pom to match the new name.
This is admittedly bypassing the root issue rather than addressing it, but given the inability to pinpoint the root cause, seems the best option at this time.
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.
I'm quite new to QtCreator, so perhaps I left my heart in eclipse-ville, but I can't for the life of me understand how I should be setting up a project hierarchy in QtCreator. I understand there is an option to create a kind of root project and then from there add sub-projects to it, which makes sense but it leaves me wondering whether or not this is necessary at the time of creating the project, e.g. can I just create a library in one project and reference it later by another project?
I've tried setting up a blanket type of project by creating a new subdirs project and then adding the main program as a subproject, but then how should I add my library project?
Ideally, I'd like to create one project as the main application and reference another project as a library. Help?
The documentation of Qt Creator contains two sections that may help you find the answers to your questions:
Adding Subprojects to Projects
Adding Libraries to Projects
EDIT:
You can find a really simple sample project here: QtSymbianDllExample. "It is intended to demonstrate how to create and use a DLL with Qt on the Symbian platform". It is a sample for Symbian development but that is irrelevant now, I do not have a Symbian phone. What is important is that it contains a root project (QtSymbianDllExample\qtssymbiandllexample.pro) and two subprojects (QtSymbianDllExample\qtenginedll\qtenginedll.pro, QtSymbianDllExample\testui_simpledllengine\testui_simpledllengine.pro) which you can examine and compare to you projects. I have checked that I can build the root project by doing the following steps:
Download and install the Windows Offline Installer from http://www.qt.io/download/
Download and extract QtSymbianDllExample.zip
Run Qt Creator
File / Open File or Project... Select qtssymbiandllexample.pro
Build / Run qmake
Build / Build project "qtsymbiandllexample"
I have a minor problem. Whenever I try to build my project using the distribution configuration it complains that one of my libraries is missing
ld: library not found for -lTouchCustoms
This only appears in distribution mode. The only difference between the release and distribution build is in the code signing section. Because of this I had to use the release build (with distribution profile code signing) to publish my app because that builds correctly, and was acceppted. If I delete and recreate the distribution config, duplicating the release config, I get the same error. How do I solve this? Thanks.
The problem is that the static library doesn't have the "distribution" build configuration. It will default to building the Release configuration instead. When the linker is trying to bring everything together, it is unfortunately looking in the "distribution-iphoneos" folder for the library while the library is actually in the "Release-iphoneos" library.
I'm trying to find a general solution for this issue in this question. For you and others it should suffice to simply add the same configuration to all static libraries you're linking against as well.
I have an msbuild project which builds a SLN file from visual studio which holds all the projects in (about 70+ project), and a lot of the projects are dependent on each other meaning they need to be build in order - sometimes a developer forgets to set the build order manually in visual studio in the solution file causing the msbuild on a clean solution to fail as something gets built out of order/cant find a dll.
Is there a way for msbuild to take all projects and work out the dependencies and build the projects in order, if there is how do i do this? using an MSBuild task? With current tries it seems to just build in the order it reads the projects in - if i pass in a list of project files+paths.
Currently the only way i can think to solve this is a external app which scans the proj files and references and then manually creates a solution each time.. but this seems overkill for such a simple thing.
Anyone solved / seen this before?
How are you calling MSBuild? If you point MSBuild to the solution file, it should be able to work out the dependencies. If you point it to individual project files, then it won't be able to resolve any project references.
If you don't use project references you can still control the dependency order in a solution by using the "Project Dependencies" dialog to manually set the dependencies.
While Project Dependencies are hard to maintain and not shared across .sln files, Project References are honoured and do dictate the order consistently - see the ResolveReferences task in Microsoft.Common.targets.
ASIDE: A 'friend of mine' may 'during a refactoring' have accidentally stubbed out their Build Task and it's DependsOnTargets linkage to the Microsoft.Common.targets ResolveReferences task and ended up with ProjectReferences not being honoured in ways that sound like the question here. If you read some of the posts, you might get the idea that it's all mad shaky - it's not; the shaky bits are the Project dependencies, not the Project references.
See this excellent MSDN Blog article by Dan Moseley that really explains the topic, including some useful workaround strategies. (via this mildly related issue with building xUnit.net).
If all of your dependent projects are in the solution and you are using Project references, Visual Studio should manage the dependencies for your and build in order of that dependency list.
It sounds like you are not using project references. I always recommend project references.
This is an old question but the issue was most likely that projects in the solution used direct references to dependent DLLs (Add Reference > select Browse tab > select dependent DLL) instead of using project references (Add Reference > select Projects tab > select dependent project). With direct references, Visual Studio can't figure out the dependency chain. You must tell it by right clicking on the solution node and select Properties. Pick Common Properties > Project Dependencies to set the required projects. Mr. Klaus is correct but I wanted to document how to fix this issue.
While it is correct that MSBuild should observe the build order when you use project dependencies there is one caveat. It doesn't at present observe the reverse build order when building the clean target (as I have blogged about here). For regular build however it works nicely as described by others here.
I am using Msbuild 4 found at c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
It seems to solve the problem.
There is no Microsoft tool that will examine all the dependencies of your 70+ projects and generate a solution file with dependencies clearly declared for you.
You have to do that on your own by using 2 different methods:
Manually specify a dependency, for the solution, in visual studio.
Specify a project reference in the project file itself.
If you don't want to do that, then you will have to swallow the medicine and accept that you will to use an external tool to do that for you. Yes it's clunky but it can be made to work. If you check in your solution file to your source control you can mitigate these problems. As long as you have an active solution file to work with.
I at one point didn't, and I had 600+ projects in the build. So I wrote a tool (years ago) that would automate 99% of this work. It uses the .NET MSBuild API's to read the msbuild files (no recreating the wheel here with xml api's). It then examines outputs and inputs and generate a dependency tree which I can then do a few things with it:
Spit out a solution file.
Do a dependency sort (also a topological sort in academia), and spit out those projects in order they should be built (for a non-parallel type of build, which can be useful sometimes).
print out all sorts of diagnostic information about dependencies.
The only limitation I have seen with the tool is with a few crazy COM dependencies which are pretty sketchy anyways. Which I added a super simple work-around.