Relative Paths

[kmc]

In LabWindows/CVI 7.1, Is there a way to add a project include path relative to where my current project is. I.E. I would like to be able to specify something like ..\\myincludes instead of c:\myproject\myincludes

[Wendy L]

Hello kmc,

We discourage editing the project file manually to determine if a file's location is relative or not. The project file is a text file, so you should open it up in any text editor. The general syntax for making a file path relative is:

Path Is Rel = True
Path Rel To = "Project"
Path Rel Path = "../testfile.h"
Path = "/c/documents/testfile.h"

The valid values for the Path Rel To tag are:

• Project - where the project file is located
• CVI - the base CVI path
• VXIPlug&Play - the base VXIpnp path

In particular, the include path section can be found under [Include Paths].

By using ../ in the relative path, you can reference locations that aren't just subdirectories of the current directory of your project.

Hope that helps.

[Jumper_Bones]

Hello Wendy, did this behavior change in CVI version 8.5 (the ability to hand-edit the [Include Paths] section in the project file)?

I used notepad to edit the paths to be relative, exactly as you had indicated.  Worked fine.

Then later in the day I made a change to the project file (added some other non-source file to it).

Saved the project, then exited.

Re-opened the project later, and the relative paths were now absolute (went back to "Include Path 1 Is Rel = False").

So I did an experiment to prove my edits were being stepped on by CVI:  I re-edited them to be relative path, was able to build project fine, made changes to contents of project via the CVI IDE, saved the project, viewed the edits I had made, and edits were back to absolute.

Am I doing something wrong here?

JB

[Jumper_Bones]

To save some back and forth questions, here is exactly what I'm doing (I used just 1 include path to make it simple):

The project file starts out like this (before I edited it):

[Include Paths]
Include Path 1 Is Rel = False
Include Path 1 = "/c/Workspace/dev/ATE/psdk/include"

I edit it manually to look like this (this project file lives in a folder next to the psdk folder, hence the use of the "../" notation):

[Include Paths]
Include Path 1 Is Rel = True
Include Path 1 Rel To = "Project"
Include Path 1 Rel Path = "../psdk/include"
Include Path 1 = "/c/Workspace/dev/ATE/psdk/include"

Open CVI, and it understands the relative include paths in the project, and it builds fine, even after I discard all previous object files.

But if I modify the project file via the CVI IDE, it goes back the way it was before I edited it.

JB

[LuisG]

Hello JB,

While it's true that you can edit project files manually, those changes are not necessarily persisted when CVI needs to re-save the file. Unfortunately, when it comes to writing out the paths, each time that CVI needs to save the project file it decides what, if anything, they are relative to, irrespective of their initial state in the file. This is one of the reasons why Wendy mentioned that is not recommended that you edit the project file directly. (The other reasons is that we don't document all the tags in the project file, and it is very easy to make a mistake that renders the project unreadable by CVI -- having said that, your changes are correct. Your modified project works just fine)

This behavior did not change in 8.5.

Up until CVI 7.0 (I think) paths needed to be at, or below, the project directory in order to be considered to be relative to the project. This was changed in 7.0 in order to allow paths located above the project directory to still be considered relative, as long as they were in the same drive. Unfortunately, however, this change was only made for files in the project. It did not apply to other paths, such as include paths. I've been trying to remember why that distinction was made, and I haven't been able to. But it was quite intentional, which gives me some pause, as far as changing this is concerned.

So you're left without any good options. I suppose you'd have to monitor your project file and repeat this change whenever CVI saves the file. I realize this is pretty cumbersome. We'll try to evaluate this some more on our end, and see if it continues to make sense to make this distinction between project files and other paths.

Luis

[Jumper_Bones]

Thanks for the quick reply, Luis.

I'm thinking that one work-around for me, for now, is to write a perl script to do these edits for me, and then manually invoke the script (using the "Tools>>Customize" mechanism) after a project file is saved from the CVI IDE.  It's a PITA, but workable.

The purpose for me needing a feature like this is to assist live debugging on the target platform (the test stand), using the exact same libraries from the development platform (laptop), which are stored on a common network drive that is mounted to each platform the same way (relative to the project folder).

In my opinion, the less that any sort of "customizations" live in (or relative to) the CVI IDE, and the more they live in (or relative to) the actual files in the project(s), including all the project.prj files and the workspace.cws configuration file, then the easy it is for me to develop/debug on one system or another, knowing that I got the same exact libraries and project settings in the project(s) and in the workspace.  Also, any edits to these libraries/settings become common to both platforms, even though I admit that the libraries are rarely edited unless it is necessary.

I believe this is true even for when a source code manager is used with the CVI 8.5 project(s).  I am about to start using the Accurev SCM with CVI 8.5 this month for the first time.  So far it looks compatible with it when I did a preliminary evaluation a couple of weeks ago, but I'll report back to this forum on how well I think it works after I've used it for a few more weeks/months.

JB

[LuisG]

JB,

Since you're planning on sort of automating the editing of the project file, you might want to look at this example:

C:\Documents and Settings\All Users\Documents\National Instruments\CVI85\samples\dotnet\FileSystemWatcher

You

[LuisG]

JB,

Since you're planning on sort of automating the editing of the project file, you might want to look at this example:

C:\Documents and Settings\All Users\Documents\National Instruments\CVI85\samples\dotnet\FileSystemWatcher

You can probably use some

[LuisG]

JB,

Since you're planning on sort of automating the editing of the project file, you might want to look at this example:

C:\Documents and Settings\All Users\Documents\National Instruments\CVI85\samples\dotnet\FileSystemWatcher

You can probably use some of

[LuisG]

JB,

Since you're planning on sort of automating the editing of the project file, you might want to look at this example:

C:\Documents and Settings\All Users\Documents\National Instruments\CVI85\samples\dotnet\FileSystemWatcher

You can probably use