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

[Jeremy Huddleston Sequoia]

On Jul 4, 2013, at 6:19 AM, Ryan Schmidt <ryandesign at macports.org> wrote:

> 
> On Jul 4, 2013, at 01:42, Jeremy Huddleston Sequoia wrote:
> 
>> On Jul 3, 2013, at 11:18 PM, Joshua Root wrote:
>> 
>>> On 2013-7-4 01:11 , Jeremy Huddleston Sequoia wrote:
>>>> 
>>>> On Jul 3, 2013, at 12:53 AM, Joshua Root <jmr at macports.org> wrote:
>>>> 
>>>>> Yes, we should try to get a proper fix in upstream, but running
>>>>> autoreconf isn't any easier than adding this line.
>>>> 
>>>> Slightly, but it's more correct and doesn't force us to keep perl5.12 around just to satisfy a buggy configure check.
>>> 
>>> 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
> 
> As far as I understand Joshua's proposal, that is the sole purpose it would serve.
> 
>> that shouldn’t be there in the first place?
> 
> I cannot verify whether the check should be there, but the developers put it there, so they presumably had a reason.

Maybe they did at the time, but that is no longer relevant.

https://bugs.launchpad.net/intltool/+bug/1197875

>> If we have to edit the Portfiles, I’d rather add ‘use_autoreconf yes’ as the proper fix than add a new hack.
> 
> You've patched the intltool port to remove this check in its m4 file. Have you sent this patch to the developers,

https://bugs.launchpad.net/intltool/+bug/1197875

> and have they agreed to make this change upstream? I don't want to get us into a situation where we're forever maintaining this difference in MacPorts.

How is this any worse than what we’re doing now?  Before this change, we had 180 broken ports because they did nothing, and ~30 ports which hacked around that brokenness by setting INTLTOOL_PERL.  All those ports would need to be updated at the same time as intltool.

Now, those 180 broken ports “just work” as long as intltool and perl5 are built with the same variants.  If we want to require that those variants match, then you DON’T need to do anything (except remove the INTLTOOL_PERL setting in those other ports).  If you want to support perl5 and intltool not using the same perl version, then you need to fix intltool.m4 ... 

> A problem with running autoreconf is it takes some time, and it can require adding dependencies that would not otherwise be needed -- not just on autoconf, automake and libtool, but also on other otherwise optional libraries

I’m not concerned about most of these.  They are almost always installed on users systems that build from source and they take almost no time to install.  If an actual optional library dependency is required (other than a package that just installs some m4 macros), then editing the configure script directly is probably the safer option.

> -- which I believe is the reason gconf is now failing to build:
> 
> https://trac.macports.org/ticket/39632

Yeah, this found a missing dependency which should’ve actually been there to begin with.

> I have in the past encountered ports where I wanted to autoreconf and simply could not figure out how to get it to run successfully, and had to resort to patching the configure script instead. Not sure if any of the ports that need intltool fall into this category.

There are a couple that I didn’t autoreconf simply because there were already patches to configure and Makefile.in files directly, and I didn’t want to bother fixing those to autoreconf instead.  I haven’t yet hit any that I couldn’t autoreconf.

>>> 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.
> 
> I presume the only reason the other ~200 ports didn't set it is because nobody found the problem yet, because most users do not use a different version of perl than the default. I think this (or a) fix is needed for all of the ports using intltool that use an autoconf-based configure script, which is probably most of them if I had to guess.

As long as perl5 and intltool are built with the same variant, nothing is needed.

If you want to support mixing versions there, then you MUST fix this at the level of intltool.m4 (or do some hackery to figure out what version of perl was used for intltool and pass it in as INTLTOOL_PERL) in every port.


-------------- 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/606a7d01/attachment-0001.p7s>