bugGNU Octave - Bugs: bug #48101, After changing m-file...

 
 

bug #48101: After changing m-file documentation, build system relinks liboctave, liboctinterp, etc.

Submitter:  Rik <rik5>
Submitted:  Thu 02 Jun 2016 05:19:56 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 03 Jun 2016 09:32:42 PM UTC, comment #8: 

I checked in the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/7b0436d0f5be

Now "make dist" should not fail but will warn if the configure option --disable-hg-id was used.  The build summary message printed by make will also show the hg id.  There is also a warning if the build is not from mercurial (no .hg directory) and the HG-ID file contains "hg-id-disabled".

John W. Eaton <jwe>
Group administrator
Fri 03 Jun 2016 03:40:53 PM UTC, comment #7: 

Yeah, I was wondering about the namespace hit with the existing Automake option.

I'm fine with a --disable-XXX option.  Shouldn't it be '--disable-hg-id' to be perfectly clear?  Our version control system is hg, and the file is HG-ID.

In addition, I propose that there be no restriction on 'make dist'.  This configure option is only for experts and it is not likely to be invoked accidentally.  Of course, I'm being somewhat selfish here as I want to avoid the constant re-builds, but I also use 'make dist' to make tarballs which I then feed to MXE octave.  It's annoying to have to re-configure every time I want to build an MXE version.  If jwe is concerned about accidentally creating a release without the embedded HG-ID then maybe it is enough to have the build process issue a warning.  A requirement for release would then be that a grep through the make log showed no warnings.

Rik <rik5>
Group administrator
Thu 02 Jun 2016 10:20:46 PM UTC, comment #6: 

Hm, I may try to rename this from --enable-maintainer-mode to something more clear like --disable-vcs-id if there are no objections. I don't think it's a clear implication that --enable-maintainer-mode means you don't want the hg revision, plus this option is overloaded from an automake option of the same name that does something completely different.

Mike Miller <mtmiller>
Group Member
Thu 02 Jun 2016 10:01:09 PM UTC, comment #5: 

I checked in the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/418b6066e544

John W. Eaton <jwe>
Group administrator
Thu 02 Jun 2016 07:56:30 PM UTC, comment #4: 

That seems like a cute hack.  The HG-ID will then be static and won't trigger the Makefile rule.

Rik <rik5>
Group administrator
Thu 02 Jun 2016 07:24:45 PM UTC, comment #3: 

How about if we wrote "maintainer-mode" to the HG-ID file if Octave is configured with --enable-maintainer-mode?

John W. Eaton <jwe>
Group administrator
Thu 02 Jun 2016 07:16:38 PM UTC, comment #2: 

I haven't been following the hg ID issue.  Is there a way to potentially disable it for maintainers, or only embed it when running 'make dist'?

It's nice when the code-compile-test loop is as short as possible.

Rik <rik5>
Group administrator
Thu 02 Jun 2016 06:44:58 PM UTC, comment #1: 

If you make any change that alters the hg ID, then the build-info.cc files will change and need to be recompiled which causes the shared library files to be relinked.

I don't see a way to fix that and still embed the hg ID in the libraries.

Storing the hg ID in separate files outside of the binaries would solve the recompiling problem but would not be as reliable for identifying screwed up installations in which people are running with incorrect or mismatched library versions.

John W. Eaton <jwe>
Group administrator
Thu 02 Jun 2016 05:19:56 PM UTC, original submission:  

The build system seems to go overboard and relink the main libraries such as liboctave, liboctinterp, liboctgui whenever a documentation change is made in the scripts/ directory.  This also causes all the DLDFCNs to be re-linked.  This seems unnecessary.

Steps to Reproduce:


edit scripts/miscellaneous/ls.m and make a small change to the documentation
make -j4 all |& tee mymake.log


The logfile is attached.

Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #37359:  mymake.log added by rik5 (10KiB - text/x-log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-06-02 jwe StatusNone Fixed
        Open/ClosedOpen Closed
    2016-06-02 rik5 Attached File- Added mymake.log, #37359

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code