On Nov 8, 2013, at 1:39 PM, Bernhard Spinnler <Bernhard.Spinnler@gmx.net> wrote:

BTW: ./run -I chokes on the same error ./run -i does. ./run -b completes successfully, but when I start caldavd twisted fails for some reason. I could provide details in case of interest. For now I will just ./run -n in place.

run -b is designed to produce a fully self-contained 'root' of Calendar Server and all its dependencies (all the way down to python!). It is currently used only for a very specific deployment, under very specific conditions, and has not been tested or qualified for general purpose use. Having said that, please feel free to experiment. I can't think of any reason why it would necessarily break outside of the current (internal) use case.

When using run -b, supply a path at which the root is to be installed; e.g. ./run -b /whatever/foo/bar/CalendarServer. I would recommend against using "/" or "/usr/local", at least until you are experienced with the behavior of this mode of operation, and are confident that you won't stomp something that shouldn't be stomped. Once again, I am reiterating that run -b is not that smart - it always builds / installs the same set of deps, and it's probably not going to keep you from shooting your legs off if you point it in the wrong direction.

To actually use the resulting root, it's expected that the invoking shell has sourced the environment.sh file which is produced by run -b and lives in the root's installation directory. I tried this just now, and it seems to work on Mavericks enough to build / install the root at the supplied directory. After sourcing the environment.sh file, I can run one of our support tools in 'bin' without throwing any Python tracebacks, which means all of our modules are being found and loaded. I stopped short of actually trying to run the service, as that would involve provisioning a postgres cluster somewhere and doctoring up a new config file.