Destination directory is not relative in build spec?

[Michael Aivaliotis]

[LV 8.5] I've just only now noticed this issue. When I open the exe build specification on different computers, where the *.lvproj file is located in a different folder, the Destination directory path setting in the Information section is absolute. This has serious implications in a multideveloper environment. Each developer has their project folder in their own location and when they open the build it will fail to execute because the path doesn't exist on their machine. This destination path needs to be relative to the project file. How many years has NI had to get this right?

[gmart]

QUOTE (Michael_Aivaliotis @ Mar 17 2008, 11:16 AM)

[LV 8.5] I've just only now noticed this issue. When I open the exe build specification on different computers, where the *.lvproj file is located in a different folder, the Destination directory path setting in the Information section is absolute. This has serious implications in a multideveloper environment. Each developer has their project folder in their own location and when they open the build it will fail to execute because the path doesn't exist on their machine. This destination path needs to be relative to the project file. How many years has NI had to get this right?

Can you give a concrete example of the directory problems you saw? The destination location should be relative to the project's location.

[Michael Aivaliotis]

QUOTE (gmart @ Mar 17 2008, 09:58 AM)

Can you give a concrete example of the directory problems you saw? The destination location should be relative to the project's location.

No problem.

I have the following setup:

Original Configuration:

D:\_Projects\Experiments\subfolder\buildpathissues\source\mycode\Untitled Project 1.lvproj

The build spec defines a destination as:

D:\_Projects\Experiments\subfolder\buildpathissues\builds

Now I move the subfolder here:

D:\_Data\subfolder\buildpathissues\source\mycode\Untitled Project 1.lvproj

Now when I open it in the new destination i see this in the build spec destination:

D:\_Projects\Experiments\subfolder\buildpathissues\builds

Nothing changed. The relative build destination is still the same, so why didn't the build spec reflect the new location?

[Michael Aivaliotis]

I've reported this to NI support.

[gmart]

I haven't got a change to look more into this, but the default destination directory is not the directory you listed. It is something like "D:\_Projects\Experiments\subfolder\buildpathissues\source\builds\mycode\My Application". So the directory in your example may not fall into the definition of "relative" from the algorithm that calculates this. I'll look more into this when I get a free moment.

[Michael Aivaliotis]

QUOTE (gmart @ Mar 19 2008, 06:15 AM)

I haven't got a change to look more into this, but the default destination directory is not the directory you listed. It is something like "D:\_Projects\Experiments\subfolder\buildpathissues\source\builds\mycode\My Application". So the directory in your example may not fall into the definition of "relative" from the algorithm that calculates this. I'll look more into this when I get a free moment.

Aaaarg! Definition of "relative"? Response from support:

QUOTE

Thank you for contacting National Instruments. The relative path seems to

work correctly when the default is used for the Destination Directory. I

have tested out several scenarios and it seems that the relative path is

used as long as the Destination Directory points to the location of the

LabVIEW Project or a sub-directory within that folder. I have also found

that it works when it points to a folder that is next to the folder

containing the project. I'm going research this issue further and get back

to you with more information. In the mean time, could you test out the

following destination directories?

1) D:\_Projects\Experiments\subfolder\buildpathissues\

2) D:\_Projects\Experiments\subfolder\buildpathissues\source

3) D:\_Projects\Experiments\subfolder\buildpathissues\source\mycode

Please let me know if you see relative paths when copying these Source

Distributions to another location on your hard drive. Thanks!

Just to remind y'all, the project file is located under the "mycode" folder.

So out of the three above folders, only the last 2 remapped correctly when the project file moved. I consider this a bug. What do others think? It sounds like, "leave everything as default and it will work". huh? The one good thing from this discussion is that now I finally understand the mystery of why the destination path behaves like it does and I hope I've saved others form smashing their computers to the wall.

[Michael Aivaliotis]

QUOTE (gmart @ Mar 19 2008, 06:15 AM)

I haven't got a change to look more into this, but the default destination directory is not the directory you listed. It is something like "D:\_Projects\Experiments\subfolder\buildpathissues\source\builds\mycode\My Application". So the directory in your example may not fall into the definition of "relative" from the algorithm that calculates this. I'll look more into this when I get a free moment.

Aaaarg! Definition of "relative"? Response from support:

QUOTE

Thank you for contacting National Instruments. The relative path seems to

work correctly when the default is used for the Destination Directory. I

have tested out several scenarios and it seems that the relative path is

used as long as the Destination Directory points to the location of the

LabVIEW Project or a sub-directory within that folder. I have also found

that it works when it points to a folder that is next to the folder

containing the project. I'm going research this issue further and get back

to you with more information. In the mean time, could you test out the

following destination directories?

1) D:\_Projects\Experiments\subfolder\buildpathissues\

2) D:\_Projects\Experiments\subfolder\buildpathissues\source

3) D:\_Projects\Experiments\subfolder\buildpathissues\source\mycode

Please let me know if you see relative paths when copying these Source

Distributions to another location on your hard drive. Thanks!

Just to remind y'all, the project file is located under the "mycode" folder.

