# Idea: Splitting stdlib into smaller separate libraries **URL:** \ **Category:** Uncategorized\ **Created:** [March 2, 2022, 12:56am UTC](https://fortran-lang.discourse.group/t/idea-splitting-stdlib-into-smaller-separate-libraries/2883 "2022-03-02T00:56:10Z")\ **Posts on this page:** 1\ **Showing post:** 13
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [March 3, 2022, 4:11pm UTC](https://fortran-lang.discourse.group/t/idea-splitting-stdlib-into-smaller-separate-libraries/2883/13 "2022-03-03T16:11:44Z")
As @zoziha mentions in [Who is using stdlib? - #8 by zoziha](https://fortran-lang.discourse.group/t/who-is-using-stdlib/2880/8) , you can use stdlib as an external library and there is already a version of stdlib that breaks it into subsections by @degawa at [GitHub - degawa/stdlib\_modules: Provides each Fortran stdlib module as an individual fpm project](https://github.com/degawa/stdlib_modules) that explores how this might work. I have maintained a large library at [GitHub - urbanjost/general-purpose-fortran: General Purpose Fortran Cooperative](https://github.com/urbanjost/general-purpose-fortran) that I generally also make major components of into individual fpm repositories so I can say there are pros and cons. - being able to build and use individual modules allows for making individual releases of such with their own documentation and testing which is particularly appealing when the overall package is frequently changing as something like stdlib is/will be doing. - it can create a large amount of duplication if you want the modules to truly be independent packages, or you have to require a build to build other packages, risking descending into “dependency hell”. - build times are minimized and so on. Some of the other possible solutions to selectively build only routines used works better with non-modularized procedures but does not buy much with modules without something quite elaborate in place to only build sections of modules. There are a lot of arguments along the way but my general conclusion is binary releases for several major compilers as agnostic packages (no CMake, fpm, make, …) covers a lot of users and usage as most users are not using more than a few compilers (often one). Then, a expanded source version, possibly built for each compiler, possibly still containing “almost defacto” fpp preprocessing directives. A makefile for the release would be preferred. For those who want to build themselves or capture and incorporate the code I think focusing on fpm is the better alternative, but it needs to be able to use a pre-built fpm package more easily without having to install the components as a conventional external library, and needs the profile for a “shared” build to be able to be specified. I picture this as an area you specify for fpm packages that you can point to and your builds will use the “standard” build profile for a compiler to build it once and other packages can then link to that build in the project’s build directory in a read-only mode, with an option in the fpm.toml file to use a specific profile build. Ultimately, something stdlib-compatible will be supplied with compiler distributions, but these are some ideas on how it could evolve in the mean time. In general I think a lot of users just want to be able to use stdlib as a “product” and install compiler-specific versions in subdirectories they can point to; others want the source free of having to pull down a lot of infrastructure to incorporate in their code or to examine and extract routines from without learning about github and git and fypp and …; and the last major group wants an efficient way to maintain large projects in fpm. --- _[View the full topic](https://fortran-lang.discourse.group/t/idea-splitting-stdlib-into-smaller-separate-libraries/2883)._