Re: Project out of sources compilation

[Ergus]

On Sun, Mar 17, 2024 at 12:36:44PM +0100, Augusto Stoffel wrote:
> On Sat, 16 Mar 2024 at 14:12, Ergus wrote:
>
> > 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 Emacs variables, why you think dir-local variables only works
> “partially”?
>
> As to environment variables, they are generally assumed to be global in
> Emacs and it goes a bit against the grain to make them buffer-local /
> project dependent.  Nonetheless, there are packages for that (one is
> buffer-env, which I wrote) and they work fine (at least for me).
They work for one directory, but when the project includes multiple
roots (project-external-roots) the variables are somehow missing just
when jumping with xref to a definition.

However, we can ignore this as I mentioned before.

> > 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.
>
> Is this meant to store editor configuration or environment variables?  I
> guess turning VSCode configuration variables into Emacs alternatives
> would be tricky. 

No please. No interaction-importing from other editors will be
maintainable in the long path.

> But if this is about env vars and the directory
> organization is sensible, then one could configure buffer-env to
> interoperate.

This is it. The idea is to extend project.el in order to bring more
project-oriented features.

Lets say:

The user (or project.el backend) could specify the `build` directory and
the environment that needs to be set to execute the program from the
build or bin directory.

So with a simple modification of dir-locals.el the user may be capable
to run M-x compile (or project-compile), M-x gud-gdb... or being more
ambitious M-x project-generate (to call autogen.sh and ./configure or
cmake depending of the project-backend)

For sure we wont cover the 100% of the projects, but wuth automake and
autotools we will be very close (and in the future someone could add
other backends for it)