Repository navigation
Merge upstream? #79
Description
Activity
Hi @wpbonelli, thanks for bringing this up. This project started as a TypeScript rewrite to explore a more modular architecture—easier to test, extend, and maintain. I didn't have grand plans initially, but it's matured enough that I think it could serve the community well. I see it as pretty complete. Happy to discuss what that might look like.
Sweet. I see that this action supports more toolchains and has a few new inputs. To make the transition easier for people, I guess we'd want this to be a clean superset of the old action. Would you consider supporting the
update-environmentinput (or similarly named)? See fortran-lang/setup-fortran#128 for background. I don't see any other behavior changes but correct me if there are any.I wonder if it might make sense to start shunting some more users over here, to exercise the new code before it replaces the upstream. Maybe we can put a note on the upstream readme to solicit some volunteers.
Pinging @awvwgk since he is the original owner of
setup-fortranand has more stature/permissions infortran-langthan I doYes, I can make this a clean superset of the old action and add things like the
update-environmentinput over the next couple of days.When this Action goes upstream, then
fortran-lang/setup-fortranshould be bumped tov2. Users then have to manually upgrade and breaking changes wouldn't come as a surprise. But we'll make the transition as smooth as possible, of course. In case things still break, they can still safely revert tov1until we fixed all compatibility issues onv2.It would be great to consolidate those two projects, as long as we keep the same feature set, the actual underlying implementation (bash scripts or typescript) don't matter too much to me. One option is to copy the code of this repo into the
fortran-lang/setup-fortranrepo in a separate branchdevelopand release it asv2.beta. Once we are happy with the feature coverage we can switch over fully to this project.We would have too disconnected git histories in
fortran-lang/setup-fortran, but I believe that should be fine, it allows users to depend on the v1 implementation as long as they need and we can gradually switch over to this project. Practically, you will only need write permissions in @fortran-lang for this, which both of you should have, but I can double check.Reacted by wpbonelli@wpbonelli It's at a state now where I'm feeling like it can be merged. The compatibility changes were made here: #81. It should now supersede fortran-lang/setup-fortran except for the few points mentioned in the migration guide. Feel free to try out
minhqdao/setup-fortran@v1if you'd like.Cool. I made a
developbranch upstream. Feel free to open a PR.Good idea with the migration guide, about this though
For some 2022 ifx releases, the release number differed from the compiler version number
if I recall right, one reason for disagreeing Intel version numbers was, the oneAPI kits were versioned differently than the compilers themselves. But maybe that was only an issue with ifort, and the disagreements with ifx were a real mistake?
Reacted by Minh DaoThis is what I mean for the 2022 versions, where release numbers ≠ compiler version numbers:
https://www.intel.com/content/www/us/en/developer/articles/release-notes/fortran-compiler/2022.html
So if you specified
2022.1on the old workflow, it pulled2022.2.0. That changed.ifort, as you pointed out, were often just "somewhere" towards the end.Got it, so with your new action, it's the compiler version that counts, not oneapi
Let's continue this conversation in the PR: fortran-lang/setup-fortran#245
Hey @minhqdao this rewrite is looking really good. Could it supersede the composite action in
fortran-lang/setup-fortranat some point? Is that what you have in mind? I don't know where you are in terms of completion but let me know if you want to coordinate.