On 26/11/2015 12:28, Barry Jackson wrote: > Hi Bill, Hi Barry, ... > This was just to test since I have been hitting some build issues with > the earlier versions which seem fixed in svn, however now I have found > this list I'm sure those can be resolved and I will continue with a > stable version for the distro package. OK, no problem with testing for future distribution. >>> It now looks for 'asciidoctor' not 'asciidoc' which breaks our build >>> unless we patch the CMakeLists.txt, can this be modified to accept both >>> names? >> The current development branch has switched to using asciidoctor for the >> User Guide as discussed here recently. > I need to look at the archives then as I only registered last night ;) It is spread across a few threads because Greg KI7MT is also switching over some of the other projects in the wsjt repo. The jist of it is that asciidoctor is much cleaner and easier to configure and is, almost, a drop in replacement for asciidoc. > >> The source asciidoc files have >> been edited slightly to work well with asciidoctor, I'm not sure if they >> are still fully asciidoc compliant. We still rely on asciidoc for the >> manpage generation since asciidoctor manpage support is not quite up to >> scratch yet. You will need to patch more than just the CMake script >> since the supporting style theme CSS has been removed. >> >> What is the issue with using asciidoctor? I assume there is no problem >> with having Ruby as a dependency and the asciidoctor tool is available >> as a source tarball I believe. If you have Internet capability on your >> build host then asciidoctor can be obtained using the Ruby gem package >> manager. > I had never heard of 'asciidoctor' until I hit this, and on Googling I > found an asciidoctor site which seemed to mix 'asciidoc' and > 'asciidoctor' arbitrarily in the text, so I assumed (bad I know) that > they were one and the same. > Mageia does not package asciidoctor yet, so I will look into that before > 1.7 is released. The terminology confusion probably comes from asciidoc source files being called asciidoc, asciidoctor processes asciidoc source files to produce documents, asciidoc also can produce documents from the same asciidoc source files. Think of it like "A C compiler produces programs from C source files, gcc also produces programs from the same C source files."
... > Regarding Hamlib, I would rather avoid any bundled software that is > available in the distro (it's also policy). I have been testing wsjtx > with our packaged hamlib and not had any problems that I am aware of, it > seems fine handling CAT with my TS-450S. > I have tested in both Mageia 5 (hamlib-1.2.15.3) and Mageia > 6(dev)(hamlib-3.0). > What is the difference between your fork of hamlib (which I also tested) > and upstream hamlib? If there are major differences, and we were to > patch upstream with your changes, are they likely to adversely affect > other softwares that use hamlib? This is a tricky area. First off there is no impact on other applications as we statically link Hamlib into WSJT-X. The background is that we found many issues with Hamlib despite it being the best available library for CAT control and more. I forked Hamlib and set about fixing the issues. WSJT-X should be built with a Hamlib from my fork at present, it is hoped that we can switch back to a Hamlib official package soon but we currently are still finding issues that are not fixed in Hamlib 3.0 stable. I am pushing all my fixes upstream to the Hamlib team so they are getting into their repo but there is still a lag. It is still strongly recommended to build with my Hamlib fork although the differences with Hamlib 3.0 are currently minimal, nevertheless a check with one rig is insufficient since the differences may only effect other rigs. The upstream source tarball we provide which you can build yourself (See ^/branches/wsjtx-superbuild for the project that does that) contains the correct Hamlib fork sources to match the WSJT-X it builds. Because of static linking, provision of an upstream source tarball and my fork being in a public repository (github) there should not be any packaging policy issues. Just think of it as more sources to WSJT-X rather than a package dependency. > > 73 > Barry > G4MKT 73 Bill G4WJS. ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
