Rosemary 3.1 is like Rosemary 3.0, except that it is in Cedar 6.0 instead of Cedar 5.2. This necessitated a few minor changes:
The mesa modules now communicate by importing and exporting interfaces; they used to simply import directly from program to program, but they can't anymore because Cedar6.0 declines to guarantee its implementation of that.
The translator now generates Foo.Mesa and FooImpl.Mesa from Foo.Rose. The interface (Foo.Mesa) will contain declarations of all the cell types and cell type functions. The interface and implementation files have the same DIRECTORY statement, except that the interface appears in the implementation's DIRECTORY, but not in its own. The interface has no IMPORTS or EXPORTS. The Open statement generates output only in the implementation module; if you want something open in the interface, you have to explicitly insert an OPEN statement. In .Rose sources, the CEDAR statement inserts explicit Cedar code in the implementation module; the InterfaceCEDAR statement inserts explicit Cedar code in the interface.
The dependencies that Rosemary reports to MakeDo have been hacked some, hopefully giving better coverage, ableit with a slightly bogus mechanism. Rosemary now claims that the translator needs BarImpl.BCD when translating Foo.Rose (for all Bar that Foo references with a Library statement). The consequences are that it will try to compile the implementations of modules Foo references before it even tries to translate Foo, and that the dependency tree rooted at the top-level cell of a design really should include all of the parts now.
There is now a way to say that a .rose module is referencing a cell type that is implemented by something outside the control of the translator (e.g., extracted by Spinifex). The External statement takes a list of identifiers of cell types that the translator will simply assume exist (with uncheckable interfaces).
Rosemary.DF now uses the psuedo-server Rosemary. You should define it as
% PseudoServerAdd Rosemary $ Indigo