wsjt-devel

[wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Bill S. <g4...@cl...>]

Hi All,

I have just pushed the latest updates I've made to Hamlib 3 to my public 
fork of the project. These changes are not yet fully completed so I have 
not submitted them to the hamlib team yet.

Also I intended to change the WSJT-X compile and link commands in the 
CMake script to ensure any unreferenced code is stripped from final 
release configuration builds. To assist in this the configuration of 
hamlib builds needs to change with a few extra compiler and linker flags.

Here is a generic build recipe for hamlib suitable for use in the WSJT-X 
build, it should work as is on Linux, on Mac a small patch to autogen.sh 
is probably required (depending on how you install the required 
autotools) and on Windows see below.

mkdir ~/hamlib-prefix
cd ~/hamlib-prefix
git clone git://git.code.sf.net/u/bsomervi/hamlib src
cd src
git checkout integration
mkdir ../build
cd ../build
../src/autogen.sh --prefix=$HOME/hamlib-prefix \
     --disable-shared --enable-static \
     --without-cxx-binding --disable-winradio \
     CFLAGS="-fdata-sections -ffunction-sections" \
     LDFLAGS="-Wl,--gc-sections"
make
make install

This will build a binary hamlib package located at ~/hamlib-prefix so 
you will need to add that to your CMAKE_PREFIX_PATH variable in your 
WSJT-X build. On Linux that is probably the only path you have on 
CMAKE_PREFIX_PATH unless you are using a locally installed Qt installation.

On Windows there is a complication in that the compilers used to build 
Qt and WSJT-X are the MinGW ones bundled with the Qt package but hamlib 
needs to be build from an MSYS shell. This means that you need to tell 
the hamlib configuration to use the Qt bundled MinGW compilers (if you 
don't then the thread support library use by hamlib will be incompatible 
with that used by Qt and WSJT-X). So on Windows the hamlib build recipe 
is something like:

In an MSYS shell:-

mkdir ~/hamib-prefix
cd ~/hamlib-prefix
git clone git://git.code.sf.net/u/bsomervi/hamlib src
cd src
git checkout integration
mkdir ../build
cd ../build
../src/autogen.sh --prefix=$HOME/hamlib-prefix \
     --disable-shared --enable-static \
     --without-cxx-binding --disable-winradio \
     CC=<path-to-Qt-MinGW-tools>/gcc \
     CXX=<path-to-Qt-MinGW-tools>/g++ \
     CFLAGS="-fdata-sections -ffunction-sections" \
     LDFLAGS="-Wl,--gc-sections"
make
make install

NOTE: <path-to-Qt-MinGQ-tools> should be substituted with the actual 
path to your Qt bundled tools e.g on my system it is 
C:\Tools\Qt\Tools\mingw48_32\bin .

this will leave a hamlib binary package installed at 
c:/Users/<user-name>/hamlib-prefix which is what needs to be on your 
CMAKE_PREFIX_PATH. On Windows you almost certainly will be using a CMake 
toolchain file and this is where you will need to specify the hamlib 
binary location as one of the paths in CMAKE_PREFIX_PATH.

73
Bill
G4WJS.

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Bill S. <g4...@cl...>]

An update for Mac builders.

It appears that the Mac clang LLVM compilers do not support the 
function-sections, data-sections and, gc-sections options so those 
should be omitted on Mac builds. they probably only make sense for ELF 
binary targets anyway which is not the case on OS-X anyway so if they 
were supported they would probably be ignored.

So the Mac hamlib for WSJT-X recipe needs to be something like:

mkdir ~/hamlib-prefix
cd ~/hamlib-prefix
git clone git://git.code.sf.net/u/bsomervi/hamlib src
cd src
git checkout integration
mkdir ../build
cd ../build
../src/autogen.sh --prefix=$HOME/hamlib-prefix \
     --disable-shared --enable-static \
     --without-cxx-binding --disable-winradio
make
make install

73
Bill
G4WJS.

On 23/09/2014 15:50, Bill Somerville wrote:
> Hi All,
>
> I have just pushed the latest updates I've made to Hamlib 3 to my 
> public fork of the project. These changes are not yet fully completed 
> so I have not submitted them to the hamlib team yet.
>
> Also I intended to change the WSJT-X compile and link commands in the 
> CMake script to ensure any unreferenced code is stripped from final 
> release configuration builds. To assist in this the configuration of 
> hamlib builds needs to change with a few extra compiler and linker flags.
>
> Here is a generic build recipe for hamlib suitable for use in the 
> WSJT-X build, it should work as is on Linux, on Mac a small patch to 
> autogen.sh is probably required (depending on how you install the 
> required autotools) and on Windows see below.
>
> mkdir ~/hamlib-prefix
> cd ~/hamlib-prefix
> git clone git://git.code.sf.net/u/bsomervi/hamlib src
> cd src
> git checkout integration
> mkdir ../build
> cd ../build
> ../src/autogen.sh --prefix=$HOME/hamlib-prefix \
>     --disable-shared --enable-static \
>     --without-cxx-binding --disable-winradio \
>     CFLAGS="-fdata-sections -ffunction-sections" \
>     LDFLAGS="-Wl,--gc-sections"
> make
> make install
>
> This will build a binary hamlib package located at ~/hamlib-prefix so 
> you will need to add that to your CMAKE_PREFIX_PATH variable in your 
> WSJT-X build. On Linux that is probably the only path you have on 
> CMAKE_PREFIX_PATH unless you are using a locally installed Qt 
> installation.
>
> On Windows there is a complication in that the compilers used to build 
> Qt and WSJT-X are the MinGW ones bundled with the Qt package but 
> hamlib needs to be build from an MSYS shell. This means that you need 
> to tell the hamlib configuration to use the Qt bundled MinGW compilers 
> (if you don't then the thread support library use by hamlib will be 
> incompatible with that used by Qt and WSJT-X). So on Windows the 
> hamlib build recipe is something like:
>
> In an MSYS shell:-
>
> mkdir ~/hamib-prefix
> cd ~/hamlib-prefix
> git clone git://git.code.sf.net/u/bsomervi/hamlib src
> cd src
> git checkout integration
> mkdir ../build
> cd ../build
> ../src/autogen.sh --prefix=$HOME/hamlib-prefix \
>     --disable-shared --enable-static \
>     --without-cxx-binding --disable-winradio \
>     CC=<path-to-Qt-MinGW-tools>/gcc \
>     CXX=<path-to-Qt-MinGW-tools>/g++ \
>     CFLAGS="-fdata-sections -ffunction-sections" \
>     LDFLAGS="-Wl,--gc-sections"
> make
> make install
>
> NOTE: <path-to-Qt-MinGQ-tools> should be substituted with the actual 
> path to your Qt bundled tools e.g on my system it is 
> C:\Tools\Qt\Tools\mingw48_32\bin .
>
> this will leave a hamlib binary package installed at 
> c:/Users/<user-name>/hamlib-prefix which is what needs to be on your 
> CMAKE_PREFIX_PATH. On Windows you almost certainly will be using a 
> CMake toolchain file and this is where you will need to specify the 
> hamlib binary location as one of the paths in CMAKE_PREFIX_PATH.
>
> 73
> Bill
> G4WJS.

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[John N. <jm...@rm...>]

Hi Bill,

Thanks for corrected Mac script for new hamlib3.

WSJT-X 1.4.0-rc1 r4345  running OK with new hamlib3 on Mac with 10.9.4  (Debug version at present.)

--- John G4KLA

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Joe T. <jo...@pr...>]

Hi Bill,

Some feedback on your build procedure for hamlib on Windows.

I followed your suggested procedure:

> In an MSYS shell:-
>
> mkdir ~/hamib-prefix
> cd ~/hamlib-prefix
> git clone git://git.code.sf.net/u/bsomervi/hamlib src
> cd src
> git checkout integration
> mkdir ../build
> cd ../build
> ../src/autogen.sh --prefix=$HOME/hamlib-prefix \
>       --disable-shared --enable-static \
>       --without-cxx-binding --disable-winradio \
>       CC=<path-to-Qt-MinGW-tools>/gcc \
>       CXX=<path-to-Qt-MinGW-tools>/g++ \
>       CFLAGS="-fdata-sections -ffunction-sections" \
>       LDFLAGS="-Wl,--gc-sections"
> make
> make install

Since I have Greg's JTSDK-QT installed, for "<path-to-Qt-MinGW-tools>" I 
substituted "C:/JTSDK-QT/qt5/Tools/mingw48_32/bin".

> this will leave a hamlib binary package installed at
> c:/Users/<user-name>/hamlib-prefix which is what needs to be on your
> CMAKE_PREFIX_PATH. On Windows you almost certainly will be using a CMake
> toolchain file and this is where you will need to specify the hamlib
> binary location as one of the paths in CMAKE_PREFIX_PATH.

Both "make" and "make install" ran to completion without errors.
I find no hamlib binary package installed at
c:/Users/<user-name>/hamlib-prefix :

joe@phy-joe ~/hamlib_g4wjs
$ ls -l
total 24
drwxr-xr-x 50 joe Administrators  8192 Sep 24 09:11 build
drwxr-xr-x 58 joe Administrators 16384 Sep 24 09:05 src

