From: Ray Andrews <rayandrews@eastlink.ca>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: 'whence' question and others
Date: Mon, 10 Nov 2014 08:57:54 -0800 [thread overview]
Message-ID: <5460EE92.6020307@eastlink.ca> (raw)
In-Reply-To: <CAH+w=7Zbmr0rWSeY+tXWk0=qoi+moY7-9EDz86-dPTcjLttTig@mail.gmail.com>
On 11/10/2014 12:20 AM, Bart Schaefer wrote:
> If you build from the parent directory, configure will be (re)run when
> necessary by "make". Also in that case, the documentation will be
> rebuilt when the .yo files are changed.
Is there a decent doc for 'configure', what it does, how it works? I see
the msg. scroll by,
and they are mostly about what is and isn't available. One can easily
understand that
there'd be a check for essential stuff, but it seems do do much more
than that. What makes
a reconfigure necessary?
> What exactly do you mean by "function help"? The documentation for the
> library functions? On most linux systems "info libc" will probably work
Tx. Once I got the proper name of the lib from that the rest was easy.
> If you configure with --enable-zsh-debug then a function dputs() is
> available which writes messages to the file named by the
> $ZSH_DEBUG_LOG parameter. It's kind of a stripped-down printf() which
> accepts only a few %-formats: %s = string, %d = int, %L = long, %c =
> char (including multibyte), %e = error number [for strerror()], and %l
> which is for non-nul-terminated strings and accepts two arguments, the
> char* and the number of bytes to print. If you want to leave some kind
> of tracing on during normal use, I would recommend using dputs() and
> setting $ZSH_DEBUG_LOG. There are also a set of DPUTS() macros which
> are sort of like assert() wrappers for dputs(). Something akin to the
> above paragraph ought to be in zsh-development-guide somewhere.
Good, some nice robust methods.
next prev parent reply other threads:[~2014-11-10 15:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <545A6D66.3080500@eastlink.ca>
[not found] ` <1458.1415209763@thecus.kiddle.eu>
[not found] ` <20141105180035.22f6e9b1@pwslap01u.europe.root.pri>
[not found] ` <141105204330.ZM2973@torch.brasslantern.com>
2014-11-06 21:10 ` 'whence' question Peter Stephenson
2014-11-06 21:58 ` Bart Schaefer
2014-11-08 20:41 ` Peter Stephenson
2014-11-09 18:51 ` Bart Schaefer
2014-11-10 5:15 ` 'whence' question and others Ray Andrews
2014-11-10 8:20 ` Bart Schaefer
2014-11-10 8:23 ` Bart Schaefer
2014-11-10 16:57 ` Ray Andrews [this message]
2014-11-10 19:53 ` Vin Shelton
2014-11-11 16:52 ` 'whence' question Ray Andrews
2014-11-11 19:14 ` Bart Schaefer
2014-11-11 19:38 ` Bart Schaefer
2014-11-11 20:22 ` Ray Andrews
2014-11-11 18:16 ` Ray Andrews
2014-11-11 19:33 ` Bart Schaefer
2014-11-11 20:40 ` Ray Andrews
2014-11-08 21:55 ` Bart Schaefer
2014-11-10 10:04 ` Peter Stephenson
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5460EE92.6020307@eastlink.ca \
--to=rayandrews@eastlink.ca \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/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://git.vuxu.org/mirror/zsh/
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 NNTP newsgroup(s).