Bug #122158 for ExtUtils-F77: RFE: provide overrides for incorrect assumptions

Wed Jun 21 15:41:53 2017 djerius [...] cpan.org - Ticket created

Subject:

RFE: provide overrides for incorrect assumptions

ExtUtils::F77 can't handle all of the corner cases, although it tries. For example, I've discovered OSX systems where gfortran is only available as gfortran-mp-4.X (choose your X), with no link made to gfortran, so it isn't found. Some ideas on how to deal with this: * Have a system for overriding some of the assumptions via environment variables (in addition to possible arguments passed to import()). * Create a cache of the "proper" values upon installation of ExtUtils::F77, to eliminate the need to set the environment variables. That would lead to things being out of sync if one upgraded compilers. * If the code were refactored into system specific modules with ExtUtils::F77 just being a dispatcher, it would be possible to create a plugin system which would allow local rules for selecting the compiler which would be more sophisticated than replacing a single value (e.g., using the latest version of gfortran-mp-4.X, or noticing when cached versions were no longer the latest one). I like the last the best, but things would have to be carefully done to prevent breakage. Or, this might be the time to freeze ExtUtils::F77 and transition to a newer ExtUtils::Fortran distribution. Any thoughts? Diab

Wed Jun 21 19:36:49 2017 karlglazebrook [...] mac.com - Correspondence added

Subject:	Re: [rt.cpan.org #122158] RFE: provide overrides for incorrect assumptions
Date:	Thu, 22 Jun 2017 08:36:17 +1000
To:	bug-ExtUtils-F77 [...] rt.cpan.org
From:	Karl Glazebrook <karlglazebrook [...] mac.com>

My thoughts are: I am happy to take small patches to EU::F77 but would not have the time to do a big refactor. It might be impossible, it really needs a development team that have access to a wide variety of test systems. I think I am the only developer. For now I would take the view that people living in corners should expect to be inconvenienced :) Karl Show quoted text

> On 22 Jun 2017, at 5:41 am, Diab Jerius via RT <bug-ExtUtils-F77@rt.cpan.org> wrote: > > Wed Jun 21 15:41:53 2017: Request 122158 was acted upon. > Transaction: Ticket created by DJERIUS > Queue: ExtUtils-F77 > Subject: RFE: provide overrides for incorrect assumptions > Broken in: (no value) > Severity: Wishlist > Owner: Nobody > Requestors: djerius@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=122158 > > > > ExtUtils::F77 can't handle all of the corner cases, although it tries. For example, I've discovered OSX systems where gfortran is only available as gfortran-mp-4.X (choose your X), with no link made to gfortran, so it isn't found. > > Some ideas on how to deal with this: > > * Have a system for overriding some of the assumptions via environment variables (in addition to possible arguments passed to import()). > > * Create a cache of the "proper" values upon installation of ExtUtils::F77, to eliminate the need to set the environment variables. That would lead to things being out of sync if one upgraded compilers. > > * If the code were refactored into system specific modules with ExtUtils::F77 just being a dispatcher, it would be possible to create a plugin system which would allow local rules for selecting the compiler which would be more sophisticated than replacing a single value (e.g., using the latest version of gfortran-mp-4.X, or noticing when cached versions were no longer the latest one). > > I like the last the best, but things would have to be carefully done to prevent breakage. Or, this might be the time to freeze ExtUtils::F77 and transition to a newer ExtUtils::Fortran distribution. > > Any thoughts? > > Diab

Wed Jun 21 19:36:50 2017 The RT System itself - Status changed from 'new' to 'open'

Mon Jun 26 17:34:21 2017 devel.chm.01 [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #122158] RFE: provide overrides for incorrect assumptions
Date:	Mon, 26 Jun 2017 17:34:06 -0400
To:	bug-ExtUtils-F77 [...] rt.cpan.org
From:	Chris Marshall <devel.chm.01 [...] gmail.com>

I hate to sound non-optimal but given the lack of multiple developers using fortran and perl, it might be simplest to add some fixes for your specific problem. As the current maintainer, I would not be offended if you were interested in taking over this module. That said, maybe an Alien::Fortran module might be a better place for a more robust implementation. Cheers, Chris On Wed, Jun 21, 2017 at 3:41 PM, Diab Jerius via RT < bug-ExtUtils-F77@rt.cpan.org> wrote: Show quoted text

> Wed Jun 21 15:41:53 2017: Request 122158 was acted upon. > Transaction: Ticket created by DJERIUS > Queue: ExtUtils-F77 > Subject: RFE: provide overrides for incorrect assumptions > Broken in: (no value) > Severity: Wishlist > Owner: Nobody > Requestors: djerius@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=122158 > > > > ExtUtils::F77 can't handle all of the corner cases, although it tries. > For example, I've discovered OSX systems where gfortran is only available > as gfortran-mp-4.X (choose your X), with no link made to gfortran, so it > isn't found. > > Some ideas on how to deal with this: > > * Have a system for overriding some of the assumptions via environment > variables (in addition to possible arguments passed to import()). > > * Create a cache of the "proper" values upon installation of > ExtUtils::F77, to eliminate the need to set the environment variables. That > would lead to things being out of sync if one upgraded compilers. > > * If the code were refactored into system specific modules with > ExtUtils::F77 just being a dispatcher, it would be possible to create a > plugin system which would allow local rules for selecting the compiler > which would be more sophisticated than replacing a single value (e.g., > using the latest version of gfortran-mp-4.X, or noticing when cached > versions were no longer the latest one). > > I like the last the best, but things would have to be carefully done to > prevent breakage. Or, this might be the time to freeze ExtUtils::F77 and > transition to a newer ExtUtils::Fortran distribution. > > Any thoughts? > > Diab >

Tue Jun 27 10:20:38 2017 djerius [...] cpan.org - Correspondence added

On Mon Jun 26 17:34:21 2017, devel.chm.01@gmail.com wrote: Show quoted text

> I hate to sound non-optimal but given the lack of multiple developers > using > fortran and perl, it might be simplest to add some fixes for your > specific > problem. As the current maintainer, I would not be offended if you > were > interested in taking over this module. > > That said, maybe an Alien::Fortran module might be a better place for > a > more robust implementation. > > Cheers, > Chris >

As a reply to both Karl and you, I recognize that there's a lot of legacy knowledge embedded in this, and that developer time is limited. My main purpose in filing the RFE was to make sure that there weren't already plans afoot. I looked at tweaking the current code, but I'd rather not risk breaking things. I think a new module is a better path forward, and will try to find some tuits. My main drive is to get PDL (and PGPLOT of all things) to more easily install on random OS X boxes, as fortran isn't a native compiler. There doesn't seem to be a generic compiler discovery framework in Perl to work with (ExtUtils::HasCompiler seems C/C++ oriented). I'll be pondering on this for a bit. Thanks for your response! Diab

Tue Jun 27 17:17:29 2017 karlglazebrook [...] mac.com - Correspondence added

Subject:	Re: [rt.cpan.org #122158] RFE: provide overrides for incorrect assumptions
Date:	Wed, 28 Jun 2017 07:17:15 +1000
To:	bug-ExtUtils-F77 [...] rt.cpan.org
From:	Karl Glazebrook <karlglazebrook [...] mac.com>

Good luck with that. Yes I agree a new module would be the way to go if you want to put together a ‘proper compiler discovery framework’. EU::F77 is basically a series of hacks and rules-of-thumb layered over each over since the 1990s. Karl Show quoted text

> On 28 Jun 2017, at 12:20 am, Diab Jerius via RT <bug-ExtUtils-F77@rt.cpan.org> wrote:

> > As a reply to both Karl and you, I recognize that there's a lot of legacy knowledge embedded in this, and that developer time is limited. My main purpose in filing the RFE was to make sure that there weren't already plans afoot. > > I looked at tweaking the current code, but I'd rather not risk breaking things. I think a new module is a better path forward, and will try to find some tuits. My main drive is to get PDL (and PGPLOT of all things) to more easily install on random OS X boxes, as fortran isn't a native compiler. > > There doesn't seem to be a generic compiler discovery framework in Perl to work with (ExtUtils::HasCompiler seems C/C++ oriented). I'll be pondering on this for a bit. > > Thanks for your response! > > Diab