env.Depends() in extra_script


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.

Simplified Problem

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”:

    .global binary
    .global binary_size
    .section .rodata
    .incbin "somebinary.bin"
    .int 1b - binary

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")

The Issue

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?

Have you tried AlwaysBuild()?

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’ve been playing around with this, and I have a solution, though it’s less clean than I would like.


env.Depends("$BUILD_DIR/src/binary.o", "binary.bin")

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.

1 Like

That is right solution! :upside_down:

So, in other words, I was over thinking it. facepalm