|
From: | Philip Nienhuis |
Subject: | Re: "features" problems |
Date: | Sat, 19 Mar 2016 22:06:49 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 |
Carnë Draug wrote:
On 19 March 2016 at 00:04, PhilipNienhuis <address@hidden> wrote:Carnë Draug wroteThere 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
[Prev in Thread] | Current Thread | [Next in Thread] |