Can't find files when building EXE unless the WHOLE codebase is in an auto-populating folder

[Jed_Davidow]

I have a project with FPGA (specifically a couple cRIO targets).

I have a build spec for a PC target, then a target that's set up for Scan Mode, then a couple targets set up for FPGA mode.

When I try and build the FPGA or Scan Mode targets, I NEED to have the entire code folder (and sub-folders) in an auto-populating folder.

What's strange is that I manually added the same folder, and then pulled the Top-level VI out so that it was easier to see within the project.  When I did that, I got errors that files were broken and missing.  I then removed that folder and added the same folder as auto-populating and all is well.

Yes, I was able to make the build work by including debugging, not removing TypeDefs, etc.  This also cause the build to go from 2MB and 30 secodns build time to 50MB + 10 min build time.

Why si this?  I would like to remove the files for other targets from the Source of each of the targets.  If I do this, I can't build (these are other top-level VIs that are not appropriate on a per target basis).

Any ideas?

[Ben-N]

Hi Jed!

Let me make sure I understand what the situation is.  You said that you pulled the Top-level VI out of its original location so that it was easier to see in the project.  Did you actually change the the folder level of the VI?  If so, that makes sense because in most projects, the file path is set relative to the location of the project file, so if you change the location of the project or one of the VI's, the relative path between the files is changed and therefore causes the error you were seeing with broken and missing VIs.  In short, the file wasn't where it expected to be.  By re-adding the folder as autopopulating, the file paths are reset to their new relative file paths and the VIs are no longer broken and missing.

You mentioned that the build time went from about thirty seconds to 10 minutes.  Is that for the FPGA code?  Are you recompiling each time, or what do you mean by that figure?

Also, have you considered moving each of these builds to a separate project and copying the VIs to each project?  You could keep all the projects in one main folder with sub folders and you wouldn't have to worry about modifying the project.

[Jed_Davidow]

Hi Ben,

So here's the layout...

***Top-Level Folder***

    ProjectA.lvproj

    ProjectB.lvproj

    TopLevelA.vi

    TopLevelB.vi

    SubVIs_Folder

        Shared VIs and such used by all projects

Now, within each project, I have multiple targets.  But that doesn't seem to be the trouble.

When I first coded, out of laziness, I just added the TopLevelFolder as an Auto-populating folder to each of my project areas.  This was a little ugly, as ProjectA included projectB.lvproj and TopLevelB.vi in the project list.

So I removed the auto-populate and pulled TopLevelA.vi out of the folder up one level, so that when you open the project you see the TopLevelVI + The non-auto-populated TopLevelFolder.

A) The code works perfectly in Dev mode

B) If I change the options to inlcude debugging, the code works fine, but takes 10m to compile.

C) I reversed this situation and went back to auto-populating, and I got 1m compile and 2MB (vs 10min+48MB).

So what I am trying to say is that ALL I did when I removed the auto-populate was to click "Stop Auto Populate" and moved the Top-level VI up one folder level within the project.  This causes it to fail compile (unless debugging is checked).

[Ben-N]

Hey Jed,

Can you take a screenshot of the project explorer for both of those layouts?  I'm not totally sure that I understand what the layout of the projects are.

Secondly, have you considered having a Top Level Folder that inside has a folder for Project A, Project B, and each of those folders have separate instances of the SubVI folder?  In addition, you could have the SubVI folder at the same level as Project A and Project B.  It just sounds to me like a folder hierarchy issue that you can get around if you put things in different folders.  That may mean you have two copies of the same SubVI's, but i imagine that this weird behavior will go away.

[Jed_Davidow]

Are you suggesting that I have separate actual instances of the SubVIs?  I would rather not do that, as this is a parallel development project (the Top level VIs are just minor variations of each other).

I can try and get you screenshots.  All I am saying is that when the code is added statically I have trouble, but when it's added with Auto-populate I don't.  Same VIs are in the project, same linkages, same code that runs find in Dev mode.

[Ben-N]

Hey Jed,

It sounds like the problem you are having is coming from a file path issue.  When you manually add folders as "Snapshot" the file paths are set and will generate errors if the files are moved.  The autopopulating folder updates file path locations so you don't have those same issues.  Debug mode allows for the file paths to be reassociated, but at the expense of time, and in some cases resources.  Enabling debugging will cause the compilation to take longer.

You wrote:

So what I am trying to say is that ALL I did when I removed the auto-populate was to click "Stop Auto Populate" and moved the Top-level VI up one folder level within the project.  This causes it to fail compile (unless debugging is checked).

This makes complete sense.  By moving ANY VI in a project and not having the folder set to auto-populate or having debugging enabled will cause an error because that VI that you moved isn't where it is supposed to be.  This is the way that projects and the compilation of programs was designed.

To avoid this, don't move files around after they have been added to the project unless you have folders set to autopopulate, or have debug mode enabled.  When you start shuffling file paths, associations get broken and compilations will fail.

[Jed_Davidow]

Ah!  The paths are not relative?  I think you are right- I added the static folders on one machine and then used perforce to move to another and do the build.  Even though the relative paths are the same, if they are using full paths, this would break everything.

I will try again and see if that works.