LabVIEW Idea Exchange

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

Support "Development Environments" / "Development Sand Boxes"

Status: New

Similar ideas have already been posted but non of them totally hits what I'm missing.

 

As always - what is the current situation?:
- LabVIEW is installed under "C:\Program Files (x86)\..." - this is a folder where admin rights are usually required to modify it.

- in the named folder the standard VIs are included: vi.lib / user.lib / instr.lib

- my project lays somewhere else - e.g. "C:\myLVProjects\project1", "C:\myLVProjects\project2", ...

- my first project is LabVIEW32 bit, my second is LV64bit,
- one project needs to have the binary code separated from the VI, the other one not
- one projects needs some toolkits from the VI Package manager, the other one not or maybe even incompatible ones to the first project

- one project needs VIs from an additional search path, the other one too but with a different version


long story short:
There are many situations where the configurations of two or more projects conflict with each other. Therefore, switching between two projects can be quite effortful — from adjusting configurations to (de)installing toolkits.

What I like to propose is the following:
Having a new option in the LabVIEW start screen "Create a new development environment".
The only the user has to do is to select a folder on a drive with enough free space.
LabVIEW shall now setup an entire code- and configuration environment. Means it copies vi.lib, user.lib, instruments.lib to this folder. It create a LabVIEW.ini and a link to the exe using this INI. It creates a folder for the compiled object code cache and so on. Installing add-ons from VI package manager shall also be stored in this new folder structure.
And of course, there shall be a place where I can manually add some libraries, my project files and finally also my build results.
If LabVIEW is now started from the named link it only uses the VIs from the environment folder as long relative paths are used (which shall be default).

Again in short:
I expect an encapsulated environment that contains everything that is needed to develop one project entirely independent from a second and third project.

 

12 Comments
crossrulz
Knight of NI

My current assessment between VIPM and NIPM:

VIPM is great for per LabVIEW version install.

NIPM is great for system install.

 

For this reason, I found NIPM packages are a lot better for installing to LVAddons. This is not to say that JKI could update VIPM to fix this. I think I heard chatter of JKI trying to figure this out. But NIPM has a lot of flaws that really need fixed, many I would like to help the LabVIEW Open Source Initiative (*cough*revert installed package*cough*).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
GregR
Active Participant

We are aware of the difficulties and agree we need to make the process smoother.