3 ms·
I've implemented build/task systems in two different ways in the past. The first is a bash script that ends in $1 ${2:} or something in that region. Then
by zaarn 9y ago
I've implemented build/task systems in two different ways in the past.
The first is a bash script that ends in
$1 ${2:}
or something in that region. Then I can define functions and call them directly from the command line. It's rather protable (if you have bash or I bothered to write POSIX sh compatible)
The other was a simple DAG similar to how the author describes it. Each task was a root node and subtasks were nodes connected to it. To figure out which tasks to run I'd simply scan the entire task graph for what has no subtasks and spawn a thread/process for each runnable task. Once a task finished, it's removed from the DAG. Successfully used to run database upgrade tasks (update multiple tables at once if they queries don't depend on eachother)
The only thing I ask of a custom build system is that it A) includes the classic "all" and "clean" options B) it doesn't have any dependencies beyond what I can expect from any random distro, C) autodetect libraries in common locations, not the locations on the original dev machine and D) don't require root permissions. ever. (outside "install" and maybe we can insert a rant in here how a lot of packages don't have a "uninstall" or "remove" option, making me track down the files it shat onto my disk)