github
Advanced Search
  • Home
  • Pricing and Signup
  • Explore GitHub
  • Blog
  • Login

lloyd / bakery

  • Admin
  • Watch Unwatch
  • Fork
  • Your Fork
  • Pull Request
  • Download Source
    • 4
    • 1
  • Source
  • Commits
  • Network (1)
  • Issues (0)
  • Downloads (0)
  • Wiki (1)
  • Graphs
  • Branch: master

click here to add a description

click here to add a homepage

  • Branches (3)
    • 0c3fbd8ad6a94965b655c407937fd451318460a6
    • e8127a079e9e4b82a170f9c77ca0a93b02055fd7
    • master ✓
  • Tags (0)
Sending Request…
Enable Donations

Pledgie Donations

Once activated, we'll place the following badge in your repository's detail box:
Pledgie_example
This service is courtesy of Pledgie.

A ports system for software projects. Add software by adding "recipes". Build software by placing an "order". Yummy! — Read more

  cancel

  cancel
  • Private
  • Read-Only
  • HTTP Read-Only

This URL has Read+Write access

(zip) fix osx makefile patch.  no idea how it got so borked 
lloyd (author)
Fri Jan 15 11:22:14 -0800 2010
commit  ea4c852d8a2a25532dc293af5b2ccedb88ae5dd7
tree    e07363de3c198671b71b877ce7bc8c69a2dc5ba1
parent  2778d961858022104171a94154ad5a65acfb757e
bakery /
name age
history
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.
Blog | Support | Training | Contact | API | Status | Twitter | Help | Security
© 2010 GitHub Inc. All rights reserved. | Terms of Service | Privacy Policy
Powered by the Dedicated Servers and
Cloud Computing of Rackspace Hosting®
Dedicated Server