<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 31, 2014, at 6:00 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 31, 2014 at 5:25 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com" target="_blank">kyrtzidis@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div style="word-wrap:break-word"><br><div><div class=""><div>On Mar 31, 2014, at 4:44 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 31, 2014 at 4:23 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com" target="_blank">kyrtzidis@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>><br>
> What I'm suggesting is:<br>
><br>
> 1) Drop the -I paths that are earlier than the module in the header search path when building the module<br>
> 2) Include the rest of the header search paths in the configuration hash for the module<br>
<br>
</div>This will prevent us from sharing system modules across projects, and, as Ben already mentioned, will result in an explosion of module files, even within the same project.<br></blockquote><div><br></div><div>Why? System modules would only have system include paths, and these would usually be the same across projects, right?</div>
</div></div></div></blockquote><div><br></div></div><div>I see what you mean, but we also need to support the case where the system framework developer can point to the framework in his local directory to be used, instead of the system one, how do you suggest we allow this ?</div>
</div></div></blockquote><div><br></div><div>I'd like for a module to be able to specify its own include paths. If a module does so, the include paths of the host build should not be included in its hash.</div></div></div></div></blockquote><div><br></div><div>That didn't quite address my question, let me be more specific. We generally need to allow, as an example, system AppKit to import a user-local Foundation; neither system AppKit specifying its own include paths, nor looking up module dependencies of AppKit only in system include paths, allow this.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>
</div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div style="word-wrap:break-word"><div class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;">
Even if we include the search paths in the module hash we will still need to re-lookup the module dependencies before loading the module, because a new module.map may have showed up somewhere in the search paths since the time we built the module; unless I’m missing something, I don’t see any benefit in including the header search paths in the hash.</blockquote>
<div><br></div><div>The hash should include everything that affects the way the module is built. If we're transferring include paths from the user of the module to the module build, the hash should include those paths, or two modules with different search paths could collide in the cache.</div>
</div></div></div></blockquote><div><br></div></div><div>The collision is avoided by using the path to the module.map as Ben proposes; if different search paths resolve to different module dependencies, this is a case where we need to rebuild, but the same is true if the same paths are used but a different module.map shows up as dependency.</div>
</div></blockquote><div><br></div><div>I don't see how that's sufficient -- the include paths can also affect how non-modular #includes within the module behave.</div><div><br></div><div>As a somewhat-contrived example, suppose I have a library</div>
<div><br></div><div> blah/</div><div> module.map</div><div> foo.h</div><div> mode1/</div><div> foo-impl.h</div><div> mode2/</div><div> foo-impl.h</div><div><br></div><div>... where foo-impl.h is textually-included into foo.h, and this is supposed to be used in two modes: one with a -I path pointing to mode1, and one with a -I path pointing to mode2. We should ensure those two modules don't collide in the cache. (Maybe mode1 and mode2 provide inline assembly for different CPU variants, or such.)</div>
</div></div></div>
</blockquote></div><div><br></div><div>Non-modular includes are problematic beyond just how to lookup the headers during module building. The major problem they introduce is that those same non-modular headers can be textually #included in the translation unit, before or after the module import that contains the same header contents, causing multiple definitions or other semantic issues. That's why we tend to prefer the clear semantic model that modules depend only in the headers that the module is comprised of, or other modules, and we want to encourage people to modularize their headers.</div></body></html>