Have CMake and Make backends

[certik]

Currently the Haskell based fpm is compiling things directly, just like Cargo does it. That's the best default. (The "archived" Rust based fpm was generating CMake.)

However, until fpm is everywhere used by everybody, it would be super helpful to have a CMake and pure Make backends. That way we can move packages like stdlib or any of my own packages into using fpm, and yet not require it from the users --- they would continue using CMake or Make.

Also by generating the CMake / Make automatically, it will be a lot easier to maintain those in stdlib for example.

Since fpm knows (or should know) everything about the Fortran project, it can generate 100% robust CMake and Make files, following the latest practices for CMake / Make, human readable, etc.

I am thinking having these backends would be beneficial for many purposes, such as debugging, anyway. We should also have a Ninja backend.

[milancurcic]

and yet not require it from the users --- they would continue using CMake or Make.

Also by generating the CMake / Make automatically, it will be a lot easier to maintain those in stdlib for example.

I don't understand why generate CMake of Make files. If fpm is smart enough to generate a correct CMake or Makefile for an arbitrary package, would it not be smart enough to simply build the package on its own?

I thought that the value of enabling CMake or Make backend is when fpm is not smart enough yet to build the package on its own, but is just smart enough to detect an existing CMakeLists.txt, Makefile, or configure file, and run the appropriate commands to build it, like, cmake . or FC=gfortran make.

[certik]

Let me see if I can explain it better.

We should assume that fpm is smart enough to completely build the project on its own. We are very close and we will get there soon.

The other assumption is that the goal has never been to call an existing CMakeLists.txt or configure script. The whole point of fpm is that users write fpm.toml and they never write CMakeLists.txt or configure by hand.

So with these assumptions, yes, you can just use fpm. However, it will be a while before we can just get every user using fpm. For example I don't think it would be wise to get rid of the CMake build system in stdlib and only use fpm --- maybe later, but not today. At the same time, I would love to be using fpm with stdlib as well as all my other Fortran projects now. So to achieve it, if fpm can generate CMake, then users of my packages can keep using CMake as they do now. But I, as a developer, can just use fpm, and use fpm to generate the CMake files for my users (and commit them to git), so that I do not need to maintain the fpm build system, and a separate CMake build system by hand. And since fpm knows how to build the project on its own, it also by definition knows how to generate beautiful looking CMake files that just work (or any other build system also).

[milancurcic]

Okay, I understand now. The use case for this is when a developer releases a new package, they can use fpm to emit configuration files for different build systems.

For example, datetime-fortran started with a manual Makefile. Then Zaak wrote a CMakeLists.txt, and Michael modernized it later. Mark wrote an autotools config. Now it can be built in these different ways.

If I had fpm back then, I could just have done something like:

fpm build --cmake
fpm build --make
fpm build --conda
...

and be done with it.

[certik]

Yes exactly. And not just be done with it, but you can keep using fpm to keep the other build systems up-to-date. When you have a bigger project, the inter-dependencies of Fortran modules change every time you modify the use line (all the time). So you have to update manual Makefiles all the time you change this. And every time you add / remove files or move them around, you would have to update CMake also. fpm could do all that for you.

In fact fpm could detect that your project contains fpm-generated CMake (from some comment in it) and it can warn you every time it needs to be re-generated.

[everythingfunctional]

So, the idea here is that, not only should FPM be able to use "non"-FPM packages, it should also be able to generate "non"-FPM packages? I think this may be inviting a lot of requests for special cases. We might end up constantly chasing users who aren't willing to actually use FPM as intended.

I'm not saying it isn't doable or worth considering. If we limit the scope to saying these other build systems must functionally produce exactly what FPM itself would do it might not be too bad, but then I don't think that actually reaches many people that we wouldn't have already convinced to switch over.

On the other hand it might provide a slightly smoother transition path. Make these tweaks to your current build system so FPM can use. Then get all your user's to adjust to that. Then stop maintaining that build system yourself and let FPM do it.

I'll have to think about this for a while.

[milancurcic]

I made a joke a year ago, and we may actually do it.

I share the same concerns as Brad. Mainly that this effort may not be closely aligned with FPM itself. In other words, it would be helping users to not use FPM. On the other side, if this would help many packages support multiple build systems, it would improve their portability, a long-term Fortran goal.

[certik]

From a practical perspective, we already use both CMake and manual Makefiles for stdlib (because people have requested both) and now we also want to use fpm. I have the same problem with dftatom and Milan with datetime-fortran. I bet there are tons of other projects like that too. So instead of each of us maintaining 3 different build systems, let's just all collaborate on CMake and Makefile backend to fpm, which will produce higher quality CMake / Makefile in the end, and it will remove the burden of each of us maintaining 3 different build systems.

[everythingfunctional]

Ok, let's at least finish a beta version that just supports standard FPM projects before we start tackling this one though.

[certik]

I agree. I only posted it here to keep it in mind.

[lauvergn]

Okay, I understand now. The use case for this is when a developer releases a new package, they can use fpm to emit configuration files for different build systems.

For example, datetime-fortran started with a manual Makefile. Then Zaak wrote a CMakeLists.txt, and Michael modernized it later. Mark wrote an autotools config. Now it can be built in these different ways.

If I had fpm back then, I could just have done something like:

fpm build --cmake
fpm build --make
fpm build --conda
...

and be done with it.

I think this feature will be great in particular when you want to distribute a code:

• some users just want to type "make" to be able to compile the code (and maybe edit the makefile)
• the fpm installation (with its dependencies) is not straightforward and it adds another layer. If it fails, without this feature you will not be able to run the code.

lauvergn (alias gardhor)

[certik]

What would be a good behavior for the end user for the cmake backend?

Perhaps

fpm generate --cmake

and it would create (or override) proper CMakeLists.txt files for your current project in your existing directory. Then I can commit them to git if I want to. (There can be another mode where it copies everything into a new directory.)

What about dependencies? One way could be to create proper CMakeLists.txt in build/dependencies, and then hook them up properly from your main project CMakeLists.txt.

@LKedward, @milancurcic what do you think?

[awvwgk]

@certik I currently working on a meson backend for fpm built upon #266 and #257, once either of the PRs is merged I can get this branch from its currently transitional state into a stable form and publish it for testing.

I have a (somewhat) working model for CMake as well, but this is far more involved to get a proper dependencies handling compared to meson, therefore I won't push any of those until I'm done with meson generator.