Prerelease thoughts Part I: llvm

The act of pushing out a release is quite a task, taking weeks rather than days. Why is that ? And how can it be fixed ?

Ideally pushing out a release should be not more than a days work, after all, it is just tagging and pushing to github right ? But it isn’t so. There will have to be a couple of changes the way I manage this project.

Topics

• llvm (this)
• Github and CI
• Packages
• Project

llvm

mulle-clang

The dependency of mulle-objc on llvm is my personal biggest pain point. But it’s not the biggest time sink. So far I have always been able to merge my mulle-clang diffs back into clang with a day or two worth of effort.

The llvm Mono Repository

This time though llvm moved all its code into a mono-repo, which invalidated my previous commit history and the automated build scripts. I had to rebase my sources on a new git repository. I had to redo my build scripts and most time consuming I also had to do recreate my VMs which are building the compilers for various OS. This took a few additional days.

The Sword of Damocles

But there is this sword of Damocles hanging over the project head, that llvm will do a a big rewrite some day and that the fairly painless merge of mulle-objc won’t be possible anymore.

The failed Masterplan

The master plan as set out four years ago, was to gain enough momentum for the project, so that we could get the mulle-objc changes into the llvm codebase alongside with the other Objective-C runtimes. This would have removed the dangling sword almost completely, since incompatible changes upstream would become apparent in llvm as soon as they were committed. That would not have been a guarantee against mulle-objc becoming incompatible eventually. But it would have been much, much more unlikely. But sadly the momentum to get mulle-objc accepted never happened and from the current perspective one must conservatively assume that it will not happen.

Though you should never blame the audience, it is actually your fault :)

The C++ Quagmire

Also clang is a bitch to debug. There are numerous different types of strings, types and custom C++ containers. Most of them are opaque when you try to inspect them in the debugger with ‘p’. Some have introspection functions, some not, nothing is uniform (like ‘po’ for Objective-C objects).

Furthermore the whole project, when built with debug symbols, requires a retarded amount of resources. The question is really why ? It’s just a compiler. But it’s not a C-compiler written in C (see tcc). It’s a C++ compiler made for compiling C++ code. It’s bloating up bureaucratic bloat with bureaucratic code.

The clang development process feels like wading through a quagmire and I hate it. So I haven’t even attempted to shoehorn new language features into the compiler itself, but restricted myself to use macros for a new feature such as PROTOCOL_CLASS.

mulle-lldb

Hope

The lldb debugger code base is better, in that it is much, more nicely structured than clang. But it’s also worse, because lldb is basically lldb + clang + llvm. So more complexity on top of complexity. The C++ mindset…

and Despair

And it’s even worse to debug. After spending a week trying to debug something, relating to symbols, where I just remember the debugger calling back into the compiler and copying various AST context back and forth. I did something, which I rarely do: I gave up.

Consequences

What does this means for now and the future ?

mulle-lldb is dead

In the short term this means, that mulle-lldb is history and the replacement is mulle-gdb. gdb is a much simpler debugger than lldb (still). It didn’t take more than two days to implement the necessary changes to get it to work with mulle-objc. The merging so far has been trivial.

mulle-gdb is alive

mulle-gdb is not as nice as mulle-lldb was. I am not happy with its current capabilities but I can live with it. But it is just a matter of time until it gets into a nicer shape.

mulle-clang is not feeling well

On the compiler front I am evaluating my options. There is no real time pressure, but the writing is on the wall. mulle-clang will become history as well and there will be some sort of mulle-cc in the future.

Continue to Prerelease thoughts Part II: CI