Closed lundmark closed 7 years ago
So this was because I had two objgroups that had nothing in them, so it turns out that their GUID becomes the same. Much obliged if there was a warning or similar for empty objgroups.
Thanks for the report. The GUID hashing is pretty lame, it simply uses the label of the node (the thing that prints when it executes) - it could probably be redesigned to use the input data in some more elaborate way.
I'm not sure if I have the same issue, I have written a defrule for flatbuffers which generates from an idl an header file only (no implementation file) and writing that in a sources-statement triggers the "same guid" error. any ideas how to work around that limitation?
to give you a bit more context:
DefRule {
Name = "FbsCompiler",
Pass = "CodeGeneration",
Command = "flatc -c -b --scoped-enums $(<)",
ImplicitInputs = {"flatc"},
Blueprint = {
FbsFile = { Required = true, Type = "string", Help = "Input filename" },
},
Setup = function(env, data)
io.write(string.format("Test\n"))
return {
InputFiles = { data.FbsFile },
OutputFiles = {
"$(OBJECTDIR)/"..string.gsub(data.FbsFile, ".fbs", "_generated.h"),
},
}
end,
}
Program {
Name = "test",
Sources = {
FbsCompiler { FbsFile = "monster.fbs" },
...
and in my case it seems the "ImplicitInputs" triggered the error. replacing that with "$(OBJECTDIR)$(SEP)flatc$(PROGSUFFIX)" fixed it for me...
It seems DefRule
uses the input files ($(<)
) as the default label/annotation, which is then what is hashes to make a guid. You can supply your own annotation.
From the DefRule
function:
local annot = ruledef.Annotation
if not annot then
annot = name .. " $(<)"
end
So if you add Annotation = "FbsCompiler $(@)"
then it should be unique because your output files have to be unique anyway.
Closing as fixed. Let me know if it should be reopened.
Hi,
I'm running tundra 2.0 beta11 and when trying to build my project I get the following error: [E] duplicate node guids: ObjGroup and ObjGroup share common GUID (bbdac33add54cc51f562e674fdb744d3)
Now I assume that this is because somehow two different ObjGroup's somehow generate the same GUID. I'm not really sure what it is that I've been doing wrong - this didn't come up from adding another objgroup or similar. It would be very nice if the names of those objgroups would be printed so that I could get some more information about the issue and how I could resolve it myself.