Re: Project out of sources compilation

[Dmitry Gutov <dmitry@gutov.dev>]

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.