Projects with multiple drivers about fpm HOT 14 CLOSED

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.

from fpm.

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

from fpm.

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.

from fpm.

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.

from fpm.

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.

from fpm.

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.

from fpm.

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. :)

from fpm.

Yeah, that's probably true.

from fpm.

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.

from fpm.

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.

from fpm.

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.

from fpm.

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

from fpm.

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.

from fpm.

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

from fpm.