Problem: configure fails on system without pkg-config

[jimklimov]

Solution: detect presence and usability of pkg-config program
and autotools macros (they end up as unexpanded tokens if
pkg-config is not installed), and use this knowledge to
proceed with search for libcppunit - or not. When the test is
optional, we should not kill the build if we can not make it
due to missing tools.

[clepple]

@jimklimov I'm not sure I understand when this situation would arise. Are we talking about building from a tarball? If from Git, we have some assumptions about using recent autotools that I am not sure if this patch addresses.

I just did a tarball build (tarball built with make dist from master@704459f89) on OS X where pkg-config was not in the PATH, and things configured and built fine. Just a single data point, but there seems to be a lot of code here for a small corner case.

[jimklimov]

I was recently building on a minimized-footprint system, so adding autoconf was not sufficient - had to find and add the pkg-config package too. Note that those are different projects, so without pkg-config installed, the PKG_* macros are not defined in m4 and remain verbatim tokens including parentheses and producing shell script parsing failure.

Actual use of pkg-config that I've found in NUT is currently constrained to cppunit scaffolding (so far at least), so actual NUT project code can live and build quite happily on systems without pkg-config.

[clepple]

I use the term "autotools" loosely, and I guess I assume that if people are using autogen.sh, then they should have their distribution's version of build-essential installed (including pkg-config). It's not that I think we should ignore minimal systems, but that they are better served by installing from tarballs.

FWIW, the libusb-1.0 branch uses pkg-config.

I don't want to spend too much time bikeshedding this, so if you want to merge this, I guess I don't have a specific objection, but let's not set a precedent here - I really don't want the NUT configure.ac to basically reinvent the portions of autoconf/automake/pkg-config that are already available in later versions. As has been done for other auxiliary tools, if a widely-available developer tool is missing during the run of autogen.sh, I think we should error out with a message that shows what is missing, rather than just warning.

[jimklimov]

Well, here the situation seems sort of special - I've never seen such a corner-case aspect :) On one hand, pkg-config is a separate tool, but integrated with autotools via m4 macros - so until it and its macros are installed, autotools rightly has no idea how to interpret them or even differentiate those tokens from common shell code. While many projects went on to use it heavily to detect installed dependencies, NUT did not yet do so - and so can build production code without it present, so lack of this package should not be fatal to autogen+configure+build - at least not at this point in NUT project's evolution. What benefit would the dist'ed tarballs have (and are some easily available to people who want a recent master or experimental branch) - the generated files like the configure script and manpages would come pre-generated, so only a compiler is required, right? Jim

…

On Oct 28, 2017 16:25, "Charles Lepple" ***@***.***> wrote: I use the term "autotools" loosely, and I guess I assume that if people are using autogen.sh, then they should have their distribution's version of build-essential installed (including pkg-config). It's not that I think we should ignore minimal systems, but that they are better served by installing from tarballs. FWIW, the libusb-1.0 branch uses pkg-config. I don't want to spend too much time bikeshedding this, so if you want to merge this, I guess I don't have a specific objection, but let's not set a precedent here - I really don't want the NUT configure.ac to basically reinvent the portions of autoconf/automake/pkg-config that are already available in later versions. As has been done for other auxiliary tools, if a widely-available developer tool is missing during the run of autogen.sh, I think we should error out with a message that shows what is missing, rather than just warning. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#491 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABj5lO9R657hbaWWDXeJ34Q_pK9fOjQXks5swzlSgaJpZM4QA_7I> .

[clepple]

What benefit would the dist'ed tarballs have (and are some easily available to people who want a recent master or experimental branch) - the generated files like the configure script and manpages would come pre-generated, so only a compiler is required, right?

correct, only a compiler and a Bourne-compatible shell for a minimal build. Buildbot creates a tarball for every master and branch commit. Recent tarballs (from the last month or so) are not currently available due to some reshuffling after the Buildbot master was moved, but nobody seems to have noticed except a few bots. Should be possible to set up again, but debugging that is a pain, and it's not near the top of the TODO list.

