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

[Patrick Steinhardt <ps@pks.im>]

On Mon, Aug 25, 2025 at 05:40:17PM -0700, Junio C Hamano wrote:
> 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.

> 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