Re: [PATCH] Project out of sources compilation

[Dirk-Jan C. Binnema]

On Monday Apr 01 2024, Ergus wrote:

> On Mon, Apr 01, 2024 at 10:49:25AM +0300, Dirk-Jan C. Binnema wrote:

>>> I added one method and with that I already support autotools and cmake.
>>
>>(would be nice to add "meson" too!)
>>
> No problem once the feature will be more advanced I can add it to the
> project-multi backend in my github...

Great!

For meson support, I found I needed somewhat of a variation on
`locate-dominating-file' to find the remotest parent directory that has
a meson.build. Guess it's similar to what's needed for cmake. 

>>No immediate opinions on how to implement this, but things I commonly
>>want in projects:
>>
>>- build
>>- run
>>- test
>>- install
>>- flash
>>- debug
>>- clean
>>
> Lets start with the one common to all: `build'
>
> Some others are difficult to support i.e I have no idea what is
> `flash'. And makefile based projects may not have a clean target defined.

Yes, these are only useful for _some_ projects; currently I have some
custom solution to determine the flash command for the current
project (if any). But I think it'd be nice to somehow attach the
functionality to the current project. 

Note - it'd indeed be hard to automatically guess/determine this for
some project; in many cases, it would probably require the user to
configure some project-specific variable to set the commands.

> The install may be also controversial as it may refer to install in the
> system or create an install directory.
>
> And run is complicated because most projects create multiple outputs, so
> we need to find some kind of standard method to list them in order to at
> least ask the user in the first call.

As above, some of this might require some project-specific user
variables.

For comparison e.g. VSCode allows for doing such actions for many
projects; Emacs can do that as well, but currently it requires quite a
bit of custom tweaking; I'm just saying it'd be nice to integrate that
with project.el.

Some .project-locals.el could be useful for this.

> As Dmitry said, the multiple targets may be also difficult to handle
> with this abstraction either to `build only one' (may require
> completion in the command manually) or to debug (in order to know
> which target/executable to debug). I am not saying it is impossible,
> just that I don't have enough knowledge about all the tools and their
> support for such commands.
>
> Also remember that this only applies to specific backends because vc
> backends know nothing about this, so the commands need to be defined
> somehow conditionally in M-x according to the backend... That's very far
> from my elisp capabilities...
>
>>It's possible of course to "multiplex" with the compile-command and put
>>in a "transient" or something like that; but it'd be nice to handle this
>>directly across projects; also for adding menu / toolbar commands.
>>
>>Guess this is a bit of an open-ended list, so having `project-*-command`
>>may not to be the best.
>>
> Agree here, but I am not a good lisper... so probably Dmitry can bring
> some advanced elisp feature I am not be aware of that could solve this
> issue.

Sorry for hi-jacking your useful proposal to propose some more :-)

Kind regards,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036