From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Dirk-Jan C. Binnema" Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Project out of sources compilation Date: Mon, 01 Apr 2024 10:49:25 +0300 Message-ID: <87le5x34l6.fsf@gmail.com> References: <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2.ref@pyv2z5snot6h> <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2@pyv2z5snot6h> <87ttl5w0mr.fsf@gmail.com> <1fd527fc-9643-49d2-8fae-d7e7fd043fe1@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1284"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.12.2; emacs 30.0.50 Cc: Dmitry Gutov To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 01 09:50:35 2024 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 1rrCR8-0000BP-4I for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Apr 2024 09:50:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rrCQA-0000U8-5c; Mon, 01 Apr 2024 03:49:34 -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 1rrCQ7-0000TZ-Et for emacs-devel@gnu.org; Mon, 01 Apr 2024 03:49:31 -0400 Original-Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rrCQ5-0002hC-Fd for emacs-devel@gnu.org; Mon, 01 Apr 2024 03:49:31 -0400 Original-Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-515a81928a1so6047831e87.3 for ; Mon, 01 Apr 2024 00:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711957766; x=1712562566; darn=gnu.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=bHy1m/17/Y4TLz0GVGjpU9XMKYpDKy0TqidJiFrHN6E=; b=ZIFROTAipKBy4OpcPn2dB3S8GlFIyz57YFuHCHjCHYFftAzK1fKH81S79Vk9MTX/Mu mCKXLPezQC5Qk0dGHniiNijC/XCvVUiZyOQH/IVMwuOz3Y8BiFEOTHbEyzDMsIznIovx QnrvSNXSYfDSJciTVr8Fs1pvtIUBcdLiglc3Ozo4U4ug/Mt75WXGeectH//olTTcBtZH qTTPdBcwBr6UUMqVALfxfuPNCk8vx2BNPeSvOFJuqDE7YXEZxzysDw8paH+kQ4ATV0ms nNpoTPZvErUX82FS9jDHvoH0gATeL6VYqnPC/jUthh+Te9GheZ+9VO9ZuMLRg+IN0eYF KQtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711957766; x=1712562566; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bHy1m/17/Y4TLz0GVGjpU9XMKYpDKy0TqidJiFrHN6E=; b=CdVuwG1T8DTPbiXLQUmFTmP1t6M4Pv08jed8x6AUzejDz4ku+5TI8D0QKIwA7D8bAX oB/vcCmFgxnWzQTILCZ+8bUvGoW+5p4VXXh+NaiRQS2MVfzKNzyt4UPG6Cikbn/clyQS SFYF0wP0ydDL41S4mfyNmmR3F20GN0FOQJ5166ST5zkcC5imbGppfOeMwDrHP9vaZShr CreACshbjBfpoFpTRbqeNuy5XIunFQYkxvOtdnA4gEDWJN/I6olbCwGmkl2IDM52AqBs TecVnjIiYts+zX3sTcnASakA6nLTjt5a+foyArR2w/ECvSftgcT0f5bRTnEbAIJ/ExEd wUCg== X-Gm-Message-State: AOJu0YyamaKGNts5KRj4ykQEWmPTM4Yi3C64A7lyjVRiemry9WVHOK4u tpU3gboKYGgZTKsvSN9Jvu5mRm3awakajubr10BWUFJkpWTqVGHqnWUu8S2j X-Google-Smtp-Source: AGHT+IHmXOQFlFP2JD1qklEnrK/7gJLwDRNDOqYOWdbSYLHyY7R4DVw8UNKfXH9ALkSsOkndXWRSUA== X-Received: by 2002:a05:6512:3b95:b0:516:a4f1:d01a with SMTP id g21-20020a0565123b9500b00516a4f1d01amr4156878lfv.53.1711957766281; Mon, 01 Apr 2024 00:49:26 -0700 (PDT) Original-Received: from evergrey ([2001:999:504:72c4:dcee:681:4c30:2]) by smtp.gmail.com with ESMTPSA id d12-20020a0565123d0c00b005158d77665asm1368088lfv.30.2024.04.01.00.49.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Apr 2024 00:49:25 -0700 (PDT) In-Reply-To: (Ergus's message of "Sun, 31 Mar 2024 23:07:31 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::12c; envelope-from=djcb.bulk@gmail.com; helo=mail-lf1-x12c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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:317441 Archived-At: On Sunday Mar 31 2024, Ergus wrote: > Hi Dmitry: > > On Sun, Mar 31, 2024 at 05:41:24AM +0300, Dmitry Gutov wrote: >>Hi Ergus, >> >>On 27/03/2024 18:38, Ergus wrote: >> >> I originally suggested a variable that stores a relative file name. But I see >> that you prefer the fetching of this file name to be more dynamic. >> > Yes, that's actually the point. In out of sources compilation there is a > possibility that there will be more than one subdirectory to build, in > that case the user may be asked at least once which one to choose. This > is also valid to detect the `compile-commands.json' which may have > different version in each of the build-dir candidates. > > https://github.com/Ergus/project-multi-mode/blob/c679d73a26b162e4158f6451027ca94e33faca0b/project-multi-mode.el#L109 My 0.02: Having separate build-directories seems to be increasingly common (in my bubble I hardly see anything else anymore) Allowing for _multiple_ build-directories is also quit common/useful. E.g., for doing debug/release builds, or for building for different target hw (embedded dev). For me, a daily need. So having direct support for this in project.el would be quite welcome, so I can use that instead of my private hacks. >>Why don't we just make it a function variable, at least at first? >> > Because I wanted somehow to follow the project.el schema of using a > generic that the backend could optionally define transparently. > > And make that definition independent from the user config variable, so, > the user defined variable takes preference over the generic search > performed by the backend which if not defined automatically goes to > project root. Somehow adding a custom variable I think interferes with > the idea that the backend provides the functionality... But I may be > wrong. > >> Call it 'project-compile-dir`, which would be settable to a string (constant >> value, to be customized through dir-locals), or a function that either accepts >> the current project value, or is simply called "inside project root" (with >> default-directory bound to that value). >> > I will try this again, but I had some issues before. > >> Alternatively, if you see a need to add additional methods >> ('project-compile-command'?), it could become a new hook and a new facility >> (e.g. project-build-functions) which could be structures similarly to >> project.el, i.e. the hook returns a "project builder" value, and the value has >> some methods that it can defined/override. Then different build tool backends >> could be mixed with different project backends more easily. >> > I would prefer avoid more abstraction layers in the api. We actually > need some `project-compile-command' like function, but structuring it > with generics and more layer is IMHO adding too much complexity for a > public api... Isn't there a simpler alternative? > >> So far I only see one additional method, though, and the constructed >> compile-command value is relatively simple. Curious to see whether this will >> get more complex with additional targets. >> > I added one method and with that I already support autotools and cmake. (would be nice to add "meson" too!) No immediate opinions on how to implement this, but things I commonly want in projects: - build - run - test - install - flash - debug - clean It's possible of course to "multiplex" with the compile-command and put in a "transient" or something like that; but it'd be nice to handle this directly across projects; also for adding menu / toolbar commands. Guess this is a bit of an open-ended list, so having `project-*-command` may not to be the best. Kind regards, Dirk. -- Dirk-Jan C. Binnema Helsinki, Finland e:djcb@djcbsoftware.nl w:www.djcbsoftware.nl gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036