From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from codesynthesis.com (codesynthesis.com [142.44.161.217]) by sourceware.org (Postfix) with ESMTPS id D61773851C17 for ; Thu, 5 Nov 2020 07:08:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D61773851C17 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesynthesis.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=boris@codesynthesis.com Received: from brak.codesynthesis.com (unknown [105.184.207.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by codesynthesis.com (Postfix) with ESMTPSA id F1BE65F1DE; Thu, 5 Nov 2020 07:08:56 +0000 (UTC) Received: by brak.codesynthesis.com (Postfix, from userid 1000) id A20B91A800C4; Thu, 5 Nov 2020 09:08:52 +0200 (SAST) Date: Thu, 5 Nov 2020 09:08:52 +0200 From: Boris Kolpackov To: gcc-patches@gcc.gnu.org Subject: Re: [00/32] C++ 20 Modules Message-ID: References: <94392c65-0a81-17c3-c5d3-f15a5e91dd79@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94392c65-0a81-17c3-c5d3-f15a5e91dd79@acm.org> Organization: Code Synthesis User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 07:09:00 -0000 Nathan Sidwell writes: > Here is the implementation of C++20 modules that I have been developing > on the devel/c++-modules branch over the last few years. Congrats on reaching this point. > It is not a complete implementation. The major missing pieces are: > > [...] Building C++20 modules requires non-trivial integration between the compiler and the build system. This patch set introduces a module mapper, a novel mechanism for such integration. Has it been tried by any non-toy build system and on any real project? If the answer is "no", then by shipping modules in GCC 11 are we making any likely changes in this area impossible or unnecessarily difficult? To give an example of such a likely change, currently the mapper has a notion of the central module repository directory that is used to resolve all the relative CMI (compiled module interface[1]) paths (even paths like ./foo.gcm). However, this model will not apply to all build systems. For example, in build2 (the build system I am involved with), there can be no such central place since a project can pull dependencies that are built in other places. Currently, the only way to disable this repository semantics is to use absolute CMI paths throughout. Also, FWIW, I've attempted such a build system integration with build2 back in 2019. While the overall idea of the module mapper worked well, I had to make substantial extensions in my own branch[2] of Nathan's c++-modules (also described in this[3] WG21 paper). AFAIK, these extensions haven't yet been considered for merging into c++-modules. [1] BTW, SG15 seems to have settled on the BMI (built module interface) term instead of CMI: https://github.com/cplusplus/modules-ecosystem-tr/blob/master/definitions.tex [2] https://github.com/boris-kolpackov/gcc-cxx-modules-ex The branch used to live on gcc.gnu.org/git but was dropped as part of the svn-to-git migration. [3] https://wg21.link/P1842