<div dir="ltr">Thanks, Valdis. <div><br></div><div>I have found another way around my problem but the information is useful. </div><div><br></div><div>Eric</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jan 27, 2014 at 1:27 PM, <span dir="ltr"><<a href="mailto:Valdis.Kletnieks@vt.edu" target="_blank">Valdis.Kletnieks@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, 27 Jan 2014 12:49:40 -0800, Eric Fowler said:<br>
<br>
> I want to know more about how that file interacts with the build system. In<br>
> particular, in situations like a build seeing a syntax error in foo.c, I<br>
> want to trace from foo.c all the way up to every entry in dot-config that<br>
> imports or depends on foo.c.<br>
<br>
</div>You have that backwards. You want every entry in .config that foo.c depends<br>
on.<br>
<br>
Hint 1: For a given drivers/bar/foo.c, you want to take a quick peek<br>
at drivers/bar/.foo.o.cmd - that's what kbuild uses so 'make' can figure<br>
out what needs rebuilding<br>
<br>
Hint 2: Fiven the list of .c and .h files files that a given .o depends<br>
on, it becomes trivial to generate a list of CONFIG_* variables that are<br>
potentially referenced.<br>
<br>
Hint 3: It's almost always a problem with a missing declaration of 'frobozz'<br>
or whatever - at which point 'find include -type f | xargs grep frobozz' and<br>
then looking at what #ifdef's wrap the definition of frobozz is usually more<br>
productive....<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">cc:NSA<br></div>
</div>