rabs
BUSY
| rabs | BUSY | |
|---|---|---|
| 2 | 24 | |
| 9 | 80 | |
| - | - | |
| 6.7 | 3.7 | |
| 6 days ago | about 1 year ago | |
| C | C | |
| MIT License | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rabs
-
Knit: Making a Better Make
I've also written my own alternative to make called Rabs (https://github.com/wrapl/rabs) which uses an imperative language to specify the dependency graph as well as the build instructions. It's designed for really fast incremental builds.
-
Minilang: A scripting language for embedding in C
Indeed, the API started off much lighter when I first worked on it (for a generic build system https://github.com/wrapl/rabs) but over time I made it more and more flexible as I found different applications for it.
BUSY
-
Xz Backdoor and Autotools Insanity
CMake - as autotools - is a meta build system; it e.g. generates make files, which are essentially scripts. Also CMake itself is essentially a VM with a scripting language. Both CMake and Make are Turing complete (and dynamically typed, as mentioned). And yes, not all build systems are the same; e.g. https://github.com/rochus-keller/BUSY has a statically typed specification language and intentionally avoids a Turing complete language.
-
New build system for C/C++
> Have you coded the lexer/parser from scratch
Yes. Here is the lexer: https://github.com/rochus-keller/BUSY/blob/main/bslex.c
and here is the parser: https://github.com/rochus-keller/BUSY/blob/main/bsparser.c
and here is the specification: http://software.rochus-keller.ch/busy_spec.html
I also developed and checked the EBNF in parallel using my EbnfStudio tool; this tool could also generate a parser, but since I'm using much of the Lua VM infrastructure a manual parser implementation was more straight-forward .
- What should be used to build the CPython of tomorrow?
- A simple shell based build tool for C/C++
-
Knit: Making a Better Make
If you haven't seen it: https://github.com/rochus-keller/BUSY
> BUSY is a lean, statically typed, cross-platform, easily bootstrappable build system for GCC, CLANG and MSVC inspired by Google GN
It uses lua and config files that are mostly directories and filenames.
-
Using Qt 6 under LGPLv3
> Instead of qmake the BUSY build system (see https://github.com/rochus-keller/BUSY) is used
It must be a rite of passage to make(!) one's own build system, damn
- BUSY lean build system with new Qmake backend
- Show HN: Busy build system now has a Qmake back end
- New BUSY build system, MVP release
What are some alternatives?
remake - Enhanced GNU Make - tracing, error reporting, debugging, profiling and more
scratch - Personal scratch code
tundra - Tundra is a code build system that tries to be accurate and fast for incremental builds
turborepo - Incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust – including Turborepo and Turbopack. [Moved to: https://github.com/vercel/turbo]
shellb - Simple Shell based build tool
GnTools - GN meta-build system parser, static code model and navigable code browser
gtec-demo-framework
nappgui - SDK for building cross-platform desktop apps in ANSI-C
coalton - Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp.
oil - Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
Rake - A make-like build utility for Ruby.