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

[Ryan Schmidt]

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.

> 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, 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.

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 -- which I believe is the reason gconf is now failing to build:

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

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.


>> 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.