bugGNU Octave - Bugs: bug #47832, build fails with read-only source...


bug #47832: build fails with read-only source tree when generating DOCSTRINGS

Submitter:  Dan Sebald <sebald>
Submitted:  Tue 03 May 2016 12:02:29 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:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Tue 03 May 2016 10:14:52 PM UTC, comment #9: 

Did exactly that with http://hg.savannah.gnu.org/hgweb/octave/rev/9631aac4b635

This should be pretty safe, of course it requires writing to the source directory when building from mercurial, but when building a source distribution now I can build from scratch with a read-only source tree.

Mike Miller <mtmiller>
Project Administrator
Tue 03 May 2016 08:11:38 PM UTC, comment #8: 

Can the rule be rewritten so that it puts the temporary file in the build tree?  That should fix the problem if there really is no change in the generated DOCSTRINGS file because the move-if-change script will just delete the tmp file if it is the same as the DOCSTRINGS file from the tarball.

There is no hope of making this work correctly if there is something that requires building the docs because the rules that automake generates will write to the source tree.

And, as I said, I tried the automake option to place the info files in the build tree, but that fails for some other reason that I can't remember exactly, but I think it still tries to write something in the source tree (tmp directory when running makeinfo?).

John W. Eaton <jwe>
Project Administrator
Tue 03 May 2016 07:37:55 PM UTC, comment #7: 

The primary bug here is that a source distribution can't be built now if the source tree is read-only. This is an actual bug, salvaging this report for that purpose. I'll see if I can patch the DOCSTRINGS rules to work within that constraint.

Build ends with

  GEN      ../libinterp/DOCSTRINGS
/bin/bash: line 1: ../libinterp/DOCSTRINGS-t: Permission denied
Makefile:26556: recipe for target '../libinterp/DOCSTRINGS' failed
make: *** [../libinterp/DOCSTRINGS] Error 1

Mike Miller <mtmiller>
Project Administrator
Tue 03 May 2016 04:51:44 AM UTC, comment #6: 

By tarball build, I meant a build from a tarball distribution.  I.e., the tar file that results from running "make dist".

Please, stop.  I looked at this.  Even if you write complicated conditional rules that somehow fix the problem with writing the DOCSTRINGS files in the source tree, you still have the problem that the automake generated rules still write info files to the source tree.  So what does it matter if the DOCSTRING files are also written there?

John W. Eaton <jwe>
Project Administrator
Tue 03 May 2016 04:40:32 AM UTC, comment #5: 

I meant "derived from the same source-tree".  (Was thinking "tree" and conflated with "branch".)

I should be clear, the "build-tarball" step would not put the DOCSTRINGS into the source tree liboctave directory, except inside the tarball itself if that is possible with the "tar" command.  Then, the tarball would be uncompressed and the liboctave/DOCSTRINGS files are present so a conditional DOCSTRINGS build step would recognize them and not build the DOCSTRINGS, but instead (and this is important) simply copy those DOCSTRINGS files to the build-dir/liboctave/ directory.  Otherwise, the DOCSTRINGS would be built as part of compilation into the build-dir/liboctave/ directory.  That way, in either scenario the DOCSTRINGS end up in the build-dir/liboctave directory where the next step of build process can always find them.

Dan Sebald <sebald>
Tue 03 May 2016 04:19:51 AM UTC, comment #4: 

How does a tarball build work?  Is that part of a "make"?  Or is it something separate that just takes a (before ./bootstrap, or after bootstrap?) source tree and archives it?  It seems to me that's the process that should put the DOCSTRINGS files into the source tree, maybe as the very last step.  Of course, such a process couldn't go out and search for the DOCSTRINGS in some build directory because there could be any number of build directories derived from one branch.  The "build-tarball" process could maybe regenerate the DOCSTRINGS to a temp directory and then place them in the source tree at the current location.

Dan Sebald <sebald>
Tue 03 May 2016 04:07:05 AM UTC, comment #3: 

