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: Project out of sources compilation Date: Sun, 17 Mar 2024 08:22:56 +0100 Message-ID: <9098131B-AFBE-4978-B679-4C1D5507F55E@aol.com> References: <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2.ref@pyv2z5snot6h> <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2@pyv2z5snot6h> <5e04b699-6a0a-45ef-92cc-2115b58a869e@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27856"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org, Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 17 08:24:10 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 1rlksM-00072Y-5n for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Mar 2024 08:24:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rlkrV-0005fq-9Y; Sun, 17 Mar 2024 03:23:17 -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 1rlkrT-0005fc-46 for emacs-devel@gnu.org; Sun, 17 Mar 2024 03:23:15 -0400 Original-Received: from sonic311-13.consmr.mail.bf2.yahoo.com ([74.6.131.123]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rlkrQ-0006ZM-Hd for emacs-devel@gnu.org; Sun, 17 Mar 2024 03:23:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1710660188; bh=gxM9gwdc9Mv+H6XZGjQC7K+1Kg+W2c+OohudF97yrbQ=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject:Reply-To; b=JTvGW2KnVu4GXY2n8jqx/3vjWJB6lqYtdiFk9Z2Ha1v2LhmxUHgjpary7Z2aqhhALL8Ur0u045+MhPch1Wl1HCIsoeuUdFGBeTyRCrhtiTDGCQbY+WLVsTEtXnuVTKvSEAcxlY+RYkD9CzHN+c4v0GGUyJ+jFqIcPAN25o6QN//AFGzvYlSh6Isat8wjz/CGKUOiAmk7kyhzZA2V3+iDSwtkUJ2DfNLcMRaJ0nTi1Y2OVUr7EMmEVi+mJOwZu0FTfrj4SSnlRAcpGeF3ScQ/F5TM7kLMlZBMyLJhfYwbHfTK7XMm4FiM96u62cHp23Am6IaVw18oUcU9iv1Udd8Yng== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1710660188; bh=rQQC0WfIRc6IUiGz74pRuU4gpCCCdLaDRlnMDRfEj/c=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=WuBnRxP7LTz4NH2jH2z7GFPaaJSsdGpL74R/rz1CRCugqMCAaa+wwWgqIc4aoOM2Yf7e2jfXpzLpO12+L5CGSbG4Mkrvc2zf1BHtvP0brFOfAEiWyFZL+ZRr7fqrU9CQSMBIkaxfhHk8HP1xDT1xVwlSINHxKnGR6gA4ieu2VW21h2W3hjH43hZXtmfKaz7vxzBnbo5DC9crzI9XEG3HcGK8nX/AY6mIn3K18drTtl0osSU9Ew+JOdiLQFOYRgSQbCbJLXduxqI1TWH5TwOZylAMaBtN9gdwVIJMH3ZIukcp+dXW/u2LWZhr/8VrAfHA9Gac1Zt7HsbS3jh4w7p1Xg== X-YMail-OSG: JXzi8OYVM1lld69GHbtBHlmBP0rBuLQ3b3XATSJFztiZ78nLH45uObbLQiUztj2 mSrSQbgpnPmcLOur.yD7QzoYfCfnn3mcdtIVXV1aI5a62k8298s8x9HuO778t9DyKyyMD7uAF6tL 34JWsH7D0ect5vPlpPWKivmjq2WyX5BkobaWu5gqnYE2E0qDr8s1OGmO_7zrabivLaeIMJHwakvQ 9PoGdvItJNKWXGGO0eM6bRbumqKObjUp8kU_ut.OXZXPwC6MJfa9Oj2J5OTZK84189SZVrZNstoa uvD11GKvv8K.Mz2mX51O.n4vAxu2NxmwhY4b6LxFD0g0dbVKDXUptMi9Wb5.HqPdwIAgdjdbeO04 CtT4lVbiHnKVjKpix2aLOkXIkKn0tLGzriFPEA0AulTcxe7qsAL0x3pBOaHsPcZLPszNVdTGLGFF GRtZ7LqP9RlLsZSIlvn4SeMKk8vBGA_ZUL.xZ65hPE0Oi8U2f_6wrn.IHVTHGkvFh94WamT1XlgT O4z1jNZZjA1.PFVJ1h.5IXNUfy0mTv8P7PPDH9ACux1n33F4A.GXVFivr24JRDoXtlSVU9.YjIbf GbbzU9rpXVq0jEUOwI6jNcdLTokAv4RoE7RaZ1tNI.L0BE2V3mx_YtQW.Z1dneFY18rM.Q3oLW8X M.cxHU6g_pHPAVnfHEjXIWvxdUEXthKlIuG.IKJz2CnFluIBXk.vU0hK2gpeR.5PYpKYT_EH3ORO apOdfK3winA4mHiNQk.QEBBz2UCmLL34ZmCs5RYHH3x5O6FS5xzkAEaiwoMPcPkzWu9H8En.VuH1 IlKF1sZHcGQ65HnToDKwBj2loIYbR7GfudPtq7Aq7m X-Sonic-MF: X-Sonic-ID: 9eb009ea-2146-476a-a385-9e5022d393a9 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Sun, 17 Mar 2024 07:23:08 +0000 Original-Received: by hermes--production-ir2-7bc88bfc75-h6nxx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c5cba94052b0d90f243e8b3b1c3cbbf3; Sun, 17 Mar 2024 07:23:04 +0000 (UTC) In-Reply-To: <5e04b699-6a0a-45ef-92cc-2115b58a869e@gutov.dev> X-Mailer: WebService/1.1.22129 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.131.123; envelope-from=spacibba@aol.com; helo=sonic311-13.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, 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:317134 Archived-At: Hi: On March 17, 2024 3:53:42 AM GMT+01:00, Dmitry Gutov = wrote: >Hi! > >On 16/03/2024 15:12, Ergus wrote: > >> These days I have been working with cmake projects here and there and i= n >> 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=2E >>=20 >> 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): >>=20 >> 1=2E Out of sources compilation=2E >>=20 >> Most of projects now prefer to do out-of sources compilation=2E Either = to >> keep source code clean or to keep multiple compilations at the same tim= e >> (i=2Ee Debug/Release/win32) >>=20 >> The project=2Eel package has already some compilation commands, but the= y >> assume that the compilation will be executed in the project's >> root=2E=2E=2E which is not true most of the time=2E >>=20 >> Maybe we may add an extra custom variable that could be specified in th= e >> dir-locals=2Eel in order specify where the compilation command must be >> executed=2E >>=20 >> Some more heuristics here is possible, but I would settle for at least >> something simpler=2E > >project=2Eel has just one, very simple command, where the only thing that= it does it switch to the root first=2E How will you customize it? With a h= ook, where the user would write a function "determine a directory for compi= lation"? They might as well define a new command - or redefine this one=2E = Or just an option with relative directory name? > IMO the only thing we need is probably a variable/custom like project-buil= d-dir=2E The user can define it in the dir-locals and the project command w= ill use it if defined/ else use project-root=2E Maybe the backend could ini= tialize it=2E Alternatively (and not totally exclusive) project=2Eel could define a proj= ect-build-dir function that project backends could optionally redefine (i= =2Ee I use a plist as project id in gags-mode and getting any stored proper= ty from there is very easy with a command)=2E By default it will be an alia= s for project-root in the VC backend=2E There is also some need for a 'bin' dir, that is, where the final executab= le will reside, useful to execute and debug with tools like gud and indepen= dent from 'build'=2E=2E=2E For example in a python project this may be the= project root OR where the file with __main__ resides, but a python project= usually won't specify a build dir=2E But let's go for one thing at a time= =2E >> 2=2E Eglot compilations database place=2E >>=20 >> When compilation is out of sources the cmake generated >> compile_commands=2Ejson also goes in that directory by default=2E >>=20 >> This issue can be managed with a line in dir-locals, or just manually >> coping the database=2E >>=20 >> ((eglot-workspace-configuration >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =2E (:clangd (:initializationOptions (:= compilationDatabasePath >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "build"))))) >>=20 >> Probably some simple slight integration of Eglot with Project may help= =2E > >That seems like it can be a Eglot user option=2E Again, just storing a fi= le name relative to the project root? > Actually it doesn't need to be relative=2E For example QtCreator creates t= he build dir outside the sources directory in the same level=2E So, the onl= y requirement is to be a valid path=2E Relative to root or absolute one >> =C2=A0 2=2E1 This mixes with the previous one because if we change the >> =C2=A0 compilation directory the line with initializationOptions is no= t >> =C2=A0 updated and requires manual intervention >>=20 >> 3=2E Projects multiple backends >>=20 >> This one is tricky because at the moment I have gtags-mode, that >> includes a backend for project=2Eel, there is the default backend, but >> also we could add something called cmake-backend (i=2Ee looks for >> CMakeLists=2Etxt that includes a 'project' entry) >>=20 >> In that case emacs cannot use all the information form the three even i= f >> it is not contradictory, so the user ends up opening the terminal and >> doing things manually=2E > >Indeed, project=2Eel doesn't "merge" backends=2E Is there an obvious algo= rithm for merging backends which would be understandable to an average user= ? > >If the only thing you wanted combined is the root detection, I suggest re= using the variable project-vc-extra-root-markers, automatically or manually= (just have the user set it)=2E If its data structure is now powerful enoug= h, it can be updated=2E For example, if the logic both looks for CMakeLists= =2Etxt and checks its contents, project-vc-extra-root-markers could support= cons entries like (MARKER =2E CHECK-FN)=2E Actually the idea is as simple as: if any of the backends explicitly speci= fies some property that the others don't, then use that one=2E Applied in this case=2E VC backend does not have any "build" Information i= n general=2E But a cmake backend could detect a "build" directory and propo= se it (looking for a CMake cache inside it for example)=2E An hipothetical = autotools backend may do the same=2E > >> 4=2E Flymake integration >>=20 >> Even without eglot, flymake should be capable to work very easily with >> cmake projects=2E >>=20 >> This step is also a stage before doing a proper plugin integration of >> tools like cppcheck for flymake=2E > >Is there something particular that is required? > >> 5=2E Project local variables (a man can dream, a man can dream) >>=20 >> There are some situations where we want to have variables shared among = a >> project=2E (i=2Ee some output directory, logging option when executing, >> flags, environment variables)=2E >>=20 >> At the moment these options work partially by using directory >> variables=2E 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=2E >>=20 >> 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=2E > >Does such subdirectory in VS Code affect the project residing its its par= ent directory, or some other projects as well? Your description above sound= s more like our =2Edir-locals=2Eel=2E > >And the directory locals facility in Emacs also has the less well-known c= apability called "directory class", see the bottom of https://www=2Egnu=2Eo= rg/software/emacs/manual/html_node/emacs/Directory-Variables=2Ehtml=2E I th= ink it should work okay for sharing variables between projects=2E > >Perhaps it's less user-friendly than one had hoped, I don't know=2E Some = improvements for related UIs would be welcome=2E > >Just creating a parallel built-in way to set variables inside directories= but for projects sounds a bit much=2E Also, we don't always detect a buffe= r's project before the user asks for it=2E So I'm not sure what hooks could= be added, even if we wanted=2E > Ok, I buy this one because there are the dir-locals, which are not ideal f= or project purposes, but it is already there and it isn't worth adding anot= her abstraction layer >> 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=2E Or which one= s >> are maybe better to put as feature requests for a more skilled lisper o= r >> package maintainer=2E > >Patches are welcome, but see above=2E > >Cheers, >Dmitry=2E > Best, Ergus --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E