[finiteloop]

As someone who writes a lot of toy languages, I made this scaffolding for a LLVM-based compiler: https://github.com/finiteloop/compiler

It uses Bison and Flex for parsing and lexing unlike this post, but may be a useful starting point for those building their own toy languages.

[chrisaycock]

Reusable compiler components are really helpful. I made this example for parsing with ANTLR:

https://github.com/empirical-soft/calculANTLR

It uses a C++ port of CPython's ASDL to define the AST.

[dbcurtis]

Doesn’t the LLVM API go through breaking changes fairly often? How do you track all that and keep your sanity?

[finiteloop]

Everyone says that but I have not experienced it. In practice, I think this impacts backend extension developers more than people targeting LLVM IR. My experience covers version 7-11, but perhaps it used to be worse?

[vnorilo]

I've been updating a small codegen since the 3.x days. There have been many API changes with major versions. That said, I always found it pretty easy to implement the changes (something like a workday for my ~10k LLVM-interfacing LoC), and the changes tend to be such that once you get it to compile again, it just works as before.

I think LLVM is an excellent demonstration of how to design and implement big systems well in C++, and as a part of that, they also do breaking changes pretty well.

[exDM69]

> Doesn’t the LLVM API go through breaking changes fairly often? How do you track all that and keep your sanity?

No, not very big ones. But they give no stability promises.

If you're using a language other than C++ via API bindings, you will experience some churn going from version to version as the bindings need to be updated too.