Hi Axel, At 2022-07-09T13:09:40+0200, Axel Kielhorn wrote: > I used to build groff with a toolchain from Macports. > > Therefore I had perl at: > > #!/opt/local/bin/perl -w > > After cleaning my system I now use the system version of Perl at: > > #!/usr/bin/perl -w > > This has resulted in the correct version in the Makefile: > > PERL = /usr/bin/perl > PERL_VERSION = 5.30.2 > > Since pdfmom does not depend on Makefile, this change isn’t picked up. > > pdfmom: $(gropdf_dir)/pdfmom.pl $(SH_DEPS_SED_SCRIPT) > $(AM_V_GEN)$(RM) $@ \ > && sed -f $(SH_DEPS_SED_SCRIPT) \ > -e "s|[@]VERSION[@]|$(VERSION)|" \ > -e "s|[@]RT_SEP[@]|$(RT_SEP)|" \ > -e "s|[@]PERL[@]|$(PERL)|" $(gropdf_dir)/pdfmom.pl \ > >$@ \ > && chmod +x $@ > > This affects other programs as well, but with pdfmom it leads to a > build error. > > Of course this isn’t really a bug, I should have typed > make clean > first. > > After that groff builds fin on MacOS 11.
That's good news! Thanks for verifying this. Regarding your problem, my understanding of the GNU Autotools design philosophy is that if you change your build host's configuration in a way that can impact the outcome of an Autoconf check, then you really should run 'make distclean && configure'. Moving executables around or changing their versions qualifies. In other words, to be completely proper you should have reset the state of the build even more aggressively than what you said you should have done. In light of that, adding explicit dependencies on Makefiles in our Automake inputs seems superfluous. Your build went wrong because you violated one of the assumptions of the build system. I therefore don't think it is actually a bug that such an explicit dependency is missing in groff. (So I agree with your statement about it not really being a bug.) I welcome correction by anyone with a greater command of GNU Autotools than I have. There have to be thousands... :D Regards, Branden
signature.asc
Description: PGP signature
