I have an object file library that exists as a standalone VC++ solution. I have a number of other completely separate VC++ solutions, and I would like some of them to utilise the classes included in this library.
However, since they are in the same solution, I cannot seem to add them as a dependency. I have attempted to investigate so-called "linker" dependencies but can't get it to work.
Does anyone know of a standard, modern efficient way to do this. Eventually my plan is to conglomerate these projects into a single solution as I believe they should be, but that is not something I have the time to deal with right now.
I think you are mixing terms project and solution. Generally speaking, solution is a collection of projects, with specified dependencies between them.
Library should be a project (possibly dependent on another projects), but not a solution. If you would like to include your library in another solutions, simplest way to do that would be to add project for library (and any dependent projects) to solutions you would like to add them by right clicking on solution->add->add existing project->add your project. This will ensure library will be compiled as part of solution.
You would need to set dependencies between projects (in your solution), and add include/linker path for the library to any projects using it within the solution.
Related
I have a main project that has several 3rd party libraries. I just added a new 3rd party project. The problem I'm facing is the new project breaks when the main project compiler definitions are passed to it.
How can I avoid passing these definitions to the 3rd party project?
Also, if the 3rd party project is compiled stand-alone, it only requires two include directories. But when compiled with the main project there are many extra directories passed to it.
I've tried looking for a set_definition() but I'm not seeing anything helpful.
Any links to examples or write ups will be nice. It might also be that I'm not looking for the right solution.
thanks
Using global 'add_definition' is old-approach. In present may be much better define compiler flags, defines etc. per target, folder, source files etc. (in your case COMPILE_DEFINITIONS?)
Just google for 'modern CMake' and you will find slides and videos from conferences how to use modern CMake.
I'm working at an organization with a product suite based on several hundred Visual Studio solutions (mostly C++). Some of these solutions generate libraries that are used by other solutions and there's also a common "include" folder containing headers that shared by multiple modules.
The issue is that the dependencies are not explicitly stated anywhere, and the build system resolves dependencies by specifying a linear build order that makes sure the dependent modules get built at the right time. This works well for the build system but leaves developers at a disadvantage when trying to work on components with many direct and indirect external dependencies. For example, I might want to edit one of the library projects or shared headers and then build all the affected modules without necessarily knowing ahead of time which ones are affected. Another use case involves building a module after doing a fresh pull from TFS and having the modules it depends on built first without having to build the entire system.
I am wondering if there is/are any tool(s) available that can automate dependency generation for building large projects. I have considered creating a few really big solutions that encapsulate the other solutions but that seems really awkward and clumsy. Also, I don't like the idea of having developers manually specify dependencies as it can error prone, especially with such a large code base. I worked with scons a few years ago and really liked the way it could parse source files and automatically discover all the dependencies dependencies. Is there anything available today that can do the same thing with Visual Studio solutions?
This is not a duplicate of Visual Studio: how to handle project dependencies right?
I need to emphasize the magnitude of the problem I am trying to solve. This is a very large existing code base. In the main directory there are several hundred sub-folders, each one containing one of more VS solutions (not projects). Each solution, in turn, contains one or more projects. As I said before, I'm not trying to establish dependencies among a few projects in a solution. The problem is much bigger than that. I'm trying to find a way to establish dependencies among the solutions themselves (several hundred of them). For example, one solution may contain some projects that generate libraries for security, others for communications, etc. There may be, for example, dozens of solutions that use the communications libraries. So essentially I'm trying to create a directed a cyclic graph with hundreds of nodes and potentially tens of thousands of edges.
You could use cmake (https://cmake.org/). With it, you can specify several libraries and apps to be built. Once configured, you can modify a project and the build will just update the dependent projects. Cmake also provides a visual studio generator, so that you can continue using that IDE.
A possible disavantage to you is that, to configure, you must explictly specify, for each project (library or executable), with what projects it must be linked and what folders it must include. There are ways to define some global includes and links, but the use will depends on your problem.
VS does track dependencies (by parsing source files). It doesn't make sense that something could automatically set dependencies of your VS projects, in any other build tools you'd still have to specify in some way that for linking project A.exe you need to use B.lib.
If you use newer VS versions you should simply add references to lib to your exe/dll projects. If you manually added project dependencies, most likely you should remove them all, especially make sure you don't make static lib projects dependent on each other. VS allows you to do that (for example, if build of one library generates some source files that another static lib uses), but in general these shouldn't have any dependencies and this allows VS to optimize builds by building them in parallel.
For example, commonly you could have some kind of Base.lib, then System.lib and Graphics.lib. All of these are user by your App.exe. System.lib uses code from Base.lib, Graphics.lib uses code from System.lib and Base.lib. So, naturally the dependency chain is clear and you go and set them in VS, and that's a mistake! In cases like this in VS you should make these 4 libs independent and only App.exe should be dependent on all these libs (e.g. it should have references to all of these). VS will figure out what is the the correct dependency of these projects.
Regarding Cmake case: it simply generates VS projects and solutions, if you use VS then cmake cannot do more than VS itself can.
I am working on a game engine project in C++ with VS2010. We have one main project, OgreProject, which includes some Ogre3D stuff for rendering. Then, we have a class library project called AudioLibrary. AudioLibrary uses fmod, and has includes to the appropriate headers and libs. The problem arises when a class in OgreProject wants to use the SoundPlayer.h in AudioLibrary. Then, OgreProject does not know where #include is. It feels wrong to tell OgreProject where fmod is, since it will not directly use these headers. What is the correct way to using header files from AudioLibrary in OgreProject, without OgreProject knowing of ?
There is no correct way. There's no magical way for one library to know about the other library; you'd have to configure them to do that. If you put them in the same solution you can add one project to another as a project reference.
You might try the Pimpl idiom (or pattern).
It will let you remove everything related to fmod from your project's header file. Only the implementation files will need the fmod headers, not client projects.
See this answer which explains the benefits.
You should probably define a heirarchy for all the components of your project and keep all the header files from a particular component which other components are going to use at a pre-defined place. Other components can then always look at this place. There is nothing wrong in telling the components where to look for these dependencies explicitly
Currently my visual studio is basically generating Engine.dll and Game.exe
Engine.dll links to some other basic libraries like:
d3dx9d.lib
ComCtl32.lib
WinMM.lib
WSock32.lib
etc.
I also wanted to try to create an Engine.lib, but I get some really nice warnings now: Symbol x has been defined already. These libraries define the same symbols.
So I read somewhere that I must force my user (Game.exe) to link to the libs instead. But this is just really inconvenient I think, especially if I have many games and I decide to add another library to my engine. It's just maintenance for something so simple.
Should I stick to the .dll, or is there some way to fix this beauty up?
Thanks a lot,
Antoon
You need to make up your mind whether the want the DLL or the static link library. Advantage of a DLL is that the build times can be quicker if you make local changes. Advantage of a .lib is that you'll end up with only one deployable file.
Getting it linked (either the static .lib or the dll's import .lib) is otherwise automatic. You want to make sure that the library is built first, can't link the .exe without it. Right-click the exe project in the Solution Explorer window, Project Dependencies, tick the library project. That automatically adds the .lib to the exe project's additional dependencies.
Using #pragma comment(lib, "engine.lib") in the engine's header file is another way. Repeat for other dependencies like the OS import libraries. Getting the library path right is a // todo item.
Did you create a different namespace to avoid naming clashes?
EDIT -- seems like there is some confusion as to what you're asking, because you are asking a couple of questions.
To me, it sounds like you want to take a stab at implementing your own Engine class. However, you've got naming issues. I am treating this as more of an architectural question now. If you write your Game to an interface, then the problem goes away. For example, if your Engine is using different algorithms, then if you had written an EngineInterface that the current Engine and YourEngine implemented, then you could easily use Strategy to flip between the different implementations on the fly. This is nice because you'll be able to see the differences in-game if you wire the preferences into the app.
If the symbols are not supposed to be the same, use diferent names or control how they are exposed. Another option is the usage of namespaces to avoid naming conflicts.
If the symbols are supposed to be the same thing, you need to define those only once in one of the libs.
I am having a bit of trouble organising my source files.
I have my own small, but growing collection of code that I would like to use in various projects. The file and folder layout is something like this:
library\sub1\source.h
library\sub1\source.cpp
library\sub2\source.h
library\sub2\source.cpp
One of my problems is that I want to include this code, as needed, in my other projects. To date I have used absolute paths to point to the libary code, but there must be a better way.
Futhermore, I need to add every library file I use to a project's files Visual Studio in order for it to compile correctly.
So my question in short is how do I fix this? What is the proper/best way to handle the above situation.
You shouldn't, in general, add source files from libraries directly to other projects. Compile them separatly as a library and use those.
For organising the library's directory structure itself, right now I settled on something like the following structure
library1/widget.h
library1/private/onlyinlib.h
library1/private/widget.cpp
(and if applicable)
library1/private/resources/widget.jpg
library1/private/project/widget.xcode
I put all headers directly in the library path, and have a subfolder private which will contain everything that's only used by the library, but should never be shared / exposed.
The greatest advantage is that every project I start only needs a include path pointing at the directory containing my libraries, then every (public) include is done like
#include "library1/widget.h"
private includes are simply
#include "onlyinlib.h"
This has a number of advantages:
If new libraries are introduced, there's no messing with project /compiler settings to get the headers 'visible'.
Moving to other compilers / platforms is also very little hassle.
The headers are automatically 'namespaced', i.e. by including part of the path too, it's next to impossible to get a nameclash with the includes
It's immediatly obvious where a header comes from, and if a header is part of the public interface or not
I don't think that there's a proper way to do this - it's going to depend on exactly what you are trying to achieve.
Here's some things you might not be aware of:
You can use relative paths in your projects.
You can use environment variables in paths.
You can add directories to Visual Studio's search rules.
This gives you a little more control over where you put the include files and if you add your folders to Visual Studio's search rules you don't have to include any paths at all.
If you must include third-party code instead of just linking with a pre-compiled version (e.g., perhaps you need to make modifications or tweaks to it), consider branching it in whatever you use for source-control:
/trunk/... --- your code goes here
/thirdparty --- pristine copies of third-party libraries go here
/thirdparty/lib1
/thirdparty/lib2
etc.
/trunk/lib1 --- branched from: /thirdparty/lib1, perhaps with local changes
this is the version that you build/link with.
Assuming you use a decent source-control system, this scheme will allow you to easily upgrade to newer versions of third-party libraries and then merge those changes with the changes you've made locally.
For example, suppose "lib1" releases a new version:
Commit the change to /thirdparty/lib1.
Merge from /thirdparty/lib1 to /trunk/lib1
Fix any merge conflicts.
This is, IMO, the only sane way to handle upgrading third-party libraries to which you've made local modifications.
First: Add all used directorys to your project include paths. Add them as relative paths if possible.
Second: You must add all used librarys/source files to your project. This can be either done in the project explorer, or in the Project->Linker tab. In the latter case, you'll have to add the used directories to the projects library paths as well.
Usually its not a good idea to use paths in #include directives.