On Sun, May 12, 2013 at 9:22 AM, Zaak Beekman <[email protected]> wrote:
> I'm curious why you want to install the .mod files. As far as I know, I > don't think you need these at run time, but I could be wrong. (I know this > to be true at least for statically linked binaries.) > When application code that use the modules (compiled into the library) is compiled, the compiler requires the .mod files. I do know, however, if you are providing a library .mod files are NOT > compatible across different compiler vendors, and even different compiler > releases from the same vendor. This, along with compilation cascades, is > one of the main motivations for the sub-module functionality specified in > F2008. This way, library vendors can ship the module sources with the > libraries, containing any type definitions, interface info, other use > associations, module variables etc. but place all of the procedures in > submodules and ship those as (possibly an archive) of compiled > submodules/object files. The customer can then build the .mod file with > their compiler, without exposing the possibly proprietary implementation > details of the methods/procedures. This is my current understanding, anyway. > Submodules (which I have never used) address the compilation cascade problem, but I think you're mistaken about the second part. The way an array object, for example, is implemented (rank, bounds, strides, memory address, etc) will vary between compilers; you can't pass an array created in code built by one compiler to a procedure built by another. You'd need some sort of Fortran ABI standard, which doesn't exist, for this to work.
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
