This memo tells how to rebuild Alpine's bcds from their Cedar sources. It is implementor documentation; consult the administrator documentation for instruction on how to start up a server, using the new bcds.
Cedar release directory
The df files mentioned below all contain imports from the Cedar5.1 directory. Because this directory now changes with each Cedar release, these df files will have to be hand-edited with each Cedar release.
There being no accepted convention for denoting "the release directory of the current Cedar release,", we use "Cedar5.1" for that purpose below.
The Alpine server implementations
To establish context,
% CD ///AlpineRelease/ -- the name is up to you
% Bringover /Indigo/Alpine/Release50/Top/AlpUmbrella .
Alpine has five public interfaces, i.e. interfaces for remote access from workstations: AlpineTransaction, AlpineFile, AlpineVolume, AlpineOwner, AlpineDebug. AlpineEnvironment is a types-and-constants-only module used by everybody.
The public interfaces must occasionally be recompiled, generally due to Cedar changes. Most often the recompilation will not affect the format of calls on the wire, hence will not require the client implementations out in the world to change. Very occasionally the public interfaces will change in an incompatible way, as happened recently when the size of FileIDs changed. Then you must not only recompile, but change the version stamp on the interface and distribute new client software to the world.
You change the version stamp by editing AlpineRemoteExportImpl. You increment each half of AlpineRemoteExportImpl.version by one, then save the file.
If you are recompiling the public interfaces, you must be sure that the bcds of the same names (AlpineEnvironment.bcd, AlpineFile.bcd, etc) do not exist in the root directory; otherwise Lupine will become confused. Then
% Bringover -p /Indigo/Cedar5.1/Top/Lupine
% AddDebugSearchRule ///AlpineRelease/ -- to help Lupine
% AlpExportsCompileExports .
To rebuild the server implementations, whether or not you have recompiled the public interfaces,
% AlpUmbrellaCompileExports; AlpUmbrellaCompileInternals .
When you are done,
% SModel AlpUmbrella
% VerifyAlpine -- "VerifyDF AlpUmbrella" does not work very well
% Delete *!* -- clean up the scratch directory
See the comments in AlpUmbrella.df; they explain how to rebuild a single Alpine configuration without rebuilding everything else.
The Alpine client implementations
If you have just recompiled the server implementations, be sure to SModel them before building the client implementations.
To establish context,
% CD ///AlpineClientRelease/ -- the name is up to you
% Bringover /Indigo/Alpine/ClientRelease50/Top/AlpUser .
To rebuild the client implementations,
% AlpUserCompileExports; AlpUserCompileInternals .
When you are done,
% SModel AlpUser
% VerifyDF AlpUser
% Delete *!* -- clean up the scratch directory
Alpine and the Cedar release
The procedures above only write files on /Indigo/Alpine/. We release only the client software to /Indigo/Cedar*.*/. Unfortunately, not all client software is controlled by AlpUser.df: the public interfaces belong to AlpUmbrella. This means that a separate df file, AlpineUser.df, is required for the release.
A safe way to proceed is as follows:
% CD ///AlpineCedarRelease/ -- the name is up to you
% Bringover /Indigo/Alpine/Release50/Top/AlpUmbrella
% Bringover /Indigo/Alpine/ClientRelease50/Top/AlpUser
% Open /Indigo/Cedar5.1/Top/AlpineUser.df
% -- now edit it to point to the next release directory, say Cedar5.2, and save
% SModel AlpineUser
% VerifyDF AlpineUser
% Del *!* -- clean up the scratch directory