bugGNU Octave - Bugs: bug #47745, build fails to rebuild Texinfo...

 
 

bug #47745: build fails to rebuild Texinfo sources until second make all

Submitter:  Mike Miller <mtmiller>
Submitted:  Thu 21 Apr 2016 12:20:38 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 29 Apr 2016 09:26:07 PM UTC, comment #4: 

Solves the problem I reported, thanks.

Mike Miller <mtmiller>
Group Member
Thu 28 Apr 2016 08:53:10 PM UTC, comment #3: 

I checked in the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/09c086133228

With this change, compiling from a tarball should still not rebuild the docs, though the DOCSTRINGS files will be rebuilt (because the .df files are not distributed).  But by using move-if-change, Make should stop at that step and not generate new .texi files.  This will happen each time make runs, but that step is fairly quick so it shouldn't cause too much trouble.

I think the reason for needing to run make twice was the order-only dependence of DOCSTRINGS on .DOCSTRINGS and the fact that the .DOCSTRINGS target could also touch the timestamp of the DOCSTRINGS file.  So the existence of .DOCSTRINGS was sufficient for DOCSTRINGS to be considered up to date on the first run, but the timestamp of the DOCSTRINGS file was also changed.  Make didn't notice that change until the second run.

John W. Eaton <jwe>
Group administrator
Thu 21 Apr 2016 04:48:48 PM UTC, comment #2: 

Marking as confirmed.  I've known about this for a while but didn't get around to reporting it.  In the old build system the SUBDIRS variable serialized the build process.  While each directory was built in parallel, the directories themselves were built one after the other and libinterp and scripts always preceded the doc directory.  It was this ordering that re-made the DOCSTRINGS files, if necessary, and then re-built the documentation if the DOCSTRINGS files had changed.


Rik <rik5>
Group administrator
Thu 21 Apr 2016 03:44:45 PM UTC, comment #1: 

The rules for building the docs are complicated because they are supposed to not do anything if you are building from an unmodified source tree that has been extracted from a tarball.  AND the automake-generated rules write Info files into the source tree by default.  Oh, but now I see there is an option for turning that feature off and putting the info files in the build tree.  I'm going to check that out and see if it at least simplifies the generated rules a bit.

John W. Eaton <jwe>
Group administrator
Thu 21 Apr 2016 12:20:38 AM UTC, original submission:  

When rebuilding a modified Octave build tree, the make dependencies fail to recognize that the DOCSTRINGS files may be updated, which requires rebuilding doc/interpreter/*.texi, and recursively the manual files. A second make finishes the build. I'm labeling as a build failure because a single "make all" should be all that's required.

This has something to do with the way the libinterp/DOCSTRINGS and scripts/DOCSTRINGS files are declared, because we don't want to have to rebuild them for users who download the source tarball, but we do want to rebuild them if the source actually changes any docstrings.

Make needs to statically analyze all dependency paths. There is a dependency from *.texi to the DOCSTRINGS, but not from DOCSTRINGS to the source files, intentionally. But this is the cause of the build error.

This was mentioned earlier in a comment on bug #46063, but deserves being tracked on its own.

Here is an example that triggers this bug for me every time:


## in build dir, which is one level under source dir
$ make all
$ make all
## everything is now built
$ vim ../scripts/help/help.m
## introduce a typo or some change to the texinfo block and save
$ make -j all
## a few GEN rules show, but nothing actually needs to be rebuilt
$ make -j all
## now make sees new DOCSTRINGS and rebuilds doc/interpreter


It has to be a parallel build. I think with a non-parallel build it works simply by accident of the order that the "all" targets are listed.

Mike Miller <mtmiller>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-29 mtmiller StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2016-04-21 rik5 StatusNone Confirmed
    2016-04-21 mtmiller Dependencies- bugs #47748 is dependent

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code