#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 | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): Replying to [comment:1 larryv@…]:

Replying to [ticket:40249 Peter.Danecek@…]:

...

**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?

I don’t see why this should be necessary. MacPorts base already passes variant selections to dependencies.

Well I ended up with something like this: {{{ [radegast:ports/python/py-obspy] petr% port installed | grep obspy py-obspy @0.8.4_1+gcc48 (active) py26-obspy @0.8.4_1+gcc47 (active) py27-obspy @0.8.4_1+gcc45 (active) }}} So I assumed, it would not work. From documentation I concluded it would not be even possible to depend on specific variants, so I was thinking to revert to the previous behaviour. -- Ticket URL: <https://trac.macports.org/ticket/40249#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X

#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 | ------------------------------+-------------------------------- Comment (by larryv@…): Replying to [comment:3 Peter.Danecek@…]:

Okay, I see now how it would work. A port cannot depend on a specific variant of a port. So once it is already installed, the present version is kept. However, if it is not activated, the version with the correct variant is requested. In some way this makes sense.

Right. Variants are only passed if dependencies are to be activated.

But the above behaviour is quite ugly, inconsistent and misleading. So is there a way to avoid it?

Do not add variants to `py-obspy`. Users should not be installing it; they should be installing the Python-specific subports. -- Ticket URL: <https://trac.macports.org/ticket/40249#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X

#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

#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 | ------------------------------+-------------------------------- Comment (by Peter.Danecek@…): No problem. It's solved I guess ;-) -- Ticket URL: <https://trac.macports.org/ticket/40249#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X