[sword-devel] Submission of OSIS files for Bibles and Commentaries

Peter von Kaehne refdoc at gmx.net
Thu Dec 24 01:44:55 MST 2015


Dear All,

The following is an adaption for the new more or less automatic process
which I now use for publication of modules on the CrossWire site.

Please ensure that all OSIS files you submit have the correct
osisIDWork, osisWork and xml:lang entries in the OSIS header. This is
important. 

Also the OSISRefWork entry in the OSIS header should read either
"Bible" or "Commentary". 

I extract as much as possible conf entries from the actual OSIS files. 

On the other side I will need in future only stubs for the conf files. 

Copyright entries, About and Description, Direction, Versification and
Lang are the minimum needed as of necessity. ShortPromo etc entries
will be accepted and filtered through. But everything that can be
surmised or computed, will be produced automatically. 

This is not notified so far, but I am simply giving you the heads up. 

When I come round to it I will write up the Wiki accordingly.

To give you an understanding of what I am trying to do (and am doing
now mostly correctly now):

A single "make" will produce a local (in the same directory) module,

"make test" will run it through all kinds of test and produce error
logs

"make localdeploy" will do all of the above but put it into my Xiphos
module folder, so that I can check it actually works

"make publish" will do all of the above (apart from the local deploy
and push it to the server, copy it into the usual folder, create a
zipped version and put this in the right place for And Bible etc,
create an index and put that into the right place, create a new
mods.d.tar.gz in the repo root folder, clean up everywhere and walk
away. 

I still need to write a CrossWire news and an announcement email by
hand.... 

Some of the above has still some bugs. E.g. the "make publish" only
works if I have undone the "make localdeploy". I am slowly getting to
grips with Make files. My scripts correctly find most Feature and
GlobalOptionFilters. Sometimes this is a bit irritating if you thought
your module has no footnotes, but the script finds the one solitary
one. 

I use the system now in production and use each flaw found to eliminate
it/expand on the process. It already is much faster than deploying a
module by hand, once you count all the little bits here and there in
(getting a Zip up, notifying Nic to get a index done etc) 

I have a similar system for USFM files. 

So far


Peter




More information about the sword-devel mailing list