I’ve read multiple posts on social media now complaining about how scary LLVM is to get to grips with. It doesn’t help that the repository is ginormous, there are frequently hundreds of commits a day, the mailing list is nearly impossible to keep track of, and the resulting executables are topping 40Mb now… Those tidbits aside - LLVM is super easy to work with once you get to grips with the beast that it is.

I’ve had a lot of people using my unicode library utf8.h since its release - thanks to all who’ve found the library useful and provided feedback! One of the things that I’d scrimped on previously was my support for case-insensitive comparisons for letters beyond those in ASCII. I knew little about this, but when a user requested that my library also supported accented latin characters, and later greek symbols, I jumped to the occassion to add support.

I’ve long been after a cross-platform way to launch processes and interact with them for use from C & C++. After a brief scouring of the interwebs, I didn’t find any that matched my criteria: No build system dependencies. Works in C and C++. Works on Windows, Linux and macOS. Single header (or at least single header / single source file). So I did what I always do when confronted with this issue - I wrote my own!

One component of Codeplay’s ComputeAorta that I manage is our high precision maths library Abacus. One major component of Abacus, and in fact all math libraries, are a requirement to have remez reduced polynomial approximations of functions. In the past we’ve made use of Maple, Mathematica, lolremez, our own fork of lolremez, and to be honest none of them have been satisfactory to our needs. We want a scriptable solution that we can use to bake the generated polynomials automatically into Abacus with minimal user intervention.

LLVM comes with a really useful set of options LLVM_USE_CRT_ which allows you to specify a different C RunTime (CRT) when compiling with Visual Studio. If you want to be able to compile LLVM as a release build, but compile some code that uses it in debug (EG. our ComputeAorta product that allows customers to implement OpenCL/Vulkan on their hardware insanely quickly), Visual Studio will complain about mixing the differing version of the CRT.