However, I do find libhamlib.a and libhamlib.la in
.../build/src/.libs, and after copying them to their normal location in 
Greg's JTSDK-QT, WSJT-X seems to build correctly.  (The build was, 
however, using the old (4/2/2014) include files, and perhaps other parts 
of the April 2014 build of hamlib.)

So...

1. Has something in "make install" failed to work for me as you expected?

2. I see no use of CMAKE_PREFIX_PATH anywhere in CMakeLists.txt, and
inserting the line
	set (CMAKE_PREFIX_PATH C:/Users/Joe/hamlib_g4wjs)
at the top of CMakeLists.txt seems to do nothing.  Have I got something 
wrong here?

	-- Joe, K1JT

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Bill S. <g4...@cl...>]

On 24/09/2014 15:05, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> Some feedback on your build procedure for hamlib on Windows.
>
> I followed your suggested procedure:
>
>> In an MSYS shell:-
>>
>> mkdir ~/hamib-prefix
>> cd ~/hamlib-prefix
>> git clone git://git.code.sf.net/u/bsomervi/hamlib src
>> cd src
>> git checkout integration
>> mkdir ../build
>> cd ../build
>> ../src/autogen.sh --prefix=$HOME/hamlib-prefix \
>>        --disable-shared --enable-static \
>>        --without-cxx-binding --disable-winradio \
>>        CC=<path-to-Qt-MinGW-tools>/gcc \
>>        CXX=<path-to-Qt-MinGW-tools>/g++ \
>>        CFLAGS="-fdata-sections -ffunction-sections" \
>>        LDFLAGS="-Wl,--gc-sections"
>> make
>> make install
> Since I have Greg's JTSDK-QT installed, for "<path-to-Qt-MinGW-tools>" I
> substituted "C:/JTSDK-QT/qt5/Tools/mingw48_32/bin".
OK, that's correct.
>
>> this will leave a hamlib binary package installed at
>> c:/Users/<user-name>/hamlib-prefix which is what needs to be on your
>> CMAKE_PREFIX_PATH. On Windows you almost certainly will be using a CMake
>> toolchain file and this is where you will need to specify the hamlib
>> binary location as one of the paths in CMAKE_PREFIX_PATH.
> Both "make" and "make install" ran to completion without errors.
> I find no hamlib binary package installed at
> c:/Users/<user-name>/hamlib-prefix :
>
> joe@phy-joe ~/hamlib_g4wjs
> $ ls -l
> total 24
> drwxr-xr-x 50 joe Administrators  8192 Sep 24 09:11 build
> drwxr-xr-x 58 joe Administrators 16384 Sep 24 09:05 src
>
> However, I do find libhamlib.a and libhamlib.la in
> .../build/src/.libs, and after copying them to their normal location in
> Greg's JTSDK-QT, WSJT-X seems to build correctly.  (The build was,
> however, using the old (4/2/2014) include files, and perhaps other parts
> of the April 2014 build of hamlib.)
OK. That is the pre-install location. You need the install location 
because it puts the configured PkgConfig files there as well as the 
library. The PkgConfig file (<install-prefix>/lib/pkgconfig/hamlib.pc) 
is required for the WSJT-X build to correctly locate and link the hamlib 
static library.

So if the 'make install' worked without error then I suggest that the 
install prefix was not where you thought it was. The install prefix is 
set in the configure command line (in this case autogen.sh which passes 
it to configure) as the --prefix argument. If you review your command 
history in MSYS you should be able to check what you actually specified 
as the install prefix.

My example uses a structure like:

~/hamlib-prefix
     |
     +--------------------src
     |
     +--------------------build

where the source is checked out (cloned from git) into ~/hamlib-prefix/src,
the configure (autogen.sh) and the build (make) are run in 
~/hamlib-prefix/build,
with the products of the install phase going into ~/hamlib-prefix.

So after a successful build you should have:

~/hamlib-prefix
     |
     +--------------------src
     |
     +--------------------build
     |
     +--------------------bin
     |
     +--------------------lib
     |
     +--------------------include
     |
     +--------------------share
and a few other deeper sub-directories.
>
> So...
>
> 1. Has something in "make install" failed to work for me as you expected?
>
> 2. I see no use of CMAKE_PREFIX_PATH anywhere in CMakeLists.txt, and
> inserting the line
> 	set (CMAKE_PREFIX_PATH C:/Users/Joe/hamlib_g4wjs)
> at the top of CMakeLists.txt seems to do nothing.  Have I got something
> wrong here?
CMAKE_PREFIX_PATH is something you normally pass to CMake on the command 
line because it is user or site specific. When there are several user or 
site specific variables, for example when cross compiling (which using 
MinGW virtually is) it is normal to gather all the non project specific 
CMake variables into a toolchain file. The idea is that the toolchain 
files defines a common environment, say for example all the setup for 
building Qt programs using MinGW compilers, fftw and hamlib. The path to 
the toolchain file is then specified on the CMake command line as the 
variable CMAKE_TOOLCHAIN_FILE. This is AFAIK the mechanism that the 
JTSDK-QT uses on Windows. You should never need to edit the 
CMakeLists.txt file for something specific to your system like the 
location of required tools or libraries.

Hope this helps decode what is going on and what has gone amiss with 
your first attempt at building hamlib on Windows.
>
> 	-- Joe, K1JT
>
73
Bill
G4WJS.

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Joe T. <jo...@pr...>]

Hi Bill and Greg,

As you recognized, the procedure I went through installed the newly 
built hamlib files, but not in the places I had expected.  My mistake.

I have now changed the "--prefix=..." part of the command that invokes 
autogen.sh to read "--prefix=C:/JTSDK-QT/hamlib3/mingw32", and all 
appears to be well.  Newly built files appear in the bin, lib, include, 
and share directories there, and the usual JTSDK-QT commands build 
WSJT-X properly.

The only complaint issued by any of the scripts is this one from  the 
JTSDK-QT command "build wsjtx package":

#######################################################################
CPack: Create package
CPack: - package: 
C:/JTSDK-QT/wsjtx/build/Release/wsjtx-1.4.0-rc1-win32.exe gene
rated.

-----------------------------------------------------------------
                    INSTALLER BUILD ERROR
-----------------------------------------------------------------

  There was a problem building the package, or the script
  could not find:

  C:\JTSDK-QT\wsjtx\build\Release\wsjtx-1.4.0-win32.exe

  Check the Cmake logs for any errors, or correct any build
  script issues that were obverved and try to rebuild the package.
#######################################################################

The message is completely benign: the script just did not understand 
that the package name would include the modifier "-rc1".


For the record then, here's what I did to build the latest version of 
hamlib3 in Windows:

In an MSYS shell:-

mkdir ~/hamib_g4wjs
cd ~/hamlib_g4wjs
git clone git://git.code.sf.net/u/bsomervi/hamlib src
cd src
git checkout integration
mkdir ../build
cd ../build
../src/autogen.sh --prefix=C:/JTSDK-QT/hamlib3/mingw32 \
      --disable-shared --enable-static \
      --without-cxx-binding --disable-winradio \
      CC=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/gcc \
      CXX=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/g++ \
      CFLAGS="-fdata-sections -ffunction-sections" \
      LDFLAGS="-Wl,--gc-sections"
make
make install

... and then, in the JTSDK-QT environment CMD shell:

build wsjtx rinstall
build wsjtx package

	-- Joe

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Bill S. <g4...@cl...>]

On 24/09/2014 17:31, Joe Taylor wrote:
> Hi Bill and Greg,
Hi Joe,
>
> As you recognized, the procedure I went through installed the newly
> built hamlib files, but not in the places I had expected.  My mistake.
>
> I have now changed the "--prefix=..." part of the command that invokes
> autogen.sh to read "--prefix=C:/JTSDK-QT/hamlib3/mingw32", and all
> appears to be well.  Newly built files appear in the bin, lib, include,
> and share directories there, and the usual JTSDK-QT commands build
> WSJT-X properly.
Good.
>
> The only complaint issued by any of the scripts is this one from  the
> JTSDK-QT command "build wsjtx package":
>
> #######################################################################
> CPack: Create package
> CPack: - package:
> C:/JTSDK-QT/wsjtx/build/Release/wsjtx-1.4.0-rc1-win32.exe gene
> rated.
>
> -----------------------------------------------------------------
>                      INSTALLER BUILD ERROR
> -----------------------------------------------------------------
>
>    There was a problem building the package, or the script
>    could not find:
>
>    C:\JTSDK-QT\wsjtx\build\Release\wsjtx-1.4.0-win32.exe
>
>    Check the Cmake logs for any errors, or correct any build
>    script issues that were obverved and try to rebuild the package.
> #######################################################################
>
> The message is completely benign: the script just did not understand
> that the package name would include the modifier "-rc1".
>
>
> For the record then, here's what I did to build the latest version of
> hamlib3 in Windows:
>
> In an MSYS shell:-
>
> mkdir ~/hamib_g4wjs
> cd ~/hamlib_g4wjs
> git clone git://git.code.sf.net/u/bsomervi/hamlib src
> cd src
> git checkout integration
> mkdir ../build
> cd ../build
> ../src/autogen.sh --prefix=C:/JTSDK-QT/hamlib3/mingw32 \
>        --disable-shared --enable-static \
>        --without-cxx-binding --disable-winradio \
>        CC=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/gcc \
>        CXX=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/g++ \
>        CFLAGS="-fdata-sections -ffunction-sections" \
>        LDFLAGS="-Wl,--gc-sections"
> make
> make install
>
> ... and then, in the JTSDK-QT environment CMD shell:
>
> build wsjtx rinstall
> build wsjtx package

