[Octave-bug-tracker] [bug #45659] version function: options and return values supported by Matlab

[John W. Eaton]

Follow-up Comment #13, bug #45659 (project octave):

Thanks for working on this.

Instead of adding a new function to return the release date, wouldn't it be
sufficient to just add the release date to the octave_config_info structure?

I'd rather include header files to provide function declarations instead of
inserting them by hand (your extern decl for oct_hg_id) in toplev.cc.  So
instead of generating the header file, why not make that static and generate
the source file instead?  Then toplev.cc could include build-info.h (which
won't change with each change to the hg id) and the hg ID can be substituted
into the build-info.cc file.

After thinking about it a little more, and also encountering numerous times
when bugs are reported and we aren't sure whether the correct versions of
libraries are being used, I think it might be useful to have version functions
defined in each library (liboctave_version, libinterp_version, and
libgui_version).  Then the octave_config_info could contain fields for each of
these.  If things are working properly, each of these should return the same
result.  But if there is some build problem, we could detect that there is a
library version mismatch and at least warn about it.

Also, a small comment about commit messages.  Instead of writing "Add this or
that ...", please write things like


* build-info.in.h, build-info.cc: New files.
* mk-build-info-h.in.sh: New script.
* configure.ac, Makefile.am: Update.
* module.mk (update_hg_id, libinterp/build-info.h): New rules.
* defaults.cc (FOCTAVE_RELEASE_DATE): New function.
* version.m: Also return release date.
* toplev.cc (F__octave_config_info__): New field, hgid.



    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/