[Scons-users] Dependencie with Sconscripts and builder's environment

[Albert Arquer]

Hi Bill,

yes sure, I though it would be much harder to do that because I thought it
would have to do with some weird feature we are using, however I was able
to replicate the issue with a very tiny peace of code:

Create a file called sconscript.py with the following contents:

from SCons.Environment import Environment
from SCons.Builder import Builder
from SCons.Builder import is_a_Builder
import datetime
import os

def TestBuilder(target, source, env):
    print "now generating " + str(target[0])
    print "comment is: {}".format(env['COMMENT'])

    if os.path.exists(str(target[0])):
        os.remove(str(target[0]))
    file_target = open(str(target[0]), 'w')
    file_target.write(str(datetime.datetime.now()))
    file_target.close()
    return None

env = Environment()

env.PrependUnique(BUILDERS = {'test_builder':Builder(action = TestBuilder)})

env.test_builder( target = "dummy_target", source = [], COMMENT = "holaaaa")
env.Help("dummy_target")



Then, from the directory where the file sits: scons -f sconscript.py
--debug=explain dummy_target

Your should see how the target is built, the output is generated and the
print statements appear on the console.
Now go into sconscript.py and modify the COMMENT argument passed to the
test_builder, put "holaaaa2" for example.

Rerun the las scons command: scons -f sconscript.py --debug=explain
dummy_target

You should see scons reporting the target is up to date, however it is not,
it's arguments have changed!

So is this a known limitation? Are we doing something wrong?

Thanks,
Albert.


2016-10-11 17:39 GMT+02:00 Bill Deegan <bill at baddogconsulting.com>:

> Albert,
>
> Can you provide an example of a change to an Environment() which should
> but isn't causing a rebuild?
> Preferably a small testcase we can run without your complete
> environment/sources..
>
> -Bill
>
> On Tue, Oct 11, 2016 at 5:16 AM, Albert Arquer <albert.arquer at gmail.com>
> wrote:
>
>> Hello there
>>
>> We use scons intensively in our team to build our deliverables. We have
>> many many sconscripts and we found out that we had to explicitly tell scons
>> that a particular target depends upon those sconscripts
>> self.env.Depends(target, scons_sources...).
>>
>> The reason for this is that while many times modification of our
>> sconscripts are automatically caught by scons (because they have an impact
>> in the dependency tree) other changes might be more subtle, for examples
>> those changes which only modify a builder's environment.
>> Ideally we would expect scons to detect changes in the builder's
>> environment and realize the target generated by that builder is out-dated,
>> however this is not what we have seen.. If a builder's env changes but
>> no other dependencies or target/sources change, scons still says the target
>> is up to date...
>>
>> Is this a known limitation of scons? if so, is there any workaround
>> besides the one I already stated? or are we going about this all wrong?
>>
>> I find this weird as I have never seen any examples where a scons target
>> was explicitly registered as dependent on the Sconscript which declared the
>> target, so that makes me suspect there might be a better way to do this...
>>
>> Also another weird thing is that I have noticed scons is capable of
>> detecting when a particular builder has changed, as is capable of isolating
>> that change to the targets that actually use that builder, so why not
>> compute the builder's signature combined with the environment?
>>
>> Thanks,
>> Albert.
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
> _______________________________________________
> 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/20161011/1d619e57/attachment-0001.html>