This question already has answers here:
What are *-devel packages?
(2 answers)
Closed 6 years ago.
I'm confused about the use for "*-devel" packages, and so I looked it up. According to an answer in this post, What are *-devel packages?:
"For running an application using the library libfoo only the actualy
shared library file (.so., for example libfoo.so.1.0) are needed
(plus possibly some data files and some version-specific symlinks).
When you actually want to compile a C application that uses that
library you'll need the header files (.h, for example foo.h) that
describe the interface of that application as well as a version-less
symlink to the shared library (.so, for example libfoo.so ->
libfoo.so.1.0). Those are usually bundled in the *-devel packages."
This seems redundant to me. To me it sounds like this: "To use the library you need just the libfoo. But if you want to use the library, you need the header files and hence libfoo-devel"
I can't quite find the answer to the importance of the header files.
After you built an application using libfoo, you obviously do not need any of libfoo's headers installed any more. The application is already compiled. You don't need the header files to run something that's already compiled. The only thing you need is libfoo itself, because your application is linked to it.
And that's your libfoo: just the library itself. Maybe an occasional configuration file, or something else, that's needed at runtime.
On the other hand, if you need to build and compile the source code that uses libfoo, you need the header files, and other supporting files. Whatever is needed to build the source code that uses libfoo.
And those bits are the ones that go into the libfoo-devel package. That's the stuff that's needed to build the source code that uses libfoo.
Related
What is the utility of devel packages like "libgtk+-devel" or "python-devel" etc.? Do they contain source of the library? How is it different from non-devel packages like libgtk+?
The *-devel packages (usually called *-dev in Debian-based distributions) are usually all the files necessary to compile code against a given library.
For running an application using the library libfoo only the actualy shared library file (*.so.*, for example libfoo.so.1.0) are needed (plus possibly some data files and some version-specific symlinks).
When you actually want to compile a C application that uses that library you'll need the header files (*.h, for example foo.h) that describe the interface of that application as well as a version-less symlink to the shared library (*.so, for example libfoo.so -> libfoo.so.1.0). Those are usually bundled in the *-devel packages.
Sometimes the *-devel packages also include statically compiled versions of the libraries (*.a, for example libfoo.a) in case you want to build a complete stand-alone application that doesn't depend on dynamic libraries at all.
Other languages (such as Java, Python, ...) use a different way of noting the API of a library (effectively including all the necessary information in the actual library) and thus usually need no separate *-devel packages (except maybe for documentation and additional tools).
They usually contain necessary headers and libraries. For example, python-devel will provide the Python headers and libraries that you need if you want to embed the Python interpreter in your own application. Some additional tools and documentation are included, too (e.g. a developer manual or code examples).
In c/c++ we use -I for specifying header files location and -L path for specifying library path. I have an eigen and boost libraries, so what I did is that I copied these libraries to /usr/include directory in linux and in source file of my program I just used the header file of these libraries. My question is how does the source file of these libraries get linked with my program source file in which I am only using header files of these libraries?
It depends on the libraries you are using. Eigen3 is header-only: no need to link against it. With Boost, it depends. Most parts are header-only but some libraries might need to be linked.
On the copying to /usr/include. This sounds horribly wrong. Use the package manager of your distribution to get a package of the libraries you require. You should almost never put files yourself into /usr/{include|lib...} directly but prefer /usr/local/{include|lib...}.
You are also a little confused about source code and object code. Generally, a library will contain compiled, object, code, but C++ template expansion requires some kind of source code or source-like code in order to perform template instantiation.
However, the bottom line is that the syntax to include a library depends on the compiler/linker combination you are using. You need to state that before someone can answer the question fully.
The directory "/usr/include" is considered special, part of the operating system or platform you are using, so you should not copy files into it.
Note that the construction "c/c++" is not very meaningful - the two languages C and C++ have different syntax and different linkage models. Best to say which one you meant.
Let's say I have 10 *.hpp and *.cpp files that I need to compile a code. I know that I will need those same files for many different codes. Can I create a "package" with those files that would allow me to simply write:
#include <mypackage>
instead of:
#include "file1.hpp"
#include "file2.hpp"
...
#include "file10.hpp"
I wouldn't then need to write a makefile every time I need this "package".
To be more precise, I use Linux.
A collection of CPP sources (H files and CPP files) can be compiled together in to a "library," which can then be used in other programs and libraries. The specifics of how to do this are platform- and toolchain-specific, so I leave it to you to discover the details. However, I'll provide a couple links that you can have a read of:
Creating a shared and static library with the gnu compiler [gcc]
Walkthrough: Creating and Using a Dynamic Link Library (C++)
Libraries can be seperated in to two types: source code libraries, and binary libraries. There can also be hybrids of these two types -- a library can be both a source and binary library. Source code libraries are simply that: a collection of code distributed as just source code; typically header files. Most of the Boost libraries are of this type. Binary libraries are compiled in to a package that is runtime-loadable by a client program.
Even in the case of binary libraries (and obviously in the case of source libraries), a header file (or multiple header files) must be provided to the user of the library. This tells the compiler of the client program what functions etc to look for in the library. What is often done by library writers is a single, master header file is composed with declarations of everything that is exported by the library, and the client will #include that header. Later, in the case of binary libraries, the client program will "link" to the library, and this resolves all the names mentioned in the header to executable addresses.
When composing the client-side header file, keep complexity in mind. There may be many cases where some of your clients only want to use some few parts of your library. If you compose one master header file that includes everything from your library, your clients compilation times will be needlessly increased.
A common way of dealing with this problem is to provide individual header files for correlated parts of your library. If you think of all of Boost a single library, then Boost is an example of this. Boost is an enormous library, but if all you want is the regex functionality, you can only #include the regex-related header(s) to get that functionality. You don't have to include all of Boost if all you want is the regex stuff.
Under both Windows and Linux, binary libraries can be further subdivided in to two types: dynamic and static. In the case of static libraries, the code of the library is actually "imported" (for lack of a better term) in to the executable of the client program. A static library is distributed by you, but this is only needed by the client during the compilation step. This is handy when you do not want to force your client to have to distribute additional files with their program. It also helps to avoid Dependancy Hell. A Dynamic library, on the other hand, is not "imported" in to the client program directly, buy dynamically loaded by the client program when it executes. This both reduces the size of the client program and potentially the disc footprint in cases where multiple programs use the same dynamic library, but the library binary must be distributed & installed with the client program.
On Linux:
g++ FLAGS -shared -Wl,-soname,libLIBNAME.so.1 -o libLIBNAME.VERSION OBJECT_FILES
where
FLAGS: typical flags (e.g., -g, -Wall, -Wextra, etc.)
LIBNAME: name of your library
OBJECT_FILES: objects files resulting from compiling cpp files
VERSION: version of your library
Assuming your "file1.hpp" and "file2.hpp" etc are closely related and (nearly) always used together, then making one "mypacakge.h" that contains the includes of the other components is a good idea (it doesn't in and of itself make it into a library - that is a different process altogether).
If they are NOT closely related and/or used together, then you shouldn't have such a "mega include", because it just drags in a bunch of things that aren't needed.
To make a library involves building your code once, and either generating a .lib file or a shared librar (.dll or .so file). The exact steps to do this depends on what system you are using, and it's a little too complicated for me to explain here.
Edit: To explain further: All of the C++ library is actually one library file or shared library file [along with a number of header files that contain some of the code and the declarations needed to use the code in the library]. But you include <iostream> and <vector> separately - it would become pretty awful to include EVERYTHING from all the different C++ library headers in one <allcpplibrary>, even if it was a lot less typing involved. It is split into sections that do one thing per headerfile. So you get a "complete" set from one header file, but not a too much other things you don't actually need.
Yes and no.
You can write an include-all header so that #include "myLib.h" is sufficient, because you include all those headers through the single header. However, that does not mean that the single include is enough to have the content of the 10 '.cpp' files linked to your project automagically. You will have to compile them into a library and link that single library (instead of all the object files) to the projects that use "myLib.h". Library binaries come as static and dynamic libraries, the files are typically named .lib and .dll (windows) and .a and .so (linux) for static and dynamic libraries, respectively.
How to build and link such libraries depends on your build system, you might want to loke those terms up on the net.
One alternative is to get rid of the .cpp files by defininig all the functions in the headers. That way you won't have to link the additional library, but it comes at the cost of increased build times, because the compiler will have to process all those functions every time you include the header directly or indirectly into one of your translation units.
If a client needs all ten headers to actually make use of your "package" (library), that's pretty bad interface design.
If a client needs only some headers, depending on which parts of your library are being used, let the client include the appropriate headers, so only a minimal set of identifiers are introduced. This helps scope, modularization, and compilation times.
If all else fails, you can make an "interface header" for external use, which is different from the ones you use internally for actually compiling your library. This would be the one that gets installed, and consists of the necessary contents from the other headers. (I still don't think you would need everything from every header in your lib.)
I would discourage Salgar's solution. You either have individual headers, or a monolithic one. Providing individual headers plus a central one that simply includes the others strikes me as pretty poor layout.
What I do not understand is inhowfar Makefiles play into this. Header dependencies should be resolved automatically by your Makefile / build system, i.e. it shouldn't matter here how your header files are layed out.
simply all you'd have to do is create a .h or .hpp file that has
#ifndef MAIN_LIB_H
#define MAIN_LIB_H
#include "file1.hpp"
#include "file2.hpp"
#include "file3.hpp"
...
#include "file10.hpp"
#endif
make the file called whatever I would choose main_lib.h because of the ifndef, and just
#include "DIRECTORY PATH IF THERE IS ONE/main_lib.h"
in the main file. No need for anything else if you were using visual studios. Just build then press CTRL + F5.
We can include < iostream > and we do not care about its cpp file, but why can't we do the same for our own classes ?
So if my project uses 50 custom classes, not only do I have to have 50 includes, but also have to compile/link 50 cpp files along with them (and clutter the project tree).
Q: Is there any way to use custom headers the same way we use standard libraries ?
In other words is there a kosher way so that we do not have to add all those cpp files in the project. I want to only include ClassSnake.hpp which in turn knows where to find ClassSnake.cpp which links to ClassVector.hpp which knows how to find ClassVector.cpp ... all in an automatic daisy chain without me having to explicitly add those cpp files in my project tree.
Edit: I am not worried so much about the cpp files recompiling. My issue is with having to remember which class internally links to which other class, so that I can properly include all those hidden cpp files in the project tree ... and clutter the tree.
Not really.
What you're missing is that your compiler toolchain has already compiled the bits <iostream> needs that aren't in the header.
Your compiler (linker really) just implicitly links this code in without you having to specify it.
If you want to clean up your project tree a bit, you could create other projects that are libraries of code for one main project to use.
Headers do not (normally) provide implementations of things (functions, classes), they must be implemented somewhere if you are going to use them.
When you include your own header, you include your own sources in order to provide the implementation. Straight forward enough there.
When you include a standard header (such as iostream), the implementation is in the libraries you include (either implicitly because the compiler just does it, or explicitly through compiler/linker options).
As an extention to Collin's answer, you could always offload "shared" code to a shared library, and then reference the header files and lib files in your other projects. The lib files will only come in to play at the linker stage, as all those other pesky .cpp files have already been compiled.
If this is is just a self-enclosed project with no other commonality, you're just going to have to suck up the fact you have to provide an implementation :)
First of all if you use a system such as make then it will identify that the .cpp file has not changed and therefore the compiler does not have to reconstruct the object file.
You can also create your own static/shared library. The method to do this depends on the platform. If you go down this avenue then all you need is the header file along with the library.
Please Google on how to construct how to make a library for you particular platform.
Actually, if you have a decent build process cpp files that have not changed will not be compiled again. They only have to be linked. If you don't want that either you need to create your own libraries. It can be done, is just a bit more involved.
Edit: This question might help you if you want to create your own library.
So answer to edited question: Yes, you can avoid having all those cpp files in the project but only if you don't want to change them. In this case you can just create a static or dynamic library and you will only need the symbols for linking. In that case you would create another project to compile everything into such a library.
STL code like "iostream" is made of templates no code is actually generated until instances of the templates are created.
I'm using a closed source library (by Activ financial) that includes with their API a boost distribution, both some boost header files and boost library files.
I also use Boost in my existing codebase, and I need to use Activ from my existing code.
Some points
I can encapsulate my use of Activ so that the entire Activ part amounts to a single class I wrote that does not expose any of Activ's headers
This single header file does not use any boost anything
In this way I can ensure that the Activ parts of my code use Activ's Boost HPP files, and my code uses my Boost's HPP files
My worry comes in linking. How can I ensure that my Activ dependent code links to Activ's Boost, and my other code links to my Boost?
I'm using g++ now, will also be doing this in VS2008. I got it working in VS2008 before, but I have no idea how everything linked. I want to try to make sure it's done correctly.
Is there a way to do it without further encapsulating the Activ part in a dynamic library?
Edit:
For one, my final product is always an executable file. For two, I statically link to boost myself. The Activ library includes both static and dynamic versions of Boost object libraries, and I plan to statically link it.
I never pass Boost objects between code that uses different boost versions.
The question is, how do I link one cpp or .o file to objects in one library file, and then make sure other .o files link to the identical objects in another library file? Is this possible?
Does the library dynamically or statically link to Boost? If statically linked, does the library expose the symbols in the DLL (declspec export)?
If the library is statically linked and the symbols are not exposed, and you do not pass any Boost data structures (smart_ptr, threads, etc) back and forth, you are likely safe to use your own version of the Boost library in your DLL.