[Scons-users] Dividing SConstruct code into set of aliases; no code called by default

[Dirk Bächle]

Faheem,

On 20.10.2014 23:58, Faheem Mitha wrote:
>
> Hi Dirk,
>
> Thank you for your reply. See below.
>
> [...]
>
>
> Hmm. Well, while I realise that scons is a pretty DIY system as
> software systems go (it basically a set of building blocks) there are
> still good practices, and, er, not so good practices. I prefer the
> good practices. :-)
>
> So, if you prefer I put it another way, I'm asking whether the way I'm
> doing this is reasonable; or whether there is a more natural way to do
> this - one that goes with the grain, rather than against it.
>
from what you wrote here, I understand that you want to know how the 
"SCons way" of expressing this kind of build looks. So, the way the 
framework is designed and implemented you usually don't care about 
wrapping builders into blocks, that you then try to control yourself. 
You leave the decision about which sources changed, and therefore which 
targets need to be rebuilt, to SCons (after all, that's why you use a 
build system and don't write shell scripts, right?). You do this by 
simply specifying which environments and builders should get used for 
creating all your targets. And *all* means all here...
Then, from this kind of "forest of target trees", you select the 
concrete outputs that you want to get compiled/created in this run by 
specifying their names as arguments on the command-line.
If no dependencies have changed, SCons will detect that they're 
up-to-date...so they don't get rebuilt.

Regards,

Dirk