As for the man page (re)builds, there might be a better way to handle that, but de-facto there are two sets of target lists in docs/man/Makefile.am: * man5_MANS (more for other numbers, other formats) that would build just the pages needed for your drivers, developer features etc. requested by configure script * MAN_MANS and HTML_MANS that would build (and are used to check) all docs there are for a format, regardless of whether you build a driver or daemon for it today. Of these, MAN_MANS are (usually) pre-built and dist'ed in the tarball, so a build system is not required to have asciidoc to package NUT, and can use pages from the tarball "as is". But fair point, I'll add a `make all-man` in PR #1345 spawned to tune builds to cover netbsd better :) On Wed, Mar 30, 2022, 19:02 Greg Troxel <gdt at lexort.com> wrote:> > * make check > > When I run make check, the good news is that it seems to pass > everything. > > But it looks like it is building man pages that maybe should have been > built during the build. > > [snip] > Making check in docs > Making check in man > make check-local > PASSED man-source sanity check (checked 130 files) > DOC-MAN Generating hosts.conf.5 > DOC-MAN Generating upsset.conf.5 > DOC-MAN Generating upsstats.html.5 > DOC-MAN Generating upsset.cgi.8 > [snip] > > * make install > > looks good > > * make distcheck > > This fails because of missing libneon, but the earlier configure worked. > Is the configure intentionally forcing on all optional things? > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220331/ed593a3d/attachment.htm>
On 3/31/22 6:15 AM, Jim Klimov wrote:> As for the man page (re)builds, there might be a better way to handle > that, but de-facto there are two sets of target lists in > docs/man/Makefile.am: > * man5_MANS (more for other numbers, other formats) that would build > just the pages needed for your drivers, developer features etc. > requested by configure script > * MAN_MANS and HTML_MANS that would build (and are used to check) all > docs there are for a format, regardless of whether you build a driver or > daemon for it today. > > Of these, MAN_MANS are (usually) pre-built and dist'ed in the tarball, > so a build system is not required to have asciidoc to package NUT, and > can use pages from the tarball "as is". > > But fair point, I'll add a `make all-man` in PR #1345 spawned to tune > builds to cover netbsd better :)I see; it actually makes sense that the build only builds what is needed and make check builds all as a prereq to check. That doesn't bother me and I don't think it's wrong. It was just that often when I see make check building things that aren't test programs it's a sign of a bug. I see your point about distcheck. I tend to build tarballs from source to then use in pkgsrc (not that I publish those tarballs and packages), to be able to debug the combination of upstream and pkgsrc to be ready for a release. I can certainly just flip my script to the light version. For things like neon, easy to add them. But it seems like some of the dependencies are unusual and perhaps even proprietary. It would be great to have all this explained and I'll have a look at making a PR.
On Mar 31, 2022, at 9:18 AM, Greg Troxel wrote:> > I see your point about distcheck. I tend to build tarballs from source > to then use in pkgsrc (not that I publish those tarballs and packages), > to be able to debug the combination of upstream and pkgsrc to be ready > for a release. I can certainly just flip my script to the light version. >mostly for the archives (sounds like Greg has a solution), this page talks about the difference between "make distcheck" and "make distcheck-light" in NUT: https://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building - C