MakeDo now has client procedures that know about the creation of .mob, .c2c.c, and .o files. These clients are loaded on demand, to save GFI when you're running in PrincOps and don't need them.

Mimosa is reworked version of the Cedar/Mesa compiler. The intention is to eventually arrive at a compiler base that can have multiple targets. Mimosa does not generate BCD files; instead it generates MOB files for the symbol table information and C files for the executable code. The C files can be seen as intermediate files with the final result being the (UNIX) O files produced by the C compiler (and also a pass through the loader) [there is also a native code generator for the Dragon, but this code generator is currently mothballed], see MimosaDoc for more details.

The dependencies involved with Mimosa are similar to those with PrincOps compiler, except that BCD extensions are replaced by MOB extensions and that C and O files must be added when there is executable code (i.e. everything but DEFINITIONS files). The C files generated by Mimosa are renamed to have the extension .C2C.C to help differentiating them from user-written .C files. Files with extension .C2C.C produce files with extension .C2C.O.

The process of binding modules in Mimosa starts with a version of the PrincOps binder, called Cinder because, again, it generates C as intermediate code and includes (UNIX) "loading" the O files of the component modules into a single O file. Cinder accepts an extension of C/Mesa that includes a STATIC REQUEST statement to indicate that some files (outside the traditional Mesa/Cedar world) are required and should be included in the "loading" process. Typically these files correspond to O files generated by C files that do not correspond to any Mesa file.

MakeDo contains two different actions. The first action involves Mimosa and Cinder and generates foo.mob and foo.c from PROGRAM, or MONITOR file foo.mesa and CONFIG file foo.config, and foo.mob from DEFINTIONS file foo.mesa. The second action invoves the C compiler, the UNIX loader, and some transfer program (through the MMCCMesa et al commands) and converts foo.c into foo.o. The second action determines the correct invocation sequence to use based on whether there exists a foo.config or a foo.mesa file.

Mimosa and Cinder dependencies are similar to the PrincOps compiler. Cc dependencies are based on a version stamp encoded on the C files generated by Mimosa, and on create times if they are missing. The dependencies used for C are extracted from the #include "fileName" commands present in foo.c. Any reference to a path name in fileName (i.e. a "/") will cause the dependency to be ignored. Include commands of the form #include <fileName> are also ignored. The depencies do not take into account the role of the C preprocessor [so you can really shoot yourself in the foot if you want to].

Include dependencies that arise with some uses of TRUSTED MACHINE CODE are not modelled (yet). If I get requests, I'll get to it sooner.

The Cc actions give an special meaning to file names appearing in a DF file with an explicit directory part and ending with an .O extension. Such a file is assumed to be generated from a C file with a name obtained by replacing the .O by a .C and removing the explicit directory part. The transformation is performed as indicated in CcCommandsDoc, using the directory part to indicate the "remote binary directory". In addition, MakeDo gives specific semantics to several directory parts:

The actions used to construct .mob and .o objects can be modified by providing .switches files. If they exist, the contents of the file are passed as the value of the switches to Mimosa and ComplexCc, respectively. Switches passed to ComplexCc are interpreted as follows:

MakeDo issues MMCCMesa, MMCCConfig and MMCCC commands. These commands are a simple layer on top of ComplexCc, MS, and cRCopy. It is possible to customize the action performed using the MakeDo.UnixCommandsSubstitutions user profile entry. This entry contains a sequence of either pairs of strings or the string "defaults". The pairs are TextReplace match and replace string literals (i.e. no patterns). Defaults expands to the sequence:

The MMCC* commands can also be redefined for more complex customization [NB: the specialization mechanisms used for the MMCC* commands and for switches should be identical].

The boolean-valued user profile entry MakeDo.dbxDebug requests the use of the MS program to allow Cedar/Mesa source-level debugging.

The token-valued user profile entry MakeDo.Reporter indicates what method to use to report on the progress of MakeDo.

MakeDo has been ported to PCedar. The only "reporter" implemented in PCedar is "Files" [this will change soon now that we have PViewers], and none of the MDS user profile entries are meaningful; consequenlty, the -p argument only accepts one argument.

See the document LifeInPCedar.tioga for more details on how to use MakeDo on PCedar.

[See also [Mimosa]<Mimosa>Documentation>DFPorterDoc.tioga]

The DF software is not very adequate to describe the sharing of code that we want between PCedar and PrincOps. We hope that we will move to something better soon (most likely based on the Jasmine project from BSDU). In the meantime we have an organization based on a tree of DFs, where the top level Foo-Source.df contains the files that are common to both PCedar and PrincOps worlds, the second level contains two files, Foo-PrincOps.df (or plain Foo.df), for PrincOps files, and Foo-PCR.df for PCedar files, and the third level may contain up to 3 files, Foo-Sun3.df, Foo-Sun4.df, and Foo-SoftCard.df, which are children of Foo-PCR.df and which contain files that are specific to the sun3, sun4, or SoftCard respectively. An example of this organization are the files describing MakeDo. They are:

Because of this organization, it is not meaningful to "MakeVerify" any of these DF files on isolation. Instead, MakeVerify should be invoked with a "path" in the DF tree. The two paths that correspond to the above organization are:

Moreover, since some goals end up being in DF files other than the "leaves" of the "paths", the proper way to redo the packages would be:

Since typying these commands is cumbersome, each "leaf" DF file is expected to contain comments with the commands so that they can just be SHIFT-selected into a command tool.

Finally, note that the use of "qbo" and "smodel" must be changed. It is still correct to obtain the exported files from a DF file by just doing "qbo -p Foo.df", but to bring over all the files before making changes to a package, the whole path of files should be brought. In the above case:

And similarly for smodel.

Until all the PCedar DF files have been converted (and even after if we are not careful), it will be delicate to share the PCeadr and the PrincOps versions of a package in a local directory, but it can be done if you are pretty careful

A lingering problem with the DF-tree organization is that makeverify will complain when the structure of the intermediate DF nodes differs between the local disk and the remote location. What I do is to fix first all the other problems in the DFs first, then do an smodel of the MakeDo-Source.df, then another MakeVerify, then an smodel of the MakeDo-PCR.df, a MakeVerify, and an smodel of the MakeDo-Sun4.df. Or you can do the MakeVerify after all the smodels.