[Nut-upsdev] a few build nits

[Jim Klimov]

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).

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.

On Thu, Mar 31, 2022, 15:18 Greg Troxel <gdt at lexort.com> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220331/ffa33e86/attachment.htm>