[Pkg-crosswire-devel] BT docs, help and manpages

[Jonathan Marsden]

Dmitrijs Ledkovs wrote:

>> [Aside... I just noticed that right now BT's help wants to browse these
>> documents under /usr/local/share/bibletime/docs ... which happens to
>> work here, only because I did a manual install of BT earlier, but we
>> can't package it that way!  /usr/local is out of bounds for packaged
>> software... ]

> I am sure that a small prefix in the rules will put it in the right place

Well, probably ... but in the cmake rules, right?  Because we have to
get the software to look there for the help, too.

>>> Well that would be cool =D I'm still working on libsword7. I'm playing with
>>> symbols files so far they are misbehaving. But I should sort it out
>>> soon.

>> OK.  What exactly is going wrong with that?  Do you have an example of
>> what breaks?

> I don't know =D  I've branched off and started from scratch. Waiting
> for launchpad build results since it's the AMD64 that misbehaves =D

I am running om amd64 here... tell me how to test, and point me to your
bzr branch!  There was that rpath issue I had, but I already fixed that
using chrpath -d, you have that in your debian/rules, right?

>> Manpages for libsword7: This is a different kind of issue -- do we need
>> one manpage for each documented library API function?  We didn't have
>> them for libsword6, but that was a different era and maybe the rules are
>> tighter now than they used to be about that?

> There are ~2000 symbols exported by the library =D No debian doesn't
> force you to do that.

Not symbols, but function calls.  A manpage for every defined constant
would be madness, I agree!  But manpages in section 3 for the officially
documented API calls would be good to have, IMO.

> There are a few executables that libsword is building
> installmgr, cacheing-indexing thing and a few converters. They need manpages.

Ah, yes, I had asked about that days ago... noone has volunteered to
write those yet...

Jonathan