[GNC-dev] CMake build system for gnucash-docs

[Geert Janssens]

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