peekabot: update to version 0.7.2 + bugfixes

[staffan@…]

In addition to updating to the latest released version of the package, the attached patch (diff'd relative trunk/dports/science/) does a few other things:

• Make it build on x86_64 by forcing a 32-bit build of the parts (the server/GUI) that rely on broken dependencies; FLTK doesn't compile for x86_64, and as far as I can tell it likely never will (see #21054).
• Switch to using xercesc3 over xercesc, since the universal variant of xercesc doesn't build (#23255).
• Add a workaround for a mysterious memory error.
• Split the peekabot port into two ports - one for the server (GUI) and one for the client library. This allows us to still build in client library for the native architecture, thus not forcing programs using peekabot to be compiled in 32-bit mode. It doesn't seem like it's possible to make a port containing a mix of 32-bit and 64-bit stuff, thus the split.

Ideally, I would want the old "peekabot" port to be a metapackage that installs both the peekabot-client and peekabot-server ports, but there doesn't seem to be any way to do that, or at least I cannot figure it out. Instead, I opted to simply remove the old port since its broken -- it don't know if that will cause any problems for people who already have it installed??

I am the port and upstream maintainer.

[staffan@…]

New patch, including a meta-package.

[staffan@…]

I attached a modified patch that includes a meta-package (peekabot), modeled after the xorg-fonts meta-package, that installs both the client and the server packages.

[ryandesign (Ryan Carsten Schmidt)]

Instead of setting both distfiles and worksrcdir, it is simpler to just set distname.

You should almost never override the fetch or checksum phases. Instead just clear the distfiles variable.

In peekabot-server, instead of manually handling build_arch, you should just use set "supported_archs i386 ppc".

Would it be reasonable for peekabot-server to have a dependency on peekabot-client? If so, I might suggest instead of peekabot being a metaport that installs both peekabot-client and peekabot-server, how about having peekabot indicate that it has been "replaced_by peekabot-server"? I think this will work better for any who already have the old full peekabot port installed, but I will test it out.

[staffan@…]

Thanks for the review! I'll post an updated patch when I get back home after the weekend.

It's actually useful to have the client and server in separate packages that do not depend on each other since you sometime need only just one part, so I would strongly prefer to keep them independent. And except for running configure twice there's no wasted build time in having it split up. What problems do you foresee with the meta-package approach?

[staffan@…]

Updated patch incorporating fixes from the review.

[staffan@…]

New patch attached, with post-review fixes. It still uses the meta-package approach.

[nerdling (Jeremy Lavergne)]

Committed in r69058 and r69059.

[staffan@…]

The Portfile committed in r69058 for peekabot-server has the Portfile for peekabot-client appended at the end; it does not build. Just remove the extraneous stuff and it should work again (I'll attach a patch as well).

[staffan@…]

Fix errors introduces in r69058.

[wsiegrist@…]

Fixed in r69065.

[ryandesign (Ryan Carsten Schmidt)]

Replying to staffan@…:

What problems do you foresee with the meta-package approach?

This one: #25721.