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

[Dirk Bächle]

Hi Faheem,

On 20.10.2014 16:34, Faheem Mitha wrote:
>
> Hi,
>
> [...]
>
> #########################################################################
>
> I'm trying to divide up my SConstruct file into blocks of code, where 
> each
> block is controlled by an Alias, and no code is run by default; i.e. just
> by runningscons. The Aliases are of course run from the command line e.g.
> (in the example below):
>
>     scons h
>
> Here is some example code. This appears to work Ok. However, three
> questions.
>
> Is there a better way to do this?
>

this first question is almost impossible to answer, unless you specify 
on which scale to measure "better". Do you want "less code", "more 
robust code", "more convenience for the user", "more convenience for the 
developer", ... ?

> More specifically, I don't understand how the target arguments in the
> Alias call get passed to the h and h3 action functions. I notice if I
> leave them blank the build does not work. However there is no obvious way
> for the targets to be passed to these functions, since they do not take
> any arguments.
>
SCons is a file-oriented build system, so it expects you to define a 
"target" as an outcome. If you leave this out, SCons won't do anything, 
because obviously there is no output anyway...so why bother? (this a 
little over-simplified, but I hope you get the idea behind it ;) )
> Relatedly, the documentation says that action functions requires target,
> source, and env arguments. These action functions don't have these but
> work anyway. How come?
The "h" and "h3" functions as you define them are *not* Actions. They 
are wrapper methods that you add to an instance of the Environment 
class, and call them as such. So they don't need to pass any arguments, 
but the Program() methods you call inside these wrappers have to. That's 
why you call them with the source and target options...and that's when 
SCons sees the link/dependency to the Alias later on.

Best regards,

Dirk