* The goal should be to simplify the use of tools as much as we want to simplify (or make possible) their implementation

The goal for C++ is to simplify its uses.
The complexity has to go somewhere. I am a tool builder, as well as a C++ programmer/consumer. In that capacity, I will gladly ask a little bit more from the tool builder.

From: tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> On Behalf Of Corentin
Sent: Friday, February 8, 2019 9:59 AM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Subject: Re: [Tooling] Clang Modules and build system requirements


I think the information _should_ be in the source file.
The goal should be to simplify the use of tools as much as we want to simplify (or make possible) their implementation.
Asking people to manually maintain a module mapping for every project doesn't seem to be a reasonable stance given:

  * The information would have to be encoded in the build system too anyway because build systems will have different requirements than these files
  * Each dependency would have to have a similar file which both compilers and tools would have to search for
Module make compiling individual source files harder, however, it is not a new problem
Each source file already depends on a set of include paths and defines that may vary on a source-per-source and configuration-per configuration basis.

Any project beyond a simple Hello World has some of its state in a build system, and the only accurate way to build or parse a TU is to ask the build system for the relevant info.

It would be nice that the source code was the single source of truth. The preprocessor has been prohibiting that since forever (and it is not something we can fix any time soon).
It would, therefore, be preferable not to introduce a third source of truth beyond the build system and the files.


This is not to say such manifest should not exist, in fact, I would love if it did.
But I think it should be generated and maintained by a build system rather than be manually maintained.
Neither of these precludes that

  * The file could be manually maintained if you really want to do so
  * The file could be committed - although I would strongly discourage that

In such a scenario, the file would be updated by invoking the build system (which would *NOT* need to compile anything) to update the file, but a scan of modified files as well as potentially a configuration step


That would ensure the manifest you want describes a known build configuration ( which is relatively easy ) rather than describes how to set up a build ( which is akin as specifying a build system description format)


That generated manifest file could further be used by a compiler to build all the dependency of a TU, but doing so would start to turn compiler in a build system ( minus the configuration part), which I don't think many people would be comfortable with.



On Fri, 8 Feb 2019 at 18:26 Mathias Stearn <redbeard0531_at_[hidden]<mailto:redbeard0531_at_[hidden]>> wrote:
On Fri, Feb 8, 2019 at 12:33 AM Tom Honermann <tom_at_honermann.net<mailto:tom_at_[hidden]>> wrote:

I've been recently claiming two properties of Clang Modules that I believe have been central to their success.

  1. Clang modules are built on #include directives in such a way that existing tools that have no knowledge of Clang modules continue to work as they always have.
  2. Modules are built implicitly on demand (by default) such that build system updates are not required (other than to pass '-fmodules' to enable the feature).

Unfortunately that design of "compiler handles everything, build systems are oblivious" means that clang modules break several important build-system-adjacent tools, such as ccache[1] and icecream[2]. distcc is likely also affected since it originally worked the same as icecream. It is possible that the new "pump" mode makes it work in distcc, but I don't have a cluster to test that on.

I think the clang modules design makes it somewhere between hard and impossible for these kinds of tools to work well with them. Support for distributed builds is one of my major concerns with modules. Almost any form of modules that isn't just "better scoping in headers with no caching" will make distributed builds more complicated than today. I want to hope that this problem is solvable though. Having the machinery hidden in the compiler rather than explicitly managed makes it substantially harder (while admittedly making simple builds simpler).

[1] https://github.com/ccache/ccache/blob/2753dafa38e14bfc5d4bb5c2b692edad964aaef6/src/compopt.c#L66<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fccache%2Fccache%2Fblob%2F2753dafa38e14bfc5d4bb5c2b692edad964aaef6%2Fsrc%2Fcompopt.c%23L66&data=02%7C01%7Cgdr%40microsoft.com%7C35415c3dc0364d3a261a08d68def28c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852455656892180&sdata=M%2BSebtQFsD04dDJHYtFfufvQTchwxolgiW%2FDcUH8cyE%3D&reserved=0>
[2] This is how I tested. It also fails with remote cpp enabled. If there is a better way, I'd be happy to try it.
> ICECC_REMOTE_CPP=0 ICECC_PREFERRED_HOST=remote_host /usr/lib/icecream/bin/icecc clang++ -fmodules -c test.cpp
test.cpp:1:29: fatal error: module 'Header' not found
#pragma clang module import Header /* clang -E: implicit import for #include "header.h" */

_______________________________________________
Tooling mailing list
Tooling_at_[hidden]<mailto:Tooling_at_[hidden]>
http://www.open-std.org/mailman/listinfo/tooling<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7C35415c3dc0364d3a261a08d68def28c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636852455656892180&sdata=MyhtzYcBrEdjxoQMr3ylWYAuO6UXuOO%2FHHvqYkzMuvc%3D&reserved=0>