[Octave-bug-tracker] [bug #64977] Explore options for the bytecode interpreter in Octave 9

[Markus Mützel]

URL:
  <https://savannah.gnu.org/bugs/?64977>

                 Summary: Explore options for the bytecode interpreter in
Octave 9
                   Group: GNU Octave
               Submitter: mmuetzel
               Submitted: Mon 04 Dec 2023 12:15:17 PM CET
                Category: Configuration and Build System
                Severity: 5 - Blocker
                Priority: 5 - Normal
              Item Group: None
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: 9.0.90
         Discussion Lock: Any
        Operating System: Any
           Fixed Release: None
         Planned Release: 9.1.0 (current stable)


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Mon 04 Dec 2023 12:15:17 PM CET By: Markus Mützel <mmuetzel>
During the developer meeting last week, we talked about different options for
how to handle the code for the bytecode interpreter (which is on the stable
branch now) for Octave 9.
We are not sure if all of the new code is platform and compiler agnostic. So,
there is the risk that it could fail to compile on some (obscure) platform or
compiler combinations.

To still allow users on potentially affected platforms to build Octave without
the bytecode interpreter, we talked about the following options:

0. Leave as-is. Don't do anything with respect to the bytecode interpreter on
the stable branch before Octave 9.

1. Re-instate the configuration option that allows to skip compiling the parts
of the code that are required only for the bytecode interpreter. That would
also require to identify those portions of the code and guard them with
preprocessor guards or potentially not building some object files entirely.

2. Revert the changes for the bytecode interpreter on the stable branch and
keep the changes only on the default branch. That would also require to
identify the respective parts. But compared to option 1, they would be removed
on the stable branch (but not the default branch) instead of adding
preprocessor guards around them.

3. Revert the changes for the bytecode interpreter on both the stable and the
default branches and move its development to a feature branch that could be
merged when the bytecode interpreter is deemed to be ready. This would entail
similar edits as for option 2. But they would affect the stable *and* the
default branches.

There might have been more options that I don't recall.

My personal favorite would be option 1.

What do other developers think? Any favorites or alternative options?








    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64977>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/