$workspace_name built-in variable?

[fabrizio.benedetti]

I need a $workspace_name variable... is there a built-in variable providing the workspace name (as there is a $project_name variable)? If not, is there anything I can do to work around it?

Ciao!
  Fabrizio

[fabrizio.benedetti]

  Is it possible to register a script that C::B would execute on loading a Workspace? And, can the script get the workspace name and set a variable?

...or:

  can I use script expansion where I need to obtain the Workspace name? [[ print(GetProjectManager().GetWorkspace().GetTitle()); ]] (but seems that no method exists to obtain the title of the current workspace)

[fabrizio.benedetti]

  I added the following built-in macros:

WORKSPACE_FILE, WORKSPACE_FILENAME, WORKSPACE_FILE_NAME, WORKSPACEFILE, WORKSPACEFILENAME
WORKSPACENAME, WORKSPACE_NAME
WORKSPACE_DIR, WORKSPACE_DIRECTORY, WORKSPACEDIR, WORKSPACEDIRECTORY

The attached patch shows my changes.

Ciao!
  Fabrizio

[attachment deleted by admin]

[killerbot]

though I haven't looked at the path (yet) sounds interesting, I would suggest to have jut one name for each variable, just like the other ones in CB, using the same style.

[fabrizio.benedetti]

I would suggest to have jut one name for each variable, just like the other ones in CB, using the same style.

  Actually, I dubbed the CB style for the project variables, which are provided in a number of variations (MacrosManager::RecalcVars()):

PROJECT_FILE, PROJECT_FILENAME, PROJECT_FILE_NAME, PROJECTFILE, PROJECTFILENAME
PROJECTNAME, PROJECT_NAME
PROJECT_DIR, PROJECT_DIRECTORY, PROJECTDIR, PROJECTDIRECTORY
PROJECT_TOPDIR, PROJECT_TOPDIRECTORY, PROJECTTOPDIR, PROJECTTOPDIRECTORY

  Maybe these could be reduced to just one name too.

Ciao!
  Fabrizio

[fabrizio.benedetti]

Two words on why do I need the workspace_name variable so badly:

My simplified scenario is the following: 3 components, each with its own project. Say, Component1, Component2, Component3. 2 products, each with its Workspace: say, ProductA, ProductB.

ProductA contains Component1 and Component2. ProductB contains Component1 and Component3.

Now, the shared Component(s) are configurable at compile time, by means of some conditional defines. Hence, the resulting dlls or libs will differ. By using the workspace name for composing the output path in the properties of the Component projects, I can direct the build output in the desired path: C:\Builds\ProductA\Component1 or C:\Builds\ProductB\Component1 are expanded from C:\Builds\$(WORKSPACE_NAME)\$(PROJECT_NAME).

Obviously, I also have to use the Workspace name in specifying the additional include paths for the shared Components, so the Components can include the configuration headers specified in the current workspace.

Hope this can be of any help for somebody else!

Ciao!
  Fabrizio

[killerbot]

ok, I was unaware there were so many variants 

[thomas]

The practical value or rather validity of variables like WORKSPACE_FILENAME or WORKSPACE_DIR is limited in my opinion, because a workspace does not have any such thing as a directory/location. A workspace is a collection of project files which may be located anywhere. Introducing something like a "workspace directory" suggests that there is some defined hierarchy, which is not the case.

[MortenMacFly]

Introducing something like a "workspace directory" suggests that there is some defined hierarchy, which is not the case.

Huh? I think he just means the location / name of the C::B *.workspace files. And this *does* exist and is defined.

But: You must not have a workspace. That's where the "default" (virtual) workspace comes into play. In that case the variable would provide nonsense.

[thomas]

What I mean is that 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.

For a workspace, that's not the case. A workspace is an arbitrary collection of projects, which may be on different disks or computers, and a single project can even be contained in several workspaces at the same time.
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". To me, that's misleading.

[fabrizio.benedetti]

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.