4 ms·

> have never heard of vcpkg 14.4k+ stars, and it's a product from Microsoft. It uses cmake under the covers (for now?). Doesn't mean it will win, but it's a co

> have never heard of vcpkg 14.4k+ stars, and it's a product from Microsoft. It uses cmake under the covers (for now?). Doesn't mean it will win, but it's a contender. > Binaries are platform specific Yes? Each new platform has to be more or less officially adopted into a build-system. Maybe better one "official" build-system rather than dozens. Reduce the surface-area for adding a new platform and maybe it won't seem so herculean anymore. > trying to tell me how to deal with them An official build-system doesn't have to be any less feature-ful than the hodge-podge of current offerings. > creating binaries is a potentially complex task that is [...] an important step for programmers It doesn't need to be as complicated as it is today. And I don't think you intended it, but this last bit reads as dismissive and condescending. Many of us veteran C++ folks are so used to the way things have always been that it's hard to imagine an alternate universe where a sane and powerful build-system was "in the language" from the start. It may be a hard problem, but `cargo` has some interesting ideas, and I don't hear anyone complaining about not being able to do low-level and platform-specific things in Rust...

PaulDavisThe1st 5y ago
The first problem with these concepts for packaging is that they almost always start with a provably false assumption: * that there is a canonical way to build every dependency With this assumption in hand, they move to a conception in which you somehow make the dependencies available (canonically built) and then assemble your binaries (if not your actual installer) with this. But there is no canonical way to build lots of dependencies. Two reasons (at least); * software libraries with build flags that totally change their behavior. One example that I deal with is libfftw which can be built for single-threaded or multithread use (and the two should not be used in the wrong context). Of course, this can be addressed by referring to each "version" with a different name, but if there are N build flags, that causes an explosion of possible variant names. Another example would include libraries that have hard-coded search paths (this is NOT automatically wrong) that are set at build time; the search paths may differ depending on the target platform. The "appropriate" location for dynamically-loaded modules, for example, differs even among Linux systems, because of the behavior of the system's dynamic linker. Plugins (compiled to dynamically-linked objects, loaded at run time based on user input) are always problematic because they have their own build systems that can be out of sync with those of their associated SDKs. * projects that need to patch libraries with changes that, for whatever reason, will not be accepted upstream. An example for me are changes I made to GTK2 to support macOS's version of mouse events so that you can differentiate the extent of a scroll wheel "roll" correctly. My project needs this functionality, and it was never going to be part of GTK2 (the API was frozen before anyone realized that macOS handled scroll wheel events differently). So my project builds with a patched version of GTK2, not the one provided by the platform "package manager" These sorts of real world complications are easy to want to dismiss or wave away or pretend that there's some sort of magic that will make them vanish and never come back. I don't believe that this is true.

PaulDavisThe1st 5y ago

The first problem with these concepts for packaging is that they almost always start with a provably false assumption: * that there is a canonical way to build every dependency With this assumption in hand, they move to a conception in which you somehow make the dependencies available (canonically built) and then assemble your binaries (if not your actual installer) with this. But there is no canonical way to build lots of dependencies. Two reasons (at least); * software libraries with build flags that totally change their behavior. One example that I deal with is libfftw which can be built for single-threaded or multithread use (and the two should not be used in the wrong context). Of course, this can be addressed by referring to each "version" with a different name, but if there are N build flags, that causes an explosion of possible variant names. Another example would include libraries that have hard-coded search paths (this is NOT automatically wrong) that are set at build time; the search paths may differ depending on the target platform. The "appropriate" location for dynamically-loaded modules, for example, differs even among Linux systems, because of the behavior of the system's dynamic linker. Plugins (compiled to dynamically-linked objects, loaded at run time based on user input) are always problematic because they have their own build systems that can be out of sync with those of their associated SDKs. * projects that need to patch libraries with changes that, for whatever reason, will not be accepted upstream. An example for me are changes I made to GTK2 to support macOS's version of mouse events so that you can differentiate the extent of a scroll wheel "roll" correctly. My project needs this functionality, and it was never going to be part of GTK2 (the API was frozen before anyone realized that macOS handled scroll wheel events differently). So my project builds with a patched version of GTK2, not the one provided by the platform "package manager" These sorts of real world complications are easy to want to dismiss or wave away or pretend that there's some sort of magic that will make them vanish and never come back. I don't believe that this is true.