Re: [PATCH 0/3] meson: wire up gitk and git-gui

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 2, 2025, 13:00 UTC
Message-ID: <aLbqeL1X5CajH-Z8@pks.im>
In-Reply-To: <xmqqsehencem.fsf@gitster.g>

On Mon, Aug 25, 2025 at 05:40:17PM -0700, Junio C Hamano wrote:

Show 12 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> 
> > If this is proving to be a blocker we can also change upstream to not be
> > a separate project.
> 
> What do "upstream" refer to in this sentence?  Meson?
> 
> If you are talking about "gitk" and/or "git-gui", then such an
> alternative version of these patches would not change the picture an
> iota, wrt "the limitation of the tool should not force the sources
> that might consider using the tool to pay the price---which might be
> proving to be a blocker", no?

gitk/git-gui in this case.

Show 5 quoted lines

> Not that I am saying it _is_ a blocker.  But the above sounds like
> making things worse for no gain, so I must be misunderstanding what
> you meant X-<.
> 
> So, ... confused.

So, to hopefully alleviate the confusion, there's two ways to include a certain directory into Meson:

  - `subdir()` includes directories at arbitrary locations. The
    directory is treated as part of the project that calls `subdir()`.
    This is mostly done to segregate the project into multiple different
    components to keep things more maintainable.

  - `subproject()` includes directories in a specific location. The
    difference is that these are treated as separate projects, so there
    is a certain boundary between the top-level project and its
    subproject. Things done in the subproject won't taint anything in
    the superproject.

Right now I'm using `subproject()`, which has the effect that both gitk and git-gui can be compiled standalone with Meson, but also as part of the Git project. It does have the limitation though that the project must be in a specific directory.

What I was trying to say is that we could convert the build instructions of gitk and git-gui to not be standalone projects anymore. This would mean that we can include the subdirectory from any arbitrary location, but they cannot be built standalone without Git anymore.

Using `subproject()` is a much better fit for our specific use case, even though we have to move things around. I'm not particularly fond of this limitation, but I haven't found a better way to achieve this until now.

So yes, it's a limitation we get from Meson. But it's easy to work around this limitation by moving the projects into the "subprojects", which is a one-time cost, only. I've said for a long time anyway that I think our top-level directory could use some cleanup to make things a bit more discoverable for new contributors, e.g. by move all the code files into a "lib/" folder. So that's probably part of why I don't see this refactoring as a huge downside, even if it is working around a limitation.

Patrick