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

[John W. Eaton]

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

I checked in your changes to add fftwf_version to __octave_config_info__. 
Thanks.

It's not the HG-ID target being tagged with .PHONY that is causing the
trouble.  There are move-if-change rules to prevent further action if there
are no changes to the build-info.cc source file.

The problem is that we are now putting the build time into the source file. 
So that will always change and I see no simple way to fix that.

If you use __TIME__ and __DATE__ as you did before, those could be
signifcantly different from the actual last build time if your hg id wasn't
changing.  For example, if you were working on some changes and your hg id was
always SOMETHING+ (you aren't checking in any changes) but you are repeatedly
building.  Then the "build time" would not change because the source file with
the __TIME__ and __DATE__ would not change.

If you change %OCTAVE_BUILD_TIME% to 0 in libinterp/build-info.in.cc, then run
make a few times you should see what I mean.  HG-ID and build-info.cc will be
generated, but build-info.cc shouldn't change so no compiling or linking
should happen either.

If we use __TIME__ and __DATE__ as you did before, then the timestamps
recorded in the object file could be signifcantly different from the actual
last build time if your hg id wasn't changing.  For example, if you were
working on some changes and your hg id was always SOMETHING+ (you aren't
checking in any changes) but you are repeatedly building.  Then the "build
time" would not change because the build-info.cc source file with the __TIME__
and __DATE__ macros would not change, so would not be recompiled.

Do we really want build time and date embedded in a source file?  Is this
really a Matlab compatibility issue?  Who cares?  The more important info is
the HG ID.

Maybe just record the build time in a text file somewhere and have Octave read
it at startup?  Maybe just edit into the version.m file directly?

But I still think that it would be useful to have the hg id stored in
liboctave, libinterp and possibly libgui so that we can ensure that the
libraries are consistent and the ones that are expected.

    _______________________________________________________

Reply to this item at:

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

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