build-graph 2.2.0 → 2.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: c1db7b0de55419c77b5c17f17e93f4e62304a93872265545cce248c58d78e1c8
-  data.tar.gz: 989d5bae8d7eb3b324648cf64eecdd999c8f5104a849bd5715cab8cd7ad26079
+  metadata.gz: 732e8eb3e448d4b4d2e29b99cfa776dd3fee02bcac14bf93c87112e907bca776
+  data.tar.gz: 030b9b4aa3f3aadddd4f29569c8ff43151ec10d5a921bc7dd58300cc9808b78b
 SHA512:
-  metadata.gz: 93c3f170fb2ad8da49f56d30248e8403e504f8fef5e562f19cd3280cfa60471cc09b0dc440a6d7f3c63fef7c8da25e1da5e6faacce446c91cbb6e3d9ced740fb
-  data.tar.gz: '0382b9651118034b7aebdfcfa7a0599adf430172ac3ec0243905728b2a2326ca621c44011d7d5a071308e4c1e3bdb83977292fd6a3f9ef2c0b141488edf27329'
+  metadata.gz: 6cd9d0b4486e3617da1496598baf89a16508fac212ad0c92023948098eab6e1d53ad7fc0c75e9de3f5b0bba5b8f5acebab9cd833d2fb72a6d9220df6babb6183
+  data.tar.gz: b71e886594c0b7aba83db98e4c7da0d5ed97d4f3341006edaa723246a531631457d224ec2a46b5caa25326f938c19861058bb6c28f6b06e1eee207f51a591d7d

data/context/getting-started.md

@@ -0,0 +1,65 @@
+# Getting Started
+
+This guide explains how to use `build-graph` to build a dependency graph for file-based build systems.
+
+## Installation
+
+Add the gem to your project:
+
+~~~ bash
+$ bundle add build-graph
+~~~
+
+Or install it directly:
+
+~~~ bash
+$ gem install build-graph
+~~~
+
+## Usage
+
+A build graph is an abstract set of `[input, process, output]` nodes. A node executes its process within the context of a `Task` which represents a specific set of inputs and outputs and is managed within a `Walker` that walks over graph nodes, regenerating tasks where required. If inputs or outputs change (i.e. become dirty), the old task is nullified.
+
+A `Walker` is used to traverse the build graph once. As it walks over the graph it builds a set of `Edge` relationships between nodes and only traverses relationships which are complete (`Walker#wait_on_paths`). Parent nodes also wait until all their children are complete (`Walker#wait_on_nodes`). It also keeps track of failures (`Walker#failed?`) and fails all dependencies of a node.
+
+A `Task` is instantiated once per node when traversing the graph. The task represents a specific process being applied to the graph, e.g. build, clean, etc. It is responsible for actually performing any real actions and providing the methods to do so. A `Task` contains all details about the specific graph state at that point in time, e.g. `Task#children` and updating the node state in `Task#exit`. Statistics on the build graph are also captured through `Task` and `Walker`, e.g. number of nodes visited, etc.
+
+### Inputs and Outputs
+
+Inputs to a node should be all on-disk state and any additional parameters which cause its behaviour to produce different results.
+
+Outputs from a node should be all files that are generated directly by the processes within the node and sometimes its children.
+
+### Dirty Propagation
+
+A `Node` has a set of `#inputs` and `#outputs` but these are abstract. For example, `#outputs` could be `:inherit` which means that the node symbolically has all the outputs of all its direct children. A `Task`, at the time of execution, captures its inputs and outputs and these may be monitored for changes in real time.
+
+File changes are currently detected using `File::mtime` as this is generally a good trade off between efficiency and accuracy.
+
+When a task is marked as dirty, it also marks all its outputs as being dirty, which in turn could mark other tasks as dirty. This is the mechanism by which dirtiness propagates through the graph. The walker should only have to traverse the graph once to build it completely. If multiple updates are required (i.e. building one part of the graph implicitly dirties another part of the graph), the specification of the graph is incomplete and this may lead to problems within the build graph.
+
+### Example Graph
+
+~~~ ruby
+target("Library/UnitTest", [] => :inherit) do
+	library([UnitTest.cpp] => "UnitTest.a") do
+		compile([UnitTest.cpp] => "UnitTest.o")
+		link([UnitTest.o] => "libUnitTest.a")
+	end
+	
+	copy headers: ["UnitTest.hpp"]
+	
+	# Outputs become libUnitTest.a and UnitTest.hpp
+end
+
+target("Executable/UnitTest", [] => :inherit) do
+	depends("Library/UnitTest")
+	
+	executable("main.cpp" => "UnitTest") do
+		compile("main.cpp" => "main.o")
+		link(["main.o", "libUnitTest.a"] => "UnitTest")
+	end
+	
+	# Outputs become UnitTest
+end
+~~~

