Context Navigation

Ideas for student projects for Google SoC 2007 (some of them may be too small, but could be combined with others into "combo" tasks):

Improve errors reporting and input validation

Bakefile currently doesn't report all errors as clearly and nicely as it could. For example, some unexpected inputs may result in a Python exception being reported, instead of explanatory, human-readable error. Fixing this involves:

better error reporting at runtime, i.e. add appropriate exception handling in more places
validation of input -- some way of specifying constraints on input must be added, either using some existing validation language (Relax-NG etc.) or by providing a way to embed this information in .bkl files (<define-tag>, <define-rule>) in particular
keeping track of when variables were modified for the last time and reporting it when a variable triggers an error
adding more unit tests in the process

General bugfixing

There's number of partially fixed or unfixed problems reported by users. The goal of this task would be to get pending patches into submittable state and implement fixes for open bugs.

Currently there are about 40 tracker items open:

The project would involve in closing them after properly committing the right fixes/modification to a branch of bakefile SVN. All currently open items would be fixed in the project except:

http://sourceforge.net/tracker/index.php?func=detail&aid=1606002&group_id=83016&atid=568032 : interfacing bakefile with PHP
http://sourceforge.net/tracker/index.php?func=detail&aid=1581469&group_id=83016&atid=568029 : options' of the subprojects are optimized out - this is an entire SoC proposal alone (see below)

Time-permitting also the Code::Blocks support could be implemented:

http://sourceforge.net/tracker/index.php?func=detail&aid=1240619&group_id=83016&atid=568032

New DLL+LIB target type

Bakefile currently has three canonical target types: executable, static library and shared library. It would be nice to implement libtool-like "shared+static library" target type for conveniently creating both kinds of the library. This would be easy to do if we added autoconf-libtool target that would use libtool internally, but it's going to be quite difficult in other formats, because no other [supported] make or IDE understands this concept natively.

Possible solution: for targets which do not support such dll+lib concept (basically, everything different from libtool and MSVC projects) simply treat them as a union of a conditional <dll> and conditional <lib> adding an option such as BUILD_SHARED=0/1 which allows the user to choose among the static or dynamic build.

Output optimization

Optimize output size, e.g.:

avoid doing target_foo.o and just use foo.o if there is no conflict between 2+ targets having foo.o
use implicit rules when possible -- this is important, it can significantly reduce output's size in common cases (probably not for wxWidgets, but that has a very complicated and untypical makefiles)

Custom compilation rules

Implement support for compiling other sources than C and C++, including the typical flex/bison->.c->.o compilation and support for Qt's moc files. The basics for making this are there since the beginning, but so far only C and C++ inputs are implemented. This involves:

updating the code to really be ready to accept different input types
provide user-friendly way of defining custom compilation rules
implement a preset or module for Qt's moc handling
implement a module for flex/bison
possibly add some more modules for frequently needed things (SWIG? Java/GCJ? C#/Mono?)

Type safety

Currently, Bakefile uses Make-like "everything is a string" approach to variables. This causes problems in two situations: when appending e.g. compiler flags to a variable that is semantically a list (it works, but the output is ugly, with multiple spaces) and when (e.g. include) paths contain spaces. With a type system that would recognize lists, we could handle quoting of names with spaces and their correct line-breaking in a much simpler way.

Single-run makefiles generation

Currently, multiple makefiles for a project are generated using the bakefile_gen utility, which runs bakefile to generate one makefile at a time. This generally works OK, but is causing problems when you need to add inter-makefile dependencies, e.g. to make a sample depend on the main library. You can't use <library> in this situation, because a subproject has no information about parent's (or sibling's) targets, so you have to rely on <sys-lib>, which is suboptimal. The only way to fix this is to implement single-run generator that process all bakefiles at the same time. Obviously, it can't be as simple as this, because we still want to avoid regenerating makefiles that didn't change, so the implementation would probably do something like passing targets data through a cache.

XCode backend

(Plus possibly some other "mainstream" backends.) There's already partial implementation, but it's not finished. Probably not big enough project...

GUI

(For the sake of completeness.)

A GUI is not very important for a makefile generator, but OTOH, it looks attractive, specially for new users. In such case, I think that a bakefile GUI should be a "simple" scintilla-based editor with:

bakefile documentation integrated
buttons to launch bakefile_gen and/or bakefile (obviously :))
integrated console to parse bakefile's output

GUI should preferably actually first come in a form of Eclipse/ Visual studio plugin, thats where most of the users are anyway. XCode, Codeblocks closely behind.

Download in other formats:

Plain Text