Hi all,
This is an important topic for fpm, as shown by the number of related issues:https://github.com/fortran-lang/fpm/issues/50 https://github.com/fortran-lang/fpm/issues/112 https://github.com/fortran-lang/fpm/issues/191 https://github.com/fortran-lang/fpm/issues/350 https://github.com/fortran-lang/fpm/issues/329
I will perhaps open the meeting with a summary of these issues and what is to be discussed and decided.
1 Like
There are some major design points we have to discuss. I currently see five, somewhat independent, points where we have to make decisions on.
Syntax of the compilation profile in the manifest
Representation of the manifest as profile_config_t in fpm
Translation of the representation of the profile into an actual compilation profile in the fpm model (interaction with --flag option from command line)
Handling of build name (compiler + hashed flags) for dependencies with different sets of flags
Inclusion of the compilation profiles in the build targets
Depending on our choices for the individual points we have to think about how to the transformation between the different layers will look and at which points we want to inject defaults and overwrites.
3 Likes
There was also a discussion thread with many ideas:
See for example #112. We need to be able to specify specific compiler flags per file as an option, in order to allow people to get their stuff built. However, I am worried that we could become just...
2 Likes
And what about compiler wrappers like mpifort? How can they be handled in an elegant way? Will there be more general options for activating commonly used libraries like MPI, netCDF etc.?
Thanks @Carltoffel , these are valid points related to the above. We have separate issues tracking these (linked below) where you can see some possible solutions or propose your own if you have any ideas!
See here also for how fpm already has basic support for MPI with the Intel mpiifort wrapper.
opened 06:30PM - 09 Feb 21 UTC
specification
Many Fortran codes use MPI and we should teach `fpm` about it and support it nat… ively.
There are two main approaches to it:
* Use the mpi compiler wrappers such as `mpif90`, which are provided by MPI implementations such as `mpich` or `openmpi`. Those compiler wrappers call the compiler with correct flags to link all MPI libraries correctly.
* You call the compiler wrappers `mpif90` to figure out what flags to use, then you supply those flags manually when executing the given compiler.
CMake supports both options and I have used both in my projects. There are pros and cons of each approach and I have discussed this with quite a lot of people already. I personally lean towards the second approach, which treats MPI as a 3rd party library that you depend on. Ultimately, that is what it is. However, for `fpm`, the user does not actually see how the compiler is being invoked anyway, so the first approach might also work. So I would choose whatever approach is easier to implement and maintain in fpm and I think we can even switch later (internally) if needed.
Let's discuss the user facing design. It seems it might be as simple as adding `mpi=true` into `fpm.toml` for each executable that should be compiled with MPI. And `fpm` would then transitively enable MPI for each module and dependency that the executable needs. In terms of choosing which MPI implementation should be used, we can start by using whatever `mpif90` is available in `PATH`.
opened 08:32PM - 12 Apr 21 UTC
This is a whole can of worms. The documentation regarding the [`dependency()`](h… ttps://mesonbuild.com/Dependencies.html) function in meson gives a nice impression on all the things one can / has to consider when dealing with dependencies.
*How does fpm find dependencies now?*
Currently, we assume the compiler can find external libraries and include files all by itself.
This works fine for system libraries, but usually there are packages under different prefixes like `/opt` or in the users home which could also be used, but are not included by default.
*Using a dependency tool*
A somewhat standard way to handle non-system dependencies are `pkg-config` or `cmake` package files, some platforms might provide their own like OSX frameworks. Also some packages are known to provide incorrect package files.
*Using environment variables*
An third-party library usually provides a way to make itself known to the system, using environment variables like `CPATH` to add include directories, `LIBRARY_PATH` to add to the library search path and `LD_LIBRARY_PATH` to add to the runtime load path. This mechanism allows fpm to automatically pick up third-party dependencies by relying on the compiler.
*Setup scripts / environment modules*
Setting those variables in the first place is tricky, usually third-party libraries provide scripts which can be sourced by the shell or an environment module that can be loaded. Sometimes those scripts and modules are not working correctly as well. This is a common issue with environment modules which miss certain crucial environment variables (missing `CMAKE_PREFIX_PATH` is a classic).
---
As a developer there is nothing more painful than working in a broken environment. Either because some overzealous setup script in `/etc/profile.d` messes with all other packages, an environment module exports the wrong paths, or a `pc` file with a typo won't be recognized.
*Can we / Should we do something about this?*
Thanks everyone; we’ll meet tomorrow Tuseday 25th May at 18:00 UTC (11:00 PDT / 14:00 EDT / 19:00 BST / 20:00 CEST).
Laurence Kedward is inviting you to a scheduled Zoom meeting.
Topic: GSoC Project Chat (fpm compiler flags)
Join Zoom Meeting
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference...
Meeting ID: 955 6894 8785
Dial by your locationhttps://bristol-ac-uk.zoom.us/u/abycOcEByr
Join by SIP95568948785@zoomcrc.com
Join by H.323
2 Likes
Sorry I could not join the meeting. Did you come up with any interesting ideas or plans how to solve the multiple orthogonal issues?
Are there any ways we can contribute from the community (apart from commenting on issues and reviewing pull requests)? What I have in mind is perhaps building some kind of table of (universal) compiler features, where we could fill the options from individual compilers.
Thanks Ivan, It sounds like you’re on the same page as us.
We’ll be having a short weekly meeting on Thursdays at 14:00 UTC which everyone is welcome to join.
See below for a Zoom invite for the recurring weekly catchup meeting for the fpm compiler flags GSoC project. Occurs weekly on Thursdays at 14:00 UTC, with the first meeting happening today (27th May).
This is mainly an opportunity for Jakub to catch up with myself and Brad on progress and technical details, but the meeting is open to all who are interested in the project.
Laurence Kedward is inviting you to a scheduled Zoom meeting.
Topic: GSoC Weekly Catchup (fpm compiler flags)https://bristol-ac-uk.zoom.us/meeting/tJYtc--urzguHNybK3pS4S8GY1bCTkUDaYsI/ics?icsToken=98tyKuCqrj8sHNWWtB-PRowQAo-gM-7zmHZbgo1EnjS2ExMHUVvRD7NAEYZ0JfzR
Join Zoom Meeting
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference...
Meeting ID: 920 4661 3468
Dial by your locationhttps://bristol-ac-uk.zoom.us/u/ab3tfWmzQ7
Join by SIP92046613468@zoomcrc.com
Join by H.323
certik
May 27, 2021, 4:21pm
11
It might be useful to consider abstracting the problem into one of defining a universal Fortran compiler command-line driver program that maps its command line to each of set of particular Fortran compilers, and then using that universal Fortran command in fpm. It would be a useful thing to have in its own right, too.
See this issue to discuss this idea further: Universal Fortran compiler · Issue #475 · fortran-lang/fpm · GitHub