Requires Boost libraries to be available as an external library.
On Debian style Linux distributions:
sudo apt install boost-dev-all
On Red Hat style Linux distributions:
sudo dnf install boost-dev
On macOS install Boost from a suitable Open Source package manager,
e.g. MacPorts:
sudo port install boost
If building WSJT-X packages on macOS for distribution you must build
boost and its dependants from sources with a suitable macports.conf
file specifying the target macOS version (10.12 at present). To build
Boost from sources in this case:
sudo port -s install boost
On MS Windows boost must be built from sources using the correct MinGW
compilers, i.e. the Qt tools 32- or 64-bit g++ for each target
bit-width respectively. To build boost something along the lines of
the following recipe should be used:
1) Download the boost ZIP source archive from
https://sourceforge.net/projects/boost/, the latest release should be
OK, at the time of writing that was 1.74,
2) create a directory for the sources:
MKDIR C:\boost-install
and extract the boost sources there.
3) Bootstrap and build Boost.Build. If you are building both 32- and
64-bit variants then do this twice, each from the correct MinGW
terminal session for the necessary tool-chain. Specify a unique
install directory for each variant (--prefix=). I use C:\Tools as a
root directory for external libraries and tools, choose whatever suits
your development environment.
CD C:\boost-install\boost_1_74_0\tools\build
bootstrap.bat gcc
b2 --prefix="C:\Tools\boost-build\MinGW32" install
CD C:\boost-install\boost_1_74_0\tools\build
bootstrap.bat gcc
b2 --prefix="C:\Tools\boost-build\MinGW64" install
4) Build Boost. If you are building both 32- and 64-bit variants then
do this twice, each from the correct MinGW terminal session for the
necessary tool-chain. Specify a unique build and install directory for
each variant (--build-dir= and --prefix=). I use C:\Tools as a root
directory for external libraries and tools, choose whatever suits your
development environment.
SET Path=%Path%;C:\Tools\boost-build\MinGW32\bin
CD C:\boost-install\boost_1_74_0
b2 --build-dir="C:\boost-install\boost_1_74_0\build" ^
--build-type=complete ^
--prefix="C:\Tools\boost\MinGW32" ^
toolset=gcc install
SET Path=%Path%;C:\Tools\boost-build\MinGW32\bin
CD C:\boost-install\boost_1_74_0
b2 --build-dir="C:\boost-install\boost_1_74_0\build" ^
--build-type=complete ^
--prefix="C:\Tools\boost\MinGW32" ^
toolset=gcc address-model=64 install
5) Once successfully built the sources directory and build trees
within can be deleted. The build products are contained in the install
directories (C:\Tools\boost-build and C:\Tools\boost in my case).
6) Update your development environment to include the boost headers
and libraries. In my case I have scripts that set up 32- and 64-bit
environments, they need to be modified to include the appropriate
boost library directories on the Path environment variable so that
applications linked to Boost libraries can locate the DLLs. For
32-bit:
SET Path=C:\Tools\boost\MinGW32\lib;%Path%
For 64-bit:
SET Path=C:\Tools\boost\MinGW64\lib;%Path%
7) To build WSJT-X CMake will need to be able to locate the Boost
libraries. I do that using tool-chain files for each of 32- and 64-bit
in both Debug and Release configurations which are passed to the CMake
configuration invocation using the -DCMAKE_TOOLCHAIN_FILE= variable
assignment. In the tool-chain files you need to add the appropriate
Boost installation directory to the CMAKE_PREFIX_PATH variable,
something like:
set (BOOSTDIR C:/Tools/boost/MinGW32)
...
set (CMAKE_PREFIX_PATH ${BOOSTDIR} ${QTDIR} ...
adjust as needed for 32- or 64-bit variants.
polynomial fit is done over 400 Hz bandwidth for T/R periods longer
than 15s, and over approx. 600 Hz (10 times the signal bandwidth) for
T/R period of 15s.
Passing `--language en', '-l en-US', or `-l en_US` now takes a special
action to not load any translations using the current locale. This
allows the current system UI language not to influence an translations
loaded via the command line override when the native en-US is wanted.
This allows the Spanish UI translation to work, for now, for all
Spanish speaking locales. If necessary we can make it es-ES if other
translators feel it is not a good base for their Spanish variant. OTOH
if they just need to l10n a few strings then, say for Argentina, then
they can do that in an wsjtx_es_AR.ts and untranslated strings there
will fall back to the ones in wsjtx_es.ts automatically. This happens
because of teh way the application loads multiple translation files in
an order suitable for that to happen.
Xavi, EA3W, assures me that all Catalan dialects and variants are
essentially the same, so there's no need to have country variant
specific Catalan translation files.
