Comments (12)
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
.
from fpm.
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.
from fpm.
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).
from fpm.
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.
from fpm.
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.
from fpm.
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.
from fpm.
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.
from fpm.
Ok, let's at least finish a beta version that just supports standard FPM projects before we start tackling this one though.
from fpm.
I agree. I only posted it here to keep it in mind.
from fpm.
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)
from fpm.
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?
from fpm.
@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.
from fpm.
Related Issues (20)
- `-ffree-line-length-none` should be used by default in tests HOT 1
- Dependency level macro definitions continuously trigger dependency state changes
- Issue with running multiple examples in fpm version 0.10.1 HOT 2
- Issue with running multiple examples in fpm version 0.10.1 HOT 2
- Memory profiling reveals multiple "Conditional jump or move depends on uninitialised value(s)" errors HOT 2
- Release candidate fpm.F90 uses gfortran-specific backslash line continuations HOT 1
- CI for Metapackages broken for Macos openmpi and mpich
- build issue with ambiguous generic `OPERATOR(==)` interface HOT 1
- [build] Nonportable usage in fpm-0.10.1.F90 HOT 2
- App is not installed if source is not main.f90 HOT 1
- MPI-code can not be built with Intel compiler when using standard flags HOT 6
- target option being ignored
- Preprocess macros not work when building via `fpm build` or `fpm run` HOT 1
- fpm test with --runner HOT 8
- bug(ci): uploaded artefacts not pinned to specific GCC version HOT 2
- Implicit interface not working with lfortran HOT 2
- Linker flags are not parsed correctly by the command-line interface HOT 4
- Does fpm support lfrotran HOT 3
- Retain dynamically generated reponse file for ar command during build
- Install script always picks the latest release HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fpm.