From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Project out of sources compilation Date: Sun, 31 Mar 2024 23:07:31 +0200 Message-ID: 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; 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="4107"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 31 23:08:44 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 1rr2Q0-0000sV-Gc for ged-emacs-devel@m.gmane-mx.org; Sun, 31 Mar 2024 23:08:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rr2P2-0006co-Je; Sun, 31 Mar 2024 17:07:44 -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 1rr2P1-0006cW-4j for emacs-devel@gnu.org; Sun, 31 Mar 2024 17:07:43 -0400 Original-Received: from sonic311-14.consmr.mail.bf2.yahoo.com ([74.6.131.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rr2Ox-0003RR-4W for emacs-devel@gnu.org; Sun, 31 Mar 2024 17:07:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1711919256; bh=stTTV34F2005IpXnDo/29Z2Qj7vytyb8dMpgbZVuHHY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=JxlPc4k1Gkwfyf6BUjxgx37j+myY+Tqxdtu16DOvl9VpRU6RexxrVZ5TxVc3eUrbDpnEENrXkiPHpDCqpMM9CvoUS+TU6noYBpYVkDs7wqtTyGRkBpUDLkg6auOtB5SKSLYCtxBJqrhQloYxhch+fzSLVe0CO0QGkF01gDyA+nelK/5DIlz1JkoB74HN/QU2xpLqQMIxfvxaysgXTTSN+e5z+GeUjWemTvMiH+2WmzYfDveFSLwQCDBO+vmE9/28uKmtB5CE03Nvx/gDcSRlCEciIyRh1lmZp5I/PyCjXnLBy/J55ErR9MMSmJGoOiFwXBIHPlWgw7lL/gpDbeR0OA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1711919256; bh=PVBALtYkYAN4XT5xJXDnwarviWmhPLIQu6p/pVpMG7Q=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Z89Npgm2dIX5Utj9vaq6WWHSbVX0MpLe7c6STU2Ja5lN+7G/bGLeC0xxgvQie5dDfYYEtboQra81/1ruzU6aQg3nfIO9UfaDrnFTCYdlmJ6g+/BKYGJvGL6mk2jWqz+qMeu8xwbo8nE/v0g+ZBPWv1GsTCpyS0Shxzx7/pq4r+vZZxAYOiiHfUvHM61Pumkk/uVkbO1R+95q+LePds0yiTIsVPGBn3JEjAXn52ezRA4/cQVhFlzQbJs/1pU8zkFar9pz0NhyF26hNVQ3bkAC40JUz4XcSjYHUZKEFwQyBHiHbpVGk7KYyPNvBwfSF2FxhVWTxx8lQUf1z6cjqUPnhw== X-YMail-OSG: ZuQwU88VM1l6EVc_ZwD37WNbteMvOLxpEBikg5iQqYalV.6EWkJC1PiYCZ2ddGY 1Xc4E_aRDWqTwfAOXSv_YLy7EyRrVPA92lI_0NoHhGZeKzNk4FMUAF9lhRb6UbCcMQJTbSJc.A1A ef0.1yA7Yq54Vu2ExPoNUHC_jFEnns0LdArk0_eDC_CNqa1EJ_F1VzN2JhKIFePt25PYdtIBF9Z9 Y27_GEEz.R0VADMatQ8GknsQJeWuyyzCkU0bMF8XAFO53PwHmqxJhQ.s5bsU_I097lCVcq8JYn3S rp59OL4aETbkmZRmchNUxyZfSWnJ40yxG5YMoYZO7ewkCFqcv9mVilmTNBYIisMqjQhuxoDX0fi5 8XYNfX1Tmm0DSZ8wu4jUW5Pxm__8E1PWVew1pHMi1ojlK3StFMMg.2dl56cC6RSmYsmRYOVi1VYG rSMsXvkqHttmWg_6HXMOGjniA4v7daX8BtViY6w0ggUYHvNgU9yr3Cr0cRtO7e9u77Co3B6_INLD 0nzl.hwKoFuHC5UdXlODv42Tw6b5AvLhn_GumnRKZB_c.HxDSJvtP6YbgzxIeLoXJHWPd75MKA9B gUn6NsDfhqfu1bIdjLRUUOwuGfuXrCZrlxX_OGshkchjiPgZtNwOd5mL3nDV5fbEodBKX_qM9KGT sURWs61hjHS.NQB4z27ZeNvQXAg1aFnpFkL2Qvny8EedzhjS4mJksEmnixRdCd0EJTQIx3O0TUo7 qL8fdEU1Lagg6l9dZKwDSva_PBdgkmwTLdhfQ5HQn.AHAtiTylI6D9d8hNd6AKRw2nwNabIIIoad to.ONC2yIISCjB7dGcf23Yjn7be1nbV_.eq4dcsuH8 X-Sonic-MF: X-Sonic-ID: e85b80ed-f9a4-448d-9e62-517c3611b4a9 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Sun, 31 Mar 2024 21:07:36 +0000 Original-Received: by hermes--production-ir2-7bc88bfc75-bwvz5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a60eff5343ca4ed7b696c5581388d9f5; Sun, 31 Mar 2024 21:07:32 +0000 (UTC) Content-Disposition: inline In-Reply-To: <1fd527fc-9643-49d2-8fae-d7e7fd043fe1@gutov.dev> X-Mailer: WebService/1.1.22205 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.131.124; envelope-from=spacibba@aol.com; helo=sonic311-14.consmr.mail.bf2.yahoo.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, RCVD_IN_MSPIKE_H2=-0.001, 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:317434 Archived-At: 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: > >>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. > 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 >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. >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. > In project-name I actually only changed the docstring, I didn't change anything else. >>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))) >> > >