OK and for future reference if you need to pick up a new generation of 
hamlib then the recipe is:

In an MSYS shell:-

cd ~/hamlib_g4wjs/src
git pull
cd ../build
make
make install

... and then, in the JTSDK-QT environment CMD shell:

build wsjtx rinstall
build wsjtx package

>
> 	-- Joe
73
Bill
G4WJS.

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[KI7MT <ki...@ya...>]

Hi Bill, Joe,

I did some testing with this today. I Downloaded & Installed (unzipped):

http://hivelocity.dl.sourceforge.net/project/mingwbuilds/external-binary-packages/msys%2B7za%2Bwget%2Bsvn%2Bgit%2Bmercurial%2Bcvs-rev13.7z

I used this version of MSYS as it has Git, SVN, Hg, and all Autotools
pre-packaged in a simple .7z file.

Process:
------------------------------
-Installed to: /d/msys32/msys
-Ran /d/msys32/msys/msys.bat
- Set %PATH to:
PATH=.:/d/msys32/msys/bin:/c/JTSDK-QT/qt5/Tools/mingw48_32/bin
mkdir -p ~/hamlib-g4wjs/build
cd ~/hamlib-g4wjs
git clone git://git.code.sf.net/u/bsomervi/hamlib src
cd src
git checkout integration
cd ../build

../src/autogen.sh --prefix=C:/JTSDK-QT/hamlib3/mingw32 \
--disable-shared --enable-static \
--without-cxx-binding --disable-winradio \
CC=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/gcc \
CXX=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/g++ \
CFLAGS="-fdata-sections -ffunction-sections" \
LDFLAGS="-Wl,--gc-sections"

mingw32-make -j6
mingw32-make install
------------------------------

MSYS has a make.exe associated with it, so I opted to use the
mingw32-make binary to keep things consistent with gcc/g++.
I'm not sure if this is critical or not, but, hamlib compiled and
installed without error, but it's " Seriously Slow "

I do not have libusb installed on my system, and I got this warning:

" libusb--USB backends will be disabled "

I'm not sure how to get around that one. Are you getting this error?

73's
Greg, KI7MT

On 9/24/2014 16:44, Bill Somerville wrote:
> On 24/09/2014 17:31, Joe Taylor wrote:
>> Hi Bill and Greg,
> Hi Joe,
>>
>> As you recognized, the procedure I went through installed the newly
>> built hamlib files, but not in the places I had expected.  My mistake.
>>
>> I have now changed the "--prefix=..." part of the command that invokes
>> autogen.sh to read "--prefix=C:/JTSDK-QT/hamlib3/mingw32", and all
>> appears to be well.  Newly built files appear in the bin, lib, include,
>> and share directories there, and the usual JTSDK-QT commands build
>> WSJT-X properly.
> Good.
>>
>> The only complaint issued by any of the scripts is this one from  the
>> JTSDK-QT command "build wsjtx package":
>>
>> #######################################################################
>> CPack: Create package
>> CPack: - package:
>> C:/JTSDK-QT/wsjtx/build/Release/wsjtx-1.4.0-rc1-win32.exe gene
>> rated.
>>
>> -----------------------------------------------------------------
>>                      INSTALLER BUILD ERROR
>> -----------------------------------------------------------------
>>
>>    There was a problem building the package, or the script
>>    could not find:
>>
>>    C:\JTSDK-QT\wsjtx\build\Release\wsjtx-1.4.0-win32.exe
>>
>>    Check the Cmake logs for any errors, or correct any build
>>    script issues that were obverved and try to rebuild the package.
>> #######################################################################
>>
>> The message is completely benign: the script just did not understand
>> that the package name would include the modifier "-rc1".
>>
>>
>> For the record then, here's what I did to build the latest version of
>> hamlib3 in Windows:
>>
>> In an MSYS shell:-
>>
>> mkdir ~/hamib_g4wjs
>> cd ~/hamlib_g4wjs
>> git clone git://git.code.sf.net/u/bsomervi/hamlib src
>> cd src
>> git checkout integration
>> mkdir ../build
>> cd ../build
>> ../src/autogen.sh --prefix=C:/JTSDK-QT/hamlib3/mingw32 \
>>        --disable-shared --enable-static \
>>        --without-cxx-binding --disable-winradio \
>>        CC=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/gcc \
>>        CXX=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/g++ \
>>        CFLAGS="-fdata-sections -ffunction-sections" \
>>        LDFLAGS="-Wl,--gc-sections"
>> make
>> make install
>>
>> ... and then, in the JTSDK-QT environment CMD shell:
>>
>> build wsjtx rinstall
>> build wsjtx package
> 
> OK and for future reference if you need to pick up a new generation of 
> hamlib then the recipe is:
> 
> In an MSYS shell:-
> 
> cd ~/hamlib_g4wjs/src
> git pull
> cd ../build
> make
> make install
> 
> ... and then, in the JTSDK-QT environment CMD shell:
> 
> build wsjtx rinstall
> build wsjtx package
> 
>>
>> 	-- Joe
> 73
> Bill
> G4WJS.
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

-- 
73's
Greg, KI7MT

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Bill S. <g4...@cl...>]

