On 20/02/2014 19:49, Joe Taylor wrote:
Hi Bill,
Hi Joe,
So Joe, are you now able to build wsjtx on Windows with the
checked in CMake script?
Yes, the build seems to work perfectly.
I haven't thought about packaging issues yet, but it seems I may need
only to change the paths in wsjtx.iss. Or do you have another
packaging scheme that would be better?
CMake uses CPack to generate packages.
On Windows it supports NSIS and Wix.
On *nix it supports Debian and RPM plus various archive formats and
source packages.
On Mac it supports application bundles etc. in Drag'n'Drop and Package
Manager installers.
Most of the CMake setup is either automatic or common to all, some
tweaking for the various packaging tools such as providing graphics
artwork and icons is tool and platform specific.
All the generators basically mirror the CMake install tree into the
final package archive. There is a tool to pull in the external
dependencies automatically on Windows and Mac.
We do need to put some thought into the location of writeable files in
the final user install destination. Although writing to the binary
directory suits wsjtx it is not compatible with package "regulations" on
various platforms. The biggest complexity here is supporting multiple
instances of wsjtx and a bit of coordination with Laurie and JTAlert but
I'm sure it's not insoluble.
One outstanding issue is integration with QtCreator, I am not a
QtCreator user at all so I don't know how well building with CMake fits
in. Given that qt-project.org is clearly committed to CMake users since
they include and maintain the CMakeConfig scripts in the Qt releases, it
can't be that difficult. I'll admit to not having looked into this even
though it is on my list, does anyone have any experience? I would hope
there is some easy way to tell QtCreator to use a pre-defined external
command to build rather than use qmake.
I just tried opening CMakeLists.txt with QtCreator, rather than
wsjtx.pro. After a little bit of fooling around, it works OK.
It will not be a problem. I will continue to use QtCreator for
editing code and for designing the GUI. Actual project builds can be
done either inside QtCreator or in a command window.
OK, so the most common complicated part for inexperienced users will
probably be how to add new source files to CMakeLists.txt, that is a
pretty easy process to document.
So yes, let's make CMake the default for building WSJT-X.
OK, no need to retire the qmake or make Makefiles just yet but at some
point I will check in something that cannot be easily back fitted to
them. We don't need to worry about who uses which until then.
3. Unless I hear arguments against it, I propose to submit a ticket to
SourceForge on Monday next week, asking them to migrate the whole WSJT
project from BerliOS to SourceForge. No doubt this will be somewhat
disruptive. I imagine we'll all need to register at SourceForge,
possibly subscribe anew to mailing lists, etc., etc. Probably we
should refrain from doing any more commits to BerliOS after Monday.
Any other advice?
All sounds good to me.
<snip>
OK. There's nothing magical about next Monday -- we could put it off
for weeks, if necessary. But if we're ready to make the switch, I
guess we might as well bite the bullet sooner rather than later.
Agreed.
-- Joe
73 Bill
G4WJS.
_______________________________________________
Wsjt-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/wsjt-devel