So out of the three above folders, only the last 2 remapped correctly when the project file moved. I consider this a bug. What do others think? It sounds like, "leave everything as default and it will work". huh? The one good thing from this discussion is that now I finally understand the mystery of why the destination path behaves like it does and I hope I've saved others form smashing their computers to the wall.

[gmart]

QUOTE (Michael_Aivaliotis @ Mar 20 2008, 11:25 AM)

Aaaarg! Definition of "relative"? Response from support:

Just to remind y'all, the project file is located under the "mycode" folder.

So out of the three above folders, only the last 2 remapped correctly when the project file moved. I consider this a bug. What do others think? It sounds like, "leave everything as default and it will work". huh? The one good thing from this discussion is that now I finally understand the mystery of why the destination path behaves like it does and I hope I've saved others form smashing their computers to the wall.

I wasn't trying to be flippant when I said definition of "relative". I believe the support response is what I was trying to say. We are doing the relative-izing based on some definition of relative. I'll get you more info when I find it.

[Donald]

Hello,

I have a similar problem. One of my LabVIEW 8.5 Windows projects could not be build by a student he has the source directory on anthor path. I tried it myself and when I move the source code to another location. The build script for the installer fails with cryptic error message that 2 <app> files are missing. No identication which file or in what location these files are expected. Deleting the exe + data folders from the installer spec and adding them again solves the problem.

The build exe spec from the same project still works fine which is strange because Michael seems to have a problem with this. My project was upgraded from LV8.2.1, maybe this helps to find the problem.

Best regards,

Donald

[gmart]

QUOTE (Michael_Aivaliotis @ Mar 20 2008, 11:25 AM)

Aaaarg! Definition of "relative"? Response from support:

Just to remind y'all, the project file is located under the "mycode" folder.

So out of the three above folders, only the last 2 remapped correctly when the project file moved. I consider this a bug. What do others think? It sounds like, "leave everything as default and it will work". huh? The one good thing from this discussion is that now I finally understand the mystery of why the destination path behaves like it does and I hope I've saved others form smashing their computers to the wall.

First, a little history to put this situation into perspective. The decision of what to use for a default destination directory was based on the attempt to not cross link the output files and source files. This is why the default build location is a sibling directory of the source directory instead of a directory under it. If the output directory was under the source directory it could be possible that if a source file was missing, LabVIEW's search algorithm would find it in a subdirectory under the source location.

The calculation of "relative" is based on the above situation. The primary destination directory is considered "relative" if it's a sibling directory to the project's parent. This matches the behavior of the determination of the default destination. This choice for "relativeness" was chosen to avoid issues of having a destination path with many relative locations. For example, in your example, we could store the destination directory as "..\..\..\builds". Now if you move the project to C:\temp, what should happen?

I think we have this behavior because we don't have a user defined base path from which we determine our relativity. We use the project path as the base path but that may not be what you want. It works in a majority of the cases, but since projects can be moved anywhere, you do run into these types of problems. So, while this may not be the answer you wanted, I hope it sheds some light as to why the current behavior is what it is.

[Michael Aivaliotis]

QUOTE

we could store the destination directory as "..\..\..\builds". Now if you move the project to C:\temp, what should happen?

Well, it seems that you already have implemented a backup plan for this because if the path doesn't exist you revert to the fixed path right? So do the same. Ideally, the build should fail with a descriptive error because I've had many time where I have built something only to scratch my head when the output is missing. Then I realize thet the builder created the entire hierarchy of paths to the build out put in the WRONG location. However, the scenario you describe is a very rare case. Most developers I know work with a source folder NOT a single project file. Moving the project file is bad. Typicaly you would move your project folder. In my example, this is the "subfolder".

The main thing is that NI's definition of relative falls outside the typical understanding. The destination is NOT relative to the project file regardless of how you spin it. It's a non-standard handling. The other option is to allow the user to enter a relative path themselves in the form "..\..\..\builds" and the problem is solved. No sweat of NI's back.

[Yianni29]

LabVIEW 2010 is out, and when I try entering a relative path by using the "..\" construct, I receive an error message stating "Paths must be absolute"

At least now I have pre and post build events so I can move the project output to where I want them to be.

[David Wisti]

Those absolute paths have been a thorn in my side for quite a while. I'm very glad to hear there is a workaround using the pre and post build events. Can you post an example explaining how this is done?

LabVIEW 2010 is out, and when I try entering a relative path by using the "..\" construct, I receive an error message stating "Paths must be absolute"

At least now I have pre and post build events so I can move the project output to where I want them to be.

Edited August 8, 2010 by David Wisti

[jgcode]

Can you post an example explaining how this is done?

You can now download LabVIEW 2010 (see this thread) and try it out (even just to eval for 30 days).

[David Wisti]

I already starting messing around with pre and post builds in 2010. Modifying the destination directory in the pre build means messing with projectitem methods with these tags:

Bld_localDestDir

Destination[0].path

Destination[1].path

There is a VI that NI made to help with this at:

LabVIEW 2010\vi.lib\AppBuilder\GetTargetBuildSpecs.vi

I don't have a working example yet but I'm getting closer.

You can now download LabVIEW 2010 (see this thread) and try it out (even just to eval for 30 days).