On 24/09/2014 22:52, KI7MT wrote:
> Hi Bill, Joe,
Hi Greg,
>
> I did some testing with this today. I Downloaded & Installed (unzipped):
>
> http://hivelocity.dl.sourceforge.net/project/mingwbuilds/external-binary-packages/msys%2B7za%2Bwget%2Bsvn%2Bgit%2Bmercurial%2Bcvs-rev13.7z
>
> I used this version of MSYS as it has Git, SVN, Hg, and all Autotools
> pre-packaged in a simple .7z file.
>
> Process:
> ------------------------------
> -Installed to: /d/msys32/msys
> -Ran /d/msys32/msys/msys.bat
> - Set %PATH to:
> PATH=.:/d/msys32/msys/bin:/c/JTSDK-QT/qt5/Tools/mingw48_32/bin
> mkdir -p ~/hamlib-g4wjs/build
> cd ~/hamlib-g4wjs
> git clone git://git.code.sf.net/u/bsomervi/hamlib src
> cd src
> git checkout integration
> cd ../build
>
> ../src/autogen.sh --prefix=C:/JTSDK-QT/hamlib3/mingw32 \
> --disable-shared --enable-static \
> --without-cxx-binding --disable-winradio \
> CC=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/gcc \
> CXX=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/g++ \
> CFLAGS="-fdata-sections -ffunction-sections" \
> LDFLAGS="-Wl,--gc-sections"
>
> mingw32-make -j6
I don't trust parallel make on Windows, I would avoid using it.
> mingw32-make install
> ------------------------------
>
> MSYS has a make.exe associated with it, so I opted to use the
> mingw32-make binary to keep things consistent with gcc/g++.
> I'm not sure if this is critical or not, but, hamlib compiled and
> installed without error, but it's " Seriously Slow "
>
> I do not have libusb installed on my system, and I got this warning:
>
> " libusb--USB backends will be disabled"
>
> I'm not sure how to get around that one. Are you getting this error?
Don't worry about it, I get that too and have no idea how to get a 
working libusb of the right version on Windows. hamlib uses an old 
version of libusb and the API has since changed, the only source package 
I could find for the old libusb doesn't compile on Windows and I can't 
find a binary package :( I don't think we lose much by not having the 
USB back ends since the important rigs with USB interfaces emulate COM 
ports rather than having custom USB devices.
>
> 73's
> Greg, KI7MT
73
Bill
G4WJS.
>
> On 9/24/2014 16:44, Bill Somerville wrote:
>> On 24/09/2014 17:31, Joe Taylor wrote:
>>> Hi Bill and Greg,
>> Hi Joe,
>>> As you recognized, the procedure I went through installed the newly
>>> built hamlib files, but not in the places I had expected.  My mistake.
>>>
>>> I have now changed the "--prefix=..." part of the command that invokes
>>> autogen.sh to read "--prefix=C:/JTSDK-QT/hamlib3/mingw32", and all
>>> appears to be well.  Newly built files appear in the bin, lib, include,
>>> and share directories there, and the usual JTSDK-QT commands build
>>> WSJT-X properly.
>> Good.
>>> The only complaint issued by any of the scripts is this one from  the
>>> JTSDK-QT command "build wsjtx package":
>>>
>>> #######################################################################
>>> CPack: Create package
>>> CPack: - package:
>>> C:/JTSDK-QT/wsjtx/build/Release/wsjtx-1.4.0-rc1-win32.exe gene
>>> rated.
>>>
>>> -----------------------------------------------------------------
>>>                       INSTALLER BUILD ERROR
>>> -----------------------------------------------------------------
>>>
>>>     There was a problem building the package, or the script
>>>     could not find:
>>>
>>>     C:\JTSDK-QT\wsjtx\build\Release\wsjtx-1.4.0-win32.exe
>>>
>>>     Check the Cmake logs for any errors, or correct any build
>>>     script issues that were obverved and try to rebuild the package.
>>> #######################################################################
>>>
>>> The message is completely benign: the script just did not understand
>>> that the package name would include the modifier "-rc1".
>>>
>>>
>>> For the record then, here's what I did to build the latest version of
>>> hamlib3 in Windows:
>>>
>>> In an MSYS shell:-
>>>
>>> mkdir ~/hamib_g4wjs
>>> cd ~/hamlib_g4wjs
>>> git clone git://git.code.sf.net/u/bsomervi/hamlib src
>>> cd src
>>> git checkout integration
>>> mkdir ../build
>>> cd ../build
>>> ../src/autogen.sh --prefix=C:/JTSDK-QT/hamlib3/mingw32 \
>>>         --disable-shared --enable-static \
>>>         --without-cxx-binding --disable-winradio \
>>>         CC=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/gcc \
>>>         CXX=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/g++ \
>>>         CFLAGS="-fdata-sections -ffunction-sections" \
>>>         LDFLAGS="-Wl,--gc-sections"
>>> make
>>> make install
>>>
>>> ... and then, in the JTSDK-QT environment CMD shell:
>>>
>>> build wsjtx rinstall
>>> build wsjtx package
>> OK and for future reference if you need to pick up a new generation of
>> hamlib then the recipe is:
>>
>> In an MSYS shell:-
>>
>> cd ~/hamlib_g4wjs/src
>> git pull
>> cd ../build
>> make
>> make install
>>
>> ... and then, in the JTSDK-QT environment CMD shell:
>>
>> build wsjtx rinstall
>> build wsjtx package
>>
>>> 	-- Joe
>> 73
>> Bill
>> G4WJS.
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[KI7MT <ki...@ya...>]

Hi Joe,


On 9/24/2014 16:31, Joe Taylor wrote:
> Hi Bill and Greg,
> 
> As you recognized, the procedure I went through installed the newly 
> built hamlib files, but not in the places I had expected.  My mistake.
> 
> I have now changed the "--prefix=..." part of the command that invokes 
> autogen.sh to read "--prefix=C:/JTSDK-QT/hamlib3/mingw32", and all 
> appears to be well.  Newly built files appear in the bin, lib, include, 
> and share directories there, and the usual JTSDK-QT commands build 
> WSJT-X properly.
> 
> The only complaint issued by any of the scripts is this one from  the 
> JTSDK-QT command "build wsjtx package":
> 
> #######################################################################
> CPack: Create package
> CPack: - package: 
> C:/JTSDK-QT/wsjtx/build/Release/wsjtx-1.4.0-rc1-win32.exe gene
> rated.
> 
> -----------------------------------------------------------------
>                     INSTALLER BUILD ERROR
> -----------------------------------------------------------------
> 
>   There was a problem building the package, or the script
>   could not find:
> 
>   C:\JTSDK-QT\wsjtx\build\Release\wsjtx-1.4.0-win32.exe
> 
>   Check the Cmake logs for any errors, or correct any build
>   script issues that were obverved and try to rebuild the package.
> #######################################################################
> 
> The message is completely benign: the script just did not understand 
> that the package name would include the modifier "-rc1".

Yes, I've hard coded that, as I've not found a file I can snag the file
name from:

CMakeCPackOptions.cmake

${CPACK_PACKAGE_NAME}-1.4.0-rc1-${CPACK_SYSTEM_NAME}

Which is what sets the the output file name I believe.

In any case, I've updated jtsdk-cmake.bat, will post it to SVN shortly.


> 
> 
> For the record then, here's what I did to build the latest version of 
> hamlib3 in Windows:
> 
> In an MSYS shell:-
> 
> mkdir ~/hamib_g4wjs
> cd ~/hamlib_g4wjs
> git clone git://git.code.sf.net/u/bsomervi/hamlib src
> cd src
> git checkout integration
> mkdir ../build
> cd ../build
> ../src/autogen.sh --prefix=C:/JTSDK-QT/hamlib3/mingw32 \
>       --disable-shared --enable-static \
>       --without-cxx-binding --disable-winradio \
>       CC=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/gcc \
>       CXX=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/g++ \
>       CFLAGS="-fdata-sections -ffunction-sections" \
>       LDFLAGS="-Wl,--gc-sections"
> make
> make install
> 
> ... and then, in the JTSDK-QT environment CMD shell:
> 
> build wsjtx rinstall
> build wsjtx package
> 
> 	-- Joe
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

-- 
73's
Greg, KI7MT

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Bill S. <g4...@cl...>]

On 24/09/2014 17:50, KI7MT wrote:
Hi Greg,
> Hi Joe,
>
>
> On 9/24/2014 16:31, Joe Taylor wrote:

<snip>

>> The only complaint issued by any of the scripts is this one from  the
>> JTSDK-QT command "build wsjtx package":
>>
>> #######################################################################
>> CPack: Create package
>> CPack: - package:
>> C:/JTSDK-QT/wsjtx/build/Release/wsjtx-1.4.0-rc1-win32.exe gene
>> rated.
>>
>> -----------------------------------------------------------------
>>                      INSTALLER BUILD ERROR
>> -----------------------------------------------------------------
>>
>>    There was a problem building the package, or the script
>>    could not find:
>>
>>    C:\JTSDK-QT\wsjtx\build\Release\wsjtx-1.4.0-win32.exe
>>
>>    Check the Cmake logs for any errors, or correct any build
>>    script issues that were obverved and try to rebuild the package.
>> #######################################################################
>>
>> The message is completely benign: the script just did not understand
>> that the package name would include the modifier "-rc1".
> Yes, I've hard coded that, as I've not found a file I can snag the file
> name from:
>
> CMakeCPackOptions.cmake
>
> ${CPACK_PACKAGE_NAME}-1.4.0-rc1-${CPACK_SYSTEM_NAME}
>
> Which is what sets the the output file name I believe.
That is correct but the definitive source information is in 
Versions.cmake in the source directory.
>
> In any case, I've updated jtsdk-cmake.bat, will post it to SVN shortly.
>
<snip>

73
Bill
G4WJS.

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Bill S. <g4...@cl...>]

A small clarification:-

On 24/09/2014 17:53, Bill Somerville wrote:
> On 24/09/2014 17:50, KI7MT wrote:
> Hi Greg,
>> Hi Joe,
>>
>>
>> On 9/24/2014 16:31, Joe Taylor wrote:
> <snip>
>
>>> The only complaint issued by any of the scripts is this one from  the
>>> JTSDK-QT command "build wsjtx package":
>>>
>>> #######################################################################
>>> CPack: Create package
>>> CPack: - package:
>>> C:/JTSDK-QT/wsjtx/build/Release/wsjtx-1.4.0-rc1-win32.exe gene
>>> rated.
>>>
>>> -----------------------------------------------------------------
>>>                       INSTALLER BUILD ERROR
>>> -----------------------------------------------------------------
>>>
>>>     There was a problem building the package, or the script
>>>     could not find:
>>>
>>>     C:\JTSDK-QT\wsjtx\build\Release\wsjtx-1.4.0-win32.exe
>>>
>>>     Check the Cmake logs for any errors, or correct any build
>>>     script issues that were obverved and try to rebuild the package.
>>> #######################################################################
>>>
>>> The message is completely benign: the script just did not understand
>>> that the package name would include the modifier "-rc1".
>> Yes, I've hard coded that, as I've not found a file I can snag the file
>> name from:
>>
>> CMakeCPackOptions.cmake
>>
>> ${CPACK_PACKAGE_NAME}-1.4.0-rc1-${CPACK_SYSTEM_NAME}
>>
>> Which is what sets the the output file name I believe.
> That is correct but the definitive source information is in
> Versions.cmake in the source directory.
The variable set of WSJTX_RC defines the RC number and that line will be 
commented out in a final release.

WSJTX_VERSION_IS_RELEASE is not currently used but I have left it in and 
expect it to be set to '1' when we make a final cut.
>> In any case, I've updated jtsdk-cmake.bat, will post it to SVN shortly.
>>
> <snip>
>
> 73
> Bill
> G4WJS.
73
Bill
G4WJS.

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[KI7MT <ki...@ya...>]

HI Joe,

I forgot to mention, when building the package:

build wsjtx package

the script will perform at build tree configure first, then, it runs:

cmake --build . --target package

%OPTION% is not set, so the default is Release

I don't think you need to build the install target:

build wsjtx rinstall

as it appears, at least from what I can see on the screen, it's building
it on its own.

If this is not correct, then I need to change the build script for the
package target to first perform an install target build, then package it.

73's
Greg, KI7MT