Is there some variable that could be defined for a tarball that will conditionally prevent its build?  Hmm, that is kind of tricky.  I mean, just the presence of the DOCSTRINGS in those source tree subdirectories could be enough to determine if the build/make software should regenerate the files.  And if it does regenerate the files, then place them in the build tree.  But how to manage such a thing under source control?  That would require that the version control system not have the files by default then add them when creating the tarball.  Taking something out for a tarball might work, but not the other way.

Dan Sebald <sebald>
Tue 03 May 2016 03:49:11 AM UTC, comment #2: 

Also, if your question was about why are there two DOCSTRINGS files, it's historical.  When there were separate Makefiles in the scripts and libinterp directories, it made sense to build separate DOCSTRING files in each of those directory trees.  I'm not sure that is really needed now, but it was less work to leave them as separate files, especially since the method for extracting docstrings from the .m files is completely different from the method used for .cc files.

John W. Eaton <jwe>
Project Administrator
Tue 03 May 2016 02:54:31 AM UTC, comment #1: 

No, it was not in the wrong direction.  I see no better way to handle this and still preserve the property that the documentation should not be rebuilt if building from a tarball distribution file.

But if you see a better way to do this job and avoid writing any files in the source tree, then propose a patch.

John W. Eaton <jwe>
Project Administrator
Tue 03 May 2016 12:02:29 AM UTC, original submission:  

There was just a compilation fix:


but it appears there is another such file, scripts/DOCSTRINGS:

sebald@ ~/octave/octave/octave $ hg status
? .run-octave.in.swp
? libinterp/DOCSTRINGS
? liboctave/numeric/.schur.cc.swp
? liboctave/numeric/schur.cc.orig
? run-octave.in.orig
? scripts/DOCSTRINGS

It's here in Makefile.in:

Makefile.in:@AMCOND_BUILD_DOCS_TRUE@am__append_5 = $(srcdir)/libinterp/DOCSTRINGS \
Makefile.in:@AMCOND_BUILD_DOCS_TRUE@        $(srcdir)/scripts/DOCSTRINGS
Makefile.in:libinterp_EXTRA_DIST = $(srcdir)/libinterp/DOCSTRINGS \
Makefile.in:libinterp_MAINTAINERCLEANFILES = $(srcdir)/libinterp/DOCSTRINGS \
Makefile.in:        $(FCN_FILES) $(GEN_FCN_FILES_IN) $(srcdir)/scripts/DOCSTRINGS \
Makefile.in:scripts_MAINTAINERCLEANFILES = $(srcdir)/scripts/DOCSTRINGS
Makefile.in:@AMCOND_BUILD_DOCS_TRUE@$(srcdir)/libinterp/DOCSTRINGS: $(ALL_DEF_FILES) | libinterp/$(octave-dirstamp)
Makefile.in:@AMCOND_BUILD_DOCS_TRUE@        $(INSTALL_DATA) $(srcdir)/libinterp/DOCSTRINGS $(DESTDIR)$(octetcdir)/built-in-docstrings
Makefile.in:@AMCOND_BUILD_DOCS_TRUE@$(srcdir)/scripts/DOCSTRINGS: $(FCN_FILES) $(GEN_FCN_FILES) | scripts/$(octave-dirstamp)

The point is that these DOCSTRINGS files look to be generated, so perhaps they do belong in the build tree and there are a host of definitions within the make file using DOCSTRINGS for which the root path should be $(top_builddir).  Maybe


went in the wrong direction.

Dan Sebald <sebald>


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

Attach Files:

No files currently attached


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 sebald (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 project members can vote.





    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-05-03 mtmiller StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2016-05-03 mtmiller StatusNone Confirmed
        SummaryAnother DOCSTRINGS file in the source tree build fails with read-only source tree when generating DOCSTRINGS

    Back to the top

    Powered by Savane 3.9