Re: Implementation of convn

[Søren Hauberg]

man, 24 03 2008 kl. 17:56 -0400, skrev John W. Eaton:
> | Don't we have "private" directories now? I would think all __functions__
> | should be moved to "private" directories.
> 
> We could do that for .m files relatively easily, though it would
> require some changes to the Makefiles (and possibly the layout of the
> sources).
> 
> But doing this for .oct files is not as easy.  The rule for functions
> in private directories is that they are only visible to the functions
> in the parent directory.  But generally all .oct files live in the
> same architecture dependent directory tree, separate from the
> architecture independent .m files.  For example,
> 
>   /usr/share/octave/3.0.0/m/polynomial
>   /usr/lib/octave/3.0.0/oct/x86_64-pc-linux-gnu
> 
> If you put your convn.m file in /usr/share/octave/3.0.0/m/polynomial,
> functions that are "private" for it belong in
> 
>   /usr/share/octave/3.0.0/m/polynomial/private
> 
> but that is is an architecture independent directory, so it is not the
> right place for a .oct file.
> 
> I don't see a good solution for this problem.

I'm not in anyway claiming to understand all the issues here (or rather:
I don't understand them at all), but I see two things that might be
helpful.

1) We might want to auto-add "x86_64-pc-linux-gnu" directories to the
path. That is, if we add "/some/path" to the path, then the files in
"/some/path/x86_64-pc-linux-gnu" should also be available. For
"private" directories files
in "/some/path/private/x86_64-pc-linux-gnu" would also be private. 

2) Perhaps we want a top-level private directory. That is, a directory
containing functions that are available to other functions distributed
with Octave, but not directly available to the user.

Anyway, since I don't really understand the issues here, this mail just
qualifies as brain-farting...

Soren