[jimklimov]

Well... I have no really strong opinion about this, but think it's reasonable to plug a problem that can be a detractor for newcomers into the NUT ecosystem (came across this issue consulting one), if only by providing a reasonable diagnostic. It may make sense to un-clutter the main script and offload that testing logic into an m4 include file and a new macro at some point, though. As for tarballs, Travis can IIRC upload releases to e.g. github storage, using securely stored credentials. Maybe that could be set up instead of buildbot, if fixing it proves hard?

…

On Oct 29, 2017 21:01, "Charles Lepple" ***@***.***> wrote: > What benefit would the dist'ed tarballs have (and are some easily available > to people who want a recent master or experimental branch) - the generated > files like the configure script and manpages would come pre-generated, so > only a compiler is required, right? correct, only a compiler and a Bourne-compatible shell for a minimal build. Buildbot creates a tarball for every master and branch commit. Recent tarballs (from the last month or so) are not currently available due to some reshuffling after the Buildbot master was moved, but nobody seems to have noticed except a few bots. Should be possible to set up again, but debugging that is a pain, and it's not near the top of the TODO list. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#491 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABj5lIzsGgjz4gjX7lNo4OUaYPhjtv_kks5sxNm3gaJpZM4QA_7I> .

[jimklimov]

Thinking more about this, the opinion became stronger: building on a system that lacks pkg-config causes the generated configure script to fail in a way that is hard to debug. This PR fixes that part of the problem, and can work for any checkout from git without relying on tarballs. It also allows the builds to pass on systems that do not have pkg-config (e.g. proprietary Unix deployments where one may not install much).

@aquette : do you have an opinion on this?

[jimklimov]

@aquette @clepple : How about adding this to 2.7.5? I believe the added logic should not break anything, but can fix builds out of the box on certain systems. Which should be good PR for a release :)

[clepple]

I guess the benefits outweigh the disadvantages, though it would be nice to clean up some of that logic later. If Arno doesn't have any objections, merge away. What about adding a Travis builder to test the case where pkg-config is not installed? I didn't look too hard in .travis.yml, but it seems like pkg-config is being installed implicitly. (Same on the Buildbot environments, but currently they are all set up to run 'make distcheck-light' which implies a lot of dependencies. Still haven't gotten to fixing the old tarball builder, or adding builders that build from a release tarball instead of git.)

[jimklimov]

Tried to stage the test, see https://travis-ci.org/networkupstools/nut/jobs/311621280 - but found that in Debian the*.pc files are part of *-dev packages, along with headers etc... so removing the pkg-config package also removes the dependencies NUT wants to build against.

[clepple]

so removing the pkg-config package also removes the dependencies NUT wants to build against.

yeah, I guess I wasn't clear - I was thinking of a very minimal Travis builder, so something without any of those libraries installed to start with. Maybe even just build-essential, autoconf and automake?

[jimklimov]

"without those libraries" it had problems passing configure (no headers of things to build against)... I'm now trying a different approach at removing pkg-config package contents while having the needed rest installed...

[jimklimov]

@clepple : I've finally crafted a way to stage this situation (lack of pkg-config) on Travis.

This was a bit difficult because modern autoconf somehow expects/relies on pkg-config's pkg.m4 being present while it generates the configure script, although I did not unravel why - saw no direct references during cursory review.

On older systems that did not have it sort of always, their older autotools probably did not rely on it either, and/or the release tarballs could be used which include a copy of pre-generated configure script.

You can see an example log of successful build (not finding a number of components where it defaults to looking by pkg-config files, but not crashing with invalid syntax of the configure script itself - as it did before the PR) e.g. here : https://api.travis-ci.org/v3/job/382089663/log.txt

Side note: compared to initial premise of this being needed for libcppunit, it seems that pkgconfig metadata is also consulted to look for quite a few other dependencies, as at least one data source about those.