Bill, With the structure you suggest, would it be possible for a developer work on only one of the products without having to check out and build all products during development?
73, -- Edson PY2SDR On Sun, Mar 30, 2014 at 12:22 PM, Bill Somerville <[email protected]>wrote: > 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 >
------------------------------------------------------------------------------
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
