Re: Project out of sources compilation

[Ergus <spacibba@aol.com>]

Hi:

On March 17, 2024 3:53:42 AM GMT+01:00, Dmitry Gutov <dmitry@gutov.dev> wrote:
>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?
>

IMO the only thing we need is probably a variable/custom like project-build-dir. The user can define it in the dir-locals and the project command will use it if defined/ else use project-root. Maybe the backend could initialize it.

Alternatively (and not totally exclusive) project.el could define a project-build-dir function that project backends could optionally redefine (i.e I use a plist as project id in gags-mode and getting any stored property from there is very easy with a command). By default it will be an alias for project-root in the VC backend.

There is also some need for a 'bin' dir, that is, where the final executable will reside, useful to execute and debug with tools like gud and independent from 'build'...  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. But let's go for one thing at a time.


>> 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?
>
Actually it doesn't need to be relative. For example QtCreator creates the build dir outside the sources directory in the same level. So, the only requirement is to be a valid path. Relative to root or absolute one

>>    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).

Actually the idea is as simple as: if any of the backends explicitly specifies some property that the others don't, then use that one.

Applied in this case. VC backend does not have any "build" Information in general. But a cmake backend could detect a "build" directory and propose it (looking for a CMake cache inside it for example). An hipothetical  autotools backend may do the same.

>
>> 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.
>
Ok, I buy this one because there are the dir-locals, which are not ideal for project purposes, but it is already there and it isn't worth adding another 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. 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.
>

Best,
Ergus

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.