gnome.yelp() doesn't compile help pages at compile time
mjog opened this issue · comments
Currently, gnome.yelp()
does not build Yelp help pages at compile time, instead it both builds and installs the help pages using (what I assume is) an install-time script hook.
Geary has historically built its help pages as part of the build process so we know it's working, to be able to proofread the manual using the app from the source directory, to catch tool errors, and so on. It would be good to be able to continue to do this.
PR to follow.
Famous last words. This is a bit murkier than I was expecting. My initial plan was to simply to arrange to call yelphelper.py build
as a run target, but then that still won't get executed by default, so then I looked at making it a custom target, but realised that would need a list of generated output files so it knows when it is out of date, but then you want to only rebuild the minimum if something has actually changed (e.g. a page or a .po file), and it all started to look kind of sucky.
So my currently plan of attack is to actually do it properly: as follows, in gnome.yelp()
:
- Read
LIGUAS
to work out what languages are present - Create two custom targets for each lang:
- Run
msgfmt
to createbuilddir/lang/lang.gmo
, depending onsrcdir/lang/lang.po
- Run
itstool
to create eachbuilddir/lang/source.page
, depending onbuilddir/lang/lang.gmo
and each source page
- Run
- Create a new custom target
help-project
that depends on each merged source page, and return that along with the currenthelp-project-pot
andhelp-project-po
targets.
Thoughts?
This is slightly problematic in that if the user does a ninja install as root the gmo files and merged pages in the build directory are owned by root, so you also need to be root to delete them.
This was reported by a user for Geary's build.
That is a general problem any time you call ninja
as another user, just a bit more prominent if its under install
.
As mentioned here, a consequence of this bug is that files built at install step won't be removed by ninja uninstall
.
As mentioned here, a consequence of this bug is that files built at install step won't be removed by
ninja uninstall
.
That is #1601
@mjog Any news on this one?
It's really annoying that ninja install
takes more than a minute (on an SSD) even though I just ran install.
@abderrahim, sorry, fell right off my plate, quite far apparently. :/
@eli-schwartz ah yeah, looks like it. I'm not like to get to this any time soon though, unfortunately. If anyone else want so step up, feel free.