[CMake] Querying targets for Fortran module files & module file installation advice

Zaak Beekman zbeekman at gmail.com
Wed Apr 3 09:24:12 EDT 2019


Hi all,

This didn't get any bites, so I'm re-sending it. Any thoughts, however
short they may be would be appreciated. Right now, the only obvious
solution to me is to use `install(SCRIPT ...)` where a script uses
`file(GLOB_RECURSE ...)` to enumerate modules and submodules in the
build path, followed by a `foreach(...)` loop over all the found
artifacts to install them with `file(INSTALL ...)`. This feels
fragile, and un-idiomatic. Am I missing a better way to do this?

Thanks,
Zaak

On Sun, Mar 31, 2019 at 5:10 PM Zaak Beekman <zbeekman at gmail.com> wrote:
>
> Hi all,
>
> What's the best approach for handling cross-platform (i.e., MSVS, Mac,
>  Linux) installation of Fortran module files associated with
> libraries?
>
> After searching the docs, I couldn't find any good and obvious way to
> handle installation of Fortran module files associated with library
> targets. These are compiler specific, and, perhaps a better approach
> might be to ship all executable code compiled into libraries and put
> inside submodules, and ship a free/open parent module with interface,
> type, class, constant, etc. definitions.
>
> But, at any rate, it would be nice if there were a better way to
> install Fortran module files besides something like:
>
> ```
> set(CMAKE_Fortran_MODULE_DIRECTORY "${CMAKE_BINARY_DIR}/include")
>
> ...
>
> install(DIRECTORY ${CMAKE_Fortran_MODULE_DIRECTORY} DESTINATION
> ${CMAKE_INSTALL_INCLUDE_DIR})
> ```
>
> In particular, it is hard to know which .mod and .smod files will be
> produced ahead of time without parsing the source, or manually
> enumerating them. One can use the approach outlined above, but a few
> problems and drawbacks remain:
>
> 1. With IDEs like MSVS, I always seem to end up getting an additional
> directory installed under ${CMAKE_INSTALL_INCLUDE_DIR} with the name
> of the build configuration (e.g., `debug`)
> 2. Utility/test modules may have generic names (e.g. assertions.mod)
> that probably should not get installed and will very likely lead to
> name  clashes with consuming projects
> 3. Lack of standard definition of module file format and Fortran ABI
> makes portability dicey, at least until ISO_Fortran_BINDING is widely
> available and adopted
>
> It would be great if there were a target property that could be
> queried for associated module and submodule files. In addition
> additional "it just works" logic around installing Fortran targets and
> how modules are handled would be really nice. This obviously isn't an
> easy/trivial question to answer, but being able to query targets for
> module file build artifacts would be a great starting point.
>
> In the mean time, I think my only acceptable options to handle IDEs
> like MSVS is to use the `SCRIPT` signature of `install()` where I can
> use `file(GLOB_RECURSE ...)` to find module files and strip out any
> build configuration specific directory structure. (Or at least adopt
> my own logic and conventions for this...)
>
> Any tips or advice would be very appreciated!
>
> Thanks,
> Zaak


More information about the CMake mailing list