Menu
▾
▴
Re: [wsjt-devel] Clear guidance - Development Environment
|
From: Bill S. <g4...@cl...> - 2018-12-07 16:32:43
|
Stephen,
comments in line below.
On 07/12/2018 10:32, Stephen Ireland wrote:
>
> Joe,
>
> A couple of weeks back I put a post in here requesting details of how
> the environment for compiling and developing WSJT-X releases was
> constructed. I received responses that many have commented as being
> unhelpful and lacking guidance back.
>
Please remember WSJT-X is an open source project, requests for
information about development tools are fine but demands will get little
response. Collaboration in the Open Source community is largely based on
contribution and individuals usually earn their status proving their
interest and capabilities by making direct contributions. Even then the
contributions must be in line with where the project leader(s) want to
go, after all it is their project and they drive it forward, usually by
giving huge amounts of their time and experience free of charge to the
user community.
>
> From comments passing it appeared that Greg Beam’s brilliant JTSDK was
> not being used as the central environ; with great difficulty I also
> gathered from responses that base development is performed under Linux
> and that Windows versions are cross-compiled from Linux. Likewise I
> drew conclusions that development from XCode was based upon
> Linux-lines. Can this please be confirmed?
>
While not detracting in any way from Greg's excellent work with the
JT-SDK, it is a wrapper around the pre-existing tasks and tools that any
competent developer would know how to do and acquire or at least be able
to work out for themselves. The need for the JT-SDK comes from the large
community of users who are not software developers but are keen to build
the very latest development sources even before they are deemed ready
for release by the core team. This fills a need but by no means is the
best environment for a developer who is making changes to the source on
a daily basis. The JT-SDK is largely biased towards building the sources
without any changes with a single aim of producing an executable to go
and try out on the bands. Apart from the fact that the JT-SDK is heavily
MS Windows focused (yes I know it has a Linux variant, but more about
building WSJT-X for Linux below), it is actually inconvenient for a
developer who is working on multiple projects that share the same tool
sets as those used by WSJT-X. Having the tools bundled up with a WSJT-X
focus in not workable for a developer in such a position.
The bottom line is that the JT-SDK is a tool for end users that want to
build WSJT-X from sources on Windows with an aim to run the product an
with no intention of doing any development work on the project. I am
sure one could use the JT-SDK as a developer but once the initial set up
of a development machine is complete, the day to day tasks of software
development are more easily done with the underlying tools that the
project uses, e.g. CMake.
>
> There has been a number of comments in separate posts eluding to this
> same request that I am making.
>
I haven't seen those, perhaps you are referring to posts where Linux
users are trying to build from sources because the binary installer
packages we provide are not suitable for their particular Linux
distribution or versions. These cases are almost always due to some lack
of knowledge of the packaging system for their Linux distribution or of
Linux development in general. We are more than happy to help these
individuals on a case by case basis, which it almost always is because
their experience level vary greatly and the variants of Linux vary
equally each requiring slightly different recipes for building a complex
package like WSJT-X.
>
>
> So that we are all on the same page, pending the “General
> Availability” release of WSJT-X 2.0 and the concept racing into a
> brave new world, can the development/production environ and versions
> of software used (i.e. Qt versions, Linux environs if used etc.)
> please be confirmed? If Greg Bream’s scripts etc. are not used can the
> environment and its setup/deployment please be clearly documented (in
> an evolving document ?) so that everyone working across WSJT-X and is
> advancement can be completely on the same page?
>
The tool and library versions are not fixed, there are certain
constraints determined by the source code itself and also by production
restrictions. Largely we use the latest versions of all dependencies but
those latest versions are gated by requirements to support older
operating system versions. Individual users need not be constrained so
strictly if they wish to build from sources since they only have to
produce executables that run on their individual system.
With v2.0.0 GA the basic constraints are:
MS Windows:
* We use the MinGW variant of the MS Windows Qt development package as
we have no need or interest in using the proprietary tool chain for
the MSVC++ variant of the Qt development package.
* Qt v5.5 (last version that supports Windows XP) we will drop XP and
Vista support in an upcoming version which will allow us to make
production builds with a newer Qt version nevertheless users may
build with any newer Qt version right now, although Qt v5.12
(released yesterday) is not yet tested to my knowledge.
* The compilers used are those that are packaged with the Qt MinGW
package, this is non-optional as the C++ ABI is not guaranteed
compatible between compiler versions let alone compiler vendors. As
MinGW is a native port of the full GNU GCC compiler suite, it
provides us with a C, Fortran, and C++ toolchain which is all that
WSJT-X needs.
* Other dependent packages are whatever is the latest, they are all
stable and the latest version is as good as any recent version. This
includes fftw3, the MS DirectShow SDK, and the Omni-Rig server
(optional).
* For Hamlib we use the latest master branch (actually from a forked
repo but the branch used tracks the Hamlib master branch extremely
closely) and always build it ourselves, this may change in the
future but for now the WSJT-X team and other WSJT-X contributors
provide a lot of upstream patches for Hamlib and we include them
into WSJT-X by using their latest master branch which is ahead of
their official releases. Hamlib is a vanilla C library and can be
built without issue using the MinGW toolchain that comes with the Qt
package.
* Hamlib has an optional dependency on the libusb project, this
library is available ported to MS windows and we use the latest
official binary release.
Linux:
* On Linux the dependent packages and tool chains are determined by
distribution and version of the development system, the WSJT-X
sources will build on any Desktop Linux distribution and version
that provides at least Qt v5.5. This last restriction is because we
have source code that will not build with Qt versions older than
v5.5. The actual version and patch level of Qt and the other
dependent packages (fftw3, libusb) along with the compiler
toolchains are all whatever that Linux distribution and version have
in their repo. Bottom line is if the toolchains can build Qt then
they are fine for WSJT-X.
macOS:
* On Macs, like on MS Windows, we would like to use the latest
versions of Qt and related tool chains but are constrained by
operating system version compatibility. Up to WSJT-X v2.0.0 we used
Qt v5.8 for production releases. At v2.0.0 that has change to Qt
v5.9 because several users have suffered a defect in Qt when they
use a proxy Internet connection (or a VPN), this defect was exposed
by code in WSJT-X that download online help and support files
directly. The defect is fixed in Qt v5.9 but that version doesn't
support OS X version 10.9 so this Qt upgrade has forced us to drop
support for OS X 10.9 (which is pretty old and out of support with
Apple).
* In general the Apple development methodology allows applications
built on the latest o/s version and with the latest tools and SDK
but flagged to be compatible back to a specified macOS/OS X version.
This means that using the latest compilers and system MacOS SDK is
fine so long at the correct options to set the oldest supported
version are used.
* The other dependencies on Mac, i.e. the ones not provided by the
system MacOS SDK and standard system libraries can be provided from
several sources, the most commonly used ones are MacPorts and
HomeBrew. Personally I use MacPorts but either is fine. These
projects provide native MacOS binary packages of Open Source
projects and include most of the packages you might find in a
typical Linux distribution repository.
* The compiler tool chains we use on Mac are the command line tools
clang and clang++, these are the Apple variants of these tools which
are available as the command line tools bundled with Xcode (the
Apple developer IDE). Because Apple do not have a Fortran compiler
we use the GNU GCC gfortran compiler that is available via MacPorts
or HomeBrew or similar.
> I realise that some fear that "releasing the rabbits” can cause
> damage. Likewise this is not supposed to be a forum for “rabbits”.
>
There no rabbits nor hats to produce them from. This is an Open Source
project, the only thing that is scarce is developer time.
What there are in abundance are users who just want something they can
install in minutes that works. This is fine and there will always be a
massive ratio of users to core developers in any successful software
project. The big difference with an Open Source project is that there
are usually only developers and users. Support is down to the developers
although the community's more experienced users make a huge contribution
here and elsewhere which is welcome and can take a big load off the core
development team who only have to chip in when deeper technical details
or complex application behaviour needs more explanation or clarification.
There have been instances where the generosity of the core development
team has been taken advantage of by others who think they can do a
better job but neglected to take the key step of developing their own
product, instead cloning the WSJT-X sources for their own purposes. This
is fine for personal use, also fine if the intent is to contribute back
to the parent project but becomes annoying when it crosses the line of
passing off our work as theirs without full credit to the original
authors and copyright holders. We have had to spend a lot of time (less
so recently as R&D is now not done in the public domain) reminding these
freeloaders of their responsibilities endowed on them by the GPL licence
we release the WSJT-X suite under.
The last paragraph also should make it clear that the JT-SDK is now
somewhat redundant as the public source repository no longer contains
pre-release code so there is nothing to be gained by building from
sources compared to the latest official release be it a beta candidate
release or a full general availability release.
> In most regulatory dominions it is stated that AR is provides a
> license for self-experimentation and hence advancement. Inquisition is
> the forerunner to experimentation. There is a lot that we can all
> learn from guidance that you and the other key developers can provide.
> There is no greater utility/legacy than to leave ideas imprinted on
> others.
>
It's all there in the public domain. We give you access to everything
that makes up a release of WSJT-X. This is far more than you get for the
transceiver on your shack desk, maybe the station logging application
you use, maybe the operating system you run your shack software on. I
find it incredulous that you cite the WSJT-X project for not being open
with their innovations.
Lastly, addressing some misinformation you have been given from sources
outside of the development team.
Core development can be done on any of the supported platforms, use your
favourite it makes almost no difference although when making GUI layout
changes it helps to have all three main platforms available to check
renderings are working well on all. This last point is because where
possible the Qt GUI classes use the native style and often native
controls which can render differently on different operating systems or
window managers.
Builds are native on all platforms. I doubt a project using Qt could be
built on a Linux hosted Windows development environment but if it could
it would still be native. Hamlib could easily be built for Windows on
Linux (as I state that is still a native build) and the Hamlib team do
exactly that for their official Windows binary packages and snapshots.
We don't simply because we are using a Windows system to build and test
the rest of WSJT-X so there is no point building Hamlib elsewhere.
On macOS Xcode must be installed but only because that is the only way
(nowadays) to install the masOS development SDK and the command line
tools we need, Xcode itself is not required to build WSJT-X.
>
> That is why I ask.
>
So to summarize, IMHO anyone who is likely to be able to contribute to
the WSJT-X project source code should already be reasonably competent in
setting up a suitable environment on their favoured operating system and
any shortfalls in knowledge could be made up by specific questions here
or simply by working it out for themselves. Frankly if they can't do
that then understanding and writing code for the project is going to be
out of their reach.
For those users that can't wait for the polished releases from the
development team, the vast bulk of which are MS Windows users, there is
a leg up via the JT-SDK which is handy as MS Windows is by far the most
complex platform to get set up for any sort of cross platform project,
but because of actions by a very small minority of freeloaders that no
longer wins them anything.
For the Linux users on distributions that have no package maintainer for
WSJT-X we provide a basic recipe and a convenient source tarball that
combines building and installing from sources of both Hamlib and WSJT-X,
which makes Linux by far the easiest platform to build WSJT-X from
sources. The same dual source tarball is also a resource for package
maintainers who want to contribute by making WSJT-X available across
versions of some Linux distribution.
Lastly, please follow normal netequette practice on email lists by
starting a new thread when opening a new topic. Replying to an existing
message on another thread and changing the subject line is both poor
practice and inconvenient for subscribers that use a threaded email
client which will potentially bury your new topic email into a closed or
ignored thread. If you don't understand that then here is a screen shot
from my Thunderbird email client:
Note your new topic is linked to the message that you replied to with a
different and unrelated subject. If I had marked that thread as ignored,
which is likely due to it being answered by Joe, before your post
arrived I would simply not have seen your post.
It is laziness to not press the "Write" (new email) or "New Topic"
button just to save you having to type in the list address again. Reply
means reply to the message, not ask a different unrelated question.
> 73
>
> Steve I
>
> VK3VM / VK3SIR
>
73
Bill
G4WJS.
|
