[Octave-bug-tracker] [bug #53856] MEX file in a private directory of a class

[John W. Eaton]

Update of bug #53856 (project octave):

                  Status:               Confirmed => In Progress            

    _______________________________________________________

Follow-up Comment #13:

I stlil can't explain why the .m file would be called if the mex file already
exists.  But for the case of compiling the mex file after the m file has
already been executed once, I think there are two problems.

First, we weren't looking at the timestamp of the private directory, so the
load path was not updated if the private subdirectory changed.  This changeset
should fix that problem:

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

I am able to see a difference with the __dump_load_path__ function. 
Previously, after compiling the .mex file, the private function map still had
the .m file.  Now it will be updated to show the .mex file instead.

Second, the function out_of_date_check in symtab.cc doesn't check to see
whether a .oct or .mex file has appeared when checking whether a .m file is
out of date.  I don't have a fix for that yet because I don't know whether
that check is always appropriate in the out_of_date_check function or if it
should be done separately (or possibly that the entire logic here should be
revamped).

However, with the first changeset above, the following now works for me when
it previously failed:


addpath ("/path/to/mex_private")
tst_privfcn  ## calls .m file
cd /path/to/mex_private/private
mex myprivfcn.c
cd /some/where
tst_privfcn  ## still calls .m file
clear functions
tst_privfcn  ## now calls .mex file


Previously, the clear functions command had no effect because the load path
was never updated.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53856>

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