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.
|
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?).
|
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
|
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?
|
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.
|
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.
|
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.
|
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.
|
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.
|
Tue 03 May 2016 12:02:29 AM UTC, original submission:
There was just a compilation fix:
http://hg.savannah.gnu.org/hgweb/octave/rev/22e7b6ad93b6
but it appears there is another such file, scripts/DOCSTRINGS:
It's here in Makefile.in:
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
http://hg.savannah.gnu.org/hgweb/octave/rev/22e7b6ad93b6
went in the wrong direction.
|