3 ms·

The language itself has made enormous progress, but build-systems and lower-level concerns like linkers and compiler idiosyncrasies still plague even simple pro

The language itself has made enormous progress, but build-systems and lower-level concerns like linkers and compiler idiosyncrasies still plague even simple projects. Tools like vcpkg paper over the horror that is cmake and more isolated build environments and could ultimately be de-facto, but even then things like mixed-version dependencies and system libraries are large barriers to entry in getting started and distributing serious work. (This applies mostly to new projects adopting modern C++. Projects that are already established in my experience don't usually have to invest much in way of their tooling and build-system provided they're not adding new dependencies or platforms on a super regular basis. We recently upgraded a 100k+ SLOC program from C++17 to C++20 and only one or two very small things failed to compile. Once the system works the system tends to stay working.) The standards committee has stayed away from delving into these issues. Perhaps with good reason. But without an official stance on how to go from "well-formed code to binaries" that covers real-world use-cases, it's hard to imagine C++ being new-learner-friendly. Perhaps modules and other newer features will obviate some of those build-like features and the problem will be more tractable by the time C++25 (?) comes around.

PaulDavisThe1st 5y ago
> Tools like vcpkg paper over the horror that is cmake and more isolated build environments and could ultimately be de-facto Given that I've been working with C++ for nearly 30 years, have used autotools, cmake, meson and waf but have never heard of vcpkg, it seems unlikely to me that such a thing is going to be the de facto anything. > But without an official stance on how to go from "well-formed code to binaries" that covers real-world use-cases, it's hard to imagine C++ being new-learner-friendly. Binaries are platform specific (especially installers). I don't want my language (which should almost necessarily be platform independent) grappling with or trying to tell me how to deal with them. Understanding that creating binaries is a potentially complex task that is largely (though not totally) independent of writing code is an important step for programmers working in compiled languages.
- ryanianian 5y ago
  > 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

> Tools like vcpkg paper over the horror that is cmake and more isolated build environments and could ultimately be de-facto Given that I've been working with C++ for nearly 30 years, have used autotools, cmake, meson and waf but have never heard of vcpkg, it seems unlikely to me that such a thing is going to be the de facto anything. > But without an official stance on how to go from "well-formed code to binaries" that covers real-world use-cases, it's hard to imagine C++ being new-learner-friendly. Binaries are platform specific (especially installers). I don't want my language (which should almost necessarily be platform independent) grappling with or trying to tell me how to deal with them. Understanding that creating binaries is a potentially complex task that is largely (though not totally) independent of writing code is an important step for programmers working in compiled languages.

ryanianian 5y ago
> 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.