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)
Change History (20)
Changed 13 years ago by ccarey@…
Attachment: | Portfile-intltool.diff added |
---|
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 follow-up: 4 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:4 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 37 ports have the INTLTOOL_PERL variable set in their Portfile:
./audio/gmpc/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12 ./audio/tagtool/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12 ./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/file-roller/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12 ./gnome/gconf/Portfile:configure.env INTLTOOL_PERL=${prefix}/bin/perl5.12 ./gnome/gnome-desktop/Portfile:configure.env-append 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/gnome-themes/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/nautilus/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12 ./gnome/oaf/Portfile: ac_cv_path_INTLTOOL_PERL=${prefix}/bin/perl5 \ ./gnome/zenity/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12 ./graphics/gegl/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12 ./graphics/gimp2/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12 ./graphics/inkscape/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12 ./net/avahi/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12 ./security/policykit/Portfile:configure.env-append INTLTOOL_PERL=${prefix}/bin/perl5.12 ./x11/gtk-engines2/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.
comment:5 follow-up: 6 Changed 12 years ago by raimue (Rainer Müller)
I added the INTLTOOL_PERL
variable to port libsoup in r99246.
comment:6 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)
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:10 follow-up: 11 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 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 anyperl
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: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: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: | new → closed |
As the discussion stalled, I assume we are fine with the current solution of forcing autoreconf for all ports that use intltool.
Patch to add perl variants to intltool