Re: Project out of sources compilation

[Ergus <spacibba@aol.com>]

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)