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

[Tom Tanner (BLOOMBERG/ LONDON)]

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
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://four.pairlist.net/pipermail/scons-users/attachments/20130416/c95f60c0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20650719913002.txt
Type: application/octet-stream
Size: 149 bytes
Desc: not available
Url : <http://four.pairlist.net/pipermail/scons-users/attachments/20130416/c95f60c0/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 9633722071695002.txt
Type: application/octet-stream
Size: 149 bytes
Desc: not available
Url : <http://four.pairlist.net/pipermail/scons-users/attachments/20130416/c95f60c0/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4883055258303002.txt
Type: application/octet-stream
Size: 149 bytes
Desc: not available
Url : <http://four.pairlist.net/pipermail/scons-users/attachments/20130416/c95f60c0/attachment-0002.obj>