On Sat, 6 Mar 2010, James Beck wrote:
> Yep, running :!make doesn't cause the delay. That's great to know. I
> don't use quickfix, so this seems like a good solution.
>
> But something doesn't add up here. If I put a ">/dev/null" at the end
> of every compiler line so that no text it sent to the screen, it still
> pauses. It's as if Vim is timing out, or expecting some kind of output
> (maybe it catches STDERR?) that it's not receiving.
>
> Just for fun, I put a "gcc mytestfile.c" at the end of the Makefile, but that
> didn't trick Vim into going faster.
Ha. :-) I like it.
But, I just discovered something interesting: the symptoms seem similar
to a problem I encountered with 'paludis' (the package manager I use
with Gentoo Linux) and 'distcc' (a distributed C compiler). Distcc
spawns a daemon to handle dynamic DNS caching. The daemon automatically
quits if it doesn't receive any requests for 20 seconds. Running
'distcc -j' (which uses that daemon once, then exits with some output)
returned immediately in the shell. But, it caused 'paludis' to pause
for 20 seconds, while 'paludis' waited for the grandchild process to
finish.
The tiny example program I came up with to test the paludis problem also
seems to cause a ':make!' hang (but not a ':!make' hang). So,
long-story-short, maybe something that's being run in your Makefile is
spawning a background process of some sort? (Vim waits for it; the
shell [even within Vim] doesn't.)
$ cat double-fork.c
#include <unistd.h>
int main(void) {
/* sleep for 10 seconds in the grandchild */
if (!fork() && !fork()) sleep(10);
return 0;
}
$ cat Makefile
all: double-fork
@echo before
./double-fork
@echo after
%: %.c
$(CC) -o $@ $<
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
