Skip to content

Understanding intent #81

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

Closed
ShamanTcler opened this issue May 19, 2020 · 3 comments
Closed

Understanding intent #81

ShamanTcler opened this issue May 19, 2020 · 3 comments

Comments

@ShamanTcler
Copy link

This is more of a discussion than an issue.

As a developer who routinely develops in FORTRAN and C, I have come across Conan, http://conan.io a C/C++ package manager.

Now in my mind C and FORTRAN are very similar in character ... both have attributes such as:

  • compilers
    • compiler vendors
    • compiler versions
    • compiler flags
  • bitness (32 vs 64)
  • debug/release builds

Etc.

Conan manages these very well via a hash assigned to the package.

Now I tried about two years ago to implement a similar scheme, to what Conan was doing but finally said ... they just do it better.

Today I use VS Code, CMake/Ninja and Conan as my "best practice". ( BTW, the new Ninja version 10. native support for FORTRAN modules ) This set up supports Intel FORTRAN/GFORTRAN and hopefully FLANG soon

So I am curious what do you think you bring new to the table.

Please don't think I am just throwing stones ... I have hundreds of thousands of lines of FORTRAN code, and Conan is bit of a "force fit", but not bad, ... so I truly am looking to improve my best practice.

@milancurcic
Copy link
Member

milancurcic commented May 19, 2020

Hi @ShamanTcler and welcome! Thank you for starting this discussion.

Here's an excerpt from an email I sent to colleagues a few days ago. It's my answer to your question.

fpm solves the (1) user and (2) developer experience problem. I don't think it solves any technical problem. How it's implemented under the hood is details, and there are many different roads we can take. But in the design of fpm we focus on UI and UX.

  1. User experience: Once fpm is installed, all that the user has to do is fpm build, fpm run, fpm test, or fpm install. This is by far the simplest UI for Fortran out there, and is aligned to what Cargo does (we designed it after Cargo exactly with UX in mind). So the only friction comes down to installing fpm. If we make this seamless--single binary executable to download--then we'll have reduced the friction to near minimum.

The key solution for here is that the user doesn't have to a) download the source code by hand; b) edit any build files; and c) download and build any dependencies by hand.

  1. Developer experience: See this doc that describes the layout of an fpm package. As you can see, we take the sane default approach like Cargo where we assume a package layout and file and module naming conventions. So the developer has to remember/learn only where to put the files and how to name them. As far as I'm aware, this is the simplest developer UI for Fortran out there. Plus, the developer also gets the perk from the user experience above, which is that dependencies are automatically downloaded, built, and linked for you.

As you know, there are tools that collectively do all of the stuff that I described. However, there's no single tool that does all of what we want, and no more. Most tools were designed and intended as "the one build system/package manager to rule them all". They all fail because this is an extremely difficult problem. They also tend to be language agnostic (or at least support several different languages), so they necessarily have to be more general and handle more edge cases, which means more complex, and more complicated for the user.

Another great developer recently said "we don't need another language-specific tool". I think that's exactly what we need. Language-agnostic is what makes a tool become either too general and complex, or the design gets out of hand to reach all its objectives. Cargo is perfect for Rust. We need Cargo for Fortran.

There's also a cultural and aesthetic aspect that people rarely bring up. It's very difficult to convince a community of developers to adopt exclusively Conda, CMake, Meson, Ninja, or whatever. Conda is maybe becoming a household name in scientific Python community, but CMake is far from being a household name for Fortran. If there's a household name for Fortran, that would maybe be autotools + Make, and that's just Linux. Yes, I'm mixing up build systems and package managers here, but I'm trying to make a point, which is that we need a household name. We need a tool that, when a newcomer to Fortran visits fortran-lang.org, we can tell them here is the one tool you should use. This will only work if we have mass buy in from the community, and I think we can do this more easily if we build a Fortran-specific build system + package manager in a single tool, than trying to adopt multiple external tools.

It's easy for you and me and most people here to say "why do you need this when there are already tools X, Y, and Z". I consider myself technically literate, and I'd walk away from a project if it asked me to install Meson or Ninja. I've walked away before from Python packages that only had the Conda install instruction, and were not installable by pip. That's just me. Now imagine how it is for somebody new to Fortran, not to mention somebody new to programming.

We are targeting Fortran users across all skill levels, and especially the entry level programmers. I think it's crucial for Fortran that a new programmer who learns Fortran as their first language, loves the experience and is not scared off.

The Fortran build system + package manager must be at least as easy (and should be easier) to install and use, than it is to install and use the compiler directly.


Take a look at Fortran Discourse. I think it's the perfect format for discussions like this.

@ShamanTcler
Copy link
Author

Thanks for the link to "FORTRAN Discourse" ... already joined. ( user CandL there)

I see mention of FORTRANCon ... good 'ole Steve Lionel is the key note, should be a good show.

Your comment "I consider myself technically literate, and I'd walk away from a project if it asked me to install Meson or Ninja." leaves me a bit perplexed ... at least regarding Ninja. I am sure this could lead to an interesting evening over a few adult beverages of your choice.

But I agree the discourse area is a better spot for this discussion. Thanks for your time and consideration.

Regards
Carl

@milancurcic
Copy link
Member

Your comment "I consider myself technically literate, and I'd walk away from a project if it asked me to install Meson or Ninja." leaves me a bit perplexed ... at least regarding Ninja.

Yes, a bit of a hyperbole. If I need the project to get work done, sure. If I'm just playing, I'd pass. From Ninja's landing page, I'm not clear how it can help me. From the manual, it sounds like a faster Make. So, a tool for power users.

I am sure this could lead to an interesting evening over a few adult beverages of your choice.

I hope we get a chance to do it soon! :)

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

3 participants