Felix Programming Language

I've been participating in a lengthy build system discussion on reddit, which has inspired me to start sketching out my ideas for FBuild:

New scheduler: I'm not too happy with the current scheduler, as I had to introduce a timeout on checking if there are done tasks to work around a flaw with python's threadsafe queue structure. It's possible for a KeyboardInterrupt to happen in between incrementing/decrementing the semaphore, and this was leading to a deadlock that needs a "kill -9" to exit. There has to be a better way to do this. I'm experimenting with multiprocessing to see if that'll be faster. In order to do that though we're going to have to implement our own pickling/unpickling of MethodType, and possibly other things too.

A new database: FBuild's a bit faster with Python 3.1's new io module, but it may be even faster if we could use a SQLite database.

Get rid of the global state: For ease of implementation, FBuild has a couple global state objects: the scheduler, the database, the logger, and the commandline options. We could fold all of these into some context object and pass it around. This would mean you'd have to write code like this though:

def build(ctx):
    static = fbuild.builders.guess_static(ctx)

Simplify the builders more: webon on reddit pointed out that the ar builder is a bit more complicated than it needs to be. Part of the reason for this is that we're writing the option list twice. First at the builder level, second at the file level. Perhaps we could simplify this by doing something like:

class Ar(fbuild.builders.Builder):
    options = {
        flags: list,
        libs: list,
        libpaths: list,
        ...
    }

    def __init__(self, exe='ar', flags=['-rc'], **kwargs):
        ...
        super().__init__(flags=flags, **kwargs)

    def __call__(self, dst, srcs, **kwargs):
        options = self.process_options(**kwargs)
        cmd = [self.exe]
        cmd.extend('-l' + lib for lib in options.libs)
        ...

Where the superclass would somehow process the option list and automatically merge the options without us needing to copy the code everywhere all the time.

Speed up FBuild: bohan on the fbuild mailing list pointed me to a benchmark he wrote to test out his build system, wonderbuild. FBuild is beating SCons and Autotools in many tests, but I think we could to a bunch better. For instance, is there any way we could get the number of system calls down?

Finish support for avr-gcc and haskell

Optionally turn of md5ing of files: It'd be pretty easy to add a flag to fbuild.path.Path to turn off using md5 for file digesting. This should help folks like bohan who are willing to sacrifice doing rebuilds of files in order to have a faster build system.

edit: I forgot to include automatic threading. We could use futures transparently thread computation without needing to explicitly use scheduler.map. Unfortunately this can get a little complicated unless we could come up with a good way to use the futures without littering scheduler.future(f, *args, **kwargs) and scheduler.force everywhere.

edit 2: Some more projects:

targets: The idea is to have simple make-like targets, possibly something like:

@fbuild.target
def configure():
    ...

def build():
    conf = configure()
    ...

@fbuild.target
def test():
    builder = build()
    ...

installation: No ideas for that yet!