<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 11:58 PM, Thompson, John <span dir="ltr"><<a href="mailto:John_Thompson@playstation.sony.com" target="_blank">John_Thompson@playstation.sony.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">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">I’m experimenting with trying to use separate module maps in my three include directories, as a possible alternative to my one module map approach in a common parent directory.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Isn’t there some way we could support cyclic dependencies in building modules?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">It seems that cycles are okay in sub-modules, but not in top-level modules.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">It seems the only way to work around having cycles in separate directories is to make lots of smaller top-level modules. But then because they are not submodules any more, cycles within an include directory start popping up. </p></div></div></blockquote><div><br></div><div><br></div><div>What you can do is to create a graph of the inclusions between headers, and then run a strongly-connected components algorithm over it (e.g. <a href="http://llvm.org/docs/doxygen/html/SCCIterator_8h.html">http://llvm.org/docs/doxygen/html/SCCIterator_8h.html</a> or your favorite graph library). The graph of top-level module dependencies must be a directed acyclic graph. Ideally, the header dependency graph would be acyclic (hence each header would be its own SCC), so we would have complete freedom in partitioning the graph into connected components that would each become a top-level module (for example, to accommodate multiple include directories). However, in the non-ideal case where we have nontrivial SCC's, all headers in a given SCC must be within the same top-level module.</div><div><br></div><div>Evidently, if headers from two different include directories are contained within a single SCC then that is a problem; however once you identify such an SCC, it should be easy to isolate the recursive dependency and break it.</div><div> </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"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"> For example:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">While building module 'limits' imported from target/include/srclimits_h.cpp:1:<u></u><u></u></p>
<p class="MsoNormal">While building module 'xstddef' imported from D:\usr\local\psp2\ORBIS SDKs\2.000_pre_mod/target/include/limits:17:<u></u><u></u></p>
<p class="MsoNormal">While building module 'initializer_list' imported from D:\usr\local\psp2\ORBIS SDKs\2.000_pre_mod/target/include/xstddef:162:<u></u><u></u></p>
<p class="MsoNormal">While building module 'type_traits' imported from D:\usr\local\psp2\ORBIS SDKs\2.000_pre_mod/target/include/initializer_list:5:<u></u><u></u></p>
<p class="MsoNormal">In file included from <module-includes>:1:<u></u><u></u></p>
<p class="MsoNormal">D:\usr\local\psp2\ORBIS SDKs\2.000_pre_mod/target/include/type_traits:12:10: fatal error: cyclic dependency in module<u></u><u></u></p>
<p class="MsoNormal"> 'xstddef': xstddef -> initializer_list -> type_traits -> xstddef<u></u><u></u></p>
<p class="MsoNormal">#include <xstddef><u></u><u></u></p>
<p class="MsoNormal"> ^<u></u><u></u></p>
<p class="MsoNormal">D:\usr\local\psp2\ORBIS SDKs\2.000_pre_mod/target/include/initializer_list:5:10: fatal error: could not build module<u></u><u></u></p>
<p class="MsoNormal"> 'type_traits'<u></u><u></u></p>
<p class="MsoNormal">#include <type_traits><u></u><u></u></p>
<p class="MsoNormal">~~~~~~~~^<u></u><u></u></p>
<p class="MsoNormal">D:\usr\local\psp2\ORBIS SDKs\2.000_pre_mod/target/include/xstddef:162:11: fatal error: could not build module<u></u><u></u></p>
<p class="MsoNormal"> 'initializer_list'<u></u><u></u></p>
<p class="MsoNormal">#include <initializer_list><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Or is using lots of small top-level modules a bad idea because of the cost in performance when dealing with separate module files?</p></div></div></blockquote><div><br></div><div>Generally, the performance to be gained from avoiding re-inclusion is so tremendous that I would avoid worrying about creating a small, fixed number of top-level modules.</div><div><br></div><div>-- Sean Silva</div><div> </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"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I would also like to minimize major changes to the headers.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks.<span class=""><font color="#888888"><u></u><u></u></font></span></p><span class=""><font color="#888888">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-John<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</font></span></div>
</div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>