octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #45659] version function: options and return v


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #45659] version function: options and return values supported by Matlab
Date: Thu, 07 Apr 2016 08:22:23 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0

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

I removed the build date and time from version.m.

The output of version for the attached patch is now:

>> version
ans = 4.1.0+
>> [v,d]=version
v = 4.1.0+
d = 2015-05-26


The date is returned as stored in OCTAVE_RELEASE_DATE. Thus, it is formatted
differently from what Matlab returns ("yyyy-mm-dd" instead of "mmmm d, yyyy").
Should I reformat with datestr for maximum compatibility?

The ___octave_config_info___ struct now has a new field "hgid" holding the hg
id.

>> __octave_config_info__.hgid
ans = 3b9524234d89+


The only file that has to be rebuild when the hg id changes is the new
build-info.cc with its generated header.

I left the functions exposing the build date and time and the hg id directly
to Octave intact for whom it might interest. My reasoning was that they can
reside in the same file that has to be re-build anyway. However, date and time
are only updated when build-info.cc is build (e.g. when it has to be re-build
to update the hg id).
If it is agreed upon that these are not needed, I am OK with removing them.

Instead of making the header file holding the hg id directly a phony target, I
took the following approach to keep the build time as efficient as possible:
- store the current hg id in a text file
- generate the header file that stores the hg id
- keep the function exposing the hg id in a seperate file
On subsequent calls:
- use a phony target that compares the current hg id with the one stored in
the file. Only if the hg id has changed:
 * overwrite the text file with the current hg id
 * generate the header file that stores the hg id

Thus, on subsequent builds of the same revision (only local changes), nothing
hg id related has to be rebuild. On updates of the hg id, only one additional
object has to be rebuild (and linked).

Are you OK with these changes?

(file #36853)
    _______________________________________________________

Additional Item Attachment:

File name: version_beta2.patch            Size:10 KB


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]