Clemens Buchacher wrote:
> On Sat, Mar 24, 2012 at 11:06:57PM +0100, Juan Pablo Carbajal wrote:
>> On Sat, Mar 24, 2012 at 10:02 PM, Clemens Buchacher<dri...@aon.at> wrote:
>>>
>>> With svn r10045, I now get the following on load instead:
>>>
>>> warning: addpath: /home/drizzd/octave/geometry-1.4.2/geom2d: No such file
>>> or directory
>>> ...
>>>
>>> The problem is that the installation prefix is set only during
>>> installation, but not during module load.
>>>
>>> The only way I can find to determine this path reliably is to create a
>>> inst/geometry_module_path.m file which returns mfilename("fullpath").
>>
>> How does pkg knows the path to add in any other package when you use
>> prefix?
>
> The path to the root package directory is added by octave. It is only
> the subdirectories that are not accessible. I have the following other
> packages, and none of those seem to add subdirectories to the
> installation path:
>
> audio communications control data-smoothing general image io linear-algebra
> mechanics miscellaneous nan nnet octcdf optim plot queueing signal specfun
> splines statistics struct symbolic
>
> The io packages seems to parse the installation directory from pkg('list')
> output for different reasons, but I find this quite ugly:
>
> pkglist = pkg ("list");
> javapkgind = find (cellfun(@(x) strcmp(x.name, "java"), pkglist), 1,
> "first");
(no offense taken) What is so ugly about it?
(not that it's my code, yet to me it seems fairly succinct and AFAICS it
works OK)
FYI it doesn't parse package installation dirs at all. It simply handles
a "suggested" dependency on another package, by checking if that other
package is loaded. If so, the rest of PKG_ADD adds entries to the
javaclasspath.
Perhaps I missed the essentials from the discussion, but IMO somewhat
analogous code could be invoked for adding pkg subdirs the "regular"
search path in Octave, including arch-dependent ones. It would put the
responsibility on developers/maintainers, but that's no big deal.
If we let pkg maintainers setup PKG_ADD / PKG_DEL themselves along these
lines, pkg.m could be kept simpler (it is already complicated enough).
Some PKG_ADD/PKG_DEL example stanzas could be put on the OF developers page.
I like the suggested pkg_ind() function, but I would rather have it more
general along the lines of
<info> = pkg_info (<package_name>, [<info_type>])
which would return the entire info structure for just one arg (or [] if
the package isn't found/installed/exist), and e.g.,
<installation_dir> = pkg_info(<package_name>, "dir")
for just one info field.
That would help "de-uglify" the io pkg's PKG_ADD :-)
Philip
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
