+8
Wird überprüft

Allow libraries as build source (instead of folders)

Ton Plomp vor 13 Jahren aktualisiert von Michael Aivaliotis (VIPM Product Manager) vor 10 Jahren 7

Sometimes my source for folder has old (or not yet finalized) VIs that I don't want to distribute, in my project I remove these VIs from the library/class, but since VIPM picks a whole folder as the build-source these VIs show up in the package. 

By selecting library or class as the build source these functions wouldn't be included.

Antwort

Angehefted
So can we agree that instead of an LVLIB it would be preferable to use an LVPROJ file as the source? I'm thinking this makes more sense. You can always put an LVLIB inside of an LVPROJ, which you should be doing anyway.
In VIPM. You can remove (exclude) VIs from the package build process. Is this not a workable option? And if not, why?

Hi Michael,


That would require me for every build to tidy up something I'm not really interested in:

The source folder. By using the project (and libraries) I have a single place to manage the code I want to release.


One option would be to create a NI-source distribution that targets a folder that is used by VIPM, that would be an easier work-around than manually exclude VIs and files in VIPM.


Ton

For VIPM 2010+ OpenG's folder hierarchy puts Candidates outside the source folder for this reason. Then they can easily be moved and re-linked when ready to go - its probably boring to most people but we spent a fair bit of time working this out to keep the best results. It goes <project>\source\library - these are the distributed VIs; and <project>\candidates. This was quite a change from using VIPM 3.0 (for me).
Jonathan. So are you recommending this as a workaround? What's your opinion on the using the library as the source?
+1
@Michael - OpenG does not make use of LabVIEW Project Libraries (but may do in the future?) I can see issues with calling private members and accessing Class data for candidates - so in these cases they would have to be part of the Library and the current VIPM exclude feature is probably best to use there, but I will have to play more with them.  

...and I would like to see the LabVIEW project definition parsed and used as to populate the Source File Settings of a new VIP in the builder. This would save me from having to find all the VIs on disk that are not a part of the distribution and having to manually exclude them.

Angehefted
So can we agree that instead of an LVLIB it would be preferable to use an LVPROJ file as the source? I'm thinking this makes more sense. You can always put an LVLIB inside of an LVPROJ, which you should be doing anyway.