On Sat, Apr 19, 2014 at 8:40 AM, Bill Somerville <g4...@classdesign.com>wrote:
> On 19/04/2014 14:12, Richard Shaw wrote:
> Hi Richard,
>
> On Sat, Apr 19, 2014 at 5:56 AM, Bill Somerville
> <g4...@classdesign.com>wrote:
>
>> Hi All,
>>
>> as most Linux distros are starting to include Qt 5 in their stable
>> official repos and because we are statically linking the Hamlib we are
>> using at present it is possible for us to generate packages that could
>> be submitted to those repositories without falling foul of their strict
>> entry requirements.
>>
>
> Well, static linking required a bundled library exception to be made by
> the Fedora board but as your patches made it upstream hopefully a new
> release (or as I'm a hamlib maintainer as well) can we just patch up to it
> or do a repository checkout?
>
> As always the problem is Windows :( getting a CMake script that checks out
> Hamlib and builds it as part of the CMake script is rather tricky on
> Windows (severe friction between Qt and Hamlib), on other platforms no
> problem setting it up as an external project in CMake. I was thinking of
> putting the Hamlib licence statement into 'copyright' as a downstream
> dependency for now. As it stands right now we can build using the Hamlib
> master repo but that may change as a result of beta testing with a wider
> range of rigs although my Hamlib fixes have been accepted pretty quickly so
> far.
>
Yup, as long as building against system libraries can be forced, I'll be
good. What I really need is an option to prevent kvasd from being
downloaded. Downloading during building is not permitted in Fedora. My long
term plan is to put a version of wsjtx in Fedora without kvasd and then
create a RPM Fusion nonfree package, something like wsjtx-kvasd, for those
users who want to add it.
> To this end I am working through the WSJT-X CMake/CPack package
>> generation for Linux with the aim to fully automate package generation
>> for Debian and RPM style packages. Richard (KF5OIM) who is our Fedora
>> RPM packaging expert tells me that the CMake/CPack tools fall short of
>> actually creating a suitable RPM package but nevertheless the closer we
>> can get, the smoother the process will be for any downstream packager
>> like Richard. With Debian packages I think I can get pretty close to a
>> suitable package straight out of the CMake/CPack build.
>>
>
> I've got my spec file setup to build for Fedora and RHEL (and
> derivatives)... If we had a Suse person to look at it then I think we would
> have the RPM based distro's covered.
>
> Ok, do you think that might be suitable as a custom template spec file for
> CPack?
>
It's got some Fedora/RH specific macros in it right now but those could be
removed/substituted and checked in with the sources.
> One of the requirements for a Linux package is a man page for each
>> executable distributed. This can be reduced to a single man page that is
>> shared by each program (for example wsjtx and jt9 could be written up as
>> a single application). So has anyone written a man page for wsjtx? I am
>> putting man page generation into the build using asciidoc as a source
>> format and don't want to duplicate any effort that has been made
>> elsewhere.
>
>
> If wsjtx doesn't accept any command line arguments and is a GUI
> application then it doesn't have to have a man page on Fedora... Is Debian
> different there?
>
> wsjtx does accept command line arguments these days, that's how you
> specify multiple instances connected to different rigs.
>
Ok, got ya. It doesn't respond to "--help" or "-h" and just brings up the
GUI so I wasn't sure. We may need to fix that behavior as well.
Thanks,
Richard
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
