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

[Jeremy Huddleston Sequoia]

On Jul 4, 2013, at 6:29 AM, Ryan Schmidt <ryandesign at macports.org> wrote:

> On Jul 4, 2013, at 03:04, Jeremy Huddleston Sequoia wrote:
> 
>> It likely was one one the 180 that had it missing.  The issue was that it was checking /opt/local/bin/perl which was 5.16 and didn’t have the XML module, so the configure check failed.
> 
> Precisely.
> 
> 
>> Assuming intltool and perl5 are built with the same variants, then the default check will succeed after my changes to intltool (whereas they would fail without my changes to intltool).  All this Portfile nonsense to autoreconf is to support the situation where someone builds perl5 with a differnet perl variant than intltool.
>> 
>>> Changing the perl used by intltool doesn't fix anything by itself, it
>>> just shifts the problem from "setting perl5 to anything but 5.12 causes
>>> problems" to "setting perl5 to anything but 5.16 causes problems”.
>> 
>> Eh... not really... it shifts it to “having perl5 and intltool not match variants causes problems” which is much less likely.  Hell, I’d be in support of just saying that you can’t switch +perl variants like we say you can’t toggle +universal.  Then we could just remove all the fuss in the other Portfiles.
> 
> We don't say that you can't toggle +universal. It's quite normal for someone to install ports without universal, and then later need to install something universal, which MacPorts handles transparently by automatically rebuilding any needed dependencies universal as well. Going the other way (getting ports to be non-universal, after having installed some universal) is more difficult, however.
> 
> 
> On Jul 4, 2013, at 03:38, Jeremy Huddleston Sequoia wrote:
> 
>> Personally, I’d prefer a perlvariants PortGroup (and one for python too) to handle these variants.
> 
> How would such a portgroup work? How would the portgroup know what tasks the port wants to do in such variants?

It would just handle the ugly framework, setting up the variant conflicts, etc.  From the client’s side, I’d just want to do

perlvariants.supported {5.12 5.14 5.16}
perlvariants.default   {5.12}
PortGroup   perlvariants 1.0

The PortGroup would setup perl5_12, perl5_14, and perl5_16 variants with +perl5_12 as a default variant.

It would set perlvariants.selected_version to our version and would set the configure.perl path.

The port itself would then handle it’s logic.  For example, the intltool port would use it like:

Index: Portfile
===================================================================
--- Portfile	(revision 107684)
+++ Portfile	(working copy)
@@ -3,6 +3,10 @@
 
 PortSystem      1.0
 
+perlvariants.supported {5.12 5.14 5.16}
+perlvariants.default   {5.12}
+PortGroup       perlvariant
+
 name            intltool
 version         0.50.2
 revision        2
@@ -35,35 +39,13 @@
 
 patchfiles      remove-intltool-perl-hack.patch
 
-# TODO: This perlver cruft should be done in the perl5 PortGroup
-if {[variant_isset perl5_8]} {
-    set perlver 5.8
-} elseif {[variant_isset perl5_10]} {
-    set perlver 5.10
-} elseif {[variant_isset perl5_14]} {
-    set perlver 5.14
-} elseif {[variant_isset perl5_16]} {
-    set perlver 5.16
-} else {
-    set perlver 5.12
-    default_variants +perl5_12
-}
-
-variant perl5_8 conflicts perl5_10 perl5_12 perl5_14 perl5_16 description {use perl 5.8} {}
-variant perl5_10 conflicts perl5_8 perl5_12 perl5_14 perl5_16 description {use perl 5.10} {}
-variant perl5_12 conflicts perl5_8 perl5_10 perl5_14 perl5_16 description {use perl 5.12} {}
-variant perl5_14 conflicts perl5_8 perl5_10 perl5_12 perl5_16 description {use perl 5.14} {}
-variant perl5_16 conflicts perl5_8 perl5_10 perl5_12 perl5_14 description {use perl 5.16} {}
-
 depends_lib-append \
-                port:perl${perlver} \
-                port:p${perlver}-xml-parser \
-                port:p${perlver}-getopt-long \
-                port:p${perlver}-pathtools \
-                port:p${perlver}-scalar-list-utils
+                port:perl${perlvariants.selected_version} \
+                port:p${perlvariants.selected_version}-xml-parser \
+                port:p${perlvariants.selected_version}-getopt-long \
+                port:p${perlvariants.selected_version}-pathtools \
+                port:p${perlvariants.selected_version}-scalar-list-utils
 
-configure.perl  ${prefix}/bin/perl${perlver}
-
 test.run        yes
 test.target     check
 

>> That being said, I’m not that dead set on that, but there is specific benefit from having the variant in intltool (because of that braindead autoconf macro).  If the group decides that it’s ok to just require that intltool and perl5 always match variant, that would be the best solution as then we’d need to do *nothing* in ports that depend on intltool.
> 
> I don't know how we would enforce the idea that the intltool and perl5 variants should match.
> 
> I consider it to be likely that a user would install a port that happens to install intltool (with its default perl5_12 variant), which installs perl5.12. Sometime later, the user is actually interested in using perl, and installs perl5+perl5_16. There's no existing mechanism in MacPorts that would prevent that.

Yeah, but at least the error message would be helpful, and the user could just install the p5.16-xml-parser port to work around the broken configure check.

> I'm not clear whether the intltool port currently relies on the existence of the perl5 port, but if it does, then I don't think that's a good idea, because I'd really like for the perl5 port to be deleted and replaced with the "port select" mechanism:
> 
> https://trac.macports.org/ticket/29763

It does not rely on the existence of the port.  I was using it for illustrative purposes.  With port select, it would simply work as long as its variant matches the selected 'port select perl’

This raises an interesting idea.  It would be nice if the port select mechanism allowed a pre/post script to be run.  Does it?  If so, such a script could warn the user if it detects intltool installed and the new perl version doesn’t have p<version>-xml-parser installed.  The user could then install that module (even though they might not actually need it other than to pass the buggy configure scripts...)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130704/7044d1fb/attachment.p7s>