Independently compiled object and module files

[dboggs]

Despite a lot of reading in user guides and advice from others on this forum, I am still having trouble understanding how best to incorporate object files and module files in my project that have been independently compiled.

I know how to create a static library of object files and reference that library in my project, but what if the object file is not in a library? It has been suggested that i can simply use Visual Studio to add the obj file to my project, but it doesn work--I still get unresolved external linker errors. Is this supposed to work?

I can use VS to specify project properties > Linker > Input and enter the entire obj filename (including path) but that is a fair amount of work and error prone.

As for modules, we would like to create a library-like collection that can be USEd by various projects, but this seems to be awkard. An independently compiled module creates two files: mymod.obj and mymod.mod. The obj file is needed for compiling a project and the mod file is needed for linking. So, as I best understand it, a "library-like" environment involves two steps:

1. Put the *.mod files in a special directory and make that directory available to projects, globally using VS Tools > Options > Intel Visual Fortran > Compilers > Includes, or project-specific using VS Project Properties > Fortran > General (or Preprocessor) > Additional Include Directories.

2. Make the *.obj files accessible to the program. But this is not as easy as it might be, as described above.

All of this effort is putting a damper on the notion around here of producing general-purpose modules. Can anyone suggest how to streamline it?

[IanH]

A quick test here shows that adding the "external" obj file to the project "works for me". (Are you compiling the separate object file outside of Visual Studio? What specific errors do you get? Make sure your compile options are consistent between the compile that gives you the object file and the compile for the main Visual Studio project.) Where I am consuming third party object code I do your steps 1 and two (I use the project specific include setting rather than the global environment (allows me to vary library versions, etc, from solution to solution) and the object code is nearly always in a library (otherwise I might have to nominate hundreds of obj files for just one library)). Where I am consuming my own "library" code I usually just provide the source to the compiler in each solution that needs it (via an external reference in the source code control system). That then gives me the flexibility to play with compiler settings for the library code in each solution that uses it. When specifying where the object code is I prefer to use the project properties, rather than having the library or object file "appear as a source file in the project"- I find this easier to manage from the point of view of project configurations (debug library pulled in for debug builds of the solution, release library pulled in for release builds, directory references depend on build macros, etc). You can still do this to some extent if the object code is referenced as a source file, but I find it clumsy. One disadvantage of the project properties is a lack of transparency, and the time required to get the properties initially set up.

[mecej4]

DBoggs wrote: "The obj file is needed for compiling a project and the mod file is needed for linking."

Correction: The mod file is needed for compiling a project and the obj file is needed for linking.

[dboggs]

Yes, sorry I got the compile/link requirements reversed. Dislexia rules again. On the more important note, I have yet to receive a recommendation for how best to handle this situation. Any advice out there? I am just surprised to conclude that handling modules in a library environment is twice (at least) the work of handling object files.

[Steven_L_Intel1]

In version 12.1 we made a change that so if you have a dependent library project, we add its "output" folder to the INCLUDE directory list of the parent. So all you should need to do is make the library project a dependent and the rest should fall out. A static library dependent project is the recommended way of handling modules (with object code) not in your project.