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 is 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

[jeremyhu (Jeremy Huddleston Sequoia)]

Sorry, r110107 was not supposed to include that change to py-obspy.

[petrrr]

No problem. It's solved I guess ;-) Actually the updated compiler handling seemed to have resolved an other open issue.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, I pushed r110118 about half an hour ago. I blame late night hacking. I accidentally committed all the changes in my python directory when I just wanted two of the ports. Luckily this was the only fallout as I was still in the process of editing the Portfile. The other change in that commit was in the middle of testing, and ended up working, so it just has a weird svn log now. Oh well.

Thanks for catching this quickly. The fact that someone hit this so quickly means the ports are likely well used, so it's a good thing I'm making these changes.