<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Ben,<br>
Thanks for the work! We will definitely need such a concept,
too.<br>
Vassil<br>
On 18/11/15 17:04, Ben Langmuir via cfe-dev wrote:<br>
</div>
<blockquote
cite="mid:22748838-F2AE-4715-BB8E-29B91459570A@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Having heard of no disagreement with the overall idea, I’m moving
ahead. An updated patch is on cfe-commits. Thanks!
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Nov 10, 2015, at 3:39 PM, Ben Langmuir <<a
moz-do-not-send="true" href="mailto:blangmuir@apple.com"
class=""><a class="moz-txt-link-abbreviated" href="mailto:blangmuir@apple.com">blangmuir@apple.com</a></a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;" class="">
<div class=""><span class="">Hey all,</span></div>
<div class=""><b class=""><br class="">
</b></div>
<div class=""><b class="">Background</b></div>
<div class=""><br class="">
</div>
<div class="">Suppose you’re developing a system library
FancyLib that installs a module map file into a
default search path, and you’re using implicit module
maps. When you’re developing locally, you will likely
end up with multiple versions of your module that are
reachable in your search paths:</div>
<div class="">* The system version
/usr/include/FancyLib/module.modulemap</div>
<div class="">* The local development version
~/…/Build/Products/Debug/FancyLib/module.modulemap</div>
<div class=""><br class="">
</div>
<div class="">You generally want to use the local
version, and ignore the one from the system.
Unfortunately, this currently causes
module-redefinition errors if both module map files
are ever parsed. For framework modules, we have been
getting away with this because the compiler almost
never looks into a framework directory if it has
previously looked into a framework directory of the
same name. Sadly the same is not true of
non-frameworks.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><b class="">Proposed change for users</b></div>
<div class=""><br class="">
</div>
<div class="">Users developing non-framework system
modules would add:</div>
<div class="">
-fmodule-map-file=path/to/local/copy/of/module.modulemap</div>
<div class=""><br class="">
</div>
<div class="">Typically, the “local copy” of the module
map file would be to somewhere inside their build
products.</div>
<div class=""><br class="">
</div>
<div class=""><b class=""><br class="">
</b></div>
<div class=""><b class="">Proposed clang changes</b></div>
<div class=""><br class="">
</div>
<div class="">The flag -fmodule-map-file already exists
in clang, and it causes clang to explicitly parse the
specified module map, making any modules defined in
that file available for @import (or via auto-import
from a #import).</div>
<div class=""><br class="">
</div>
<div class="">I propose we extend -fmodule-map-file so
that modules found by this mechanism are allowed to
shadow modules that we found implicitly in header
search paths. When searching for a module by name, we
will not consider the shadowed module at all. It will
be an error for header search to find a header that is
considered part of a shadowed module.</div>
<div class=""><br class="">
</div>
<div class="">If two modules with the same name are
*both* found in the contents of -fmodule-map-file
arguments, then it is a redefinition error. Since
these flags are ordered, we could theoretically allow
shadowing between them, but I cannot think of a good
use-case for this and suspect it would usually be
unexpected to users.</div>
<div class=""><br class="">
</div>
<div class="">If there are two modules with the same
name and *neither* of them comes from
-fmodule-map-file, then it is a redefinition error
just like it is today.</div>
<div class=""><br class="">
</div>
<div class=""><b class="">Why not use header search path
order to do shadowing?</b></div>
<div class=""><br class="">
</div>
<div class="">I originally thought we should just allow
modules that come from earlier search paths to shadow
modules from later ones. This would avoid having to
use an extra flag -fmodule-map-file, and let us infer
the module configuration “for free”, since users are
already accustomed to setting up their header search
paths. However, there are a number of problems with
this approach:</div>
<div class=""><br class="">
</div>
<div class="">* Module map files from “later” search
paths are often parsed ahead of module map files from
“earlier” paths. We would either need to eagerly
parse module map files from all search paths in order
(slow), or we would need to be able to retroactively
make a module shadowed (brittle).</div>
<div class="">* Module map lookup does not know about
search paths, so when searching for a module map file
by umbrella directory we don't know when we cross
search path boundaries</div>
<div class="">* We would need to lock down the
HeaderSearch interface to prevent modifying search
path order in the middle of a build (although that
might be a generally good thing…)</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">My patch implementing this is attached for
reference.</div>
<div class=""><br class="">
</div>
</div>
<span
id="cid:05B33A20-0064-46AC-BA17-110C4E867CA5@localhost"><fmodule-map-file-shadow.patch></span>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Ben</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>