Hi, On Mon, May 08, 2017 at 04:51:52PM -0500, Dirk Eddelbuettel wrote: > On 8 May 2017 at 23:41, Rene Engelhard wrote: > | Hi, > | > | On Mon, May 08, 2017 at 04:34:27PM -0500, Dirk Eddelbuettel wrote: > | > Not when you talk to upstream, as I do as maintainer. Upstream's code may > | > well be built against cppunit-config for years to come. > | > | Why? > | > | The point is: you (= upstream) already checks for >= 1.12.1. > | So you already have pkg-config as a given, so you don't need to check for > | cppunit-config as an alternative at all. > > I am at work and have no time to argue with you, but I did poke into > configure.ac for JAGS and it simply has > > AM_PATH_CPPUNIT(1.12.1)
Which runs cppunit-config. > Methinks that may in fact be an autotools bug that 1.14 is not found. No, again: it was simply removed in 1.14. cppunit-config is gone. cppunit-config removal was (unfortunately) a deliberate choice upstream. Don't like that either but *shrugs*. (And AM_PATH_CPPUNIT isn't contained in cppunit either anymore since it runs cppunit-config and that one is gone. Even if that one was installed, it would fail as the initial log shows). The fix is to use pkg-config, PKG_CHECK_MODULES to be precise: PKG_CHECK_MODULES(CPPUNIT, cppunit >= 1.12.1) If you really insist on doing cppuit-config again (which I still don't think is needed), maybe with a fallback like PKG_CHECK_MODULES(CPPUNIT, cppunit >= 1.12.1, [], [AM_PATH_CPPUNIT(1.12.1)]) but then you need to embed AM_PATH_CPPUNIT yourself, otherwise a autoreconf would simply fail as it's - as said - also gone from libcppunit-dev. > In either event we may now have to manually code around this. Yes. Regards, Rene
