LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
gksloane

Add Option to Make Destination Path in Application Builder a Symbolic Path (relative to the Project directory)

Status: New

I'd like to see the Destination Path in the application builder have an option to be a symbolic path based on the project directory (the direcotry where the project file lives) rather than an absolute path. For instance, if the project path (in our case, a local Git repo) was "SS10 Src Repo" and there was a subdirectory called "Builds", it would be nice to NOT have to specify "C:\users\xxx\Desktop\SS10 Src Repo\Builds" as the destination path, but rather check a box to say "symbolic path relative to Project Dir" and simply specify "Builds". If the repo is moved or renamed, all those destination paths in each project file need to be edited.

 

One reason for doing this is to locate executable that are built from the project, and called from project files via System Exec.vi. At runtime you need to find the executables (assuming they are localized and not in the PATH) and  you can use the Application Directory file constant to figure out where your executables SHOULD be (relative to  AppDir). But configuration to specify their location in each project file using an absolute path is a b**ch...  it would be great to not have to edit all the dest paths in each .lvproj each time we check out the repo on a new machine, or by a different user...

4 Comments
wiebe@CARYA
Knight of NI

That's called a relative path, and it's a relative path by default.

 

IIRC, The problem is that once it's changed to not relative, it will never become relative again.

 

More details (and duplicate ideas, AFAIC) here:

Relative Path support for App Builder Destination Directory

Application build destination directory should not require absolute paths

gksloane
Member

OK, I failed to make my point.

 

ISSUE ONE

 I didn't make the (correct) points in my original post.

 

I have a LV Project (call it TL, "top level") that has a Builds directory inside it. When I use app builder the .exe goes into that directory. Underneath TL (inside the project directory) I have sub-projects - directories that contain VIs that are included in the TL build; but they ALSO contain local project files that can build what we call "standalone" versions of the local directory's VIs.

 

To clarify; this is an ATE system. I can build the entire system (TL) or I can build a standalone executable for just one test (the subprojects). The issue is that the destination directory for the TL and subprojects needs to be the same... 

 

When I relocate the TL the top-level project destination path in fact DOES get updated to be 'relative to the project'. But... the subproject destination paths do NOT - because the destination directory is within the TL project, as is the subproject, but the destination directory of the subproject is NOT within it's project directory, but rather is within the TL project above it.

 

If I could set a checkbox to specify that a destination path was relative, *and* set what specifically it is relative to (the TL project dir, NOT the sub-project dir) I'd be a happy camper.

 

ISSUE TWO

The current implementation (I'm using LV2015 btw) obscures what is really happening:

  •  the UI doesn't accept a relative pathname (despite the fact that the path might be relative)
  • The UI displays only a fully qualified pathname (despite the fact the the path might be relative)
  • The project file contains a fully qualified pathname (despite the fact that the path might be relative.

The current implementation (again, LV2015...)

  • doesn't allow specifying absolute vs relative behavior
  • doesn't allow specifying what directory relative behavior should be relative to (the 'anchor' directory)
  • doesn't indicate (in its current form) whether LV is automagically adjusting the (relative) path or not
  • there is no concept of hierarchical projects, so you cannot 'grandfather' the anchor directory from a project above

I'd like to see this fixed...

wiebe@CARYA
Knight of NI

I agree this doesn't work well as it is.

 

It needs work.

 

I'll kudo the idea just to get NI's attention.

IlluminatedG
Active Participant

Might be relevant: https://www.vipm.io/package/illuminatedg_lib_ig_relative_build_paths/

~ Helping pave the path to long-term living and thriving in space. ~