<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019 at 12:44 AM Yafei Liu via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div>I just know that Modules has voted in C++20, and I checked the documentation about how Clang implement this feature, correct me if I'm wrong: the third party libraries are keep the same (headers, .so/.a files), and to make modules work, someone needs to add a module map file which can be find by compilers and using it to find the header. </div></div></blockquote><div><br></div><div>There's lots still to be decided/worked out/implemented in terms of what this looks like for end users.<br><br>It's expected that eventually third party libraries would ship modular code. (& eventually the standard library would have a modular interface (as well as the classic #include interface at the very least for backwards compatibility - but maybe some non-modular pieces of the standard library, etc) too - not in C++20, as I understand it)<br><br>Module maps are a feature of Clang's "header modules" (which roughly maps to the "header units" language in the C++ proposal/working draft, etc). The standard wording, as I understand it, only says that "if you treat something like a header unit (import "quoted_identifier") then expect that it /can/ be treated as an isolated unit in other places where it's included using a normal #include" - it's not expected that implementations will scan for these sort of headers & so probably more likely implementations would use something closer to/the same as these module maps that declare ahead of time the headers to treat as header units.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>And without doing the #include copy thing, the compiler directly find the API the code use.</div></div></blockquote><div><br>Not sure what you mean by the "#include copy thing" - oh, you mean classic preprocessing? <br><br>It's a bit more complicated than "the compiler directly finds the API the code uses" - what "directly"? That's sort of still open to discussion.<br><br>Generally the thinking is that compilers will generally build some kind of "Binary Module Interface" (yes, /very/ roughly analogous to a .class file in Java) from the source of a module.<br><br>But these BMI files (clang calls them PCM files - PreCompiled Modules) are not portable between machines, compilers, or even between different builds (with different -D flags, machine targets, etc) because C++ ASTs are /very/ tied to the specific target, unlike something like Java. That means they won't be shipped along with your library or the like.<br><br>You'll still be shipping C++ module interface source files like you ship header files today.<br><br>Any project that wants to use those will need a build system capable of finding these module interface source files (perhaps in locations similar to/the same as header files), building the appropriate BMIs from them (that's a new step that's causing some discussion about just how a compiler will determine how/when to build these BMIs, where to store them (it'll have to be somewhere within the build tree) and consume them, etc), and passing them to the appropriate compilations taht depend on those modules.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>my question is, if I'm writing a new library(no code legacy problem), can I some how abandon headers, just API meta data and shared libraries?<br></div><div><br></div><div>For example, just like java(which add API information in .class file), is there any trying on adding API meta data to a object file?</div></div></blockquote><div><br>No, I don't believe so - it'd be at the wrong layer of abstrtaction - object files have much stronger guarantees between compilers (see, for example, the Itanium ABI) and can have relatively long lifetimes, be used across different compilers (a library may be built with GCC, but the users of that library may be built with Clang, etc). BMIs do not have any such guarantees & need to be generated on a per-project basis, roughly speaking.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>