bugGNU Octave - Bugs: bug #37541, fltk-related defuns should be...

 
 

bug #37541: fltk-related defuns should be built even without fltk support

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Thu 11 Oct 2012 02:17:15 AM UTC  
 
Category:  Configuration and Build System Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 12 Oct 2012 02:49:58 AM UTC, comment #5: 

I checked in a changeset that moves the docstrings out of the #ifdef statements (http://hg.savannah.gnu.org/hgweb/octave/rev/b9b9795a7cd9).  Hopefully there can't be much more needed for RHEL support.

Rik <rik5>
Project Administrator
Thu 11 Oct 2012 08:10:02 PM UTC, comment #4: 

That's a good fix, now at least it won't show up in available_graphics_toolkits(), and yes we can catch the error in graphics_toolkit() if the init function doesn't exist.

The trouble with the DOCSTRINGS files is if they change depending on the build options. If the DOCSTRINGS are rebuilt, this causes a chain reaction of make dependencies that rebuilds everything under doc/interpreter, even though the difference doesn't really affect the end product in this case. Also, if I run "make dist" after having configured without FLTK, the DOCSTRINGS in the release are different than if I had configured with FLTK.

This is somewhat related to #37542, the overall theme being wouldn't it be nice if make didn't have to do any unnecessary work in the doc directory after extracting the release? We are already mostly there.

Mike Miller <mtmiller>
Project Administrator
Thu 11 Oct 2012 06:30:10 PM UTC, comment #3: 

OK, the list of available toolkits is built with PKG_ADD commands.  Those are extracted from source files unconditionally.  So I guess we need a way to not add the register_toolkit line from _init_fltk_.cc if fltk is not available.  How about the following change?

http://hg.savannah.gnu.org/hgweb/octave/rev/dca1f2bcccf3

The error about _init_fltk_ not found is expected, though the error message could be better.  Maybe the graphics_toolkit function should catch that error and produce a better message.

What trouble does it cause if internal functions are missing but the docstrings for them appear (or not) in the DOCSTRINGS file?  As Rik said, these are internal functions.

John W. Eaton <jwe>
Project Administrator
Thu 11 Oct 2012 04:56:07 PM UTC, comment #2: 

Thanks for the feedback Rik.

I don't see any error handling that you are describing at a higher level, for example here's what I see when I build with no FLTK:

octave:1> available_graphics_toolkits
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
}
octave:2> graphics_toolkit fltk
error: feval: function '__init_fltk__' not found
error: called from:
error:   /home/mike/src/octave/default/scripts/plot/graphics_toolkit.m at line 66, column 5

Point taken, this could be handled in the graphics_toolkit() function.

Another reason, though, (and this could certainly qualify as nitpicking :)) is to ensure that the DOCSTRINGS files are identical in every build no matter how configure was invoked. Currently, these FLTK internal defuns are the only difference I see when I build with everything enabled and with nothing enabled (--disable every possible option).

Here are some examples of other internal defuns that are compiled even with their corresponding optional dependencies disabled: __delaunayn__, __glpk__, __magick_read__, __magick_write__

If you want to keep the FLTK conditional as is, is there any reason to keep internal functions in the built DOCSTRINGS files? They are filtered out by mk_doc_cache, could they be filtered out at an earlier stage?

Mike Miller <mtmiller>
Project Administrator
Thu 11 Oct 2012 03:31:18 PM UTC, comment #1: 

The prefix "__" is a mark that these functions are internal and I don't think they need to be compiled when HAVE_FLTK is not defined.

The behavior that you are talking about, displaying an error if a specific functionality is not available, is already present in non-internal, user-visible functions such as graphics_toolkit().

Rik <rik5>
Project Administrator
Thu 11 Oct 2012 02:17:15 AM UTC, original submission:  

When building with or without fltk support, some internal fltk-related defuns are either built or not. I think the correct behavior is to always build them and just report an error if HAVE_FLTK is not defined.

Here is the list of defuns that are not compiled without fltk:

  • _fltk_uigetfile_
  • _init_fltk_
  • _fltk_redraw_
  • _fltk_maxtime_

I can certainly make this fix if no one gets to it before me. Either way, I'll leave this open for at least a few days in case anyone wants to disagree.

Mike Miller <mtmiller>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-10-12 rik5 StatusNone => Fixed
        Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.5