On Mon, May 7, 2018 at 10:13 AM Brad King <brad.k...@kitware.com> wrote:
> On 05/07/2018 12:01 PM, Stephen Kelly wrote: > > Hopefully Brad or someone else can provide other input from research > already done. > > I'm not particularly familiar with what compiler writers or the modules > standard specification expects build systems to do w.r.t modules. > However, IIUC at least at one time the expectation was that the module > files would not be installed like headers The module interface source file is, to the best of my knowledge, intended to be installed like headers - and I'm currently advocating/leaning/pushing towards it being installed exactly that way (in the same directories, using the same include search path, etc). > and are used only within a local build tree. The /binary/ representation of the module interface is likely to be only local to a specific build tree - since it's not portable between compilers or different compiler flag sets, even. > Are modules even supposed to be first-class entities > in the build system specification that users write? > > In the Fortran world users just list all the sources and build systems are > expected to figure it out. CMake has very good support for Fortran > modules. > Our Ninja generator has rules to preprocess the translation units first, > then parse the preprocessed output to extract module definitions and > usages, > then inject the added dependencies into the build graph, and then begin > compilation of sources ordered by those dependencies (this requires a > custom fork of Ninja pending upstream acceptance). > > Is that what is expected from C++ buildsystems for modules too? > Yes, likely something along those lines - though I'm looking at a few different possible support models. A couple of major different ones (that may be both supported by GCC and Clang at least, if they work out/make sense) are: * the wrapper-script approach, where, once the compiler determines the set of direct module dependencies, it would invoke a script to ask for the location of the binary module interface files for those modules. Build systems could use this to dynamically discover the module dependencies of a file as it is being compiled. * tool-based parsing (more like what you've described Fortran+Ninja+CMake is doing). The goal is to limit the syntax of modules code enough that discovering the set of direct module dependencies is practical for an external (non-compiler) tool - much like just some preprocessing and looking for relatively simple keywords, etc. - then the tool/build system can find the dependencies ahead of time without running the compiler (a 3rd scenario, is what I've been sort of calling the "hello world" example - where it's probably important that it's still practical for a new user to compile something simple like "hello world" that uses a modularized standard library, without having to use a build system for it (ie: just run the compiler & it goes off & builds the in-memory equivalent of BMIs without even writing them to disk/reusing them in any way)) - Dave > > -Brad >
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
