From: Patrick Steinhardt Date: Tue, 02 Sep 2025 13:00:40 GMT Subject: Re: [PATCH 0/3] meson: wire up gitk and git-gui Message-ID: In-Reply-To: On Mon, Aug 25, 2025 at 05:40:17PM -0700, Junio C Hamano wrote: > Patrick Steinhardt 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