Jeff King <peff@xxxxxxxx> writes: > I think that's the rub, though. We hit this code path by default, so > it's _not_ a sign that the builder cares about gitk. OK. >> Whether the builder wants to run the result on the same box is a >> separate and irrelevant matter. Once built and installed, a box >> without "wish" may not be able to run the result, but installing it >> after the fact will fix it without need to rebuild anything. > > Yeah, this side-steps the "other half" of the issue that Christian's > patch addresses, which seems like the more controversial part (I don't > have a strong opinion myself, though). Is that controversial at all? In the sense that it is addressing a non-issue (i.e. it is perfectly fine if installed gitk fails at runtime complaining that it cannot find wish), it might be, but to me, it appears there isn't any room for controversy there. But an out-of-box build that fails _is_ a problem worth addressing to, so I view it primarily as the "how do we do msgfmt (or its substitute that is good enough for tcl script)" issue. Perhaps we can export NO_GETTEXT from the top-level Makefile and have Makefiles in these two subdirectories to pay attention to it, in addition to NO_MSGFMT, and build them without i18n support instead of failing, or something?
