3 ms·
Nevermind the language itself, we need a way to pull compilers and project dependencies, pinned to their specific versions, with a single, ergonomic tool. vcpkg
by diath 3y ago
Nevermind the language itself, we need a way to pull compilers and project dependencies, pinned to their specific versions, with a single, ergonomic tool. vcpkg seemed really promising but the fact that they didn't start with library versioning from the get go was a very stupid decision, and nowadays versions are pinned to specific commit hashes rather than actual dependency versions, and libraries that weren't previously versioned cannot be fetched if your project relies on an older pre-vcpkg version of a library and cannot be upgraded for one reason or another. These days I find myself struggling more and more with proper dev setup where I have an up-to-date compiler on any machine I want to build the code along with its libraries without running into a rabbit hole of compiler and library issues.
- bqmjjx0kac 3y agoHave you looked into Bazel? https://bazel.build/start/cpp https://bazel.build/start/cpp It's not always easy to use, but the focus on reproducible builds and caching is really nice. Edit: I guess it doesn't fetch a specific compiler for you by default, but you could probably ship your toolchain somewhere and pin it in your WORKSPACE file.
- steveklabnik 3y agoDon't forget buck2 as well.
- andrewmcwatters 3y agovcpkg was dead in the water because they altered source packages. Completely unacceptable in many situations.
- kimixa 3y agoI also find vcpkg extremely fragile. Not in that pinning versions or the APIs or the actual contents of the packages we rely on, so much that every time we update a (rather small) set of dependencies there's nearly always some weirdness around vcpkg itself or the builds. Just the last week we updated to a newer tag and building openssl failed setting up the nasm build dependency, claiming it already existed. Which it did - there was a "nasm" folder in the tools directory it was trying to install it in, from the last time it was installed presumably and somehow got it's internal state messed up. But this caused a fatal error. I eventually worked around it by deleting the nasm directory from every build machine and letting it reinstall exactly the same package again. But the time before there was also a "random" build error, claiming that xz wasn't installed, despite the log showing it was just installed as a dependency in the line above. I guess this was fixed upstream, as the "workaround" was to use a tag from a month or so previous, but now seems to be fixed. Perhaps I'm using it wrong, perhaps you should "always" completely blast away the global vcpkg folder (and any vcpkg stuff cached in build directories from it's cmake integration) every time you touch it. But it's still time and effort for something that probably should be seamless.
- initplus 3y agovcpkg are forced to alter source packages because in the majority of cases upstream doesn't have working cross platform builds. They have weird broken CMakeLists.txt, incomplete compiler support, weird build incompatibilities with other libraries etc.
- throwaway81523 3y agoIn critical embedded development they snapshot the entire VM containing the OS, compilers, entire tool chain, and everything else.
- JohnFen 3y agoIn the olden days, we always checked the compiler, libraries, and essential build tools being used into version control along with the code. That way you could always be sure that you could compile the code. This stopped working so well with Windows, where you usually can't just copy executables out of version control and run them (you have to run an installer instead), but it still works pretty well for the Unices.
- throwat2341 3y agoUntil then there is Nix/Guix and Bazel/Buck.