Re: "features" problems

[PhilipNienhuis]

John W. Eaton wrote
> On 03/10/2016 05:30 PM, Carnë Draug wrote:
>> On 10 March 2016 at 22:21, John W. Eaton <

> jwe@

> > 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.

In the OF io package, octave_config_info() isn't just called to check for
built-in JAVA.  It is also used to e.g., check for 64-bit indexing builds. 
What would be the preferred way to check that?

Yesterday I uploaded io-2.4.1 to the package release tracker, it is (as
regards dev Octave) based on a.o. the current state of octave_config_info.
io-2.4.1 works fine with stable (its main "audience"), but reading up here I
envision its lifetime with the development branch to be a little short.
So should we expect still more octave_config_info changes? 

For my own good I'd suggest to keep octave_config_info around, and
non-=private, for a little bit longer.... :-)
It provides a great and easy way to check for various info about the build
environment of the Octave at hand, and also it often serves as a very useful
debugging aid.

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/features-problems-tp4675361p4675373.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.