The installation process is undergoing revision and this document is now out of date. There are two "installation" processes to be managed. The first covers the export of code from the CVS repository prior to rebuilding Poplog. This mechanism will be implemented in cvsbuild. The second covers the process of installing a pre-built version of OpenPoplog on a system. An initial release pack, using the InnoSetup package, is currently being tested.OpenPoplog runs on a variety of processors, operating systems and window managers. Users of the system range from those who just want to run a delivered Poplog application, to developers using Poplog, to the OpenPoplog developers themselves. Each combination of platform and usage may require a different configuration. This presents problems to the OpenPoplog developer who needs to keep everything within a single, coherent CVS repository and yet support users who need to install a specific configuration for their requirement.The remainder of this page probably belongs on another page.
So, why can we not have a direct mapping between the CVS and an OpenPoplog installation? Primarily, this is due to different versions of key binary and command files that overload elements within the namespace. The need to boot-strap the compilation and linking of a Poplog system from an existing working version means that it is critical that some namespace elements, such as the basepop11 and corepop11 binary executables, are occupied by the correct version for the target platform, but they all need to be stored in the repository, to enable the bootstrap process, but cannot all occupy the same namespace element.
One response to this is to create a repository architecture that captures the differences between configurations with a few additions to the normal Poplog architecture. One problem with this, is that a simple export of the repository contents for the "Poplog" branch, will not yield a correct configuration for immediate use. A further problem is that a changed file may need to be relocated, (or the check-in command relating to it may need to be rewritten), before it can be checked back in to the repository. To overcome this architectural dichotomy, a set of scripts exist to map between the CVS architecture and a specifically selected target architecture.
Please report errors and/or omissions to the editor.