Projects with multiple drivers

[ivan-pi]

Following the discussion at the monthly call, I've installed fpm and am trying to convert a few of my Fortran projects to the recommended structure. These projects involve some legacy fixed-style functions and subroutines, an interface module, and several driver programs (tests). The folder structure is something like:

.
├── drivers
│   ├── driver1.f90
|   └── driver2.f90
├── src
│   ├── legacy
|   |   ├── legacy1.f
|   |   └── legacy2.f
|   └── interface.f90
└── fpm.toml

Do I need to add multiple sections such as

[[driver]]
name = "driver1"
source-dir = "drivers"
main = "driver1.f90"

to the TOML file? Right now my build just crashes because of multiple executable files.

I think having multiple executable programs is a quite common type of package, say you have a library for building mesh triangulations, and then with it a small set of command line tools calling routines from this common library.

Another question is can I already specify dependencies on system-wide installed libraries. Say a project (or one of it's dependencies) needs to be linked with -llapack -lblas (with the actual LAPACK and BLAS libraries potentially in some non-default location). Does this fit under issue #99 of custom build scripts?

I had a few other comments about the installation process, but they were already fixed in #101. A remaining point might be that after doing stack install in the fpm folder, the ${HOME}/.local/bin/ folder might not be on the path already, requiring an extra command export PATH="$PATH:$HOME/.local/bin/".

[ivan-pi]

Here is the project I am trying to convert to be fpm-usable: https://github.com/ivan-pi/fortran_lsp/tree/fpm

[LKedward]

Hi @ivan-pi, regarding multiple drivers I believe the current fpm behaviour allows only one executable source file per folder, where any other Fortran files in that same folder are assumed to be modules; this is undocumented I think because the behaviour is still under discussion, see #91 - the suggestion there by @certik seems promising.

A remaining point might be that after doing stack install in the fpm folder, the ${HOME}/.local/bin/ folder might not be on the path already, requiring an extra command export PATH="$PATH:$HOME/.local/bin/".

This is a good point and should probably be added to the README.

[ivan-pi]

Thanks @LKedward for pointing me to the previous discussion. It seems that this issue is then a duplicate. @everythingfunctional and @certik, should I close this issue and comment in #91 instead?

This is a good point and should probably be added to the README.

I will create a pull request in the next day or two.

[everythingfunctional]

Hi @ivan-pi , thanks for trying out fpm with your project. You can have more than one executable per project, but as @LKedward pointed out you must have them in separate folders. Not that the entry in the toml file starts as [[executable]] instead of [[driver]], or it seemed like you considered these to be test programs, so you may want to specify them with [[test]].

As for the compiler flags, we haven't really gotten a good handle on how to deal with those. The problem mostly comes from what to do with them in terms of dependencies. Does a project's dependencies get compiled with the flags it specified? What about projects that depend on it? What about if you switch compilers? It's on our radar, it's just a really hard problem that we haven't tackled yet.

You can close this issue if you feel the other adequately covers it. Also, feel free to open up other issues if you want make sure we keep track of anything else you asked here.

[certik]

I believe Cargo supports to have multiple main programs in the bin directory. I think we agreed to use an app directory instead of bin. Is there a reason why fpm cannot compile those automatically?

It is intuitive and natural. I would expect it to work also.

[everythingfunctional]

It's not that we can't support it, it just makes things more complicated than "everything else in this folder is a module that should be compiled and linked in".

We (sort of) support having multiple programs in the app directory, they just have to be in separate sub-folders and have explicit entries in fpm.toml.

[certik]

Yes, it's a little more complicated, but it makes life so much easier for the end user. That is the whole point of fpm. :)

[everythingfunctional]

Yeah, that's probably true.

[milancurcic]

fpm init could generate the appropriate [[executable]] sections for the user. Just throwing an idea out there, not something that I think is a priority.

[certik]

Cargo does not require any modifications to Cargo.toml to have executables. We should not either. So fpm init just produces the default initial fpm.toml, and users don't need to touch it, they just create the app dir and put programs in it.

[milancurcic]

Yes, the sane default of multiple programs in app/ is what we should aim for.

My comment about fpm init was specific to the scenario of multiple programs in custom (non-default) location, which needs to be specified in the toml file, just like Cargo does.

I actually didn't know (or forgot) that we supported multiple executables by specifying them in fpm.toml, so I was happy to read about it in this thread.

[lauvergn]

Yes, it's a little more complicated, but it makes life so much easier for the end user. That is the whole point of fpm. :)

Yes, that will great !!

alias gardhor

[ivan-pi]

Is this issue still relevant?

I recall @LKedward mentioning somewhere that my fortran_lsp repo could be built fpm, meaning that this has been resolved.

[LKedward]

Hi @ivan-pi, yes I believe this issue is now solved.