<div dir="auto">Should be all FOSS as far as dependencies go, just not all OSes package all the pieces (and/or stuff nneded to build them easily).<div dir="auto"><br></div><div dir="auto">And true, some use-cases are not as wide-spread as others, e.g. LLNL libpowerman(ager) or to an extent NetXML from a decade or two of Eaton-branded networked UPSes, or IPMI exposing blade chassis as an ePDU for housed servers. But all code is open.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 31, 2022, 15:18 Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3/31/22 6:15 AM, Jim Klimov wrote:<br>
> As for the man page (re)builds, there might be a better way to handle<br>
> that, but de-facto there are two sets of target lists in<br>
> docs/man/Makefile.am:<br>
> * man5_MANS (more for other numbers, other formats) that would build<br>
> just the pages needed for your drivers, developer features etc.<br>
> requested by configure script<br>
> * MAN_MANS and HTML_MANS that would build (and are used to check) all<br>
> docs there are for a format, regardless of whether you build a driver or<br>
> daemon for it today.<br>
> <br>
> Of these, MAN_MANS are (usually) pre-built and dist'ed in the tarball,<br>
> so a build system is not required to have asciidoc to package NUT, and<br>
> can use pages from the tarball "as is".<br>
> <br>
> But fair point, I'll add a `make all-man` in PR #1345 spawned to tune<br>
> builds to cover netbsd better :)<br>
<br>
I see; it actually makes sense that the build only builds what is needed<br>
and make check builds all as a prereq to check.  That doesn't bother me<br>
and I don't think it's wrong.   It was just that often when I see make<br>
check building things that aren't test programs it's a sign of a bug.<br>
<br>
I see your point about distcheck.  I tend to build tarballs from source<br>
to then use in pkgsrc (not that I publish those tarballs and packages),<br>
to be able to debug the combination of upstream and pkgsrc to be ready<br>
for a release.   I can certainly just flip my script to the light version.<br>
<br>
For things like neon, easy to add them.  But it seems like some of the<br>
dependencies are unusual and perhaps even proprietary.  It would be<br>
great to have all this explained and I'll have a look at making a PR.<br>
<br>
</blockquote></div>