Hi Bill,

On 04/29/2015 10:06 AM, Bill Somerville wrote:
> On 29/04/2015 16:44, KI7MT wrote:
>> Hi Bill,
> Hi Greg,
> 
> <snip>
>>> Err, I am not aware of source highlighting being used in the User Guide.
>>> Are you referring to the development guide?
>> I think we took source-highlight out of all the docs for this reason. I
>> was merely providing this for information, as the Cyg32 method of build
>> allows the use of source-highlight on Windows, but that will change when
>> moving to the new method build.
> OK, thanks for that. I am aware of the complexities of using Pygments 
> and other source highlighters on Windows :(
>>
>>>> * I working on an update to JTSDK-Win32 to add everything to build the
>>>> docs, but it's going to take a while. This will also remove the Cyg32
>>>> install, which was useful for more than just docs.
>>> Just asciidoc and a working, but not necessarily default, Python 2.x
>>> where x>4 is all that is needed.
>> Yes, I need to add AsciiDoc and Python2 too the JTSDK Windows installer
>> and update paths in the WSJT-X build scripts..
> I assume CMAKE_PREFIX_PATH is what you mean, yes that is all.

For WSJT-X builds, yes, toolchain file seems like the right place for that.

WSPR and WSJT, I think I'll need to add ASCIIDOC and PY2 to the doc
Makefile. It should be ok, as Py2 is not needed for anything else, so
there is no reason to have Asciidoc or Py2 on the PATH for JTSDK-PY env.

>>
>>>> I'm not sure how Joe wants to handle all the other documentation yet, so
>>>> will need some guidance there.
>>> I expect the answer will be "There's no need to change them for now."
>>> given that WSPR and a large part of WSJT may be subsumed by WSJT-X's
>>> added modes.
>> Maybe, but If I take out Cyg32, there wont be any other doc builds, so I
>> can't do that until the shift is complete for all apps.
> OK, I was not proposing any changes to existing documentation build 
> processes, just eliding the WSJT-X user guide generation.
> 
> The WSJT-X build could use custom CMake commands to shell out to CygWin 
> if absolutely necessary, for example if we wished to generate a PDF 
> version of the manual using FOP or similar, but I would rather not go 
> there right now.

I hope it does not come to that, as Cygwin is OK for Cygwin exclusive
things, but mixing and matching is a pain, particularly with path names.

<snip>

73's
Greg, KI7MT

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to