3 ms·

And why are these build systems necessary in the first place? They mostly exist to work around the lame library ecosystem, where you never know what's installed

by s_tec 7y ago

And why are these build systems necessary in the first place? They mostly exist to work around the lame library ecosystem, where you never know what's installed or where to find it. Solving the "library problem" would presumably render these tools and their horrible complexity obsolete. If there were some type of system where library A says it depends on library B (via a URL or some other non-centralized thing), and the compiler knows how to resolve this, then you don't need 90% of the features these tools provide. You still need build parallelization and maybe detection for non-standard compiler features, but this is a much smaller and simpler problem.

umvi 7y ago
> And why are these build systems necessary in the first place? Because C/C++ compilers are fragmented. And because C/C++ is not very portable. If building for windows -> pass a bunch of -D flags to the compiler. If building for Linux, pass a different set of -D flags. Different compilers require different arguments. > If there were some type of system where library A says it depends on library B ... and the compiler knows how to resolve this Here's the crux of the problem. There is no organization that owns or maintains C++, unlike Rust. With Rust, there is only one compiler - rustc. With C++ there are at least 5 major ones maintained by 5 different (competing) organizations. There's no way to do package management in C++ without massive build system rewrites. Consider: I write a new C++ package called CoolCrypto. It depends on libssl. I wrote my package in CMake, libssl uses autotools. Barf, the package manager only speaks CMake and gives up.
jcelerier 7y ago
> And why are these build systems necessary in the first place? Because depending on the use case you generally need to build the same software in a lot of different configurations : debug / release runtimes on windows, various sanitizers, static / dynamic / dynamic with LTO, you also want to build some files only on some platforms, you want your users to be able with / without tests / examples / implementations of various types (e.g. enable / disable network protocols or media codecs at build time for the two most common use cases I know), enable / disable profiling or coverage or tracing support... add a flag for having split debug info but you need to disable it if your users run ubuntu 16.04 because here it's broken, add a flag for linking with lld but you need to disable it on macos because it's broken, change debug mode to -Og if you're on a CI machine because -O0 takes too much space and you fill the Travis CI vm, except if you're on a worker with a recent enough toolchain to support -Wl,--compress-debug-sections=zlib e.g. look at the configurability of something like ffmpeg : https://paste.ofcode.org/zBhsKWiSk3Gn73bkgfA9Yk https://paste.ofcode.org/zBhsKWiSk3Gn73bkgfA9Yk or qt : https://paste.ofcode.org/wmZZX9emiNr2uPksceZNz6 https://paste.ofcode.org/wmZZX9emiNr2uPksceZNz6 or one of the project I work on - most of the config flags here were added after the request of some users who wanted to be able to make a leaner build in some specific case ; making multiple shared libraries is a no-go first because then your users complain that they don't which of the five libraries they have to add to their system, and also because you loose LTO and have a lot of duplication of template instantiations (or monomorphized generics as it is said in Rust parlance): https://github.com/OSSIA/libossia/blob/master/cmake/OssiaOptions.cmake https://github.com/OSSIA/libossia/blob/master/cmake/OssiaOpt... You rarely have complex problems with simple solutions.

by s_tec 7y ago

umvi 7y ago

> And why are these build systems necessary in the first place? Because C/C++ compilers are fragmented. And because C/C++ is not very portable. If building for windows -> pass a bunch of -D flags to the compiler. If building for Linux, pass a different set of -D flags. Different compilers require different arguments. > If there were some type of system where library A says it depends on library B ... and the compiler knows how to resolve this Here's the crux of the problem. There is no organization that owns or maintains C++, unlike Rust. With Rust, there is only one compiler - rustc. With C++ there are at least 5 major ones maintained by 5 different (competing) organizations. There's no way to do package management in C++ without massive build system rewrites. Consider: I write a new C++ package called CoolCrypto. It depends on libssl. I wrote my package in CMake, libssl uses autotools. Barf, the package manager only speaks CMake and gives up.

jcelerier 7y ago

> And why are these build systems necessary in the first place? Because depending on the use case you generally need to build the same software in a lot of different configurations : debug / release runtimes on windows, various sanitizers, static / dynamic / dynamic with LTO, you also want to build some files only on some platforms, you want your users to be able with / without tests / examples / implementations of various types (e.g. enable / disable network protocols or media codecs at build time for the two most common use cases I know), enable / disable profiling or coverage or tracing support... add a flag for having split debug info but you need to disable it if your users run ubuntu 16.04 because here it's broken, add a flag for linking with lld but you need to disable it on macos because it's broken, change debug mode to -Og if you're on a CI machine because -O0 takes too much space and you fill the Travis CI vm, except if you're on a worker with a recent enough toolchain to support -Wl,--compress-debug-sections=zlib e.g. look at the configurability of something like ffmpeg : https://paste.ofcode.org/zBhsKWiSk3Gn73bkgfA9Yk https://paste.ofcode.org/zBhsKWiSk3Gn73bkgfA9Yk or qt : https://paste.ofcode.org/wmZZX9emiNr2uPksceZNz6 https://paste.ofcode.org/wmZZX9emiNr2uPksceZNz6 or one of the project I work on - most of the config flags here were added after the request of some users who wanted to be able to make a leaner build in some specific case ; making multiple shared libraries is a no-go first because then your users complain that they don't which of the five libraries they have to add to their system, and also because you loose LTO and have a lot of duplication of template instantiations (or monomorphized generics as it is said in Rust parlance): https://github.com/OSSIA/libossia/blob/master/cmake/OssiaOptions.cmake https://github.com/OSSIA/libossia/blob/master/cmake/OssiaOpt... You rarely have complex problems with simple solutions.