On 29/03/2014 20:07, Greg Beam wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Joe, Bill,
Hi Greg & All,
The following information will of use to anyone who is building WSJT-X
on a regular basis.
The preferred way of building WSJT-X is to use the CMake script, this is
a change from the until recently preferred qmake script and
lib/Makefile.{linux,MinGW}.
>
> While I certainly appreciate the ease in which the build happens, on
> my fastest Quad core box, it's taking upwards of 5 mins also (on Windows).
>
> Bill can correct me here if I'm out in left field here, but I think
> this is because I'm building the install target which includes the
> fixup_bundle and analysis sections.
That is probably correct, the bundle fixup part of the build is quite
slow. There are two mitigating factors:
The first is that most of the work is done the first time and it goes a
lot faster on follow on an incremental build (assuming you don't blow
away the build or install trees);
The second is that the fixup is only done on non-debug builds. This
partly because the performance of the fixup is very poor on Windows.
The basic strategy is that a Debug configuration build produces
artefacts that only run in a correctly setup environment. On Windows
that means the location of the libraries (Qt, fftw, and Hamlib) need to
be on the PATH environment at run time. This small inconvenience gives
greater flexibility in switching between different builds of those
libraries and a much faster build time.
For non-Debug configuration builds the full fixup is done. It tries (and
should succeed) in building a fully standalone package where all the non
system dependants are pulled in and a qt.conf is generated to link the
required Qt plugins, also pulled in as build artefacts. This fixup
process differs between platforms with most work being do on Mac where a
fully functioning Mac Application bundle is produced, Windows is the
next most complex with dependent libraries being pulled in and a
suitable qt.conf generated. On other systems the dependent libraries are
not bundled (this is not really possible on a Linux system as there will
be potential clashes with installed system versions), there the bundle
fixup is little more that removing RPATH references that would refer to
the build machine and not be portable.
So the first recommendation I would make is that if you do a lot of
builds, like in a development cycle, I would do Debug builds. I would
not recommend manually moving dependent libraries into the build
artefacts trees or install directories as this can lead to hard to
reproduce and diagnose errors. That means you need to have a test run
environment with the correct environment set for execution. I have
simple batch and script files to do this. I absolutely do not recommend
amending user or system PATH variables at startup or login with entries
related to testing programs since this quickly gets out of hand with
clashes of versions. Some facts that I've learned are not always common
knowledge:
1) On Linux a shared library will be runtime linked by an executable or
another shared library if the path to it is in the environment variable
LD_LIBRARY_PATH.
2) On Mac the same is true (1) but the preferred method is to use the
similar DYLD_LIBRARY_PATH.
3) On Windows similar library load behaviour is available via the PATH
environment variable, i.e. PATH isn't just for executables, it works the
same for DLLs too.
Moving on to fixup performance on Windows, this is atrocious and I know
why. CMake BundleUtilities scans each executable and libraries
recursively for dependants that are potential candidates to be pulled
in. To do this on a MinGW system it uses GNU 'objdump' which generates
copious output; CMake regular expressions are used to parse the output
to find the dependent DLLs. CMake regular expression processing is
clearly not very fast! Given that this is part of the official CMake
distribution there isn't a great deal we can do directly.
There is however a way to make things faster. If the tool 'depends.exe'
is available the CMake BundleUtilities will use that in preference to
GNU 'objdump'. 'depends.exe' produces a fraction of the output of
'objdump' and as a consequence the fixup runs much faster. The downside
is that to get 'depends' you need to install Visual Studio on the build
machine and also do the required setup in the environment you are going
to build from. Visual Studio is available in the "Express" form for free
from Microsoft and is a simple install. The environment setup is to
simply run the 'vcvars32.bat' batch found file in the VS system to
prepare your build environment.
>
> Subsequent builds are pretty fast actually, 30 seconds or less, until
> the mingw32-make install portion, that is where I'm seeing things slow
> down dramatically.
Ok, are you using Release builds? If so then I would recommend
installing VSExpress etc as described above.
>
> 73's
> Greg, KI7MT
73
Bill
G4WJS.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
