From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Project out of sources compilation Date: Sun, 17 Mar 2024 10:45:29 +0200 Message-ID: <865xxl5jrq.fsf@gnu.org> References: <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2.ref@pyv2z5snot6h> <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2@pyv2z5snot6h> <5e04b699-6a0a-45ef-92cc-2115b58a869e@gutov.dev> <9098131B-AFBE-4978-B679-4C1D5507F55E@aol.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3444"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Ergus , dmitry@gutov.dev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 17 09:46:28 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 1rlm9y-0000fx-So for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Mar 2024 09:46:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rlm9E-0000jW-CE; Sun, 17 Mar 2024 04:45:40 -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 1rlm96-0000j6-P9 for emacs-devel@gnu.org; Sun, 17 Mar 2024 04:45:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rlm96-0000qJ-AL; Sun, 17 Mar 2024 04:45:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=nOuTlaX3pdNo/Q/9E4DiDZLZsJK1obzbUSvTApE/Y28=; b=Qb5dWTWc6K4m yFuXO+RdPBYTPdDWr5+8ZWTUZvSPgdtA3Vw1OtIinJu/1xWY3Kv2JOX1/WOX+KCockYv9rKm2Imj9 vVH9gngxMI17009Y/FjY8ZHsRNzZVV3x2ofOxxmDaFxxgn+9ho12kIvp6Fb6N1UBLr8grBdMNZYtG CI7qyrKrdXF2UEpR15GEPqof96uXDg8InETuy7SVPx+YkLZyyc6sjz/P0OvTR5ktGzU7tDqUlCoWZ HJ0AQRrJCddQTWMGdoPzKWYFqUZ+Dx9xkxTxRODiqhYZjQKxpxakvF301w3DCDxwBU0isctxO3YzG IPjk1BFf2V+t8tYH2t6FEQ==; In-Reply-To: <9098131B-AFBE-4978-B679-4C1D5507F55E@aol.com> (message from Ergus on Sun, 17 Mar 2024 08:22:56 +0100) 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:317135 Archived-At: > Date: Sun, 17 Mar 2024 08:22:56 +0100 > From: Ergus > > >> 1. Out of sources compilation. > >> > >> Most of projects now prefer to do out-of sources compilation. Either to > >> keep source code clean or to keep multiple compilations at the same time > >> (i.e Debug/Release/win32) > >> > >> The project.el package has already some compilation commands, but they > >> assume that the compilation will be executed in the project's > >> root... which is not true most of the time. > >> > >> Maybe we may add an extra custom variable that could be specified in the > >> dir-locals.el in order specify where the compilation command must be > >> executed. > >> > >> Some more heuristics here is possible, but I would settle for at least > >> something simpler. > > > >project.el has just one, very simple command, where the only thing that it does it switch to the root first. How will you customize it? With a hook, where the user would write a function "determine a directory for compilation"? They might as well define a new command - or redefine this one. Or just an option with relative directory name? > > > > IMO the only thing we need is probably a variable/custom like project-build-dir. The user can define it in the dir-locals and the project command will use it if defined/ else use project-root. Maybe the backend could initialize it. > > Alternatively (and not totally exclusive) project.el could define a project-build-dir function that project backends could optionally redefine (i.e I use a plist as project id in gags-mode and getting any stored property from there is very easy with a command). By default it will be an alias for project-root in the VC backend. Maybe I'm missing something, but isn't the build tree just one more tree that is part of the project? If so, can't you use project-external-roots to add this tree to the project? I thought this was the mechanism to add trees to a project as included in the original design of project.el and its support in Emacs? > There is also some need for a 'bin' dir, that is, where the final executable will reside, useful to execute and debug with tools like gud and independent from 'build'... For example in a python project this may be the project root OR where the file with __main__ resides, but a python project usually won't specify a build dir. But let's go for one thing at a time. Likewise here. Or what am I missing?