My C++ project is dependent on a huge project. My project uses many dll's from huge project. It take about few hours to install the huge project and I want to remove the need to install the huge project for someone else.
After research I understand there is two methods to compile and link using dll 1) Using a lib and header.
2) Using loadlibary method.
In loadlibrary method I need to know exactly the methods needed to load. Since I don't know this I went with option 1. Please correct me if I am wrong.
Currently I have included the path to the big project in the compiler additional dependencies configuration option. I want to share the included header with my team. The big project has lot of headers that is not used by my dependency dlls. I tried copying all the headers but some .cpp are directly used without any headers.
Is there any way I can copy only the header files needed from the huge project? Possibly automatically using less manual work. Currently the headers and cpp are about 1gb which I can't share via github. If I can't copy the headers is there anyway I could automatically generate all the dependency definitions to a file and use it? Please let me know whats the standard way of handling situations like this.
You can dynamically build and link to the library (dll).
To do so, you need to
include the folder containing the .h files with the compiler -I argument -IC:\path\
link to the folder including the dll with the linker -L argument -LC:\path\
The lib has to be compiled with the same compiler & same platform
Related
I have a C++ solution that uses several external libraries. For that to work, the compiler needs to be able to find all the header files. Currently this works by hard-coding the header locations into the various project files. But since the headers are installed in a different location on each computer, that means the project will only build on one machine.
What is the "correct" way to deal with this problem?
I feel like there should be a way to define which libraries each project needs, and then a separate file somewhere that says where those libraries are on this particular machine. But I don't know if MSBuild has anything remotely like that.
(Obviously, as well as the header files, we have exactly the same problem with the linker needing to find the object code to link in.)
It seems you can in fact fix this using environment variables. Either through the Visual Studio user interface itself, or just by editing the *.vcxproj file in a text editor, edit the include path from
D:\Libraries\Boost\32bit\include;D:\Libraries\GTest\32bit\include
to instead be something like
$(BOOST_ROOT)\include;$(GTEST_ROOT)\include
Now the project builds on any machine where the environment variable %BOOST_ROOT% is set to the right folder path. (And likewise for %GTEST_ROOT%.)
I have an external SDK that only contains a .dll, .lib, and .h files. I'm trying to use the SDK. Nothing in the dll is readable, but the .h files have some comments about the methods.
I'm not very c++ savvy. I assume I need to load the library, then read from the dll using the methods that are defined in the .h files. Correct?
I need to know how to write a cpp project where I can link all these files, read the dll, and be able to use the methods that are defined in the sdk.
Is there a test project with the project setup where I can see how this can be done?
Any help would be appreciated.
There's several ways to achieve this, including a shortcut method using #pragma that I'm not going to recommend in case it leads you to develop poor habits.
Similarly, you can use Property Sheets, but that may seem a bit overwhelming to start with. So I'm going to give you the standard middle-of-the-road approach...
In your project settings (Alt-F7 or Project > Properties...), you need to set these options:
C/C++ > General > Additional Include Directories
Add the folder you want to be searched when using the #include directive. Without complicating this with personal preference and style considerations, just set this to the directory where the SDK's header file lives.
You can use absolute or relative paths, environment variables. Whatever. I suggest for now you just use absolute path.
Linker > General > Additional Library Directories
Same as above, but this is where the .lib file resides.
Linker > Input > Additional Dependencies
This is the name of your lib file.
Now, if you #include the SDK's header file in your project's source and compile, it should hopefully work. And the linking step should also succeed.
If not, there may be extra things you need to make the SDK play nice (such as preprocessor definitions, compiler settings, or additional dependencies).
The last thing you need to worry about is that running your program might fail because the DLL cannot be found, unless it lives in a specific place that Windows searches. Rather than mess with DLL search paths etc, you can use a Post-Build Event to copy the DLL to the same directory where your executable was built.
Still, in the project properties:
Build Events > Post-Build Event
Add a command line something like:
copy "\Path\To\MySDK\MySDK.dll" "$(OutDir)\"
Now you should be all set to go, and not have to think about it again!
I would like to create a static library in C++ to store my functions.
I'm aware this question has been asked on the Cplusplus forums but I could really use a
more accurate description of what to do.
As far as I'm aware you create a new Win32 program and then add the header file (.h) and the
code file (.cpp).
So in fact I have a few questions.
1 - How do I put my code into these files?
Do I use the .cpp?
2 - I did manage to make a simple library with an add function alone, but after compiling
and building it I was unable to #include it in a program. Why is this?
Could someone please write out a step-by-step approach to making this so I can finally do it.
I am aware MSDN has a tutorial for this, and I have looked at it.
The thing is it uses a OOP approach to making the static library, and the calls to the
functions within the library use the :: operator (think its an operator), too often which is what I want to avoid.
Would like to start simple, basically.
Thanks for any help given.
The idea of a static library, is that you write your code as usual, but you compile it as a static library. The users of a static library still need your header files, but they don't need your .CPP files anymore, because the actual implementation is contained in your static library file.
To use a library, you include the header files you need, and then link the library file with your program.
Here is a link to the microsoft walkthrough.
http://msdn.microsoft.com/en-us/library/vstudio/ms235627.aspx
How to create and use a static library using Visual Studio
Here is excactly how you do it in Visual Studio 2012.
To create a library, create a new C++ project. In the wizard, at Application Settings, choose Static library. Uncheck Precompiled header.
Create your library as you want. Don't forget to declare everything in header files.
Compile the project as you usually would. This creates a .lib file in the debug folder of your solution
To use the library, create an application as you usually would.
To link the library with your project, drag the .lib file to your project in visual studio.
To let visual studio find your header files, right click your project. Choose Properties->Configuration properties->C/C++. There is a input box called Additional Include Directories. Here, you have to write the path to the header files of you library.
You can now use the header files as if they where made by your project directly. The implementation of your library is taken from the .lib file, and everything should compile and run well.
Another option, is referencing the whole libary project in your application. To do this, you must get the library project in your solution. Right click your solution in Visual Studio->Add->Existing Project. Then you have to reference the project. Right click your project->References->Common Properties->Framework and References->Add New Reference->Choose your project. Now you can edit your library in this solution and use it directly in your application.
I am trying to use gnuplot++, but this is really a more general question about downloaded source code. I have downloaded the gnuplot++ source code and it consists of multiple .h and .cc files. I would like to use it in othercopy projects in the future so I am reluctant to add all the files into my project directory.
From what I understand gcc will look in /usr/local/include for header files, so I have put the code there for now. But what is the best way to compile and link the code?
Should I use the makefile to include the directory of the source code?
Should I keep it somewhere easy to find like /usr/local/include?
How do I know the best way to compile the code in gnuplot++?
Typically, if the project itself doesn't come with install instructions, I usually add it somewhere "public", e.g. /usr/local/project/{lib,include,src,...} where "project" in this case would be gnuplot++.
In this case, there doesn't appear to be any support for building this into a library, which makes it a little more awkward, as you need the sources included in your project itself. I'd still keep those sources separate, but you may prefer to just put them into a separate directory within the project [or spend an hour or three making a library of it].
For general practice, yes, keep the source for gnuplot++ (or any other similar 3rd-party project) separate from your own application source code. This makes it much easier to manage updates to the 3rd party projects, etc.
Yes, I would use the makefile for your application to also include the path to the headers for gnuplot++ and I would not copy those files directly into /usr/local/include. Instead, I would consider a couple options: do nothing and point your include path in your makefile to the gnuplot++ directory, or put symbolic links in /usr/local/include to point to the gnuplot++ files.
As for the best way to compile gnuplot++, I would have to look at gnuplot++ myself and see what it has to say, perhaps in a README file or similar.
In general, when using third-party libraries, you build and install those libraries according to the installation description that comes with the downloaded source.
If there is no installation guideline, it is typically a set of steps like
./configure
make
make install
Then it is the responsibility of the library to ensure the relevant headers and library files are easily locatable for use in your project.
gnuplot++ is an exception here, because it does not seem to come with its own build structure.
The best advice in cases such as this is to put the source from gnuplot++ in a directory within your project (possibly parallel to your own sources) and include the files in your own build setup.
I am right now reorganizing my project and what recently was a simple application now became a pair of C++ projects - static library and real application.
I would like to share one precompiled header between two projects, but face some troubles with setting up the .pdb file paths.
Assume my first project is called Library and builds it's .lib file with a corresponding Library.pdb file. Now, the second project is called Application and builds everything into the same folder (.exe and another Application.pdb file).
Right now my both projects create their own precompiled headers file (Library.pch and Application.pch) based on one actual header file. It works, but I think it's a waste of time and I also think there should be a way to share one precompiled header between two projects.
If in my Application project I try to set the Use Precompiled Header (/Yu) option and set it to Library.pch, it wouldn't work, because of the following error:
error C2858: command-line option 'program database name "Application.pdb" inconsistent with precompiled header, which used "Library.pdb".
So, does anyone know some trick or way to share one precompiled header between two projects preserving proper debug information?
The question is, why do you want to share the precompiled header (PCH) files. Generally I woul d say, that does not make sense. PCH are used to speed up compiling not to share any information between different projects.
Since you also write about the PDB file, you probably want to debug the library code with your applications. This can be achieved by setting the /Fd parameter when compiling the library. When you link the library in your application and the linker finds the corresponding PDB file, you get full debug support.
This sounds complicated and cumbersome to set up. More than that, it may not be possible at all.
Instead, you can include the precompiled header from one application into the second. It will still be compiled once for the second project, but maintenance becomes easy and you do not have to redefine the dependencies in the second project (just include them).