Yes, that would be good. It is doing the « expected » behaviour for a more extensive clean, but looses the granularity meaning of « distclean » that only cleans the dist folder, and libsclean only cleans the compiled grass libs.
Speculating here: Maybe if grass is compiled and installed, not compiling the libs from the repo results in having the system available libs instead. Is there a way to verify that hypothesis? Something similar happened during the code sprint, when after using libsclean made the next builds work, but I wasn’t able to reproduce like expected afterwards.. Edouard Choinière > Le 30 juill. 2024 à 09:44, Markus Neteler <nete...@osgeo.org> a écrit : > > On Mon, Jul 29, 2024 at 12:02 PM Edouard Choinière via grass-dev > <grass-dev@lists.osgeo.org> wrote: >> >> So, if libsclean was the part that made it work, we might have to look at >> running it on distclean (if distclean is commonly used as a « super clean »). > > Yes, "make distclean" is commonly used as a « super clean ». > > So, would this change improve the situation? > > index be8834ecf4..81390f0dec 100644 > --- a/Makefile > +++ b/Makefile > @@ -124,7 +124,7 @@ code-coverage-clean: > -find . -type f \( -name "*.gcda" -o -name "*.gcno" -o -name > "*.gcov" \) -delete > -rm -f .coverage > > -distclean: clean > +distclean: libsclean clean > -rm -f config.cache config.log config.status > config.status.$(ARCH) 2>/dev/null > -rm -f ChangeLog ChangeLog.bak $(ERRORLOG) grass.pc > -rm -f include/grass/config.h include/grass/version.h > > Markus _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
