Re: [wsjt-devel] WSJT-X: User Guide built with CMake - was: Re: WSJT-X: User Guide updates for v1.5.0

[Bill S. <g4...@cl...>]

On 29/04/2015 02:24, KI7MT wrote:
> Hi Bill,
Hi Greg,
>
> On 04/28/2015 07:01 PM, Bill Somerville wrote:
>> On 29/04/2015 00:52, KI7MT wrote:
>>> Hi Bill,
>> <snip>
>>>> I suppose I could invoke asciidoc like:
>>>>
>>>>        ${PYTHON_EXE} ${ASCIIDOC} ....
>>>>
>>>> which would bypass the shebang/Windows file associations and allow the
>>>> location of Python to be set by the CMake finder, that way you could
>>>> steer the version of Python from CMAKE_PREFIX_PATH.
>>> There is some good news here. Makefiles process things one line at a
>>> time, and in their own shell.
>>>
>>> So, if there is a var set for the path to python2, then $(PYTHON)
>>> $ASCIIDOC) x,y,z should only use the Python2 interrupter. Likewise, if
>>> the var is set to Python3, it should work for 3 only.
>> I'm not sure of the relevance of any of that?
> See Below.
>
>> I have changed the WSJT-X CMake script to use find_package() to locate
>> the Python interpreter and have made it an error if a v3 or newer one is
>> found. I have also executed asciidoc explicitly using the interpreter
>> found above. This will allow multiple Python interpreters even if the v3
>> is first on the PATH or associated with .py files on Windows, all you
>> need to do is set the correct Python directory in your CMAKE_PREFIX_PATH
>> if you happen to have a Python v3 on the path ahead of any earlier version.
> The problem is not with WSJT-X or any of the Qt based, apps, it's with
> WSPR and WSJT where python3 is required to be in the path in order to
> build all the targets.
OK, so that is what I have dealt with. If you have Python 3 as your 
default Python interpreter  on any system, just install Python 2.x and 
don't add it to the PATH, put its location in CMAKE_PREFIX_PATH in your 
CMake toolchain file and you are good to go with WSJT-X.
>
> Additionally, can we build the docs without building the app? That would
> most helpful when writing the docs.?
Of course! Just build the 'docs' target. The CMake script knows if a 
file is changed and rebuilds accordingly. The doc/CMakeLists.txt has to 
be maintained with new/deleted source files just as per C/C++/Fortran 
files. Unfortunately CMake doesn't have an include scanner for asciidoc 
so it doesn't detect included file changes automatically like it does 
with program source files so they have to be maintained in the script.

   cmake --build <build-tree> --target docs

I have also put in an asciidoc config file to set up stuff like the 
version number as attributes so that the documents follow the versions 
without having to edit them. Also the final document is installed with a 
version specific name so the copies on the server can all coexist, the 
program gets the correct URL embedded automatically. Should make 
releases much simpler and deals with the documentation versioning 
problem that was discussed recently.

73
Bill
G4WJS.