`make' completion in zsh-3.1.9

`make' completion in zsh-3.1.9

[Andrew Morton]

It's driving me nuts :)

I have

	bindkey '^I' menu-expand-or-complete

and when I type

/usr/src/linux> make menu<tab>

the shell locks up for about ten seconds, recurring into every
directory of the kernel tree doing *something*.  Finally,
it comes back with `make menuconfig'.

zsh-3.1.6 didn't do this - `make' completions returned
immediately.

Any suggestions?

Thanks.

Re: `make' completion in zsh-3.1.9

[Bart Schaefer]

On Mar 18,  2:13am, Andrew Morton wrote:
} Subject: `make' completion in zsh-3.1.9
}
} /usr/src/linux> make menu<tab>
} 
} the shell locks up for about ten seconds, recurring into every
} directory of the kernel tree doing *something*.  Finally,
} it comes back with `make menuconfig'.

It's running "make -nsp --no-print-directory -f Makefile .PHONY" to cause
make itself to output the list of possible completions.  I don't know why
this would be taking 10 seconds or more -- it finishes in 1 second or so
on my machine.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: `make' completion in zsh-3.1.9

[Bruce Stephens]

"Bart Schaefer" <schaefer@candle.brasslantern.com> writes:

> On Mar 18,  2:13am, Andrew Morton wrote:
> } Subject: `make' completion in zsh-3.1.9
> }
> } /usr/src/linux> make menu<tab>
> } 
> } the shell locks up for about ten seconds, recurring into every
> } directory of the kernel tree doing *something*.  Finally,
> } it comes back with `make menuconfig'.
> 
> It's running "make -nsp --no-print-directory -f Makefile .PHONY" to
> cause make itself to output the list of possible completions.  I
> don't know why this would be taking 10 seconds or more -- it
> finishes in 1 second or so on my machine.

Here's the sort of thing I get (from the top of a linux-2.4.2-ac20
tree):

# time make -nsp --no-print-directory -f Makefile .PHONY > /dev/null
make -nsp --no-print-directory -f Makefile .PHONY > /dev/null  28.85s user 3.09s system 97% cpu 32.609 total

This is with the standard Debian packages, zsh-3.1.9.dev8-2 and
make-3.79.1-4.  It's a fast machine (800MHz Athlon) with lots of
memory and decent disks, so it's not that.

I'm guessing there's some difference in make behaviour.  Presumably
this is relevant:

# make -nsp --no-print-directory -f Makefile .PHONY | wc -l
1494859

Anything that's producing that amount of output is going to take a
little while to run.

Re: `make' completion in zsh-3.1.9

[Bart Schaefer]

On Mar 17,  6:04pm, Bruce Stephens wrote:
} Subject: Re: `make' completion in zsh-3.1.9
}
} I'm guessing there's some difference in make behaviour.  Presumably
} this is relevant:
} 
} # make -nsp --no-print-directory -f Makefile .PHONY | wc -l
} 1494859

Yow.

You don't have a MAKEFLAGS environment variable set, do you?

You might try capturing a bit of the "make -nsp ..." output to see if it
really is honoring the -n (do not execute) and -s (don't print commands)
options.

However, it's possible that the Linux kernel build process has been
restructured in 2.4 in such a way that it's extremely expensive to run
make without actually building anything.  I don't have the 2.4 kernel
source downloaded here at home ...

} Anything that's producing that amount of output is going to take a
} little while to run.

Yes, I'll say.  You might try

    zstyle ':completion:*:make:*:version' command :

which will prevent completion from discovering that you have GNU make;
which in turn will cause it to parse the Makefile directly.  You lose
completion of any targets that are availble only via recursive makes,
and it'll miss GNUmakefile files, but it should run a lot faster.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: `make' completion in zsh-3.1.9

[Bruce Stephens]

"Bart Schaefer" <schaefer@candle.brasslantern.com> writes:

> On Mar 17,  6:04pm, Bruce Stephens wrote:
> } Subject: Re: `make' completion in zsh-3.1.9
> }
> } I'm guessing there's some difference in make behaviour.  Presumably
> } this is relevant:
> } 
> } # make -nsp --no-print-directory -f Makefile .PHONY | wc -l
> } 1494859
> 
> Yow.
> 
> You don't have a MAKEFLAGS environment variable set, do you?

No.

> You might try capturing a bit of the "make -nsp ..." output to see
> if it really is honoring the -n (do not execute) and -s (don't print
> commands) options.

I think it's honouring the -n, but possibly not the -s.  I can see
lots of commands that I'm guessing it would do without the -n.

> However, it's possible that the Linux kernel build process has been
> restructured in 2.4 in such a way that it's extremely expensive to run
> make without actually building anything.  I don't have the 2.4 kernel
> source downloaded here at home ...

Yes, I think that's what's happening: one or other of the Makefiles is
overriding something, somehow.  The same happens with Kaffe
(<http://www.kaffe.org/>).  I get over 2M lines with that.

[...]

>     zstyle ':completion:*:make:*:version' command :
> 
> which will prevent completion from discovering that you have GNU
> make; which in turn will cause it to parse the Makefile directly.
> You lose completion of any targets that are availble only via
> recursive makes, and it'll miss GNUmakefile files, but it should run
> a lot faster.

I guess.  make sucks---it really ought to be easy, somehow, to get at
a plausible list of targets.

Re: `make' completion in zsh-3.1.9

[Andrew Morton]

Bart Schaefer wrote:
> 
> On Mar 18,  2:13am, Andrew Morton wrote:
> } Subject: `make' completion in zsh-3.1.9
> }
> } /usr/src/linux> make menu<tab>
> }
> } the shell locks up for about ten seconds, recurring into every
> } directory of the kernel tree doing *something*.  Finally,
> } it comes back with `make menuconfig'.
> 
> It's running "make -nsp --no-print-directory -f Makefile .PHONY" to cause
> make itself to output the list of possible completions.  I don't know why
> this would be taking 10 seconds or more -- it finishes in 1 second or so
> on my machine.

Oh I see.  `make -nsp' takes a very long time to complete in the top level of
the kernel tree.  It produces 34 megabytes of output.

zsh-3.1.6 does this:

	awk /^[a-zA-Z0-9][^\/ \t]+:/ {print $1}

to find potential targets in the makefile, whereas 3.1.9 does this:

    if [[ -n "$_is_gnu[$words[1]]" ]]; then
      	< make -n stuff >
    else
        <awk '/^[a-zA-Z0-9][^\/\t=]+:/ stuff>

And the 3.1.9 behaviour actually doesn't work properly - it
matches things which can't possibly be built from this directory
such as floppy.c

Ho hum.  I'll just edit /usr/share/zsh/3.1.9/functions/User/_make
and put it back the old way.

Thanks.

Re: `make' completion in zsh-3.1.9

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> } Anything that's producing that amount of output is going to take a
> } little while to run.
> 
> Yes, I'll say.  You might try
> 
>     zstyle ':completion:*:make:*:version' command :
> 
> which will prevent completion from discovering that you have GNU make;
> which in turn will cause it to parse the Makefile directly.  You lose
> completion of any targets that are availble only via recursive makes,
> and it'll miss GNUmakefile files, but it should run a lot faster.

I've mentioned the (new) _make behaviour at least twice here,
objecting to it.  For me it was even worse: I had updated zsh from
CVS, which changed some .in files.  I did `make t<TAB>' in the main
zsh directory and that caused it to call autoconf and re-compile the
shell.

I wrote about this but got no reply from whoever put that code into
_make (I'm too lazy to look it up now).  I really think we should
either make it run make only if some style is set or come up with a
better test when to run it (or, probably better, a combination, where
the test decides what the default for the style should be in a
particular situation on a particular system).

At least we shouldn't let it out of the door in a state where people
might have to set a barely documented style to keep it from doing such 
horrible things.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de