Compiling duplicate modules names to override default behaviour

[gnikit]

I have a project geared towards teaching computational neutronics and ideally I would like to use fpm across the entire project.
The project follows mostly the traditional fpm dir structure, with the exception of the solutions directory which contains solutions
to a series of exercises. The "solutions" are modified versions of certain files under src and/or the main.F90

├── app
│   └── main.F90
├── fpm.toml
├── input.in
├── solutions
│   ├── 1a
│   │   ├── input.in
│   │   └── Materials.F90
│   └── 1b
│       ├── input.in
│       ├── main.F90
│       └── Materials.F90
└── src
    ├── Materials.F90
    ├── PETSc
    │   ├── ...
    │   └── PETSc_Vec.F90
    ├── ...
    └── Solver.F90

The way that this works is that during compilation we include the .mod files under the solution instead of the ones under src. In CMake this looks something like this

    # Solutions that change the PUBLIC interface of a MODULE e.g.
    # add a PUBLIC function, change the arguments in a PUBLIC function etc.
    # require recompilation of the altered MODULE  +
    # recompilation of all MODULEs where the altered MODULE is being USEd.
    # Here we recompile all MODULEs found in `src` to keep things simple.
    # If the codebase was large, to minimise compilation time, we would
    # have to find a way to create a list of all the MODULEs being USEd
    # from each solution MODULE and recompile only those.
    set(SOL 1b) # Test name
    unset(SRC_SOL_FILES) # Reset the list of files to be compiled
    set(MAIN_SRCS ${SOURCES}) # Copy the file names under `src/`
    file(GLOB SRC_SOL_FILES solutions/${SOL}/*.F90) # Get all Fortran files for this solution
    list(REMOVE_ITEM MAIN_SRCS src/Materials.F90) # Remove duplicate modules from MAIN_SRCS
    add_executable(${SOL} ${SRC_SOL_FILES} ${MAIN_SRCS})
    set_target_properties(${SOL}
        PROPERTIES
        OUTPUT_NAME ${SOL}
        if(NOT MSVC_IDE)
        PREFIX bin
        endif()
        RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin/sol
        Fortran_MODULE_DIRECTORY ${CMAKE_BINARY_DIR}/solutions/${SOL})

Which leads me to my question, any ideas on how to do this with fpm?
Full fpm.toml can be found below in case it helps

Click to view fpm.toml

name = "diffusion"
version = "1.0.0"
author = "ICL"
copyright = "Copyright 2022, ICL"
license = "MIT"
description = "A neutron diffusion solver using OOP and PETSc"

[build]
auto-executables = false
auto-tests = false
auto-examples = false
external-modules = ["petscsys", "petscksp", "petscvec", "petscmat"]

[library]
source-dir = "src"

[[executable]]
name = "diffusion"
source-dir = "app"
main = "main.F90"

[[executable]]
name = "diffusion-petsc"
source-dir = "app"
main = "main.F90"
link = ["petsc"]

[[example]]
name = "sol1b"
source-dir = "solutions/1b"
main = "main.F90"

[install]
library = false

[gnikit]

Apologies for the spam, I was wondering if anyone has any input on this? The project is meant, among other things, to introduce FPM as a tool to research groups across Imperial College London and ideally I would like it to demo the full strength of FPM.

[awvwgk]

The module duplicate check is global at the moment, any module file name currently has to be unique. This constraint is however only required when dealing with libraries, but not when dealing with separate executables or tests.

fpm/src/fpm.f90

Lines 221 to 222 in 3045817

	! Check for duplicate modules
	subroutine check_modules_for_duplicates(model, duplicates_found)

Since we store source files with their packages we currently lack the resolution to identify whether a module is provided as part of a program or the library itself.

[gnikit]

Thanks for the quick reply @awvwgk, so would compiling as an executable resolve this? We actually don't make use of the library

[awvwgk]

Compiling as an executable would be resolvable (in the sense of patches are welcome), for a library I however don't see this option.

[gnikit]

I see thanks for the clarification. I think we probably don't have enough time for me to conjure a patch, merge it and release it. FPM is very functional as it is, and adding support for my weird use case should be at the bottom of the TODO list.

[awvwgk]

An alternative approach might be to structure your project using local dependencies:

name = "ex"

[dependencies]
solutions.path = "Solutions/1a"

And provide in the respective subdirectores manifest files like

name = "solutions"
library.source-dir = "."

[gnikit]

I will have a play with this and let you know how it goes. Thanks for all the help!!

[gnikit]

Thanks @awvwgk but from what I could tell this approach runs into the same problem with duplicate module names (at least with my fpm master build). Not being able to easily run the solutions might be good thing, it might make students engage more with the tasks.

[awvwgk]

Another option might be to separate the working environment and the solutions but have all common files in a common dependencies:

# fpm.toml
# Please place all your code in the src/ directory
name = "ex"

[dependencies]
teaching.path = "lib"

# solutions/1a/fpm.toml
# Build this solution with fpm build -C solutions/1a
name = "solution"
library.source-dir = "."

[dependencies]
teaching.path = "../../lib"

# lib/fpm.toml
# This material is provided by instructors, you will use those routines for the course but not modify them yourself
name = "teaching"
library.source-dir = "."
build.external-modules = ["petscsys"]

[awvwgk]

For our teaching course here we provide first only online resources which should be copied (https://qc2-teaching.readthedocs.io/en/latest/programming.html) and later a single source archive which cleanly builds for the students to add source to (https://qc2-teaching.readthedocs.io/en/latest/scf.html). We have of course solutions, for the first part of the course even checked into the repo, but we don't explicitly share any of those with the students.

[gnikit]

Thanks for all the help. BTW I can finally say that FPM has made it into the Imperial College's Graduate School curriculum.