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

[Bill Deegan]

Faheem,

Have you had a chance to read the User's guide yet?

It seem you have many misconceptions about how SCons works.

All builders return lists of Node objects. (You're returning 0)

In your initial email you are not really saying why you want to do what you
are doing.
Knowing the why will help to guide a reasonable way to do it.
Generally such logic is used to speed up a slow build.
If your goal is only to avoid building targets by default, you can use
env.Ignore('.',top_thingy)

I suggest you look at: Ignore(), BUILD_TARGETS, ARGLIST in the manpage.
http://www.scons.org/doc/2.3.2/HTML/scons-man.html

And also a thorough read through the users guide. and this wiki page for
the 10k ft view.
http://www.scons.org/wiki/SconsProcessOverview

You can do something like:


if 'foo' in BUILD_TARGETS:
   my_list_of_foo_Node_objects_from_builders = []
   my_list_of_foo_Node_objects_from_builders.extend(env.Program("hello1",
"hello1.c"))
   my_list_of_foo_Node_objects_from_builders.extend(env.Program("hello2",
"hello2.c"))
   env.Alias('foo',my_list_of_foo_Node_objects_from_builders)

-Bill




On Mon, Oct 20, 2014 at 2:58 PM, Faheem Mitha <faheem at faheem.info> wrote:

>
> 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
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20141020/17d061da/attachment-0001.html>