[Scons-users] Dependency scanning of generated source code files

[Tom Tanner (BLOOMBERG/ LONDON)]

It does because the 2nd time you build, it re-evaluates the dependencies and sees they've changed.

It ends up in a correct state, but selecting the MD5-only decider and having no timestamp checking seems to confuse the scanner code somewhat.

----- Original Message -----
From: bill at baddogconsulting.com
To: TOM TANNER (BLOOMBERG/ LONDON), scons-users at scons.org
At: Apr 17 2013 09:35:57

Tom,

Try :
scons --tree=prune 
A couple times and see if the tree changes.
-Bill
On Apr 17, 2013, at 12:36 AM, Tom Tanner (BLOOMBERG/ LONDON) <ttanner2 at bloomberg.net> wrote:


> I try to use plain text, sometimes the email client gets all exotic.

> 

> However, I have been using --debug=explain and it isn't being very helpful. It shows that with a SConscript a bit like this:

> 

> data = env.Command('data.out', 'data.in', 'gendata < $SOURCE > $TARGET')

> env.Command('Prog.cc', data, 'gensource < $SOURCE > $TARGET')

> env.Command('Prog.hh', data, 'genheader < $SOURCE > $TARGET')

> env.Object('Prog.cc')

> 

> If I change data.in, I get

> scons: rebuilding 'Prog.o' because:

>           `Prog.hh' changed

>           `Prog.cc' changed

> 

> If I then change data.in so that gendata gets an error, obviously the build breaks. So I *revert* the, change, so that Prog.cc and Prog.hh aren't build because they have the right MD5. Then I get

> 

> scons: rebuilding 'Prog.o' because:

>           `Prog.hh' is no longer a dependency

>           `Prog.cc' is no longer a dependency

> 

> Sorry, needed a lot of narrowing down to get that.

> 

> It looks like the scanner code is getting a little confused about what is up-to-date and what isn't.

> 

> ----- Original Message -----

> From: bill at baddogconsulting.com

> To: TOM TANNER (BLOOMBERG/ LONDON), scons-users at scons.org

> At: Apr 16 2013 18:46:05

> 

> Tom,

> 

> The font you are using in the email is very hard to read.

> Plain text is preferred.

> 

> Can you run:

> scons --debug=explain 

> It should show you why targets are being rebuilt.

> 

> -Bill

> On Apr 16, 2013, at 10:07 AM, Tom Tanner (BLOOMBERG/ LONDON) <ttanner2 at bloomberg.net> wrote:

> 

>> I take that back. I haven't discovered what was going on at all.

>> 

>> At some point, scons decides one of the source code files needs rebuilding before it creates an object file.

>> 

>> Somehow or other this scanner decides that it can't scan the source file because it's still being built.

>> 

>> The way to reproduce this is a little complex...

>> 

>> The source code is dependant on another generated file. If you cause the generation of the first file to break, then it goes wrong.

>> 

>> in make terms (which are a bit easier to write)

>> 

>> datafile: stuff

>>   rule

>> 

>> Thing.cc: datafile

>>   rule1

>> 

>> Thing.hh: datafile

>>   rule2

>> 

>> Object('Thing.cc')

>> 

>> if 'rule' produces an error, then when it is fixed, the dependency scan fails  and scons thinks Thing.o no longer has any of the headers as implicit dependencies. This seems to be down to this in Scanner/__init__.py

>> 

>> class Current(Base):

>>    """

>>    A class for scanning files that are source files (have no builder)

>>    or are derived files and are current (which implies that they exist,

>>    either locally or in a repository).

>>    """

>> 

>>    def __init__(self, *args, **kw):

>>        def current_check(node, env):

>>            return not node.has_builder() or node.is_up_to_date()

>>        kw['scan_check'] = current_check

>>        Base.__init__(self, *args, **kw)

>> 

>> 

>> which returns False under that situation

>> 

>> ----- Original Message -----

>> From: ttanner2 at bloomberg.net

>> To: scons-users at scons.org

>> At: Apr 16 2013 14:47:43

>> 

>> Ah, it's OK, I've discovered what I was doing wrong.

>> 

>> ----- Original Message -----

>> From: ttanner2 at bloomberg.net

>> To: scons-users at scons.org

>> At: Apr 16 2013 08:11:37

>> 

>> Yes, there's separate env.Command() for each file.

>> 

>> Interestingly I don't get this problem if I build everything from scratch. It appears to be doing a rebuild that causes the issue and causes the dependency information to be lost.

>> 

>> ----- Original Message -----

>> From: scons-users at scons.org

>> To: scons-users at scons.org

>> At: Apr 15 2013 21:45:34

>> 

>> 

>> Tom,

>> 

>> Does your builder which generates the source code list all the files which are generated as targets?

>> 

>> -Bill

>> 

>> 

>> On Mon, Apr 15, 2013 at 4:35 AM, Tom Tanner (BLOOMBERG/ LONDON) <ttanner2 at bloomberg.net> wrote:

>> I've been somewhat confused as to why my builds break randomly, and I think I've found the problem.

>> 

>> Part of the build generates both source code and header files, then builds an object from the result. Which I would have thought wouldn't be an issue. However, it appears to destroy the dependencies for the .o target somehow, as if I change something use to generate the source and header files, and build with --debug=explain I get something like this:

>> 

>> --- builds thing.cc because another_file has been changed

>> --- builds thing.hh because another_file has been changed

>> --- builds thing1.hh because another_file has been changed

>> 

>> scons: rebuilding 'so_thing.o' because:

>>           'thing.hh' is no londer a dependancy

>>           'thing1.hh' is no longer a dependancy

>>           ....

>>           and so on for every #include in thing.cc

>> 

>> And if you also dump the tree output, you see that the .o is indeed not dependant on those .hh files.

>> 

>> the next time you do this process, you get

>> scons: rebuilding so_thing.o because thing.cc changed

>> even though multiple header files have changed.

>> 

>> All this occasionally results (especially if you are  building in parallel) in so_thing.o being built /before/ one or other of the requisite header files have been built.

>> 

>> So, how do I get the source code file to be rescanned after it is regenerated? and/or why is the scan producing an empty list?

>> _______________________________________________

>> Scons-users mailing list

>> Scons-users at scons.org

>> http://four.pairlist.net/mailman/listinfo/scons-users

>> 

>> <20650719913002.txt><9633722071695002.txt><4883055258303002.txt>_______________________________________________

>> Scons-users mailing list

>> Scons-users at scons.org

>> http://four.pairlist.net/mailman/listinfo/scons-users

> 

> 

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users