LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
michael_bradley

Conditional Disable Symbols defined on a per Build Spec Basis, not per Project

Say you have an application that needs to be compiled into multiple different variants, say a internal debug version with extra logging, or a version with customer specific functionality.  You can use the Conditional disables structure to ensure that  only required correct code is compiled into the EXE. By limiting what is compiled into the EXE,  DLL dependencies can be removed, avoiding the need to ship internal only/customer specific DLLs or libraries with every version of the software.

 

Conditional build symbols are currently defined at the Project level in LabVIEW, and apply to all build specifications in that project.  This means that you can't have two separate build specs for the 'standard' and debug/customer specific versions of the software, and instead have to manually change the settings between builds, introducing the possibility for human error, and making it difficult to automate all builds.

 

Any symbol defined in the Conditional Disable Symbols section in the Build spec would replace any symbol with the same name defined at the Project level.  If a symbol wasn't defined at the Build Spec Level, but at the Project Level, the Project one would be used.  When viewing the Conditional symbols for a build spec it would be useful to also show the symbols already defined at the project level, so that it's clear what is different and what is being redefined.

5 Comments
tst
Knight of NI Knight of NI
Knight of NI

This basically seems to be a duplicate of this - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-Disable-Symbols-settable-in-Application-Bu...

 

 


___________________
Try to take over the world!
srdfrn
NI Employee (retired)
Status changed to: Duplicate
marshaul
Member

Pretty sure this could be implemented in about the same amount of time it takes to mark a feature request as a duplicate.

 

Gotta have priorities, though, right? Not like giving customers needed and long-requested functionality should qualify...

AristosQueue (NI)
NI Employee (retired)

> Pretty sure this could be implemented in about the same

> amount of time it takes to mark a feature request as a duplicate.

 

You'd lose that bet. I do not know exactly what makes it so hard, but I know two good programmers have tried and given up. It has something to do with various parts of the code making assumptions about whether a given VI is compiled in as a dependency or not and when they can use cached information.

 

LV NXG is being built with conditional symbols in from the first draft instead of coming on late as happened in LabVIEW 20xx.

wiebe@CARYA
Knight of NI

>You'd lose that bet. I do not know exactly what makes it so hard, but I know two good programmers have tried and given up.

 

That is puzzling.

 

I made this myself in a pre-build VI. Tedious, as we're only granted one pre-build VI in 13 (where an array would be appropriate, 0-n VIs please, not 0-1). All it needs is entries in the build spec., in stead of hard coded in the pre-build VIs.

 

The 2nd downside is that the pre-build action actually changes the project conditions, not saving before and\or saving after a build might ruin SCC. Avoiding this would require the build to work on a temporary copy of the project, or a revert after the build. Changing the conditions back doesn't work. If the build does already work on a copy, it's done after executing the pre-build VI...

 

It's weird that DIY gets me 90% there, and NI can't get it to 100% (or the acceptable 99% Smiley Wink). But I've made some software myself, it does happen... When it does, it tends to be hard to explain the 'why'.

 

I wander if I can get around the changing project issue. I haven't tried, as I didn't need it badly enough...

 

I assume adding a 'build-in' pre-build action and adding the entries to the dialog isn't the problem? (You mentioned you don't know the reason, but someone must know)