Ideas on how to avoid filepath length issues in exes from the start of the project

[cgiustini]

Hi,

 

Lately, I have been experiencing a pretty annoying problem involving exes and file layouts. I built an exe for a project that was calling code that was maintained in a totally different project. The exe I was creating for this project built correctly, but it would never start up correctly in the path where it was built: it would report that it could not find some of the files that made up the external code to my project (Generic File I/O error). It turns that this problem stems from the fact that the filepaths for these files was too large (http://lavag.org/topic/11698-filename-too-long-in-build/). I ended up solving this problem by changing my build directory to somewhere where all filepaths ended up being short enough, but I ended up violating the rules my group had laid out for how we structure our repository. 

 

Anyways, I know that other people have run into this problem, and that they found various solutions once they started encountering the problem. Examples of solutions are shortening paths (which was not possible in my case because modifying the layout of external code would have caused a lot of problems), building with the "8.x filepath layout" option, or changing the build directory. In some ways, these are all workarounds and not actual solutions. What I was wondering is if anyone has any ideas/recipes (project layout architecture for instance) that helps totally avoid this problem from the start of the project, not the end. 

 

Carlo

 

 

 

 

[Neil Pate]

I build to a temporary directory (like c:\t) if I run into these kind of problems. It is a pain...

[LogMAN]

...Anyways, I know that other people have run into this problem, and that they found various solutions once they started encountering the problem. Examples of solutions are shortening paths (which was not possible in my case because modifying the layout of external code would have caused a lot of problems), building with the "8.x filepath layout" option, or changing the build directory. In some ways, these are all workarounds and not actual solutions...

This is exactly the point. You can find a way to solve the immediate issue, however the initial problem remains.

 

...I ended up solving this problem by changing my build directory to somewhere where all filepaths ended up being short enough, but I ended up violating the rules my group had laid out for how we structure our repository. ...

When you talk about 'repository' do you mean a repository as in SCC? If that's the case, how can a change on your local checkout violate anything in the repository? If that's not the case your file/folder structure now has a known issue

 

...What I was wondering is if anyone has any ideas/recipes (project layout architecture for instance) that helps totally avoid this problem from the start of the project, not the end. 

 

Carlo

There are many ways to solve that problem. First of all, the issue is related to long path names, so you want to have a short absolute path to your project and short relative path in your project directory.

I have a local directory on a secondary HD 'B:\projects' which is the root path for all of my projects. I checkout my projects from SVN, but only a a specific branch, or the trunk (else the hierarchy is to extensive). So one project could have the absolute path 'B:\Projects\MyProject'. Short enough.

Next we need a clean project structure to minimize file paths. In my case that would be:

..\Builds <- not under SCC

..\Documentation

..\Examples

..\Resources

..\Sources

..\<project>.lvproj

All VIs, classes, etc... are placed within the Sources directory (either the sources are in the 'Sources' directory, or somewhere in the LabVIEW installation folder). So let me count characters and I got 'B:\projects\MyProject\Sources\' => 30 plus, minus the length of my project name.

Now since I follow this layout, there have been no more problems with path length. However this requires that any files which are placed under 'Sources' are named properly (don't try to tell a story in the file name!). Also there is a rule of having at most two more directory levels (which is fine, since the project is fully capable of organizing sources using virtual folders). As example: All files related to a class are placed into a single folder, thus even with long file names it is not likely to hit the 256 character limit.

[hooovahh]

 

But seriously when I had this issue, the easiest solution was to checkout the project to the shortest path I could.  Since then I check out my code to C:\SVN\Project Name.  VIPM also had issues in the past because it would build packages in a directory along side the source but I think they now build in a temp folder for this reason.

 

EDIT:  Oh and as for builds we do put the EXE in source code control but not the installers.  The reason for this is because if I build a LabVIEW EXE, then build it again with the same source code, the EXE's won't be the same bit for bit.  They may function the same but there is no way to know for sure that the 1.0 EXE is the same functionality as another 1.0 EXE.  So if we needed to make a new 1.0 EXE by rolling the source back, then rebuilding we wouldn't know it is the same as the 1.0 made previously.  I don't really like that some builds are in source but it makes life much easier when I need to roll back and try a previous EXE.