remake
BUSY
| remake | BUSY | |
|---|---|---|
| 4 | 24 | |
| 761 | 80 | |
| - | - | |
| 5.1 | 3.7 | |
| 8 months ago | 12 months ago | |
| C | C | |
| GNU General Public License v3.0 only | 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.
remake
- Knit: Making a Better Make
-
Why you should adopt Makefile in all of your projects
Anybody who works with Make should also check out remake, because while Make is useful, it is pretty bad at diagnostics.
-
Do you consider ChromeOS and Android to be distributions of Linux?
While true that the absolute minimum install of alpine linux is gnu free I don't think it's fair to say alpine is gnu free...the build-base meta-package for a basic development environment pulls in gcc, binutils and patch, the default make tool of alpine is a gnu make fork, packages like gettext, octave, bison...are all available in the alpine repositories.
- Proposal to add build graph output to GNU Make
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?
uftrace - Function graph tracer for C/C++/Rust/Python
scratch - Personal scratch code
makefile-visualizer - Visualize the dependency of makefile and related files.
shellb - Simple Shell based build tool
makefile2graph - Creates a graph of dependencies from GNU-Make; Output is a graphiz-dot file or a Gexf-XML file.
GnTools - GN meta-build system parser, static code model and navigable code browser
bgraph - BGraph is a tool designed to generate dependencies graphs from Android.bp soong files.
gtec-demo-framework
rabs - General purpose imperative build system.
nappgui - SDK for building cross-platform desktop apps in ANSI-C
tup - Tup is a file-based build system.
coalton - Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp.