On Sun, Mar 25, 2012 at 4:58 PM, c. <carlo.defa...@gmail.com> wrote:
>
> On 25 Mar 2012, at 14:26, Juan Pablo Carbajal wrote:
>
>> function dir = pkg_dir(name)
>> [local_packages, global_packages] = pkg("list");
>> installed_pkgs_lst = {local_packages{:}, global_packages{:}};
>>
>> installed_names = cellfun (@(x) x.name,
>> installed_pkgs_lst,'uniformoutput',false);
>> [tf idx] = ismember (name,installed_names);
>>
>> dir = [];
>> if tf
>>   dir = installed_pkgs_lst{idx}.dir;
>> end
>> endfunction
>
> I don't think this completely solves the issue we are dealing with,
> if all files are installed in the same path a PKG_ADD file like this:
>
> http://geopdes.svn.sourceforge.net/viewvc/geopdes/trunk/geopdes_base/PKG_ADD?revision=456&view=markup
>
> should already be enough to deal with the problem.
> the problem is that the installation path for architecture dependent and 
> indepent file could be
> completely different. I think this is for example the case in the default 
> configuration for Octave on
> Debian and o widows.
>
> you can check that with
>
> pkg ('prefix')
>
>

Carlo,
Yes, this is exactly the solution for the PKG_ADD in geometry
http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/main/geometry/PKG_ADD?revision=10052&view=markup

The problem is that the information in pkg("prefix") doesn't survive
across octave sessions. We could store it somewhere. I suggest the
~/.octave_packages file. Is it there exactly for this?


-- 
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

Reply via email to