[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New Hamlib packages [Was: wsjtx/wsjt software]



On Wed, Jan 17, 2018 at 08:20:52AM +0100, Hegedüs Ervin wrote:
> Hi Andreas,
> 
> On Wed, Jan 17, 2018 at 12:27:55AM +0100, Andreas Bombe wrote:
> > Can you explain which of these the new version of wsjtx requires and
> > why? (The real question behind this is how we can avoid that
> > requirement.)
> 
> Wsjt-x builds with Cmake. I have no experience in Cmake, but the
> reason is that Cmake looks up the .la files for all necessary
> libraries.

That all depends on the scripts it uses. I maintain a bunch of packages
under debian-hams that use CMake and also hamlib. The thing with CMake
is that all sorts of modules to find certain libraries circulate and
they all try to do things differently.

> With the existing Hamlib packages (3.1-7) the Cmake doesn't
> recognize the existence of hamlib. I've tried to find out, what's
> the reason, and why does it found when I installed the "own"
> hamlib prefix. During the tests, I've passed to hamlib_*_DIRS
> (hamlib_INCLUDE_DIRS, hamlib_LIBRARIES, hamlib_LIBRARY_DIRS)
> values as my Debian Hamlib source dir, and Cmake recogized the
> Hamlib. So then I catched that it needs the .la files (there are
> nothing more differences with the packages).

Looking at the wjst-x included CMake/Modules/Findhamlib.cmake it does
its own manual detection, but only if pkg-config isn't found. It is
preferable to use pkg-config rather than that manual prodding anyway.

It looks like libhamlib-dev doesn't depend on pkg-config (I'm not sure
if it should, many other dev packages providing pkg-config files do) but
maybe simply Build-Depending on pkg-config so that it can be
automatically used will fix your problem.

Tested: There was an error since hamlib_LIBRARY_DIRS is empty, but if I
experimentally just remove that variable from the
find_package_handle_standard_args invokation on line 81 it works and
compiles.


Reply to: