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 <[email protected]> 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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
