[cfe-dev] How do I try out C++ modules with clang?

[Sean Silva]

On Sun, Oct 5, 2014 at 11:19 AM, Stephen Kelly <steveire at gmail.com> wrote:

> Sean Silva wrote:
>
> > Currently there is no "dotted path" (e.g. import std.algorithm, or
> > whatever) import in C++; #include's are translated into it:
>
> Right, this is what I was missing from the doc page, thanks!
>
> The starting point you attached allows me to try to make sense of the rest
> of the page.
>
> > try looking at -E with modules enabled.
>
> That's interesting. Usually, the output from -E can be saved to a .i file
> and can be compiled. With modules enabled though, a file containing
> '@import' is generated, which has no further usefulness. Not that using -E
> to create output for further usage, but I'm only making a general remark.
>

Yeah, it's not clear if this is actually a "bug" since this is what clang
is actually doing, but it's still weird to end up with objective C inside
your preprocessed C++ file.


>
> > You currently have to do everything through module maps; listing your
> > header in a module map basically tells clang "I promise you this header
> > meets certain assumptions of modularity" (which are really fairly
> > reasonable assumptions; e.g. you aren't expecting a certain macro to be
> > defined somewhere else in the code).
>
> This is exactly something I want to experiment with, to get a good feeling
> for what the limitations are, with examples.
>
> > in your own module maps for
> > C++, I recommend focusing on making sure your headers are hygienic.
>
> My interest/curiosity is whether module maps can be created for
> Qt/KDE/Boost. It seems that module maps for dependencies (such as the std
> library) are a prerequisite before that kind of playing around anyway. Is
> something floating around already for libc++/libstdc++? Even a trivial one,
> not providing separate std.io etc, but just std?
>

My experience has been that the easiest thing is to start out by just doing
a "unity module" like

module foo {
  header "bar"
  header "baz"
  ...
}

Just list every file in the directory (possibly recursively). Then just
exclude any headers that are causing problems. That should get you up and
running pretty fast.

-- Sean Silva


>
> With my 'buildsystem guy/CMake' hat on, I'm also curious how this modules
> stuff affects the buildsystems out there. Possibly not very much, because
> clang (and hopefully all drivers) will manage the dependency tracking etc.
> I'm interested in user frustration and porting pain.
>
> 1) The link directive could be problematic because it seems to assume
> library names only, and that paths are specified with -L as needed by the
> buildsystem. That's the opposite of CMake philosophy which uses full paths
> instead. Some background information here:
>
>  http://www.cmake.org/cmake/help/v3.0/policy/CMP0003.html
>
> I guess that's not something for clang to worry about, but possibly
> something for a 'how to use modules with cmake' document instructing users
> to use -fno-autolink.
>
> 2) All module.modulemap files have the same name.
>
> [Aside: in the doc, the sentence "Module map files are typically named
> module.modulemap", but elsewhere on the page it is specified to be a naming
> requirement - 'typically' is wrong here]
>
> The 'compiled' module.modulemap is not a distributable. The
> module.modulemap
> file is a distributable. It should be installed with the headers.
>
> That is, if I build/install the foo package to the /usr/local prefix, I
> will
> get files like:
>
>  /usr/local/include/foo.h
>  /usr/local/include/module.modulemap
>
> If I build and install bar, then I will get:
>
>  /usr/local/include/bar.h
>  /usr/local/include/module.modulemap
>
> How do I install foo and bar at the same time to the same prefix? Each
> provides files in the same location which are required to be called
> "module.modulemap".
>
> This potentially affects the installation rules written in buildsystems for
> foo and bar.
>
> 3) cplusplus11 as a 'requires declaration' use is unclear.
>
> If a user uses static_assert in their header, then they say they require
> cplusplus11. MSVC 2010 supports static_assert.
>
> Similarly, if a user uses constexpr in their header, then they say they
> require cplusplus11. MSVC does not support that at all. I can also point to
> other 'c++11' features that even the next MSVC release will not support.
>
> So, is this something that is proposed for standardization? How is MSVC
> expected to handle such a 'requires declaration'? Will there be a
> cplusplus17 requires declaration? When clang implements c++17 partially,
> what behavior will be used for the cplusplus17 requires declaration?
>
> Or do I misunderstand? Is cplusplus11 or similar only suitable for binary
> header is available/not available such as the type_traits example, and it
> doesn't relate to features required by the header? Does cplusplus11 exist
> only for the benefit of std library implementations?
>
>
>
> Thanks,
>
> Steve.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141009/0d277f4d/attachment.html>