Add Includes() for specifying implicit dependencies

[bdbaddog]

This issue was originally created at: 2007-04-11 08:16:22. This issue was reported by: joelink. joelink said at 2007-04-11 08:16:22

From the "Adding header file dependencies" thread on the users list: http://scons.tigris.org/servlets/ReadMsg?list=users&msgNo=10623

Jason Orendorff [email protected] wrote: 2. So I would look for a way of telling scons "x includes y". No idea if this exists. If not, do us all a favor and slip Steven a fifty, because darn it, it should! :) For C code, you rarely need it, but this could be really useful for other file types, as an alternative to writing a custom Scanner

What's being added is an Includes(dependent, dependency) method to express an implicit dependency on a file. The effect is that a modification of 'dependency' should result in any target with an implicit dependency on 'dependent' to be rebuilt.

joelink said at 2007-04-11 08:17:43

Created an attachment (id=169) patch

joelink said at 2007-04-11 08:19:26

Created an attachment (id=170) Test configuration

joelink said at 2007-04-11 11:02:33

Hold on this. I have another test configuration that is not behaving as expected.

joelink said at 2007-04-11 12:00:23

Created an attachment (id=171) Updated patch to fix scanner failing on explicit includes

joelink said at 2007-04-11 12:01:15

Created an attachment (id=172) Expanded test scenario

stevenknight said at 2007-05-21 20:40:04

Hi Joe--

I've started integrating this patch. Right now, the patch only works if the target file in question already has a scanner, in which case the explicit list is added to the implicit list found by the scanner. This is non-intuitive behavior for the following really simple test case:

env.Command('file.out', 'file.in', 'build_command $TARGET $SOURCE')
env.Includes('file.in', 'included_file')

(Where "build_command" is a hypothetical utility that doesn't have a scanner but which includes 'included_file' in the output.)

This indicates that supporting explicit includes properly is going to take a little more work, perhaps treating them as co-equal with the implicit includes. Or maybe just modifying the scan() method to handle the explicit includes. I'm not sure yet.

I'm going to keep digging at this, but wanted to let you know in case you wanted to help arrive at a more general solution.

Thanks,

   --SK

joelink said at 2007-05-22 06:19:12

Perhaps a no-op scanner can be used for files without a real one? This scanner would always return an empty list.

One thing I was attempting to accomplish with the current patch was to use the (self) node's scanner for all implicit includes in order to drill down and gather any further implicit deps included (explicitly or implicitly) via the explicitly included files.

Joe

garyo said at 2008-03-17 20:28:10

Milestone: 2.x.

gregnoel said at 2008-12-26 13:20:25

Adjust triage of issues.

stevenknight said at 2009-11-10 18:00:19

stevenknight => issues@scons

Votes for this issue: 8.

joelink attached scons-patch at 2007-04-11 08:17:43.

patch

joelink attached includes-test-case.tar.gz at 2007-04-11 08:19:26.

Test configuration

joelink attached scons-patch at 2007-04-11 12:00:23.

Updated patch to fix scanner failing on explicit includes

joelink attached includes-test-case.tar.gz at 2007-04-11 12:01:15.

Expanded test scenario