Application build destination directory should not require absolute paths

[MGiacomet]

It makes no sense (from a Software Engineering and Process standpoint) to force (and store) an absolute path for a build destination directory, in the project. What if a group is sharing a project but each developer prefers to have their files located in a different folder?!!

I recommend NI consider replacing the line of code in LabView that is checking for the presence of an absolute path for the build folder with on that does: "If user entered an absolute path, use it; otherwise, prepend the current project location to whatever (relative) path the user entered before building."

[wiebe@CARYA]

@DerrickB:

I'm on your side. I mend that it wouldn't be hard for NI to support this.

In other words: it should be fixed. Relative paths turning absolute, and no decent way back... Not sure how this isn't a bug? 

[DerrickB]

[Redacted]

Anyone have any sources for docs on the parameters and options for Bld_* entries in the lvproj file?

[DerrickB]

Alright so I just went into the project file, changed to relative paths, built the PPL, and the lvproj file reverted to absolute paths.

There isn't even a manual workaround to this project that doesn't involve editing the lvproj file every time I clone the source.

[DerrickB]

My efforts to try and fool the system. Going into the build spec in a project after making lvproj edits and clicking OK ALWAYS results in the lvproj reverting to absolute paths.

Before edits:

Editing spec in project to find a working relative path: (max one level ascension)

Manually editing lvproj for desired values:

Desired resolved path displayed in build spec:

Click OK, save project, lvproj reverts to absolute paths:

Attempt #2 with more types specified and using NI_AB_PROJECTNAME variable, still gets reverted by project

[DerrickB]

For anyone following along, I just found out there is finally a bug filed for this as of the beginning of this year (is there someone that can update the status of this feature request?) and R&D is looking into it according to NI support.

[Guangchao]

@DerrickB,

Thanks for your help, I'm a developer new to AppBuilder. Could you tell me where you find the bug? 

Is below the behavior you expect?

1. If the location of a project is C:\foo\, then default destination directory of a new build spec should be C:\foo\builds but not C:\builds.

2. I can set either an absolute path or a relative path to the destination directory.

    2.1 If I set an absolute path in same driver, say "C:\goo\builds", a relative path should be remembered.

    2.2 If I set an absolute path in different driver, say "D:\goo\builds", the absolute path should be remembered.

    2.3 If I set a relative path, say "goo\builds\", I mean C:\foo\goo\builds.

    2.4 If I set a relative path, say "goo\builds\", the UI should automatically update to "C:\foo\goo\builds" but internally remember it as relative path.

[DerrickB]

If you'll look at my posts you'll see that the issue is when trying to get to paths that in relative form would start with "../../". I'm trying to go UP two levels. I know the default path is different; I'm not trying to use the default path. I'm building PPLs from many different components and source paths and trying to collect them all to a central location which has to be done at build time for namespacing and pathing issues.

Demonstrated by two posts preceding yours, I can even manually specify "../../" for the build spec in the project files and LabVIEW still reverts to an absolute path.

[MauraW]

Application Builder using absolute paths instead of relative ones is currently being investigated by R&D in corrective action report 681975. 

There are a couple of workarounds for the time being. You can save the builds outside the parent folder of your project. You can continue editing the XML in the project file. Or you can reconfigure your integration process so the parent folder is not renamed.

[wiebe@CARYA]

>You can save the builds outside the parent folder of your project.

That's not a workaround, that's the problem. It won't work on another PC if the project uses another absolute path. So 2 people working with SCC will fight on the paths, the last commit will win...

>Or you can reconfigure your integration process so the parent folder is not renamed

Not sure about this one. I want to check out my project, without having to worry about where I put it. The build path should be relative to where I put it. And two persons working on the project should not have to worry about the absolute path.

[DerrickB]

Maura:

Saving builds outside of my project root? As in a new project with the build spec in a separate folder that doesn't contain the source? Or the build output being outside the project folder but the build spec is in my main project?

Even forcing each build environment to be identical is impossible when I'm given a provisioned server for a build environment that has a 😧 drive for working data and my dev VM only has it's main drive, C.