On 29/04/2015 16:17, Michael Black wrote: Hi Mike, > Yup...GENERATE_DOCS was not turned on. OK, so what cause the build tree to get blown away, I hope that's not part of the JTSDK process because it would be a huge time waster :( > The old file name was just left over from previous builds/installs...a new > one was not getting installed... So you may want to remove that old file on > installation now. Cleaning up install destinations is not normally done. The WSJT-X build does create an un-install script but it only removes the files that were installed so it would have to be run manually before a new install. Either way it should not be an issue.
More importantly, package builds use a fresh install location every time so installers are always "clean". > Seems the "clean" during build also does not clean the docs directory. It cleans enough to guarantee a rebuild. The CMake clean target is a minimal one that only removes timestamps and main output files. > > Trying to configure with the docs switch on though generates an error > expecting Asciidoc. That is expected behaviour, as it is an option there is no point automatically de-configuring the docs build. > > Should that be a part of the JTSDK now? Probably, I expect Greg has it in hand for if we go ahead and the option gets changed to ON. > > Mike W9MDB 73 Bill G4WJS. > > -----Original Message----- > From: Bill Somerville [mailto:[email protected]] > Sent: Wednesday, April 29, 2015 10:09 AM > To: [email protected] > Subject: Re: [wsjt-devel] WSJT-X: Documentation generation in builds > > On 29/04/2015 15:27, Michael Black wrote: > Hi Mike, >> I used "build-wsjtx rinstall". I just checked and it didn't actually >> update the doc directory. > AFAIK that is doing a full install into a local directory. I assume you set > the CMake option WSJT_GENERATE_DOCS=ON in your build tree. >> I deleted the install\Release\doc directory and did the build again. >> The build put all the GNU files in a new doc directory...but not the >> manual...so the copy that was there was an old one. >> So does the new doc build NOT put the manual in the build doc directory > now? > No it should be putting it there if it is configured to build the docs. >> I understand about the rename during install...I may test that out -- >> I don't run from the build tree...I copy it over to another directory >> (actually on another PC via dropbox) > Ok, that should be fine for release configuration builds. It won't work for > debug configuration builds unless you have all the Qt and other debug > libraries on the PATH of the destination machine. > > Looking at this I did find another issue as the location of the > documentation at run time was being calculated from the CWD rather than from > the main executable location. I've fixed that but from your description that > is not the issue you have. It seems that the 'doc' > subdirectory is not being built at all in your case. The WSJT_GENERATE_DOCS > option is the most likely candidate although that being OFF wouldn't cause > an old wsjtx-mail.html to be installed. Is it possible that your build tree > is getting wiped and recreated with the default WSJT_GENERATE_DOCS=OFF? >> Mike W9MDB > 73 > Bill > G4WJS. >> >> -----Original Message----- >> From: Bill Somerville [mailto:[email protected]] >> Sent: Wednesday, April 29, 2015 8:58 AM >> To: WSJT software development >> Subject: Re: [wsjt-devel] WSJT-X: Documentation generation in builds >> >> On 29/04/2015 14:52, Michael Black wrote: >> Hi Mike, >>> Built r5323 and tried Help/Local User Guide -- doesn't work. >>> >>> Build put wsjtx-main.html in the doc directory Help is looking for >>> wsjtx-main-1.6.0-devel.html >>> >>> A rename does make it work. >> Sound like you haven't done the install phase of the build, that's >> where the rename happens. If you are going to run build products from >> the build tree (not recommended) then you will have to directly access >> the user guide with a web browser. >>> On a side note...looking the what's the doc directory...NEWS seems to >>> be a vestigial document now. >> I put them in as place holders since GNU standard layouts require them. >> Feel free to augment the content. >>> 73 >>> Mike W9MDB >> 73 >> Bill >> G4WJS. >>> -----Original Message----- >>> From: Bill Somerville [mailto:[email protected]] >>> Sent: Wednesday, April 29, 2015 6:50 AM >>> To: WSJT software development >>> Subject: [wsjt-devel] WSJT-X: Documentation generation in builds >>> >>> Hi All, >>> >>> I have added steps to the build to generate the WSJT-X user guide >>> automatically. Currently this is working on a copy of the user guide >>> sources. This has been added as a proof of concept and IMHO it is >>> working correctly and provides several benefits over the current >>> arrangement with a separate documentation branch and build tools: >>> >>> 1) Documentation sources are held in the same VCS branch as the >>> application source code, therefore they are branched and tagged along >>> with the application source code they refer to, >>> 2) The build script injects asciidoc attributes for the current >>> version identification automatically, saving effort of routine >>> editing tasks on the documentation source for every release. Other >>> attributes that the the build script can generate can be easily >>> added, >>> 3) The documentation generation works on all platforms, >>> 4) Developers and testers see the latest documentation when they make >>> or download a development build, >>> 5) The project web server can hold old versions of the documentation >>> which will be automatically referenced by the old version of WSJT-X, >>> this is facilitated by the generated document name being unique to >>> the >> version. >>> With any new build component there may be a requirement for tools to >>> be installed, this is no exception as the user guide generation >>> requires the asciidoc tool and that itself requires a Python >>> interpreter. For *nix systems including Mac this is not a big issue >>> as these can be trivially installed on a build host system. On >>> Windows there are a couple of complications, as always :( Firstly the >>> latest release of asciidoc is broken and hangs on Windows, secondly >>> as asciidoc does not work with Python 3 there needs to be a way of >>> doing builds on a Windows build host that may well have both Python >>> v2 and Python v3 installed. To help with this I have set the build >>> script to run asciidoc with a specific Python interpreter located by >>> an absolute path, this means that even on a system where Pythion v3 >>> is the default version, i.e. on the PATH, the build will still work >>> after a minor >> adjustment to your CMake toolchain file. >>> To try out the documentation build you need to checkout the >>> development branch ^/branches/wsjtx and make sure you have asciidoc >>> and Python v2 installed. On Windows you will need to download the >>> latest snapshot of asciidoc rather than the broken release version >>> v8.6.9, this can be fetched from >> https://github.com/asciidoc/asciidoc/archive/master.zip . >>> Unzip it somewhere and adjust your CMake tool chain file to add it to >>> the CMAKE_PREFIX_PATH variable. >>> >>> Currently the documentation generation is switched off unless you set >>> the CMake option WSJT_GENERATE_DOCS to ON in your build tree >>> configuration, if adopted this option would be ON by default. >>> >>> The only disadvantage I can see is that the documentation for the >>> various applications are no longer held in a single branch, but TBH I >>> believe this is actually an advantage and the single branch was more >>> of a solution to the problem of generation not being easy on some >>> platforms rather than providing any real benefit. Obviously the other >>> applications can maintain the current structure or move to a per >> application documentation VCS and build. >>> The implementation in the development branch is only a proof of >>> concept at this point, the actual documentation content is a copy of >>> the WSJT-X user guide sources with a few minor edits to take >>> advantage of the new features like automatic version number >>> injection. If we decide to go ahead with this change; I would delete >>> the trial documentation sources and move across the real sources in >>> Subversion along with their full history. This would require a small >>> amount of coordination during the switch over to ensure any in >>> progress edits are >> not lost. >>> I would also propose that this change is small enough in scope and >>> implications to merge into the WSJT-X branch for use in the impending >>> v1.5.0 release. >>> >>> 73 >>> Bill >>> G4WJS. ------------------------------------------------------------------------------ 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
