-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bill,
Is this understanding correct: If the user wants to use Hamlib for rig control, they need to build a set of binaries on both *Nix and / or Windows? Can we still use DXLab or HRD instead of Hamlib as a short term alternative? As far as CMake goes, it's been working just fine here, both on Windows and *Nix, but your changes will take the qmake build method off the table, at least for now? I'm sure I'll have more questions down the road :-) 73's Greg, KI7MT On 3/26/2014 13:46, Bill Somerville wrote: > Hi All, > > I have finally put my head above the parapet and committed my long > evolving changes. > > The first issue is that there are several upstream changes to > Hamlib that are really required for this code to work correctly. > They are not yet all accepted into Hamlib due to the integrator for > Hamlib being in the middle of moving home. I do have a public git > fork of Hamlib from which you can clone and build, alternatively I > have several development systems available here (and can add more > if they can be built as a VirtualBx VM) where I can build a Hamlib > binary kits for general usage. > > It should also be noted that I have not updated the wsjtx.pro and > Linux/MinGW makefiles. I could do that fairly easily but have > chosen not to since the whole application builds just fine with > CMake on all current supported platforms. If this proves too be too > high a hurdle for anyone I will update the old build system files. > Note that the CMake build system can now generate installers for > Windows/Linux/Mac directly so it is not just an issue with > maintaining parallel build scripts. > > One very noticeable change is that the location of ancillary files > have changed. Writeable persistent data files now go to a "well > known" user specific location on each platform: > > Windows: %APPDATA%\WSJTX Linux: $HOME/.local/share/wsjtx Mac: > $HOME/Library/Application Support/WSJT-X and > $HOME/Library/Preferences > > These locations may vary slightly with o/s version due to file > system layout variations. > > Note that you do not need to put any files into these locations, > they get created by the running program itself. Also several files > have been built directly into the wsjtx binary as resources so > don't be worried that there don't appear to be any sample .WAV > files, Palette files or, kvasd.dat in the build or install output > directories. > > The consequence of this is two fold: > > 1) the settings will need redoing, as it happens the changes to > the settings .INI file are so great that a complete reset is best > anyway; > > 2) on Windows JTAlert will not work because JTAlert reads a couple > data files that WSJT-X writes to get program status. As an > intermediate measure until Laurie VK3AMA accommodates the new file > locations there is a CMake option to revert the location back to > where it is in the current release. This option is > WSJT_STANDARD_FILE_LOCATIONS which is ON by default, turn it off > and build if you want to interoperate with the current version of > JTAlert. > > That's all for now, there will surely be many more questions I need > to answer. > > 73 Bill G4WJS. _______________________________________________ > Wsjt-devel mailing list [email protected] > https://lists.berlios.de/mailman/listinfo/wsjt-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTMuKRAAoJEAmfcyeKlj0xitMIAPDN4XMuUgEkuWvRc9mZLTHR AbIH1TgXMG4rSDLOatabBGOaBDdGOtXBq0cPhmYzOjshEq+S41X+l9oViNQF23O1 GSSA6ntoatIbWmBE/rpaeYJlRLKOxNW1fRsvwk+MJ4Ph+sWLosFTGk9a85OO/fbp Aub+1exVhTXWRr4cCVwlnKn1dSnuwD4/HDM5IDRDYftcoNTd90kL68IdhcY+iLnk ENAxNznHAk1pX1rAVVtMsXMRRgSqpgI8AHgLaxlsV3TboDWvwBkvzJNppIxDXIvp YuiDGdD/IjUM40H6JM2eeiCZqLSWQo7JqQgX/MwOJrQTTZxHbLQqpp99ZFliN8g= =EYqT -----END PGP SIGNATURE----- _______________________________________________ Wsjt-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/wsjt-devel