On 9/24/2014 16:31, Joe Taylor wrote:
> Hi Bill and Greg,
> 
> As you recognized, the procedure I went through installed the newly 
> built hamlib files, but not in the places I had expected.  My mistake.
> 
> I have now changed the "--prefix=..." part of the command that invokes 
> autogen.sh to read "--prefix=C:/JTSDK-QT/hamlib3/mingw32", and all 
> appears to be well.  Newly built files appear in the bin, lib, include, 
> and share directories there, and the usual JTSDK-QT commands build 
> WSJT-X properly.
> 
> The only complaint issued by any of the scripts is this one from  the 
> JTSDK-QT command "build wsjtx package":
> 
> #######################################################################
> CPack: Create package
> CPack: - package: 
> C:/JTSDK-QT/wsjtx/build/Release/wsjtx-1.4.0-rc1-win32.exe gene
> rated.
> 
> -----------------------------------------------------------------
>                     INSTALLER BUILD ERROR
> -----------------------------------------------------------------
> 
>   There was a problem building the package, or the script
>   could not find:
> 
>   C:\JTSDK-QT\wsjtx\build\Release\wsjtx-1.4.0-win32.exe
> 
>   Check the Cmake logs for any errors, or correct any build
>   script issues that were obverved and try to rebuild the package.
> #######################################################################
> 
> The message is completely benign: the script just did not understand 
> that the package name would include the modifier "-rc1".
> 
> 
> For the record then, here's what I did to build the latest version of 
> hamlib3 in Windows:
> 
> In an MSYS shell:-
> 
> mkdir ~/hamib_g4wjs
> cd ~/hamlib_g4wjs
> git clone git://git.code.sf.net/u/bsomervi/hamlib src
> cd src
> git checkout integration
> mkdir ../build
> cd ../build
> ../src/autogen.sh --prefix=C:/JTSDK-QT/hamlib3/mingw32 \
>       --disable-shared --enable-static \
>       --without-cxx-binding --disable-winradio \
>       CC=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/gcc \
>       CXX=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/g++ \
>       CFLAGS="-fdata-sections -ffunction-sections" \
>       LDFLAGS="-Wl,--gc-sections"
> make
> make install
> 
> ... and then, in the JTSDK-QT environment CMD shell:
> 
> build wsjtx rinstall
> build wsjtx package
> 
> 	-- Joe
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

-- 
73's
Greg, KI7MT

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Bill S. <g4...@cl...>]

On 24/09/2014 18:09, KI7MT wrote:

Hi Greg,
> HI Joe,
>
> I forgot to mention, when building the package:
>
> build wsjtx package
>
> the script will perform at build tree configure first, then, it runs:
>
> cmake --build . --target package
>
> %OPTION% is not set, so the default is Release
>
> I don't think you need to build the install target:
>
> build wsjtx rinstall
>
> as it appears, at least from what I can see on the screen, it's building
> it on its own.
>
> If this is not correct, then I need to change the build script for the
> package target to first perform an install target build, then package it.
No that's OK, the package target will do the right thing, there's no 
need to make an install target unless you specifically need a locally 
installed Release version for testing purposes. Best advice is use 
'rinstall' for testing and 'package' if you want a deployable package.
>
> 73's
> Greg, KI7MT
73
Bill
G4WJS.
>
>
> On 9/24/2014 16:31, Joe Taylor wrote:
>> Hi Bill and Greg,
>>
>> As you recognized, the procedure I went through installed the newly
>> built hamlib files, but not in the places I had expected.  My mistake.
>>
>> I have now changed the "--prefix=..." part of the command that invokes
>> autogen.sh to read "--prefix=C:/JTSDK-QT/hamlib3/mingw32", and all
>> appears to be well.  Newly built files appear in the bin, lib, include,
>> and share directories there, and the usual JTSDK-QT commands build
>> WSJT-X properly.
>>
>> The only complaint issued by any of the scripts is this one from  the
>> JTSDK-QT command "build wsjtx package":
>>
>> #######################################################################
>> CPack: Create package
>> CPack: - package:
>> C:/JTSDK-QT/wsjtx/build/Release/wsjtx-1.4.0-rc1-win32.exe gene
>> rated.
>>
>> -----------------------------------------------------------------
>>                      INSTALLER BUILD ERROR
>> -----------------------------------------------------------------
>>
>>    There was a problem building the package, or the script
>>    could not find:
>>
>>    C:\JTSDK-QT\wsjtx\build\Release\wsjtx-1.4.0-win32.exe
>>
>>    Check the Cmake logs for any errors, or correct any build
>>    script issues that were obverved and try to rebuild the package.
>> #######################################################################
>>
>> The message is completely benign: the script just did not understand
>> that the package name would include the modifier "-rc1".
>>
>>
>> For the record then, here's what I did to build the latest version of
>> hamlib3 in Windows:
>>
>> In an MSYS shell:-
>>
>> mkdir ~/hamib_g4wjs
>> cd ~/hamlib_g4wjs
>> git clone git://git.code.sf.net/u/bsomervi/hamlib src
>> cd src
>> git checkout integration
>> mkdir ../build
>> cd ../build
>> ../src/autogen.sh --prefix=C:/JTSDK-QT/hamlib3/mingw32 \
>>        --disable-shared --enable-static \
>>        --without-cxx-binding --disable-winradio \
>>        CC=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/gcc \
>>        CXX=C:/JTSDK-QT/qt5/Tools/mingw48_32/bin/g++ \
>>        CFLAGS="-fdata-sections -ffunction-sections" \
>>        LDFLAGS="-Wl,--gc-sections"
>> make
>> make install
>>
>> ... and then, in the JTSDK-QT environment CMD shell:
>>
>> build wsjtx rinstall
>> build wsjtx package
>>
>> 	-- Joe
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[KI7MT <ki...@ya...>]

Hi Joe,

If you used the MSYS shell, $HOME/hamlib-prefix is going to be in your
MSYS /home/joe directory, probably not the Windows User path, something
like:

C:/MSYS/home/joe/hamlib-prefix

or wherever your MSYS installation is, possibly under
C:/MinGW/MSYS/home/joe/.. .. ..

Wherever the prefix path is set too during configure, you'll need to
update JTSDK-QT toolchain.cmake file to match that path, something like:

C:/Mingw/msys/home/joe/hamlib-prefix

if using the build example.

73's
Greg, KI7MT

On 9/24/2014 14:05, Joe Taylor wrote:
> Hi Bill,
> 
> Some feedback on your build procedure for hamlib on Windows.
> 
> I followed your suggested procedure:
> 
>> In an MSYS shell:-
>>
>> mkdir ~/hamib-prefix
>> cd ~/hamlib-prefix
>> git clone git://git.code.sf.net/u/bsomervi/hamlib src
>> cd src
>> git checkout integration
>> mkdir ../build
>> cd ../build
>> ../src/autogen.sh --prefix=$HOME/hamlib-prefix \
>>       --disable-shared --enable-static \
>>       --without-cxx-binding --disable-winradio \
>>       CC=<path-to-Qt-MinGW-tools>/gcc \
>>       CXX=<path-to-Qt-MinGW-tools>/g++ \
>>       CFLAGS="-fdata-sections -ffunction-sections" \
>>       LDFLAGS="-Wl,--gc-sections"
>> make
>> make install
> 
> Since I have Greg's JTSDK-QT installed, for "<path-to-Qt-MinGW-tools>" I 
> substituted "C:/JTSDK-QT/qt5/Tools/mingw48_32/bin".
> 
>> this will leave a hamlib binary package installed at
>> c:/Users/<user-name>/hamlib-prefix which is what needs to be on your
>> CMAKE_PREFIX_PATH. On Windows you almost certainly will be using a CMake
>> toolchain file and this is where you will need to specify the hamlib
>> binary location as one of the paths in CMAKE_PREFIX_PATH.
> 
> Both "make" and "make install" ran to completion without errors.
> I find no hamlib binary package installed at
> c:/Users/<user-name>/hamlib-prefix :
> 
> joe@phy-joe ~/hamlib_g4wjs
> $ ls -l
> total 24
> drwxr-xr-x 50 joe Administrators  8192 Sep 24 09:11 build
> drwxr-xr-x 58 joe Administrators 16384 Sep 24 09:05 src
> 
> However, I do find libhamlib.a and libhamlib.la in
> .../build/src/.libs, and after copying them to their normal location in 
> Greg's JTSDK-QT, WSJT-X seems to build correctly.  (The build was, 
> however, using the old (4/2/2014) include files, and perhaps other parts 
> of the April 2014 build of hamlib.)
> 
> So...
> 
> 1. Has something in "make install" failed to work for me as you expected?
> 
> 2. I see no use of CMAKE_PREFIX_PATH anywhere in CMakeLists.txt, and
> inserting the line
> 	set (CMAKE_PREFIX_PATH C:/Users/Joe/hamlib_g4wjs)
> at the top of CMakeLists.txt seems to do nothing.  Have I got something 
> wrong here?
> 
> 	-- Joe, K1JT
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

-- 
73's
Greg, KI7MT

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Bill S. <g4...@cl...>]

On 24/09/2014 16:59, KI7MT wrote:

