[CMake] Compiling Fortran Modules And

[Andreas Mohr]

Hi,

[disclaimer: quoting below is non-standard]

On Tue, May 14, 2013 at 10:48:22AM -0400, cmake-request at cmake.org wrote:
> Date: Tue, 14 May 2013 14:36:18 +0000
> From: "Pritchett-Sheats, Lori" <lpritch at lanl.gov>

| Hmm. Files with directory specification.
| 
| But then...
> 
> > set(F90Library_SOURCE_FILES)
> > foreach (src_file ${F_PREPROCESS_FILES})
> >
> >   get_filename_component(filename "${src_file}" NAME_WE)
> >   set(F_file ${CMAKE_CURRENT_SOURCE_DIR}/${src_file})
> 
| ...using filename-only prepended with a questionably precise
| *current source dir* (if that was a function/macro invoked from
| somewhere else, then I'd buy that argument since
| CMAKE_CURRENT_SOURCE_DIR likely *would* be meaningful each,
| but since it seems it's processing over that F_PREPROCESS_FILES loop
| open-coded right there, the dir does seem out-of-place versus each
| of the input file dirs).
> 
> 
> I've replaced CMAKE_CURRENT_SOURCE_DIR with <PROJECT_NAME>_SOURCE_DIR where PROJECT_NAME is my current project name. Did not change the behavior of the error. CMake still can not find rules to make the files I listed below.
> A frequent CMake pattern is to have one CMakeLists.txt per each files
> directory (to always have processing symmetrically going from foo_SOURCE_DIR to
> foo_BINARY_DIR, such as configure_file() etc.).
> 
> I'm aware that this is a frequent usage pattern. However, in this case I have numerous directories, Fortran module dependencies across these directories and at the end instead of a single library to install, I would have over 20 libraries. If I can not maintain the  old directory structure, I would rather flatten the entire src tree.

Now how did I manage to know that this would be the reply? :)
For dozens of directories, that's indeed not a very manageable or
elegant solution.


Possibly this handling is a constraint of CMake build environment
generation (possibly since some generators cannot support that handling?),
that (AFAIR) rules must be defined within the directory
of the input files for things to actually get triggered *implicitly*
properly (purely by having something [e.g. compiler inputs] request
the output argument, and the existing rule then processing it).

AFAIR the FAQ (have a look there...) or some other prominent forums
on the internet discussed this, and AFAIK the suggested workaround
was to do things via target dependency chaining instead
(i.e. implicit "generated file" hookup does not work,
thus one needs an explicit *target* for that conversion handling,
and then explicitly let something else depend on that target, or so).

But then what do I know... ;)

Andreas Mohr