Re: [wsjt-devel] (no subject)
On 12/04/2014 07:33, Claude Frantz wrote:
Hi Claude,
On 04/11/2014 07:40 PM, Greg Beam wrote:
Hamlib 3 is not part of my current Linux distribution. I have compiled
and installed it separately.
There some changes that are newer even than the Hamlib 3 main
repository, currently they are in my fork of Hamlib. They have been
submitted upstream to the Hamlib team but at the moment Nate N0NB (the
Hamlib integrator) is moving QTH so has higher priorities.
You can get the sources from my fork by:
git clone git://git.code.sf.net/u/bsomervi/hamlib u-bsomervi-hamlib
cd u-bsomervi-hamlib
git checkout integration
The integration branch has my very latest tested changes awaiting
acceptance upstream.
To build Hamlib on Windows you will need the full MinGW install, the one
bundled with Qt is only really suitable for building Qt projects and
doesn't contain the GNU tools needed for an autotools project like Hamlib.
You can build it as per Hamlib 3 with:
mkdir ~/build/hamlib
cd ~/build/hamlib
~/src/u-somervi-hamlib/autogen.sh --prefix ~/local/hamlib --disable-shared
make make install
What is the recommended method to tell Cmake to use this Hamlib 3
include and dynamic modules ?
If you have pkc-config installed then CMake will correctly identify the
Hamlib version and link it statically. On Windows you can get a cut down
binary pkg-config (the full package is difficult to install on Windows)
from https://sourceforge.net/projects/pkgconfiglite/files/ which works
just fine.
Tell CMake about the Hamlib location by adding it to CMAKE_PREFIX_PATH,
for example if you have the Qt5 package installed at .../Qt/5.2.1/ then
on Windows with the Qt5 MinGW tools set up (mingw48_32):
You will probably find it easier to set up a CMake toolchain file for
compiler and other tool chain location, I use:
#
# the name of the target operating system
set (CMAKE_SYSTEM_NAME Windows)
set (QTDIR C:/Tools/Qt/5.2.1)
set (FFTWDIR C:/Tools/fftw-3.3.3-dll32-2)
set (HAMLIBDIR C:/test-install/hamlib/mingw32)
# where to find required packages
set (CMAKE_PREFIX_PATH ${QTDIR}/mingw48_32 ${FFTWDIR} ${HAMLIBDIR}
${HAMLIBDIR}/bin)
# here is the target environment located
set (CMAKE_FIND_ROOT_PATH ${QTDIR}/mingw48_32)
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
#--
Then:
mkdir %HOMEPATH%\build\wsjtx\Release
cd build\wsjtx\Release
cmake -D CMAKE_TOOLCHAIN_FILE=%HOMEPATH%/MinGW-Qt-ToolChain.cmake ^
-D CMAKE_INSTALL_PREFIX=%HOMEPATH%/local/wsjtx ^
-D CMAKE_BUILD_TYPE=Release ^
%HOMEPATH%/src/wsjtx
Then build with:
cmake --build %HOMEPATH%/build/wsjtx/Release --target install -- -kj
That should leave a fully working WSJT-X in %HOMEPATH%\local\wsjtx\bin .
On Linux things are a bit simpler and a toolchain file isn't required;
so with commands something like:
cd ~/src
git clone git://git.code.sf.net/u/bsomervi/hamlib u-bsomervi-hamlib
cd u-bsomervi-hamlib
git checkout integration
mkdir ~/build/hamlib
cd ~/build/hamlib
~/src/u-bsomervi-hamlib/autogen --prefix ~/local/hamlib --disable-shared
make make install
mkdir -p ~/build/wsjtx/Release
cd ~/build/wsjtx/Release
cmake -D CMAKE_PREFIX_PATH=~/Qt/5.2.1/gcc_64\;~/local/hamlib \
-D CMAKE_INSTALL_PREFIX=~/local/wsjtx \
-D CMAKE_BUILD_TYPE=Release \
~/src/wsjtx
cmake --build ~/build/wsjtx/Release --target install -- -kj
~/local/wsjtx/Release/bin/wsjtx
Thanks a lot !
Best 88 de Claude
Any questions, don't hesitate to ask.
73
Bill
G4WJS.
The Makefile.linux build method has not worked since 3942 or 2842 cant
remember which. You need to build it with CMake and you Hamlib3 also.
I just built r4011 on Ubuntu 14.04 Beta2. I have it monitoring on 10m
this afternoon. All seems ok,
73's
Greg, KI7MT
On 04/09/2014 11:31 PM, Waldek SPdwaONG wrote:
Hi,
I have download latest version WSJT-X r4005 from svn adn I have try
compile on my UBUNTU 13.04 but I have problem follow:
when I have try compile:
cd lib/
make -f Makefile.linux
.
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously
Re: [wsjt-devel] (no subject)
Hi Bill,
Ok got it.
I'm using a native install of 14.04 so the VM issue not a problem. I'm
also using /proc/cpuinfo to get the core count so should be ok.
73's
Greg, KI7MT
On 04/12/2014 12:44 PM, Bill Somerville wrote:
On 12/04/2014 19:36, Greg Beam wrote:
HI Bill,
Hi Greg,
Thanks. I'm putting everything in /opt for testing and the installer
makes that easy.
I forgot to ask about one other thing. I can't find the documentation on
one of the flags your using:
-- cmake --build ~/build/wsjtx/Release --target install -- -kj
the ( -- -kj ) Is that the same as say, make -j5 on quad core box?
everything after -- is passed to the underlying make tool.
-k means keep going after errors, I run builds using the emacs compile
command and prefer all the errors in the compilation buffer at once.
-j is use multiple parallel command invocations where possible, the
number of parallel processes is determined by make if you don't pass a
number. I'm not sure it is related to the available core count, it seems
to be unlimited but that's no so bad since compiles are usually i/o
bound rather than CPU bound so they tend to wait anyway.
There is one gotcha I've found with '-j' on virtual machines, it seems
to be able to spawn more parallel processes than the vm can handle, so
in that case I use '-jn' where n is a couple more that the number of
cores assigned to that VM.
73's
Greg, KI7MT
73
Bill
G4WJS.
On 04/12/2014 12:24 PM, Bill Somerville wrote:
On 12/04/2014 19:19, Greg Beam wrote:
Hi Bill,
Hi Greg,
Quick Question. Did you install QT5 from the Linux open source installer ?
I use the open source installer for a vanilla install on all platforms.
If 5.2.x is in a distribution repository then that is probably the best
option as it will be picked up without having to specify
CMAKE_INSTALL_PREFIX. Having said that I haven't tested that because I
don't have a machine with 5.2.x available in the relevant repo.
I used the repo packages, but I think the installer method may be a
better way to go in the long run.
73's
Greg, KI7MT
73
Bill
G4WJS.
On 04/12/2014 03:29 AM, Bill Somerville wrote:
On 12/04/2014 07:33, Claude Frantz wrote:
Hi Claude,
On 04/11/2014 07:40 PM, Greg Beam wrote:
Hamlib 3 is not part of my current Linux distribution. I have compiled
and installed it separately.
There some changes that are newer even than the Hamlib 3 main
repository, currently they are in my fork of Hamlib. They have been
submitted upstream to the Hamlib team but at the moment Nate N0NB (the
Hamlib integrator) is moving QTH so has higher priorities.
You can get the sources from my fork by:
git clone git://git.code.sf.net/u/bsomervi/hamlib u-bsomervi-hamlib
cd u-bsomervi-hamlib
git checkout integration
The integration branch has my very latest tested changes awaiting
acceptance upstream.
To build Hamlib on Windows you will need the full MinGW install, the one
bundled with Qt is only really suitable for building Qt projects and
doesn't contain the GNU tools needed for an autotools project like Hamlib.
You can build it as per Hamlib 3 with:
mkdir ~/build/hamlib
cd ~/build/hamlib
~/src/u-somervi-hamlib/autogen.sh --prefix ~/local/hamlib --disable-shared
make make install
What is the recommended method to tell Cmake to use this Hamlib 3
include and dynamic modules ?
If you have pkc-config installed then CMake will correctly identify the
Hamlib version and link it statically. On Windows you can get a cut down
binary pkg-config (the full package is difficult to install on Windows)
from https://sourceforge.net/projects/pkgconfiglite/files/ which works
just fine.
Tell CMake about the Hamlib location by adding it to CMAKE_PREFIX_PATH,
for example if you have the Qt5 package installed at .../Qt/5.2.1/ then
on Windows with the Qt5 MinGW tools set up (mingw48_32):
You will probably find it easier to set up a CMake toolchain file for
compiler and other tool chain location, I use:
#
# the name of the target operating system
set (CMAKE_SYSTEM_NAME Windows)
set (QTDIR C:/Tools/Qt/5.2.1)
set (FFTWDIR C:/Tools/fftw-3.3.3-dll32-2)
set (HAMLIBDIR C:/test-install/hamlib/mingw32)
# where to find required packages
set (CMAKE_PREFIX_PATH ${QTDIR}/mingw48_32 ${FFTWDIR} ${HAMLIBDIR}
${HAMLIBDIR}/bin)
# here is the target environment located
set (CMAKE_FIND_ROOT_PATH ${QTDIR}/mingw48_32)
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
#--
Then:
mkdir %HOMEPATH%\build\wsjtx\Release
cd build\wsjtx\Release
cmake -D
