On 30/03/2014 16:37, Edson W. R. Pereira wrote:
Bill,
Hi Edson,
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?
The addition of CMake options (or see below ofr an automatic solution)
to select applications individually could help with that, it would lead
to a somewhat unintuitive repo layout, but there is no requirement that
the target of a CMake add_subdirectory() command is actually a
sub-directory. It can be a relative path or even an absolute path (I
wouldn't recommend that). So a developer could just check out the
top-level common project and the application(s) they want to work on. So
long as the relative path relationship between the common libs top-level
project to the individual application projects is correct; all will be ok.
The top-level CMake script could automatically exclude, from the build,
sibling application directories that aren't present.
73,
-- Edson PY2SDR
73
Bill
G4WJS.
On Sun, Mar 30, 2014 at 12:22 PM, Bill Somerville
<[email protected] <mailto:[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]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
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
