path handling

[John W. Eaton]

In a discussion that started yesterday on the bug list, I proposed
eliminating the implicit recursive path handling (special treatment of
trailing // in path elements).  Removing this magic would simplify the
path searching code and make the load path idea a bit more transparent
to users.  It would also enable better control of the order of
searching which could be useful for packages.

If you do want to add an entire directory tree to the path but you
don't want to list the contents by hand and you don't care about the
precise search order of subdirectories in the tree, you will be able
to do it with the new function genpath (which we also need for 
compatibility).  For example,

  addpath (genpath ("~/octave"));

adds everything in ~/octave to the front of the search path.

Setting up the default search path when Octave is built and installed
is not a big problem.  We can just build a static list of directories
that will be created by "make install" and generate a path.  For
compatibility, we should have a pathdef function that returns this path.

The disadvantage of these changes is that the list is static.
Currently, if you have Octave running and add a directory in one of
the trees that is searched recursively, Octave will automatically find
it.  If we eliminate automatic recursive searching, you would have to
explicitly add the directory to the search path before files would be
found there.

If we have a package manager, how should it add directories to the
path so that the package will be useful immediately and so that the
package will be found the next time Octave starts?  Where and how
should that information be stored?

Hmm.  This is a bit of a mess.

Comments?

jwe