Building scipy

[isuruf]

Status at https://ci.appveyor.com/project/conda-forge/scipy-feedstock/build/1.0.10/job/002sr96nxm5vpp10?fullLog=true

is 34 failed, 12047 passed, 1371 skipped, 577 deselected, 75 xfailed, 6 xpassed, 16 warnings in 397.47 seconds

Some of these are compiler errors and might have been fixed in flang upstream. This fork hasn't been updated since May 2018 and therefore has lots of conflicts.

cc @rgommers.

[rgommers]

Thanks @isuruf. Just missed this when opening gh-130. Most of those failures seem to be related to linalg; OpenBLAS was built with Flang there as well it looks like. Fixing those may not be trivial, but it's hard to tell.

I'm also thinking about sustainability. To continue on my comment in gh-130: this repo is for now a one person effort (after @xoviat has left us) so if Flang devs won't merge your PRs that's a potential issue. On the other hand; with mingw-w64 and Mingwpy the situation is quite similar. I think right now both are half-finished. Going from there to one maintained fork would be very nice. I don't think we can as a community maintain two solutions. Do you have any thoughts/preferences on this?

Cc @matthew-brett and @carlkl

[isuruf]

I think both flang and mingwpy are viable solutions. With flang, I think the expertise needed to maintain it is lower than mingwpy, so on the short term, it's easier to get flang working (except for a few compiler bugs)

On the long term though, we should go with the option that has the best chance of merging upstream and working with upstream. (This is needed much more for flang because we'll need upstream help on fixing bugs on the compiler that are not specific to windows as flang is not battle-tested) I don't think maintaining a fork indefinitely is going to be feasible. Maybe we should reach out to flang devs on their mailing list again to see what they think.

[carlkl]

Am Do., 21. Feb. 2019 um 05:08 Uhr schrieb Isuru Fernando < notifications@github.com>:

I think both flang and mingwpy are viable solutions. With flang, I think the expertise needed to maintain it is lower than mingwpy, so on the short term, it's easier to get flang working. On the long term though, we should go with the option that has the best chance of merging upstream and working with upstream. (This is needed much more for flang because we'll need upstream help on fixing bugs on the compiler that are not specific to windows as flang is not battle-tested) I don't think maintaining a fork indefinitely is going to be feasible. Maybe we should reach out to flang devs on their mailing list again to see what they think.

Personally I will keep going the mingw-w64 route. However, any solution to the windows fortran problem is welcome. Therefore I am curious about the next FLANG version for windows. C.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#129 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFOOoi2foS3hxTgMikDb2y1IjUnSY86Nks5vPhu2gaJpZM4bGkx0> .

[rgommers]

On the long term though, we should go with the option that has the best chance of merging upstream and working with upstream.

Definitely agree with that

Maybe we should reach out to flang devs on their mailing list again to see what they think.

That would be a good idea. not sure about timing though - I don't have much spare time to offer at the moment (also, I don't know much about Fortran compiler internals, so not sure if I'd be very helpful anyway).

Personally I will keep going the mingw-w64 route.

Thanks Carl. I suspected as much:)

[isuruf]

Update: Some of my PRs for flang are getting attention upstream and I'm hopeful that we'll see windows support upstream soon. (Maybe at the end of the summer if I find time)

[matthew-brett]

@isuruf - any progress with Flang / Windows?

[isuruf]

flang-compiler/flang-driver#70 was merged. There are more under review https://github.com/flang-compiler/flang/pulls/isuruf