Re: [PATCH] Project out of sources compilation

[Dirk-Jan C. Binnema]

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)

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.

So having direct support for this in project.el would be quite welcome,
so I can use that instead of my private hacks.

>>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 immediate opinions on how to implement this, but things I commonly
want in projects:

- build
- run
- test
- install
- flash
- debug
- clean

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.

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