Re: [PATCH] Project out of sources compilation

[Ergus <spacibba@aol.com>]

On Mon, Apr 01, 2024 at 10:49:25AM +0300, Dirk-Jan C. Binnema wrote:
>On Sunday Mar 31 2024, Ergus wrote:
>
>> Hi Dmitry:
>>
>> On Sun, Mar 31, 2024 at 05:41:24AM +0300, Dmitry Gutov wrote:
>>>Hi Ergus,
>>>
>>>On 27/03/2024 18:38, Ergus wrote:
>>>
>
>>> I originally suggested a variable that stores a relative file name. But I see
>>> that you prefer the fetching of this file name to be more dynamic.
>>>
>> Yes, that's actually the point. In out of sources compilation there is a
>> possibility that there will be more than one subdirectory to build, in
>> that case the user may be asked at least once which one to choose. This
>> is also valid to detect the `compile-commands.json' which may have
>> different version in each of the build-dir candidates.
>>
>> https://github.com/Ergus/project-multi-mode/blob/c679d73a26b162e4158f6451027ca94e33faca0b/project-multi-mode.el#L109
>
>My 0.02: Having separate build-directories seems to be increasingly
>common (in my bubble I hardly see anything else anymore)
>
Same for me

>Allowing for _multiple_ build-directories is also quit common/useful.
>E.g., for doing debug/release builds, or for building for different
>target hw (embedded dev). For me, a daily need.
>
This is actually part of the main goal

>So having direct support for this in project.el would be quite welcome,
>so I can use that instead of my private hacks.
>
Projectile already have support for many backends and the implementation
is pretty clean. I am doing this because I thing that something so basic
must be part of vanilla.

>>>Why don't we just make it a function variable, at least at first?
>>>
>> Because I wanted somehow to follow the project.el schema of using a
>> generic that the backend could optionally define transparently.
>>
>> And make that definition independent from the user config variable, so,
>> the user defined variable takes preference over the generic search
>> performed by the backend which if not defined automatically goes to
>> project root. Somehow adding a custom variable I think interferes with
>> the idea that the backend provides the functionality... But I may be
>> wrong.
>>
>>> Call it 'project-compile-dir`, which would be settable to a string (constant
>>> value, to be customized through dir-locals), or a function that either accepts
>>> the current project value, or is simply called "inside project root" (with
>>> default-directory bound to that value).
>>>
>> I will try this again, but I had some issues before.
>>
>>> Alternatively, if you see a need to add additional methods
>>> ('project-compile-command'?), it could become a new hook and a new facility
>>> (e.g. project-build-functions) which could be structures similarly to
>>> project.el, i.e. the hook returns a "project builder" value, and the value has
>>> some methods that it can defined/override. Then different build tool backends
>>> could be mixed with different project backends more easily.
>>>
>> I would prefer avoid more abstraction layers in the api. We actually
>> need some `project-compile-command' like function, but structuring it
>> with generics and more layer is IMHO adding too much complexity for a
>> public api... Isn't there a simpler alternative?
>>
>>> So far I only see one additional method, though, and the constructed
>>> compile-command value is relatively simple. Curious to see whether this will
>>> get more complex with additional targets.
>>>
>> 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...

>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.

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 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.

>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
>