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

[Jeremy Huddleston Sequoia]

On Jul 3, 2013, at 11:57 PM, Joshua Root <jmr at macports.org> wrote:

> On 2013-7-4 16:42 , Jeremy Huddleston Sequoia wrote:
>> 
>> On Jul 3, 2013, at 11:18 PM, Joshua Root <jmr at macports.org> wrote:
>> 
>>> We don't have to keep perl5.12 around either way. As I mentioned in
>>> #30937, we could do something like:
>>> 
>>> configure.env-append INTLTOOL_PERL=[exec cat
>>> ${prefix}/share/intltool/perl_path]
>> 
>> What purpose would it serve other than to be consumed by other Portfiles for the sole benefit of passing a configure check that shouldn’t be there in the first place?  If we have to edit the Portfiles, I’d rather add ‘use_autoreconf yes’ as the proper fix than add a new hack.
> 
> It achieves the same result as autoreconf without the extra dependencies.
> 
>>> But if you're volunteering to remove the check in all the ports that use
>>> intltool (221 according to 'port echo depends:intltool', maybe not all
>>> use autoconf but probably most do), I guess that's fine. :-)
>> 
>> I’m just planning on fixing the ones that have determined that they have some need for INTLTOOL_PERL to be defined (there are about 27 left now, below) because those are the ones that definitely won’t work with a non-default perl variant in the current state.  The other ~200 ports didn’t set it to begin with, and they’re no worse off in the current state than they were before the change.
> 
> The set of ports that set INTLTOOL_PERL is only a subset of the ones
> with the problem. It was just added as people had builds fail because of
> its absence.
> 
> Are you sure you were actually seeing problems with the ones that did
> have the INTLTOOL_PERL workaround and not the ones that didn't? That
> makes no sense to me, I would expect it to be the other way round.

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.

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.

>> I’m doing a complete rebuild with +perl5_16 (and also perl5.12 set to error out to ensure it doesn’t get accidentally pulled in) to see what I run into.  I’ll fix issues as I run into them with my port set.  After that, I’ll fix the remainder.
> 
> Well if perl5.12 is deliberately broken, then of course having it
> hardcoded won't work...

Exactly.  That’s the point.  I don’t want it on my system, so dependents need to be fixed.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130704/0ef965e4/attachment.p7s>