[MacPorts] #40249: py-obspy @0.8.4_0: update compiler variants

[MacPorts]

#40249: py-obspy @0.8.4_0: update compiler variants
------------------------------+--------------------------------
  Reporter:  Peter.Danecek@…  |      Owner:  macports-tickets@…
      Type:  enhancement      |     Status:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:
Resolution:                   |   Keywords:  haspatch
      Port:  py-obspy         |
------------------------------+--------------------------------
Description changed by ryandesign@…:

Old description:

> I updated compiler variant handling according to recipe:
> https://trac.macports.org/wiki/PortfileRecipes#fortran
>
> This update should solves the following issues:
> 1. Commit r110107 broke this port as the port requires Fortran; I
> personally was not able to build with that commit. But even if it
> installs somewhere, it is very probably not functional.
> 2. The new compiler handling seems to have resolved some subtile
> issue/incompatibility for specific combinations of `python26` and various
> `gcc` versions.
>
> I therefore bump the revision number as well, because (a) it may have
> been installed from the nonfunctional version, (b) it solves the issue 2
> and therefore should be updated/rebuild.
>
> I tested under Mountain Lion with for Python 2.6 and 2.7, with all
> compilers except `gcc49`, which I cannot install due to conflicting
> `libgcc`.
>
> **Some doubt:**
> Before the variants were available only for the subports. It was inside
> the `if {${subport} != ${name}}` block. However, it probably would make
> sense to have variants for the "superport" as well. This would than pass
> the variant to the default subport. Now, this constrain probably is
> present.
>
> So how would this be implemented correctly?

New description:

 I updated compiler variant handling according to recipe:
 PortfileRecipes#fortran

 This update should solves the following issues:
 1. Commit r110107 broke this port as the port requires Fortran; I
 personally was not able to build with that commit. But even if it installs
 somewhere, it is very probably not functional.
 2. The new compiler handling seems to have resolved some subtile
 issue/incompatibility for specific combinations of `python26` and various
 `gcc` versions.

 I therefore bump the revision number as well, because (a) it may have been
 installed from the nonfunctional version, (b) it solves the issue 2 and
 therefore should be updated/rebuild.

 I tested under Mountain Lion with for Python 2.6 and 2.7, with all
 compilers except `gcc49`, which I cannot install due to conflicting
 `libgcc`.

 **Some doubt:**
 Before the variants were available only for the subports. It was inside
 the `if {${subport} != ${name}}` block. However, it probably would make
 sense to have variants for the "superport" as well. This would than pass
 the variant to the default subport. Now, this constrain probably is
 present.

 So how would this be implemented correctly?

--

-- 
Ticket URL: <https://trac.macports.org/ticket/40249#comment:6>
MacPorts <http://www.macports.org/>
Ports system for OS X