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