Hi Bill, Mike,
An optional build method would be too add the desired Debug options to
the qtenv-build-wsjtx.cmd script, between lines 199 and 200.
then build with: build-wsjtx debug
That method creates a batch / cmd file with paths set to all the
required runtime DLL's. It also builds Joe's Check FFT program.
The default output directories for the build script are:
For 1.5-Devel
:: JTSDK\wsjtx\build\{Release,Debug}\bin
:: JTSDK\wsjtx\install\{Release,Debug}\bin
:: JTSDK\wsjtx\package
They can be changed at the top of the script with:
SET buildd=%based%\%app_name%\build
SET installdir=%based%\%app_name%\install
SET packagedir=%based%\%app_name%\package
The %option% {Release,Debug} is appended to those paths.
Obviously, this does not allow for comparing rxxx1 and rxxx2 as the
output dir's are static. However, it does allow testing both the release
and debug binary sets of the same SVN revision without overwriting.
Using the build script (for the package target), the final NSIS
installer is moved from the build directory to the package directory.
This is done to keep the package output dir's consistent with the other
WSJT applications.
There is a typo in the on-screen display message, the runtime file (for
Debug) should state wsjtx.cmd, not wsjtx.bat; I need to update that.
The -- -j xx option is enabled by default on Windows.
73's
Greg, KI7MT
On 03/03/2015 09:46 AM, Bill Somerville wrote:
> On 03/03/2015 16:40, Michael Black wrote:
> Hi Mike,
>>
>> OK…figured it out…the installer stays in the Release directory doing
>> it this way and not the "package" directory…I thought the time stamps
>> looked ok but they weren't.
>>
> As there is no sensible standard for hidden directories on Windows
> CMake/CPack use a leading underscore to signify hidden directories. I.e.
> the _CPack_Packages tree is internal to the implementation and doesn't
> contain useful output (well it does if something goes wrong but it tells
> you where to look in that case).
>>
>> So I was installing a slightly older version without the debug.
>>
> OK. A successful CMake build of a package target does end by displaying
> the path of the resulting installer package.
>>
>> Life is good again (and logical since I couldn't find the smaller
>> executable anywhere before)….
>>
>> Thanks Bill
>>
>> 73
>>
>> Mike W9MDB
>>
> 73
> Bill
> G4WJS.
>>
>> *From:*Bill Somerville [mailto:g4...@classdesign.com]
>> *Sent:* Tuesday, March 03, 2015 10:34 AM
>> *To:* wsjt-devel@lists.sourceforge.net
>> *Subject:* Re: [wsjt-devel] Debug in package
>>
>> On 03/03/2015 16:28, Bill Somerville wrote:
>>
>> On 03/03/2015 16:16, Michael Black wrote:
>> Hi Mike,
>>
>> Also I forgot to mention, check that the installer you ran is the one
>> you built. It is produced at the root of the build tree and will have
>> a modification time related to the build end time.
>>
>> No doubt I'm doing something wrong…somebody smack me with
>> enlightenment please…
>>
>> I'll try.
>>
>> I ran cmake-gui on the wsjtx\build\Release directory and set the flags.
>>
>> Then ran this in the Release directory
>>
>> cmake --build . --target install -- -j 8
>>
>> This makes a release version with debug as desired creating the
>> WSJT-X_trace.log file
>>
>> OK.
>>
>> Then run from the same directory
>>
>> cmake --build . --target package -- -j 8
>>
>> OK, that will build a deployment installer containing exactly the same
>> contents as the install target build above.
>>
>> The result from this package build (after installing the package) is
>> an executable without the debug info in \WSJT\WSJTX\bin
>>
>> 03/03/2015 09:33 AM 9,025,184 wsjtx.exe
>>
>> How are you determining that installed binary does not have the debug
>> trace facilities? Size alone may not be a good indication? Are you
>> sure you installed it into \WSJT\wsjtx ? See below - that file is not
>> the one that is packaged.
>>
>> If I look in the \jtsdk\ directory at this point I've got 5 wsjtx.exe
>> files – the 9,149,611 size indicative of having debug in it.
>>
>> There is no wsjtx.exe file with 9,025,184 bytes…so where is it coming
>> from?
>>
>> I would guess that is from a previous install and you have installed
>> the new one somewhere else or the installer didn't succeed.
>>
>> C:\JTSDK>dir wsjtx.exe/s
>>
>> Volume in drive C is NGOS
>>
>> Volume Serial Number is 6842-6994
>>
>> Directory of C:\JTSDK\wsjtx\build\Debug
>>
>> 03/01/2015 07:57 AM 26,710,147 wsjtx.exe
>>
>> 1 File(s) 26,710,147 bytes
>>
>> Directory of C:\JTSDK\wsjtx\build\Release
>>
>> 03/03/2015 09:52 AM 9,149,611 wsjtx.exe
>>
>> 1 File(s) 9,149,611 bytes
>>
>> Directory of
>> C:\JTSDK\wsjtx\build\Release\_CPack_Packages\win32\NSIS\wsjtx-1.5.0-devel-win32\bin
>>
>>
>> 03/03/2015 09:52 AM 9,149,611 wsjtx.exe
>>
>> 1 File(s) 9,149,611 bytes
>>
>> The above is the one that gets packaged in the NSIS installer.
>>
>> Directory of C:\JTSDK\wsjtx\install\Debug\bin
>>
>> 03/01/2015 07:57 AM 26,710,147 wsjtx.exe
>>
>> 1 File(s) 26,710,147 bytes
>>
>> Directory of C:\JTSDK\wsjtx\install\Release\bin
>>
>> 03/03/2015 09:52 AM 9,149,611 wsjtx.exe
>>
>> 1 File(s) 9,149,611 bytes
>>
>> Mike W9MDB
>>
>> 73
>> Bill
>> G4WJS.
>>
>> *From:*Bill Somerville [mailto:g4...@classdesign.com]
>> *Sent:* Tuesday, March 03, 2015 8:57 AM
>> *To:* wsjt-devel@lists.sourceforge.net
>> <mailto:wsjt-devel@lists.sourceforge.net>
>> *Subject:* Re: [wsjt-devel] Debug in package
>>
>> On 03/03/2015 14:45, Michael Black wrote:
>> Hi Mike,
>>
>> Assuming WSJT-X.
>>
>> I'm trying to build either a debug package or a release-with-debug
>> package. Trying to enable the WSJT-X_trace.log.
>>
>> I can build the debug or release targets with debug info no
>> problem. Just can't figure out how to make a package.
>>
>> Can someone elighten me as to the magic to make that happen?
>>
>> There are several reasons why an installer for a debug build is not
>> possible, the main one being that the debug build takes many short
>> cuts to get a fast build that make a debug build non-portable. Another
>> is that the matching debug Qt libraries are not really suitable for
>> deployment.
>>
>> I suspect you actually want debug trace logging in a release build,
>> this is possible. There are a few CMake options that control the
>> inclusion of the relevant components in a release configuration build.
>>
>> They are all documented and can be viewed using cmke-gui.
>>
>> WSJT_QDEBUG_IN_RELEASE when set to ON causes QDebug code to be
>> compiled in (qDebug () stream usage and debug stream insertors for
>> user defined Qt types for example).
>>
>> WSJT_QDEBUG_TO_FILE when set ON causes all QDebug generated output to
>> be redirected to "<temp-directory>/WSJT-X_trace.log".
>>
>> WSJT_TRACE_CAT when set to ON causes many rig control trace messages
>> to be generated.
>>
>> WSJT_TRACE_CAT_POLLS when set ON causes rig control trace from within
>> the CAT polling code, can cause very large trace files (only effective
>> when WSJT_TRACE_CAT is also ON).
>>
>> WSJT_HAMLIB_TRACE when set to ON causes the verbosity of Hamlib debug
>> trace messages to be raised to 'verbose'.
>>
>>
>>
>> Thanks
>>
>> Mike W9MDB
>>
>> 73
>> Bill
>> G4WJS.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
