On Jul 4, 2013, at 6:29 AM, Ryan Schmidt <[email protected]> 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...)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
