Open leidegre opened 1 month ago
I can write up a PR for this if it makes sense.
Should we pass default_nodes
as an array or should we pass it as a lookup table where the DAG nodes are keys for ease of use? GIven that I only have this use case atm I'm biased toward the latter.
i.e.
local default_nodes = {}
for _, v in ipairs(node_bindings) do
for _, default_node in pairs(v.DefaultNodes) do
default_nodes[default_node] = true
end
end
I think this makes sense to add. I vaguely remember doing something like this back in the day for Visual Studio, to mark certain things as being part of the default build, but it wasn't useful or something and I never completed it.
A lookup table probably makes sense if you want to PR this, there's a utility function that makes a LUT from an array.
Perfect, I'm traveling without a computer for a couple of weeks but I'll put together a PR when I'm back.
I primarily use VS Code and wanted to write an IDE generation script that sets
isDefault
for build tasks marked as such.Couldn't find the information in the arguments provided to
generate_ide_files
so I went digging and found thatDefaultNodes
is nil here:https://github.com/deplinenoise/tundra/blob/e48e03bbd8a193889337d25b42cfbd64c64c1c33/scripts/tundra/boot.lua#L142
I'm going to assume this table was meant to include the nodes that are set with
Default "unit"
. These can be found in thenode_bindings
table. For example, this will print the default nodes.Now, the "signature"
generate_ide_files(config_tuples, default_names, raw_nodes, env, hints, ide_script)
hints that just the names was meant to be provided at some point but since parameterdefault_names
isn't actually used by any IDE generation code I could find and DAG nodes don't have unit names, I'd like to suggest this change:And also change
default_names
todefault_nodes
in all instances ofgenerate_ide_files
. You then test DAG nodes in your ide generation script against this table to tell if a node is a default unit or not.