Proposal to divide the stdlib CMake project in multiple libraries

[eduardz1]

Motivation

Currently, the stdlib exports a single CMake target, this means that to use even a single feature one has to compile the entire standard library. This is particularly problematic for cases where compiler support is lacking such as https://github.com/fortran-lang/stdlib/issues/107.

In the software I am currently working on, https://ffaucher.gitlab.io/hawen-website/ (note that the public source code is not up-to-date), I would consider proposing the usage of the stdlib but compiler limitations currently make it non-feasible.

The solution would be to export a library for each module, so I believe it could be solved with something like

# src/CMakeLists.txt

add_library(stdlib_io ${IO_SOURCES})
add_library(stdlib_array ${ARRAY_SOURCES})
# ...

add_library(${PROJECT_NAME} INTERFACE)
target_link_libraries(${PROJECT_NAME} INTERFACE 
    stdlib_io 
    stdlib_array
    # ...
)

install(TARGETS 
    ${PROJECT_NAME}
    stdlib_io
    stdlib_array
    # ...
    EXPORT ${PROJECT_NAME}-targets
    LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
    ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
    PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
)

So that in our application we could, for example, only link fortran_stdlib::stdlib_io (whilst still keeping the fortran_stdlib::fortran_stdlib target available) and therefore limit the compatibility issues across different compilers (and potential points of failure in general).

This is not super straight forward to implement as dependencies will have to be managed individually (for example I see that stdlib_ansi will depend on stdlib_kinds and stdlib_string_type and will also make the CMakeLists.txt file under src quite verbose.

I would be willing to try to implement this if I find agreement in the proposal

Prior Art

No response

Additional Information

No response

[jalvesz]

This is a very interesting proposal and one that I have felt the need for as well. At this point what I would suggest is that you try to push it further and we might help out iterating on the structure of the CMakeLists down the road.

There are indeed some modules that are rather ubiquitous, such as stdlib_kinds or stdlib_constants. Having this hierarchy explicit in that new build structure can help a lot.

I wonder if the examples and tests shall follow that refactoring, I'm guessing this might be actually a bit longer to manage than just the actual sources.