Hello, Joe and all, > 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.
Here is one option we have for the library build problem, as far as the version control stuff is concerned: Subversion allows you to get a subdirectory of your workspace from somewhere else. This "somewhere else" could be a different location in the same repository. Or even a particular location in a different repository altogether. The keyword here is "Subversion externals". The details on this can be found documented, e.g., at http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html We may want to consider using this Subversion functionality for our libraries. We could keep each library in a SVN place of its own. But import it into each project that needs it, into a subdirectory of that project. When we want to make progress on a library, it is possible to do so in the context of one particular program first. While that is ongoing, the other programs can continue to use an older version of the same library. Subversion externals allow for that. Vy 73, Andreas, DJ3EI Joe Taylor wrote 2014-03-30 at 14:23 UTC: > 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. > > > *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. > > *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 > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
