Live data from Hacker News

Clang 5 in a Docker container for C++17

solarianprogrammer.com

11–20 of 69 posts

Re: Clang 5 in a Docker container for C++17

#11
post #9

Earlier quoted context omitted.

My thought exactly. Not only that, but MSVC supports C++17 features natively so I have no idea why you'd want to do this on Windows. Granted, the state of C++ on MacOS is embarrassingly bad.

> so I have no idea why you'd want to do this on Windows. If you're trying to write portable software, that's the easiest way to validate compilation for Linux without: a) using an external CI, or b) running a full VM in parallel.

Well, since we are speaking about clang there is always cross compilation option: "clang -target x86_64-linux" (note, that it supports all targets that your current build of clang has enabled).

But probably the real option (c) that you are missing here is the fabulously named "Windows Subsystem for Linux".

Re: Clang 5 in a Docker container for C++17

#12
Doesn't sound like a great idea to run a CPU-intensive application like a compiler in "Docker for Mac" which is a VM.

Why do you need a container for that? Can’t you just `brew install clang`, and when you no longer need it, uninstall cleanly?

Re: Clang 5 in a Docker container for C++17

#13
post #2

It feels like cargo-cult computer usage. The description states: "Running Clang in a container has the advantage that it is light on resources and won’t mess with your underlying OS.". Containers aren't really light on resources if the host kernel is not Linux and not messing with OS is easily attainable by installing the binaries in a custom prefix directory (e.g. ~/bin). This is especially true for compilers which…

My thought exactly. Not only that, but MSVC supports C++17 features natively so I have no idea why you'd want to do this on Windows. Granted, the state of C++ on MacOS is embarrassingly bad.

> Granted, the state of C++ on MacOS is embarrassingly bad.

In what sense? Apple keeps Clang up to date on macOS, and it is essentially no work to get the associated Clang tooling and other C++ tools (valgrind, etc) installed through something like homebrew.

Re: Clang 5 in a Docker container for C++17

#16
Does Docker for build environments make a lot of sense? I want to package up an existing environment that predates Docker (by long enough that I don't think there's an old enough base OS image on Docker Hub unless I leverage J. Random Hacker's image that's been tweaked for another project) to make it more portable. Would I be fighting against the design of the tool? Perhaps it would be better to just make a chroot and tar it up? I've tried to educate myself on the tool and make my own judgment, but it's surprisingly hard to find material about Docker that is actually about Docker instead of primarily being a sales pitch for containers and microservices that happens to describe them in Docker terms.

Re: Clang 5 in a Docker container for C++17

#17
post #2

It feels like cargo-cult computer usage. The description states: "Running Clang in a container has the advantage that it is light on resources and won’t mess with your underlying OS.". Containers aren't really light on resources if the host kernel is not Linux and not messing with OS is easily attainable by installing the binaries in a custom prefix directory (e.g. ~/bin). This is especially true for compilers which…

I just ran "pkg install llvm50" on FreeBSD. Easy, quick, and noninvasive; it's not like installing another compiler is going to trash your system, you still have to take action to use it in place of the default. Likewise on Linux, you've always been able to install multiple compilers, and I've never had a problem with that in the two decades I've been doing it.

I can see containers are sometimes useful and/or a convenience, but you're right it is currently some weird cargo-cult. I don't find it that lightweight either; it can waste serious amounts of space storing all the different images and intermediate states in Dockerfiles. At least on FreeBSD I can use jails with ZFS snapshots (and dataset compression) to keep space wastage to a minimum, and have it quickly freed when I'm done with them without any extra effort.

Re: Clang 5 in a Docker container for C++17

#18
post #11
post #9

Earlier quoted context omitted.

> so I have no idea why you'd want to do this on Windows. If you're trying to write portable software, that's the easiest way to validate compilation for Linux without: a) using an external CI, or b) running a full VM in parallel.

Well, since we are speaking about clang there is always cross compilation option: "clang -target x86_64-linux" (note, that it supports all targets that your current build of clang has enabled). But probably the real option (c) that you are missing here is the fabulously named "Windows Subsystem for Linux".

Re crosscompilation: Sure, if you want to prepare an environment which has all the dependencies, then that is a way you can take. I always found it harder than using the target system directly. And in the end if you're running any tests after compilation, you still need the target system for that.

Re WSL: If the app you're working on works on WSL, great. It's not an option for many projects though.

Re: Clang 5 in a Docker container for C++17

#19
post #9

Earlier quoted context omitted.

My thought exactly. Not only that, but MSVC supports C++17 features natively so I have no idea why you'd want to do this on Windows. Granted, the state of C++ on MacOS is embarrassingly bad.

> so I have no idea why you'd want to do this on Windows. If you're trying to write portable software, that's the easiest way to validate compilation for Linux without: a) using an external CI, or b) running a full VM in parallel.

Running containers on Windows requires a full VM in parallel. Docker just hides it.

Re: Clang 5 in a Docker container for C++17

#20

Earlier quoted context omitted.

My thought exactly. Not only that, but MSVC supports C++17 features natively so I have no idea why you'd want to do this on Windows. Granted, the state of C++ on MacOS is embarrassingly bad.

> Granted, the state of C++ on MacOS is embarrassingly bad. In what sense? Apple keeps Clang up to date on macOS, and it is essentially no work to get the associated Clang tooling and other C++ tools (valgrind, etc) installed through something like homebrew.

> Apple keeps Clang up to date on macOS,

Actually, not especially. The system compiler that ships with Xcode is still quite old and the libraries are quite out of date. For example, though the most recent Xcode finally added -std=c++17 it still lacks core library features like std::variant. I wish they could keep close to mainline but for whatever reason they can't.

Post reply on HN