Opened 7 years ago

Closed 7 years ago

#40249 closed enhancement (fixed)

py-obspy @0.8.4_0: update compiler variants

Reported by: petrrr Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: jeremyhu (Jeremy Huddleston Sequoia)
Port: py-obspy

Description (last modified by ryandesign (Ryan Schmidt))

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?

Attachments (1)

Portfile.diff (2.0 KB) - added by petrrr 7 years ago.
Updated diff to the Portfile

Download all attachments as: .zip

Change History (10)

comment:1 in reply to:  description ; Changed 7 years ago by larryv (Lawrence Velázquez)

Cc: jeremyhu@… added; Jeremy Huddleston Sequoia <jeremyhu@…> removed
Summary: py-obspy: update compiler variantspy-obspy @0.8.4_0: update compiler variants
Type: updateenhancement

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.

comment:2 in reply to:  1 Changed 7 years ago by 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.

comment:3 Changed 7 years ago by 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?

Last edited 7 years ago by petrrr (previous) (diff)

comment:4 in reply to:  3 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by 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;

Changed 7 years ago by petrrr

Attachment: Portfile.diff added

Updated diff to the Portfile

comment:6 Changed 7 years ago by ryandesign (Ryan Schmidt)

Description: modified (diff)

comment:7 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:8 Changed 7 years ago by petrrr

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

Last edited 7 years ago by petrrr (previous) (diff)

comment:9 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.