On 30/03/2014 15:23, Joe Taylor wrote: > Hi all, Hi Joe, > > 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. One way to do this is to have a top level CMakeLists.txt that builds various static libraries from sources using the CMake add_library() command their sources can be stored in separate sub directories if required (desirable). Then have other sub-directories that have each application built by a CMakeLists.txt in that sub-directory that would be built from the top level CMakeLists.txt using the add_subdirectory() command. This structure allows common build options to be shared by all libraries and specific options to be used at the level of each application. Libraries would be directly available to the application build scripts as the CMake variables that describe them are passed down automatically by the add_subdirectory() command.
Implied by this sort of structure is that all products are built at the same time. IMHO this is a good thing because as you say library changes can potentially break multiple programs that depend on the library. Builds would not be slower because once everything is built once only the bits that you change would get rebuilt. I don't know the prerequisites for the applications other than wsjtx, I guess that such a reorganization would place a greater barrier to casual development since prerequisites for all applications would really need to be in place to build. This could be mitigated with CMake options to select individual applications, with the downside that an application not built may get broken unknowingly. This would probably require a bit or re-organization of the repository and a little work on the various CMake scripts for the individual applications. I have already made some inroads to use static libraries in the wsjtx build scripts. A library of Fortran/C/C++ code that is not dependent on Qt (libwsjt) and another library of common code that is Qt dependent (libwsjt_qt) are already built and used by the executables built. > > > *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. This would come naturally as a result of the above approach to sharing static libraries between 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? The Window title bar icon should not be fuzzy, that normally happens when Windows resizes an icon when the appropriate size isn't available. I have tried to generate every possible size that Windows might need as a clean bitmaps rendered from the original SVG artwork. It might be because I have bumped the gamma on the icon drawings quite a lot which can make them look a little washed out. The brightening is deliberate to make sure the icons stand out as well as possible on various backgrounds. Aside from the technical issue, I agree that the icons need some input from someone with some real graphic artist skills, I hacked them together more as place holders that serious attempts at Icon design. The build system currently requires two Icon drawings, both need to be SVG files, one is used for large icons (the one with orange text on it at the moment) and another used for smaller versions which is the globe without text. More details in the wsjtx/artwork directory which contains the original SVG drawings. > > -- Joe, K1JT 73 Bill G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
