-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build systems #2
Comments
Meson generally has better Fortran support than CMake. |
Can you elaborate on particulars, @scivision? I don't have much Meson experience, but CMake has a whole host of useful infrastructure for reproducible builds, finding MPI, introspection, following standard installation conventions, writing package config modules, testing... And I've found recent versions to have excellent Fortran support. |
I would recommend CMake as it is known to work on all platforms with excellent support and usage in lots of projects. So we know it will deliver, even though I don't like how easy it is to write ugly CMake files. In addition, I think we should maintain simple manual Makefiles (and test them on CI), to show how to compile it by hand. So that people can easily integrate things into their projects. In particular, I would like the stdlib to be preferably written in a way so that big projects can simply copy the files into their repository and things will just work. I have done exactly that in https://github.com/certik/dftatom and I have seen people do both: some people use the provided cmake build system, and some other people literally copy the https://github.com/certik/dftatom/blob/fe479fd27a7e0f77c6a88a1949996406ec935ac2/Makefile.manual As you can see they are super simple, and so there is value in having those in addition to CMake. |
My only complaint about standard Makefiles is that dependency resolution can get pretty hairy. Also, a potential issue with standard makefiles is you may want to alter the build based on system introspection. For example, if you need to work around a compiler bug. But as long as I don't have to write maintain vanilla Makefiles, (or auto-hell) I'm happy to defer to others' preferences for including vanilla makefiles. |
I think CMake is a good common ground. Meson supports more A prime example: https://github.com/scivision/fortran2018-examples/ |
@scivision I'm curious which submodule features are missing from CMake? Their Ninja patch was upstreamed and should be included in the next release of Ninja, and I've been using submodules extensively without issue since 13.4.3 with MSVS and Makefile generators. |
for CMake, consider requiring at least 3.14 so that check_fortran_source_runs is available, or at least if() else() it. That's necessary to check if Coarrays are fully working to avoid confusing runtime errors. A compile/link check is not adequate. |
This doesn't work with CMake, last I tried https://github.com/scivision/fortran-submodule/blob/master/src/parent1.f90
|
I would suggest we do not use any features that CMake can't support. See #15. |
FWIW, the issues reported have an easy work around that gets CMake to work: Switch This is an issue only when you have a separate module procedure and the first prefix-spec is |
Add option for reverse sort in `sort` and `ord_sort`
improved aesthetics to make code consistent with stdlib's format make & cmake passed with msys2-gfortran-10.
Use this issue to discuss and propose build systems and/or methods.
Some candidates so far:
configure && make && make install
);The text was updated successfully, but these errors were encountered: