Releases: hamlibdk/HAMLIB-SDK
Version 4.1.0 Beta 1
JTSDK64 Applications and Tools: Beta 1 (Development)
JTSDK Version 4.1 Stream
The Version 4.1 stream is a learning, discovery and technique refinement experiment.
Direction
The JTSDK 4.1.0 matures the evolution of 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.
An immediate aim is to also provide Windows aarch64 kits. Please watch this space.
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][].
Release Notes: 4.1 Stream
This README.md file includes deployment instructions. The very latest news - including tips
to solve issues - can be found at https://hamlib-sdk.sourceforge.io/ .
The JTSDK 4.1.0 walks back some of the Qt deployment automation removed in [JTSDK64-3.4.1][] .
Outwardly this stream will initially appear similar to past kits. Yet the JTSDK 4.1.0
demonstrates significant enhancements and script redesigns.
[JTSDK64-4.1.0][] ships with with basic [MSYS2][] and mingw64 compilers and tools pre-deployed.
This kit only supports the construction of 64-bit software.
Future releases will aim to deploy Windows aarch64-based kits.
The preferred [MSYS2][] development environment for building Hamlib is now executed by typing
mingw64 at the [PowerShell][] prompt.
The major changes from earlier versions include:
- Script inside PowerShell and Shell Scripts have been optimised with redundant documented code removed.
- The display unit inside jtsdk64.ps1 (default display message) has been changed !
- References to the G4WJX(sk) and W4MDN(sk) Hamlib repos have been removed.
- The "hlnone" and "hlmaster" empty files as repository markers have been moved into the key hlrepo in Versions.ini
This kit primarily walks back any efforts to "Qt-versionise" deployments of Hamlib. In the past this was necessary.
This kit no longer needs to do that as it builds Hamlib SOLELY under its (updated) MinGW/MSYS2 Environment.
This should also make the construction of other software packages that require [Hamlib][] easier.
Release Notes: Updates
There are currently no update packages available.
The first update package, when available, would be [JTSDK64-4.1.0-U1][].
If (and when) available, apply this package to a base [JTSDK64-4.1.0][] before performing any post-installation steps.
If your [JTSDK64-4.1.0][] is functional and fully deployed then it can be applied to this installation. Ensure that you back up your Versions.ini file before proceeding. Customise your Versions.ini settings, based on your backup, for your preferred versions of utilities after deployment.
The Project needs contributors - Especially for AARCH64 development, Management and to write Cross-Language Documentation !
Up To Date Documentation
The most up-to date documentation and bleeding-edge notes can be found at:
- https://hamlib-sdk.sourceforge.io/ <== The Base Site and the first place to look for information
- https://groups.io/g/JTSDK/ <== The Help Forum ( jtsdk @ groups.io )
Project Status
This project is now at the Instigation 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 1.88 ) as part of the learning process.
Current packaging preempts known cases of proposed licence and delivery condition changes.
Precompiled drop-in packages are no longer available as Sourceforge, our project host, are auditing space.
The recommended development environment should be [JTSDK64-4.1.0][] with its latest update applied (if an update is available).
Conventions used in this document.
Drive paths will be referred to as x: (i.e. x:\JTSDK64-Tools\config) , where x: is the default deployment drive
- x: as used in this guide in most cases can be replaced with c:
Kit Construction
The kit is derived from techniques first documented by Greg KI7MT.
Most configuration is now based on either marker files in x:\JTSDK64-Tools\config
or specified package versions listed in x:\JTSDK64-Tools\config\Versions.ini .
See the [JTSDK Forum][] and post comments (or email main contributors found there).
Support
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.
Added Support and Features
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:
- Hamlib support for other non-JT-software packages (will occur silently???).
- [Qt][]'s incorporated [CMAKE][] is now the recommended [CMAKE][] tool.
- The version of [Boost][] can be selected in Version.ini and will be compiled to the selected version of Qt (including its MinGW release).
- Greater package version self-configuration - hence less maintenance required.
- Upgrades to "static" apps that have no generically named latest-version sources
- Versions of Qt 5 and 6 to be deployed can be set in keys within Version.ini , saving considerable amounts of time maintaining respurces (i.e. when the Qt Maintainers update packages that are available to Open Sorce users)
- PowerShell by default is set a PowerShell Windows 5.1. This can be actively changed to the latest deployable package by setting a key within Version.ini
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.
Limitations
[PowerShell][] scripts are managed to tight security rules. See the next section.
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.
[PowerShell][] Security Warnings
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.
Windows Environment Variables
The basic concept of supporting Windows Environment Variables through [PowerShell][]
$env: facilities that ease access into [CMAKE][], QMake and the MinGW compilers
will remain a cornerstone concept.
Upgrades from Versions earlier than Version 4.1.0
The [JTSDK64-4.1.0][] cannot be installed over the top of previous kits.
A new, fresh deployment be considered with this release.
Should you try an upgrade, you may need to back-up/re-name your X:\JTSDK64-Tools\tools\msys64 environment if you are performing an upgrade.
i.e:
- Close any open JTSDK64-Tools and MSYS2/mingw64 environments.
- Before starting the upgrade, open a Windows File Manager instance.
- Navigate to *X:\JTSDK64-Tools\tools*
- Using the Windows File Manager, rename the msys64 directory to something like msys64-orig
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-orig back to C:\JTSDK64-Tools)
You should, after deployment, be able to recover anything that you need from your MSYS2 user profile to your new MSYS2 deployment.
It is recommended that kits are deployed into Virtual machines (see "Deployment" section).
M...
Version 4.1.0 Alpha 1
JTSDK64 Applications and Tools: Pre-Release (Development)
JTSDK Version 4.1 Stream
The Version 4.1 stream is a learning, discovery and technique refinement experiment.
Direction
The JTSDK 4.1.0 matures the evolution of 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.
An immediate aim is to also provide Windows aarch64 kits. Please watch this space.
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][].
Release Notes: 4.1 Stream
This README.md file includes deployment instructions. The very latest news - including tips
to solve issues - can be found at https://hamlib-sdk.sourceforge.io/ .
The JTSDK 4.1.0 walks back some of the Qt deployment automation removed in [JTSDK64-3.4.1][] .
Outwardly this stream will initially appear similar to past kits. Yet the JTSDK 4.1.0
demonstrates significant enhancements and script redesigns.
[JTSDK64-4.1.0][] ships with with basic [MSYS2][] and mingw64 compilers and tools pre-deployed.
This kit only supports the construction of 64-bit software.
Future releases will aim to deploy Windows aarch64-based kits.
The preferred [MSYS2][] development environment for building Hamlib is now executed by typing
mingw64 at the [PowerShell][] prompt.
The major changes from earlier versions include:
- Script inside PowerShell and Shell Scripts have been optimised with redundant documented code removed.
- The display unit inside jtsdk64.ps1 (default display message) has been changed !
- References to the G4WJX(sk) and W4MDN(sk) Hamlib repos have been removed.
- The "hlnone" and "hlmaster" empty files as repository markers have been moved into the key hlrepo in Versions.ini
This kit primarily walks back any efforts to "Qt-versionise" deployments of Hamlib. In the past this was necessary.
This kit no longer needs to do that as it builds Hamlib SOLELY under its (updated) MinGW/MSYS2 Environment.
This should also make the construction of other software packages that require [Hamlib][] easier.
Release Notes: Updates
There are currently no update packages available.
The first update package, when available, would be [JTSDK64-4.1.0-U1][].
If (and when) available, apply this package to a base [JTSDK64-4.1.0][] before performing any post-installation steps.
If your [JTSDK64-4.1.0][] is functional and fully deployed then it can be applied to this installation. Ensure that you back up your Versions.ini file before proceeding. Customise your Versions.ini settings, based on your backup, for your preferred versions of utilities after deployment.
The Project needs contributors - Especially for AARCH64 development, Management and to write Cross-Language Documentation !
Up To Date Documentation
The most up-to date documentation and bleeding-edge notes can be found at:
- https://hamlib-sdk.sourceforge.io/ <== The Base Site and the first place to look for information
- https://groups.io/g/JTSDK/ <== The Help Forum ( jtsdk @ groups.io )
Project Status
This project is now at the Instigation 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 1.88 ) as part of the learning process.
Current packaging preempts known cases of proposed licence and delivery condition changes.
Precompiled drop-in packages are no longer available as Sourceforge, our project host, are auditing space.
The recommended development environment should be [JTSDK64-4.1.0][] with its latest update applied (if an update is available).
Conventions used in this document.
Drive paths will be referred to as x: (i.e. x:\JTSDK64-Tools\config) , where x: is the default deployment drive
- x: as used in this guide in most cases can be replaced with c:
Kit Construction
The kit is derived from techniques first documented by Greg KI7MT.
Most configuration is now based on either marker files in x:\JTSDK64-Tools\config
or specified package versions listed in x:\JTSDK64-Tools\config\Versions.ini .
See the [JTSDK Forum][] and post comments (or email main contributors found there).
Support
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.
Added Support and Features
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:
- Hamlib support for other non-JT-software packages (will occur silently???).
- [Qt][]'s incorporated [CMAKE][] is now the recommended [CMAKE][] tool.
- The version of [Boost][] can be selected in Version.ini and will be compiled to the selected version of Qt (including its MinGW release).
- Greater package version self-configuration - hence less maintenance required.
- Upgrades to "static" apps that have no generically named latest-version sources
- Versions of Qt 5 and 6 to be deployed can be set in keys within Version.ini , saving considerable amounts of time maintaining respurces (i.e. when the Qt Maintainers update packages that are available to Open Sorce users)
- PowerShell by default is set a PowerShell Windows 5.1. This can be actively changed to the latest deployable package by setting a key within Version.ini
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.
Limitations
[PowerShell][] scripts are managed to tight security rules. See the next section.
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.
[PowerShell][] Security Warnings
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.
Windows Environment Variables
The basic concept of supporting Windows Environment Variables through [PowerShell][]
$env: facilities that ease access into [CMAKE][], QMake and the MinGW compilers
will remain a cornerstone concept.
Upgrades from Versions earlier than Version 4.1.0
The [JTSDK64-4.1.0][] cannot be installed over the top of previous kits.
A new, fresh deployment be considered with this release.
Should you try an upgrade, you may need to back-up/re-name your X:\JTSDK64-Tools\tools\msys64 environment if you are performing an upgrade.
i.e:
- Close any open JTSDK64-Tools and MSYS2/mingw64 environments.
- Before starting the upgrade, open a Windows File Manager instance.
- Navigate to *X:\JTSDK64-Tools\tools*
- Using the Windows File Manager, rename the msys64 directory to something like msys64-orig
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-orig back to C:\JTSDK64-Tools)
You should, after deployment, be able to recover anything that you need from your MSYS2 user profile to your new MSYS2 deployment.
It is recommended that kits are deployed into Virtual machines (see "Deployment" section).
...
v4.0.0
JTSDK64 Applications and Tools
JTSDK Version 4.0 Stream
The Version 4.0 stream is a learning, discovery and technique refinement experiment.
Direction
The JTSDK 4.0.0 matures the evolution of 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.
An immediate aim is to also provide Windows aarch64 kits. Please watch this space.
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][].
Release Notes: 4.0 Stream
As of [JTSDK64-3.4.0][] there are no longer distinctions between "Base" and "Tools" packages. There will just me "Main Releases" and "Updates".
- Under the [JTSDK64-3.2-Stream][] the "Base Package" was [JTSDK64-Base-3.2.3][]. Under the JTSDK64-4.0-Stream the former "Base" deployment package will become [JTSDK64-4.0.0][].
- Under the [JTSDK64-3.2-Stream][] the "Patch Package" was [JTSDK64-Tools-3.2.3.3][]. Under the JTSDK64-4.0-Stream the "Update" packages will become/is [JTSDK64-4.0.0-U3][].
The Main deployment package - [JTSDK64-4.0.0][] - can be downloaded at https://sourceforge.net/projects/hamlib-sdk/files/Windows/JTSDK-4.0-Stream/JTSDK64-4.0.0.exe
The Update deployment package - [JTSDK64-4.0.0-U3][] - can be downloaded at https://sourceforge.net/projects/hamlib-sdk/files/Windows/JTSDK-4.0-Stream/JTSDK64-4.0.0-U3.exe
This README.md file includes deployment instructions. The very latest news - including tips
to solve issues - can be found at https://hamlib-sdk.sourceforge.io/ .
The JTSDK 4.0.0 walks back some of the Qt deployment automation removed in [JTSDK64-3.4.1][] .
There are also updates to some utilities and Libraries (i.e. NSIS 3.09, Updates to Ruby, LibUSB bumped to Version 1.0.27).
Outwardly this stream will initially appear similar to past kits. Yet the JTSDK 4.0.0
demonstrates significant enhancements and script redesigns.
[JTSDK64-4.0.0][] ships with with basic [MSYS2][] and mingw64 compilers and tools pre-deployed.
This kit only supports the construction of 64-bit software.
Future releases will aim to deploy Windows aarch64-based kits.
The preferred [MSYS2][] development environment for building Hamlib is now executed by typing
mingw64 at the [PowerShell][] prompt.
Release Notes: Updates
An update package [JTSDK64-4.0.0-U3][] is available for [JTSDK64-4.0.0][] .
This package provides some basic scripting updates/enhancements as well as updates for:
- LibUSB (to Version 1.0.28)
- Ruby (to Version 3.4.3-1)
- NSIS (to Version 3.11)
- Boost (to Version 1.88.0)
Apply this package to a base [JTSDK64-4.0.0][] before performing any post-installation steps.
If your [JTSDK64-4.0.0][] is functional and fully deployed then it can be applied to this installation. Ensure that you back up your Versions.ini file before proceeding. Customise your Versions.ini settings, based on your backup, for your preferred versions of utilities after deployment.
The Project needs contributors - Especially for management and to write Cross-Language Documentation !
Up To Date Documentation
The most up-to date documentation and bleeding-edge notes can be found at:
- https://hamlib-sdk.sourceforge.io/ <== The Base Site and the first place to look for information
- https://groups.io/g/JTSDK/ <== The Help Forum
Project Status
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 1.85 ) as part of the learning process.
Current packaging preempts known cases of proposed licence and delivery condition changes.
Precompiled drop-in packages are no longer available as Sourceforge, our project host, are auditing space.
The recommended development environment should be [JTSDK64-4.0.0][] with the latest update [JTSDK64-4.0.0-U3][] applied.
Conventions used in this document.
Drive paths will be referred to as x: (i.e. x:\JTSDK64-Tools\config) , where x: is the default deployment drive
- x: as used in this guide in most cases can be replaced with c:
Kit Construction
The kit is derived from techniques first documented by Greg KI7MT.
Most configuration is now based on either marker files in x:\JTSDK64-Tools\config
or specified package versions listed in x:\JTSDK64-Tools\config\Versions.ini .
See the [JTSDK Forum][] and post comments (or email main contributors found there).
Support
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.
Added Support and Features
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:
- Hamlib support for other non-JT-software packages (will occur silently???).
- [Qt][]'s incorporated [CMAKE][] is now the recommended [CMAKE][] tool.
- The version of [Boost][] can be selected in Version.ini and will be compiled to the selected version of Qt (including its MinGW release).
- Greater package version self-configuration - hence less maintenance required.
- Upgrades to "static" apps that have no generically named latest-version sources
- Versions of Qt 5 and 6 to be deployed can be set in keys within Version.ini , saving considerable amounts of time maintaining respurces (i.e. when the Qt Maintainers update packages that are available to Open Sorce users)
- PowerShell by default is set a PowerShell Windows 5.1. This can be actively changed to the latest deployable package by setting a key within Version.ini
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.
Limitations
[PowerShell][] scripts are managed to tight security rules. See the next section.
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.
[PowerShell][] Security Warnings
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.
Windows Environment Variables
The basic concept of supporting Windows Environment Variables through [PowerShell][]
$env: facilities that ease access into [CMAKE][], QMake and the MinGW compilers
will remain a cornerstone concept.
Upgrades from Versions earlier than Version 4.0.0
The [JTSDK64-4.0.0][] cannot be installed over the top of previous kits.
A new, fresh deployment be considered with this release.
Should you try an upgrade, you may need to back-up/re-name your X:\JTSDK64-Tools\tools\msys64 environment if you are performing an upgrade.
i.e:
- Close any open JTSDK64-Tools and MSYS2 Terminal Windows.
- Before starting the upgrade, open a Windows File Manager instance.
- Navigate to *X:\JTSDK64-Tools\tools*
- Using the Windows File Manager, rename the msys64 directory to something like msys64-orig
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-orig back to C:\JTSDK64-Tools)
You should, after deployment, be able to recover anything that you need from your MSYS...
Version 4.0.0 Beta 1
The JTSDK 4.0.0 is now into Beta Release Status.
[ Functionality updates - unless significant - will be frozen ]
Please peruse the documentation and recommend updates and changes.
See: https://hamlib-sdk.sourceforge.io/
Also please comment on the README.md file !
v4.0.0.0a7
JTSDK64 Applications and Tools
JTSDK Version 4.0 Stream
This kit is in ALPHA RELEASE !
This means that primary operational objectives have been met (i.e. Qt deployed to C:\Qt) It also means that there may be operational bugs !!!
This packaging is FAR FROM PERFECT !
Documentation is VERY IMMATURE.
Please test. Comment back on [email protected] !
The Version 4.0 stream is a learning, discovery and technique refinement experiment.
Direction
The JTSDK 4.0.0 matures the evolution of 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.
An immediate aim is to also provide Windows aarch64 kits. Please watch this space.
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][].
Release Notes: 4.0 Stream
As of [JTSDK64-3.4.0][] there are no longer distinctions between "Base" and "Tools" packages. There will just me "Main Releases" and "Updates".
- Under the [JTSDK64-3.2-Stream][] the "Base Package" was [JTSDK64-Base-3.2.3][]. Under the JTSDK64-4.0-Stream the former "Base" deployment package will become [JTSDK64-4.0.0][].
- Under the [JTSDK64-3.2-Stream][] the "Patch Package" was [JTSDK64-Tools-3.2.3.3][]. Under the JTSDK64-4.0-Stream the "Update" packages will become [JTSDK64-4.0.0-U1][].
The Main deployment package - [JTSDK64-4.0.0][] - can be downloaded at https://sourceforge.net/projects/hamlib-sdk/files/Windows/JTSDK-4.0-Stream/JTSDK64-4.0.0.exe
This README.md file includes deployment instructions. The very latest news - including tips
to solve issues - can be found at https://hamlib-sdk.sourceforge.io/ .
The JTSDK 4.0.0 walks back some of the Qt deployment automation removed in [JTSDK64-3.4.1][] .
There are also updates to some utilities and Libraries (i.e. NSIS 3.09, Updates to Ruby, LibUSB bumped to Version 1.0.27).
Outwardly this stream will initially appear similar to past kits. Yet the JTSDK 4.0.0
demonstrates significant enhancements and script redesigns.
[JTSDK64-4.0.0][] ships with with basic [MSYS2][] and mingw64 compilers and tools pre-deployed.
This kit only supports the construction of 64-bit software.
Future releases will deploy Windows aarch64-based kits. Note that the Raspberry Pi 5 hardware platform is used in this project.
There are patches for x86 builds maintained by The Hamlib SDK Development Team and Uwe DG2YCB
that will be advised here and on the [JTSDK Forum][].
The preferred [MSYS2][] development environment for building Hamlib is now executed by typing
mingw64 at the [PowerShell][] prompt.
Release Notes: Updates
Currently there are no Update packages available. The first update package for this stream would be An update package [JTSDK64-4.0.0-U1][].
The Project needs contributors - Especially for management and to write Cross-Language Documentation !
Up To Date Documentation
The most up-to date documentation and bleeding-edge notes can be found at:
- https://hamlib-sdk.sourceforge.io/ <== The Base Site and the first place to look for information
- https://groups.io/g/JTSDK/ <== The Help Forum
Project Status
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 1.85 ) 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.85.0][]
are available - saving many hours. Note that the continued production of these files is under review.
[Boost-1.85.0][] is built with and supplied under Qt's 5.15.2 MinGW 8.1 environs.
Note: It is not recommended to use [Boost-1.86.0][] with [Qt][] 5.15.2 as there are some build and compatability issues experienced at the time of kit development.
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 -7.3, -8.1 or -11.2 suffix !
The recommended development environment should be [JTSDK64-4.0.0][] with the latest update applied i.e [JTSDK64-4.0.0-U1][] if available.
The current environment incorporates [Qt][] 5.15.2 and support for building [Boost-1.85.0][] working with MinGW 8.1 under
the mingw64 [MSYS2][] environment.
The Next Steps
Version 4 of the JTSDK will involve a number of strategic re-thinks - and will be developed actively once
[Qt][] 5.15.2 is unavailable for deployment.
Watch the [JTSDK Forum][] for updates and to contribute.
Conventions used in this document.
Drive paths will be referred to as x: (i.e. x:\JTSDK64-Tools\config) , where x: is the default deployment drive
- x: as used in this guide in most cases can be replaced with c:
Kit Construction
The kit is derived from techniques first documented by Greg KI7MT.
Most configuration is now based on either marker files in x:\JTSDK64-Tools\config
or specified package versions listed in x:\JTSDK64-Tools\config\Versions.ini .
See the [JTSDK Forum][] and post comments (or email main contributors found there).
Support
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.
Added Support and Features
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:
- Hamlib support for other non-JT-software packages (will occur silently???).
- [Qt][]'s incorporated [CMAKE][] is now the recommended [CMAKE][] tool.
- The version of [Boost][] can be selected in Version.ini and will be compiled to the selected version of Qt (including its MinGW release).
- Greater package version self-configuration - hence less maintenance required.
- Upgrades to "static" apps that have no generically named latest-version sources
- Versions of Qt 5 and 6 to be deployed can be set in keys within Version.ini , saving considerable amounts of time maintaining respurces (i.e. when the Qt Maintainers update packages that are available to Open Sorce users)
- PowerShell by default is set a PowerShell Windows 5.1. This can be actively changed to the latest deployable package by setting a key within Version.ini
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.
Limitations
[PowerShell][] scripts are managed to tight security rules. See the next section.
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.
[PowerShell][] Security Warnings
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.
Windows Environment Variables
The basic concept of supporting Windows Environment Variables through [PowerShell][]
$env: facilities that ease access into [CMAKE][], QMake and the MinGW compilers
will remain a cornerstone concept.
Upgrades from Versions earlier than Version 4.0.0
...
Version 3.4.1
JTSDK64 Applications and Tools
JTSDK Version 3.4 Stream
The Version 3.4 stream is a learning, discovery and technique refinement experiment.
Direction
The JTSDK 3.4.1 matures the evolution of 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][].
Release Notes: 3.4 Stream
As of [JTSDK64-3.4.1][] there are no longer distinctions between "Base" and "Tools" packages. There will just me "Main Releases" and "Updates".
- Under the [JTSDK64-3.2-Stream][] the "Base Package" was [JTSDK64-Base-3.2.3][]. Under the [JTSDK64-3.4-Stream][] the former "Base" deployment package will become [JTSDK64-3.4.1][].
- Under the [JTSDK64-3.2-Stream][] the "Patch Package" was [JTSDK64-Tools-3.2.3.3][]. Under the [JTSDK64-3.4-Stream][] the "Update" packages will become [JTSDK64-3.4.1-U1][].
The Main deployment package - [JTSDK64-3.4.1][] - can be downloaded at https://sourceforge.net/projects/hamlib-sdk/files/Windows/JTSDK-3.4-Stream/JTSDK64-3.4.1.exe
This README.md file includes deployment instructions. The very latest news - including tips
to solve issues - can be found at https://hamlib-sdk.sourceforge.io/ ( see https://hamlib-sdk.sourceforge.io/QU.html ).
The JTSDK 3.4.1 primarily integrates the new nomenclature and former "Tools" package [JTSDK64-Tools-3.2.3.3][]
integrated fully into [JTSDK64-Base-3.2.3][] .
There are also updates to some utilities and Libraries (i.e. NSIS 3.09, Updates to Ruby, LibUSB bumped to Version 1.0.27).
Outwardly will appear similar to past kits. Yet the JTSDK 3.2.3
has significant enhancements - centred around Hamlib being deployed now as a DLL -
in that many of the key commands now accept switches that can make the process of developing
code quicker and simpler.
[JTSDK64-3.4.1][] with basic [MSYS2][] and mingw64 compilers and tools pre-deployed.
This kit only supports the construction of 64-bit software.
There are patches for x86 builds maintained by The Hamlib SDK Development Team and Uwe DG2YCB
that will be advised here and on the [JTSDK Forum][].
The preferred [MSYS2][] development environment for building Hamlib is now executed by typing
mingw64 at the [PowerShell][] prompt.
Release Notes: Updates
Currently there are no Update packages available. The first update package for this stream would be An update package [JTSDK64-3.4.1-U1][].
The Project needs contributors - Especially for management and to write Cross-Language Documentation !
Up To Date Documentation
The most up-to date documentation and bleeding-edge notes can be found at:
- https://hamlib-sdk.sourceforge.io/ <== The Base Site and the first place to look for information
- https://groups.io/g/JTSDK/ <== The Help Forum
Project Status
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 1.85 ) 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.82.0][], [Boost-1.83.0][], [Boost-1.84.0][] and [Boost-1.85.0][]
are available - saving many hours. Note that the continued production of these files is under review.
- [Boost-1.74.0][] is built with and supplied under Qt's MinGW 7.3 and MinGW 8.1 environs.
- [Boost-1.82.0][], [Boost-1.83.0][] and [Boost-1.84.0][] and [Boost-1.85.0][] are built with and supplied under Qt's MinGW 8.1 and MinGW 11.3 environs.
- [Boost-1.85.0][] is built with and supplied under Qt's MinGW 8.1 environs.
Note: It is not recommended to use [Boost-1.86.0][] with [Qt][] 5.15.2 as there are some build and compatability issues.**
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 -7.3, -8.1 or -11.2 suffix !
The recommended development environment should be [JTSDK64-3.4.1][] with the latest update applied i.e [JTSDK64-3.4.1-U1][] if available.
The current environment incorporates [Qt][] 5.15.2 and support for building [Boost-1.85.0][] working with MinGW 8.1 under
the mingw64 [MSYS2][] environment.
The Next Steps
Version 4 of the JTSDK will involve a number of strategic re-thinks - and will be developed actively once
[Qt][] 5.15.2 is unavailable for deployment.
Watch the [JTSDK Forum][] for updates and to contribute.
Conventions used in this document.
Drive paths will be referred to as x: (i.e. x:\JTSDK64-Tools\config) , where x: is the default deployment drive
- x: as used in this guide in most cases can be replaced with c:
Kit Construction
The kit is derived from techniques first documented by Greg KI7MT.
Most configuration is now based on either marker files in x:\JTSDK64-Tools\config
or specified package versions listed in x:\JTSDK64-Tools\config\Versions.ini .
See the [JTSDK Forum][] and post comments (or email main contributors found there).
Support
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.
Added Support and Features
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:
- Hamlib support for other non-JT-software packages (will occur silently???).
- [Qt][]'s incorporated [CMAKE][] is now the recommended [CMAKE][] tool.
- The version of [Boost][] can be selected in Version.ini and will be compiled to the selected version of Qt (including its MinGW release).
- Greater package version self-configuration - hence less maintenance required.
- Upgrades to "static" apps that have no generically named latest-version sources
- Versions of Qt 5 and 6 to be deployed can be set in keys within Version.ini , saving considerable amounts of time maintaining respurces (i.e. when the Qt Maintainers update packages that are available to Open Sorce users)
- PowerShell by default is set a PowerShell Windows 5.1. This can be actively changed to the latest deployable package by setting a key within Version.ini
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.
Limitations
[PowerShell][] scripts are managed to tight security rules. See the next section.
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.
[PowerShell][] Security Warnings
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.
Windows Environment Variables
The basic concept of supporting Windows Environment Variables through [PowerShell][]
$env: facilities that ease access into [CMAKE][], QMake and the MinGW compilers
will remain a cornerstone concept.
Upgrades from Versions earlier than Version 3.4.1
It is not recommended that the [JTSDK64-3.4.1][] be installed over th...
v3.4.0-U1
The first cut of the (very minor) update to JTSDK 3.4.0 is now available:
- See: https://sourceforge.net/projects/hamlib-sdk/files/Windows/JTSDK-3.4-Stream/JTSDK64-3.4.0-U1.exe/
It is to be reiterated that this is a first-cut. Revisions may be required (even of this).
Please test and comment.
Basically all that occurs is that Boost deployments are reverted BACK to JFrog.
Not all documentation may be in place yet at https://hamlib-sdk.sourceforge.io/ . The readme.md included with the Update 1 package and at the base of the download site should be relatively accurate.
Note that most effort at this stage is being directed at Version 4 of the SDK.
Rel-v3.4.0
###Version 3.4.0 - The Last release in the Version 3 Stream.###
Note that since release of Version 3.4.0, Qt 5.15.2 is only available from Qt "Archive" repositories. It is recommended that one performs a FULL Deployment of Qt and uses the Maintenance Tool to add Qt 5.15.2 from Archive.
This is the trigger for the start of Version 4.0 Development.
If you need Qt 5.15.2, see instructions at https://sourceforge.net/projects/hamlib-sdk/files/JTware-Deployment/Deploying-Archived-Versions-of-Qt-via-Maintenance-Tool.docx for how to deploy old version of Qt from Qt Archive.
JTSDK64 3.2.3 Tools 3.2.3.3
Updates to the JTSDK64 3.2.3
- Changes Boost source delivery away from JFrog to GitHUB
- Makes jtbuild.ps1 compatible with [ the vastly improved ] PowerShell 7
- Documentation Updates
JTSDK 3.2.3
A release version of JTSDK Base 3.2.3 Package is now available.
This is planned as the LAST RELEASE within the JTSDK 3.2 Stream. There will be No "Tools" - No further Maintenance Updates - UNLESS EXTREMELY NECESSARY. Note that the documentation is set just to provide for a Tools package just in case one becomes necessary.
Deployment.
As always it is recommended that this kit be deployed into a fresh, new fully-updated Windows virtual machine.
If deploying the kit directly to an operational filesystem it is highly recommended that you back up your original working system. This can be done by renaming the original folder containing the kit: i.e. rename x:\JTSDK64-Tools to x:\JTSDK64-Tools-Backup and then commence the deployment. You can possibly move your Qt deployment from the backup to this new deployment file structure to save a considerable amount of time.
You should be able to deploy this straight over the top of existing kits. Some MinGW components can set files read-only. It is best that you select the entire deployment directory structure and remove any set Read Only Flags if you are doing this. If there are still complaints of "locked files" or "read only files" then just ignore the issues and continue the installer. They will resolve themselves at run time and/or after a pacman -syuu is performed to update the MSYS2 environment.
Changes
All this release does is FORMALISE the "Package Updates" and, of course, update the MSYS2 environment to the latest versions as of 2022-12-12 at 12:00 UTC.
JTSDK 3.2.3 Beta 3
After reviewing past policies and practises, JTSDK 3.2.3 Beta 3 is possibly a step out of line. It has not been withdrawn yet it has been moved into https://sourceforge.net/projects/hamlib-sdk/files/Windows/JTSDK-3.4-Stream/Tests/ project path and renamed as an "Alpha" version in the Version 3.4 stream (though it is just the JTSDK 3.2.3 Beta 3).
JTSDK 3.4 Stream Introduction
There may be many more extensive changes needed to the JTSDK - basically as a result of a "quirk" where Qt maintainers changed directory structure nomenclature as of Qt 6.2.2. We have been well aware of this since the Version 6.2.2 release (i.e. The move to MinGW 9.00 - note NOT the MSYS2 delivered version of MinGW) .
i.e.
-
The MinGW "support tools" in x:\Qt\Tools the MinGW support tools are in directories /mingw810_64 for Qt 5.15.2 and /mingw1120_64 for Qt versions greater than or equal to Qt 6.2.2 - nomenclature being consistent with past practise.
-
For Qt 5.15.2 and earlier the compilers are found in x:\Qt\5.15.2\mingw81_64 <== consistent with the past. Yet as of Qt 6.2.2 (and referring to the current LTS release of Qt being 6.3.2) you find the directories named just x:\Qt\6.3.2\mingw_64 <== This lacks versioning consistency with past practise. Ideally this directory should have been named x:\Qt\6.3.2\mingw112_64 or x:\Qt\6.3.2\mingw90_64 ...
This has been raised with Qt maintainers (and early) but is too far ingrained to walk back. There were personnel changes there that possibly led to this.
This could have potential issues for experimenters with this kit which has all sorts of flow-on effects. We made the decision to set variables etc. to refer to mingw112_64 (consistent with the GCC version release) as "fudge" to overcome grief that some could experience when compiling JT-ware.
These "fudges" now may need more research and hence better solutions for our purposes - hence the Version 3.4 stream now being announced as being in active development.
Your Contribution
There will be many varied tests needed to perhaps overcome issues. That is the Norther Hemisphere Cold Winter / Southern Hemisphere psychotically hot project that we will all be researching.
Please comment back and add your constructive comments into the review process.