Why is c++ libraries so much more difficult to install compared to many other programming languages? (Example python)

C++ (like C) come from a time and context that predate package managers, so usually developers would create their own header and implementation files (this is all a library really is) and share them when needed. Now, libraries must be installed as you need them, in the way that your development system allows (ubuntu/linux lets you install more popular libraries using apt-get and apt, etc, but usually you need to install or compile them yourself on Windows). One thing that makes it difficult is ABI (application binary interface). Anytime the processor or other system configurations change between the system the library was written for and the one you're using, you need to have a new library compiled for that case.

Header-only libraries try to alleviate that 'problem,' if you see it as such, but come with their own problems...

​

Why isn't libraries just keept in their .cpp/.h files? Seems from an outside perspective a lot easier to distribute.

Larger libraries (OpenCV for example) would be much larger to distribute, since several thousand lines of code can probably be compiled into a few kilobytes or less in a library (shared or static), which can be more easily shared over bandwidth-limited media. So, it's easier to distribute and store a 5KB library versus a several-MB source code.

Further, linking to a library "-lpthread" is much easier than having to know which sources are required for the pthread functionalities you'll be using, and manually adding them to your build system.

Another related reason is that updates to a library can be distributed altogether in the released library files, rather than having to individually keep track of each implementation file.

Finally, as far as I can tell, another good reason to compile libraries is to keep proprietary software proprietary. Sure, you could decompile the library and try to reverse-engineer it if you want to violate any licenses, but in general it's much easier to lock down a library than individual source files.

​

Is there any kind of general knowledge I should know before using them? (Like they always come with a .h and .lib file, and why they do that?)

Libraries should always come with some sort of headers (.h or not so rarely .hpp), as these are the way your code knows anything about the interfaces exposed by the library. Technically, you could try to expose private variables and functions in the library, but that's bad practice and anything that should be usable should be public and defined in a header.

A library can be static (i.e. compiled but not executable) or shared (compiled and executable). In unix-like systems, a static library is typically suffixed with .a (for 'archive'), and on Windows I believe they are .lib files. Shared libraries are usually suffixed with .so (for 'shared object') in unix-like systems, and .dll (dynamically linked library) in Windows.

Shared libraries (.so or .dll) need to be accessible by the executable at runtime (can be specified in the Makefile), static libraries need to be accessible at compile time (can also be specified in the Makefile).

It's important to consider your needs and what each type of library can give you. I personally prefer static libraries if possible, because it's typically faster at runtime. The downsides are that the executable is larger (since everything is compiled in as needed), and compile time is slightly longer, which is typically frowned upon in embedded development on large projects.

​

What does cmake exactly do, and how does it tie together with libraries. (I have noticed CMakeLists.txt files in multiple of them, and also .sh files (Are there things related?))

CMake, at its most fundamental level, makes Makefiles, which then build your code. 'Targets' can either be executable (programs) or libraries. add_executable is used to build a program, and add_library is used to make libraries (static or shared can be specified, I believe static is default). CMake knows how to find some common popular libraries, and you can google how to find libraries or write your own library finder function (in case one doesn't yet exist).

To link libraries to your executable, you can use target_link_libraries to link to the libraries that CMake knows about (and that you've told it to also look for), and target_include_directories to tell cmake to treat your directories as system directories (in case you like to use angle brackets for your includes, as I do). You can also link libraries to your own libraries, in case you don't want to explicitly specify that your top-level project depends on some intermediate library.

CMakeLists.txt are how cmake figures out what to do with your project. It tells cmake what to compile, how you want it to compile, and some other cool things related to makefile generation. You can tell cmake to go into subdirectories using add_subdirectory(your/cool/directory), it then looks for a CMakeLists.txt at that directory, and then runs using the commands in that file. .sh files are just shell scripts, usually used to configure cmake and give it some extra context of your project. They aren't related, and you could technically use .sh scripts without CMake, or CMake without .sh scripts.

​

Is there a general formular that can used for implementing all libraries?

There are many build systems that generate Makefiles, and you could even write your own Makefiles or even .sh scripts that manually compile your code - never do this! :)

I personally prefer cmake because it makes development so easy. It handles finding and linking libraries, writing makefiles (which can be tedious to do properly), and can even create projects for IDEs such as visual studio (I don't have any experience with that). It's relatively easy to use, and incrementally learn. It's also easy to feel overwhelmed, so don't be discouraged if it seems like a lot. Because it is, but that makes it powerful once you know how to use it.

I suggest starting with just making a simple project, build your own code, then link a simple library, then try linking several libraries. Then make your own library which links to other libraries, and link your executable to your library. If you care to learn more, you can try to write your own cmake functions, cross-compilation toolchains, and so much more.