3 ms·

I'm a big containers fan, they work really well (assuming you're not developing with MSVC). They give you a repeatable build environment, which is a boon for so

I'm a big containers fan, they work really well (assuming you're not developing with MSVC). They give you a repeatable build environment, which is a boon for something like C where you're implicitly depending on system include paths for versioning. I said this elsewhere, but you'll get a pretty decent perf boost if you set your build intermediate directory outside your mounted volume. Instead of rm -rf /var/lib/apt/lists/*, running `apt-get clean` as part of that layer will help more. Wrapping docker commands with makefiles is sad times. Use https://magefile.org/ https://magefile.org/ or a task runner instead. Try to avoid making it a scripting language dependency. Installing ruby to install a build system when you're using cmake in the container is a bit bonkers, and the cause of the majority of the "bloat" here. I'd replace it with calls to cmake and unity directly. (And honestly, if you're going as far as using cmake, I'd ditch C altogether and usea subset of C++ with gtest) But honestly, that's about all I can complain about. This is a neat, modern workflow.

GuB-42 3y ago
> I'm a big containers fan, they work really well (assuming you're not developing with MSVC). They give you a repeatable build environment, which is a boon for something like C where you're implicitly depending on system include paths for versioning. For development, I actually don't like "repeatable build environments". I like using a different, continuously updated systems, I consider having a different environment for CI/CD and for development to be a good thing. It is one of the best way to test for compatibility problems, a kind of dogfooding. Plus, it is nice working on a system you are comfortable with, and without the performance penalties of virtualization/containerization. For releasing and testing however, containers are great.
forrestthewoods 3y ago
> where you're implicitly depending on system include paths for versioning The correct thing to do, imho, is check-in toolchains to version control.
- maccard 3y ago
  Yeah that works really well. I used to use the predecessor of "Turnkey" [0] for unreal engine, and it worked absolutely great for that problem. [0] https://docs.unrealengine.com/5.0/en-US/setting-up-turnkey-for-your-organization-in-unreal-engine/ https://docs.unrealengine.com/5.0/en-US/setting-up-turnkey-f...

GuB-42 3y ago

> I'm a big containers fan, they work really well (assuming you're not developing with MSVC). They give you a repeatable build environment, which is a boon for something like C where you're implicitly depending on system include paths for versioning. For development, I actually don't like "repeatable build environments". I like using a different, continuously updated systems, I consider having a different environment for CI/CD and for development to be a good thing. It is one of the best way to test for compatibility problems, a kind of dogfooding. Plus, it is nice working on a system you are comfortable with, and without the performance penalties of virtualization/containerization. For releasing and testing however, containers are great.

forrestthewoods 3y ago

> where you're implicitly depending on system include paths for versioning The correct thing to do, imho, is check-in toolchains to version control.

maccard 3y ago
Yeah that works really well. I used to use the predecessor of "Turnkey" [0] for unreal engine, and it worked absolutely great for that problem. [0] https://docs.unrealengine.com/5.0/en-US/setting-up-turnkey-for-your-organization-in-unreal-engine/ https://docs.unrealengine.com/5.0/en-US/setting-up-turnkey-f...