BuilDj/buildj.png "buildj.png")
BuilDj is an initiative to try to collect and describe all the required usecases of a build environment definition and its posible operations in a structured and descriptive way.
The main goal of this initiative is to come up with a solution that plays well both for humans and machines. This should enable things like better IDE integration of the projects using it, an easier to document and remember format and features like aggregation (building and linking different components of different projects together).
It approaches the problem by having a specification implemented as a YAML format that means to be easy to learn, self descriptive, machine parseable, and human writeable.
It is oriented to support the Freedesktop/GNOME stack (C, C++, Python, Vala, intltool, gtk-doc, .desktop, XDG dirs...), although further support for other toolchains should fit the design.
It is mostly a format definition, the current reference implementation is being done with waf since it provides the easiest API in terms of extensibility. However Waf's is just a reference implementation of the format, implementations using Autotools, CMake, MonoDevelop, Eclipse, Netbeans... are all more than welcome!
It does not allow programming like features, those are meant to be implemented as plugins in the underlying implementation. The ideas is that the reference implementation tries to get as much support for the most common features upstream. Most times, some crazy stuff around in autotools and other systems are hacks due to the lack of a good general purpose tool to solve that specific problem, or the lack of good documentation to implement it cleanly.
1. Main Goals
Ease of use: Intuitive and consistent, using the principle of least surprise wherever possible
Best practices: The format encourages people to use best practices such as avoiding hardcoded paths by providing tools to reference resources like icons, autogeneration of .pc files automatic i18n support and such.
Single format workflow: configuration, dependency checking, everything is meant to be defined in a single format (except for extensions of the format itself)
Cross compilable/relocatable: The format is designed around the idea of projects being relocatable and cross compilable by default, although some areas of this goal are yet to be tested and refined.
Split definition/functionality: Its meant to be an abstract definition format to be then implemented as a frontend by other tools (Waf, Autotools, CMake) and to be parsed/written by IDEs so no scripting or customizations in-line are allowed. Extensions to the format should be implemented as extensions of the underlying build system.
2. Specification
The format is under heavy development testing at the moment, ideas are more than welcome.
3. Examples
3.1. C program linking against GTK+
project:
name: CC Test
version: 0.0.1
url: http://www.gnome.org
requires:
gtk+-2.0:
type: package
version: 2.14
mandatory: True
targets:
my_gtk_program:
type: program
tool: cc
input:
- gtk_program.c
packages:
- gtk+-2.0
3.2. C program linking against another target
project:
name: CC Test
version: 0.0.1
url: http://www.gnome.org
targets:
my_library:
type: sharedlib
tool: cc
input:
- library.c
my_gtk_program:
type: program
tool: cc
input:
- program.c
uses:
my_library
4. TODO
4.1. Variables
Syntax for global variables and pkg-config variables are both planned, some ideas are ${variablename}, ${packagename:variablename}, $(environmentVariable)
4.2. Conditionals
Global conditionals are a hard one, so far we have only thought about using some syntax that will replace the child objects in a preprocessing fashion such as:
5. Repository
Patches for fixes and new features are more than welcome!!! http://git.gnome.org/browse/buildj/