Re: octave-image requires c++11

[Carnë Draug]

On 30 July 2015 at 22:50, Orion Poplawski <address@hidden> wrote:
> On 07/30/2015 12:15 PM, Carnë Draug wrote:
>> On 30 July 2015 at 04:57, John W. Eaton <address@hidden> wrote:
>>> On 07/29/2015 10:48 PM, Orion Poplawski wrote:
>>>>
>>>> It appears that octave-image 2.4.0 requires c++11:
>>>>
>>>> checking whether g++ supports C++11 features by default... no
>>>> checking whether g++ supports C++11 features with -std=gnu++11... no
>>>> checking whether g++ supports C++11 features with -std=gnu++0x... no
>>>> checking whether g++ supports C++11 features with -std=c++11... no
>>>> checking whether g++ supports C++11 features with -std=c++0x... no
>>>> configure: error: *** A compiler with support for C++11 language
>>>> features is required.
>>>>
>>>> While I can very much sympathize with wanting to have progress, just
>>>> note that it is a bit trickier (though not impossible) to get access to
>>>> a C++11 compiler on RHEL6.  Just something I wanted to note.
>>>
>>>
>>> Yeah, I'm not a fan of this choice either.  At the very least, it would be
>>> helpful to provide some kind of fallback code.  Or, if that causes too much
>>> of a maintenance burden, then it would be much better to only disable those
>>> features that actually require C++11 and at least allow a subset of the
>>> package to build.
>>>
>>
>> I don't see the point of coding a workaround.  I might as well use only the
>> workaround then.  It is possible to code without std::function, I did that
>> for a while, but it makes the code messier and I'm not interested on that.
>>
>> At the moment, C++11 is mainly used by connectivity class, which is a C++
>> class for the image package, not a function.  It is used by:
>>
>>   * bwlabeln
>>   * bwlabel
>>   * bwperim
>>   * bwconncomp
>>   * imreconstruct
>>   * watershed
>>   * conndef
>>   * iptcheckconn
>>   * bwfill
>>
>> These functions then get used by:
>>
>>   * regionprops
>>   * bwboundaries
>>   * bwpropfilt
>>   * imregionalmax
>>   * imregionalmin
>>   * bwmorph
>>   * bwclearborder
>>   * bwselect
>>
>> There are other functions which then make use of these.  Not having C++11
>> will disable a large chunk of the image package, pretty much all of the
>> mathematical morphology functions.  And I don't think a function needs to
>> be aware that one of its dependencies needs C++11 to work properly.
>> It's not a function that needs it, it's one of the classes of the package.
>>
>> It appears that the minimum required gcc version is 4.5.  That was released
>> more than 5 years ago.  Both latest stable debian and centOS releases
>> support it so I don't think it's a bad target.  Anyone with older systems
>> can:
>>
>>   1) install an older version of the image package;
>>   2) revise their need for the image package 2.4;
>>   3) upgrade their distribution;
>>   4) build a newer gcc themselves;
>>   5) employ someone to code a workaround for them.
>
> So I managed to compile octave-image without too much trouble using the gcc
> 4.9.2 compiler provided by the devtoolset-3 SCL.  However, I'm a little
> worried about having octave and octave-image compiled with different
> compilers.  Is there a test-suite for the image package that I could run?
>
> Thanks,
>   Orion

You can do the following:

  pkg load image;
  runtests (path_to_the_inst_directory_inside_the_released_tarball)
  runtests (path_to_the_src_directory_inside_the_released_tarball)

Unfortunately, not all functions have tests.

Carnë