bugGNU Octave - Bugs: bug #53123, build errors...

 
 

bug #53123: build errors "'terminal_reader' in namespace 'octave' does not name a type"

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Sun 11 Feb 2018 09:15:07 PM UTC  
 
Category:  Configuration and Build System Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  Closed
Release:  dev Operating System:  Other

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

( Jump to the original submission)

Mon 12 Feb 2018 05:30:33 PM UTC, comment #6:

https://codesearch.debian.net/

Mike Miller <mtmiller>
Project Administrator
Mon 12 Feb 2018 05:29:42 PM UTC, comment #5:

Thanks for checking. Just for the record, how are you searching?

John W. Eaton <jwe>
Project Administrator
Mon 12 Feb 2018 05:14:57 PM UTC, comment #4:

And this looks fixed to me now.

I just searched pretty widely and no one outside of octave itself is using any of the reader classes, so I agree it is safe to make them disappear rather than deprecating them.

Mike Miller <mtmiller>
Project Administrator
Mon 12 Feb 2018 05:10:14 PM UTC, comment #3:

All of the instances of this error in the wild I found are from "#include <octave/parse.h>" for the eval functions, no one is including input.h directly. The path is parse.h -> lex.h -> input.h.

Mike Miller <mtmiller>
Project Administrator
Mon 12 Feb 2018 03:22:42 PM UTC, comment #2:

I'd prefer to keep those classes hidden, so unless there is some objection, I propose we just remove the typedefs:

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

This also removes the typedef for the octave_input_reader -> octave::input_reader class. If necessary, we can restore that one. But I suspect no one is actually using any of these classes directly anyway. If they are, then they are going pretty deep into Octave internals.

John W. Eaton <jwe>
Project Administrator
Mon 12 Feb 2018 07:16:07 AM UTC, comment #1:

Ran into the same error, confirmed. Not dependent on cross-building or mxe-octave.

The header file lost some classes that are now deemed internal, but still has deprecation aliases declared for these types.

Mike Miller <mtmiller>
Project Administrator
Sun 11 Feb 2018 09:15:07 PM UTC, original submission:

After cset:

f079a0856321 move internal input reader classes out of header file

several OF-packages can be cross-built anymore, yielding compile errors along the lines of:

Philip Nienhuis <philipnienhuis>
Project Member

 

(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 mtmiller (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-12 jwe StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2018-02-12 mtmiller Severity3 - Normal => 4 - Important
        StatusNone => Confirmed
        SummaryMXE / (octave-forge) build errors "'terminal_reader' in namespace 'octave' does not name a type" => build errors "'terminal_reader' in namespace 'octave' does not name a type"

    Back to the top


    Powered by Savane 3.4