|
Installation | Build x64 | Build x86 | Developers | Notes | Questions | Sourceforge | Download |
The JTSDK 3.4.1 evolves the kits from Windows Batch Files towards Windows PowerShell-based scripts. PowerShell is also supported in Mac and Linux environs, so common-adaptation for these purposes may occur as the kits evolve.
This started as an experiment to reduce maintenance (i.e. new package versions). The deployment environment jtsdk64-setup.ps1 will always require hard-coded base package support. Once an environment is set up maintenance tasks are simplified.
PowerShell eclipses the capabilities of Windows Batch files. PowerShell completely removes needs for capable third-party environments such as Python.
The Version 3.2 stream is a learning, discovery and technique refinement experiment.
The JTSDK 3.4.1 outwardly will appear similar to the JTSDK 3.2.0-stream. Yet the JTSDK 3.4.1 has significant enhancements in that many of the key commands now accept switches that can make the process of developing code quicker and simpler.
In addition the "mirroring" of build-hamlib.sh and build-hamlib.sh-static has been broken - with build-hamlib.sh offering a number of additional command-line switches to aid developers.
The JTSDK 3.4.1 provides a version of LibUSB 1.0.27 that we have supplied.
The project needs contributors - especially with better colour tastes - to write better documentation than what can be found here !!! |
This project is now at the Release phase of its life cycle. Primary objectives have been met (i.e. PowerShell conversion, Ability to compile latest source code to bleeding-edge Hamlib code).
Future kits will be much smaller in distribution size. You will be required to build libraries (i.e. Boost) as part of the learning process.
Current packaging preempts known cases of proposed licence and delivery condition changes.
Precompiled drop-in packages for Boost-1.74.0, Boost-1.81.0, Boost-1.82.0 , Boost-1.83.0, Boost-1.84.0 and Boost-1.85.0 built under Qt's MinGW 8.1 and MinGW 11.2 environs are available (saving 3+ hours).
The recommended mainstream development environments are Qt 5.15.2 and Boost-1.85.0 working with MinGW 8.1. |
Version 4 of the JTSDK will involve strategic re-think. Watch the JTSDK Forum for updates.
Most configuration is now based on either marker files in C:\JTSDK64-Tools\config or specified package versions listed in C:\JTSDK64-Tools\config\Versions.ini . See the JTSDK Forum and post comments (or email main contributors found there).
Heads-up advice from developers is essential. We are not 'enemies'; we are just inquisitive. Nobody asked us to do this - Nobody should have to ask in the AR community. Maintainers work on this to learn. We support the development of the skill base and hence reputation of Amateur Radio.
The Sourceforge Tests folder contains bleeding-edge efforts to translate and improve scripts. Some past scripts may not be able to be eliminated easily or in fact be converted at all.
Support for following technologies are added/enhanced in these streams:
The versions of packages supported are now able to be edited into the kit in one place - the Versions.ini file. This makes maintenance tasks easier.
PowerShell scripts are managed to tight security rules.
The kits may never be able to move away from the Windows CMD processor and its "Batch files" in order to compile JT- software.
Operational techniques have already evolved i.e. the need for qt-gen-tc has been eliminated. Some needed techniques to support 'familiarity' also have limits. Ways that processes are executed may change.
Qt under the MinGW compiler set needs to be deployed to build JT-ware. This means that there can be clashes with the MSYS2 utilities and compiler sets needed to build Hamlib and other libraries. Such clashes need to be resolved mostly via setting system paths in the correct sequence and/or sometimes diabling some tools that can conflict.
There is only a small number of us are working on this project now. More assistance is needed :-)
The complexity of the GIT code distribution system - initially conceived by Linus Torvalds of Linux fame - makes code and script management harder than it needs to be. We need a dedicated manager for this role that can teach us how to use this system more effectively.
In order to overcome isssues reported a an extras folder has been included into X:\JTSDK64-Tools\tools where additional "missing" packaged DLL's can be placed.
i.e. copy missing DLL's, such as libgfortran-4.dll into this folder for recent WSJTX-builds to succeed.
Packaging requirements are therefore met.
This option is NOT RECOMMENDED FOR LONG TERM USE. It should be used as a LAST RESORT.
Fix the actual problem - whether it be how the libraries used are built OR it may be redundant scripted requirements from legacy code that has been re-introduced.
Ensure that the marker file inside x:\JTSDK64-Tools\config is named src-wsjtx |
There are no special notes for building WSJTX at this time.
Source for WSJT-X and JTDX is development prioritised for any build process.
Ensure that the marker file inside x:\JTSDK64-Tools\config is named src-jtdx |
Issue: Unable to package WSJTX or JTDX because of NUMEROUS DLL's reported as being missing
Resolution: Issue an appropriate command to find the path of necessary libraries before performing a jtbuild package command
$env:Path += ";C:\Windows\SysWOW64\downlevel;C:\JTSDK64-Tools\tools\hamlib\qt\5.15.2\bin"
$env:Path += ";C:\Windows\SysWOW64\downlevel;C:\JTSDK64-Tools\tools\hamlib\qt\6.7.2\bin"
These paths could also be added to the main Windows system paths.
Please refer to The Questions Section for more detail.
An error message at packaging may be displayed that does not identify a DLL or missing library.
Try the following procedure:
Please refer to The Questions Section for more detail and other possible solutions to issues observed.
Ensure that the marker file inside x:\JTSDK64-Tools\config is named src-js8call |
The current release version of JS8CALL will not package if the Hamlib is built with with Dynamic libraries and LibUSB support. |
The current release version of JS8CALL will not package if the Hamlib is built with with Dynamic libraries and LibUSB support.
Ensure that the marker file inside x:\JTSDK64-Tools\config is named src-none |
Modify the source for your own requirements at your own peril.
Start with a GIT pull from your base repository. This should set markers appropriate for your development.
Execute the following command at the JTSDK64-Tools command prompt:
The "source marker" in x:\JTSDK64-Tools\config can also be renamed to hl-none for a more permanent solution.
It is highly recommended that you customise the jtbuild.ps1 script in x:\JTSDK64-Tools\tools\scripts for your own purpose and set this command as a PowerShell alias so that you do not continuously over-write your work.
These kits are focussed on users that want to build their own JT-ware releases based on the latest code available.
Details on how to do this are not provided in this documentation as one should only be tinkering with JT-ware source code if one knows how to work with both the source code and how to modify the PowerShell scripts for their needs.
Ensure that you comply with the source release requirements and terms for WSJT-X source usage - again at your own peril.
If uncertain as to what these requirements are then please ask in the WSJT-X Forum.
Please test these scripts and those in the Tests folder. Report observations either via the JTSDK Forum or the email address where most most messages come from (if you cannot post). The JTSDK Forum is used somewhat as as 'blog' as information in there is too valuable for the general IT community.
The 'core team' behind this are not PowerShell gurus.
The 'core team' behind this are not Web-Developers.
This is a learning effort. If you are a PowerShell guru PLEASE PLEASE PLEASE jump in and comment to assist. Send back BETTER SCRIPT. Teach us all.
We especially require people to make these README.md scripts better !
ALL CONTRIBUTIONS AND COMMENTS ARE GRATEFULLY WELCOMED !
For submitting bug reports and feature requests, use the Issue Tracker.
Reports, suggestions and comments via the JTSDK Forum - or via the email addresses from main contributors there of late if you do not have post access - are essential.
The aim of JTSDK64-Tools is to use an Agile delivery approach to create a high-quality, yet flexible build system.
Base ref: https://sourceforge.net/projects/hamlib-sdk/files/Windows/JTSDK-3.2-Stream/README.md
Author: Steve VK3VM/VK3SIR | Contact |