220 24720 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Modules are hard for build tools Date: Fri, 26 Feb 2016 11:57:40 -0800 Lines: 99 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1456516665 31018 80.91.229.3 (26 Feb 2016 19:57:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 19:57:45 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDVNBJG4YAIBBNO4YK3AKGQEIIPXTRA@isocpp.org Fri Feb 26 20:57:45 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aZOWH-0004er-2J for gclcip-std-proposals@m.gmane.org; Fri, 26 Feb 2016 20:57:45 +0100 Original-Received: by mail-oi0-f72.google.com with SMTP id i14sf152903662oig.3 for ; Fri, 26 Feb 2016 11:57:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=gXTDDrDCy4teVJmPa0iFONm1OUrGM2Lhll+WY5QY8sU=; b=dpLzS1ngV/5s1rDQHqQpqJ0IqrKDCluImZZhQhrPGB2pLILBUjeGKQkvSAv01Ck+4J 1cInso4kHc9Xdg3yKXwS5wOV6cl5HV1Y+99x00Am3fzitJES/HFshDYasCuzbLvIndfe JJFmt4acIKhd9ccfQnlHLLm5UzQZ43Qu2EkyU/8Bl8549aWvxppDgNFwCGOHlTDfkyJ5 8pdWbdtbFNEF3p0YxoQH8s0robyuGSq8d9ai+SXPzhx5TX+5AjVTCUmWqDaQt/9aIHHP SGCG2Gok5ryP2rSCqQ7bsWj4XMexra4+m1kdrp5PYaEuxJoOxsQAesDLQnBf5llIorJD eQ1Q== X-Gm-Message-State: AD7BkJIi2j+IcFwWOvE6Idavv9poT2RAjUJL54sNnnVAJeq6DJ1QgNA10oYcgX8p5M6BOg== X-Received: by 10.182.247.97 with SMTP id yd1mr2609110obc.9.1456516663303; Fri, 26 Feb 2016 11:57:43 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.29.136 with SMTP id b8ls1361998qgb.96.gmail; Fri, 26 Feb 2016 11:57:40 -0800 (PST) X-Received: by 10.31.162.82 with SMTP id l79mr2643453vke.76.1456516660784; Fri, 26 Feb 2016 11:57:40 -0800 (PST) Original-Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com. [2607:f8b0:400c:c05::22a]) by mx.google.com with ESMTPS id h20si9631306vkf.172.2016.02.26.11.57.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2016 11:57:40 -0800 (PST) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c05::22a as permitted sender) client-ip=2607:f8b0:400c:c05::22a; Original-Received: by mail-vk0-x22a.google.com with SMTP id e6so86973321vkh.2 for ; Fri, 26 Feb 2016 11:57:40 -0800 (PST) X-Received: by 10.31.173.18 with SMTP id w18mr2268209vke.31.1456516660291; Fri, 26 Feb 2016 11:57:40 -0800 (PST) Original-Sender: metafoo@gmail.com Original-Received: by 10.31.147.74 with HTTP; Fri, 26 Feb 2016 11:57:40 -0800 (PST) In-Reply-To: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c05::22a as permitted sender) smtp.mailfrom=metafoo@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24720 Archived-At: On Fri, Feb 26, 2016 at 7:23 AM, Abyx wrote: > Without modules we have the following situation: > > There is a bunch of source files with code - > > tu1.cpp, tu2.cpp, ..., tuN.cpp, > h1.hpp, h2.hpp, ..., hM.hpp, > > And a build tool script (*make, gyp, gn, etc) > > add_executable(my_app, tu1.cpp, tu2.cpp, ..., tuN.cpp) > > The build tool have to preprocess all the .cpp files, find all the > "#include" directives and generate the build rules: > > # target dependencies > tu1.cpp.o : tu1.cpp, hA.hpp, ..., hX.hpp > ... > tuN.cpp.o : tuN.cpp, hB.hpp, ..., hY.hpp > my_app : tu1.cpp.o, ..., tuN.cpp.o > > Note that the *.o targets don't depend on each other and can be compiled > in-parallel. > > -------------------------------------------- > > Modules add the module interface translation units (I'll call it an *.ixx > file) and compiled module exports (an *.ifc file) > If a translation unit A.cpp imports a module B, then it depends on B.ifc > which depends on B.ixx. > > So if we have the following source files (for simplicity let's not use > header files) > > a_tu1.ixx, a_tu2.cpp (imports B), ..., a_tuN.cpp // module A > b_tu1.ixx (imports A), b_tu2.cpp, ..., b_tuM.cpp // module B > ... > m_tu1.ixx, m_tu2.cpp, ..., m_tuM.cpp // module M > > This means that a build tool have to produce the following build rules: > > # targets dependencies > a_tu1.ixx.o, A.ifc : a_tu1.ixx > b_tu1.ixx.o, B.ifc : b_tu1.ixx, A.ifc > ... > m_tu1.ixx.o, M.ifc : m_tu1.ixx, X.ifc, ..., Y.ifc > a_tu2.cpp.o : a_tu2.cpp, B.ifc > ... > m_tuN.cpp.o : m_tuN.cpp, X.ifc, ..., Y.ifc > my_app : a_tu1.ixx.o, ..., m_tuN.cpp.o > > And now we have *.o targets which depend on *.ifc targets, and *.ifc targets > which depend on other *.ifc targets. > > So what should we write in our build tool script, so it would generate such > build rules? > > It would be great if we could just write down all the translation units: > > add_executable(my_app, a_tu1.ixx.o, ..., a_tuN.cpp.o) > > But then the build tool would have to not only preprocess C++ code (to find > all the #include directives), but also parse it, in order to find the import > statements. > > It's not practical to manually write all the dependencies in the build > script, because this would just duplicate the import statements in the code: > > add_module_dependencies(A, b_tu1.ixx, ..., x_tuX.cpp) > add_module_dependencies(B, a_tu2.cpp, ..., y_tuY.cpp) > -- or -- > add_module_dependencies(b_tu1.ixx, A) > add_module_dependencies(a_tu2.cpp, B) You have (at least) three choices: 1) You manually list the dependencies between your libraries in your build rules. This is often a good thing for your code health, but may not be right for everyone. 2) Your build process scans for import statements. This is not really any harder than scanning for #includes; no real parsing is required, at most, you need tokenize and maybe preprocess (if you want 'import MACRO_NAME' to work). The same is true for #includes. 3) You ask your compiler to implicitly build (and cache) module interfaces on demand. This requires that your compiler has some way to map from an imported module name to the relevant interface file(s). That could happen via some implementation-defined means (such as Clang's module map files) or by making the module names directly correspond to module interface files (as suggested in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0273r0.pdf). -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnM09zTWXR_0NDj3f%3DQ1mqoO66hNeg5SPEPU9MX0eM_Ng%40mail.gmail.com. .