Hi Greg,
> Hi Joe,
>
> If you used the MSYS shell, $HOME/hamlib-prefix is going to be in your
> MSYS /home/joe directory, probably not the Windows User path, something
> like:
>
> C:/MSYS/home/joe/hamlib-prefix
Ah OK, I thought only Cygwin did that sort of stuff. I must have changed 
my MSYS profile to have the $HOME (~) at the same place as 
%HOMEDRIVE%%HOMEPATH%
>
> or wherever your MSYS installation is, possibly under
> C:/MinGW/MSYS/home/joe/.. .. ..
>
> Wherever the prefix path is set too during configure, you'll need to
> update JTSDK-QT toolchain.cmake file to match that path, something like:
>
> C:/Mingw/msys/home/joe/hamlib-prefix
>
> if using the build example.
Alternatively set the install prefix to the place that JTSDK-QT expects 
to find the hamlib installation, that way the PkgConfig file in hamlib 
will be correct. Either way is fine. Moving the hamlib installation post 
install is not the right way to go as it breaks it.
>
> 73's
> Greg, KI7MT
73
Bill
G4WJS.
>
> On 9/24/2014 14:05, Joe Taylor wrote:
>> Hi Bill,
>>
>> Some feedback on your build procedure for hamlib on Windows.
>>
>> I followed your suggested procedure:
>>
>>> In an MSYS shell:-
>>>
>>> mkdir ~/hamib-prefix
>>> cd ~/hamlib-prefix
>>> git clone git://git.code.sf.net/u/bsomervi/hamlib src
>>> cd src
>>> git checkout integration
>>> mkdir ../build
>>> cd ../build
>>> ../src/autogen.sh --prefix=$HOME/hamlib-prefix \
>>>        --disable-shared --enable-static \
>>>        --without-cxx-binding --disable-winradio \
>>>        CC=<path-to-Qt-MinGW-tools>/gcc \
>>>        CXX=<path-to-Qt-MinGW-tools>/g++ \
>>>        CFLAGS="-fdata-sections -ffunction-sections" \
>>>        LDFLAGS="-Wl,--gc-sections"
>>> make
>>> make install
>> Since I have Greg's JTSDK-QT installed, for "<path-to-Qt-MinGW-tools>" I
>> substituted "C:/JTSDK-QT/qt5/Tools/mingw48_32/bin".
>>
>>> this will leave a hamlib binary package installed at
>>> c:/Users/<user-name>/hamlib-prefix which is what needs to be on your
>>> CMAKE_PREFIX_PATH. On Windows you almost certainly will be using a CMake
>>> toolchain file and this is where you will need to specify the hamlib
>>> binary location as one of the paths in CMAKE_PREFIX_PATH.
>> Both "make" and "make install" ran to completion without errors.
>> I find no hamlib binary package installed at
>> c:/Users/<user-name>/hamlib-prefix :
>>
>> joe@phy-joe ~/hamlib_g4wjs
>> $ ls -l
>> total 24
>> drwxr-xr-x 50 joe Administrators  8192 Sep 24 09:11 build
>> drwxr-xr-x 58 joe Administrators 16384 Sep 24 09:05 src
>>
>> However, I do find libhamlib.a and libhamlib.la in
>> .../build/src/.libs, and after copying them to their normal location in
>> Greg's JTSDK-QT, WSJT-X seems to build correctly.  (The build was,
>> however, using the old (4/2/2014) include files, and perhaps other parts
>> of the April 2014 build of hamlib.)
>>
>> So...
>>
>> 1. Has something in "make install" failed to work for me as you expected?
>>
>> 2. I see no use of CMAKE_PREFIX_PATH anywhere in CMakeLists.txt, and
>> inserting the line
>> 	set (CMAKE_PREFIX_PATH C:/Users/Joe/hamlib_g4wjs)
>> at the top of CMakeLists.txt seems to do nothing.  Have I got something
>> wrong here?
>>
>> 	-- Joe, K1JT
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[KI7MT <ki...@ya...>]

HI Bill,

I agree, personally, I would set, if building for JTSDK-QT, the
--prefix=C:/JTSDK-QT/hamlib3/mingw32

that should produce: ../hamlib3/mingw32/{bin,include,lib,share} and the
associated sub-folders.

I'm not sure if MSYS comes with pkg-config or not. The SDK's have it in
the tools directory now (not the Qt5\Tools, rather JTSDK-QT/tools), but
when using MSYS env, I doubt that pgk-config is on the path unless it's
installed on / in MSYS also.

There's a side affect that will need addressing in the JTSDK-QT update
script. If the april-2014.txt goes missing, or is deleted, the update
script will copy what's in SVN back over to JTSDK-QT/hamlib3 which is
the build from April-2014, so be aware of that. Setting the SDK prefix
path should *not* delete that file, so from that aspect, things should
be ok.

73's
Greg, KI7MT


On 9/24/2014 16:08, Bill Somerville wrote:
> On 24/09/2014 16:59, KI7MT wrote:
> 
> Hi Greg,
>> Hi Joe,
>>
>> If you used the MSYS shell, $HOME/hamlib-prefix is going to be in your
>> MSYS /home/joe directory, probably not the Windows User path, something
>> like:
>>
>> C:/MSYS/home/joe/hamlib-prefix
> Ah OK, I thought only Cygwin did that sort of stuff. I must have changed 
> my MSYS profile to have the $HOME (~) at the same place as 
> %HOMEDRIVE%%HOMEPATH%
>>
>> or wherever your MSYS installation is, possibly under
>> C:/MinGW/MSYS/home/joe/.. .. ..
>>
>> Wherever the prefix path is set too during configure, you'll need to
>> update JTSDK-QT toolchain.cmake file to match that path, something like:
>>
>> C:/Mingw/msys/home/joe/hamlib-prefix
>>
>> if using the build example.
> Alternatively set the install prefix to the place that JTSDK-QT expects 
> to find the hamlib installation, that way the PkgConfig file in hamlib 
> will be correct. Either way is fine. Moving the hamlib installation post 
> install is not the right way to go as it breaks it.
>>
>> 73's
>> Greg, KI7MT
> 73
> Bill
> G4WJS.
>>
>> On 9/24/2014 14:05, Joe Taylor wrote:
>>> Hi Bill,
>>>
>>> Some feedback on your build procedure for hamlib on Windows.
>>>
>>> I followed your suggested procedure:
>>>
>>>> In an MSYS shell:-
>>>>
>>>> mkdir ~/hamib-prefix
>>>> cd ~/hamlib-prefix
>>>> git clone git://git.code.sf.net/u/bsomervi/hamlib src
>>>> cd src
>>>> git checkout integration
>>>> mkdir ../build
>>>> cd ../build
>>>> ../src/autogen.sh --prefix=$HOME/hamlib-prefix \
>>>>        --disable-shared --enable-static \
>>>>        --without-cxx-binding --disable-winradio \
>>>>        CC=<path-to-Qt-MinGW-tools>/gcc \
>>>>        CXX=<path-to-Qt-MinGW-tools>/g++ \
>>>>        CFLAGS="-fdata-sections -ffunction-sections" \
>>>>        LDFLAGS="-Wl,--gc-sections"
>>>> make
>>>> make install
>>> Since I have Greg's JTSDK-QT installed, for "<path-to-Qt-MinGW-tools>" I
>>> substituted "C:/JTSDK-QT/qt5/Tools/mingw48_32/bin".
>>>
>>>> this will leave a hamlib binary package installed at
>>>> c:/Users/<user-name>/hamlib-prefix which is what needs to be on your
>>>> CMAKE_PREFIX_PATH. On Windows you almost certainly will be using a CMake
>>>> toolchain file and this is where you will need to specify the hamlib
>>>> binary location as one of the paths in CMAKE_PREFIX_PATH.
>>> Both "make" and "make install" ran to completion without errors.
>>> I find no hamlib binary package installed at
>>> c:/Users/<user-name>/hamlib-prefix :
>>>
>>> joe@phy-joe ~/hamlib_g4wjs
>>> $ ls -l
>>> total 24
>>> drwxr-xr-x 50 joe Administrators  8192 Sep 24 09:11 build
>>> drwxr-xr-x 58 joe Administrators 16384 Sep 24 09:05 src
>>>
>>> However, I do find libhamlib.a and libhamlib.la in
>>> .../build/src/.libs, and after copying them to their normal location in
>>> Greg's JTSDK-QT, WSJT-X seems to build correctly.  (The build was,
>>> however, using the old (4/2/2014) include files, and perhaps other parts
>>> of the April 2014 build of hamlib.)
>>>
>>> So...
>>>
>>> 1. Has something in "make install" failed to work for me as you expected?
>>>
>>> 2. I see no use of CMAKE_PREFIX_PATH anywhere in CMakeLists.txt, and
>>> inserting the line
>>> 	set (CMAKE_PREFIX_PATH C:/Users/Joe/hamlib_g4wjs)
>>> at the top of CMakeLists.txt seems to do nothing.  Have I got something
>>> wrong here?
>>>
>>> 	-- Joe, K1JT
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> wsjt-devel mailing list
>>> wsj...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

-- 
73's
Greg, KI7MT

Re: [wsjt-devel] WSJT-X Hamlib 3 fork updates.

[Bill S. <g4...@cl...>]

