octave-maintainers
[Top][All Lists]
Advanced

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

Re: Unexpected behavior of "configure" "make" and __osmesa_print__.cc


From: Ben Abbott
Subject: Re: Unexpected behavior of "configure" "make" and __osmesa_print__.cc
Date: Sun, 26 Jul 2015 20:35:01 -0400

> On Jul 26, 2015, at 12:13 PM, Mike Miller <address@hidden> wrote:
> 
> On Sun, Jul 26, 2015 at 12:00:35 -0400, Ben Abbott wrote:
>> $ hg id
>> 31f89b12aaf7+ tip @
>> 
>> Configure did not find my osmesa
>> 
>> configure:77609: WARNING: OSMesa library not found.  Offscreen rendering 
>> with OpenGL will be disabled.
>> configure:77804: 
>> configure:77806: NOTE: Libraries or auxiliary programs may be skipped if 
>> they are
>> configure:77808: NOTE: not found OR if they are missing required features on 
>> your
>> configure:77810: NOTE: system. 
>> 
>> However, “make” still compiles __osmesa_print__.cc
> 
> I suspect it's compiled but mostly #ifdef'd out. So the function
> __osmesa_print__ is probably callable from the shell, but it should
> print something like
> 
>>  GEN      doc/interpreter/voronoi.eps
>> error: __osmesa_print__: support for offscreen rendering was disabled when 
>> Octave was built
>> error: called from
>>    __opengl_print__ at line 171 column 7
>>    print at line 431 column 14
>>    geometryimages at line 55 column 5

Ok. That should have been obvious to me ;-)

> The only bug here is that building the documentation now unconditionally
> relies on osmesa.
> 
> I think like I replied in the other thread, I think it might be
> worthwhile to fix the doc/interpreter/*.m scripts to do something like
> 
>  if (! octave_config_info.HAVE_OSMESA)
>    graphics_toolkit ("gnuplot");
>  endif

I like this idea, but I don’t think there is a HAVE_OSMESA field. Would …

        octave_config_info.features.OSMESA && 
octave_config_info.features.OSMESA_H

… work? hmmm, that might not work with —with-osmesa if building 
__osmesa_print__.cc failed.

Maybe adding a try-catch and unwind_protect block to print.m would work? 
Something like below ...

   ## call the graphics toolkit print script
    toolkit = get (opts.figure, “__graphics_toolkit__”);
    switch (toolkit)
      case "gnuplot"
        opts = __gnuplot_print__ (opts);
      otherwise
        try
          opts = __opengl_print__ (opts);
        catch
          unwind_protect
            set (opts.figure, “__graphics_toolkit__”, “gnuplot”)
            opts = __gnuplot_print__ (opts);
          unwind_protect_cleanup
            set (opts.figure, “__graphics_toolkit__”, toolkit)
          end_unwind_protect
        end_try
    endswitch

There should be a warning given the first time the try-block triggers the 
catch. Are there any other problems?

Ben





reply via email to

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