
Clang 5 in a Docker container for C++17 - ingve
https://solarianprogrammer.com/2017/12/14/clang-in-docker-container-cpp-17-development/
======
mbel
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
have minimal or zero dependencies.

~~~
banachtarski
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.

~~~
viraptor
> 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.

~~~
mbel
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".

~~~
viraptor
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.

------
rjzzleep
Just pick a random tool, throw it in docker and farm karma.

IIRC even though windows 10 might support docker through WSL sometime in the
future, for now it's just spinning up a vm like on mac. Is it possible to have
multiple lxss with different base images in windows 10(because then you'd just
use a ppa or something)?

So we have a VM which pulls in a bunch of layers. At that point, you might as
well just distribute a full vm through vagrant, then your vagrant up is just a
one liner.

I dual boot my laptop with macos and linux, but am I seriously the only one
with 256GB space that has to worry about how many vms/docker layers get
pulled?

I kinda liked gentoo prefix, far superior to homebrew imho. I used to update
some llvm patch for various versions[1], but the lack of binary packages and
smooth developer experience is what killed it IMHO.

[1]: [https://github.com/fishman/timebomb-gentoo-osx-
overlay/tree/...](https://github.com/fishman/timebomb-gentoo-osx-
overlay/tree/master/sys-devel/llvm)

~~~
bigdubs
Docker for mac doesn't use a virtualbox, it uses "HyperKit".

> Docker for Mac does not use VirtualBox, but rather HyperKit, a lightweight
> macOS virtualization solution built on top of Hypervisor.framework in macOS
> 10.10 Yosemite and higher.

[https://docs.docker.com/docker-for-mac/docker-
toolbox/](https://docs.docker.com/docker-for-mac/docker-toolbox/)

~~~
viraptor
Yeah, that's a VM they're describing. They need a tiny wrapper running with
its own Linux kernel.

------
0xcde4c3db
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.

~~~
mewse
I do exactly this; my build system does its builds for most platforms inside
docker containers. (I haven't figured out how to do OSX builds inside a docker
container yet, but I'll figure it out eventually!)

One of my targets is SteamOS (i.e.: Linux with a particular set of pre-
installed shared libraries), and the preferred build environment to target
that is inside a chroot. So my SteamOS builds get built inside a chroot inside
a docker container. And that was surprisingly tricky to get working! There are
some gotchas to overcome around how chroots handle symbolic links inside a
docker container. But I've got it all working now. :)

The big benefit is that host-OS-upgrades-for-security-purposes no longer
upgrade my build's toolchain as a side-effect, potentially breaking or
changing the performance of my build artifacts; it's fine to keep running
ancient software inside that docker container that's just going to be wiped
out in 10 minutes and never gets directly connected to the Internet anyway.
And the docker image can be copied around to wherever I need it, if I need
extra build workers or whatever. Once you've got the thing set up once, it's
fantastic for scaling up your build server if you eventually want to do that.

------
jsteemann
Recent versions of several Linux distributions and FreeBSD have made newer
clang and g++ versions available, which both have decent support for C++17
features.

For example, Ubuntu 17.10 provides clang-5.0-3 and g++ 7.2.0. Installing clang
5 there is as easy as

    
    
        sudo apt install clang-5.0
    

It's also easy to install various compilers side-by-side there, without
messing up the entire system.

For die hard everyday C++ development, one probably does not want the C++
compiler run in a somewhat restricted container and experience all the
potential trouble and limitations.

However, containerizing the compiler is a good way for providing a
standardized build environment, because one can pin the exact versions of the
compiler, libraries etc.

I have also seen people moving all their not-so-important stuff and/or the
components that they do own maintain themselves out into Docker containers, in
order to keep their base systems lean and clean. And so they can get rid of
the containerized things easily should they become irrelevant. Plus keeping
the containerized things relatively stable and unaffected by changes to the
base system.

~~~
nly
> Recent versions of several Linux distributions

Hell, even on CentOS 7 you can install devtoolset-7 and get GCC 7.2.1

------
gumby
Seems like a lot of work for what really is a simple process.

We build our code on MacOS with a simple Makefile that builds all of
xcodebuild, g++7 (from Homebrew) and llvm-5 (again via homebrew) without any
fancy standing on our heads. Works out of the box and doesn't interfere with
the system tools.

If you can't control what's on your PATH variable and your compiler options a
container won't save your build process.

------
git-pull
Check this out: [https://github.com/sol-prog](https://github.com/sol-prog)

Solarian programmer seems to be a talented C++ coder.

Thanks for the projects.

The Docker post was a niche thing. There's other posts for getting a system
running with Clang 5 on other platforms:
[https://solarianprogrammer.com/2017/12/13/linux-wsl-
install-...](https://solarianprogrammer.com/2017/12/13/linux-wsl-install-
clang-libcpp-compile-cpp-17-programs/). Another cool post about C++17 and
raspberry pi a few days earlier:
[https://solarianprogrammer.com/2017/12/08/raspberry-pi-
raspb...](https://solarianprogrammer.com/2017/12/08/raspberry-pi-raspbian-
install-gcc-compile-cpp-17-programs/)

Sure, I wouldn't use Clang in a Docker container (heh). But there are some
points. If building from LLVM+Clang from source, installing files/headers and
such can mess up systems royally. One docker container could theoretically
test drive clang everywhere without mucking up a system.

------
the8472

      $ pacman -Ss clang
      extra/clang 5.0.0-1 [installed]
          C language family frontend for LLVM
    

Why would I need a container for this?

------
sigjuice
Docker is useful for many things but why is is necessary here? It is trivial
to have a second copy of clang in a separate directory and just run it from
there.

------
alpb
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?

------
enriquto
A few years ago, serious people mocked those who proposed to use only static
linking.

Today, serious people mock those who refuse to distribute a whole operating
system along each program.

------
andrepd
What are the advantages vs just downloading g++ 7?

~~~
tzahola
You can write a blogpost about it.

------
arximboldi
Too bad they are on Windows. Otherwise they could just use Nix:
[https://nixos.org/nix](https://nixos.org/nix) or Guix:
[https://www.gnu.org/software/guix/](https://www.gnu.org/software/guix/)

~~~
roberthensing
Nix does run on Windows Subsystem for Linux these days.

~~~
arximboldi
And can it interact nicely with the "native" environment? I.e. build MSVC
projects or ".exe" apps in general that can be used outside of Nix or WSL? I
am not a Windows dev but I am very curious, it would be nice to move some
cross-platform projects I work on to Nix completely for dev environment...

------
brian_herman
Clang offers windows binaries on their site and I think it is compatible with
visual studio.
[http://releases.llvm.org/download.html](http://releases.llvm.org/download.html)

~~~
EpicEng
And VS supports C++17 anyway

------
inamberclad
Just occurred to me: if Docker is a container software and not a vitalization
software, how does it run Linux executables on an OSX host?

~~~
TheDauthi
It runs on top of a user-space virtual machine (xhyve, IIRC) that runs on
Hypervisor.framework that IS running linux.

------
dboreham
The buzz-word dot product is strong in this one..

