From: "Dirk-Jan C. Binnema" <djcb.bulk@gmail.com>
To: emacs-devel@gnu.org
Cc: Dmitry Gutov <dmitry@gutov.dev>
Subject: Re: [PATCH] Project out of sources compilation
Date: Mon, 01 Apr 2024 10:49:25 +0300 [thread overview]
Message-ID: <87le5x34l6.fsf@gmail.com> (raw)
In-Reply-To: <n5zr3ct3lczxwsyfu25f7cilsyf3n43vjuo74bmlozkcew4f2c@kt6g52f3xl3d> (Ergus's message of "Sun, 31 Mar 2024 23:07:31 +0200")
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
next prev parent reply other threads:[~2024-04-01 7:49 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2.ref@pyv2z5snot6h>
2024-03-16 13:12 ` Project out of sources compilation Ergus
2024-03-16 16:50 ` Konstantin Kharlamov
2024-03-16 19:00 ` Ergus
2024-03-16 20:56 ` Konstantin Kharlamov
2024-03-17 2:53 ` Dmitry Gutov
2024-03-17 7:22 ` Ergus
2024-03-17 8:45 ` Eli Zaretskii
2024-03-17 17:33 ` Ergus
2024-03-17 17:38 ` Eli Zaretskii
2024-03-17 17:58 ` Ergus
2024-03-17 11:36 ` Augusto Stoffel
2024-03-17 17:47 ` Ergus
2024-03-19 18:36 ` Ergus
2024-03-27 16:38 ` [PATCH] " Ergus
2024-03-31 2:41 ` Dmitry Gutov
2024-03-31 21:07 ` Ergus
2024-04-01 7:49 ` Dirk-Jan C. Binnema [this message]
2024-04-01 13:52 ` Ergus
2024-04-01 15:09 ` Dirk-Jan C. Binnema
2024-04-01 17:18 ` Ergus
2024-04-02 23:23 ` Dmitry Gutov
2024-04-03 19:47 ` Ergus
2024-04-06 2:05 ` Ergus
2024-04-14 1:44 ` Dmitry Gutov
2024-04-16 14:56 ` Ergus
2024-04-22 17:05 ` Ergus
2024-04-22 18:48 ` Ergus
2024-04-22 21:20 ` Mohsin Kaleem
2024-04-23 15:17 ` Ergus
2024-04-23 19:26 ` Mohsin Kaleem
2024-04-26 0:47 ` Dmitry Gutov
2024-04-02 21:39 ` Richard Stallman
2024-04-02 22:43 ` Dr. Arne Babenhauserheide
2024-04-05 21:40 ` Richard Stallman
2024-04-03 10:40 ` Konstantin Kharlamov
2024-04-03 11:45 ` Eli Zaretskii
2024-04-03 13:31 ` Konstantin Kharlamov
2024-04-03 14:11 ` Eli Zaretskii
2024-04-03 15:00 ` Konstantin Kharlamov
2024-04-03 15:47 ` Eli Zaretskii
2024-04-03 17:27 ` Konstantin Kharlamov
2024-04-03 18:22 ` Eli Zaretskii
2024-04-03 19:08 ` Konstantin Kharlamov
2024-04-03 20:12 ` Ergus
2024-04-04 5:26 ` Eli Zaretskii
2024-04-04 9:59 ` Ergus
2024-04-04 11:59 ` Eli Zaretskii
2024-04-04 12:34 ` Ergus
2024-04-04 13:02 ` Eli Zaretskii
2024-04-04 14:27 ` Ergus
2024-04-04 14:41 ` Eli Zaretskii
2024-04-04 18:15 ` Ergus
2024-04-04 18:56 ` Eli Zaretskii
2024-04-04 20:16 ` Konstantin Kharlamov
2024-04-05 5:11 ` Eli Zaretskii
2024-04-04 5:07 ` Eli Zaretskii
[not found] ` <87jzlefgi9.fsf@dick>
2024-04-03 18:44 ` Konstantin Kharlamov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87le5x34l6.fsf@gmail.com \
--to=djcb.bulk@gmail.com \
--cc=dmitry@gutov.dev \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.