Am 22.03.19 um 19:52 schrieb Eugene Kilachkoff: >> I'm just convinced if it turn out it is really a CMake issue. > > Well.. it is.
Urgs, o.k. But congratulation you have found it! > I attached the patch that should fix this. Anyone here cares to > commit? Unfortunately the workflow for accepting patches is only targeted for using the GitHub way (at least this is my impression). Technically it's no real work to apply your patch locally, commit this with you as author and push it then ... If nobody will pick it up I will at least use it in the Debian packaging tree. > As I assumed, the DBLATEX_OPTIONS is in the same scope for different > macro invocations, so it is not reset and keeps the old value. There > were simply no way current implementation could have worked properly. Logic isn't always easy, especially if there are multiple iterations do happen with different variables. :) CMake isn't here better than the autotools and you will need to work a lot with debug output. >> On the other hand asciidoc is Python2 and has some nasty downsides, as >> seen with the Japanese characters that are not correctly parsed. > > At the level of maturity asciidoc has, it is quite hard to believe there > will still be errors in national charset handling. Moreover, our current > problems are further down the pipeline. Specifically, in dblatex which > we feed incorrect settings through incorrect style applied. But some of the UTF8 characters are not correctly parsed by asciidoc, not by dblatex. The problem is simply the constrains that the Pyrhon2 re classes have here! If there is going something wrong there is no chance this can be fixed later. > Even more than that, problem does not reproduce if you build ONLY the > Polish document. However, it does appear when we MIX Japanese styles > with Polish document, and WHY these artifacts are getting mixed is the > question that should've been asked. > > In any case, the fix is here, and the rest is of historical interest only. > > >> The days of Python2 are mostly gone. You will need to move over to >> Python3 or some other language. $(someone) just needs to start this. > > Do you really believe that switching into "better" language will > magically get rid of bugs? Again, these are two various problem we have discussed and figured out now. One is the restriction that asciidoc isn't able to parse strings correctly which containing some UTF-8 chracters and the other problems was the wrong logic within the CMakeList file. The latter is now hopefully fixed. The former might likely work smarter with some other implementation which needs to be evaluated. As for every Python2 script, the time is working against. -- Regards Carsten Schoenert -- Mailing list: https://launchpad.net/~kicad-doc-devs Post to : kicad-doc-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-doc-devs More help : https://help.launchpad.net/ListHelp
