Known Issue with Parallel Project Builds?

[swegner]

Hi,

I maintain a Visual Studio solution consisting of ~40 interrelated C and Fortran projects. I have trouble building the complete solution in Visual Studio, unless the maximum "parallel project builds" is capped at 1. Is this a known issue in Intel Visual Fortran? I can build the same solution file with parallel builds if I disable all Fortran projects.

It's also very likely that I may have some conflicting setting files in our projects. We're using Visual Studio 2005 (SP1) with Intel Visual Fortran 9.1, although the project files have gone through many automatic conversions from previous versions of Visual Studio / Compaq Visual Fortran. I'm fairly sure that project dependencies have been setup correctly in the solution file, and intermediate/output directories for different projects are completely separate.

The only other possible cause I could imagine is that some projects share source files. Specifically, for each executable/library, we build 2 versions that are identical except for their name and run-time library (DLL or static). However, even for these projects, the output files should be completely disjoint.

Has anyone else had this problem? Is there an easy fix? This isn't a major problem for us, but it would be nice to be able to take advantage of parallel builds in our large project.

[Steven_L_Intel1]

You don't say what the problem is. Please elaborate.

[Jugoslav_Dujic]

We had a recent thread here, describing a problem that resembles yours, tracked to VS dependency analyser. Maybe you can contact the original poster, or Microsoft, to get a clarification? [Of course, it might be something else entirely].

[swegner]

Hi,

Sorry for the late reply. It's very hard to narrow down where the issue is coming from exactly. I can say that when building my (fairly large) C/Fortran Visual Studio 2005 solution using Visual Studio's "parallel builds", I almost always crash at one point or another. Removing the Fortran projects or setting the maximum parallel builds to "1" eliminates the problem. Let me describe my projects a little further:

We have a single Visual Studio 2005 solution file with about 40 projects, about 30 C and 10 Fortran. In general, the Fortran projects depend on the C projects, but this isn't always the case. About 5 of the projects are "initialization" projects, which build binaries and then contain a custom post-build step to run them and dynamically generate source code. Later projects use this code, and thus depend on the project.

Our projects build about 5 different libraries and 15 executables. Just about every project has a "static" and "dynamic" version-- DLL versions of the libraries, and executables that use the multithreaded DLL runtime. Also, these project files have been upgraded and adapted version-by-version since Visual Studio 6.0 and CVF-- some are even older.

I'm fairly certain the project dependencies are set up correctly, but the crashes seem to have to do when a build starts before a dependent project has completed. It may be the case that projects are waiting for the dependents to have *started*, but not neccessarily *finished*. It's hard to track down exactly where the problem is, so I'll describe the crashes I experience in an example build:

1) The first crash happens in the initialization projects. A Fortran project is set to run its generated executable as a post-build step, which generates a C header file for a subsequent C initialization project. The C project starts before the Fortran project finishes (although it depends on the Fortran project), and thus cannot find the header file. This results in a simple compiler error.

2) Trying to restart the build after this error crashes Visual Studio right away. Any attempts to restart Visual Studio and try again keep crashing it. It appears that something must be corrupted in the workspace. So, I create a new, fresh workspace.

3) I build the initialization projects one-by-one to avoid the same errors. However, when later selecting "Build All", it crashes again. It appears that the static and DLL version of the same C library project are trying to build at the same time and crashing-- perhaps one is locking a source file needed by the other?

4) I restart and compile those two libraries by hand, and then "Build All" again. It runs for a while and compiles about 10 projects-- even some Fortran projects this time. Then, it finishes a Fortran library, and crashes again, hard to say what the cause was. Restarting and trying again crashes Visual Studio. Setting the number of parallel builds down to "1" and building triggers a new error message. It looks like the workspace is corrupted again.

At this point I give up, and decide once again that the parallel builds feature is simply broken with Intel Fortran. Is there any other workaround? It's broken in both 9.1 and 10.1, on Windows XP and Vista. I haven't tried it in Visual Studio 2008 yet, but I'm not sure if it' s worth the frustration.

I wish I could come up with a simpler example that shows the problem, but I can't. Our code is open-source and publicly accessible if you'd like to give it a try:

ftp://ftp.hdfgroup.org/HDF5/current/src/hdf5-1.8.1.tar.gz

Scott

[Steve_Nuchia]

You describe exactly the symptoms I've had. You are experiencing more broken build ordering and less build engine crashing than me butI have 4x more projects in my solution.

Microsoft has acknowledged this as a bug and the fix has been checked into the source trees for both VS8 and VS9. A QFE (hotfix) is being produced for VS8; I expect the fix for VS9 to be in the upcoming SP1 RTM as no QFE appears to be forthcoming. It is definitely not an Intel problem; it reproduces in pure C++ solutions.

You should be able to pick up the threads on Microsoft connect.

-swn

[Matt_F_1]

Anyone have any luck with a fix from MS? I found several threads related to this on Microsoft Connect, but have yet to see mention of an available fix.

FWIW, I'm running into this with VS2005 SP1 and Intel C++/F95 10.1.024 with a 4 project solution. Never crashes, but the projects are built all at once (despite the their dependencies) thus breaking the build.

Thanks,
Matt

[jimdempseyatthecove]

Scott,

You've analyzed the problem quite well. I too experience similar build problems but fortunately for me launching a 2nd or 3rd build eventually progresses through to a finish. Sometimes the VS Devenv environment gets wacked and I have to exit and restart VS to get a good build. My solution has 12 projects and ~750 files. Trying to avoid circular dependencies was difficult.

I think part of the problem is VS dependency walker does not provide for recursion. By this I mean the dependencies in your solution, my solution and Fortran Module usage generally loop. The VS dependency walker is aheirarchical tree type process. Fortran Module creation and your C header file creation creates output files at the wrong level (wrong direction)in the VS dependency walker heirarchical tree. By this I mean your projects are creating additional _input_ files as opposed to the expected output files.

What helps in this case is to rework your project dependencies, seperate some projects in two if necessary, such that your C header files, and Fortran Module files are created in projects seperate from those creating object files. Then making the other projects dependent on the project(s) that create the C header files and Fortran Module files. In some cases this may require seperating the code portion of a module (CONTAINS sections) from the type declarations of the module.

Jim Dempsey

[Steve_Nuchia]

VS2008 SP1 is out as of 11 August. You must delete a bunch of hotfixes before you install it but it works!!!!

[merik]

Quoting - Steve Nuchia

VS2008 SP1 is out as of 11 August. You must delete a bunch of hotfixes before you install it but it works!!!!

Has anyone found a fix for VS2005? We are currently using VS2005 with INTEL FORTRAN 10.1.030 and experience the same problem with about 10 projects. We have a C++ DLL that links in one C++ lib and one FORTRAN lib. The FORTRAN fails to be linked before the C++ DLL is linked. This works in non parallel build mode.