build fails: Rebuild ALL succeeds

[Rudi_N]

Al:

Thank you very much for your patience and understanding. I have filed a Corrective Action Request (96253) and have brought this issue to our R&D team. However, I do not know when I will have something to report back to you. Please let me know if there is anything else I can do to keep you going in the meantime.

Have a great weekend !!!

Regards,

Rudi N.

Message Edited by Rudi N on 03-07-2008 05:50 PM

[Macbeth]

Thanks Rudi, Let me know if you need the code posted up again.
I'm actually starting to get an occasional linking error when using 'Rebuild ALL' as well. Same msg...pointing,I believe, to globals.
The project is growing,  with callbacks now included as well as more VIs. And it's not complete yet.
Any way that could save time is welcome.
I'm starting to get shy about making changes as it takes soooo looong to find out if it works.
Thanks again,
~Al

[Rudi_N]

Al:

I hope all is well. I ran your code a few times and did not run any issues with the 'Rebuild All' option. Please let me know what type of issues you are running into. I will be more than glad to help you out.

Regards,

Rudi N.

[Tariah]

Hi Rudi,
The problem is that "Rebuild ALL " has to be used every time a change is made . Why doesn't 'Build' work???

We have noticed a possible tip that may point in the same direction. When we make a change to one of the global default values and save the global VI, the 'Build' selection will not recognize that a change has been made. A message is displayed that the build is up to date and it is clearly not. It's as if the globals are not being referenced properly. 'Rebuild All' just goes ahead and recompiles everything regardless of any changes made or not. However, having to use this process is very time consuming and potentially hinders a project. If I make a minor change to ONE VI, I only want to recompile THAT particular VI and not the entire project. I'm becoming very gun shy towards making any changes; We need  to use a water-cooled octal-core PC to work this stuff.


Message Edited by Tariah on 03-14-2008 08:21 PM

[Rudi_N]

Al:

I hope all is well. I played around with your application over the past few days and I have a suggestion for you: when doing the build, try to leave the top level VI open the whole entire time. Do not close it from one build to the next one. Please try this if you haven't already and let me know what you find.

Regards,

Rudi N.

[Macbeth]

Thanks for looking into this, Rudi.
I gave it a couple of trys with the top level VI left open; though my project is now up to 100 VIs and is more complex than the copy you have.
Still no luck.The 'Build' option still fails with an error" symbols referenced in processor 'p0' could not be resolved." 
Using 'Rebuild All' works every time, taking its sweet time, of course.
So the compiling is OK and the Linking is OK when directed to compile/link every file...so there must be something fishy with the linker's command switches when using the Build option???



Message Edited by Macbeth on 03-26-2008 02:34 PM

[jmburns]

Try leaving the "Globals.vi" open during your build in addition to the top level vi.  This seems to work for me.

[Rudi_N]

Al:

I hope all is well with you. Please let us know if you are still running into these issues.

Regards,

Rudi N.

[Macbeth]

Hi Rudi,
The project has now been finalized for its first release and the problem is still unsolved. I've done a much smaller project in the mean time and as soon as I incorporate a few globals to store some parametersi get that linker error. So I try to avoid doing that. Some globals work,some don't. Haven't had time to really investigate.
Leaving the top-level VI open doesn't help nor does leaving the globals VI open. Compiling is always successful so it must be the information that is passed to the linker that's at fault, correct?
Wouldn't this be a Visual DSP problem???
Thanks for your efforts on this
~Al



Message Edited by Macbeth on 04-08-2008 08:29 AM

[Michael.Phillips]

Hi Al,

I can offer some insight on the root cause of the problem. Basically, we are not detecting that some VIs are actually unchanged when we generate C code from them. So then we regenerate C despite the fact that a VI is unchanged and then we have to recompile the C file every time. This issue will be fixed in a future release. If and when I find a solid workaround (which would probably consist of leaving some file open throughout the build/rebuild process), I'll let you know.


Message Edited by Michael P on 04-08-2008 10:43 AM