difference between SConscript and SConstruct files?

Question

As a newbie to scons, I'm faced with converting a project with multiple modules in the one repo with a common top-level build. Each module already has a SConstruct file - to allow building them on their own.

Reading on hierarchical scons setup, I see the idea is to use a top-level SConstruct which loads the sub-projects' build files using SConscript() function, and that those files are/should be called SConscript. I find the rest of the info somewhat vague (or maybe TLDR?) - so

• wondering is that a requirement for those lower-level scripts to be SConscript files?
• IOW, is there a semantic/scope/evaluation difference between SConscripts and SConstructs apart from one intended as an entry point, whereas the other one just a "sub-build file"?
• Is there any point in refactoring those sub-project's SConstructs to be one liners to call a SConscript in the same level + chaining these up to the top level Sconstruct?

Thanks!

Answer 1

Answer to your questions in order

1. No the lower level files can be called anything, as you specify the path and filename in the SConscript() call
2. Each SConscript is evaluated in it's own scope. You can pass via Export() (or SConscripts exports= argument) and bring into the SConscript (whatever you end up calling it) via Import().
3. Entirely depends if you want to do any central/top level configuration to be propagated to your sub projects. This could still be done via Import() statements in the subproject's SConstruct and then checking if the variable you expect to have imported is defined (via try/except perhaps)

This sub project has SConstructs has been done before. Likely it's cleaner to use Import() in your SConstructs in your sub project and then verify that whatever you expect to have passed is there or not before using it. Wrapping that with copious comments as to why you are doing so if the sub projects are also used standalone..

Does this answer your question?