I took a look at the caveat mentioned here, namely that a full build isn’t preformed due to the seperation of toolchains, and decided to attempt to fix this so that we wouldn’t really need to deal with it.
I have a program that depends on an external binary that I embed in the final binary. I do this by creating a file “binary.s”:
There is no problem with this, except that I want the object built from “binary.s” to be rebuilt whenever “somebinary.bin” changes. “Easy! Just call Depends!” Alright: env.Depends(ofile, "somebinary.bin")
Where does ofile come from? If this were in the main file, you could just do ofile = env.Object("src/binary.s") and depend on the fact that nothing has tried to create an object for that source file before. However, this isn’t the main file, this object has/will likely be created again, and I’m not normally a SCons user, let alone an expert.
So, can I call the Object constructor multiple times, add a dependency on one of the instances, and have it all work out? Or is there something else I need to do?
AlwaysBuild, eh? Well, if I were to use that, then just replace everywhere I say “env.Depends” with “env.AlwaysBuild”.
AKA, the same problem, at least in my mind.
I’m probably overthinking this, but once again, I’d need to (re)create the StaticObject so that I could pass it to AlwaysBuild, and I need to know if it ‘just works’, even if multiple places define the same object and each add dependencies.
Honestly, I guess I should just try it, and see if it works. I was hoping that someone else that knew what would happen would reply, but ah well. Time to experiment.
I was hoping to do something more like env.Depends(Object("src/binary.s"), "binary.bin"), but it appears that the fears that I expressed earlier were somewhat true, I couldn’t get anything like that to work. I guess this solution is clean enough, though.