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: Mon, 1 Apr 2024 15:52:36 +0200 Message-ID: <27rton4k4r6sacysluk7iikj57ai2tyiak4ldd5nzpts7thmhg@nriej75catir> References: <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2.ref@pyv2z5snot6h> <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2@pyv2z5snot6h> <87ttl5w0mr.fsf@gmail.com> <1fd527fc-9643-49d2-8fae-d7e7fd043fe1@gutov.dev> <87le5x34l6.fsf@gmail.com> 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="13199"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Dmitry Gutov To: "Dirk-Jan C. Binnema" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 01 15:53:48 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 1rrI6d-0003EV-Vi for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Apr 2024 15:53:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rrI5k-00047c-8a; Mon, 01 Apr 2024 09:52:52 -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 1rrI5h-000474-ER for emacs-devel@gnu.org; Mon, 01 Apr 2024 09:52:49 -0400 Original-Received: from sonic312-20.consmr.mail.bf2.yahoo.com ([74.6.128.82]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rrI5f-00083j-0B for emacs-devel@gnu.org; Mon, 01 Apr 2024 09:52:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1711979564; bh=mP4Gm8h7b0Cjvv1DuHFILNbtJjEE/SQeTy4I41nLut8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=FsaQMbHcl/27cm4JMDpYEAm1k2KISCD9UbBCHOYBI/Y1fJg04nfxfir+lyDG2UolRwqYMD0Dc6S1tqCccGO53F4URpaubBHsoB9KSNoXQCUBCmrxKY3Nao9YhW/J7NMdXKtiVtV/cpzAwyugEloFb6ldtAfpKKlIRM0zvW2Ef0RlzVL8Wv30Skk0GBLP8QtdW3yQj/KzvwNsDU2xBqf/PrHbLXoxeetxHvL3W7fopUPTkH0rfigyQpW3pOZrtcLSWCKGi1q76wdo91kW61w0YZ7ADHtAsb130bh/gN+Kbt6KOAIiad2UV/i1d4DQbuI5hFAu7tVHH2MeyOYns4jhXA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1711979564; bh=5Oe4fwRXZBLXSD62jsExptf9Zb2vuvZuI12PBr4R6V1=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=i+6mulWCXWJQvGEojJVrP94J6Ye6M1uvZVFhwBP/FV/StnYn0LZCEv8xJ9xdDqnEXP0Ta1OToIV2xPTob8j487JsHp52Bjgv1li1t3xl0hvtMBw5d1EecDv0zVKV47AZd/bqJqH3jriWBFpLHUSn4LhWYDvgzNNDXUHGlU2CfYgevam3lcVK4n97eKFJ0BpT0wXnIF1SUpo6ByCfdCErU4fqPBXsrdKZ6K/CNEJGzUeBo4nW6JItiqLJUoEkYv4TX3NU5ZtZncvzTPrmyDoVkp9Gx+0Xsv1mrYzHb6r9RkvB+x1AxLxVheDnWEB6cWh9CSRHW+6KI2NReoM9a6BqdA== X-YMail-OSG: OBVJ7LwVM1k3cBytO0gGFOqvQ77PWWKmcAgiPCDqlCg1tFstqIoP0dw4f_ZfZNq _Hgu9CANKvwGfRusoHPuliVh3F4704uI38sUj96IVJsAMk0T1pdOlu.PkF0DdnuA5cvI8ABqvDlf WJ8X3AiypZ9VuQvh1nXOwcpdmTyGhUEIQq1lwhw8wYfvVjCGNHGe9M0QzFIFph9tPjnqBshW0eEG dzWhwXDnI.048j3R4nnEWHRfCvK.IqbiAhxXwhaZrN5DmCFDRWNLVP8cH49oMo7B8eZ7dQscev.E psQUjrbgRim6s.PUHeHShv62kt29sWGNBsYqewzgfUd0PD2SHlhJg9Chm1ot.Hcfejx1hqftmXzp StwZ.1rZqRlkEv6xtyw8LpfmWTbgnTj6c.zuubOdJnfDQY.Y9Y1bP3s1yYdCA.YIborN6ZCmBLmJ 76jgBnORb23icOLjrKvwbyq0nUyzHNAnFqvgbgMaINSaO0udMuQPqlHJgk.RMEyPdcstNZtU1e_s ZEyOCfeiz_laTRJNNw06hjG0UoM1JXEVtLWQNtV4iz3k5eGDXOrsyTHoayXxIG9GFG7yqKCrDitz GLXvF3gglnK_Eb_pEyMiOb9Yke44_58Hnl3XnCVcQ0HyATlwOIhMuFQ81IFx9iHnlEhp9ApsTYLj dXrQCe1DFCokHhs5Iq.WMxOfwRc5Lyp4xgo45.Igb2Q8WmHi.uQzGgyMKK27OHRtBniJkID_MTuc NOHH2EzWmEB0HALfRp0g1ZGpCKa9rifzluV1SFHoOtTafcQrSygtanmd1XP8SxYUjqF48qTvImKV vPUt5nbpDRpQEOwfBu6ieEnYAgmRT1X9mYhad5y_kH X-Sonic-MF: X-Sonic-ID: 549147da-6d00-4028-9ef7-fc06827b7e64 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Mon, 1 Apr 2024 13:52:44 +0000 Original-Received: by hermes--production-ir2-7bc88bfc75-8kqvj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 44c25757134bc3dfb2f2d1e35461848d; Mon, 01 Apr 2024 13:52:38 +0000 (UTC) Content-Disposition: inline In-Reply-To: <87le5x34l6.fsf@gmail.com> 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.128.82; envelope-from=spacibba@aol.com; helo=sonic312-20.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:317447 Archived-At: On Mon, Apr 01, 2024 at 10:49:25AM +0300, Dirk-Jan C. Binnema wrote: >On Sunday Mar 31 2024, Ergus wrote: > >> 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: >>> > >>> 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 > >My 0.02: Having separate build-directories seems to be increasingly >common (in my bubble I hardly see anything else anymore) > Same for me >Allowing for _multiple_ build-directories is also quit common/useful. >E.g., for doing debug/release builds, or for building for different >target hw (embedded dev). For me, a daily need. > This is actually part of the main goal >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. >>>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. > >(would be nice to add "meson" too!) > No problem once the feature will be more advanced I can add it to the project-multi backend in my github... >No immediate opinions on how to implement this, but things I commonly >want in projects: > >- build >- run >- test >- install >- flash >- debug >- clean > Lets start with the one common to all: `build' Some others are difficult to support i.e I have no idea what is `flash'. And makefile based projects may not have a clean target defined. The install may be also controversial as it may refer to install in the system or create an install directory. And run is complicated because most projects create multiple outputs, so we need to find some kind of standard method to list them in order to at least ask the user in the first call. As Dmitry said, the multiple targets may be also difficult to handle with this abstraction either to `build only one' (may require completion in the command manually) or to debug (in order to know which target/executable to debug). I am not saying it is impossible, just that I don't have enough knowledge about all the tools and their support for such commands. Also remember that this only applies to specific backends because vc backends know nothing about this, so the commands need to be defined somehow conditionally in M-x according to the backend... That's very far from my elisp capabilities... >It's possible of course to "multiplex" with the compile-command and put >in a "transient" or something like that; but it'd be nice to handle this >directly across projects; also for adding menu / toolbar commands. > >Guess this is a bit of an open-ended list, so having `project-*-command` >may not to be the best. > Agree here, but I am not a good lisper... so probably Dmitry can bring some advanced elisp feature I am not be aware of that could solve this issue. >Kind regards, >Dirk. > >-- >Dirk-Jan C. Binnema Helsinki, Finland >e:djcb@djcbsoftware.nl w:www.djcbsoftware.nl >gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036 >