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.
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.
I find your example of installing a package to be somewhat amusing.
The fact that one can install a package in some OS means that somewhere, one or more people sat down and wrote a recipe for building and packaging it, and then hopefully performed some minimal QA on the final product to make sure it actually works.
This is not trivial, particularly not if multiple versions of a compiler may need to coexist (because of other packages depending on a particular version), and it needs to be done for each combination of compiler version and OS.
To me, examples like: "just run <insert package installation command here>", expecting a package to just magically install itself on some OS are the symptoms of a cargo-cult.
Rather, I think that using containers is more like outfitting a cargo container with a fully stocked and staffed workshop, then shipping the container and personnel to where the client needs it to be. The client then only needs to supply the storage space for the container and the goods that need processing (a shared directory in this particular case) and wait for the finished result.
Sure, some of the workers may not speak your language, they may use different tools, but until (if?) the workshop gets rebuilt and staffed on "native soil", the inconvenience should be acceptable.
Not to mention Docker on OSX just runs an underlying Virtualbox (HyperKit on newer versions) instance. So just run the VM, Docker is not doing anything
Not to mention if I had a dime for every case of people running full-blown distros under docker I would have been a millionaire by now
> 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.
Technically, yes. But by full VM, I mean a parallel desktop/server system with permanent storage that you have to maintain in different ways to a temporary container. Same technologies, different user experience. Docker hides it by providing a nice layer on top.
Clang on Windows (not cross targeting) is faster for basically no performance loss (it's in the noise for chrome). It's actually very significant performance gain in some cases. Build time savings is literally hours on official builds.
Cross-targeting from linux is probably slower ATM (clang-cl is not fast :P)
That said, if you have a single compiler you can use across platforms, and it generates the best code (or within a small enough percent), and enables a suite of cross-platform dynamic error checking capabilities (ASAN, etc), that provides significant productivity/etc advantages for people. Especially when you can easily improve them according to your own engprod priorities.
The label worst std support would go to: EDG eccp, Intel C++, IBM XLC++, Sun/Oracle C++, Embarcadero C++ Builder, Cray, HP aCC [Collapse], Digital Mars C++
MSVC has very bad C support, this is their problem, not C++.
Yes, that's true. Their overall C support is horrible, esp. up to C99.
But they were still the first ones who implemented C11, which gcc and clang refuse to do.
I'm sorry but this MSVC C11 claim is complete nonsense.
C11 is an extension of C99, so you can't have C11 support without C99.
But this nonwithstanding, MSVC doesn't appear have wide support for post-C99 C11 features either. For example, _Generic and t.
Are there any parts of C11 that MSVC supports aside from the Annex K functions, which is optional in C11? Annex K happens to be an extension proposed by Microsoft, so it's small wonder they implement it and it's quite disingenious to talk up microsoft for C11 support in this case. Other vendors didn't think it was very good, so didn't implement that optional feature.
And contrary to your claim, gcc and clang seem to have quite good C11 support.
Well, MSVC supports those eye candy features yes. But it doesn't implement the C++ in the standard conforming way. Name lookup, overload resolution, and templates and practically everything is not implemented according to the spec.
Really, it's garbage and it shouldn't be considered as C++ compiler.
Maybe one reason one might prefer using Clang over MSVC is that it's open source and it runs on all major platforms so you're hopefully less likely to run into issues. Although I admit I'm just taking a guess, since I'm only a casual Windows user.
I write many simple scripts with node just because it works everywhere with minimal quirks. I also have a few incredibly simple web apps which I use to visualize or explore small datasets. It's great to able to open up an html file in the browser and have it work everywhere.
Docker containers aren't an ideal solution, but they make it easier to get things running everywhere. Consider why stuff like Electron is so popular, despite its many quirks.
> 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.
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.
I'm not quite clear about your point. The version of Clang that Apple ships, for whatever reason, is pretty far behind the released Clang. I cited std::variant as an example of something which has been in the public Clang for ages.
As far as compiler support goes, Clang supports all of C++17 except for P0522R0 which is a defect report (ambiguity in specification) so cannot be implemented as written. Ditto GCC.
However std::variant is a library entity, not a compiler entity, and indeed, the libraries are a bit behind. Neither GCC's nor LLVM's runtime library support the parallelism extensions and have other gaps in areas exotic (memory, unfortunately which I would like to use) and prosaic (filesystem, which though I'd like to use it as well don't really care about). But they have been solid on C++17 core functionality for quite a long time.
C++ isn't as important to Apple as Swift (or even, still, ObjC) and C++17 is pretty new, so one can hardly blame Apple for this, especially since it's so trivial to simply use another compiler.
No it's awful. They are most certainly not up to date, and even worse, the compilers they ship that advertise certain flags aren't even necessarily feature complete. A glaring example of this was the lack of thread_local support for ages.
Yup. It was only about a year ago that the undefined behaviour sanitizer stopped segfaulting when I turned it on, despite it being clearly "documented" in the man page. I'm amazed that a company with the resources of Apple has such shoddy developer tools.
"AppleClang" is some strange fork with some features (both compiler and library) omitted or broken. OpenMP, for example, is one thing I've been missing for a good while; I've not checked if that's now present with new releases. I can understand adding extra functionality to a fork, like Objective C and swift stuff, but dropping bits is strange.
It's due to issues like this that I do all our clang testing on FreeBSD, where it's a more vanilla build of the llvm codebase, and I treat AppleClang as a wholly separate compiler variant which requires independent testing.
I think clang's OpenMP implementation might not be 100% ready? Many FreeBSD ports that have an OPENMP option straight up use gcc when that option is enabled.
While docker is pretty bloated and doesn't really add new capabilities, I've found it a real time-saver for distributing cross-platform build environments to a dev team running multiple Linux/osx releases, especially when those build environments are used only a few times per year.
Probably a VM or really good scripts could take care of it, but since we use docker elsewhere people don't have to learn something new that they'd treat as a black box anyway
Eh, I made a G++7 container for using with CircleCI. Makes life a lot easier (and is faster) than screwing around with running scripts before each build
No, it is rather vague what the original article means by "won’t mess with your underlying OS". And your "underlying OS won't mess with it" is equally vague too, IMHO. Providing some examples of "mess with" will be helpful.
Unless you've found a serious bug / security vulnerability, Docker doesn't mess with your OS. On OSX / Windows (and this is definitely an argument against Docker ux), it's not even running on your OS but a separate VM.
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.