LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW NXG 4.0 GLL - How to use them?

Solved!
Go to solution
Highlighted

I saw NXG 4.0 supports building libraries into GLLs so gave it a quick shot, but I can't find any info about using the GLLs in any useful way. I can build them...but that's about it.

 

  • There is no way (I could find) to build a standalone GLL. They are only built when an application is built.
  • Conversely, there's no way NOT to build a library into a GLL when building an application. If I use libraries to organise my code, they will be compiled into GLLs. This creates a bit of a mess on disk (each GLL gets it's own top level folder, containing a single GLL). Can libraries not be statically built and included in the executable?
  • A compiled GLL can not be replaced with an updated build version, or even an identical recompiled version. The calling application will throw an error (-4503) when it's loading the GLL. So although it's being dynamically loaded, it has to be the exact file compiled with the application. This kinda defeats the primary use case for dynamic loading.
    • gll_fail.png
  • I can't find any way of calling code in a pre-existing GLL. GLLs don't seem to be supported in the NXG project.
    • gll_file_type.png
  • If I have a project with two applications referencing the same library, then build each application, they don't share a single GLL. Instead they get their own built versions of the GLL. If I move the GLLs on disk, maintaining the necessary relative paths, the GLL can't be shared due to error -4503 above.

 

Is there any way to use a GLL, beyond being a bit of extra compiler output?




Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
0 Kudos
Message 1 of 4
(310 Views)
Solution
Accepted by topic author MichaelBalzer

Hello Michael,

Thanks for the feedback! You are correct in your analysis of the situation. In the LabVIEW NXG 4.0 release, the GLLs don't do too much. I wanted to share our reasoning for this, and give you a heads up to some things that are coming down the pipeline.

We wanted to get people comfortable with the concept of how we build components, and how these built components (i.e. GLLs) compose the binary output of your applications. Components are the main organizational tool in LabVIEW NXG, and having desktop libraries compile into GLLs is a continuation of that theme.

There are still "source components," just not as a build option. You can always take a .gcomp directory and give that to somebody else or use it in a separate project. But for the notion of what happens on build on the desktop, right now we will always build these into GLLs. We do have on our long-term backlog an option for creating a monolithic EXE, but we will not get to that any time in the near future. The capabilities that GLL will soon provide were higher on the list of requirements for the customers we have spoken to than monolithic EXEs.

On the subject of those GLL capabilities, the team is currently hard at work on patching individual GLLs (and thus being able to build GLLs individually) as well as the ability to load a GLL dynamically from your built app. 

I am excited to see these features get out the door. Our general approach has been to get smaller increments of functionality out the door more often, so stay tuned for the next LabVIEW NXG release!

Thanks,

Taylor

Message 2 of 4
(170 Views)

Thanks for the detailed response, Taylor. I was hoping for a PPL / LVLIBP replacement when I saw GLLs were included in NXG 4.0, and it sounds like they will be in a future release.

 

A monolithic exe isn't high on my requirements list either, but would be a nice to have. A key feature I'd like to see (and I'm sure many others) for GLLs would be around plugin architectures. Not just the ability to create them, but a much simpler workflow for code creation. Right now with PPLs and LVLIBPs, it means juggling several projects in and out of memory so libraries don't get locked, or have build errors. Multiple projects also exacerbates any code refactoring amongst PPLs and their dependencies. If and when this can all be done from a single project in NXG, I'll happily switch!




Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
0 Kudos
Message 3 of 4
(130 Views)

So you'll be glad to know that we have drastically simplified the workflows around creating GLLs and using them as plugins. No more separate projects for each PPL. As we get close to releasing this, I'll be able to share more details on the specifics of the workflows, but I hope that you will be pleased!

Message 4 of 4
(61 Views)