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

[Faheem Mitha]

Hi Dirk,

Thank you for your reply. See below.

On Mon, 20 Oct 2014, Dirk Bächle wrote:

> 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", ... ?

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.

I see that wrapping a set of builders with a function, and then
calling that function is suboptimal in one important respect.

Here again are my criteria: divide the code into pieces, each piece
controlled by an alias. Nothing should run by default: i.e. if just
scons is called. Actually, it would be good if a help message was
printed if just scons was called (it doesn't currently do that). I
haven't yet even been able to figure out how to get the `--aliases`
command called by default.

Since the function itself does not know about the build targets, it
runs even if the targets are present. This is rather suboptimal. Could
this code be altered so the function does not run if the targets have
already been built?

I noticed that trying to wrap a collection of builders with another
builder doesn't work, because scons complains that two ways of
building the same target have been specified. Is there some way around
this?

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

Yes, I realise that targets need to be specified. My main question is
how the builders (which are inside the function, or wrapper) are
seeing 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.

I don't follow this. My question is how the target arguments to the
Alias function (if it is a function) get inside the wrapper function
to the builder objects. I realise the builder objects are called with
source/target options, but if I don't pass any arguments to the Alias
object, nothing happens.

                                                       Regards, Faheem