Skip to content
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

Closed
milancurcic opened this issue Dec 14, 2019 · 11 comments
Closed

Build systems #2

milancurcic opened this issue Dec 14, 2019 · 11 comments

Comments

@milancurcic
Copy link
Member

Use this issue to discuss and propose build systems and/or methods.

Some candidates so far:

  • autotools (configure && make && make install);
  • CMake
  • Hand-written Makefiles
@scivision
Copy link
Member

Meson generally has better Fortran support than CMake.

@zbeekman
Copy link
Member

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.

@certik
Copy link
Member

certik commented Dec 17, 2019

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 .f90 files into their project. And so I recommend for both to be easy. In addition to CMake, it has manual Makefiles:

https://github.com/certik/dftatom/blob/fe479fd27a7e0f77c6a88a1949996406ec935ac2/Makefile.manual
https://github.com/certik/dftatom/blob/fe479fd27a7e0f77c6a88a1949996406ec935ac2/src/Makefile.manual

As you can see they are super simple, and so there is value in having those in addition to CMake.

@zbeekman
Copy link
Member

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.

@scivision
Copy link
Member

scivision commented Dec 18, 2019

I think CMake is a good common ground. Meson supports more submodule syntax than CMake, but it's not a big deal here. Maybe if we try to keep the common build system choice (perhaps CMake) as the one that's known to work for everything, it wouldn't hurt to have other build systems also available e.g. Meson. This is what I do for most projects, although for me Meson is the primary choice.

A prime example: https://github.com/scivision/fortran2018-examples/
CMake and Meson are generally equally supported, except for a few things needlessly tricky in CMake, I did only in Meson. Each directory has CMakeLists.txt and meson.build that are independent, to allow users of either build system to enjoy.

@zbeekman
Copy link
Member

@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.

@scivision
Copy link
Member

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.

@scivision
Copy link
Member

scivision commented Dec 18, 2019

This doesn't work with CMake, last I tried https://github.com/scivision/fortran-submodule/blob/master/src/parent1.f90

MODULE PURE SUBROUTINE or module pure function

@certik
Copy link
Member

certik commented Dec 18, 2019

I would suggest we do not use any features that CMake can't support. See #15.

@zbeekman
Copy link
Member

FWIW, the issues reported have an easy work around that gets CMake to work:

Switch MODULE PURE SUBROUTINE to PURE MODULE SUBROUTINE. Additionally, within an interface block this is a non-issue, as far as I can tell.

This is an issue only when you have a separate module procedure and the first prefix-spec is MODULE followed by additional prefix-specs then SUBROUTINE, FUNCTION or PROCEDURE outside of an INTERFACE block. See https://gitlab.kitware.com/cmake/cmake/issues/18427 for a discussion.

@milancurcic
Copy link
Member Author

We're currently using both Make and CMake (user's choice).

We will transition to fpm soon. @LKedward has an stdlib mirror as an fpm package here.

I will go ahead and close this in favor of #279.

awvwgk pushed a commit that referenced this issue Jun 3, 2021
Add option for reverse sort in `sort` and `ord_sort`
jvdp1 pushed a commit that referenced this issue Jun 4, 2021
milancurcic pushed a commit that referenced this issue Aug 22, 2021
improved aesthetics to make code consistent with stdlib's format
make & cmake passed with msys2-gfortran-10.
jvdp1 pushed a commit that referenced this issue Oct 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants