From: Jeff King <peff@peff.net>
To: Todd Zullinger <tmz@pobox.com>
Cc: Christian Couder <christian.couder@gmail.com>,
Junio C Hamano <gitster@pobox.com>, git <git@vger.kernel.org>,
Dominik Mahrer <teddy@teddy.ch>,
Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH] Makefile: check that tcl/tk is installed
Date: Fri, 17 Nov 2017 17:02:10 -0500 [thread overview]
Message-ID: <20171117220210.6xqi26mabbyvxc2m@sigill.intra.peff.net> (raw)
In-Reply-To: <20171117174258.GP3693@zaya.teonanacatl.net>
On Fri, Nov 17, 2017 at 12:42:58PM -0500, Todd Zullinger wrote:
> > I'd rather add a separate check for msgfmt than mixing the 2 issues,
> > because I think that unless it has been explicitly told to do so, Git
> > should not try to build git-gui and gitk in the first place if there is
> > a big chance that those tools will not work.
>
> If that's a motivation, wouldn't a check in the gitk and git-gui scripts
> handle it? That would provide an error at run time to the user. This
> change is about helping the user who builds their own git and then runs it,
> so if they built git without wish installed and then ran git-gui, they'd get
> a clear error that wish is missing and could easily install it. It's not
> needed for the build, so they wouldn't need to rebuild anything.
I think the message is already OK:
$ ./gitk
./gitk: 3: exec: wish: not found
The question is whether we would want to catch this at build time. And I
think Junio's point is that we don't _know_ it's an error at build time.
We could be building gitk for use on a system that isn't quite like the
build system, so any "solution" here is going to have to make an
assumption either way.
It's also not foolproof. You could build when wish is present, and then
later uninstall it and receive the same error message.
I also think all of this is largely orthogonal to gettext. It just so
happens that if you don't have gettext installed, we'll try to run wish
as part of the build process, but detecting broken tcl setups was
definitely not part of the intent there.
And the failure actually runs the other way, too. If you have neither
gettext nor tcl, you get this confusing output:
$ make NO_GETTEXT=1
...
MSGFMT po/pt_pt.msg MSGFMT po/hu.msg Makefile:252: recipe for target 'po/pt_pt.msg' failed
make[1]: *** [po/pt_pt.msg] Error 127
(the problem is not msgfmt, but our tcl substitute which cannot run).
I'm actually tempted to say that we should not be building the tcl parts
by default. IOW, instead of NO_TCLTK we should have USE_TCLTK. That
would also require an adjustment by package builders, but it would
hopefully be a really obvious one. And once the user has told our
Makefile that they definitely want to build the tcl parts, we'd
presumably just trust that the tcl path they give us is sane.
But it's possible I'm underestimating how many people actually use the
tcl scripts. Certainly I don't, and git-gui seems fairly primitive to me
these days compared to 3rd party tools. But then I don't use any of them
either. ;)
-Peff
next prev parent reply other threads:[~2017-11-17 22:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-15 12:52 [PATCH] Makefile: check that tcl/tk is installed Christian Couder
2017-11-16 1:35 ` Junio C Hamano
2017-11-17 15:35 ` Christian Couder
2017-11-17 17:42 ` Todd Zullinger
2017-11-17 22:02 ` Jeff King [this message]
2017-11-20 17:25 ` Christian Couder
2017-11-20 18:12 ` Christian Couder
-- strict thread matches above, loose matches on Subject: below --
2017-11-20 17:15 Christian Couder
2017-11-20 17:17 ` Christian Couder
2017-11-20 19:19 ` Jonathan Nieder
2017-11-20 23:58 ` Christian Couder
2017-11-26 19:15 ` Jeff King
2017-11-26 20:57 ` Christian Couder
2017-11-27 15:31 ` Jeff King
2017-11-27 1:13 ` Junio C Hamano
2017-11-27 4:31 ` Junio C Hamano
2017-11-27 4:35 ` Jeff King
2017-11-27 5:22 ` Todd Zullinger
2017-11-27 8:24 ` Christian Couder
2017-11-27 15:27 ` Jeff King
2017-11-27 23:42 ` Junio C Hamano
2017-11-28 4:35 ` Junio C Hamano
2017-11-27 9:08 ` Junio C Hamano
2017-11-25 20:46 ` Christian Couder
2017-11-26 3:53 ` Junio C Hamano
2017-11-26 14:00 ` Christian Couder
2017-11-26 17:43 ` Ramsay Jones
2017-11-26 18:34 ` Christian Couder
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171117220210.6xqi26mabbyvxc2m@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=teddy@teddy.ch \
--cc=tmz@pobox.com \
/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 public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).