Re: [GNC-dev] CMake build system for gnucash-docs
Op woensdag 4 september 2019 18:44:14 CEST schreef Frank H. Ellenberger: > Dear Geert, > > I currently see no reason to do this now > - release this weekend - and There's no impact on release. The autotools build system is still in place and unchanged. The cmake build system should be seen as a tech preview. Interested people can test it and provide feedback. CMake was introduced in the same way in the 2.6 release series and then made default in 3.x. I'm planning the same steps for docs. If we can successfully reproduce all the autotools capabilities, it hope it cmake to become to default for the 4.x series. > am also tired to rewrite the related wiki parts. I'm sorry to hear that. Nobody says you have to of course. This is a volunteer project after all. And for clarity your work *is* appreciated. For me migrating docs to cmake follows naturally from migrating code to cmake. It has always been my intention to end up with one build system only. It should reduce the amount of build system documentation we have to write as there's only one left. Now we have to explain the peculiarities of both cmake and autotools. > I think there are > several more important projects. Perhaps. > > 1. About CMake > In Code we should clean up CMake. Many parts were written a decade > ago. In between CMake got many modules, which on the long run might be > more error prone than our self written ancestors. > I agree CMake in code could use a review. That's a huge project impacting the actual code base. The CMake introduction on maint on the other hand doesn't impact the current build processes at all as autotools is still there and the default. > 2. in Docs: > 2.1 Conversion to po based translation. Current state: Apply recently > defined enities on documents. > I see my involvement here more on the structural level: help provide the tools to do po based translation and possibly even help in a semi-automated conversion of the existing documents to the po format. However I prefer to do that on cmake rather than autotools. We'll have to write new build rules to support a po based workflow. Doing so first in autotools means we have to port even more build system to cmake afterwards. > 2.2 The incomplete restructuring > > 2.3 Replace of over a decade outdatet GDP parts: I estimate 99% of xsl > came from them and I suspect it for many output glitches. Also many > docs contain their templates "Do not remove..." > GDP has been the Gnome1 ancestor of GDU, which ended with Gnome2. And > from there came also the OMF generation. But OMF should not simply be > dropped but replaced by other forms of metadata like e.g. .desktop > files. If you have more details on these, I'm interested. I don't see how .desktop files would replace the .omf file ? Where is that currently being used ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] CMake build system for gnucash-docs
Dear Geert, I currently see no reason to do this now - release this weekend - and am also tired to rewrite the related wiki parts. I think there are several more important projects. 1. About CMake In Code we should clean up CMake. Many parts were written a decade ago. In between CMake got many modules, which on the long run might be more error prone than our self written ancestors. 2. in Docs: 2.1 Conversion to po based translation. Current state: Apply recently defined enities on documents. 2.2 The incomplete restructuring 2.3 Replace of over a decade outdatet GDP parts: I estimate 99% of xsl came from them and I suspect it for many output glitches. Also many docs contain their templates "Do not remove..." GDP has been the Gnome1 ancestor of GDU, which ended with Gnome2. And from there came also the OMF generation. But OMF should not simply be dropped but replaced by other forms of metadata like e.g. .desktop files. Just my 2ยข Frank Am 02.09.19 um 19:29 schrieb Geert Janssens: > Over the weekend I spent a few cycles to port the gnucash-docs autotools build > system to cmake. > > Most of it is done and can be played with by checking out the current maint > branch on gnucash-docs. > The main missing elements are: > - generating the Windows specific chm files > - uninstall rules > - omf/scrollkeeper/rarian support > > The last one is easy: I don't intend to add this. It was there because old > versions of yelp (<2.23) required it. No platform we care about still uses > that old yelp version so omf is obsolete. > > The other two will follow hopefully somewhere next week. > > Other than that there are a few important changes between the autotools system > and the cmake system. The most important one is that autotools provided a > fully self-contained Makefile in each document directory. Cmake on the other > hand works with a single top-level makefile (or ninja ruleset if you prefer). > > That is, with autotools you could > cd guide/C > make html > And that would build you the html version of the English guide > > This is not possible in cmake. However I have tried to provide equivalent > targets instead wherever possible. So to achieve the above you can instead do > make C-gnucash-guide-html > > The targets are always named > -- > > So similarly you will find > de-gnucash-help-pdf > pt-gnucash-help-epub > ja-gnucash-guide-mobi > > and so on. > > Entering > make help > will provide a list of available targets to choose from. > > This gets even more complicated when attempting to install. There is only one > global install target (inherit to cmake). However one can restrict what to > install by setting environment variable CMAKE_INSTALL_COMPONENT to one of the > targets mentioned above (at least one for which install is implemented/makes > sense). So for example > > CMAKE_INSTALL_COMPONENT=C-gnucash-guide-html make install > > That will only install the English guide in html format. Currently this will > work for xml and html targets. The pdf, epub and mobi targets don't have > install rules. And I'm even considering dropping them for html. It doesn't > make much sense to have an install rule for html as it's not something a > packager will want to install on their system. They should use the xml target > instead. > > The last tidbit I'm still considering for improvement is to replicate the > install paths in the build directory, much like we do for the gnucash build > system as well. That is, instead of storing the pdf file in > /guide/C > store it in > /share/gnucash-docs/C > > There are a few additional notes in https://github.com/Gnucash/gnucash-docs/ > blob/maint/CMakeNotes.txt > > Feedback is welcome. > > Regards, > > Geert > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] gnucash maint: I18n fix: Trim user-visible strings from unneeded whitespace.
Op dinsdag 3 september 2019 22:34:33 CEST schreef Christian Stimming: > Am Dienstag, 3. September 2019, 08:36:20 CEST schrieb Geert Janssens: > > Op maandag 2 september 2019 22:27:02 CEST schreef Christian Stimming: > > > Updatedvia https://github.com/Gnucash/gnucash/commit/16a69e2a > > > (commit) > > > > > > from https://github.com/Gnucash/gnucash/commit/abc0964c (commit) > > > > > > commit 16a69e2a63f462346f498918eee738e5443bea58 > > > Author: Christian Stimming > > > Date: Mon Sep 2 22:25:39 2019 +0200 > > > > > > I18n fix: Trim user-visible strings from unneeded whitespace. > > > > > > This makes translations unnecessarily confusing. If the layout > > > needs some space, feel free to add padding and such. > > > > Isn't this kind of empty space introduced by the glade tool automatically > > if strings become too long ? > > I don't think so. In this particular case the space and line breaks showed > up in gnucash.pot and the translations, but in all other cases it does not. > I think this is just a misformatting from the previous editor of this glade > file who didn't check the effects of this formatting on the translation > strings, so I fixed this at least for the future. > > Regards, > Christian Ok, good to know :) Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
