GNU bug report logs -
#70408
30.0.50; Eglot and Project integration
Previous Next
Full log
Message #35 received at 70408 <at> debbugs.gnu.org (full text, mbox):
On 16/04/2024 16:51, João Távora wrote:
> On Tue, Apr 16, 2024 at 1:56 PM Dmitry Gutov <dmitry <at> 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.
This bug report was last modified 1 year and 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.