bug#70408: 30.0.50; Eglot and Project integration

[Dmitry Gutov <dmitry@gutov.dev>]

On 16/04/2024 16:51, João Távora wrote:
> On Tue, Apr 16, 2024 at 1:56 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
> 
>> IIUC Ergus's request is primarily about a situation where an
>> "out-of-tree" build is used. Meaning, the directory for build artefacts
>> is not a subdirectory of the project root, but -- apparently -- some
>> sibling directory of it (e.g. "../build"). So it's somewhat atypical,
>> although I suppose the solution from the link above might work with it too.
> 
> Ah, I know about that.  That's where compile-commands.json is generated
> by CMake.  But using that './build' as the project root passed via LSP
> to clangd
> (and likely any other server) will most likely fail: that's not  the
> project root
> and it doesn't have any versioned source files  (only auto-generated ones).
> 
> Because of this, C++ projects usually have sth like:
> 
>    ln -sf build/compile_commands.json compile_commands.json
> 
> as a build step.

Would you say it's common across most projects? E.g. generated as a 
build step by CMake in out-of-tree comfigurations.

Or is it something Emacs users tend to add.

What I'm wondering is whether we might be currently disadvantaged 
compared to the users of some other editors, which might have some more 
auto-detection in that area.

> Alternatively, you invoke clangd with `--compile-commands-dir=build`.
> I don't think there's anything project.el or Eglot can do or should do
> about this case.
> 
>> This bug is split off from an emacs-devel discussion, where I posted a
>> draft solution of mine:
>> https://lists.gnu.org/archive/html/emacs-devel/2024-04/msg00279.html
>> I'm curious for any feedback - like would that be good enough for this
>> and related cases, or maybe if someone has an even simpler approach in mind.
> 
> I'll pass, but wish you luck.  I've stated in the past that I think
> project.el should
> allow subprojects inside larger projects, and let users of
> project-current (direct
> or indirect) specify if they're interesting in the innermost,
> outermost, or intermediate
> projects when searching for projects to act on, via a combination of prefix
> arguments, arguments, customized special variables or let-bound special
> variables.

I'm open to continuing this discussion somewhere, but it's unrelated to 
this particular one. Note that, as I explained, it would be easy to 
create a set of commands acting on "super" projects, but that's probably 
not what you're looking for.