I was thinking how close you were coming to creating something resembling a repository, but an active one instead of a passive one. I have always thought of a repository as something more akin to an archive such as netlib. It is interesting to think about it as an active tool for constructing a project. Select a number of libraries by describing required capabilities and it is not to hard to picture the playground writing an fpm.toml manifest file for you, for example.
Can github host the repository archive files? Is anyone familiar with things like AWS CodeArtifact or Cloudflare R2? Wondering if something like that or something else would make a good area to store published fpm packages. It seems like a Github site and some CD/CI scripts or the existing fpm repository code could handle package submittals but then there is the need to store copies as letting everyone self-host their packages on github would mean if the ID went away so would the package (well, at least until someone make a new copy/repository assuming the package was unencumbered legally).
which is a different interface for the 298 precompiled packages in the FPM playground, looks more like a registry. Packages that could not be precompiled for the registry are listed here along with blockers.
@Beliavsky this is a great effort! The packages that failed to build for your environment I am assuming have “tough” dependencies?
I feel very strongly that we should figure out how to build all of our fpm packages in pure Fortran. We have to rewrite all non-Fortran dependencies into Fortran, using the intrinsic functions that get us quite far. And then we’ll need to figure out a cross-platform API for the rest, such as the Qt rewrite. Roughly speaking, you need two levels of API:
Low-level C stdlib-style API. I figured out how to do this in C using a super simple API: GitHub - certik/corec: Core C minimal portable C stack · GitHub, the same API can be used in Fortran. It has 4 simple implementations (Linux, macOS, Windows, WASM) in C: corec/platform at main · certik/corec · GitHub and probably that can stay in C, not sure if it is possible to do in Fortran on all platforms. But fpm can compile C just fine, so this shouldn’t be a problem. And you build everything else on top, in pure Fortran. I built a full C compiler from scratch (in C) on top of this API, and it works.
Graphics API: for that I have good experience with SDL3 GPU API: SDL3/CategoryGPU - SDL Wiki, this is needed for the Qt rewrite, as it would be used to do all the drawing. I think the API itself can be used from Fortran, but for the implementation probably we just want to reuse SDL3. This takes care of everything, except shaders, for those I had some success using WebGPU and automatically compiling it to DirectX, Vulcan and Metal. For Fortran applications, since we are not writing 3D games, just GUI, the shader situation is probably not that complex and could be packaged up in some ways that it’s not a problem in practice.
Packaging the above into a few well-maintained and reusable fpm packages, the rest of the Fortran ecosystem can build on top. For the low-level API fpm package, we can figure out how to do it in Fortran and extend Fortran (via LFortran) to do what we need, and for other compilers we simply provide a C implementation. That way compilers that are interested can support the pure Fortran ecosystem directly. I think you shouldn’t need to go to C for anything, except possibly for the GUI stuff via the Graphics API.
