Sunday, March 13, 2011

Critical review of build systems

Last time I looked at possible alternatives to OpenEmbedded, I mostly looked at how many packages they support, how many architectures/OSes, and how easy is to add overrides. Of course, OpenEmbedded outperforms any other generally available build system in these respects.

But still, while the idea of grand unified build system is very cool, maybe it would be easier to add/extend support for some non-Linux OS to some other build system? (As OE is targetted at Linux.) Let's see.

This software tries to steal "grand unified" motto, though so far it has 200+ packages, but supports Windows. Recipes are structured as Python classes, overrides are handled like:

class Ctypes__mingw (Ctypes):

 One thing which immediately catches eye is "def patch (self)". Yeah, Python doesn't let people play with curlies, but they'll go out fo their ways with braces. Recipes-classes do allow deal of declarativeness, for example, in specifying patches, and yet there're stuff like:

    def patch (self):
        self.system ('''
cd %(srcdir)s && patch -p1 < %(patchdir)s/busybox-mkconfigs.patch

Summary: Violates standard codestyle for target language (PEP8), breaks declarative vs imperative metadata separation.

Targets mingw32 (only). Doesn't support DLLs. Uses .mk for recipes. Both recipes and other files (patches, etc.) lie in one flat directory. Recipes look clean, but one target and no sharedlibs is trivial case on its own.

No comments: