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
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)
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]
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.
Quote from: killerbot on July 16, 2008, 05:08:50 PM
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
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
ok, I was unaware there were so many variants :oops:
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.
Quote from: thomas on July 16, 2008, 06:34:16 PM
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.
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.
Quote from: thomas on July 16, 2008, 08:16:14 PM
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.