Build Specifications: Programmatically Adjusting "Source File Settings" For Each VI

[vekkuli]

I posted on lavag.org about this as well: http://lavag.org/topic/10643-programmatically-modifying-buildspec/ (last reply).

I wish to modify the "Source File Settings" of a build specification—or alternatively create an entirely new build specification—according to, namely, this http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/compiler_optimizing_for_execution_speed/ , and mainly the part where you'd go through every source file and uncheck "Use VI Property" and "Allow Debugging".

I took a look on how changing the settings in the Build Properties interface affects the Project XML file, and the markup appeared to like this:

<Property Name="Source[5].itemID" Type="Ref">/My Computer/.../VI.vi</Property>
<Property Name="Source[5].properties[0].type" Type="Str">Allow debugging</Property>
<Property Name="Source[5].properties[0].value" Type="Bool">false</Property>
<Property Name="Source[5].propertiesCount" Type="Int">1</Property>

So, I decided to give it a try to just get a list of all the VI's and tag the same for each—admittedly I had no idea whatsoever what I was doing. Here's the script:

The first source file index is hardcoded simply based on the two source tags that were already there (I don't even know what they really are). After running and saving the project file, looking at the XML file it looks like it should do the job, however, when I open the properties again the source file settings for each file have become grayed out (what's that all about anyway?), so how can I confirm it?

I'm not familiar with scripting like this and I find the way that I had to create the tags a little too arbitrary and out of control for my taste. Where could I learn more about this topic? How have you guys taken care of scripting like this?

[vekkuli]

... and I just discovered I can put all my source files into a Virtual Folder in the project (earlier I simply had them in Libraries under the root) and check "Set VI properties for all contained items" on the Virtual Folder to apply the changes to every VI. Good to know!

Suppose we're still interested in the programmatic method...

[ValkoA]

Dear vekkuli,

I think you are on the right track for programmatic tag modification, but in such a case the code is a bit more complicated. For each project source item, a list of property tag pairs exists. There is Source[x].properties[y].type to determine what is modified and Source[x].properties[y].value is the value being set for this property. Let me give you an example of how I'd set debugging off for all items:

1. Find out how many source items are there by Reading the SourceCount tag.
2. Get the Source[x].type tag for every source item. If it is a "VI", we modify it, otherwise it is ignored.
3. Check the existing property types with the Source[x].properties[y].type tag of the remaining sources. If the property "Allow debugging" already exists, we should not duplicate it.
4. If the property exists, set the  Source[x].properties[y].value to false (or whatever else we want to)
5. If it does not exist, we have to create it. If source x has y properties already, we have to set Source[x].properties[y+1].type tag to "Allow debugging" and  Source[x].properties[y+1].value tag to false.

What do you think about this approach?

Kind regards:

[vekkuli]

Yes, I see how it would be more robust that way. Thank you! Although I do think there's an issue following the SourceCount tag because as far as I know it only refers to the number of Sources that already have tags marked to it. By default none of the VI's really have any so even if there are 600 VI's in the project the SourceCount would be something like 2 in a fresh build specification. Did you try it out?

Also, do you have any clue why it would gray out the corresponding source parameters in the build properties if I make programmatic modifications to the tags? Is it actually a sign that the properties are invalid/corrupt?

[ValkoA]

Dear vekkuli,

You are indeed correct that on the Source, not all source files are listed there, just the ones you specify as Startup or Always Included in the build, plus dependencies. Altogether, there are a couple of scenarios.

1. It is possible that some items are not in the project, only in the dependencies. Dependencies are always Source [0].
2. It is possible some items are in a virtual folder or other container. In these cases, only the container is it the sources list, not the items themselves.
3. It is possible to have standalone VIs and Controls.

The previous advice can be used the same way for containers and dependencies, the only hing you need to add/check is the Source[x].Container.applyProperties tag. It is a boolean value that corresponds to the "set VI properties or all container items" selection in the Build properties window.

I'll try to create some example code later.

Regards:

[christian_w]

For a source folder (container) these tags are required

                <Property Name="Source[13].itemID" Type="Ref">/DTRTOS-MXIe-LX50-1/Algorithms</Property>
                <Property Name="Source[13].properties[0].type" Type="Str">Allow debugging</Property>
                <Property Name="Source[13].properties[0].value" Type="Bool">false</Property>
                <Property Name="Source[13].propertiesCount" Type="Int">1</Property>
                <Property Name="Source[13].type" Type="Str">Container</Property>
                <Property Name="Source[14].Container.applyProperties" Type="Bool">true</Property>
                <Property Name="Source[14].Container.depDestIndex" Type="Int">0</Property>

To get the itemID reference I used

the others coded like described before

Since I have 6+ RT targets in my project this saves a lot of time and is the safest way to keep the RT build specs synchronized in terms of disabled debug options for all items.