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

[KI7MT <ki...@gm...>]

Hi Bill,

On 04/28/2015 07:37 PM, Bill Somerville wrote:
> 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.

WSPR and WSJT don't use Cmake, they use Autotools (Makefile) :-) .. I 
think I can add a separate Makefile in the docs dir  and call it from 
the parent. That is the part that needs testing.

Unless you converting WSPR and WSJT over to building with Cmake?

>>
>> 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

Ok, that's easy enough.


> 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.
>