Company-wide CVF migration to IVF

[longden]

In a situation with many developers using CVF on a single project(ie, common source and CVF workspace/project files) is there an optimal way of rolling IVF to all the developers, or must each person configure the IVF settings separately and manually, following the instructions of the first person to do so?

I was wondering if there was perhaps a recommended procedure todistribute working.sln and .vfproj files, rather than asking everyone to follow a long configuration process, but it seems like this would only work if the source file pathnames were exactly the same on each computer?

[Steven_L_Intel1]

I've generally found that project files are environment-independent unless hardcoded paths were used. Source file paths are relative to the project file, so in general you can just ZIP a "solution", unzip it and build it.

Where things can get sticky is if you have to change defaults such as add directories to the Include and Libraries paths, as this is a per-user configuration.

[Intel_C_Intel]

Hello.

We have just made the transition CVF -> IVF, and the only compiler option we had to pay attention to was /iface. Now if you have some non-fortrancodethat calls CVF made Fortran code,"/iface:cvf"may be useful, or you can ensure that the non-Fortran code uses the same decoration as is default in IVF. Actually we found the latter solution to be the better one -as Intel Fortran and Intel C++ nowshares the same default calling convention (very convenient).

Regarding optimization flags there are no issues, for example it is no problem tolink high performance vectorized SSE2 code with non-SSE2 (blended) code.

Lars Petter

Message Edited by lpe@scandpower.no on 01-04-2006 01:27 PM

[longden]

Lars,

We had a lot more changes to make during the migration, mostly with project dependencies and project settings (compiler and linker) to minimize the number of warnings (60,000+ !!) During migration, projects with combined Fortran/C code were split into two projects (as expected from the white paper), but both output projects inheriteddependencies from the original such that it created a redundancy during the Link step.

Example:

- Project A (Fortran and C) is dependent on Project B.

- Project A migrates to become Projects A and A_lib.

- Dependencies set by the migration wizard:

Project A depends on A_lib and B

Project A_lib depends on B

Note that both A and A_lib are dependent on B. During Link, this redundancy results in a lot of warnings that gets worse as other projects with the same issuecontribute to the problem. Project Dependency had to be manually reworked to remove the redundancies created by the wizard. Granted these are only warnings, but the large number causedbuilds to take over an hour, and once removed, the build completed in about 5 min.

[Intel_C_Intel]

Hello,

I understand your concerns, and with so many files and people involved, it may be a good idea to make a company-wide recipie on how to do it. The reason I think this may be a good idea is that you have many files and warnings and also mixed language (Fortran and C) issues. Then one experienced engineer inyour company can develope a prototype on how to do it in your case and distribute this to the other employees. For example everybody has to select the same calling convention to make linking possible. Instead of distributing the .vfproj and .vcproj project files, you may instead just make a short list, typically one page, that include the essentials.

Lars Petter