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. > >> 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. > >> 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. > > -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
