On Sun, Mar 25, 2012 at 12:43 PM, c. <carlo.defa...@gmail.com> wrote:
>
> On 24 Mar 2012, at 23:06, Juan Pablo Carbajal wrote:
>
>> On Sat, Mar 24, 2012 at 10:02 PM, Clemens Buchacher <dri...@aon.at> wrote:
>>> On Sat, Mar 17, 2012 at 01:42:19PM +0100, Juan Pablo Carbajal wrote:
>>>> On Sun, Mar 11, 2012 at 12:56 PM, Clemens Buchacher <dri...@aon.at> wrote:
>>>>> Hi Juan,
>>>>>
>>>>> Version 1.4.0 of the geometry package produces the following warnings on
>>>>> load:
>>>>>
>>>>> warning: addpath: /usr/lib/octave/packages/geometry-1.4.0/geom2d: No such
>>>>> file or directory
>>>>> warning: addpath: /usr/lib/octave/packages/geometry-1.4.0/io: No such
>>>>> file or directory
>>>>> warning: addpath: /usr/lib/octave/packages/geometry-1.4.0/polygons2d: No
>>>>> such file or directory
>>>>> warning: addpath: /usr/lib/octave/packages/geometry-1.4.0/shape2d: No
>>>>> such file or directory
>>>>> warning: addpath: /usr/lib/octave/packages/geometry-1.4.0/octclip: No
>>>>> such file or directory
>>>>> warning: addpath: /usr/lib/octave/packages/geometry-1.4.0/graphs: No such
>>>>> file or directory
>>>>>
>>>>> This happens only if I install with different prefixes:
>>>>>
>>>>> pkg prefix /usr/share/octave/packages /usr/lib/octave/packages
>>>>
>>>> This is fixed for me. Could you double check?
>>>
>>> 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").
>>>
>>> Clemens
>>
>> How does pkg knows the path to add in any other package when you use
>> prefix? I see ocs is having the same problem... probably all
>> multi-packages using PKG_ADD have it.
>>
>> We could use the NEWS file or maybe the documentation to get the
>> installation path of the package...I do not see how to od it for an
>> arbitrary prefix in the arch dependent files....
>>
>> Ideas?
>>
>> PS: I am adding Carlo and Rik to the discussion. Since this may be
>> something to tackle more generally.
>
> Adding subdirectories is not done by pkg.m upon installation but it is rather
> left to the package developer to take care of this in the PKG_ADD scripts
>
> The logic in PKG_ADD in "geometry" and "ocs" is correct in case of a local
> install
> but not in case of a global install.
>
> I see 3 possibilities to fix this:
>
> 1 - change the PKG_ADD in the packages
>
> 2 - patch pkg.m to handle subdirectories in a better way
>
> 3 - forbid the use of subdirectorues in packages
>
> I personally don't like the third solution, what would you prefer?
>
> c.
>
>
Hi Carlo,
Thank you very much for the answer.
I am definitely against option 3, since packages with subdirectories
(or multipackages, as I call them) are really handy when joining
different atomic packages (like geom2d, svg and octclip into
geometry). Additionally, the idea of "module" is well represented by a
subfolder (like in ocs). If this is not intelligent for some reasons I
can't foresee, then I will be happy to reconsider option 3): no
multipackages allowed.
The solution Clemens is suggestion goes into the lines of option 1)
modify PKG_ADD. Probably is the best way to go, but can produce a lot
of headaches for package developers. We could avoid that by providing
a standardized way of doing this (as Clemens suggest), but in that
case we could move that standard solution to pkg.
What I have in mind is something like the database that gen_doc_cache
generates. Maybe pkg could maintain such a database with the folders
where the packages where installed? This will improve the way
pkg("list") generates the folder list, and maybe add a column to the
output indicating "Arch dependent folder" or something like that.
There is already a ~/.octave_packages file, we could just store the
folders according to the output of pkg("prefix").
So I am up for option 2., by improving the part of pkg that generates
~/.octave_packages. What do you think?
Cheers,
JPi
--
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/
------------------------------------------------------------------------------
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
