Hi Joe, Bill, On 10/17/2014 06:15 PM, Bill Somerville wrote: > On 18/10/2014 00:56, Joe Taylor wrote: > Hi Joe, >> Hi Greg, >> >> About a possible common library: >> >>>> I would like to see any common libraries built with CMake, this is >>>> because CMake has powerful tools for exporting library code for use in >>>> other CMake built projects. This doesn't make them any less useful for >>>> non-CMake projects. >>> Unless you plan on coveting WSJT and / or WSPR over to Cmake, I >>> wouldn’t' want to deal with this at all, WSPR may not factor in, but >>> still. The builds for those two packages are already hybrids, adding a >>> third layer would compound things further. I'm sure there is a long list >>> of reasons why X is better that Y, but, seems to me, there are plenty of >>> fish to fry, so no urgent need to go throw a line in the water :-) >> It may not need to be very complicated. A simple CMakeLists.txt (or a >> simple Makefile) can build the library, say libpackmsg.a, from sources >> moved into a new branch. Building the library would be a prerequisite >> to building the programs, and would be managed by the CMakeLists.txt >> file (WSJT-X and MAP65) or Makefile.jtsdk (WSJT). > Of course you are correct but I see Greg's point too. I expect he is > concerned about the complexities of delivering an application on Linux > for example where the whole thing must be built from sources plus > existing packages. A statement like "Building the library would be a > prerequisite to building the program ..." is not trivial in the package > building world because the prerequisite build has to be part of the > product build. This is because the only binary inputs to the packaging > process allowed are other already in place packages. > > We have just attacked that same problem for WSJT-X where an autoconf > based hamlib build must be aggregated with the CMake WSJT-X build. > Fortunately in that case CMake provides the tools as we have > demonstrated with the new wsjtx-superbuild project. The same probably > isn't true of an autoconf based project which I believe some of our > applications are. That is part of the concern for sure, the other is, one library built one way and the other half built another all for the same app.
What I was meaning by building all the libraries was, I believe all 5 apps have a library, and addding a common library would make 6 libraries?. Why not create a libwsjt package ( similar to what hamlib does ) or something, which would include all libraries, mutual or exclusive, then link against that package. While this adds another package of sorts, it can simplify things a fare bit during local test builds, packaging, or infrastructure server builds. I would think, this approach should help with duplicate source also. I prefer GNU Make over CMake, but either one is a fine, the important thing is, they should all get built at the same time and by the same build system. >>> I certainly see the benefits of having a common library set, but if >>> that's to be done, do them all, not just one or two for a particular >>> need. Clearly a roadmap of some kind could be beneficial here, maybe >>> include long term integration plans for all the apps, if that is on the >>> cards. >> It's mainly the message packing and unpacking that needs to be >> consistent across all three programs. As you say, there is other >> potentially common code as well; but the benefits of making all of that >> code uniform across all programs are much smaller. > I can see a few other possibilities like rig control, location, distance > and, bearing functions. Yes, maybe the Astro Data also, SR/SR. MR/MS, Az/Elev bearing information. >>> A few months back, 6+ or so, I tried to do some commonality checks >>> between the different .F90 / .f90 files. I found allot of delta's, but I >>> had no way of knowing which file was truth, so, kinda of gave up on that >>> adventure. I think this would be benifical for sure, but do them all, >>> and publish the libs. >> Those deltas, of course, are the main motivation for maintaining a >> single set of source files. > There is a potential downside, updating a library with a poorly designed > interface, and library interface design is very difficult, can break one > client that uses it in some ambiguous way despite the change correcting > some defect for another client. So it does place a larger testing burden > on perhaps more mature applications that have fewer release cycles. > > I will always vote for reusing code by sharing a library rather than > copying sources and possibly diverging, but there is no free lunch here. But the upside is, its consistent, and if a problems arises, and the library hasn't changed, should point to the app. >> -- Joe, K1JT > 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://p.sf.net/sfu/Zoho _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
