On 13/11/2014 13:00, Greg Troxel wrote: Hi Greg,
> Bill Somerville <g4...@classdesign.com> writes: > >> OK, hopefully the WSJT-X superbuild project mentioned previously will >> help you with that as it aims to provide a "proper" upstream source >> tarball that will build on any *nix system. There are some restrictions >> in that it requires Qt 5 at least, other than that it aims to make your >> life as a *nix package maintainer as easy as possible. > Sure, needing dependencies is fine; qt5 is pretty normal these days. > > I am a little unclear on why what seems like a normal build is > superbuild, but when I get enough time to dig in I'll see where things > are and ask if I don't follow it. It will become clearer if you look at the wsjtx-superbuild build script: https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx-superbuild/CMakeLists.txt and that the above file is the only source in the superbuild project apart from documentation. It comes about because currently WSJT-X requires a build of a fork of hamlib. The superbuild project encapsulates building both hamlib and WSJT-X as a single step or, more relevantly to package maintainers, as a two step process in which the first step makes a source tarball suitable for building on another build host. You may ask why the normal WSJT-X build script does do this all already. The answer is two fold, firstly the hamlib fork is only a temporary situation and will go when the hamlib team make a release of v3 which will have all the fork changes included. The second is that it is not possible to build hamlib and WSJT-X in the same environment on Windows for various annoying but valid technical reasons outside of our control. > >> That's exactly where we are heading for away from Windows and Mac, I >> hope. The KVASD EULA is here: >> >> https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/trunk/kvasd-binary/kvasd_eula.txt > It seems that this grants permission for verbatim distirbution of a > binary along with the license. So there could actually be binary > packages (hosted at no-charge FTP sites, but not included on CDROMs for > which a fee is charged, to use the venerable 90s terminology :-). > >> The SVN layout is somewhat confusing. Most of Joe's projects are >> branches rather than being under a trunk. WSJT is the trunk, WSJT-X , >> WSPR, WSPR-X, MAP65 exist as branches and some have "real" branches such >> as WSJT-X v1.3 and WSJT-X v1.4 as well. > It would be nice to address this at some point, but I realize it's a lot > of churn for perhaps not a huge gain. But renaming in svn is pretty > easy. Agreed and it has been discussed. The current position is that it is more trouble than it is worth. > > The big question in svn layout is where to put the trunk/tags/branches > (TTB). It seems with several related but separable projects it makes > sense to have top-level not be TTB but wsjt, wsjt-x etc. and have each > of those have TTB. There is some background work on packaging some common functionality in libraries, this also has a bearing on any future reorganizations of the SCS repository. I suspect the first question to be asked is "Is having all the JT modes in one application a goal of the project?" and if the answer is yes; the single trunk/branches/tags layout is suitable, if no then; having a trunk/branches/tags per application or library may be better. One thing is sure, the current layout is a PITA for anyone who uses git-svn and also breaks the 'svn switch' command for some projects because the branch lineage in the repository is not consistent. > > If there isn't a reorg, it would be nice if the web site under > http://www.physics.princeton.edu/pulsar/k1jt/devel.html > explained this with a sentence or two under "Explicit Downloading > Instructions", and also explained how some svn branches are actually > branches. > >>> Longer term, it would be good to have a roadmap for removing the >>> need/desire to use non-Free code, as it seems to be causing signficant >>> practical problems (with the resulting lack of portability arguably >>> being the largest issue). I've seen some comments on the list, but am >>> unclear on the status/prognosis. >> As far as I understand the main issue is not just with the source code >> as such but the patents that protect the algorithm contained therein. > It would be nice to explain in the docs which countries that's valid in. > I've only see a reference to a US patent so far. > > 73 de n1dam 73 Bill G4WJS. ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