data/context/index.yaml

@@ -0,0 +1,18 @@
+# Automatically generated context index for Utopia::Project guides.
+# Do not edit then files in this directory directly, instead edit the guides and then run `bake utopia:project:agent:context:update`.
+---
+description: Build::Graph is a framework for build systems, with specific functionality
+  for dealing with file based processes.
+metadata:
+  documentation_uri: https://ioquatix.github.io/build-graph
+  funding_uri: https://github.com/sponsors/ioquatix
+  source_code_uri: https://github.com/ioquatix/build-graph.git
+files:
+- path: getting-started.md
+  title: Getting Started
+  description: This guide explains how to use `build-graph` to build a dependency
+    graph for file-based build systems.
+- path: visualization.md
+  title: Visualization
+  description: This guide explains how to use <code class="language-ruby">Build::Graph::Visualization</code>
+    to generate Mermaid flowchart diagrams from a build graph.

data/context/visualization.md

@@ -0,0 +1,79 @@
+# Visualization
+
+This guide explains how to use {ruby Build::Graph::Visualization} to generate Mermaid flowchart diagrams from a build graph.
+
+## Overview
+
+When debugging or documenting a build graph, it is useful to see the relationships between inputs and outputs visually. `Build::Graph::Visualization` produces a [Mermaid](https://mermaid.js.org) `flowchart LR` diagram from a completed {ruby Build::Graph::Walker}, showing each file as a node and each build step as a directed edge.
+
+## Usage
+
+After running a walker, pass it to {ruby Build::Graph::Visualization#generate}:
+
+~~~ ruby
+require "build/graph/visualization"
+
+walker = Build::Graph::Walker.new do |walker, node|
+  task = Build::Graph::Task.new(walker, node)
+  task.visit do
+    # perform the actual build step here
+  end
+end
+
+walker.update(root_node)
+
+visualization = Build::Graph::Visualization.new
+diagram = visualization.generate(walker)
+
+puts diagram
+~~~
+
+The output is a Mermaid diagram string that can be embedded in documentation, printed to the terminal, or written to a file:
+
+~~~
+flowchart LR
+    _src_main_c[main.c]
+    _obj_main_o[main.o]
+    _src_main_c --> _obj_main_o
+    _obj_main_o[main.o]
+    _bin_program[program]
+    _obj_main_o --> _bin_program
+~~~
+
+## Traversal Without Building
+
+To generate a diagram without actually executing any build steps (e.g. for documentation or dry-run inspection), use {ruby Build::Graph::Task#traverse} instead of `visit` in the walker block:
+
+~~~ ruby
+walker = Build::Graph::Walker.new do |walker, node|
+  task = Build::Graph::Task.new(walker, node)
+  task.traverse
+end
+
+walker.update(root_node)
+
+diagram = Build::Graph::Visualization.new.generate(walker)
+~~~
+
+Unlike `visit`, `traverse` skips input validation and does not require any files to exist on disk. It registers all node outputs with the walker so that dependent nodes can still be resolved correctly.
+
+However, `traverse` only follows **declared** edges — the inputs and outputs as written in the build definition. Some build systems discover additional dependencies at build time (for example, a C compiler producing a `.d` file that lists every header it included). Those discovered edges will not appear in the diagram.
+
+## Complete Graph Visualization
+
+To get a complete and accurate picture of the graph, including any dependencies discovered during execution, use {ruby Build::Graph::Task#visit} with an empty block instead of `traverse`:
+
+~~~ ruby
+walker = Build::Graph::Walker.new do |walker, node|
+  task = Build::Graph::Task.new(walker, node)
+  task.visit do
+    # perform the actual build step here, e.g. compile, link, etc.
+  end
+end
+
+walker.update(root_node)
+
+diagram = Build::Graph::Visualization.new.generate(walker)
+~~~
+
+This executes the build steps and captures the full set of inputs and outputs — including any that are only known after running the task — giving a diagram that accurately reflects what was built and why.

data/lib/build/graph/task.rb

@@ -66,6 +66,23 @@ module Build
 			# A list of any inputs whose relevant tasks failed:
 			attr :inputs_failed
 			
+			# Traverse the graph without performing any real work. Unlike {visit}, this does not
+			# wait for inputs to be generated, making it suitable for graph analysis tasks such
+			# as visualization where actual files do not need to exist.
+			def traverse
+				update_inputs_and_outputs
+				
+				@walker.enter(self)
+				
+				update_outputs!
+				
+				@state = :complete
+				
+				@walker.exit(self)
+				
+				return self
+			end
+			
 			# Derived task can override this function to provide appropriate behaviour.
 			def visit
 				update_inputs_and_outputs

data/lib/build/graph/version.rb

@@ -7,6 +7,6 @@
 module Build
 	# @namespace
 	module Graph
-		VERSION = "2.2.0"
+		VERSION = "2.3.0"
 	end
 end

data/lib/build/graph/visualization.rb

@@ -0,0 +1,55 @@
+# frozen_string_literal: true
+
+# Released under the MIT License.
+# Copyright, 2026, by Samuel Williams.
+
+module Build
+	module Graph
+		# Generates Mermaid flowchart visualizations of build graphs.
+		class Visualization
+			# Convert a path to a valid Mermaid node ID.
+			# @parameter path [String] The path to sanitize.
+			# @returns [String] A sanitized identifier safe for use in Mermaid diagrams.
+			def sanitize_id(path)
+				path.to_s.gsub(/[^a-zA-Z0-9_]/, "_")
+			end
+			
+			# Generate a Mermaid flowchart diagram for a completed walker.
+			# @parameter walker [Walker] The completed walker containing tasks.
+			# @returns [String] A Mermaid flowchart diagram in text format.
+			def generate(walker)
+				lines = ["flowchart LR"]
+				
+				walker.tasks.each do |node, task|
+					next unless task.inputs && task.outputs
+					next if task.outputs.equal?(:inherit)
+					
+					input_ids = task.inputs.to_a.map{|path| sanitize_id(path)}
+					output_ids = task.outputs.to_a.map{|path| sanitize_id(path)}
+					
+					task.inputs.each do |path|
+						lines << "    #{sanitize_id(path)}[#{path.basename}]"
+					end
+					
+					task.outputs.each do |path|
+						lines << "    #{sanitize_id(path)}[#{path.basename}]"
+					end
+					
+					label = node.respond_to?(:title) ? node.title.to_s : nil
+					
+					input_ids.each do |input_id|
+						output_ids.each do |output_id|
+							if label && !label.empty?
+								lines << "    #{input_id} -->|#{label}| #{output_id}"
+							else
+								lines << "    #{input_id} --> #{output_id}"
+							end
+						end
+					end
+				end
+				
+				return lines.join("\n")
+			end
+		end
+	end
+end

data/lib/build/graph/walker.rb

@@ -160,7 +160,6 @@ module Build
 			# Register a task as active and record its declared output paths.
 			# @parameter task [Task] the task that is beginning execution.
 			def enter(task)
-				
 				@tasks[task.node] = task
 				
 				# In order to wait on outputs, they must be known before entering the task. This might seem odd, but unless we know outputs are being generated, waiting for them to complete is impossible - unless this was somehow specified ahead of time. The implications of this logic is that all tasks must be sequential in terms of output -> input chaning. This is by design and is not a problem in practice.
@@ -183,7 +182,6 @@ module Build
 			# Mark a task as finished, resolve its output paths and notify any waiting tasks.
 			# @parameter task [Task] the task that has finished execution.
 			def exit(task)
-				
 				# Fail outputs if the node failed:
 				if task.failed?
 					@failed_tasks << task
@@ -216,7 +214,6 @@ module Build
 			# Remove a node and its associated task from the walker, e.g. after it has been invalidated.
 			# @parameter node [Node] the node to remove.
 			def delete(node)
-				
 				if task = @tasks.delete(node)
 					@monitor.delete(task)
 				end

data/lib/build/graph.rb

@@ -8,3 +8,4 @@ require_relative "graph/task"
 require_relative "graph/node"
 require_relative "graph/walker"
 require_relative "graph/edge"
+require_relative "graph/visualization"

data/readme.md

@@ -10,10 +10,16 @@ Please see the [project documentation](https://ioquatix.github.io/build-graph) f
 
   - [Getting Started](https://ioquatix.github.io/build-graphguides/getting-started/index) - This guide explains how to use `build-graph` to build a dependency graph for file-based build systems.
 
+  - [Visualization](https://ioquatix.github.io/build-graphguides/visualization/index) - This guide explains how to use <code class="language-ruby">Build::Graph::Visualization</code> to generate Mermaid flowchart diagrams from a build graph.
+
 ## Releases
 
 Please see the [project releases](https://ioquatix.github.io/build-graphreleases/index) for all releases.
 
+### v2.3.0
+
+  - Add `Build::Graph::Visualization` for generating Mermaid diagrams of the build graph.
+
 ### v2.2.0
 
   - Remove `logger` interface.
@@ -28,6 +34,22 @@ We welcome contributions to this project.
 4.  Push to the branch (`git push origin my-new-feature`).
 5.  Create new Pull Request.
 
+### Running Tests
+
+To run the test suite:
+
+``` shell
+bundle exec sus
+```
+
+### Making Releases
+
+To make a new release:
+
+``` shell
+bundle exec bake gem:release:patch # or minor or major
+```
+
 ### Developer Certificate of Origin
 
 In order to protect users of this project, we require all contributors to comply with the [Developer Certificate of Origin](https://developercertificate.org/). This ensures that all contributions are properly licensed and attributed.

data/releases.md

@@ -1,5 +1,9 @@
 # Releases
 
+## v2.3.0
+
+  - Add `Build::Graph::Visualization` for generating Mermaid diagrams of the build graph.
+
 ## v2.2.0
 
   - Remove `logger` interface.

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: build-graph
 version: !ruby/object:Gem::Version
-  version: 2.2.0
+  version: 2.3.0
 platform: ruby
 authors:
 - Samuel Williams
@@ -84,11 +84,15 @@ executables: []
 extensions: []
 extra_rdoc_files: []
 files:
+- context/getting-started.md
+- context/index.yaml
+- context/visualization.md
 - lib/build/graph.rb
 - lib/build/graph/edge.rb
 - lib/build/graph/node.rb
 - lib/build/graph/task.rb
 - lib/build/graph/version.rb
+- lib/build/graph/visualization.rb
 - lib/build/graph/walker.rb
 - license.md
 - readme.md
@@ -106,14 +110,14 @@ required_ruby_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
-      version: '3.2'
+      version: '3.3'
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 4.0.3
+rubygems_version: 4.0.6
 specification_version: 4
 summary: Build::Graph is a framework for build systems, with specific functionality
   for dealing with file based processes.