Existing makefile-like build systems conflate what we are building with how we are building it. Every project has its own Makefile, autoconf, vsproj, etc., which explain how to build it, and where the files are.
In reality, many simple projects build exactly the same way. That way may involve complex steps, but rarely do they differ meaningfully. It does not make sense to write out a different recipe every time you buy groceries, so why should you re-describe how a project builds every time you begin a new, similar project?
- Feast: A completed set of build products.
- Kitchen: A tool environment (ex: vs2015 64-bit on Windows 10).
- Dish: A single completed build product.
- Recipe: Software that determines how to create one build product from multiple prepared ingredients.
- Prepared Ingredient: A built intermediate unit, as defined by the recipe's needs.
- Raw Ingredient: Human editable raw file.
- Chef: Software that builds raw ingredients into dishes.
Feast will be an ABI-stable C library first and a command line executable second. This lets you optionally integrate Feast into your GUI tools instead of being forced to choose between an IDE-native build system and a command line prompt.
Feast will use OS system calls and native threads on Windows, Mac and Linux to provide optimal cross-platform building.
While all build systems produce a single completed build product (a "Dish" in Feast nomenclature), only a few support the building of individual compilation units ("Prepared Ingredients"). Even fewer support the automatic refreshing of Prepared Ingredients when they change on disk. Because Recipes are defined separately from the list of Raw Ingredients, it becomes trivial to perform an incremental compile.
If you need to ask your build system to rebuild your project, you have always wasted precious seconds. Feast continuously runs, monitoring Prepared Ingredients for updates.
- Recipe to run Make: For existing/legacy build systems looking to benefit from Feast's features, it is possible and trivial to write a recipe to wrap a build system. This gets you GUI integration and automatic rebuilding by pointing it at a single Makefile.
- Recipe to build a book with LaTeX: Rather than write a Makefile that explains how to compile multiple LaTeX files, how to clean them up, etc., just point them at a single directory of .tex files.
- Custom asset cooking for games: Write a recipe to bake your assets, mapping extensions to tools and known build productsn.
- Recipes must be easy to define. This is a failing of Scons, where you could teach it to do a new thing, but first you must gain access to its source tree and understand API internals.
- Recipes must self-document. Once the community has created a Recipe, it must be usable by people who did not create it.
- Dependency checking must be definable in a recipe but be very fast for large projects doing incremental rebuilds with a fresh start.
- Consider JFDI's API and self-propagating feature as wins to integrate as compatible.
- Weigh embedding Python with a simplified API in any case.