Re: "features" problems

[Philip Nienhuis]

Carnë Draug wrote:
> On 19 March 2016 at 00:04, PhilipNienhuis <address@hidden> wrote:
> > Carnë Draug wrote
> > > There may be a very limited set of things, currently in
> > > octave_config_info,
> > > that we can make public.  We should decide which ones.  Some can be tested
> > > easily at runtime and already functions to do it (java and image io for
> > > example).  I have started a list of those at the wiki [1].
> > >
> > > Which ones are tricky to test at runtime and should be exposed outside
> > > core?
> >
> > [...]
> >
> > A little issue with the __have_feature__ method is that it isn't possible
> > (or I have missed something) to find out e.g. , api version, or arch, or
> > libdir. The io package makes use of that info as well.
> > Of course workarounds can be thought up but they seem less robust to me than
> > directly querying octave_config_info() or __octave_config_info__()
>
> Why do you need api_version and libdir in the first place?  Those
> would be among the ones that I'd guess should not be made public.

Why should it not be public?

IMO it's entirely up to users and esp. developers to determine what to 
do with this sort of info. It is there so why not make use of it if 
there is a clear need. I was glad it was so easy to get and use it.
Obviously it's at the main developers discretion to select what info may 
be public but I find it akin to pedantic to withhold very useful and 
reliable configuration & system info from other developers (e.g., OF 
package developers).
As regards plain users I can follow. But to set up add-on software for 
use with Octave, other than Octave's build dependencies, such info is 
often indispensable.

In the io package libdir is used in a.o., chk_spreadsheet_support.m to 
find subdirs where Java class libs can be found. Some Linuces put those 
in /usr/bin or its subdirs.

api version + other info like canonical_host_type is currently needed to 
find out where the arch-dependent package modules are located; 
post_install.m uses it to move PKG_ADD around. The underlying issue 
(invoking functions before all of the package has been loaded) has been 
discussed here or in the bug tracker a while ago but no solution emerged.

> You can get arch (I'm assuming you meant arch of the host --- beware of
> cross compiling) using computer ().

Please, I know about ispc/isunix/ismac. See above fro some of the info I 
(and a.o., the io package) use.

Philip