Re: Default fpath

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote:

> ...
> 
> The initial fpath contains the Debian and Linux directories despite the
> fact that I always remove them after installation. I get rid of them
> with the (N) but I don't think they should be there. I suppose that in
> the longer term, we'll have to add configure-time checks for these and
> other operating systems we might have functions for. 

We plan to cleanup the directories before release anyway -- every
suggestion about things will then be welcome, I think.

(The Linux/Debian stuff is a bit of a problem anyway, because the
files in it are not only useful on linux/debian systems, I think.)


Bart Schaefer wrote:

> ...
> 
> This gives me an idea ... it ought to be possible to point autoload (or
> some new builtin) at a zcompiled digest file and have it mark all the
> functions therein for autoloading.  That way, you could (once) select
> the functions to compile into the digest, then simply add the digest to
> your $fpath and issue a single autoload command.  (Note 1)

Nice idea...

> ... [ big snip, no strong opinions on that ]
> 
> } The obvious solution is to have a variable which is set when zsh first
> } runs such as $ZSH_FUNCTIONS. In fact, it might be better in the longer
> } term to have an associative array which points to any compile-time
> } defined directories. So we would have something like:
> } ZSH_INSTALL[functions]=/usr/local/share/zsh/$ZSH_VERSION/functions
> } ZSH_INSTALL[lib]=/usr/local/lib/zsh/3.1.6-dev-19
> } ZSH_INSTALL[share]=/usr/local/share/zsh
> } etc.
> 
> That's a reasonable idea, though (other than "functions" and maybe "lib")
> I can't decide what the standard set of key names should be.  I dislike
> the idea of following the autoconf naming convention; I don't really
> think bindir, datadir, infodir, etc. are especially useful.

Agreed.

> ...
> 
> Note 1 -- While we're on the topic of zcompile, it could use:
> (1) a way to append to an existing .zwc, rather like `ar' works, and

That's a bit problematic because of the little/big-endian thing. I.e. we
can't just append to a wordcode file (and I don't want to have
multiple headers). But of course we could make it read/change/re-write
such files, also allowing deletion of functions. Is it worth it? I
mean, creating wordcode files is quite fast for me...

> (2) an option to say whether each function should be autoloaded zsh-style
>     or ksh-style, so that the right thing happens regardless of the run-
>     time setting of kshautoload.)

But currently it is the same as for loading from a normal file,
wouldn't it probably be confusing if the wordcode file said how to
load it? But don't get me wrong: I never use kshautoload, so I
wouldn't be against allowing it. Per-function or per-wordcode file?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx