public
Description: A ports system for software projects. Add software by adding "recipes". Build software by placing an "order". Yummy!
Homepage:
Clone URL: git://github.com/lloyd/bakery.git
bakery /
name age message
file .gitignore Loading commit data...
file ADDING_RECIPES
file LICENSE
file README.textile
file TODO
directory example/
directory ports/
README.textile

Welcome to the Bakery

There is nothing new under the sun.

That being so, a large part of what we do in writing software is leverage other peoples libraries (you down wit OPL?). If you are someone who maintains or contributes to a software product that uses “3rd party” or “external” open source software, then welcome to the bakery!

The bakery is not new, it’s simply the application of an existing Good Idea (The BSD Ports system), to a new problem: using 3rd party source from a software project.

The Problem

When developing end user software there’s massive benefit to using existing 3rd party open source software. Would you write an XML parser from scratch? Are you nuts? But, building open source software is hard. Not all software is as simple as:

./configure --prefix="myinstalldir" && make && make install

Further, building software on windows always sucks. NMake? Visual studio? Makefiles and msys? This is all madness that we all suffer independently. What too many of us end up doing is:

  • Checking Binaries Into Revision Control – Great! now how did you do that? How can someone else regenerate that magic binary? Debug it?
  • Using system supplied libraires – Rad! Now apple can slip a bugfix bug under your ass. Your test matrix just became infinite.

So the solution? Where possible and reasonable, for end user software, it benefits you AND your users to build and ship the libraries you depend on. It also benefits your users for you to be diligent in updating the libraries you use where stability or security is afforded.

Now setting up an automatic build system for it, building it, patching it, regularly upgrading it? All pains in the arse. This is where the bakery comes in. A centralized repository of ports for various external software.

Usage Overview

Adding Recipes

Use some software that’s not currently in the bakery? fork it, write a recipe, and send a pull request. Done.

Placing Orders

Starting a new project? Let’s see, you’ll need ICU, some XML parsing, the fastest JSON parser on the planet (YAJL), and Some Other Stuff. Using the bakery is simple:

  1. git submodule OR copy the bakery into your source tree
  2. write an “order”, a configuration file saying which ports to build
  3. at the time someone checkouts out the repo, they should run the “bakery” build script.

Guiding Principles

We have to start somewhere. But nothing is forever.

  1. We cook for linux, MacOSX and Win32
  2. We use ruby and are proud of it: Building software sucks, and being able to sprinkle a little high level language on the problem from time to time is just fine.
  3. NO 3rd party binaries, NO third party source in tree. The bakery is recipes only.
  4. in general we build static libraries. The thought is that because we’re taking a size hit by shunning libraries present on the system, we can leverage the static linker to minimize that cost.