Opened 13 years ago

Closed 7 years ago

#30937 closed enhancement (worksforme)

intltool @0.40.6_1 Enhancement to support perl5 variants

Reported by: ccarey@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.0.1
Keywords: haspatch Cc: drkp (Dan Ports), nonstop.server@…, ryandesign (Ryan Carsten Schmidt), raimue (Rainer Müller), cooljeanius (Eric Gallager)
Port: intltool

Description

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.

Attachments (1)

Portfile-intltool.diff (1.7 KB) - added by ccarey@… 13 years ago.
Patch to add perl variants to intltool

Download all attachments as: .zip

Change History (20)

Changed 13 years ago by ccarey@…

Attachment: Portfile-intltool.diff added

Patch to add perl variants to intltool

comment:1 Changed 13 years ago by ccarey@…

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

comment:2 Changed 13 years ago by drkp (Dan Ports)

Cc: dports@… added

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

comment:3 Changed 12 years ago by nonstop.server@…

Cc: nonstop.server@… added

Cc Me!

comment:4 in reply to:  2 Changed 12 years ago by 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.

Version 1, edited 12 years ago by nonstop.server@… (previous) (next) (diff)

comment:5 Changed 12 years ago by raimue (Rainer Müller)

I added the INTLTOOL_PERL variable to port libsoup in r99246.

comment:6 in reply to:  5 Changed 12 years ago by raimue (Rainer Müller)

I added the INTLTOOL_PERL variable to port gegl in r99259.

comment:7 Changed 12 years ago by 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?

comment:8 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

intltool-1.0.tcl:

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

?

comment:9 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

Cc Me!

comment:10 Changed 12 years ago by raimue (Rainer Müller)

Cc: raimue@… added

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.

comment:11 in reply to:  10 Changed 12 years ago by 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.

comment:12 Changed 12 years ago by raimue (Rainer Müller)

Fixed zenity in r100455.

comment:13 Changed 12 years ago by 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.

comment:14 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Any comment on the two-line portgroup proposed earlier?

comment:15 Changed 12 years ago by jmroot (Joshua Root)

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

comment:16 Changed 12 years ago by 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.

comment:17 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:18 Changed 11 years ago by 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.

comment:19 Changed 7 years ago by raimue (Rainer Müller)

Resolution: worksforme
Status: newclosed

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

Note: See TracTickets for help on using tickets.