For the casual user pulling packages using apt-get (Linux) or, in the case of MacOS, ports, fink, and Homebrew, they are not going to dig in to the make support. For myself, I want to do the same, just build the binaries. Hacking these package managers to affect the compiler and linker options as an end-user is not an easy task.
On a side note, if glib2 is dropping support for older platforms, it is just a matter of time before NUT will not build on older platforms, based on when those managing the dependencies decide to break with the past. https://gitlab.gnome.org/GNOME/glib/-/issues/3437#note_2195247 https://gitlab.gnome.org/GNOME/glib/-/issues/3441 Just a thought. On Wed, Aug 21, 2024 at 5:42 PM Jim Klimov <[email protected]> wrote: > Well, NUT does "since forever" have reference docs on packaging into 8 or > so entities each with its dependency tree, so heavy stuff can be pulled in > on a need-to-have basis. As anything, it can be improved and updated, but > it is there and many systems follow it. Those who missed the memo... the > onus is on them. > > The `nut-scanner` tool (and its lib) design using run-time `dlopen()` of > available dependencies (might be pulled for drivers the particular system > needs) instead of "normal" linking with everything at build time pursues > the same goal, as far as its package-required footprint goes. > > Jim > > > On Wed, Aug 21, 2024, 20:28 Greg Troxel via Nut-upsuser < > [email protected]> wrote: > >> Jim Klimov via Nut-upsuser <[email protected]> writes: >> >> > Upsmon as such has no need for XML (libneon et al); that would be >> > nut-scanner and the Eaton NetXML protocol driver. >> >> Sure, but it is normal for packaging systems to build the entire >> project, so that whatever someone wants is available, and thus depend on >> the union of the dependencies. That's what ups-nut more or less >> suggests by building everything at once, instead of having N separate >> tarballs to be built/installed. >> >> The art is choosing how much grief to goto to make split packages, >> guessing on who wants what, and who won't already have the dependencies. >> Things like libxml are IMHO not a big deal; qt on the other hand is a >> major problem, to pick an extreme (for a program that is not a >> using-facing qt app; for qgis it's fine). >> >> _______________________________________________ >> Nut-upsuser mailing list >> [email protected] >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >> >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
