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: Project out of sources compilation Date: Sun, 17 Mar 2024 04:53:42 +0200 Message-ID: <5e04b699-6a0a-45ef-92cc-2115b58a869e@gutov.dev> References: <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2.ref@pyv2z5snot6h> <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2@pyv2z5snot6h> 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="6635"; 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 17 03:54:36 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 1rlgfU-0001WM-0U for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Mar 2024 03:54:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rlgen-0005Gz-MG; Sat, 16 Mar 2024 22:53:53 -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 1rlgek-0005Gn-Fx for emacs-devel@gnu.org; Sat, 16 Mar 2024 22:53:50 -0400 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rlgei-0003bn-I7 for emacs-devel@gnu.org; Sat, 16 Mar 2024 22:53:50 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 81C8432002E8; Sat, 16 Mar 2024 22:53:45 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 16 Mar 2024 22:53:45 -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=fm3; t=1710644025; x=1710730425; bh=Z6lQJKKyuWwnkHcWnlWaRbQahee0JtpcxCt754Dv50U=; b= g4B4hRoOzIDN9FjEI7+wuzwdTsGBxQ+4J9yoIvklvKlxGGpsI5ywA4KyL+BtYkPg sSnvXk2SHEhichAmZ3d/jDnSRMbwx3hbU6SnBsYdFCC+WjnQLOi039eZOu3yl45P CMVIksSDrO+KzkgvIqJT0VIJP7VXnHBWh+VO/ivL4JwwcrXzeeS61P9KgwV04b2w ObvakjRWvYg8KoDTdtcerHuk/em+6D8lmGbzGiZLYdRBhq879U8zfRHubPwxA3Da YozuFm0OA2DBohVxcMS+asEfU5MolWmqx3fYkDHQccTaNfY8YICSr1i9cRMBoJoF 2c1wIh7z8ZDOlEe7Ps/vSg== 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=fm1; t=1710644025; x= 1710730425; bh=Z6lQJKKyuWwnkHcWnlWaRbQahee0JtpcxCt754Dv50U=; b=n 7GIpXFX7Ofm+hLmHSrjRO+0WXazZbeMsSuqeMOSDsB3LhuuJW5uajL0id8yheARa lFKA4zGBkliwbfQpBLpLge0v30tkfY6QnyIpT3EjpHDYQymkpVvT2/G+ln84u+7+ w4ZvHINJbsmIUQcPAvCmuYvyNGMq8Q/WLuR5H+lSh6TniQij4yFs2PDNMNMlgBGH 8rkleUWOhkxewwCXe3hN59rdxew2e9jAnar6iorLyy0GedazrzG43k+VjEnQC0xe AKPBfNMxj5ZdOUWHHBTPSB2ZSJMqm+kmp8WcMQ/IdIPN0JgC2NHmbubN+5m6AFqd a7QFwvkx6DktTf8af3b4g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrkeefgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtke ertddtvdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhu thhovhdruggvvheqnecuggftrfgrthhtvghrnhepueetudfhiedtjeekuefffeehgfffve evteejtdfhteetgeethfevueejkeejgfevnecuffhomhgrihhnpehgnhhurdhorhhgnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrh ihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 16 Mar 2024 22:53:44 -0400 (EDT) Content-Language: en-US In-Reply-To: <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2@pyv2z5snot6h> Received-SPF: pass client-ip=64.147.123.20; envelope-from=dmitry@gutov.dev; helo=wout4-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, T_SCC_BODY_TEXT_LINE=-0.01 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:317129 Archived-At: Hi! On 16/03/2024 15:12, Ergus wrote: > These days I have been working with cmake projects here and there and in > spite of I could handle most of the work from emacs, it required a lot > of extra time to make it more or less comfortable. > > I wrote a couple of simple functions to manage my needs, but at the end > I think that there are some small piece missing to handle common > workflows and glue everything (with the users in mind of course): > > 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? > 2. Eglot compilations database place. > > When compilation is out of sources the cmake generated > compile_commands.json also goes in that directory by default. > > This issue can be managed with a line in dir-locals, or just manually > coping the database. > > ((eglot-workspace-configuration >       . (:clangd (:initializationOptions (:compilationDatabasePath >       "build"))))) > > Probably some simple slight integration of Eglot with Project may help. That seems like it can be a Eglot user option. Again, just storing a file name relative to the project root? >   2.1 This mixes with the previous one because if we change the >   compilation directory the line with initializationOptions is not >   updated and requires manual intervention > > 3. Projects multiple backends > > This one is tricky because at the moment I have gtags-mode, that > includes a backend for project.el, there is the default backend, but > also we could add something called cmake-backend (i.e looks for > CMakeLists.txt that includes a 'project' entry) > > In that case emacs cannot use all the information form the three even if > it is not contradictory, so the user ends up opening the terminal and > doing things manually. Indeed, project.el doesn't "merge" backends. Is there an obvious algorithm for merging backends which would be understandable to an average user? If the only thing you wanted combined is the root detection, I suggest reusing the variable project-vc-extra-root-markers, automatically or manually (just have the user set it). If its data structure is now powerful enough, it can be updated. For example, if the logic both looks for CMakeLists.txt and checks its contents, project-vc-extra-root-markers could support cons entries like (MARKER . CHECK-FN). > 4. Flymake integration > > Even without eglot, flymake should be capable to work very easily with > cmake projects. > > This step is also a stage before doing a proper plugin integration of > tools like cppcheck for flymake. Is there something particular that is required? > 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 example vs-code adds a subdirectory with project variables that the > user (but also any plugin) can refer to in the project's scope. Does such subdirectory in VS Code affect the project residing its its parent directory, or some other projects as well? Your description above sounds more like our .dir-locals.el. And the directory locals facility in Emacs also has the less well-known capability called "directory class", see the bottom of https://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html. I think it should work okay for sharing variables between projects. Perhaps it's less user-friendly than one had hoped, I don't know. Some improvements for related UIs would be welcome. Just creating a parallel built-in way to set variables inside directories but for projects sounds a bit much. Also, we don't always detect a buffer's project before the user asks for it. So I'm not sure what hooks could be added, even if we wanted. > I could try to implement some of this with your help; but I need some > feedback on which of them are desired and which are not. Or which ones > are maybe better to put as feature requests for a more skilled lisper or > package maintainer. Patches are welcome, but see above. Cheers, Dmitry.