I am C++ beginner. I have a simple console project. with class files inside that use boost (.libs) and openCV (dlls). I want to put all my existing classes into some namespace and into seperate projects. So I need a tutorial on how to separate my application project and code library in visual studio enviroment inside one sln?
First you create a new W32 Project (and solution) for your new executable (exe or dll).
Choose save all (or else if something goes wrong, you'll lose everything).
After this you go to the solution explorer (in the right margin) and right-click on the solution-name (not the project). In the popup-menu choose Add->new Project.
Now you create a new w32 project (for a new library). In the Dialog that comes up you choose next and in the following page you choose static library (and some other options if want to). Now choose Finish and the new project will be added to the solution. Now choose save all.
Repeat these steps for all the libraries you want to create (and don't forget to save things).
You could build the solution now so that things exists.
Next you must add the libraries to your executable-project.
Go to the properties of that project and select All Configurations in the combobox in the left-upper corner.
Now select the linker option and in there choose the input option. Now choose the additional libraries option in the property-page and in there choose edit. In the dialog that pops up you can add all libraries-names you just created.
If you were to build now the linker will complain that it cannot find those libraries, so one more step is required.
In linker-options choose General and in the property-page there is a property Additional Library Paths. Here you must supply the path to all those libraries by choosing edit.
In the dialog that pops up there is a button Macros that supplies a large list of macros that you can use for specifing paths (like $(SolutionDir) and $(Configuration)).
expample : $(SolutionDir)\lib1\$(Configuration)
You could build the solution now and no errors of not finding libraries should come up.
EDIT ,NB: if there is no source compiled in the library the build will be successfull but no library will be made, so you need some code in it. Otherwise the library will still not be found.
Now there's one more step to take.
Your Libraries should supply header-files to use the libs but if you include them in your source the compiler cannot find them.
You need to add additional include directories to your executable-projects properties.
Go to the C/C++ option in the executable-projects properties and there you'll find the additional include directories and there you choose edit and supply the dirs containing the header-files you need.
expample : $(SolutionDir)\lib1
Now you're ready to go.
By the way, try one library at a time so you go through the process a few times, learning and getting experienced with it.
Hope this will suffice.
Related
I've created a static c++ library in Visual Studio (2013) called "mylib.lib". It is multi-threaded (/MT) and I specify the "output file" under Librarian/General to be "$(OutDir)$(TargetName)$(TargetExt)" so I can name it without the "mt" Visual Studio wants to force onto the end of the file name just because I used '/MT'.
This project also links in several other dependencies so they're all in one giant "mylib.lib" file for consumption by using applications. These other librarys are "A.lib", "B.lib", and "C.lib". They are also built specifying the output name so as not to have "mt" on the end of their file names.
Now I want to consume "mylib.lib" in a C++ application that also uses '/MT' to build. The application links with that library and calls a single function within it. The application fails to link because it "cannot open file 'Amt.lib' LNK1104".
The application doesn't have a direct dependency on "A.lib" and that dependency is already contained in "mylib.lib" which it DOESN'T try to link as "mylibmt.lib". The seemingly arbitrary decision to apply the "mt" suffix in one case and not another is confusing.
What is going on inside Visual Studio's mind here? And is there a way I can tell it to NOT append "mt" onto certain libraries?
One way to accomplish this is to set "No default libraries" in the consuming application and then manually add every "additional" dependency in the Linker section. This requires tracing all the way down the dependency tree, but it does work.
The easier way to do it is add the desired libraries to the "Ignore specific default libraries" field under Linker|Input. For example, I added "Amt.lib", "Bmt.lib", and "Cmt.lib" to that field -- then added "A.lib", "B.lib", and "C.lib" to the "Additional Dependencies" field (also under Linker|Input).
I am attempting to use the new VS2015 precompiled header refactoring tool. When I launch it, it pops up a message saying:
To improve recommendations, add third party library paths to the
'Exclude Directories' property under VC++ Directories (in the Project
Properties dialog).
I'm not clear on precisely what a directory is being excluded from if I list it here. All the MSDN help text has to say about it is:
Directories not to search when checking for build dependencies
That helps a little, but I'm still not completely sure about what functionality I will gain/lose if I list something here. Something like, say, boost (which the message from the pch tool seems to be suggesting). Can anyone say exactly what this setting does?
The general idea is that every time you hit 'Build' the IDE (or msbuild more specifically) has to check all the dependencies to see which cpp files need to be rebuilt. If you have a large project and many headers (boost being a good example) then this may have to check for thousands of headers (because each header also needs to have its dependencies checked).
If you have a third party library such as boost which is only updated very rarely then you can add the path to the Exclude box so that the dependency checker won't bother checking any of those libraries. However, if you do update the library at some point, or make a small change to it then you will have to manually rebuild all projects that relied on it, because you have told the build system not to do it for you.
In practice I've never found it to be a problem, even with a few MLOC project and a boost installation, especially if you're building with an SSD. If you're on older hardware then it may be worth using, but I think it may cause problems when you inevitably forget to rebuild dependent projects.
I need some help to add a .*lib file for my solution and this solution has many projects.
I am going to make it more clear. Lets i have a "ABC.sln" solution in visual studio 2010. This ABC.sln has several projects (VC++ Project (1,2,3....*vcxproj) and these 1, 2 and 3 projects required a 123comman.lib file in the linker option of their respective projects.
Currently i add this library file in all three projects and it works fine but i think there must be some way to set this library file as a common stuff for all projects inside a solution. So that i just set it once and all projects can share it.
Is it possible ? if yes how can we do that ?
Thanks!
VS2010 introduced the concept of Property Pages, which is distinct and separate from Project Settings. Property Pages are similar to Project Settings in that you can specify things like additional dependencies, language rules, optimization settings, etc. But unlike Project Settings, Property Pages use a different file to store these settings, and these files can be shared across all (or any) projects in your solution.
Documentation for Property Pages is here -- I'll leave the details up to you. But to get started, go to View > Property Manager, open up one of your projects, create a new property page for a given platform (x64 Debug, x64 Release, etc), and set your settings. Then you can use this Property Page in your other projects.
Projects can share configuration via property sheets. You can create them in the project configuration tree by right-clicking a project and selecting "add property sheet" or something like that (been a while). In a property sheet, you can specify the import, and then you can add the property sheet to all other projects as well.
This does not reduce the initial work: you still have to add something to every project. Solutions do not have the ability to inject anything into projects; they're a completely different file format.
However, it does save you work if you then have to do another task that is common to all projects, like changing the library name you want to include, or adding another library. Then you only have to do it once, in the property sheet.
Make a NuGet package out of this library, and use the package manager to add the dll to all projects.
An in-depth description of how to generate a NuGet package for C++ code can be found here.
If you do it this way, it only takes a single click per project (to enable the checkbox when adding the package in package manager) to add the library as dependency.
If your problem is only about sharing the same file among different projects in a single solution. You can add the file at solution level and then do add existing items in individual projects and choose to add them as link.
This way you have only one copy of file that is shared.
I'm normally working in c# so certain things in c++ keep confusing me alot (they seem so diffrent yet the names almost the same)
I created a Console project in which i want to run a diffrent project for testing purposes. i added the project as a reference to the console app, and then got kinda stuck.
there is no namespace in the projects, so i can't do a using and if i try to include the other file, it cannot find it (and i want to avoid being unable to debug through it all).
the code for the class can be found here(ignore the c# part), the console is just a standard console with nothing in it yet.
Yeah, C++ doesn't have the notion of assemblies that exists in C# and .NET. It makes tasks like this slightly more difficult, a virtue of the fact that C++ compiles directly to native code.
Instead, you'll generally #include the necessary header files (*.h) at the top of your code file, and instruct the linker to link to the appropriate .lib file(s). Do that by going to your project's Properties, selecting Linker -> Input, and adding the file to the "Additional Dependencies" section.
As an alternative to linking to the .lib file, you can use Visual Studio to add a reference to the other project, if it's part of the same solution. Microsoft has a walk-through on creating and using a dynamic link library in C++ that might be worth a read.
I'll assume you're using Visual Studios:-). You have to tell
the compiler where to look for its includes. Under Visual
Studios, open the properties page for the project, then go to
Configuration Properties->C/C++->General, and add the necessary
directories in the entry Additional Include Directories. (If
the other project is in the same solution, use a relative path.
But I think the dialog box that pops up when you click on the
button on the right does this automatically. I'm not a great
fan of all this GUI stuff in general, but Microsoft seems to
have done this particular part quite well.)
Once you've done this, you might have to go through a similar
process for linking: this time it's under Configuration
Properties->Linker->General, and the entry is called Additional
Library Directories, but the principle is the same. (This may
not be necessary, if you're putting all of the dll's and
executables in the project in the same directory.)
We've got a program which runs separately, executed with an execvp command. So it needs a main method, but I believe that poses a problem to eclipse with a managed make. Do we have to keep this code segregated into a separate project, or is there a way to incorporate it into the same eclipse project?
Create a project for each executable that has a main() function, and create an additional project to represent the software as a whole (a "container" project of sorts). Eclipse allows you to specify projects as dependencies of other projects, and in this case you will want to set up the container project to list the other projects as "Referenced Projects".
To do this, create the container project, then right-click on the project in the left-hand column (project explorer) and click "Properties". A dialog box will appear. Select the "Project References" item in the list on the left-hand side and you will see a list of all projects that Eclipse is currently working with. Check the boxes next to the projects for your individual executables, then click OK. Now, when you perform a build on the container project, Eclipse should automatically perform a build on these dependent projects as well.
When using sub-projects in this manner, I have (personally) found it useful to create a working set that includes the container project and all of the sub-projects (this can make searching the entire software project easier).
Keep it in the same project and use preprocessor defines which you define differently depending on what kind of main you want to include in the current project. Here the mains are in the same file, but they can of course reside in different files.
#if defined(MAIN_ONE)
int main()
{
// Do stuff
}
#elif defined(MAIN_TWO)
int main()
{
// Do some other stuff
}
#endif
If the makefile being invoked doesn't compile the 2 main() methods into the same executable, it won't cause a problem. I don't know how eclipse projects are handled - if it's like VS, where "project" means a single executable or library, and "solution" is a group of "projects", then it would seem you'd need more than one project. If, OTOH, a "project" can contain different "subprojects" where a "subproject" is an executable or library, you should be able to handle that easily.
I am not aware of any easy way to build two mains using Eclipse build system. The smallest change you need to do might be to move to makefiles and use makefile targets to build.
Instead, I'd advise you to move to using CMake. CMake can be used to generate makefiles to be used with eclipse. The advantage you get from using CMake is that you can easily state how to build the libraries and link the libraries to form the executables. CMake can generate builds for Eclipse, Visual Studio, Code Blocks, or makefiles (so you can use command prompt).
This is built in the C++ language. You would have to modify it to get your result. There is something to do 2 things at once if that is what you want.