From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mohsin Kaleem Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Project out of sources compilation Date: Tue, 23 Apr 2024 20:26:59 +0100 Message-ID: <87mspjx4l8.fsf@kisara.moe> References: <1fd527fc-9643-49d2-8fae-d7e7fd043fe1@gutov.dev> <87le5x34l6.fsf@gmail.com> <27rton4k4r6sacysluk7iikj57ai2tyiak4ldd5nzpts7thmhg@nriej75catir> <09a8189d-07e3-4bc5-a4f4-127dcdcec2d1@gutov.dev> <2bpiuffyzhqvirscyn5prs4rb6m5ito7xnwqvc53obm32isp3g@w73yut5uku4y> <87il09hz6n.fsf@kisara.moe> <4e5bg4tmzu3pl334wiw5fei5s5uxbqnnoio3avqou5sde3dodk@3bewafrmdzus> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3583"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 24 06:59:50 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 1rzUjV-0000ko-Kl for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Apr 2024 06:59:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzUis-0007YW-KU; Wed, 24 Apr 2024 00:59:10 -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 1rzLnO-0004Ah-AQ for emacs-devel@gnu.org; Tue, 23 Apr 2024 15:27:14 -0400 Original-Received: from 119.ip-51-38-65.eu ([51.38.65.119] helo=mail.kisara.moe) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rzLnM-0006qV-71 for emacs-devel@gnu.org; Tue, 23 Apr 2024 15:27:14 -0400 Original-Received: from mk-desktop (bcde7b88.skybroadband.com [188.222.123.136]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mail.kisara.moe (Postfix) with ESMTPSA id F1950A2796; Tue, 23 Apr 2024 21:27:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kisara.moe; s=default; t=1713900428; bh=MQwakvI94C8BGPisIZD1Yp3Pb+25bcpnIxAgSRgNWqg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZGHGSfNLubUO0/ErGTDBYLSca97lU9Aj23wlCh/NyhAsSc2/xSBf5faZui1FRXbd4 sKpnnkjoJ2IiR40HiUXnZLBYSXq7La81D1Ra2yte0utUf7f/Pk26nSiF/kGrWne4rw cSJck9dhvXZr9Dfue99d47oVRqqRNGq7BK15HxYe1a9NPhU+P5SRXE1bOiRfcN3oak swnwKDdzx7fBjhreRAdxSq4AUV39+DmW9qEeVL8loUg6m1gfa1lMlu9VzqWEFndNtY MpdvczG0gbMGulY0gEpr7kO6Rq5u+Py9G8aZQqhHvoDaBLKSupwe/EmXyJeQQ0Hvyj tYplQVMAxGuZA== In-Reply-To: <4e5bg4tmzu3pl334wiw5fei5s5uxbqnnoio3avqou5sde3dodk@3bewafrmdzus> Received-SPF: pass client-ip=51.38.65.119; envelope-from=mohkale@kisara.moe; helo=mail.kisara.moe X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 24 Apr 2024 00:59:10 -0400 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:318016 Archived-At: Ergus writes: > I'll give it a look. I am aware of cmake presets, but we don't even > support cmake or out of sources compilation yet, so I tink that > supporting the most basic cmake setup will be already a step forward. We being the projects you work on? My suggestion was more for automating how you set build configurations. Supporting that in Emacs is separate but still useful. It's just which directory you configure to and build in is yet another part of this instead of some custom thing only Emacs understands. > Yes, that's actually the current approach in my POC code. after some > fight with rust projects. However, the difference on moving or not is so > simple that it doesn't even represent a difficulty. Just moving is easy, but a interface for that that isn't confusing would probably be a lot harder. For example you can switch to a compilation buffer and run cd and recompile and that should work. But it's much easier to just see the command containing the non-common directory it needs to run in. > This implies removing many of the features project.el already has > (project-compile, project-eshell, project-compile-buffer-name-function) > + somehow create another level of abstraction over project.el... I think we probably should. There's a lot of builtin Emacs functionality which is just duplicating standard things in subtly different ways. project-other-{window,tab}* for example. Embark at least supercedes this IMO because it generalises the selection backend from the end user action. In this case project-compile, project-eshell, etc. If this was being done today I'd probably just define a 'project-run-from-root' helper and let the end users alias it to a command if they think its useful. Like so: (defalias 'project-compile! (project-run-from-root #'compile)) But I digress. > The initial basic commands (config, build, test/run) seems to be common, > even in python projects it usually needs to get dependencies, create > virtualenvs and so on. However if a project does not support a build > command a simple message can solve it easily. I agree, but my point was this doesn't really align with anything else project.el does atm. Listing files for a project is orthoganal to which "configure command" makes sense for whatever kind of project this looks like. And necessarily multiple configure commands may make sense at once. > FWIK every directory may have a CMakeLists.txt, but they need to have a > project() entry to be considered a project's CMake. The search is > actually unavoidable and the regex check actually solves the race > conditions. > > I know that the search is not efficient, but with a couple of > optimizations if works very well even with tramp. This aligns with what I know but also that a encompassing CMake with a project can depend on a sub-directories CMake with a project. So if you just configure and build the parent project it'll configure and build all sub-projects. I'm not sure when you'd not want to do this, if the projects have overlapping targets perhaps... but at that point you should probably just move them to independent projects because their already that. > Nested projects is something very common these days and supporting them > in project.el is part of another parallel discussion going on already > (very slowly btw). I have yet to encounter any so I'll assume you're right :-). > More or less the same idea; I use with plist. I think they a bit > simpler, but the same underground. I tend to avoid eioio because I have > heard some performance complains (don't know if they are justified) but > also because plists are somehow more flexible in some aspects. I haven't noticed any performance issues at least in my limited usage of them. > Actually I am not trying to do anything so fancy. We cannot go from 0 to > 100 in a single pass. If we start 1. recognizing projects backends and > giving a better compile-command for them in the right place and to the > right build-dir is a good step forward compared to what we have. Then we > talk about test and finally we can consider the generate one. You should probably keep in mind sometimes there's a feed forward mechanism in these things. CMake for example requires you to setup a file prior to configuring if you want to introspect about the build configuration and available targets. It might help to keep this in mind, in my case I had to add a hook mechanism for all of these commands after the fact to generate and keep this file in sync. [1]: https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html > At the moment project.el only handles one backend at the time. I made a > simple workaround to extend it a bit, but that is a bit tricky and at > this point simplicity matters. Otherwise we end up with an inefficient > and complex interface easy to break and hard to make it work. This is probably another reason this should be orthogonal to project.el. The project backend is something well defined like a git repo. The project type backend is whatever arbitrary marker communicates what the project type is. -- Mohsin Kaleem