Add a New Comment (Rich Markup)
Comment Type & Canned Response: None None > Multiple Canned Responses Fixed in development Crash with no stack trace Already fixed in newer version Fixed in stable Bad description Bad description and crash Bad stack trace Obsolete version Duplicate and not fixed Duplicate and needs more info Duplicate and fixed Need info and old
( Jump to the original submission )
That's good enough for me. Closing this report.
I pushed a change
http://hg.savannah.gnu.org/hgweb/octave/rev/21c12b837089
to only delete built documentation on 'make maintainer-clean'.
I can now build in-tree from a source distribution with multiple sequences of './configure && make' and 'make distclean' and get repeatable results and identical content to the original source tarball, with the only anomaly being octave.jar.
The octave.jar file is built from some .class files compiled from .java sources. The .java sources are distributed, as is the octave.jar file, but not the .class files. This is analogous to distributing an executable and a bunch of sources, but not the *.o files that were linked into the executable. Make has to regenerate these intermediate files because they are missing, which causes the end product to be overwritten.
I agree that it is not ideal to use an internal name like "clean-aminfo". On the other hand, Automake and the whole Autotools suite are ancient and change very slowly. It might be 5 years before that name gets changed, and in the meantime we would have everything working correctly.
I vote to make the change.
I can prevent the built-in automake rule that deletes the doc files by defining a target "clean-aminfo" that overrides the automake one. But this is an internal name, not mentioned in the user manual, doesn't seem like a good idea to depend on that name/behavior. Other than that there is no way to prevent 'make clean' from deleting the dvi/pdf/ps/html files.
I pushed a change that fixes which files get deleted and preserved for the clean and distclean targets:
http://hg.savannah.gnu.org/hgweb/octave/rev/659731a4563f
The general principle I applied is for 'make clean' to delete files that are created by 'make all', and 'make distclean' to delete files created by './configure'.
The exceptions are the source files that we build during 'make all', but that we want to be part of the source distribution. So now all of the libinterp and liboctave files that were mentioned here before are not deleted on clean or distclean.
There is still a small set of files that are distributed but are deleted on 'make clean' (if the user does an in-source-tree build) that I don't have a good way to fix at the moment:
doc/interpreter/octave.dvi doc/interpreter/octave.html doc/interpreter/octave.pdf doc/interpreter/octave.ps doc/liboctave/liboctave.dvi doc/liboctave/liboctave.html doc/liboctave/liboctave.pdf doc/liboctave/liboctave.ps scripts/java/octave.jar
The documentation files are deleted because of a built-in automake rule. The octave.jar file needs to be deleted because it seems to always get rebuilt even if it exists in $(srcdir).
The problem seems to be the line in config.h that is
#include "oct-conf-post.h"
config.h is in the build directory and it assumes that oct-conf-post.h is also in the build directory. The line that generates this in config.h is in configure.ac:
AH_BOTTOM([#include "oct-conf-post.h"])
If there is a way to substitute a variable, such as $srcdir, in the configure.ac code then this can be easily solved. I tried, but wasn't successful. We could also have a rule to copy over oct-conf-post.h from the source to the build directory but first checking to see if they were the same. Something has to be done, but I don't have good ideas right now.
After Rik's change (comment #6) I get this (cloned repo/fresh checkout) on Mageia-4 Linux (just did the usual ./bootstrap in the src dir (= my <development_subdir>/dev) followed by ../dev/configure ; make -j7 in the build dir:
: : CC cloexec.lo In file included from ../../dev/libgnu/base64.c:42:0: ../config.h:3479:27: fatal error: oct-conf-post.h: No such file or directory #include "oct-conf-post.h" ^ compilation terminated. In file included from ../../dev/libgnu/areadlink-with-size.c:21:0: ../config.h:3479:27: fatal error: oct-conf-post.h: No such file or directory #include "oct-conf-post.h" ^ compilation terminated. Makefile:2145: recipe for target 'areadlink-with-size.lo' failed make[4]: *** [areadlink-with-size.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... Makefile:2145: recipe for target 'base64.lo' failed make[4]: *** [base64.lo] Error 1 In file included from ../../dev/libgnu/md5.c:22:0: ../config.h:3479:27: fatal error: oct-conf-post.h: No such file or directory #include "oct-conf-post.h" ^ compilation terminated. In file included from ../../dev/libgnu/c-ctype.c:18:0: ../config.h:3479:27: fatal error: oct-conf-post.h: No such file or directory #include "oct-conf-post.h" ^ Makefile:2145: recipe for target 'md5.lo' failed compilation terminated. make[4]: *** [md5.lo] Error 1 Makefile:2145: recipe for target 'c-ctype.lo' failed make[4]: *** [c-ctype.lo] Error 1 In file included from ../../dev/libgnu/canonicalize.c:17:0: ../config.h:3479:27: fatal error: oct-conf-post.h: No such file or directory #include "oct-conf-post.h" ^ compilation terminated. Makefile:2145: recipe for target 'canonicalize.lo' failed make[4]: *** [canonicalize.lo] Error 1 In file included from ../../dev/libgnu/cloexec.c:20:0: ../config.h:3479:27: fatal error: oct-conf-post.h: No such file or directory #include "oct-conf-post.h" ^ compilation terminated. In file included from ../../dev/libgnu/bitrotate.c:1:0: ../config.h:3479:27: fatal error: oct-conf-post.h: No such file or directory #include "oct-conf-post.h" ^ compilation terminated. Makefile:2145: recipe for target 'cloexec.lo' failed make[4]: *** [cloexec.lo] Error 1
Copying / symlinking oct-conf-post.h to libgnu/ (OK a dirty hack) fixes the build for Linux, but cross-building in mxe-octave doesn't work as "make all dist" doesn't copy it (of course) to libgnu/ in the dist archive. Manually adding it to the dist archive before building in mxe works, of course.
I wonder why a mere rename of an include file + its references break the build process.
@jwe: Yes, you've got it right. 'make clean' by itself removes files that were present in the original tarball. However it only has this issue for in-tree builds. VPATH builds with a separate build directory appear to be fine from my testing.
This bug has been present for a long time but I don't think it's been a big issue because the normal usage pattern is
tar xf octave.tar.gz cd octave ./configure make make install cd .. rm -rf octave
Maybe I misunderstand Rik's comment #6 then, because it seems to say that make clean by itself (not make maintainer-clean) will remove some files that are included in the tarball distribution.
@jwe: Yes, your "rules" in comment #7 match the guidance frome GNU that I published in comment #1.
Yes, that is my understanding of the clean targets.
This bug was originally about files, e.g. libinterp/parse-tree/oct-parse.cc, that are deleted on make clean (because they are in BUILT_SOURCES, and all of BUILT_SOURCES is added to CLEANFILES). This goes back to previous versions too, in 3.8 if you unpack the offical tar release, build it, clean it, you can't build again without installing bison.
One problem I've further noticed after reporting this is that we have some files that we like to distribute (so they should not be deleted on distclean), but if you do an out-of-tree build they are copied into the build tree, so they should be deleted.
For example, DOCSTRINGS are copied (with timestamp preserved) into the build directory. Thanks to Rik's change, they are not deleted on distclean (because they are distributed) but that leaves leftover files for out-of-tree builds now.
So we may need more special handling for those types of files.
I've always thought that the clean rules could be written something like this:
clean: rm -f some files that are built by make rm -f perhaps leaving some that are not rm -f included in a tarball distribution distclean: clean rm -f some other files so that rm -f we are back to the set of files rm -f from a tarball distribution maintainer-clean: distclean rm -f also remove files that need special rm -f tools to rebuild that only maintainers rm -f are expected to have
Is that not correct?
I checked in a changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/9c7dd58b57e4) that handles oct-conf-post.h. At this point 'make distclean' preserves all of the original files. The list of files that are removed from the original tarball with 'make clean' is now
./libinterp/parse-tree/oct-parse.cc ./libinterp/parse-tree/lex.cc ./libinterp/parse-tree/oct-gperf.h ./libinterp/parse-tree/oct-parse.h ./libinterp/corefcn/oct-tex-lexer.cc ./libinterp/corefcn/oct-tex-parser.cc ./libinterp/corefcn/oct-tex-symbols.cc ./libinterp/corefcn/graphics-props.cc ./libinterp/builtin-defun-decls.h ./scripts/java/octave.jar ./doc/liboctave/liboctave.html/* ./doc/liboctave/liboctave.pdf ./doc/liboctave/liboctave.dvi ./doc/liboctave/liboctave.ps ./doc/interpreter/octave.html/* ./doc/interpreter/octave.ps ./doc/interpreter/octave.dvi ./doc/interpreter/octave.pdf
@Mike: oct-conf.post.h is generated from oct-conf.post.in.h by configure
AC_CONFIG_FILES([ oct-conf-post.h:oct-conf-post.in.h
However, I don't see that there are any substitutions between in.h and .h. Maybe there was at one point, but processing this through configure no longer seems necessary. If that is the case we could remove it from configure.ac and use EXTRA_DIST to distribute it. There is no need to clean it, even at the maintainer-clean level because it is not a generated file.
I fixed ChangeLog by moving it to MAINTAINERCLEANFILES here (http://hg.savannah.gnu.org/hgweb/octave/rev/517f5a006279).
@Mike: I think I answered my own question. I unpacked a tarball and if I do an in-tree build then I see what you are saying. I alse notice that the HTML documentation and the manual itself (octave.pdf, octave.ps, octave.dvi) are also removed with a simple 'make clean'
@Mike: I'm unable to reproduce the list of files being deleted in the source tree for 'make clean'. I am using a VPATH build. Were you doing an in-tree build?
Good catch, although we need to think carefully about what files belong in which cleanup batch.
Here is the guidance from GNU Autotools
As the GNU Standards aren’t always explicit as to which files should be removed by which rule, we’ve adopted a heuristic that we believe was first formulated by François Pinard: If make built it, and it is commonly something that one would want to rebuild (for instance, a .o file), then mostlyclean should delete it. Otherwise, if make built it, then clean should delete it. If configure built it, then distclean should delete it. If the maintainer built it (for instance, a .info file), then maintainer-clean should delete it. However maintainer-clean should not delete anything that needs to exist in order to run ‘./configure && make’.
I fixed the removal of the documentation files (.texi and DOCSTRINGS) with distclean target in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/4300fe896004).
The following files are part of the source distribution tarball, but are deleted when the "clean" target is executed. This leaves the user with fewer files than were there when the source was unpacked:
* libinterp/builtin-defun-decls.h * libinterp/corefcn/graphics-props.cc * libinterp/corefcn/oct-tex-lexer.cc * libinterp/corefcn/oct-tex-parser.cc * libinterp/corefcn/oct-tex-symbols.cc * libinterp/parse-tree/lex.cc * libinterp/parse-tree/oct-gperf.h * libinterp/parse-tree/oct-parse.cc * libinterp/parse-tree/oct-parse.h * scripts/java/octave.jar
And the following set of files are similarly deleted when the "distclean" target is executed, again leaving the user with fewer files than we gave them in the source tarball:
* ChangeLog * doc/interpreter/*.texi * libinterp/DOCSTRINGS * oct-conf-post.h * scripts/DOCSTRINGS
Ideally, the "distclean" target should return the user to the same set of files that were there when the tarball was unpacked. I plan to look at this, just documenting what I've found so far.
(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
Items that depend on this one: None found
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.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 3 latest changes.
Copyright © 2022 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.9