Bill, I appreciate some of what is in this as between what you and Joe have presented here as it provides a base for me and many others to sift through to obtain some clarity.
My apologies if for whatever reason some posts ended up in wrong places. Due to disabilities I work primarily off email feeds. My interest here, having disabilities myself, is to support other Amateurs that I and others work with in making this software accessible to their needs. Sometimes it requires customisation. Many here are very competent; others vary in degrees. I have formerly been teaching this sort of stuff – based on systems programming - for over 30 years in both high and low level Academic and Technical Environments. I had problems interpreting some responses. I was not alone, and some responses since my initial posts echo this observation. The purpose here is that AR is for private learning and advancement – for helping others. HAM – Help All Mankind. Please refer to the private email that I have sent as some of what is in this email is far from appropriate in an open developers’ forum – especially when AR needs to unify and rally around central leaders (as many here in this group are). 73 and thanks to you both so far, though further constructive comments and guidance would be appreciated. Stephen Ireland VK3VM / VK3SIR Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 ________________________________ From: Bill Somerville <g4...@classdesign.com> Sent: Saturday, December 8, 2018 3:32:30 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] Clear guidance - Development Environment 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: [cid:part1.87539CC0.7EDEB058@classdesign.com] 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.
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
