On 02/04/2014 20:56, Edson W. R. Pereira wrote:
Hi Bill,
Hi Edson,
I may have misunderstood the issue. I thought that you were having
issues with Hamlib on Linux and on Windows. I stand corrected.
There are issues but I think they are now dealt with.
We still have to build my fork of hamlib until the changes are all
accepted (Nate is moving QTH so that will be a little delayed but all
the pull requests are sent awaiting his action).
Building my hamlib fork (or indeed the official master branch) on Linux
is very straightforward with all the prerequisites for a default build
being readily available in repos (C compiler, autoconf, libtool,
TexInfo, pkg-config, ...).
Building hamlib on Windows is small inconvenience but can be done fairly
easily from an msys console with mingw versions of the above tools and
the Qt bundled mingw48_32 compiler toolchain.
I agree that it should not be a problem with Qt5 on linux.In the worst
case, compiling from sources would not be a problem.
Apart form taking about a day!!
Sorry for any confusion, hopefully the dust will settle soon and we can
get back to the real stuff ;)
At least now a Mac or Windows package ready for release can be produced
in a few minutes by anyone using the CMake script.
73,
-- Edson PY2SDR
73
Bill
G4WJS.
On Wed, Apr 2, 2014 at 4:32 PM, Bill Somerville <g4...@classdesign.com
<mailto:g4...@classdesign.com>> wrote:
On 02/04/2014 20:10, Edson W. R. Pereira wrote:
Bill, Greg,
Hi Edson,
The dependency on a custom install of Hamlib could pose as a
problem for many. Including testers. The Linux situation is also
rather bad. To make things worse, I don't foresee the changes in
Hamlib making its way to a public release any time soon. In the
past, it took quite some time to get changes released. Then there
is the time for the changes to propagate into the Linux
distributions.
I don't see the problem (at least not with hamlib).
On Windows the installer (and the release build) fully package all
the required libraries. There are no external dependencies other
that standard o/s DLLs.
On Mac the installer (and the release build) create a Mac bundled
application, again with all external dependencies embedded apart
from standard o/s dylibs.
On Linux my latest changes will mean that hamlib is statically
linked (actually it will probably be statically linked on all
platforms for consistency). The external dependencies are fftw
which is available on all recent Linux distros and Qt5 which is on
some.
So the problem is Qt5 on Linux, not hamlib. Since qt-project.org
<http://qt-project.org> provide comprehensive binary installers
for many platforms I don't think this is a big issue.
What do you think of using rigctld instead of linking with the
lib? It seems rigctld works on Unix and Windows. We could then
keep our custom hamlib as a separate package.
I don't understand this suggestion, rigctld is a server that can
be talked to by hamlib clients instead of talking directly to the
rig. The hamlib integration in WSJT-X can already do this as the
network rigctl backend is just another hamlib backend. We would
still have to ship a rigctld with the latest hamlib linked to get
the correct functionality. Doesn't this double the issues with two
hamlib programs that have to be statically linked to hamlib 3.0?
73,
-- Edson PY2SDR
73
Bill
G4WJS.
On Wed, Apr 2, 2014 at 3:58 PM, Greg Beam <ki...@yahoo.com
<mailto:ki...@yahoo.com>> wrote:
Hi Bill,
Ok, thank you.
One other question. How are you setup to build on Windows,
are you using
MSYS + MinGW32 from mingw.org <http://mingw.org> to build the
QT projects?
I ran into thread issues when I tried that, and thus, ended
up having to
use MinGW32 for WSJT & WSPR, and mingw48_32 from QT5 tools.
If your setup using just MSYS + MinGW, and we can get that to
work for
all 5 apps, that would certainly simplify things.
As a side note, I was able to build WSJT-X from the package
you'd sent
previous. It didn't find the Static Hamlib binaries, but it's
up and
running on 20m.
73's
Greg, KI7MT
On 4/2/2014 18:30, Bill Somerville wrote:
> On 02/04/2014 15:50, Greg Beam wrote:
>> HI Bill,
> Hi Greg,
>>
>> Thanks for the update.
>>
>> Is there any chance of providing the required libraries
for Windows,
>> other wise, this change has a much larger impact than
pkg-config. As you
>> stated in the original release, Autotools, m4, Libtool and
are all
>> requirements to build Hamlib (I found it wants a few more
also), which
>> basically means, one needs MSYS (on Windows) installed in
addition to
>> the Qt5 tool chain. That is a pretty substantial
requirement to provide
>> one library.
> Yes I agree that building hamlib does need a few MinGW extra
> prerequisites. Once set up there is no problem of course.
>
> I would really like to get the WSJT-X project to build
hamlib as an
> external project, but all the things you mention are a
problem there
> with the added complexity that hamlib really needs to be
built from an
> msys console whereas Qt programs like jt9 and wsjtx must be
built from a
> windows console because of the way qt-project have built
their MinGW
> environment.
>
> I will build a Windows hamlib for you with at least a
static libraries.
> I hadn't realized that you were relying on the binary
packages I posted
> earlier. I am currently trying to sort out the libusb
dependency so I'll
> update the binaries when I've either sorted that out or
given up.
>>
>> Alternatively, is there any way to simply tun off the
Hamlib requirement
>> at build time and rely on 3rd part tools such as DXL
commander, HRD etc?
> No that won't work since hamlib is used for independent PTT
port control
> for all interfaces.
>>
>> Is Hamlib 1.12.x still an option? It just seems allot to
fore the use of
>> an unreleased Library that requires so much to accommodate
it use.
> I have put in a version check since there are so many fixes
in hamlib
> 3.0 that I cannot give any guarantees that CAT control will
work with
> the old library. I want developers and testers to use the
new hamlib to
> help me iron out defects that remain.
>>
>> 73's
>> Greg, KI7MT
>>
> 73
> Bill
> G4WJS.
>>
>>
>>
>> On 4/2/2014 12:46, Bill Somerville wrote:
>>> Hi All,
>>>
>>> because we are currently using a fork of hamlib and also
because even
>>> when all the changes in the fork are accepted and
released as a new
>>> version of hamlib is probably a long way off; it is
necessary to deal
>>> with how we link to hamlib in our release packages.
>>>
>>> On Windows and Mac we currently bundle the hamlib and
other dependencies
>>> (fortarn, fftw & Qt5) as DLLs/dylibs in the installed
package. On Linux
>>> there isn't an equivalent solution and shipping
non-standard (where
>>> non-standard means newer versions from that available via
distribution
>>> package repositories) is not really possible. Fortran and
fftw are ok as
>>> a suitable version is in all repos that I know of. Qt5 is
in some of the
>>> newer Linux repos but not all. Hamlib (v3.0) isn't in any
repo.
>>>
>>> The normal approach with non-standard libraries is to
static link them
>>> into the application. Unfortunately building a Qt5
suitable for static
>>> linking is very difficult (maybe impossible) so we can't
do much about
>>> that, OTOH qt-project.org <http://qt-project.org>
provides easy to use installers for Qt5 for
>>> many platforms. So for Qt5 I think we will have to let
Linux users who
>>> don't have Qt5 in their distribution package repositories
sort out the
>>> Qt5 dependency themselves.
>>>
>>> For hamlib we are able to static link. To enable this I
have upgraded
>>> the CMake find module for hamlib to include static
linking capabilities.
>>> Hamlib uses pkg-config to tell clients how to link it so
you will need
>>> to have pkg-config installed on your build machines. It
is a standard
>>> package on all Linux distros, it is available from
MacPorts on Mac. On
>>> Windows it is a bit more complicated as the full
pkg-config package for
>>> MinGW has a circular dependency with glib. So I suggest
you install
>>> pkg-config-lite which you can get from here
>>> https://sourceforge.net/projects/pkgconfiglite/ Install
the latest
>>> binary package and make sure it is on you MinGW PATH for
builds.
>>>
>>> While sorting this out I discovered a defect in the
hamlib pkg-config
>>> generation, a fix for has been submitted to the hamlib
developers. My
>>> integration branch of my hamlib fork has the fix in place.
>>>
>>> So you will need to update your hamlib sources:
>>>
>>> cd <source-dir>/u-bsomervi-hamlib
>>> git pull origin integration
>>>
>>> Then rebuild hamlib. In the past I have suggested a
hamlib configuration
>>> with only dynamic libraries, because of these changes you
probably want
>>> to build static hamlib archives (the WSJT-X build will
still work with
>>> the dynamic libs but static is now preferred).
Reconfigure your hamlib
>>> build as follows:
>>>
>>> Assume you build out of the source tree in a
sub-directory called
>>> 'build' and install into 'c:\test-install\hamlib'
>>>
>>> cd build
>>> ../autogen --prefix /c/test-install/hamlib
>>> make clean && make && make install
>>>
>>> Once that is done you can re-build WSJT-X as usual. I
would recommend
>>> deleting the CMakeCache.txt in your WSJT-X build tree(s) and
>>> re-configuring since CMake isn't perfect at picking up
changes in
>>> external dependencies.
>>>
>>> Sorry for the disruption, but we have to move towards
being able to
>>> deliver clean installer packages for all supported platforms.
>>>
>>> 73
>>> Bill
>>> G4WJS.
>>>
>>>
------------------------------------------------------------------------------
>>> _______________________________________________
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>>
------------------------------------------------------------------------------
>> _______________________________________________
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
------------------------------------------------------------------------------
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
