|
|
HAMLIB SDK Version 3Evolving the JT-ware Software Developer's Kit (JTSDK) |
|
|
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 parent Version 3.2 stream is a learning, discovery and technique refinement experiment. Subsequent versions are an evolution from this.
The JTSDK 3.4.1 outwardly will appear similar to previous JTSDK Version 3-stream releases. Yet the JTSDK 3.4.1 has significant updates and enhancements in that many of the key commands now accept switches that can make the process of developing code quicker and simpler.
The JTSDK 3.4.1 also moves away from PowerShell Windows 5.1 (The default MS-Windows-supplied version - also referred to as "PowerShell Core") to more contemporary release versions.
The JTSDK 3.4.1 solves a long standing issue with LibUSB support - that up until now has been disabled. Most changes in this preview incorporate enhancements to the MSYS2 environment to better support the LibUSB with Hamlib.
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).
Current packaging methods also preempts known cases of proposed licence and delivery condition changes.
The recommended mainstream development environments are Qt 5.15.2 and Boost-1.85.0 working with MSYS2 MinGW 8.1 - as supplied in the Base Kit. These documents will detail Boost 1.85.0 deployments.
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 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. See the next section.
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.
You may receive the following security notification:
Execution Policy Change The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the about_Execution_Policies help topic at https:/go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"):
It is safe to select Y. These scripts are not any processor flaw tests. Remember that developing these scripts is also a learning exercise for the Development Team.
The basic concept of supporting Windows Environment Variables through PowerShell $env:
The JTSDK64-3.4.1 can be installed over the top of previous kits - although it is highly recommended that you start from scratch.
It is highly recommended that kits are deployed into Virtual machines (see "Deployment" section).
It is highly recommended that a new, fresh deployment be considered with each new base package release.
You can keep old deployment(s) by closing all open environment windows and renaming the deployment folder (i.e. C:\JTSDK64-Tools to C:\JTSDK64-Tools-Old)
If you need to revert back to your old deployment then all you need do is rename that folder back to its original filename (i.e. C:\JTSDK64-Tools-Old back to C:\JTSDK64-Tools)
Maintenance updates will be applied in the form of "Update" packages. There is no current update package available. The first update to the JTSDK64-3.4.1 would be JTSDK64-3.4.1-U1.exe .
Note: Maintainers are no longer supporting the "Base" and "Tools" nomenclature.
| It is ESSENTIAL that any available update packages be applied to a deployment. |
You do not need to apply previous update packages. Just deploy the latest update package that is available as it contains all previous updates for that stream.
These steps assume that you have a deployed base environment
Note: There is no current update package.
Updates may apply to the MSYS2 environment. Therefore the "profile" directory for MSYS2 must be deleted and re-created.
i.e: PowerShell: Remove-Item "C:\JTSDK64-Tools\tools\msys64\home*" -Recurse -Force
Note: The src directory in your backup shoudl contain your previous work. It is safe to copy this enture foler across to your new MSYS2 Profile.
You will need to pull down your Hamlib repository again and/or restore any custom work to folders created within the MSYS2 environment. See Step 3b below.
It is recommended to deploy the JTSDK into a fresh Windows Virtual Machine. For those unfamiliar with "Virtual Machines" and "Virtualisation Technologies" you shoud refer to https://www.redhat.com/en/topics/virtualization/what-is-virtualization .
Note: Almost EVERY CPU that Runs Windows x64 these days has virtualisation support.
If you have concerns please refer to https://www.technorms.com/8208/check-if-processor-supports-virtualization .
There are lots of virtualisation environments available. Click on the links below to obtain details on how to deploy these systems:
Trial Virtual Machine images for Windows 10 (with Microsoft's Compiler Suite) can be downloaded from https://developer.microsoft.com/en-us/windows/downloads/virtual-machines.
These Virtual machines should have a lifetime of at least 30 days.
Due to changes within CMake from version 3.28.0 onwards, it may be necessary to have a current deployment of WSJT-X and/or your JT-ware variant that you are working on deployed and IN THE SEAERCH PATH.
Obtain a current release version of your product from:
Install the base package so that it can be found in the Windows search path.
Note that these instructions assumes a fresh Windows 11 Virtual Machine is used.
| The latest "Tools" package (if available) can be found at https://sourceforge.net/projects/hamlib-sdk/files/Windows/JTSDK-4.0-Stream/ . |
It is recommended to use all the default settings and file locations provided by the installer.
It is recommended that you disable real-time scanning for your Antivirus program. This can significantly slow down deployment.
As users will have many varied solutions (Including the most common option being Windows Antivirus) the steps to do this will not be documented here.
When you start up the JTSDK64-Setup environment in Windows 11 you may notice the following:
-------------------------------------------
JTSDK Setup v3.4.1
-------------------------------------------
Required Tools
PowerShell ..... 5.1.26100.1882
VC Runtimes .... Not Installed
Git ............ Not Installed
OmniRig ........ Not Installed
Qt Tool Chain(s) Deployed
Qt: none
Tools: none
Optional Components
VS Code ........ Not Installed
Boost .......... Not Installed
Post Install / Manual Setup Commands
Main Install ... postinstall
MSYS2 Shell .... msys2
PS C:\JTSDK64-Tools>
Commence Deployment with the following command:
The command postinstall starts the deployment process.
------------------------------------------------------ JTSDK64 Tools Post Install/Redeployment Selections ------------------------------------------------------ At the prompts indicate which components you want to install or redeploy. For VC Runtimes, OmniRig, Git, MSYS2 and VS Code use: --> Y/Yes or N/No Qt deployment now just runs the Installer and/or Maintenance Tool and no longer offers a scripted deployment option. Use: --> Y/Yes or N/No NOTE: VC Runtimes, Git, Qt and MSYS2 are mandatory to build JT-software. The Latest PowerShell is highly recommended. * Enter Your Install/Redeployment Selection(s): (recommended) Latest PowerShell (Y|N) .:
It is highly recommended (for performance reasons) that you deploy the latest PowerShell Core .
(required) VC/C++ Runtimes (Y|N) .....:
The Visual C/C++ Runtimes are required.
(required) OmniRig (Y|N) ..............:
The OmniRig Rig Control tool is required.
(required) Git-SCM (Y|N) ..............:
The Git-SCM is required.
(required) Qt (Y|N) ...................:
Note: Qt 5.15.2 is NO LONGER AVAILABE THROUGH MAINSTREAM REPOSITORIES.
Qt 5.15.2 and any later versions, plus their support tools (i.e. MinGW 8.1, MinGW 13.1) must be deployed manually. Qt 5.15.2 must be deployed from "Archive" repositories......................
As it is impractical to script deployment from Archive repos, scripted deployments have been removed. One must manually deploy Qt and its components.
(required) MSYS2 Setup (Y|N) .........:
You are required to set up the MSYS2 environment.
(optional) VS Code (Y|N) .............:
Visual Studio Code is an optional component. VS Code is an excellent editor for working with PowerShell scripts (if you need to customise these yourself). It also has a number of useful code formatter addins.
Note that deploying VS Code is not mandatory for JTSDK operation.
You are then presented with the selections you have made:
* Your Installation Selections: --> Latest PowerShell ................: Y --> VC Runtimes ......................: Y --> OmniRig ..........................: Y --> Git ..............................: Y --> Qt ...............................: Y --> MSYS2 ............................: Y --> VS Code ..........................: Y
During this phase some tools will require some interaction at the keyboard or via the mouse (especially the Qt deployment as one MUST now have their own account and agree to their licensing terms).
| Follow on-screen prompts carefully. |
| Manual intevention with installation programs will be required. |
| If anything goes wrong RE-START the postinstall script, selecting 'N' to the option that failed. |
Refer any installation issues issues to the JTSDK Forum
A set of resources for deploying Qt 5.15.2 is available at https://hamlib-sdk.sourceforge.io/Qt/indexQt.html
Qt MUST be deployed to x:\JTSDK64-Tools\tools\Qt .
The resource https://hamlib-sdk.sourceforge.io/Qt/UDQT.html details how to deploy Qt 5.15.2 from Archive.
A MSYS2 environment window will open as part of the postinstall process.
JTSDK64 Tools MSYS2 (MSYS) For main menu, type ..: menu For Help Menu, type ..: jthelp Copyright (C) 2013-2024, GPLv3, Greg Beam, KI7MT and JTSDK Contributors. This is free software; There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. sdk@radio ~ $
------------------------------------- JTSDK64 Tools Main Menu ------------------------------------ 1. Set MSYS2 path to find Qt compilers 2. Update MSYS2 3. Install Hamlib dependencies 4. Install msys64 GNU Compilers 5. Install FL-app dependencies 6. Update MSYS2 Keyring (Deprecated) 7. Build Hamlib - Static Libraries 8. Build Hamlib - Dynamic Package 9. Add Hamlib to pkgconfig a. Clear Hamlib Source b. Select HAMLIB Repository h. List help commands v. List version information e. Enter 'e' or 'q' to exit Enter your selection, then hit:
Perform the following steps:
Note that the window may close on completion if there are updates.
Perform the following steps:
| The basic deployment is now complete. |
Once complete you should exit the JTSDK64-Setup environment.
Perform the following step:
As of March 2024 it has been observed that Qt 5.15.2 is no longer available from "Mainstream" installer sources
| Qt 5.15.2 is still available from "Archive" ast the time of writing. This means that Qt must be deployed manually from "Archive" Repositories |
By this stage you should already have Qt deployed
Yoiu can add additional kits such as Qt 6.7.2 along with its MinGW 13.1.0 components and the Qt Maintenance Tool.
| See the guide https://sourceforge.net/projects/hamlib-sdk/files/JTware-Deployment/Deploying-Archived-Versions-of-Qt-via-Maintenance-Tool.docx for latest instructions |
Example: Adding additional Qt Kits
Perform the following steps:
To add Qt 6.7.2 (as an example):
On Completion:
There must only be ONE marker file indicating the Qt version selected in x:\JTSDK64-Tools\config If the system abends with a warning check the x:\JTSDK64-Tools\config directory and remove the unwanted item with the prefix 'qt' |
In JTSDK64-Tools:
Note: If you have difficulties packaging Hamlib with JTDX and/or JS8CALL you may need to use the The build-hamlib.sh script from the MSYS2 terminal as follows:
This will take time as it pulls from the master repository for Hamlib.
Source distribution repositories can be changed by changing the marker file in x:\JTSDK64-Tools\config
| ** THIS IS SLOW **. Despite "dropins" being available on the Sourceforge and Github the best procedure is to build your own. |
In JTSDK64-Tools:
Around 90 minutes later you should now have a deployment of Boost based at the recommended v1.84.0 (configurable in C:\JTSDK64-Tools\config\Versions.ini) that is suitable to build JT-ware under your selected Qt version on your machine.
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 are available - saving many hours..
Extract the folder for the Boost version-package that you want to use into x:\JTSDK64-Tools\tools\boost (create the directory if it does not exist) and then remove the -8.1 or -11.2 suffix !
A Windows symbolic link will also work with a drop-in package. Refer to the example below:
Note: The preference is to build your own Boost package and NOT use these "dropins".
| A commandlet Reset-Boost.ps1 is available to reset Boost builds. |
| Environments should now be complete for building JT-ware |
| There are build errors at the final packaging stage that may arise that can be overcome with this simple set of steps.. |
General JT-ware Packaging Issues: Support for an "extras" folder
In order to overcome several issues 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.
There is a JTDX-specific build issue (that may have already been addressed) that can be fixed quite easily by adding components into the WIndows search path.
On your Windows Destop:
Note: This is a temporary work-arround (if it has not been addressed already). Hopefully JTDX CMakeFile scripts will be updated in a future release so these patches are no longer requried.
The release-source-code pulled is for the latest JT-software release. The JT-source that you pull is configurable from C:\JTSDK64-Tools\config. Rename the file src-wsjtx from a default pull of WSJT-X to either src-jtdx or src-js8call if desired.
The "major" used Jt-ware distributions are supported without discrimination or political comment.
In JTSDK64-Tools:
Options preferred are package (a Windows Installer package - the preferred "clean" way) and rinstall (just a static directory full of "runnable" files).
Both the jtbuild and build-hamlib- scripts now contain a number of switches that can be used to disable default features of the scripts.
Use the embedded help facilities to discover the currently available set of switches:
i.e. 1: In The PowerShell Environment:
PS C:\JTSDK64-Tools> jtbuild -h
--------------------------------------------
Default Build Commands
--------------------------------------------
Usage .....: jtbuild [ OPTION ] [[ SWITCH ]]
Examples...: jtbuild rinstall
: jtbuild rinstall -ng
Options:
rconfig Release, Config Only
dconfig Debug, Config Only
rinstall Release, Non-packaged Install
dinstall Debug, Non-packaged Install
package Release, Windows Package
docs Release, User Guide
Switches:
Switches only work if an [ OPTION ] is supplied.
-nc Do not run configure
-ng Do not check/pull source
* To Display this message, type .....: jtbuild -h
PS C:\JTSDK64-Tools>
i.e. 2: In The MSYS2 Environment:
---------------------------------------------------------------
BUILD-HAMLIB - HELP
---------------------------------------------------------------
* Available Command Line Options:
--> -h ........: Help
--> -b/-nb ....: Process / Do not process bootstrap
--> -c/-nc ....: Process / Do not process configure
--> -g/-ng ....: Process / Do not pull/check source from GIT repository
--> -libusb ...: Configure with LibUSB support
--> -nlibusb ..: Do not configure with LibUSB support
--> -static ...: Statically Linked Libraries built
or ..
--> -dynamic ..: Shared/Dynamically Linked Libraries built
* Note: You cannot select -static with -dynamic
If using switches you may need to combine options to over-ride default build behaviour:
i.e.: build-hamlib -nb reverts to Hamlib default STATIC build behaviour
build-hamlib -nb -dynamic over-rides this behaviour
radio@radio ~
$
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. 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-4.0-Stream/README.md
| Editor: Steve VK3VM/VK3SIR | Contact |