Hello All,
I've started building the new version of JTSDK (v2.0.0), and thought I'd
send out an update as to where things currently stand.
All of this is open for discussion, suggestion, improvements or
whatever, so now is the time to speak up if things don't sound quite
right. All feedback is welcome.
If all goes according to plan, I should have a testing version posted in
the next couple weeks. I've successfully built all Docs & Apps using the
new JTSDK v2.0.0, only minor path tweaks were needed. Current focus is
on Win32 packaging, fixing up build scripts, support files and function
lists.
This message it focused on Windows, however, JTSDK for *Nix is well
under way and a release will follow shortly after the Windows formal
release. Meta package testing on Launchpad was ok for Ubuntu, locally on
Jessie and Sid via pbuilder and VM's. KVASD-Installer is working up
through Ubuntu+1 ( aka Vivid ), although, packaging for Vivid is under
heavy revision / update from Ubuntu Dev's.
While the previous Win32 build method(s) ( JTSDK-{DOC,PY,QT} ) worked (
to a degree ), there were allot of issues and lessons learned. It is
hoped JTSDK v2 will address most of the major issues identified to date,
or at least the ones I've kept a log of. Please feel free to send along
your particular issues, needs and improvement suggestions. Again, all
feedback is welcome.
JTSDK v2.0.0 PRIMARY GOALS:
* Reduce the administration burden on Joe, specifically, remove the need
to constantly update the WSJT website when changes are needed to binary
packaging.
* Reduce the number of binary files in the WSJT application source trees
( asciidoc.exe, a2x.exe, python27.exe, msvc/python dll's etc ).
* Use a traditional release methods ( trunk, branches, tags ).
* Provide a single *point & click* update method ( not JTSDK-DOC ).
* Use Win32 Installers rather than archive files.
* Provide Windows Start Menus for all the Environments and Tools
* Simplify Installation, Updates and Usage for all users.
SPECIFIC CHANGES / IMPROVEMENTS:
* JTSDK v2.0.0 will have it's own project on SF ( already reserved ),
and use similar build methods, with the exception of Documentation, see
below.
* The SF project will use the same release method currently employed
with WSJT-X ( trunk, branches, tags ). Trunk being the head of
development, branches and tags for releases. It should be noted, this
project is focused 100% on build tools for WSJT applications &
documentation.
* The SF project is set to use Subversion as the VCS. The number of
contributors is expected to be low, as such, for the sake of simplicity,
a centralized workflow was selected. It can be shifted over to Git if a
distributed flow is needed / wanted.
* JTSDK v2 is housed in single folder *C:\JTSDK* rather than (3)
separate folders in the present JTSDK-{DOC,PY,QT} v1.0.0. Later versions
~2.0+ will provide for an alternate install location ( D:\JTSDK for
example ). The core issue with user selected install locations boils
down to re-basing Python3 and QT5 . I not found a simple, yet elegant
solution to this problem.
* Documentation builds will use a single shell script ( currently in the
WSJT ../branches/docs/build-doc.sh ) for both Windows and *Nix. The
current shell script can produce a Single File ( data-uri ) or Linked
version of a particular document. However, due to missing base64
dependencies in the pre-built Python27 binary, we cannot build data-uri
versions on Windows. The new build method ( Cyg32 Env ) solves this
problem and allows the use of source-highlight or Python Pygments if
desired.
*NO Binaries* ( a2x.exe, python27.exe, asciidoc.exe, etc ) will be
needed in the WSJT Documentation Source Tree ( this is the way is should
be ). I've tested this method of build on both Windows and *Nix
successfully. Previous tests on Mac were also successful when using this
shell script. Build commands are the same as before. Future plans will
include a Dialog / Ncurses Menu System ( in ~v2.0.1, ~v2.0.2 or later )
as well as direct command line entry.
* JTSDK v2 will have 3 InnoSetup v5 Installers for each formal release:
( names subject to change ):
- jtsdk-online-win32-2.0.0.exe: This version will download all binary
packages during the installation ( Cmake, Qt5, FFTW, etc ) from the
project folders on SF, and extract them to the appropriate location
during the install process. The installer itself is rather small, only a
few MB in size, however, depending on your internet speed, can take a
while to install.
- jtsdk-win32-2.0.0.exe: This is an all inclusive installer. It will be
several hundred MB in size, but contains all the packages in a
single-file installer. This is similar to how the QT project runs their
online / offline installer setups.
- jtsdk-maintenance-tool.exe: While still being developed, will provide
a means to update binary packaging if and when the need arrives. Items
such as Cmake, Hamlib3 updates, Qt5x changes, Python3x, FFTW etc. Exact
version control is being worked on ( slowly ) and may not be released
with the first round of installers. Stay tuned.
TOOL CHAIN / ENVIRONMENT ISOLATION
* There will be (3) primary environments; Windows-CLI ( command-line ),
MSYS ( bash 3.1.17 ), and Cyg32 ( bash 4.1.17 ), all selected / run from
a Windows Start-Menu:
- Windows-CLI: This is the same isolation used today with JTSDK-{QT, PY,
DOC}, however, documentation has changed to Cyg32. When selected from
the Windows Start Menu, it will run the QT/PY environment script setting
the appropriate tool-chain and application folder paths as needed. For
documentation, see Cyg32 below.
- MSYS: This is a limited use environment. Primary use is for building
hamlib3 when a new version is needed or requested. MSYS is isolated from
it's accompanying mingw32 tool-chain ( used for WSJT and WSPR builds ),
however, through the use of mount points or .mingw_profile scripts in
the users /home/$USER directory, can easily be configured for use. The
same applies to the QT5\Tools\mingw48_32 tool-chain. You can also call
these tool-chains directly from a script, such as build-hamlib.sh. MSYS
has all the autotools needed to run configure / aclocal / m4 macros,
pkg-config, and includes VCS tools such as Git, SVN, Hg, etc. The Gnu
tools are a bit dated. Bash is ( v3.1.17 for example ), but, for it's
intended purpose, should not present many problems.
- MSYS Updated versions of Bash and various Gnu Tools are possible,
however, the deployment method requires msys2-dll's and / or a package
manager that is not available from the original MinGW project. Compiling
from source is an option, but is a *very involved process*. If anyone
wants to attempt this, and provide a new Gnu Tool set + Bash, I'd be
happy to include it with JTSDK ~v2+
- MSYS Similar to Cyg32, with respect to user profile generation, a set
of default .bashrc, .profile, .minttyrc and .bash_alias files are
provided from the /scripts/ mount location. These can be customized to
automate various tasks such as building hamlib3, checking Git updates
etc. More information will be provided in the Dev-Guide upon it's next
release. You can add your own aliases ( shortcuts ) in the
/home/$USER/.bash_alias file as desired.
-Cyg32: This env provides an isolated Python-2.7.8 environment, updated
CoreUtils, Bash 4.1.17, patch, diff, rsync and general file-utils used
by Windows-CLI & Documentation build scripts. There are many reasons why
this is good for the project, however, the primary reason is to get the
latest Gnu Tools, or at least, *a much newer Bash version* than the
original MSYS/MinGW project currently provides.
- Cyg32 *does not* have it's respective tool-chain ( i686-pc-mingw32 /
i686-pc-cygwin ) installed as it is not needed for documentation nor any
of the WSJT application builds. In fact, it's undesired to have the
tool-chain installed as it can cause issues with --build, --host and
--target triplets if your not careful. None of the Autotools have been
installed in this environment.
- Cyg32 Cygwin pulls Windows %USERNAME% information ( a among other
items ) when generating / creating /home/$USER and configuring Network /
Group information. In order to make this *re-generate* at install time (
when you first run the Cyg32 environment ), a fare bit of customization
had to be done to UID / Group generation in /etc/profile. All seems to
be working as expected, but further testing is definitely needed in this
area.
- Cyg32 Updates and New Package installation can be performed through
the use of it's primary update tool ( setup_x86.exe ), which is included
with JTSDK v2.0.0 under C:\JTSDK\cyg32\setup_x86.exe. Use of this
facility is purely up to the end end user. However, care should be
exercised when using the tool for any package that affects user account
/ group installation / account manipulation, as several of the profile
scripts have custom updates / patches applied for use with JTSDK.
Basically, use at your own risk :-)
BUILD SCRIPTS:
* Rather than having one big script for all QT/PY application builds,
the intent is to have one script for each ( wsjtx-build.bat,
wsjt-build.bat, wspr-build.bat etc ). This allows much greater control
over each applications specific needs without affecting the other
builds. WSJT-X for example, has several Debug build options that are not
present in MAP65 or WSPR-X, the same is true with build targets.
* The Documentation build script is a bit different, in-so-far-as, the
build tool / method is the same for all documents, AsciiDoc, thus
allowing the use of a single script delineating the different elements,
in either Windows ( via Cyg32 ) or *Nix in a native Bash shell.
SUPPORT SCRIPTS / AUX FILES
* At present, I'm suing a single folder C:\JTSDK\scripts to house all
misc files, apart from the QT-ENV / PY-ENV scripts, as those reside in
the root directory. This allows for a single point update method and we
can mount this location from any of the three environments ( MSYS, Cyg32
or Windows-CLI ) without fear of pulling in unwanted tool-chains or
build packages. It also allows for better revision control ( branches &
tags ).
* The scripts folder contains items such alias lists ( shortcuts ),
profile scripts, bash functions lists, version information scripts and
general help files.
WINDOWS START MENU ADDITIONS / UPDATES
* JTSDK v2.0.0 will provide a normal Windows Start Menus, including:
- JTSDK Script Updates ( one click update for all build scripts )
- JTSDK Maintenance Tool ( Update Binary Package Versions )
- QT-ENV for QT5 based builds ( WSJT-X, WSPR-X, MAP65 )
- PY-ENV for Python3 based Builds ( WSJT, WSPR )
- DOC-ENV for the Documentation builds ( all docs )
- Python3 Command-Line Tool
- iPython Tools ( future consideration )
- Links to tools such as Cmake-GUI, QtCreator, RapidEE etc
- VCS Tool Access ( Git, SVN, Hg, etc)
- SSH Access / Tools
- GnuPG Key Tools ( generate, manage, etc )
- JTSDK Specific README / Documentation
- JTSDK Uninstaller
In theory, one *should not* have to run a Windows CMD terminal in order
to launch any of the JTSDK primary environments. Even if your not
building an application, all the the ENV's will provide access to many
Gnu / Developer Tools including several VCS apps ( Git, SVN, Hg, etc ).
You can customize most of the environments to suit your particular needs.
That's all for now. As stated earlier, feedback either good or bad is
welcome.
--
73's
Greg, KI7MT
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
