Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Projects/source file confusion

jarvusluntatintel
1,078 Views

This may be a microsoft/visual studio issue not a Intel/Fortran issue, but the various projects/source codes in my solution are being confused. This happens in several different contexts, but the easiest to explain (and the most annoying) is:

My regular project and library are single precision, but I have created a second project and library that are double precision by setting default Real KIND = 8.

So there is lib4 library and a lib8 library in the overall solution. Project4 statically links to lib4 and project8 statically links to lib8.

There is a /lib4/source file directory and lib4/debug directory.

There is a lib8/debug directory. The lib8 uses the same source and points to the lib4/source file directory.

When I debug from project8 and step into subroutine foo inside of lib8, it looks correct, the default reals are 8 byte. However, after I quit debugging and then I check the properties page (based on subroutine foo) it tells me the file I am looking at is in lib4 not lib8! The annoying part is if I debug in and then see a mistake and correct it and recompile the library, it recompiles lib4 not lib8. When I then debug project8, it doesn't tell me that anything is out of date, it just runs the old exe that has the non-updated lib8.

As a different rant (that is relevant to the situation). lib8 is a dependency of project8. So when I go to run project8, why doesn't it tell me that lib8 is out of date and ask if I want to build/link? Am I missing a setting?

If I already have foo from lib8 opened, everything works as I expect. I step into foo, quit debugging, check the properties page, I am still in lib8, can make changes and the correct library recompiles.

This behaviour started suddenly a couple of months ago. I had not made any changes to my projects/solutions. It is possible that IT support installed some update at that time that I did not know about.

Anyone with any insights?

cheers

0 Kudos
8 Replies
bmchenry
New Contributor II
1,078 Views
i would have originally thought what you had is a cross pollination issue.
but then on rereading "The lib8 uses the same source and points to the lib4/source file directory" i would suggest you look at the "Defining Generic Names for Procedures" so the single soruce has an interface which accepts real4 or real8 etc

On another note, I have several projects which refer to 'common' source files and they note when the source is updated from the other projects.
so if your setup isn't seeing update then there is an issue in your setup.
not sure how complicated it'd be but you might try setting up the the solution and projects again.
Put the projects in separate directories. and be sure the target for each project is also a separate directory.

b
0 Kudos
jarvusluntatintel
1,078 Views

Thanks for the response. If it is a cross pollination issue that means what???

The issue goes beyond just having real4 or real8, it was just one of the easier ones to describe. For instance this morning, I had foo in project8 opened, debuged down into lib8 and made changes and then did a batch build (since my standard F7 would have built lib4 instead of lib8). I then clicked back on the file foo and pressed F5. However, even though the filefoo had been opened up in visual studio the whole time, it started debugging project4, instead of the expected project8. When I looked at the Solution Explorer editor, it showed that I had foo in project4 opened. And yes, it really was project8 the first time. Looking at local variables it is obvious whether everything is single or double precision.

If I was sure that setting everything up again would fix it, I would consider it, but it would be a major headach. I have a dozen projects and thousands of files. I have changed the optimization options on some of the individual files.

Each project and target dohave separate directories. My projects/project4/..., My projects/project8/... and so on. The only "shared" directory is the source code since I do not want to have the code duplicated in two different spots and have to make the same changes to the same files multiple times.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,078 Views
Jarvis,

When you are in the IDE in "edit mode" (not in a debug session) you are in an instance of the program Devenv. When you start a Debug session, the Devenv of the edit session shells into a new instance of Devenv .and. replaces the context of the open windows. This replacement attempts to be transparent with the open windows with exception to the Memory, Locals, Watch, ... which usualy appear on the bottom. When the debug session ends (e.g. you click on Stop), the Debug session of Devenv terminates and the shell returns to the edit session of Devenv. And (my guess) the IDE attempts to rework the window placements. Having two window tab titles of the same name may result in the wrong source window being on top.

I suggest you try this.

Setup a debug session where you can make the problem occur.
Run to break point in window of interest.
Before you click on Stop, make an edit in the file (e.g. add ! *** TEST), say at/before the line of the break point. Now click on Stop.

See if the comment "goes away". Then browse the solution window for the file you know you edited. Open that file and see if the comment is present, it should be, and my guess is it will be.