On 24/09/2014 17:22, KI7MT wrote:
> HI Bill,
Hi Greg,
>
> I agree, personally, I would set, if building for JTSDK-QT, the
> --prefix=C:/JTSDK-QT/hamlib3/mingw32
>
> that should produce: ../hamlib3/mingw32/{bin,include,lib,share} and the
> associated sub-folders.
Sounds good.
>
> I'm not sure if MSYS comes with pkg-config or not. The SDK's have it in
> the tools directory now (not the Qt5\Tools, rather JTSDK-QT/tools), but
> when using MSYS env, I doubt that pgk-config is on the path unless it's
> installed on / in MSYS also.
I don't think the hamlib build requires PkgConfig, the .pc file it 
generates is just a substituion into src/hamlib.pc.in .
>
> There's a side affect that will need addressing in the JTSDK-QT update
> script. If the april-2014.txt goes missing, or is deleted, the update
> script will copy what's in SVN back over to JTSDK-QT/hamlib3 which is
> the build from April-2014, so be aware of that. Setting the SDK prefix
> path should *not* delete that file, so from that aspect, things should
> be ok.
Yes that sounds sensible.
>
> 73's
> Greg, KI7MT
73
Bill
G4WJS.
>
> On 9/24/2014 16:08, Bill Somerville wrote:
>> On 24/09/2014 16:59, KI7MT wrote:
>>
>> Hi Greg,
>>> Hi Joe,
>>>
>>> If you used the MSYS shell, $HOME/hamlib-prefix is going to be in your
>>> MSYS /home/joe directory, probably not the Windows User path, something
>>> like:
>>>
>>> C:/MSYS/home/joe/hamlib-prefix
>> Ah OK, I thought only Cygwin did that sort of stuff. I must have changed
>> my MSYS profile to have the $HOME (~) at the same place as
>> %HOMEDRIVE%%HOMEPATH%
>>> or wherever your MSYS installation is, possibly under
>>> C:/MinGW/MSYS/home/joe/.. .. ..
>>>
>>> Wherever the prefix path is set too during configure, you'll need to
>>> update JTSDK-QT toolchain.cmake file to match that path, something like:
>>>
>>> C:/Mingw/msys/home/joe/hamlib-prefix
>>>
>>> if using the build example.
>> Alternatively set the install prefix to the place that JTSDK-QT expects
>> to find the hamlib installation, that way the PkgConfig file in hamlib
>> will be correct. Either way is fine. Moving the hamlib installation post
>> install is not the right way to go as it breaks it.
>>> 73's
>>> Greg, KI7MT
>> 73
>> Bill
>> G4WJS.
>>> On 9/24/2014 14:05, Joe Taylor wrote:
>>>> Hi Bill,
>>>>
>>>> Some feedback on your build procedure for hamlib on Windows.
>>>>
>>>> I followed your suggested procedure:
>>>>
>>>>> In an MSYS shell:-
>>>>>
>>>>> mkdir ~/hamib-prefix
>>>>> cd ~/hamlib-prefix
>>>>> git clone git://git.code.sf.net/u/bsomervi/hamlib src
>>>>> cd src
>>>>> git checkout integration
>>>>> mkdir ../build
>>>>> cd ../build
>>>>> ../src/autogen.sh --prefix=$HOME/hamlib-prefix \
>>>>>         --disable-shared --enable-static \
>>>>>         --without-cxx-binding --disable-winradio \
>>>>>         CC=<path-to-Qt-MinGW-tools>/gcc \
>>>>>         CXX=<path-to-Qt-MinGW-tools>/g++ \
>>>>>         CFLAGS="-fdata-sections -ffunction-sections" \
>>>>>         LDFLAGS="-Wl,--gc-sections"
>>>>> make
>>>>> make install
>>>> Since I have Greg's JTSDK-QT installed, for "<path-to-Qt-MinGW-tools>" I
>>>> substituted "C:/JTSDK-QT/qt5/Tools/mingw48_32/bin".
>>>>
>>>>> this will leave a hamlib binary package installed at
>>>>> c:/Users/<user-name>/hamlib-prefix which is what needs to be on your
>>>>> CMAKE_PREFIX_PATH. On Windows you almost certainly will be using a CMake
>>>>> toolchain file and this is where you will need to specify the hamlib
>>>>> binary location as one of the paths in CMAKE_PREFIX_PATH.
>>>> Both "make" and "make install" ran to completion without errors.
>>>> I find no hamlib binary package installed at
>>>> c:/Users/<user-name>/hamlib-prefix :
>>>>
>>>> joe@phy-joe ~/hamlib_g4wjs
>>>> $ ls -l
>>>> total 24
>>>> drwxr-xr-x 50 joe Administrators  8192 Sep 24 09:11 build
>>>> drwxr-xr-x 58 joe Administrators 16384 Sep 24 09:05 src
>>>>
>>>> However, I do find libhamlib.a and libhamlib.la in
>>>> .../build/src/.libs, and after copying them to their normal location in
>>>> Greg's JTSDK-QT, WSJT-X seems to build correctly.  (The build was,
>>>> however, using the old (4/2/2014) include files, and perhaps other parts
>>>> of the April 2014 build of hamlib.)
>>>>
>>>> So...
>>>>
>>>> 1. Has something in "make install" failed to work for me as you expected?
>>>>
>>>> 2. I see no use of CMAKE_PREFIX_PATH anywhere in CMakeLists.txt, and
>>>> inserting the line
>>>> 	set (CMAKE_PREFIX_PATH C:/Users/Joe/hamlib_g4wjs)
>>>> at the top of CMakeLists.txt seems to do nothing.  Have I got something
>>>> wrong here?
>>>>
>>>> 	-- Joe, K1JT
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> wsjt-devel mailing list
>>>> wsj...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>

Re: [wsjt-devel] Packaging for -rc1

[Bill S. <g4...@cl...>]

On 24/09/2014 18:00, Joe Taylor wrote:
> Hi all,
Hi Joe,
>
> Should the installation packages for wsjtx-1.4.0-rc1 include the
> latest-and-greatest version of the WSJT-C User Guide?  It's online at
>
> http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main.html
>
> Which is good, since that lets us continue to improve the manual.
> However, for occasions when internet is not available, maybe it should
> be installed locally as well.  Perhaps even add an item such as "Local
> User Guide" on the Help menu?
We can certainly do that. The installer already creates a web link in 
the start menu and the programs and features entry but they are WIndows 
specific places. A local help menu item is no problem and a good idea, 
should we use a Qt window to display it (might be expensive in terms of 
installer size if we need other DLLs) or shell out to the default web 
browser. I need to check what Qt has in the way of launching a default 
web browser in a portable fashion.
>
> While I'm at it, nit-picking: since the manual's name is "WSJT-X User
> Guide", we should change the Help menu item "Online User's Guide" to
> read "Online User Guide".
Yes.
>
> Bill, are you going to commit the change with a box for "Allow Tx
> frequency changes while transmitting"?
I was waiting for any opinions on the whole lockout behaviour stuff I 
sent you which is in front on my local commit queue, the change is made 
and committed locally here. If you are OK with the other changes I'll 
push the lot out to the repo.
>
> 	-- Joe
73
Bill
G4WJS.

Re: [wsjt-devel] Packaging for -rc1

[Joe T. <jo...@pr...>]

Bill, Greg, and all --

I'd say display the local copy of ":WSJT-X User Guide" in the default 
web browser -- just as we do, already, with the online URL.

And yes, go ahead with committing the lockout behavior code.

I agree that building "rinstall" before the "package" target is not 
necessary.

Greg -- I think maybe I asked this before, but don't remember the 
answer.  After "build wsjtx package", the "package" directory remains 
empty but wsjtx-1.4.0-rc1-win32.exe appears in the "build" directory. 
Is this really what you want?  I can't recall that I've ever seen 
anything in the "package" directory.

	-- Joe

On 9/24/2014 1:11 PM, Bill Somerville wrote:
> On 24/09/2014 18:00, Joe Taylor wrote:
>> Hi all,
> Hi Joe,
>>
>> Should the installation packages for wsjtx-1.4.0-rc1 include the
>> latest-and-greatest version of the WSJT-C User Guide?  It's online at
>>
>> http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main.html
>>
>> Which is good, since that lets us continue to improve the manual.
>> However, for occasions when internet is not available, maybe it should
>> be installed locally as well.  Perhaps even add an item such as "Local
>> User Guide" on the Help menu?
> We can certainly do that. The installer already creates a web link in
> the start menu and the programs and features entry but they are WIndows
> specific places. A local help menu item is no problem and a good idea,
> should we use a Qt window to display it (might be expensive in terms of
> installer size if we need other DLLs) or shell out to the default web
> browser. I need to check what Qt has in the way of launching a default
> web browser in a portable fashion.
>>
>> While I'm at it, nit-picking: since the manual's name is "WSJT-X User
>> Guide", we should change the Help menu item "Online User's Guide" to
>> read "Online User Guide".
> Yes.
>>
>> Bill, are you going to commit the change with a box for "Allow Tx
>> frequency changes while transmitting"?
> I was waiting for any opinions on the whole lockout behaviour stuff I
> sent you which is in front on my local commit queue, the change is made
> and committed locally here. If you are OK with the other changes I'll
> push the lot out to the repo.
>>
>> 	-- Joe
> 73
> Bill
> G4WJS.
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Packaging for -rc1

