This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Unable to use Path Variables in CCSv5.1 build logging location

I am using CCS version 5.5.1.00031.

Under the project properties I want to change the location of the C/C++ Build Logging location using relative addressing. When using a path such as d:\somedir\ccs.log it works.

When I try using environment variables defined in the Build Environment or Path Variables defined in the Linked Resources tab it will not output a log file. Here is couple of examples I have tried: ${PROJECT_LOC}\build\CCSv5_build.log and ${CWD}\build\CCSv5_build.log.  CCS does output the log when I set up the location shown in the examples. I have tried  ..\build\CCSv5_build.log also and that does not work either.

Note that I have removed the hardcoding of paths in the Build Environment and replaced with Linked Resources Path Variables(CWD changed from d:\projdir\debug to ${PROJECT_LOC}\debug. I assume this is ok.

Does the build logging location have to be hardcoded with a specifice drive letter and directory path or should it be able to interpret Path Variables?

  • Hi Dave,

    The log file location field needs an absolute path. Any kind of variable or relative path is not supported. Is there any reason why you would like to avoid an absolute path? This path is stored in the workspace metadata folder, so it is not something that would get imported into another workspace.

    btw - Linker Resource Path Variables can ONLY be used for linking source files to a project. It would not be used elsewhere.\

    Thanks

    ki

  • There is a reason I want a relative path. This project will be used in a team environment where anyone should be able to install CCS and open the project. I don't want to require other users to have to use the same path setup for the workspace or project that I use. Thus the reason for relative paths in the compile and link setup.  Also the project environment has a build directory where the output files are placed. It would be nice to have the build log placed there also. Our process requires verifying there are no warnings or errors in the build log so it needs to be easy to find. It is also an auditable artifact saved with other project information.

    The build log is buried in the metadata plugin folder in one of about 20 eclipse folders. None of these folders are intuitve as to where it is located so everyone must memorize where it is at. I suppose I can always look at the projects properties to find its location but that means I have to start CCS if I can't remember where it is located.

    I haven't done a team project export yet so I don't know how this is all going to work. If the logging directory changes to the path of anyone's workspace then I can live with it but if it retains my path then it will be very disappointing. In CCS 3.01 all anyone had to do was install CCS, wherever they wanted, load the project via the .pjt file and the project was opened with all settings and paths intact. It didn't matter what the root path was to the project files.

  • Dave Saubers said:
    This project will be used in a team environment where anyone should be able to install CCS and open the project. I don't want to require other users to have to use the same path setup for the workspace or project that I use.

    The main problem is that the path for the log file location is stored in your workspace metadata folder, not in the project files. So even if you could stick a relative path in there, that change would not take effect for anyone else that you shared the project with and imported the project into their workspace (since workspace metadata is not shared).

    It is the Eclipse/CDT way of storing this property in the workspace that is the main issue.

    Dave Saubers said:
    If the logging directory changes to the path of anyone's workspace then I can live with it but if it retains my path then it will be very disappointing

    It WILL always update the path to use the workspace location of the current workspace that the project has been imported to.

    Thanks

    ki