In VS IDE, when I have multiple files of same name in different projects (or have a backup copy of the file open) I will dwell the mouse over the file name on the Tab. This will show the path to the file. This verifies that I will be editing the correct file.

Jim Dempsey
0 Kudos
jimdempseyatthecove
Honored Contributor III
1,078 Views
Jarvis,

An alternate way of keeping the files strait is

Open your LIB4 source file
Open your LIB8 source file
Right-Click on Tab Name of LIB8 source file
Select New Vertical Tab Group

What you should see now is the LIB4 source file in a left tab group pane and the LIB8 source file in the right tab group pane. If you have dual monitors, then you can stretch the IDE window such that it crosses both monitors. The grasp the separator between the left and right tab group pane and move it to the point at/between the two monitors. Thenplace the remainder of the LIB8 source files in the right tab group pane.

Jim Dempsey
0 Kudos
jimdempseyatthecove
Honored Contributor III
1,078 Views
I forgot to mention.

You can stretch the IDE main window across both monitors only if it is NOT in full screen mode. In adjustable screen mode you can grab the upper left corner of the IDE window and position it to the top left corner of your left monitor, then grasp the lower right corner of the IDE window and position it to the bottom right corner of the right monitor. (or any where in between)

Jim Dempsey
0 Kudos
bmchenry
New Contributor II
1,078 Views
you asked: If it is a cross pollination issue that means what???

that means for a given solution with several projects/directories that a file or files that you think are in one project/directory are actually in another project/directory. That would explain why when you change a file in one project/directory that you think is also in the other project/direcory that it isn't being flagged as being changed when you jump from one project to the other
...OR...
the confusion is because the target build directory is the same between the two projects/directories so the changed file will also have a changed target so jumping between projects doesn't flag the 'changed source file' since the target is also changed.

Hope thatexplains my term 'cross pollination'
0 Kudos
jarvusluntatintel
1,078 Views
Jim

Thanks for the reply and the description of "edit mode" versus "debug session".

However, my problem is not that the wrong file is getting edited. There is one and only copy of the source files. The problem is that I have two different projects using the exact same source file. When I step into lib8 (from project8) under the "Project" menu at the bottom of the menu it tells me that I am in lib4 even though all the local variables are showing 8 bytes. So if I edit this file, the correct file does get edited (as there are no other copies of this file). My annoyance is that if I press F7 (as is my habbit), it compiles lib4 when I want it to compile lib8. I can get around this by using the "batch build" option and that works, but I keep getting bitten by this problem in different ways. For instance, after the batch build, I go back to the file that I had opened in project8, but instead of being in project8 it has switched to project4.

I never intentionally have files from project4 and project8 opened at the same time (nor lib4 and lib8). So it is not a question of having twowindows tab tiltles of the same name. When "foo" from project8 turns into "foo" from project4, there is only window that foo is opened in.

I've been trying to decide if it is worth recreating my solution and all the projects from scratch and if I successfully did that whether the problem would just come back again or not.
0 Kudos
jimdempseyatthecove
Honored Contributor III
1,078 Views
>>There is one and only copy of the source files
that's ok
>>I have two different projects using the exact same source file
that's ok
>>it tells me that I am in lib4 even though all the local variables are showing 8 bytes
didn't you say the source file "lives" in the lib4 folder?

>>My annoyance is that if I press F7 (as is my habbit), it compiles lib4 when I want it to compile lib8

Try this change in solution organization

Solution YourSolution
Project YourLib4 (library project)
headers
sources
...
Project YourLib8 (library project)
headers
sources
...
Project YourMain4 (x32 application project)
headers
sources
...
Project YourMain8 (x64 application project)
headers
sources
...

IOW use seperate projects as opposed to different build configurations for one project
Then:

Set the dependencies for YourMain4 to include YourLib4 but not YourLib8
Set the dependencies for YourMain8 to include YourLib8 but not YourLib4
(I haven't tried this)
Select Build Configuration to x32
Properties on YourMain8 to exclude from build
Select Build Configuration to x64 (see if YourLib8 is back in build)
Properties of YourMain4 to exclude from build
(if you are unable to exclude projects per build configuration then ignoreabove steps)

When you want to debug x32, set the startup project to YourMain4
When you want to debug x64, set the startup project to YourMain8

Although this is a little quirky (not using from configuration drop-down), it may give you what you want.

Jim Dempsey
0 Kudos
Reply