From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Project out of sources compilation Date: Sun, 31 Mar 2024 05:41:24 +0300 Message-ID: <1fd527fc-9643-49d2-8fae-d7e7fd043fe1@gutov.dev> References: <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2.ref@pyv2z5snot6h> <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2@pyv2z5snot6h> <87ttl5w0mr.fsf@gmail.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="22230"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 31 04:42: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 1rql9V-0005Zd-Fq for ged-emacs-devel@m.gmane-mx.org; Sun, 31 Mar 2024 04:42:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rql8a-0003Et-Ow; Sat, 30 Mar 2024 22:41:36 -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 1rql8Z-0003Ee-Mg for emacs-devel@gnu.org; Sat, 30 Mar 2024 22:41:35 -0400 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rql8X-00017N-3V for emacs-devel@gnu.org; Sat, 30 Mar 2024 22:41:35 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4D10C5C0059; Sat, 30 Mar 2024 22:41:28 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 30 Mar 2024 22:41:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1711852888; x=1711939288; bh=s+gPMV2Me4VJMjdgQhXTIEx5ZMXOxEhYC6MY7JlO9CU=; b= aClhSMN8PQWzgE0xIBgKOjBGYi4C8+7W4bg3DmTb/murkkwdnOFSe18FJItBwXZq uTFgMKrAVnBq5kCl3wL/2LXb+PSf8h48HVBRrT7YXQwfg+S24I7B1/xlMTbQRZCl pERtb4PZkMjFqoN+9t3eTgX5EkQ8Dby0AjhjHR7BBa9gBqNIwtVS7AUB+PynQDO5 ENzxQ/ylJl3UnSU/HVkO8oBRAtqHxvZAinpvqlnnnots0zkskGh0QaKHMveV88Pa LGbWLFtSbjWJPO4DW/SF11D8fYhKsVxeU6xhNnP2HQ8ZTPy1LtB9MX21dQMNP8Wr irfwb3oFJ0AFalY5360TKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1711852888; x= 1711939288; bh=s+gPMV2Me4VJMjdgQhXTIEx5ZMXOxEhYC6MY7JlO9CU=; b=C Ra8aj/rfz7W6GkmYPCPPvyn+Hhm2E7+7e1MiJHcbonkG5PYhR5PBslJfC2zpuyB6 5DvoZjs1CdTFJuLolPvrb/vGVLiwIhvBODLHqJyfXJgD61YwrffUHTPaLjPg5o6A tg2D3pYaI596FDb+uNZNaVQ/hb5wVf2oRK0Dlor/l4kU6I5wcMpOs3JBT3nNvt6w 6tLbrOTjc0hgU9nWVhpDyslQWFE606CDD+/W/FusfDsysP8OKF+zMI2V8fmYo1TO YZLtRxODm+2N06X04buniUNBHblo7rnHkornAH/+j6KwsgwWcTkp+bhC0CzkLXIw drz62+GcvwjKbOORrAMvA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddviedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfevfhfhjggtgfesth ekredttddvjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehg uhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpeefvdejveeiffefueekleevieekge dttdevieelvefgvdfghfdtgfegfeefgeeigfenucffohhmrghinhepghhithhhuhgsrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 30 Mar 2024 22:41:26 -0400 (EDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.29; envelope-from=dmitry@gutov.dev; helo=out5-smtp.messagingengine.com X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1 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:317404 Archived-At: Hi Ergus, On 27/03/2024 18:38, Ergus wrote: > Here I attach a very simple patch to allow project out of sources > compilation and project build detection. > > So far I already implemented a very primitive backend [1] for project.el > using these features to detect and compile autotools and cmake projects; > and, at some point I will propose it for elpa. > > But I need to work a bit more on it; and, of course, the functionalities > in the attached patch need to go to vanilla this way or some other > equivalent. 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. Why don't we just make it a function variable, at least at first? 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). 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. 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. As far as the redefinition of 'project-name' goes, perhaps we'll allow project-vc-name to be a function as well? Or decide on some other way to assign a build tool the name to a project. > Best, > Ergus > > [1] > https://github.com/Ergus/project-multi-mode/blob/master/project-multi-mode.el > > > > On Tue, Mar 19, 2024 at 07:36:35PM +0100, Ergus wrote: >> Hi Dmitry: >> >> Here I attach a very simple approach to add support for out of sources >> compilation in project.el >> >> This is just a POC, but to have some starting point to discuss. >> >> Best, >> Ergus >> >> >> >> On Sun, Mar 17, 2024 at 06:47:43PM +0100, Ergus wrote: >>> On Sun, Mar 17, 2024 at 12:36:44PM +0100, Augusto Stoffel wrote: >>>> On Sat, 16 Mar 2024 at 14:12, Ergus wrote: >>>> >>>>> 5. Project local variables (a man can dream, a man can dream) >>>>> >>>>> There are some situations where we want to have variables shared >>>>> among a >>>>> project. (i.e some output directory, logging option when executing, >>>>> flags, environment variables). >>>>> >>>>> At the moment these options work partially by using directory >>>>> variables. If we have the concept of a "project", maybe it is >>>>> logical to >>>>> have some sort of project scope concept, specially for projects >>>>> sharing >>>>> a common root. >>>> >>>> For Emacs variables, why you think dir-local variables only works >>>> “partially”? >>>> >>>> As to environment variables, they are generally assumed to be global in >>>> Emacs and it goes a bit against the grain to make them buffer-local / >>>> project dependent.  Nonetheless, there are packages for that (one is >>>> buffer-env, which I wrote) and they work fine (at least for me). >>>> >>> They work for one directory, but when the project includes multiple >>> roots (project-external-roots) the variables are somehow missing just >>> when jumping with xref to a definition. >>> >>> However, we can ignore this as I mentioned before. >>> >>>>> For example vs-code adds a subdirectory with project variables that >>>>> the >>>>> user (but also any plugin) can refer to in the project's scope. >>>> >>>> Is this meant to store editor configuration or environment >>>> variables?  I >>>> guess turning VSCode configuration variables into Emacs alternatives >>>> would be tricky. >>> >>> No please. No interaction-importing from other editors will be >>> maintainable in the long path. >>> >>>> But if this is about env vars and the directory >>>> organization is sensible, then one could configure buffer-env to >>>> interoperate. >>> >>> This is it. The idea is to extend project.el in order to bring more >>> project-oriented features. >>> >>> Lets say: >>> >>> The user (or project.el backend) could specify the `build` directory and >>> the environment that needs to be set to execute the program from the >>> build or bin directory. >>> >>> So with a simple modification of dir-locals.el the user may be capable >>> to run M-x compile (or project-compile), M-x gud-gdb... or being more >>> ambitious M-x project-generate (to call autogen.sh and ./configure or >>> cmake depending of the project-backend) >>> >>> For sure we wont cover the 100% of the projects, but wuth automake and >>> autotools we will be very close (and in the future someone could add >>> other backends for it) >>> >>> >>> >>> >>> > >> commit cfa10dfeac01ae25a7acd6857fae0b377b625779 >> Author: Jimmy Aguilar Mena >> Date:   Tue Mar 19 17:57:25 2024 +0100 >> >>    Add basic project-build-dir implementation >> >>    This is just a dummy prototype to discuss about alternatives. >> >> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >> index ac18aceadcf..0ca4ca85566 100644 >> --- a/lisp/progmodes/project.el >> +++ b/lisp/progmodes/project.el >> @@ -51,6 +51,9 @@ >> ;; files inside the root must not be considered a part of it).  It >> ;; should be consistent with `project-files'. >> ;; >> +;; `project-build-dir' can be overridden if the project backend has some >> +;; extra information about the project build directory. >> +;; >> ;; This list can change in future versions. >> ;; >> ;; Transient project: >> @@ -208,6 +211,12 @@ project-prompter >>   :group 'project >>   :version "30.1") >> >> +(defcustom project-build-dir nil >> +  "Build directory for current project." >> +  :type 'directory >> +  :safe t >> +  :version "30.1") >> + >> ;;;###autoload >> (defun project-current (&optional maybe-prompt directory) >>   "Return the project instance in DIRECTORY, defaulting to >> `default-directory'. >> @@ -289,8 +298,30 @@ project-external-roots >> headers search path, load path, class path, and so on." >>   nil) >> >> +(cl-defgeneric project-build-dir (_project) >> +  "Return build directory of the current PROJECT. >> + >> +This function is intended to be defined by the backend when possible. >> +Otherwise this returns nil and the `project-compile' command will be >> +called in the project-root. >> +If the user defines the directory-local variable `project-build-dir' it >> +will have precedence over the result of this function." >> + nil) >> + >> +(defun project-get-build-dir (project) >> +  "Return build directory of the current PROJECT. >> +If the variable `project-build-dir' is defined, this function returns >> +it, otherwise it returns the project root.  If the defined path is >> +relative, this expands it relatively to the project's root" >> +  (let ((dir (or project-build-dir >> +                 (project-build-dir project) >> +                 (project-root project)))) ;; I assume project-root >> is absolute >> +    (if (file-name-absolute-p dir) >> +        dir >> +      (expand-file-name dir (project-root project))))) >> + >> (cl-defgeneric project-name (project) >> -  "A human-readable name for the project. >> +  "A human-readable name for the PROJECT. >> Nominally unique, but not enforced." >>   (file-name-nondirectory (directory-file-name (project-root project)))) >> >> @@ -1391,7 +1422,7 @@ project-compile >>   "Run `compile' in the project root." >>   (declare (interactive-only compile)) >>   (interactive) >> -  (let ((default-directory (project-root (project-current t))) >> +  (let ((default-directory (project-get-build-dir (project-current t))) >>         (compilation-buffer-name-function >>          (or project-compilation-buffer-name-function >>              compilation-buffer-name-function))) >