[GRASS-dev] GRASS 7.1 compiles but won't run

[Glynn Clements]

Moritz Lennert wrote:

> > However, if you think it would help, I can delete the entire
> > installation and checkout again.
> 
> Yes, I have found that from time to time make distclean is not enough. I 
> haven't dug into this deeply enough to understand why, but there seems 
> to be some cleaning tasks missing and that corrupts the source tree even 
> after a make distclean.

"svn status --no-ignore" will show everything except for unmodified,
version-controlled files. Modified and non-version-controlled files
will be shown (even if explicitly ignored due to an svn:ignore
property).

In a perfectly clean source tree, that command should produce no
output.

The only difference between "make distclean" and "make clean" is that
the former also removes the files generated by "configure" (so you'll
get an error if you try to build without first running configure,
rather than it using stale files).

Here (on Linux), I don't see any ignored files after "make distclean",
and the only non-ignored "unknown" files are patches, logs, notes, etc
which are there through my own actions (i.e. not as a result of
running "make").

It's possible that, on other architectures, the build process may
create additional files which should be added to the "clean" rule. 
Please report any that are found.

When updates remove directories, those directories will be removed
from SUBDIRS in the parent Makefile, which means that "make clean"
won't remove them. "svn update" will delete any removed files, but it
won't delete subdirectories which aren't empty (e.g. if "make clean"
wasn't performed first, the OBJ.$(ARCH) directory will remain and thus
the parent directory won't be deleted by "svn update").

Similarly, if files or directories which are marked for cleaning via
$(EXTRA_CLEAN_FILES), $(EXTRA_CLEAN_DIRS) or $(CLEAN_SUBDIRS) are
removed, they'll typically also be removed from those variables in the
relevant Makefile, and thus won't be removed by "make clean". They
typically won't be explicitly listed as build targets or dependencies
either, but their mere presence may still affect compilation.

-- 
Glynn Clements <glynn at gclements.plus.com>