[Bill S. <g4...@cl...>]

On 24/09/2014 18:11, Bill Somerville wrote:
> On 24/09/2014 18:00, Joe Taylor wrote:
<snip>
>> Should the installation packages for wsjtx-1.4.0-rc1 include the
>> latest-and-greatest version of the WSJT-C User Guide?  It's online at
>>
>> http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main.html
>>
>> Which is good, since that lets us continue to improve the manual.
>> However, for occasions when internet is not available, maybe it should
>> be installed locally as well.  Perhaps even add an item such as "Local
>> User Guide" on the Help menu?
> We can certainly do that. The installer already creates a web link in
> the start menu and the programs and features entry but they are WIndows
> specific places. A local help menu item is no problem and a good idea,
> should we use a Qt window to display it (might be expensive in terms of
> installer size if we need other DLLs) or shell out to the default web
> browser. I need to check what Qt has in the way of launching a default
> web browser in a portable fashion.
OK Qt has QDesktopServices to do this so all that remains is how the 
WSJT-X CMake install target gets the actual content. Should it just 
download the version from the URL above as at the time the build is run?

<snip>

73
Bill
G4WJS.

Re: [wsjt-devel] Packaging for -rc1

[Joe T. <jo...@pr...>]

> OK Qt has QDesktopServices to do this so all that remains is how the
> WSJT-X CMake install target gets the actual content. Should it just
> download the version from the URL above as at the time the build is run?

Yes.  That will ensure getting the latest (released) version of the manual.

	-- Joe

Re: [wsjt-devel] Packaging for -rc1

[KI7MT <ki...@ya...>]

Hi Joe,

On 9/24/2014 17:21, Joe Taylor wrote:
> Bill, Greg, and all --
> 
> I'd say display the local copy of ":WSJT-X User Guide" in the default 
> web browser -- just as we do, already, with the online URL.
> 
> And yes, go ahead with committing the lockout behavior code.
> 
> I agree that building "rinstall" before the "package" target is not 
> necessary.
> 
> Greg -- I think maybe I asked this before, but don't remember the 
> answer.  After "build wsjtx package", the "package" directory remains 
> empty but wsjtx-1.4.0-rc1-win32.exe appears in the "build" directory. 
> Is this really what you want?  I can't recall that I've ever seen 
> anything in the "package" directory.

I just built: build wsjtx package

and wsjtx-1.4.0-rc1.exe is in the package directory

See Lines 205 to 209 in jtsdk-cmake.bat
-------------------------
:NSIS_PKG
cmake --build . --target package
IF NOT EXIST %BUILDD%\%OPTION%\%WSJTXPKG% ( GOTO NSIS_BUILD_ERROR )
mv -u %BUILDD%\%OPTION%\%WSJTXPKG% %PACKAGED%
GOTO FINISH_PKG
-------------------------

The mv line should be putting the file in ../package, this may have been
an artifact of having the wrong file name in the build scripts, %WSJTXPKG%.

Try updating from Docs, then rebuild the package target, it should land
in ../package

73's
Greg, KI7MT

> 	-- Joe
> 
> On 9/24/2014 1:11 PM, Bill Somerville wrote:
>> On 24/09/2014 18:00, Joe Taylor wrote:
>>> Hi all,
>> Hi Joe,
>>>
>>> Should the installation packages for wsjtx-1.4.0-rc1 include the
>>> latest-and-greatest version of the WSJT-C User Guide?  It's online at
>>>
>>> http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main.html
>>>
>>> Which is good, since that lets us continue to improve the manual.
>>> However, for occasions when internet is not available, maybe it should
>>> be installed locally as well.  Perhaps even add an item such as "Local
>>> User Guide" on the Help menu?
>> We can certainly do that. The installer already creates a web link in
>> the start menu and the programs and features entry but they are WIndows
>> specific places. A local help menu item is no problem and a good idea,
>> should we use a Qt window to display it (might be expensive in terms of
>> installer size if we need other DLLs) or shell out to the default web
>> browser. I need to check what Qt has in the way of launching a default
>> web browser in a portable fashion.
>>>
>>> While I'm at it, nit-picking: since the manual's name is "WSJT-X User
>>> Guide", we should change the Help menu item "Online User's Guide" to
>>> read "Online User Guide".
>> Yes.
>>>
>>> Bill, are you going to commit the change with a box for "Allow Tx
>>> frequency changes while transmitting"?
>> I was waiting for any opinions on the whole lockout behaviour stuff I
>> sent you which is in front on my local commit queue, the change is made
>> and committed locally here. If you are OK with the other changes I'll
>> push the lot out to the repo.
>>>
>>> 	-- Joe
>> 73
>> Bill
>> G4WJS.
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

-- 
73's
Greg, KI7MT

Re: [wsjt-devel] Packaging for -rc1

[Joe T. <jo...@pr...>]

RR Greg, thanks.  After updating from C:/JTSDK-DOC/doc,
wsjtx-1.4.0-rc1-win32.exe shows up in the package directory.

	-- Joe

On 9/24/2014 1:44 PM, KI7MT wrote:
> Hi Joe,
>
> On 9/24/2014 17:21, Joe Taylor wrote:
>> Bill, Greg, and all --
>>
>> I'd say display the local copy of ":WSJT-X User Guide" in the default
>> web browser -- just as we do, already, with the online URL.
>>
>> And yes, go ahead with committing the lockout behavior code.
>>
>> I agree that building "rinstall" before the "package" target is not
>> necessary.
>>
>> Greg -- I think maybe I asked this before, but don't remember the
>> answer.  After "build wsjtx package", the "package" directory remains
>> empty but wsjtx-1.4.0-rc1-win32.exe appears in the "build" directory.
>> Is this really what you want?  I can't recall that I've ever seen
>> anything in the "package" directory.
>
> I just built: build wsjtx package
>
> and wsjtx-1.4.0-rc1.exe is in the package directory
>
> See Lines 205 to 209 in jtsdk-cmake.bat
> -------------------------
> :NSIS_PKG
> cmake --build . --target package
> IF NOT EXIST %BUILDD%\%OPTION%\%WSJTXPKG% ( GOTO NSIS_BUILD_ERROR )
> mv -u %BUILDD%\%OPTION%\%WSJTXPKG% %PACKAGED%
> GOTO FINISH_PKG
> -------------------------
>
> The mv line should be putting the file in ../package, this may have been
> an artifact of having the wrong file name in the build scripts, %WSJTXPKG%.
>
> Try updating from Docs, then rebuild the package target, it should land
> in ../package
>
> 73's
> Greg, KI7MT
>
>> 	-- Joe
>>
>> On 9/24/2014 1:11 PM, Bill Somerville wrote:
>>> On 24/09/2014 18:00, Joe Taylor wrote:
>>>> Hi all,
>>> Hi Joe,
>>>>
>>>> Should the installation packages for wsjtx-1.4.0-rc1 include the
>>>> latest-and-greatest version of the WSJT-C User Guide?  It's online at
>>>>
>>>> http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main.html
>>>>
>>>> Which is good, since that lets us continue to improve the manual.
>>>> However, for occasions when internet is not available, maybe it should
>>>> be installed locally as well.  Perhaps even add an item such as "Local
>>>> User Guide" on the Help menu?
>>> We can certainly do that. The installer already creates a web link in
>>> the start menu and the programs and features entry but they are WIndows
>>> specific places. A local help menu item is no problem and a good idea,
>>> should we use a Qt window to display it (might be expensive in terms of
>>> installer size if we need other DLLs) or shell out to the default web
>>> browser. I need to check what Qt has in the way of launching a default
>>> web browser in a portable fashion.
>>>>
>>>> While I'm at it, nit-picking: since the manual's name is "WSJT-X User
>>>> Guide", we should change the Help menu item "Online User's Guide" to
>>>> read "Online User Guide".
>>> Yes.
>>>>
>>>> Bill, are you going to commit the change with a box for "Allow Tx
>>>> frequency changes while transmitting"?
>>> I was waiting for any opinions on the whole lockout behaviour stuff I
>>> sent you which is in front on my local commit queue, the change is made
>>> and committed locally here. If you are OK with the other changes I'll
>>> push the lot out to the repo.
>>>>
>>>> 	-- Joe
>>> 73
>>> Bill
>>> G4WJS.
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> wsjt-devel mailing list
>>> wsj...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>

[wsjt-devel] Packaging for -rc1

[Joe T. <jo...@pr...>]

Hi all,

Should the installation packages for wsjtx-1.4.0-rc1 include the 
latest-and-greatest version of the WSJT-C User Guide?  It's online at

http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main.html

Which is good, since that lets us continue to improve the manual. 
However, for occasions when internet is not available, maybe it should 
be installed locally as well.  Perhaps even add an item such as "Local 
User Guide" on the Help menu?

While I'm at it, nit-picking: since the manual's name is "WSJT-X User 
Guide", we should change the Help menu item "Online User's Guide" to 
read "Online User Guide".

Bill, are you going to commit the change with a box for "Allow Tx 
frequency changes while transmitting"?

	-- Joe