Handling reusable libraries, source control, and multiple developers path conflicts

[Mikejj]

Hi All,

Need some ideas how to handle reusable libraries for our projects when working with different developers.

A typical scenario goes like this:

• We have Project A
  • This is in a folder called c:\LV\projects
• Project A relies on 2 different reusable libraries x.lvlib and y.lvlibp
  
  • The libraries are placed in folder called c:\LV\tools\
• All 3 items above have their own git repo
  • Except the y.lvlibp only has the source code, not the actual compiled lvlibp files

Now another developer comes and clones the Project A and x.lvlib repos into their computers. They put Project A in c:\projects. They get the built library y files from a cloud storage service (let's say dropbox or google drive) and put x and y into c:\libraries. Launch the Project A and the project immediate looks for the two missing libraries and can't find them.

I believe if you do this the files within the Project A folders will all update their path ok (relative pathing I believe), but all the path to the library dependencies will break and you will have to search for them. This creates further headaches if someone commits the lvproj files, now you have a fight in the lvproj file between develops on who's tools path is right.

Some help needed with this situation are:

1. How to manage the fact that the folder structure/location might be different on different develops computer?
   
   1. Just enforce a rule to always put the files in the same location, ie: Project goes in c:\projects and libraries go in c:\tools no matter what computer you are on. This seems very clunky to me as a solution
   2. Copy all the dependencies libraries into the Project folder. This creates a hassle if the libraries are updated, then I have to sync them to the latest locally, move them into the project folders, then sync the project with the repo.
2. Is there a better way to distribute reusable PPL lvlibps than what we are doing now by just putting in some cloud drive?

Many thanks in advance and hope to hear back some great ideas.

Regards,

Mike

[billko]

---

@Mikejj wrote:

Hi All,

Need some ideas how to handle reusable libraries for our projects when working with different developers.

A typical scenario goes like this:

• We have Project A
  • This is in a folder called c:\LV\projects
• Project A relies on 2 different reusable libraries x.lvlib and y.lvlibp
  
  • The libraries are placed in folder called c:\LV\tools\
• All 3 items above have their own git repo
  • Except the y.lvlibp only has the source code, not the actual compiled lvlibp files

Now another developer comes and clones the Project A and x.lvlib repos into their computers. They put Project A in c:\projects. They get the built library y files from a cloud storage service (let's say dropbox or google drive) and put x and y into c:\libraries. Launch the Project A and the project immediate looks for the two missing libraries and can't find them.

I believe if you do this the files within the Project A folders will all update their path ok (relative pathing I believe), but all the path to the library dependencies will break and you will have to search for them. This creates further headaches if someone commits the lvproj files, now you have a fight in the lvproj file between develops on who's tools path is right.

Some help needed with this situation are:

1. How to manage the fact that the folder structure/location might be different on different develops computer?
   
   1. Just enforce a rule to always put the files in the same location, ie: Project goes in c:\projects and libraries go in c:\tools no matter what computer you are on. This seems very clunky to me as a solution
   2. Copy all the dependencies libraries into the Project folder. This creates a hassle if the libraries are updated, then I have to sync them to the latest locally, move them into the project folders, then sync the project with the repo.
2. Is there a better way to distribute reusable PPL lvlibps than what we are doing now by just putting in some cloud drive?

Many thanks in advance and hope to hear back some great ideas.

Regards,

Mike

---

Option "a" is the correct option.  If they are, in fact, working on the same project, they should be structuring it identically.  No ands, if, or buts about it.  If the components come from different repos, then you might even have a document describing where everything goes.  It's all about teamwork.  In order to function smoothly as a team, certain aspects of individuality must be sacrificed.  The freedom to put things where you choose in a project worked on by a team is one of those sacrifices.  Can you imagine working in a machine shop where everyone put the tools away in a different location instead of having a place (the tool crib) where everyone can expect to find them?

For question number 2, I think having them on a network drive is fine.  Just keep doing what you are doing, keeping the distributions on a drive, and keeping the source somewhere else.

[Mikejj]

Thanks for the insight.

For question 1, I was originally looking into JKI VIPM Pro to install the dependencies. But just enforcing a set of rules seems to be a really simple solution to it all. I originally wanted as much flexibility as possible for other developers, but after seeing all the dependency conflicts and headache, it doesn't seem to be worth it.

[Jay14159265]

You can use git to manage a Labivew code base, its not perfect but it's workable. Labview has some diff and merge tools that make it possible. 

https://www.ni.com/en-us/innovations/videos/18/merging-and-comparing-labview-code-with-git-or-hg.htm...

Also you can make a VI in your project that puts all the files in the correct location, like an installer. Then tell people to run that VI when they pull the repo. 

[Mikejj]

Hi Jay,

I am already using git and have it configured with lvcompare and lvmerge and they are working...mostly, LVmerge is especially wonky at times and will often break my VI on merge so I try to avoid having to work on the same vi as much as possible.

For you recommendation to create a VI to move files, do you have a template or example that I can get started from?

Thanks,

Mike

[Jay14159265]

Yes, the merge tool for labview can be pretty terrible if you make lots of changes to the same VI. I wish NI would spend the time to make that better so you could ignore changes that don't require a re-compile. 

For the VI that moves files I do not have a template for that, it is only an idea based on what I do when I make installers. On further thought maybe the better idea would be to make a path manager VI that sets the paths for all the required external libraries. When someone pulls the repo have them run that vi which will require them to point to the  location of the .lvlib on their computer. Then the path manager VI would set the paths in the code so that it can find the required libraries. Save the paths to an ini file and don't track the ini file in the repo that way each user will only have to do it once. Also include a readme in the repos about where the lvlib should reside on the computer so something like "Always put the awesomeLib.lvlib in this path:  C/repo/awesomeLib.lvlib" (or wherever it needs to go).