A Ceda Workspace File typically uses the extension xcws. It defines a set of projects to be built (i.e. added to an MSVC solution). A workspace file is stored in the virtual tree and therefore is assumed to be uniquely identified by a logical path. There are no additional constraints on the possible location of a workspace file.
Some projects are added to a workspace indirectly. For example, when adding a project, all its subprojects are implicitly added as well. These subprojects may in turn have subprojects and so on that are also added implicitly. Note that a project is only added to a MSVC solution once even though it may be a subproject of many projects.
One “parent” workspace can reference another “child” workspace. The parent inherits all the projects defined by the child. This referencing between workspace files can form arbitrary DAG structures (i.e. cycles are not permitted). The inheritance of projects is transitive.
The file format of an xcws consists of a name (which will be used for the generated MSVC solution file), followed by a list of double quoted strings enclosed in curly braces. Each string is a logical path using only forward slashes, either to a project directory or else to a child .xcws file. E.g.
"Object"
{
"Ceda/Utils.xcws"
"Ceda/cxObject"
"Ceda/Object/exObject"
"Ceda/Object/txObject"
}
Projects can be nested in the .xcws file to create additional dependencies between projects when the MSVC .sln file is generated. A workspace can reference another workspace in order to include all the projects and dependencies specified by that workspace. This results in the union of all the project dependencies.