intltool @0.40.6_1 Enhancement to support perl5 variants

[ccarey@…]

The attached patch to intltool’s Portfile allows either Perl 5.8, 5.10, 5.12, or 5.14 to be a supported library dependency through the addition of variants with identical names to those for perl5. If no variant be specified when compiling intltool, then the default will be a Perl 5.12 library dependency, which leaves the unpatched behavior unchanged and mirrors the default variant of perl5 compilation.

[ccarey@…]

Patch to add perl variants to intltool

[ccarey@…]

A similar patch for help2man, #30938, should be applied and compiled first, since help2man is an ancestral dependency of intltool.

[drkp (Dan Ports)]

Hmm. At the moment, it's important that we keep intltool using perl5.12 only. Because autoconf for intltool-using programs looks at build-time for a version of perl to use for intltool, we have to set INTLTOOL_PERL to the perl binary that we installed intltool for, in all the ports that use it. (See, for example, #32425).

If we added support for building intltool with a different perl version, we'd have to change those ports to figure out which one was used to build the installed intltool, and set INTLTOOL_PERL accordingly. That might be the way to go, but it'll require some effort...

[nonstop.server@…]

Cc Me!

[nonstop.server@…]

Replying to dports@…:

Using this code in a pre-configure block to figure out what version of perl was used for intltool at build-time works very well.
I was able to install port VLC and all its dependencies this way using perl5.16 only.

pre-configure {
    # the perl executable should be the one explicitly required by intltool
    if { [file exists "${prefix}/bin/intltool-prepare"] == 1 } {
        set channel [open "${prefix}/bin/intltool-prepare"]
        set line [gets ${channel}]
        close ${channel}
        configure.env-append INTLTOOL_PERL=[string trim [string trimright \
            [string trimleft ${line} #!] -w]]
    } else {
        configure.env-append INTLTOOL_PERL=${prefix}/bin/perl${perl5.major}
    }
}

I added PortGroup perl5 to some ports (including non-perl) to get access to variable perl5.major averting the need to set the variable by hand, but I'm not sure if this is acceptable for non-perl ports.

The following 27 ports have the INTLTOOL_PERL variable set in their Portfile:

./databases/libgda3/Portfile:configure.env-append  INTLTOOL_PERL=${configure.perl}
./databases/libgda4/Portfile:configure.env-append  INTLTOOL_PERL=${configure.perl}
./databases/libgda5/Portfile:configure.env-append  INTLTOOL_PERL=${configure.perl}
./devel/shared-mime-info/Portfile:configure.env-append  INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/gconf/Portfile:configure.env   INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/gnome-doc-utils/Portfile:configure.env-append  INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/gnome-keyring/Portfile:configure.env   INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/gnome-mime-data/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/libbonobo/Portfile:configure.env-append  INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/libbonoboui/Portfile:configure.env   INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/libgnomecanvas/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/libgnomeui/Portfile:configure.env   INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/libgsf/Portfile:configure.env           INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/libsoup/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12
./gnome/oaf/Portfile:                ac_cv_path_INTLTOOL_PERL=${prefix}/bin/perl5 \
./graphics/gegl/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12
./graphics/inkscape/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12
./security/policykit/Portfile:configure.env-append  INTLTOOL_PERL=${prefix}/bin/perl5.12
./x11/gtkspell2/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12
./x11/xkeyboard-config/Portfile:configure.env-append    INTLTOOL_PERL=${prefix}/bin/perl5.12
./xfce/xfce-utils/Portfile:                INTLTOOL_PERL=${prefix}/bin/perl5.12
./xfce/xfce4-appfinder/Portfile:configure.env   INTLTOOL_PERL=${prefix}/bin/perl5.12
./xfce/xfce4-session/Portfile:configure.env   INTLTOOL_PERL=${prefix}/bin/perl5.12
./xfce/xfce4-settings/Portfile:configure.env   INTLTOOL_PERL=${prefix}/bin/perl5.12
./xfce/xfdesktop/Portfile:configure.env   INTLTOOL_PERL=${prefix}/bin/perl5.12
./xfce/xfprint/Portfile:configure.env   INTLTOOL_PERL=${prefix}/bin/perl5.12
./xfce/xfwm4/Portfile:configure.env   INTLTOOL_PERL=${prefix}/bin/perl5.12

Hopefully this will help to get intltool and intltool-using programs separated from a specific perl version.

[raimue (Rainer Müller)]

I added the INTLTOOL_PERL variable to port libsoup in r99246.

[raimue (Rainer Müller)]

I added the INTLTOOL_PERL variable to port gegl in r99259.

[raimue (Rainer Müller)]

Fixed gtkspell2 in r99771, inkscape in r99772.

Maybe it's time for a PortGroup to avoid changing each dependent port once again when the version of perl used for intltool changes?

[ryandesign (Ryan Carsten Schmidt)]

intltool-1.0.tcl:

depends_build-append port:intltool
configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12

?

[ryandesign (Ryan Carsten Schmidt)]

Cc Me!

[raimue (Rainer Müller)]

Fixed gimp2 in r100415.

An alternative and maybe the better way to fix the issue would be to change ${prefix}/share/aclocal/intltool.m4 not to detect any perl binary, but use the path ${prefix}/bin/perl5.XY that was used when building intltool. This would be a patch to the port intltool itself and would allow to use the variant approach originally suggested in this ticket.

[raimue (Rainer Müller)]

Replying to raimue@…:

An alternative and maybe the better way to fix the issue would be to change ${prefix}/share/aclocal/intltool.m4 not to detect any perl binary, but use the path ${prefix}/bin/perl5.XY that was used when building intltool. This would be a patch to the port intltool itself and would allow to use the variant approach originally suggested in this ticket.

I looked into this approach, but unfortunately this would not remove all changes from the port using intltool. The distributed software might already ship a copy of the macros from intltool.m4 as a local version in aclocal.m4. In this case, it is still required to specify the INTLTOOL_PERL variable in the Portfile or, as an alternative, regenerate the aclocal.m4 using something like autogen.sh or autoreconf.

Forcing a regenerate of the autotools related files is more intrusive than simply specifying the required environment variable, so I have to acknowledge that my proposal would not be the better fix.

[raimue (Rainer Müller)]

Fixed zenity in r100455.

[jmroot (Joshua Root)]

You're right that the macro is fundamentally broken, but it's already baked into countless configure scripts. Maybe we could at least have intltool install a file indicating which perl it uses, so the dependents can do something like:

configure.env-append INTLTOOL_PERL=[exec cat ${prefix}/share/intltool/perl_path]

which then allows the version used to be updated without breaking everything.

[ryandesign (Ryan Carsten Schmidt)]

Any comment on the two-line portgroup proposed earlier?

[jmroot (Joshua Root)]

Not a lot of point since using the PortGroup takes one line anyway and reduces clarity.

[ryandesign (Ryan Carsten Schmidt)]

It would embody the "don't repeat yourself" principle and give us a single place where the perl version number can be changed when the time comes.

[cooljeanius (Eric Gallager)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

There's no need to use INTLTOOL_PERL at all, anywhere. All setting it does is allow you to pass that configure check. It has absolutely no baring on the built product because intltool has the correct path in its #!

r107542 removes it from intltool.m4

Just remove the envvar from Ports and have them autoreconf to pickup the fixed macro.

[raimue (Rainer Müller)]

As the discussion stalled, I assume we are fine with the current solution of forcing autoreconf for all ports that use intltool.