Pork, MCPP, Oink and Elsa…What’s going on?

It seems that there is some confusion as to what pork is and how it’s related to oink and elsa. So here is my view of it.

Pork is my set of tools that use Elsa to rewrite sourcecode (mainly Mozilla code). Our use of Pork is solely for rewriting as it is not suited for convenient and hardcore analysis needs as much as the GCC based tools are.

MCPP is the secret sauce C preprocessor that makes C++ rewriting with Elsa possible by annotating preprocessed files with information to undo the lexical braindamage resulting from macro expansion.

Elsa is a awesome C++ parser. Awesome in that is can preserve more information regarding parsed code than any other C/C++ parser and it is easy to extend.

We maintain our own version of Elsa within pork.

I think our version of Elsa is the most up to date and most compatible with newer C++ features and headers used by newer GCC releases. We encourage other projects with C++ parsing/rewriting needs to collaborate with us. We will be parsing code with Elsa for a few years to come and it’s a lot of work to maintain a C++ parser by a single entity. I think elsa is a much better backend to build refactoring support onto than any other C++ parsing project out there right now.

The Messy Details

Now lets move on the more confusing parts: oink, oink-stack, and the oink mailing list.

oink consists of some static analysis tools and was meant to be a central place where all of the Elsa and Elsa-related development was supposed to happen. When people refer to oink, they usually mean the oink-stack which is a subversion meta repository that pulls in a dozen of subrepositoes(smbase, elkhound, elsa, oink(where static analysis tools live), etc).

So when I started working on refactoring tools I was told that I should aim to have my tools added to oink, but there were some legal hassles to work out in the meantime so I cloned the oink-stack and developed my tools with minimal changes to oink-stack. This included various elsa extensions, bugfixes, etc.

However, the little momentum that oink had has fizzled out due to various personality conflicts and various academics loosing interest. The code has been bitrotting for as long as I’ve been working at Mozilla.

So the end result of oink is that we have pork which is a superset of oink. I’m not even sure if I mention the name pork anywhere in the sources. So pork at the moment means “Taras’ continuation and extension of oink”. I am using the oink mailing list for any discussion on changes to Elsa/etc in hopes that at least some of the genius lurkers there will regain their interest in elsa.

Where do We Go From Here?

Onward! Due to the original authors vision of what C++ is and the state of C++ at the time Elsa was conceived, current pork code causes people to have many WTF moments (followed by banging head against keyboard) when they first start using it.

The short version of my plan is:

  • allow one to do “using namespace std” when using elsa
  • Restructure pork repositories such that there are only 3 of them rather than 11 (elsa, elkhound, pork)
  • get rid of the oink repository (those tools do not work for us)
  • Make pork only consist of just my tools (with a sane build system) rather than be mixed into unmainted oink stuff
  • Make pork compile with new compilers (GCC 4.3 and recent MSVC++)
  • Keep track of this in a bug
  • Clean up various misc things

Some of you might ask “But Taras, why now, why not just keep doing what you’ve been doing?”. I was doing what I was doing because I had an overwhelming goal of devising a way to automate static analysis and refactoring of Mozilla on my shoulders and I wasn’t convinced that it was feasible. I had to learn to split my time between tool development and actually using the tools. Naturally I cut corners on tool development :)

Since then slowly, but surely various awesome hackers have started doing rewrites and analyses themselves freeing me up to focus more on development. To make matters sweeter, various hackers have started submitting bugreports, fixes, ports to my tools. This gives me more time to focus on the big picture.

Finally, I belive that automation of the sort we are doing at Mozilla is something that has been missing from open source development practices and it will catch on once people realize what they’ve been missing. Reducing those WTF moments will help people think positively.

Update:

Why three repositories instead of one?

  1. The three will be elkhound, elsa, pork
  2. elkhound is useful on it’s own
  3. elsa is too and other elsa users are likely to not care about Mozilla’s rewriting tools

Is oink really dead?

Yes. The maintainers have moved on to other projects. When they were maintaining oink, outside contributors couldn’t get their code upstream.

4 comments

  1. James Napolitano

    What is Elkhound?

  2. Elkhound is the parser generator that powers elsa. http://www.cs.berkeley.edu/~smcpeak/elkhound/

  3. I just stumbled on your site. I’ve been doing quite a bit of work with Elsa for the past several months. My focus has been getting Elsa to actually generate code. I do most of C right now with some C++.

    Maybe we should see if we could sync our trees up?

    More info at http://ellcc.org

  4. I tried to use Elsa to parse glibc. Elsa failed to parse some of glibc codes. Is it possible for me to get the latest Elsa from you?