py-obspy @0.8.4_0: update compiler variants

[petrrr]

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?

[larryv (Lawrence Velázquez)]

Replying to 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.

[petrrr]

Replying to larryv@…:

Replying to 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.

[petrrr]

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.

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

[larryv (Lawrence Velázquez)]

Replying to 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.

[petrrr]

Well, that exactly was my doubt about. Thanks for this clarification!

I update the diff file and revert to the behaviour the port had before r110107. I intentionally use a second if clause (as I expect further changes if a compiler ports group should become available), but feel free to change this;

[petrrr]

Updated diff to the Portfile