Nicolas, can I make a suggestion for the build process? Tora_mod, right now, has this annoying thing where it checks for the headers it wants ... twice. Once for apache 1.3 and once for apache 2. And if it doesn't find them, it asks you to provide the path or enter "s" to skip. I'd like to suggest alternative logic:
1. Check for 1.3. 2. Check for 2.0. 3. If neither 1.3 or 2.0 exist, ask for a pointer to the headers or skip as per the current logic. 4. If either one exists, assume the user wants only that version of tora_mod to be built and (maybe) output a warning for the other one. Overriding this logic would be some environment variables: BUILD_TORA_MOD (this would signal that you want the binding with apache 1.3) BUILD_TORA_MOD2 (this would signal you want the binding with apache 2) TORA_MOD_DIR (this optional value would specify the path to the apache 1.3 headers) TORA_MOD2_DIR (same, but for apache2) SKIP_TORA (if set to any value other than nil, don't even check for the paths, just pass over tora completely) 2009/7/29 Nicolas Cannasse <[email protected]> > Jens Peter Secher a écrit : > >> I am preparing the Debian package for Neko 1.8.1 and I have two questions: >> >> Nicolas, do I need to bump the SONAME of libneko? Version 1.8.0 is >> named libneko.so.0.0; should version 1.8.1 be named libneko.so.1.0, or >> are there only conservative changes (libneko.so.0.1)? >> > > Yes, 1.8.1 should be backward compatible with 1.8.0 > > Any suggestions (Michael Pliskin?) on how I should distribute the >> various parts of Tora? Right now the Debian package only includes >> mod_tora2.ndll, but how would you ideally like it to be packaged? >> > > That's fine this way. People can download the tora haxelib package to get > the server : > > haxelib install tora > haxelib run tora > > Nicolas > > > > -- > Neko : One VM to run them all > (http://nekovm.org) >
-- Neko : One VM to run them all (http://nekovm.org)
