-
Notifications
You must be signed in to change notification settings - Fork 108
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
Comments
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.
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.
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. |
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 |
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 hope we get a chance to do it soon! :) |
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:
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.
The text was updated successfully, but these errors were encountered: