From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Augustin_Ch=c3=a9neau_=28BTuin=29?= Newsgroups: gmane.emacs.devel Subject: Re: [PROPOSAL] Builder, a build system integration for Emacs Date: Mon, 22 May 2023 18:35:04 +0200 Message-ID: <76e12f7c-335f-476b-ffb3-fd8e8e4ab5d0@mailo.com> References: <95980ffc-86e7-ad54-4a20-539d8c6ea5d0@mailo.com> <3f68f4bc-d426-0bcc-1329-674c12b29386@mailo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35572"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 22 18:36:21 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q18WD-00090e-1p for ged-emacs-devel@m.gmane-mx.org; Mon, 22 May 2023 18:36:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q18VG-0003eQ-BB; Mon, 22 May 2023 12:35:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q18VE-0003dj-Qg for emacs-devel@gnu.org; Mon, 22 May 2023 12:35:20 -0400 Original-Received: from msg-4.mailo.com ([213.182.54.15]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q18V4-0007en-3F for emacs-devel@gnu.org; Mon, 22 May 2023 12:35:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1684773305; bh=OfVoaurdpVIZzgkj6ggF/qSnnE/7jiDhpdEVB/Iva4M=; h=X-EA-Auth:Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hI7dxPecJxJAoAuZJGEELb0yi2E/N4D89N9hebYBYUENXIS3hgVzJgo5dllfS6OAj s6qgxpjzR+drBlIW6Nat797wXzo6JiK3Tt+iiAvXkxPGfK56HOkZL/sSKJ7XQDJqXb in1cGYPYu8ptSW9jBkdg0iaYHDS05hI1N/YGOm/8= Original-Received: by b221-4.in.mailobj.net [192.168.90.24] with ESMTP via ip-20.mailobj.net [213.182.54.20] Mon, 22 May 2023 18:35:05 +0200 (CEST) X-EA-Auth: A9vZP/T/SBkEYcZ5g1SqN3O8/zSVljAsgmAOKKkLjKH1NQI7pXeJNzrS5CQIqB3EJelP25b10yUU/xdV7mU6OhKDKdBbiuFM Content-Language: fr, en-US In-Reply-To: Received-SPF: pass client-ip=213.182.54.15; envelope-from=btuin@mailo.com; helo=msg-4.mailo.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.091, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306273 Archived-At: Le 21/05/2023 à 21:58, Jim Porter a écrit : > On 5/21/2023 12:33 PM, Augustin Chéneau (BTuin) wrote: >> Interestingly I already thought about chaining build systems, but I >> wasn't sure how to implement it. >> Unfortunately the main drawback of your method is that you can't >> easily switch between a debug or release mode (if I understood your >> code correctly). > > Well, the main reason for that is that I just haven't implemented that > yet, since I'd want to go well beyond just a debug/release toggle. For > example, this feature could probably be useful for configuring *any* > kind of build variant, including things like cross-compilation. I > haven't figured out a sufficiently-generic way to handle that across > many build systems though. > Oh I didn't mean a simple toggle, I meant an arbitrary command variant. For instance with Builder you can define a "debug2", "compile_arm" or any other command. Maybe you could do something like this with Taco: (cmake (build-step . configure) (project-file . "CMakeLists.txt") (working-directory srcdir) (commands (release . "cmake" "-G" "Unix Makefiles" builddir) (option . "cmake" "-G" "Unix Makefiles" "-DMY_OPTION=yes" buildir)) (next-step build (make . parallel))) (make (build-step . build) (project-file . "Makefile") (working-directory builddir) (commands (default . "make") (parallel . "make" "-j4"))) > Currently, the way I tend to use taco is just to let it give me an > appropriate template for the compile command, which I hand-edit. For the > configuration step, I often add some extra options, but I only need to > do that when I'm setting up a build; for actually compiling a project, > the default is usually what I want. > >> Also, what if an intermediate step is used in two different context, >> both with different next step? > > I think that should be fine. For example, CMake can generate Makefile or > Ninja files, depending on what flags you pass. Once it does that, it > should be easy to see what the next step is retrospectively by looking > at the files in your build dir. > > (This could get a bit trickier for something like meson, which seems to > want you to use its own `meson compile` wrapper, even though it uses > Ninja as the default build backend. But in that case, I think you'd just > need to scan for an appropriate sentinel file for meson in the build > dir, and then have the "meson compile step" be higher priority than the > generic "Ninja compile step".) > That's why I went with the idea that each build system uses its own command to compile, but that's still not ideal as you can't change globally the "make" command... >> I thought of something with a list of targets names, but I'll need to >> think more deeply. >> Currently you could achieve the same manually, but I agree it's not >> very convenient. > > This is something I've thought a bit about too: right now, taco is only > good for compiling a project, but it doesn't help for things like > running unit tests, building HTML documentation, etc. That will take > some careful thought though, since some build systems let you define > arbitrary build targets for things like this, and others treat targets > specially. For example, `make test` is just a normal Make target like > any other, but `meson test` is (somewhat) special; I could call my Make > "test" target anything I like (e.g. "check"), but I don't think meson is > so flexible. > Yes, this is getting complex very quickly. I think that separating targets is simpler, so you have a known list of targets (configure, compile, package, install, test, and run), and you can treat each case and build system separately. The price to pay is a lower interoperability between build systems, but I'm not sure if the additional complexity worth it anyway. But I would be interested if you manage to solve it properly! > Another lower-level option for targets is to take advantage of Emacs' > built-in Pcomplete code. Pcomplete can handle completing command-line > arguments for lots of commands, and if you added some Pcomplete handlers > for "make" that let you tab-complete Make targets, then you could > probably use that in Builder (or taco) as well. This has the additional > benefit that you get nice tab-completion in M-x shell too. > Nice, thank you! I wasn't aware of its existence, I'll try it.