Project out of sources compilation

[Ergus <spacibba@aol.com>]

Hi:

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.

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.

   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.

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.

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.

--

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.

WDYT?
Ergus