Open Bug 1191873 Opened 9 years ago Updated 2 years ago

Experiment with clang modules

Categories

(Firefox Build System :: General, defect)

defect

Tracking

(Not tracked)

People

(Reporter: ehsan.akhgari, Unassigned)

Details

I'm copy and pasting some stuff from an email thread where we discussed this.  The docs for this feature are at http://clang.llvm.org/docs/Modules.html#modularizing-a-platform

What I was imagining we would do is that at configure time, we would compute the paths to the system headers (as we currently do), and we would generate a std.modulemap based on it.  Something like (untested):

module std {
  umbrella "/usr/include"
  // other similar directories
  export *
}

I suppose the first step could be doing that and adding -fmodules and -fimplicit-module-maps if needed to CXXFLAGS and building the whole tree successfully.

Next, we would start to define modulemaps for our code.  These will be .modulemap files we will check into the tree.  One thing that I am not sure of is whether the way we copy headers to objdir/dist/include would work well with module maps.  My suspicion is that it may not, and if this proves to be the case, then we would need to do the harder thing, which is adding support for module maps to the build system, hopefully by piggybacking on the existing EXPORTS moz.build rules to generate the right module maps and put them in dist/include.  This part requires experimentation.
(In reply to Ehsan Akhgari (not reviewing patches, not reading bugmail, needinfo? me!) from comment #0)
> we would compute the paths to the system headers (as we currently do)

Note we actually don't compute any system header paths, except for Windows, and that's only for STL wrappers.
Yes, we would need to start doing that.  It's just a matter of parsing the output of `clang++ -E -x c++ - -v < /dev/null` so it should be fairly simple to do.
Product: Core → Firefox Build System
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.