modules as include files

[Intel_C_Intel]

Hello all;

Using the development environment, I'm having trouble with modules that are searched for outside of the immediate project (as opposed to their .F90 files being added to the source files folder of the project). Specifically, if variables defined in the module are not accompanied by the "parameter" attribute, a linker error LNK2001 is generated indicating each variable as an unresolved external.

If I then just add the .f90 file for the offending module to the source file folder, no such error occurs.

It appears that in the former mode the modules are not being recompiled, but rather previously compiled mod files must be located in some specified "include" directory in order for the modules to be recognized. This appears to be at odds with the Programmer's Guide:

"If your program includes modules, you do not need to explicitly add them to your project, they appear as dependencies. The visual development environment scans the file list for modules and compiles them before program units that use them."

Any help on this would be greatly appreciated; I'm tired of tracking down all the modules I need and inserting them into the project by hand!

Tim

[Jugoslav_Dujic]

Well, the description in Programmer's Guide is a bit imprecise. The thing works like this:

When you USE a MODULE in your file, the compiler does not require to have its .f90 file, but its .mod file. When a source containing MODULEs
is compiled, both FileName.obj and a set of ModuleName.mod files is
produced (one for each contained MODULE). Normally, for modules included
into the project, .mod files will be in its .Debug directory (which is the default place to search for modules for every project).

If you want to use modules from another location(s), follow these steps:

1) Make sure the .f90s containing MODULEs are compiled; locate their .mod files in corresponding Debug directories.

2) Copy .mod files into appropriate place(s), say, make a directory
called Shared.

3) Add Shared directory either into your INCLUDE environment variable
or enter the path to Shared in Project/Settings/Fortran/Preprocessor/Custom INCLUDE and USE paths.
(I'm not 100% sure if the former works)

See, for example, the Program files...DFInclude directory: there are
.f90s and .mods for each MODULE (there are DFWIN, DFLIB, DFLOGM) etc.
You can even copy your .mods there and use them as regular Compaq's
ones.

HTH

Jugoslav

[Intel_C_Intel]

Jugoslav;

Thanks for your kind reply. My original note is perhaps unclear. I had, in fact,performed the steps you suggested, except that instead of changing the INCLUDE path environment variable I used your second approach with CUSTOM INCLUDE and USE path. Setting the latter does the job part way: the .mod files in my "SHARED" folder are recognized and processed, except that any variables declared in the modules that are not decorated with the PARAMETER attribute yield "unresolved external" error messages. As I mentioned in my original note, if the .F90 files are for the offending modules are then added to the project, no such errors occur.

All this raises a second question as to whether problems might arise if the module.F90 files (previously compiled and located in SHARE) and the immediate application are compiled with different compiler options.

Any wisdom?

Tim

[Jugoslav_Dujic]

Hmmm, I'm giving up. This has something to do with name mangling, where module variables are exported as ModuleName_mp_VariableName (if not PARAMETERs), but I don't know how to overcome this. Steve?

[Steven_L_Intel1]

Since I haven't seen an example of what's being tried, I don't know what the problem is. The "name mangling" you refer to is correct. I don't know what Tim is really trying to do - if he'd send a ZIP file of his project to us at [email protected], we'd be glad to take a look.

Steve

[Jugoslav_Dujic]

Me again. Re-thinking about that, the behaviour is logical (though it's a real PITA). Namely, if you do connect .mod files, the compiler is happy, but linker doesn't have nothing to link with, since no one had told him where to find modules' .objs. You probably have to also specify in
.../Settings/Link/Input additional .objs containing the "meat" of the modules
(PITA again). I'm not sure if linker would search for .objs if they are contained in default library dirs (Tools/Options/Directories) and what does
"Directories for Source Files" mean in that dialog, but you may give it a try.

Jugoslav

[Steven_L_Intel1]

Ok, I'm beginning to see.

Yes, if you are getting .mod files from somewhere else, then you also need to add the .obj files to the project somehow. The easiest way to do this is to just add them as project files. I like to use a static library project type for something that is just modules - then the .mod files and the .lib are all one needs to use.

Steve

[Intel_C_Intel]

OK, so I've tried making .LIB files and find that these *still* must be added to the project manually--the linker doesn't go out and look for them in the directory indicated by the LIB environment variable. This was what I was hoping to avoid: having to go track down stuff and add them manually. Oddly, the MOD files are amenable to automation by locating them in the directory specified by the INCLUDE environment variable. I guess I don't see what advantages are supposed to derive from this logic. It seems easier to just locate the .F90 modules in a common directory dedicated to modules and then just add the needed module source code to the project at hand. Then there's no need to worry about .MOD files and .LIB files and where they are located. The only penalty would appear to be that the modules are recompiled every time the project is built, but so what?

Have I grasped the intentions of the designers correctly?

Thanks to Steve and Yugoslav for their suggestions; at least I understand the issues a lot better.

Tim

[Steven_L_Intel1]

There's a reference to the module name in the source that does a USE, so the compiler knows to look for the .MOD. There's nothing, by default, to tell the linker what object file or library to pull in for the module's globals. But you can fix this by adding the following line to your module source:

!DEC$ OBJCOMMENT LIB:"whatever.lib"

Where whatever.lib is the name of the static library from your module project. This will make the linker go look for it, following the same paths it uses for other libraries. You can put a full path in there if you want.

Steve