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: Wed, 3 Apr 2024 21:47:10 +0200 Message-ID: References: <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2@pyv2z5snot6h> <87ttl5w0mr.fsf@gmail.com> <1fd527fc-9643-49d2-8fae-d7e7fd043fe1@gutov.dev> <87le5x34l6.fsf@gmail.com> <27rton4k4r6sacysluk7iikj57ai2tyiak4ldd5nzpts7thmhg@nriej75catir> <09a8189d-07e3-4bc5-a4f4-127dcdcec2d1@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16372"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Dirk-Jan C. Binnema" , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 03 21:48:21 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 1rs6ar-00043g-F4 for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Apr 2024 21:48:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rs6a2-0004qE-LK; Wed, 03 Apr 2024 15:47:31 -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 1rs6Zw-0004oM-Sl for emacs-devel@gnu.org; Wed, 03 Apr 2024 15:47:25 -0400 Original-Received: from sonic303-3.consmr.mail.bf2.yahoo.com ([74.6.131.42]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rs6Zs-0000n2-0B for emacs-devel@gnu.org; Wed, 03 Apr 2024 15:47:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1712173636; bh=cehZlNIcOtgqfnLC/AIQb0BkPaj2br9KgFFaN6V6v4Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=Fakv7B9JATo9dn2YFEtKtXDi7Ixvay6UfXg6J8JkCr5UeFwPAzp1f7GOjTYeJGef2Fa85rz6iiOBxVrC9gyjyDB8gaEY1LcUZuwtt4lk582hePkfJuuMV2UU9ydCE/vTF2ufFgrUQ6UGmp4JdUpB4awIm7voPAmO0OAIav90245vTIPITRIYN8OW1Ft7EBvGroe/nRfSgk+VcRPOjZMprZQnGmCfzg9FmzIwsqyWYumbs+QcpybsiLvBkop4jkBQJddMyED2TztLezdwLiixlYUo0UItQj1IK1F/DlDdpK3bYkZiVVVyaCcAVbRc4vODBXlKVpRH4Clf/eeK6AeEUg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1712173636; bh=fyhwNTteUjWB3TYHiaytFaGGEwkQx9BJY0SWgqWSlQN=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=ROfpRZqrpNEP4j3haF6jFzM3GOncBYvN45z4Ccc8nHmz+C6c57L9vkBDYmoXVUfq599KLjcAhXEbKvgdjuWrahBtBUFkccIkPvmhY/bloCUFdQr0xuiTLbXXz89t+pqSry1ChrgYM08xnqvscNdir4oy0uvdDphE+eL7GZHxypwMJbUFa2W9885sLsx13CRrHqedpY0g1/XPoi2c05hqMXD5Uu7Q30+DpXy6Vv/5boWDGDFuW986YlTOqU29odVzqDuyYH/S0cW6+mgmDLwpnEf6sh7Bf03oB6TdsHu6CcJcd/YZUpviLGNqurEfNSW6BNweh6hzLkP5Kmuub6oSPQ== X-YMail-OSG: c7nlKo8VM1mBKROOjnlqOJLt2EUx6Y5csggC20Hby8pgcpde7ATIbPetj9vDmF2 Gol24CRQ79FbR1iPZBHfGls.6cp24vxme7a3BfNtZk7ehUricgqFOXaX.3WxdMxNU5UfsGEePm1q VhPArG7cy8wtM9Jz2wnYgslFzd2zsmXf6sPXE0loW5NiPlCszzOIDhngvdYgnsYYJj7dMSPHpX1g fDmdxeehHtL_Xq_6EHVsDHuEpRZLpenoIJsw9LJ2EideZfGw2B2964NMXK7vLxqDjY7UZWwiKWiT VQ0BsBD5c0SF873iWIK4V1wS6f9S5fDVR4T3ajyqhe0Yv_EKvAKXVy.xFl0R.9kk0fumU.pZp42f 9dz3093kOSkvIujLvPT463AxuaVSrtpdB1w3sqX5KOsceAGtDFX2bzLCn_0e3tBzVFSd3w4sVcpz aXh.wRvqipr.gSFJX0OaQYCUFVfyaUeUY9eUUk8uuN43nM9soM5hbHEF.RLKXiTdEOydEQj_ECZh N00CSBSwNoIoYc8BuAsQAyzc.eWLa_5A.mGQfxJjXdemd0FhLRv9XzTRPsKSuFe6X3gr767peeC_ lrA2LKpI9gHcu2lP99q7I4X6I8_kKzgOvNRZb9iACAqAhQrRidFHiKvBerJwtul5BRfr4FDafZ0X radzV91Hj2yrfrc2ZI5_4gQLLzCZ_Xu2bW_fm0_FlM9ynBEh4HRjRFx4rgFl62qJHdDy2dFSKtFH AMMgCD5z2WD8X1sTKnZCUpGdkvpOtWoB1kGWPe50BsTUsNM.FOMvAoxdCDKQaz0srUu1OL5JkE02 eBt8_IaiMD5HbekWrYEO0iz_2Sb1WFpTRbgddv4uLM X-Sonic-MF: X-Sonic-ID: 520a2368-ec1a-4d3b-b29f-4c367685fb63 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Wed, 3 Apr 2024 19:47:16 +0000 Original-Received: by hermes--production-ir2-7bc88bfc75-h6nxx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4d994e3c63ccd47929b6bce32bc74742; Wed, 03 Apr 2024 19:47:12 +0000 (UTC) Content-Disposition: inline In-Reply-To: <09a8189d-07e3-4bc5-a4f4-127dcdcec2d1@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.42; envelope-from=spacibba@aol.com; helo=sonic303-3.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:317502 Archived-At: Hi Dmitry: So far I Think I understood part of your las email about functionality. On Wed, Apr 03, 2024 at 02:23:03AM +0300, Dmitry Gutov wrote: >On 01/04/2024 16:52, Ergus wrote: >>>So having direct support for this in project.el would be quite welcome, >>>so I can use that instead of my private hacks. >>> >>Projectile already have support for many backends and the implementation >>is pretty clean. I am doing this because I thing that something so basic >>must be part of vanilla. > >Speaking of Projectile, it has this block of definitions of "project >types". Which could maybe better called "build tool types" in the >context of this discussion. > >It would be nice if we could port them over to a design which would be >useable by both Projectile and project.el (and together with other >project.el backends), rather than having every project backend >re-implement these settings, or re-enumerate the supported types. > Their design is actually fine, but I would prefer to keep things simpler in the api side because project is intended to be more general. Their use case adds too many functions in order to register, call, test and generate the different backends I thing it is actually too much for vanilla. If we want that complexity maybe is better to retake the last year discussion you mentioned before: https://lists.gnu.org/archive/html/emacs-devel/2023-05/msg00509.html But adding that will require also parallel work and code in order to integrate with project.el. >That's why the idea of orthogonal APIs seems appealing to me (the >current one for file listing and root finding; the new one for build >tools, and compiling, and running, I guess). > I would probably insist in a simpler basic feature still in the current project.el. I can't see the features as a separated thing. What I would probably propose here is (maybe) to move the vc-backend to it's own file as a separated package in order to keep the general api separated from the "plugin". So if a developer wants to create a backend it is clear whats needed and what the standard implementation example... >Until we've drawn up some design for the latter, though, maybe a >customizable function variable will suffice. > What I have in mind as now is to add a variable and a method that can be both optionally defined. The method defined by backends and the variable by the user (maybe in dir-locals). This way the backends won't be forced to define any of these if compilation is not supported (i.e vs-backend) or if the project is for a non-compilable languaje (i.e an hypothetic python project) project-compile-info accepts a second variable that in this case expects 'dir or 'compile-cmd in any case when not implemented the function gives null and the caller (compile in this case) falls back to the default values. This can accept any other command like 'generate-cmd 'test-cmd and so on. In the future we can define any other random command relying on these So far the only we need for compilation is more or less this: ``` diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index a10e24f3e28..9d77d5452f3 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -290,8 +290,29 @@ project-external-roots headers search path, load path, class path, and so on." nil) +(cl-defgeneric project-compile-info (_project _info) + "Return build information 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 use +the default values. +The current valid values for INFO are `dir' and `compile-cmd'" + nil) + +(defun project-get-build-dir (project) + "Return absolute build directory for the current PROJECT. +1. Tries the generic function `project-compile-info' with info='dir. +2. else it return the project-root. +If the defined path is relative, this expands it relatively to the +project's root." + (let ((dir (or (project-compile-info project 'dir) ;; backend function + (project-root project)))) ;; I assume project-root is always absolute + (if (file-name-absolute-p dir) + dir + (expand-file-name dir (project-root project))))) @@ -1392,10 +1413,15 @@ project-compile "Run `compile' in the project root." (declare (interactive-only compile)) (interactive) - (let ((default-directory (project-root (project-current t))) - (compilation-buffer-name-function - (or project-compilation-buffer-name-function - compilation-buffer-name-function))) + ;; I am wondering whenever we need to expand connection local + ;; variables at this point... maybe before or inside the let. + (let* ((project (project-current t)) + (default-directory (project-get-build-dir project)) + (compile-command (or (project-compile-info project 'compile-cmd) + compile-command)) + (compilation-buffer-name-function + (or project-compilation-buffer-name-function + compilation-buffer-name-function))) (call-interactively #'compile))) ``` Finally the only missing detail is user side configuration... I was thinking in a plist defconst (similar to the approach in eglot-workspace-configuration) so the user can set it completelly or partially and we only need to do: (or (plist-get project-info-plist 'compile-cmd) (project-compile-info project 'compile-cmd) compile-command) In this way the user only has one variable to set in the config with all the parameters optional as well which stays easy, simple in implementation and with a predictable behavior. WDYT?? Best, Ergus