[107528] trunk/dports/textproc/intltool/Portfile

[Ryan Schmidt]

On Jul 4, 2013, at 03:04, Jeremy Huddleston Sequoia wrote:

> It likely was one one the 180 that had it missing.  The issue was that it was checking /opt/local/bin/perl which was 5.16 and didn’t have the XML module, so the configure check failed.

Precisely.


> Assuming intltool and perl5 are built with the same variants, then the default check will succeed after my changes to intltool (whereas they would fail without my changes to intltool).  All this Portfile nonsense to autoreconf is to support the situation where someone builds perl5 with a differnet perl variant than intltool.
> 
>> Changing the perl used by intltool doesn't fix anything by itself, it
>> just shifts the problem from "setting perl5 to anything but 5.12 causes
>> problems" to "setting perl5 to anything but 5.16 causes problems”.
> 
> Eh... not really... it shifts it to “having perl5 and intltool not match variants causes problems” which is much less likely.  Hell, I’d be in support of just saying that you can’t switch +perl variants like we say you can’t toggle +universal.  Then we could just remove all the fuss in the other Portfiles.

We don't say that you can't toggle +universal. It's quite normal for someone to install ports without universal, and then later need to install something universal, which MacPorts handles transparently by automatically rebuilding any needed dependencies universal as well. Going the other way (getting ports to be non-universal, after having installed some universal) is more difficult, however.


On Jul 4, 2013, at 03:38, Jeremy Huddleston Sequoia wrote:

> Personally, I’d prefer a perlvariants PortGroup (and one for python too) to handle these variants.

How would such a portgroup work? How would the portgroup know what tasks the port wants to do in such variants?


> That being said, I’m not that dead set on that, but there is specific benefit from having the variant in intltool (because of that braindead autoconf macro).  If the group decides that it’s ok to just require that intltool and perl5 always match variant, that would be the best solution as then we’d need to do *nothing* in ports that depend on intltool.

I don't know how we would enforce the idea that the intltool and perl5 variants should match.

I consider it to be likely that a user would install a port that happens to install intltool (with its default perl5_12 variant), which installs perl5.12. Sometime later, the user is actually interested in using perl, and installs perl5+perl5_16. There's no existing mechanism in MacPorts that would prevent that.


I'm not clear whether the intltool port currently relies on the existence of the perl5 port, but if it does, then I don't think that's a good idea, because I'd really like for the perl5 port to be deleted and replaced with the "port select" mechanism:

https://trac.macports.org/ticket/29763