3 ms·

> The actual problem are libraries with hundreds or thousands of source files in dozens of directories and a CMakeLists.txt file from hell. Why is that a probl

by brabel 3y ago

> The actual problem are libraries with hundreds or thousands of source files in dozens of directories and a CMakeLists.txt file from hell. Why is that a problem? If you have a large library, surely it's better to properly break it up into separate files?! > no need for a package manager. Well, yeah if you don't want even a build system, large projects in general become really difficult to maintain anyway. The solution seems to be like every programming language created after 1989? Have a package manager and make it irrelevant if the library contains 1 file or 1000. What's the reason C resists so much using a package manager, even when similarly low level languages like Rust and Zig have them and make them first class citizens?

flohofwoe 3y ago
> Why is that a problem? If you have a large library, surely it's better to properly break it up into separate files?! That's at best good for developing the library (even that is debatable though), but definitely not when just using the source-distribution of the library in a project. > What's the reason C resists so much using a package manager... One important problem is that there are so many package managers and build systems for C and C++ projects. So the choice for a library author is either to support all package managers and build systems (not really a realistic option), or none specifically (much better but requires that the library source distribution is designed for simple integration into projects without esoteric build requirements). Requiring a specific package manager and build system is hostile to users preferring other tools. The problem doesn't lie with C or C++ users, but with the respective language committees saying "dependency management and build system standardization isn't our problem".
tomovo 3y ago
> If you have a large library, surely it's better to properly break it up into separate files?! Sqlite solves this dilemma by providing both: regular source code repository with separate files for development and an "amalgamation" with everything in a single .c file. The latter makes it really easy to integrate.
- edflsafoiewq 3y ago
  Zstd too. IOW the single-file header (or .c/.h) is a build artifact, like a .dll.

by brabel 3y ago

flohofwoe 3y ago

> Why is that a problem? If you have a large library, surely it's better to properly break it up into separate files?! That's at best good for developing the library (even that is debatable though), but definitely not when just using the source-distribution of the library in a project. > What's the reason C resists so much using a package manager... One important problem is that there are so many package managers and build systems for C and C++ projects. So the choice for a library author is either to support all package managers and build systems (not really a realistic option), or none specifically (much better but requires that the library source distribution is designed for simple integration into projects without esoteric build requirements). Requiring a specific package manager and build system is hostile to users preferring other tools. The problem doesn't lie with C or C++ users, but with the respective language committees saying "dependency management and build system standardization isn't our problem".

tomovo 3y ago

> If you have a large library, surely it's better to properly break it up into separate files?! Sqlite solves this dilemma by providing both: regular source code repository with separate files for development and an "amalgamation" with everything in a single .c file. The latter makes it really easy to integrate.

edflsafoiewq 3y ago
Zstd too. IOW the single-file header (or .c/.h) is a build artifact, like a .dll.