pymol: update to svn 4024, add gcc48 variant, etc

[howarth@…]

The attached Portfile.diff and revised setup_py.diff patch updates pymol to the current svn revision 4024. It also adds support for the gcc48 variant and adopts the same approach as Fedora towards eliminating the use of the pymol_path symlink. The patch to setup.py is also adjusted to handle the changes in current svn regarding the prefix_path search by placing macports' directory first. Note that the breakage in the apsb tools plugin from the switch to tcl/tk 8.6 still exists and I am awaiting for a fix from the developer (if one exists for the current blt code).

[howarth@…]

revised pymol_shell.diff to work around radeon rendering issues

[howarth@…]

Updated proposed changes to add missing license field as well as add new apbs_tkinter.patch to fix apbstools plugin under tcl/tk 8.6.

[howarth@…]

setup_py.diff patch adjusted for pymol 1.6.0

[howarth@…]

apbs_tkinter.patch adjusted for pymol 1.6.0

[howarth@…]

apbs-psize.patch adjusted for pymol 1.6.0

[howarth@…]

patch to eliminate numerous clang warnings

[howarth@…]

Portfile.diff to update to pymol 1.6.0 with previous changes

[howarth@…]

The attached files include the previous changes but update the pymol packaging to build the new 1.6.0 release which has huge improvements on graphics cards whose performance (like Radeon X1600) was degraded severely in the 1.5.x releases.

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

slightly revised unified diff for pymol 1.6.0 based on maintainer's patches

[mojca (Mojca Miklavec)]

I fetched your patches and did some slight modifications:

• used a python PortGroup instead of the outdated/deprecated python26
• switched to python27, removed dependency on python (it should already be added by the PortGroup)
• also added the gcc49 variant
• the latest version in SVN doesn't use dependencies on gcc4x ports, so I also removed that from gcc48, even though I didn't test those options
• fixed a few offsets and "fuzzes" in the patches
• replaced tabs with spaces in some patches (I'm not sure how python handles mixtures of tabs and spaces, so just in case)
• adjusted some whitespace in the Portfile

I noticed that the version in SVN is now 4040, but I didn't dare to change that.

I didn't do any extensive testing of the port. If you agree with these changes, I'll commit them.

If you need to upload a large number of files next time, please do a unified diff like the one I attached:

svn co https://svn.macports.org/repository/macports/trunk/dports/science/pymol
cd pymol
# do your modifications
svn diff > output-file.patch

[mojca (Mojca Miklavec)]

Also: #38532 (which indicated PSF).

[howarth@…]

The changes in pymol-1.6.0.diff​ are fine. Don't forget to also commit the update to blt at ​https://trac.macports.org/ticket/40203 otherwise the APBS Tools plugin in pymol will crash under tcl/tk 8.6 when the "Choose Externally Generated PQR:" button is clicked in the PyMOL APBS Tools window.

[mojca (Mojca Miklavec)]

Thank you for pointing that out (next time it makes sense to provide a link to related tickets early enough).

Now - ouch, I don't understand a bit about the other ticket, so I feel a bit uncomfortable committing that one, even though the time is way past the maintainer timeout. I suggest asking on the developer mailing list.

Just a question: does the Tcl/Tk patch need to be committed before upgrading pymol? If the answer is no, I can commit pymol now. If not, I would really like to see someone else confirm the Tcl/Tk patch. Just a hint: it might help if you provide some links to the origin of the patch or discussion(s) about it in the other ticket.

[howarth@…]

Blt is a pretty much a nightmare. The upstream developer no longer works on it and basically wants to be left alone. One reason is that the package is incorrectly written to use many private data structures and calls in tcl/tk (which are simply hard coded into the blt sources from an ancient tcl/tk release). The proposed change in ​https://trac.macports.org/ticket/40203 resolves the tk side of this by replacing the out of date local declarations of private tk data structures and calls with those from the private headers of tcl/tk 8.6.0. Since MacPorts doesn't package the tcl/tk private headers, the proposed patch bundles these from the tcl/tk 8.6.0 sources for the blt build. Eventually someone needs to do the same for the tcl private header usage in blt (as it uses a number of data structure fields that are no longer used in tcl as of 8.5).

[howarth@…]

The blt fix doesn't have to be committed for pymol to build. The issue is that blt (as used in the APBS Tools plugin of pymol) is broken due to the switch to tcl/tk 8.6.0 in MacPorts. The private tk internals forked enough to break using blt in this context. You can easily see this by the following steps. 1) Install pymol using the pymol-1.6.0.diff changes. 2) execute pymol and select the APBS Tools plugin 2.1 menu item from the Plugin menu in pymol 3) when the APBS Tools window appears click on the "Choose Externally Generated PQR" button. This will crash pymol under the current blt. If you install the proposed blt packaging from ​https://trac.macports.org/ticket/40203 and repeat these steps, the file chooser will appear instead of pymol crashing.

[mojca (Mojca Miklavec)]

The main question is: do you prefer me to commit the new version of pymol now or do you prefer to wait until the issue with Tcl/Tk is solved?

[howarth@…]

Replying to mojca@…:

The main question is: do you prefer me to commit the new version of pymol now or do you prefer to wait until the issue with Tcl/Tk is solved?

I don't understand the question. There are no issues with Tcl/Tk and pymol. Blt has issues with Tcl/Tk (due to its own improper use of private header data structure and calls) but that issue is orthogonal to updating pymol. Please commit the changes in pymol-1.6.0.diff​.

[mojca (Mojca Miklavec)]

Committed in r110734.

[mojca (Mojca Miklavec)]

Just curious: is it possible to build pymol with Tcl with +corefoundation at all? The nasty issue is that now pymol and its dependencies (at least stimfit, but possibly others) all fail to build on the buildbot:

• ​https://build.macports.org/builders/buildports-lion-x86_64/builds/14039