Hacker News Reader

Comment by Keyframe | Hacker News Reader

I've been setting up my little docker image that has both llvm/clang/tidy/clangd and gcc inside with boost with an idea I'd run it and from outside use it to code with live checking and compiling without littering my OS. Now, I feel like I'm doing something that already exists but couldn't really find what everyone use, ought of those that would prefer such a setup. Debugger within is probably a pipe dream, but who knows.

Basically I'd prefer to have a docker image with tooling that I can hook into.

View on HN

I find it absurd that a programming language which compells someone to set up a containerized OS just to manage their build toolchain could be considered "modern".

I cannot disagree. Gcc is trivial to compile and set with prefix however you want. Llvm behemoth, not so very much though and I'd like to have both for reasons. There's always some gotcha involved, and when you finally set it all up, you forgot what and how you did it and then you dig through shell history file to reconstruct what you did in order to replicate it on other machines or same if you nuke the OS.. blah. Rustup and cargo and pyenv and nvm even spoiled us.

It would truly be absurd to claim that C++ is a modern language. A subset of C++ however, is modern. This does not include the toolchain and standard build practices.

Your point stands, but it is/was implied, how I took it at least.

I guess that's why i went into JavaScript instead of java. I use to write HTML back when i was around 10 years old, back then java applets were the only way you could have something interactive and dynamic on your page, so i started to learn it. After a while i learned that you could do a lot of neat stuff with JavaScript. So i stopped using java.

I install Rust's toolchain and development tools inside of a container, I also do this with Python and will do it with C++ sometime in the future.

I don't do this because I have to, I do this because I prefer to keep non-system -critical software managed by non-root users and separated from the systems rootfs.

On your common desktop Linux distro, I think C and C++ toolchains are the least difficult to setup and use without a container though (for me). On Gentoo I can just emerge gcc or clang and enable whatever USE flags I want, and they are installed and updated automatically with the rest of my system.

I use the Gentoo system package manager to manage my Rust toolchain as well instead of using rustup, so that it behaves like described above, it's updated and managed automatically and with the rest of my system!

I do realize that many distros have issues with software being out of date though, and that is a big problem! With Gentoo I can install multiple versions of most things in parallel and can very easily package anything that doesn't exist yet.

Also to clarify, I use the system package manager to build and manage my containers, this is how I use the system package manager to manage Rust's toolchain but also have it inside of a container. All of my containers are just nested Gentoos that I can install stuff into with the system package manager. I can also install a package manager into the nested Gentoo and build/install stuff while "inside" of it.

I'd be really interested in a write-up of your setup with more details so I can try it.

> I install Rust's toolchain and development tools inside of a container, I also do this with Python and will do it with C++ sometime in the future.

The thing is, you don't need to do this with Rust as far as I can tell. There may be some benefits, but ultimately your project can easily specify its own compiler version, its own target directory (the default is per-project), etc. There are some shared resources like caches, which you can split if you want to.

I can see why you'd still do this - but, the main reason would be... if you have dependencies on C/C++.

> On your common desktop Linux distro, I think C and C++ toolchains are the least difficult to setup and use without a container though

In my experience, the hard part is rigorously controlling the libraries a build uses. Using CMake, it's easy enough to add libraries to a build, but harder to stop the thing going off and looking round /usr/lib64 and so on. On my physical workstation, there is all sorts of stuff in there, because i have a desktop environment and a cornucopia of tools installed. I don't want a build using any of it! If a build needs a library which i have not explicitly added, i want it to fail, not use something from the system. But between default paths and rpaths in libraries and so on, that seems hard to do in a watertight way. I've done endless fiddling with sysroot flags, but i'm not sure it's not leaking. A container takes care of all that in a very definite way.

VS Code is designed to work with these - https://code.visualstudio.com/docs/devcontainers/containers

Interesting, thanks for that. That's kind of the idea, but preferably without the 'extend' part on top of containers. I'm not using VSCode though so I'll shop around or maybe I'll convert, who knows.

Maybe nix (https://github.com/NixOS/nix) is a better tool for what you're looking for if you're on Linux, you can setup nix shells and work in them, what's installed inside the shell won't be accessible from outside.

As is with most people and nix, it's on todo list to check it out. This might be the trigger. Thanks!

Reply on news.ycombinator.com