<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jan 18, 2017 at 10:20 PM Stephen Kelly <<a href="mailto:steveire@gmail.com">steveire@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
    <div class="m_8419110947294836577moz-cite-prefix gmail_msg">On 01/18/2017 11:12 AM, Manuel Klimek
      wrote:<br class="gmail_msg">
    </div>
    </div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg">
          <div dir="ltr" class="gmail_msg">On Wed, Jan 18, 2017 at 1:15 AM Stephen Kelly
            via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>>
            wrote:<br class="gmail_msg">
          </div>
          <blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Richard
            Smith via cfe-dev wrote:<br class="gmail_msg">
            <br class="gmail_msg">
            > This does mean that build systems will need to track
            interface<br class="gmail_msg">
            > dependencies in a way they didn't before (you need to
            know which module<br class="gmail_msg">
            > interfaces should be built before which other module
            interfaces), and that<br class="gmail_msg">
            > information will either need to be provided or detected
            by the build<br class="gmail_msg">
            > system. If a build system wishes to automate this, it
            would not be<br class="gmail_msg">
            > dissimilar to the #include scanning that some existing
            build systems<br class="gmail_msg">
            > already perform.<br class="gmail_msg">
            <br class="gmail_msg">
            In my perspective the biggest problem with clang modules
            (and the reason I<br class="gmail_msg">
            stopped investigating it from a buildsystem perspective) is<br class="gmail_msg">
            <br class="gmail_msg">
             <a href="https://llvm.org/bugs/show_bug.cgi?id=21593" rel="noreferrer" class="gmail_msg" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=21593</a><br class="gmail_msg">
            <br class="gmail_msg">
          </blockquote>
          <div class="gmail_msg"><br class="gmail_msg">
          </div>
          <div class="gmail_msg">I believe explicit module maps solve your problem, but
            your bug doesn't contain enough information to know what you
            want :)</div>
        </div></div></blockquote></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"></div>
      </div>
    </blockquote>
    <br class="gmail_msg">
    Hi Manuel,<br class="gmail_msg">
    <br class="gmail_msg">
    I don't know what "explicit module maps" means. <br class="gmail_msg"></div></blockquote><div><br></div><div>You can give the module maps necessary to clang at the command line instead of relying on clang finding them somewhere.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
    The bug report links to a mailing list thread. Does that provide
    more context? IOW: Why make <br class="gmail_msg">
    <br class="gmail_msg">
     /usr/include/module.modulemap <br class="gmail_msg">
    <br class="gmail_msg">
    contended by everything that installs into /usr ? Was a solution of
    uncontended<br class="gmail_msg">
    <br class="gmail_msg">
     /usr/include/<name>.modulemap <br class="gmail_msg">
    <br class="gmail_msg">
    considered and discarded? Why?<br class="gmail_msg"></div></blockquote><div><br></div><div>You can have /usr/include/<name>.modulemap if you want. Your build system just will need to support that.</div><div><br></div><div>You can even put your module map in /usr/lib or wherever else other parts of your library are going to be installed in, as long as build systems will pick up the right flags to compile your library with.</div><div><br></div><div>The current implementation of automatic detection of module maps is completely driven by the original Obj-C use cases.</div><div>For C++, I don't expect that we will use that mechanism, much for the reasons you cite. My hope is that we'll go into a world where we explicitly specify the module maps on the command line (less magic!).</div><div><br></div><div>Cheers,</div><div>/Manuel</div><div><br></div></div></div>