<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 11, 2013, at 3:37 PM, Ryosuke Niwa wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier <span dir="ltr">&lt;<a href="mailto:kevino@theolliviers.com" target="_blank">kevino@theolliviers.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote:<br>
<br>
&gt; On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier &lt;<a href="mailto:kevino@theolliviers.com">kevino@theolliviers.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileName&lt;portName&gt;.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machin<br>


</div>&nbsp;es it might be a couple seconds. For me, it's negligible given the benefit I get from it.<br>
<div class="im">&gt;<br>
&gt; If I understand correctly, gyp is also capable of this kind of<br>
&gt; wildcard inclusion and exclusion. This will be the tool that allows<br>
&gt; the gyp build to be shared among many ports with the same source<br>
&gt; lists.<br>
<br>
</div>Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation.<br>

</blockquote><div><br></div><div>We do! WebCore.gypi just lists all files and&nbsp;<a href="http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.gyp/WebCore.gyp">http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.gyp/WebCore.gyp</a> defines what gets built on each platform.</div></div></blockquote><div><br></div><div>Sorry if I wasn't clear, but by rule-based compilation, I mean not having a WebCore.gypi to maintain at all. waf needs no such file because it checks the filesystem with a set of rules to determine what sources to build.&nbsp;</div><div><br></div><div>Thanks,</div><div><br></div><div>Kevin</div><br><blockquote type="cite"><div class="gmail_quote"><div>- R. Niwa</div><div><br></div></div>
</blockquote></div><br></body></html>