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

[Rainer Müller]

On 2013-07-02 07:30, Jeremy Huddleston Sequoia wrote:
>> I am not sure that we want to do this.
> 
> Without doing this, it's nearly impossible to build ports if you have any non-default perl selected.
> 
> With this change, everything in my default set (which includes 2249 ports) built with +perl5_16.

If ports failed before, for what reason did they fail?

If they were missing p5.16-xml-parser or other p5.16-* modules it's due
to the fact that they were picking up the wrong perl. Those ports need
to be fixed by setting INTLTOOL_PERL, not intltool itself.

>> Doesn't this now necessitate that all ports using intltool immediately acquire the same variants,
> 
> Why?  This port provides intltool, not perl modules.

I think you are still unaware of the fact that the default configure
macro does not simply call 'intltool', but a perl interpreter with the
intltool script as argument. This makes a huge difference as it picks up
*any* perl interpreter on your system by default, not necessarily the
one intltool was built with. This could well be a perl installation that
misses the various perl modules required to run intltool that are listed
in the Portfile, leading to build failures.

We countered this by setting INTLTOOL_PERL in dependent ports which
forces this macro to use a certain version of perl. At the time this was
introduced, perl5.12 was chosen as the single version to use for that
purpose.

The alternative would be to patch lots of configure scripts not to use a
perl interpreter, but just call ${prefix}/bin/intltool. Compared to
setting a single environment variable, this is tedious.

>> and also ensure using the active_variants portgroup that the variant selected in each port is the same as the variant used in the intltool port?
> 
> Again, why would that be?

I need to use the right version of perl to run intltool, the one that
intltool declares a dependency on.

>> It was much more straightforward when the intltool port (and any other port that uses perl or perl modules) simply used perl 5.12.
> 
> Yes, straight forward so long as you used +perl5_12.  If you used a non-default perl, you were out of luck.

Before this change, intltool always used perl version 5.12 no matter
what perl5 +perl5.XY you installed. Dependents were fixed by setting
INTLTOOL_PERL to use ${prefix}/bin/perl5.12 to run intltool.

If I now install intltool +perl5.16, every dependent of intltool is
broken. They are still hardcoded to use ${prefix}/bin/perl5.12 that may
not even be installed anymore.

If I want to fix that, how would I know which perl to use? It has to be
the same as intltool was installed with, but that can now be changed by
the user with a variant.

So what am I supposed to do with the ports depending on intltool now?

Rainer