Hi Joe, I've been thinking about this on for a good while now. see below:
On 03/30/2014 08:23 AM, Joe Taylor wrote: > Hi all, > > Thanks for the good information and ideas being shared here. Our > combined efforts will surely help us to further improve WSJT-X and the > other WSJT-related programs, to make them easier to maintain and > distribute on multiple platforms, and to facilitate more widespread > participation in their development. > > Several things on my mind today: > > *To Do List* - Here's an item to add to the list I posted a few days ago. > > How best should we manage code used in more than one of our programs? > For example, I note that the following Fortran routines are common to > both WSJT and WSPR: azdist.f90, conv232.f90, db.f90, deg2grid.f90, > fano232.f90, four2a.f90, gencwid.f90, geodist.f90, getfile.f90, > grid2deg.f90, morse.f90, nchar.f90, packcall.f90, packgrid.f90, > packpfx.f90, pctile.f90, peakup.f90, set.f90, slope.f90, sort.f90, > ssort.f90, thnix.f90, thnix_stub.f90, unpackcall.f90, unpackgrid.f90, > unpackpfx.f90, xfft.f90. Many of these are used in WSJT-X, MAP65, and > WSPR-X as well. > > At present, we have multiple copies of these routines in the different > SVN branches, and they're not necessarily identical. They probably > should be, and it could help a lot if they were stored and maintained in > one place only. > > What is best practice in such a situation? Should we have an SVN branch > or branches called "common" or "libxyz" or some such, and build these > functions into libraries that can be linked by the several programs? We > would need to be aware that changes to things like calling sequences > might then require corresponding changes in more than one program. > Therefore, functions to be moved into such libraries should be ones that > have been stable for some time, and judged likely to remain so. > > I realize that (especially for code like that summarized above) I'm > probably the one best suited to do this work. But I would value any > organizational suggestions on how best to arrange our source-code tree. Ideas / Thoughts: I think that's a good idea, creating libwsjt / libwsjtx or something, then manage all the libs in a separate project / branch whatever. Where they go and how they are managed in the repo, I suppose that goes down to preference with respect to repository structure and VCS choice. - I will put together a simple matrix that lists all the lib type files v.s. applications need (based on current Makefiles and CMakeLists.txt) , then you can take a look and see what makes the most sense. Like you said, most of us can read the Fortran files, but understanding them well enough to make decisions is a whole different matter. - A second exercise would be to diff all 5 applications for the common files, and decide which is to be the master so to speak, then get everything up to the same level while thoughts / ideas about how best to manage things continues. I've run into a couple of instances, while trying to compile on Linux, where F90 / f90 / f or the file content itself was different. So at a minimum, even if nothing changes for the time being, we should go through all 5 apps and try to level them all up. > *Build Methods* - I think we're now committed to using CMake for > production builds of WSJT-X. CMake build tools are now in place for > MAP65 and WSPR, as well, although the scripts in place now are less > sophisticated than the one for WSJT-X. Some effort is needed here, and > CMakeLists.txt files for WSJT and WSPR could also be written. I'd like to give this a shot for WSPR, then when it's flushed out, maybe work on WSJT. While documenting the build methods for Linux, I had to work through a few CMakeLists.txt items for WSPR-X and MAP565 (minor, but important for Linux builds, Mac / OS X needs doing). The changes have not been checked into SVN yet, adn there sme issues with Rig control code that Im unable to fix. We already have a working autotools solution in place for WSJT and WSPR. I think the focus for change should be on the Primary & Secondary use platforms first, then worry about tertiary. Windows is cleary the front runner. Linux is seeing allot of new user activity due to the whole XP flap. I'm not sure about Mac usage or its share in the overall usage of the 5 applications. > *Trivia* - Does anyone here have some graphics skills? Our icons need > work. Somehow the ones in window title-bars look fuzzy compared with > wsjt.ico, the one we had been using; and I notice the icon for WSJT-X in > the Windows taskbar has become an unrelated system default. Can we > restore the use of the green-on-blue world globe for this purpose, and > perhaps tweak the picture so that it works well on all our supported > platforms? > > -- Joe, K1JT 73's Greg, KI7MT > > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
