Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the theoretical reason for C++ dependency production not being automated?

Tags:

c++

build

C++ Buildsystem with ability to compile dependencies beforehand

Java has Maven which is a pleasure to work with, simply specifying dependencies that are already compiled, and deposited to Mavens standard directory, meaning that the location of the dependencies is standardized as opposed to the often used way of having multiple locations (give me a break, like anyone remembers the default installed directories for particular deps) of C/C++ dependencies.

It is massively unproductive for every individual developer having to, more often than not, find, read about, get familiar with the configure options/build, and finally compile for every dependency to simply make a build of a project.

What is the theoretical reason this has not been implemented?

Why would it be difficult to provide packages of the following options with a maven-like declaration format?

version
platform (windows, linux)
src/dev/bin
shared/static
equivalent set of Boost ABI options when applicable

Having to manually go to websites and search out dependencies in the year 2013 for the oldest major programming language is absurd.

like image 349
MetaChrome Avatar asked Jan 10 '13 17:01

MetaChrome


3 Answers

There aren't any theoretical reasons. There are a great many practical reasons. There are just too many different ways of handling things in the C++ world to easily standardize on a dependency system:

  • Implementation differences - C++ is a complicated language, and different implementations have historically varied in how well they support it (how well they can correctly handle various moderate to advanced C++ code). So there's no guarantee that a library could be built in a particular implementation.
  • Platform differences - Some platforms may not support exceptions. There are different implementations of the standard library, with various pros and cons. Unlike Java's standardized library, Windows and POSIX APIs can be quite different. The filesystem isn't even a part of Standard C++.
  • Compilation differences - Static or shared? Debug or production build? Enable optional dependencies or not? Unlike Java, which has very stable bytecode, C++'s lack of a standard ABI means that code may not link properly, even if built for the same platform by the same compiler.
  • Build system differences - Makefiles? (If so, GNU Make, or something else?) Autotools? CMake? Visual Studio project files? Something else?
  • Historical concerns - Because of C's and C++'s age, popular libraries like zlib predate build systems like Maven by quite a bit. Why should zlib switch to some hypothetical C++ build system when what it's doing works? How can a newer, higher-level library switch to some hypothetical build system if it depends on libraries like zlib?

Two additional factors complicate things:

  • In Linux, the distro packaging systems do provide standardized repositories of development library headers binaries, with (generally) standardized ABIs and an easy way of specifying a project's build dependencies. The existence of these (platform-specific) solutions reduces the impetus for a cross-platform solution.
  • With all of these complicating factors and pre-existing approaches, any attempt to establish a standard build system is going to run into the problem described in XKCD's "Standards":
    Situation: There are 14 competing standards.
    "14? Riculous! We need to develop one universal standard that covers everyone's use cases."
    Soon: There are 15 competing standards.

With all of that said:

There is some hope for the future. For example, CMake seems to be gradually replacing other build systems. Some of the Boost developers have started Ryppl, an attempt to do what you're describing.

like image 119
Josh Kelley Avatar answered Oct 21 '22 07:10

Josh Kelley


(also posted in linked question)

Right now I'm working on a tool able to automatically install all dependencies of a C/C++ app with exact version requirement :

  • compiler
  • libs
  • tools (cmake, autotools)

Right now it works, for my app. (Installing UnitTest++, Boost, Wt, sqlite, cmake all in correct order)

The tool, named «C++ Version Manager» (inspired by the excellent ruby version manager) is coded in bash and hosted on github : https://github.com/Offirmo/cvm

Any advices and suggestions are welcomed.

like image 32
Offirmo Avatar answered Oct 21 '22 07:10

Offirmo


well, first off a system that resolves all the dependencies doesn't makes you productive by default, potentially it can make you even less productive.

Regarding the differences between languages I would say that in Java you have packages, which are handy when you have to organize and give a limited horizon to your code, in C++ you don't have an equivalent concept. In C++ all the libraries that can solve a symbol are good enough for the compiler, the only real requirement for a library is to have a certain ABI and to solve the required symbols, there are no automated ways that you can work to pick the right library, also solving a symbol it's just a matter of linking your function to the actual implementation, this doesn't even grant you that a correct linking phase will make your app work.

To this you can add important variables such as the library version, different implementations of the same library and different libraries with the same methods name.

An example is the Mesa library VS the opengl lib from the official drivers, or whatever lib you want that offers multiple releases and each one can solve all the symbols but probably there is a release that is more mature than the others and you can ask a compiler to pick the right one because they are all the same for its own purposes .

like image 1
user1849534 Avatar answered Oct 21 '22 07:10

user1849534