3 ms·

That's funny, because I think C libraries and applications are, by and large, much easier to build and install than software written in any other language. I'v

That's funny, because I think C libraries and applications are, by and large, much easier to build and install than software written in any other language. I've written distribution packages for a lot of free software, and the ol' ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. This is a really bad regression in software development. edit: I should note that the ./configure && make style of building a la Autotools is not C specific. I've seen other projects written in other languages use it and building their software is just as easy as a C project.

msbarnett 11y ago
> ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. ./configure && make && make install is wonderfully simple -- iff your system already has all of the package's dependencies installed. Otherwise you're left to manually track down ./configure && make && make install every dependency, and all of their dependencies, etc. In reality nobody does this, and system package managers are imperfectly providing for C/C++ what language-specific, cross-platform package managers are providing for the communities of Rust, Ruby, et al. Consequently the C/C++ community is more balkanized/less integrated across platforms.
- davexunit 11y ago
  It's not the job of the build system to manage dependencies. Conflating the two has contributed greatly to the packaging mess we're in today.
  - msbarnett 11y ago
    There's certainly a strong Old School mentality in the C/C++ that says that you throw code into a repository somewhere with build instructions, and if other people want to use it in their project it's on them to package it for their system and worry about coordinating, building, and installing other dependencies. There is no "language community" so much as a Debian community and an Arch community and an OS X community and a Windows community and each and every platform should attempt to "Package the World" and solve this problem in its own way. The author cares not. Count me among the New School that feels that if you want to share your code, you package it yourself, declare its dependencies in a standard way and throw it into a central, community organized place and the whole community immediately benefits from it using a standard tool that pulls down your package and its dependencies on demand, regardless of platform. Having come to the New School from the Old School, it moves so much faster, and there is infinitely less friction when it comes to sharing code. To point at an obvious example, Common Lisp post-Quicklisp is an infinitely more pleasant and vibrant community to work in than it ever was previously. Agree to disagree, I guess.

msbarnett 11y ago

> ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. ./configure && make && make install is wonderfully simple -- iff your system already has all of the package's dependencies installed. Otherwise you're left to manually track down ./configure && make && make install every dependency, and all of their dependencies, etc. In reality nobody does this, and system package managers are imperfectly providing for C/C++ what language-specific, cross-platform package managers are providing for the communities of Rust, Ruby, et al. Consequently the C/C++ community is more balkanized/less integrated across platforms.

davexunit 11y ago
It's not the job of the build system to manage dependencies. Conflating the two has contributed greatly to the packaging mess we're in today.
- msbarnett 11y ago
  There's certainly a strong Old School mentality in the C/C++ that says that you throw code into a repository somewhere with build instructions, and if other people want to use it in their project it's on them to package it for their system and worry about coordinating, building, and installing other dependencies. There is no "language community" so much as a Debian community and an Arch community and an OS X community and a Windows community and each and every platform should attempt to "Package the World" and solve this problem in its own way. The author cares not. Count me among the New School that feels that if you want to share your code, you package it yourself, declare its dependencies in a standard way and throw it into a central, community organized place and the whole community immediately benefits from it using a standard tool that pulls down your package and its dependencies on demand, regardless of platform. Having come to the New School from the Old School, it moves so much faster, and there is infinitely less friction when it comes to sharing code. To point at an obvious example, Common Lisp post-Quicklisp is an infinitely more pleasant and vibrant community to work in than it ever was previously. Agree to disagree, I guess.