octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "features" problems


From: Carnë Draug
Subject: Re: "features" problems
Date: Fri, 18 Mar 2016 22:20:22 +0000

On 10 March 2016 at 22:42, John W. Eaton <address@hidden> wrote:
> On 03/10/2016 05:30 PM, Carnë Draug wrote:
>>
>> On 10 March 2016 at 22:21, John W. Eaton <address@hidden> wrote:
>>>
>>> [...]
>>> I recently changed the layout of the structure returned by
>>> octave_config_info.
>>>
>>> Instead of writing
>>>
>>>    octave_config_info ("features").JAVA
>>>
>>> I recommend writing
>>>
>>>    __have_feature__ ("JAVA")
>>>
>>> as that will work with the new and old structure layouts.
>>>
>>
>> Should we make use of this private and internal functions outside core?
>>
>> And since octave_config_info() was not a private function, if we want to
>> change this, should we not deprecate "features" first?
>>
>> The whole point of not using a private function is that their behaviour
>> will
>> not change suddenly.
>
> Yeah.  Unfortunately, the layout of the structure returned by
> octave_config_info wasn't very good.
>
> Probably octave_config_info should have been tagged as a "system"/"private"
> function as well.
>
> jwe

I discussed this with jwe and Mike Miller last week.  I think it's important
that this is mentioned here since otherwise I don't think there's public
explanation of the reasoning behind the change.

The reasoning behind this is that we can't ensure Octave will maintain the
configure variables and names over versions.  Most of those names only make
sense in light of the Octave internals that should not be made public.  The
example that makes this the most obvious is the use of:

    octave_config_info ("features").MAGICK

This will tell us whether Octave has support for image reading and writing
(we are currently using graphicsmagick or imagemagick for this).  But we
may change in the future for another library such as cimg and MAGICK will
stop having meaning.

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?

Carnë

[1] http://wiki.octave.org/Cookbook#Find_Octave_configuration



reply via email to

[Prev in Thread] Current Thread [Next in Thread]