21–30 of 69 posts
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.
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…
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/
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.
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.
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.
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.
Running containers on Windows requires a full VM in parallel. Docker just hides it.
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 an…
I'm sure with certain languages/runtimes you can leverage the package/dependency manager to serve the same purpose, but I imagine having a docker image for this would mean everyone's using the same base OS with the same installed library versions. This way anyone who wants to contribute to your OSS project can clone the repo, run a simple command to initialize the dev environment, and start hacking right away.
As an aside, I completely agree with your sentiment about trying to learn about the actual tech rather than just being sold on some sales pitch targeted towards less tech-savvy crowds. The best "solution" I've found for this problem myself is to educate myself as much as I can on the fundamentals of the problem space and try to reason about that decision myself.
For example, I haven't done much of a deep dive into docker yet but have spent a lot of time trying to learn as much as I can about the fundamentals/primitives provided by operating systems and kernels. I feel this way I can always reference back to basics and make a better decision of whether something is gimick-y or not.
Lately I've been so frustrated with people selling these "solutions" yet not having any understanding of the how things work that I've spent the last 3 years trying to learn as much as I can about infrastructure primitives (TCP/IP + general networking theory, database theory + database engines, and OS/kernel internals). It takes a lot of time but I definitely think it's worth it since it's a lot harder to be "fooled" when you actually understand things from the bottom up, for some definition of "bottom". It also helps that I work in this space professionally, so the investment in learning these things literally pays off.
Anyway, that's the end of my rant : )
What are the advantages vs just downloading g++ 7?
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 an…
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…