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 _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
