Juan Pablo Carbajal wrote:
> On Sun, Mar 25, 2012 at 5:16 PM, Philip Nienhuis<pr.nienh...@hccnet.nl>
> wrote:
>> 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
>
> Does this solves the problem with the arch dependent files? I think
> like this you only get the path to the installation of the package but
> not the compiled files, right?
> We need to store this information somewhere at the time pkg("prefix")
> is called. I think ~/.octave_packages could be used for this. It
> already containts the installation folder, we need to add just one
> field to the structure.
For each package (with compiled functions at least) in the file
octave_packages there is already the "archprefix" field, which points to
the compiled functions. It only lacks the last bit to the actual .oct
files (which AFAIU depend on the compiler version), but that can be
gotten from octave_config_info() (I think we need to glue to fields from
that together).
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
