it may make sense to address a file as $PROJECT_DIR/file.ext or $PROJECT_DIR/../src/file.ext or whatever. That's because there is normally a relation between a project file, its location, and the files in a project. You can of course do it differently on purpose, but naturally it is like that.
However, when I think of a variable $WORKSPACE_DIR, what intuitively comes to my mind is "the directory under which all the projects in this workspace are found"
I think to
PROJECT_DIR and
WORKSPACE_DIR with the same semantics: the path part of the project / workspace full path. The idea of "the directory under which all the project files are found" definately makes sense, but it is not necessarily the same as the project / workspace file path: I usually create a
C:\Dev\myProject\ dir, and inside of that:
C:\Dev\myProject\src\,
C:\Dev\myProject\include\,
C:\Dev\myProject\project\, the latter being the location for .cbp project files, makefiles, build scripts, todo files, and other stuff. In this scenario,
C:\Dev\myProject\project\ could not be interpreted as "the directory under which all the project files are found" - better,
PROJECT_TOP_DIR could serve to the purpose, and should be set to
C:\Dev\myProject\ (it is automatically generated, is it?)
I may attempt a suggestion: leave
PROJECT_NAME and
PROJECT_DIR as they are now, and add
WORKSPACE_NAME and
WORKSPACE_DIR; also,
PROJECT_ROOT could be added, as a user-defined field in the project properties, replacing
PROJECT_TOP_DIR. Maybe
WORKSPACE_ROOT makes no sense, given projects may be scattered around multiple locations - but having at least one of
WORKSPACE_ROOT or
WORKSPACE_DIR to me makes sense: in the project files of my "shared components" (please see my earlier reply) I specify additional include paths using that information, so that the shared components can include different configuring headers when used in different workspaces.