[122521] trunk/dports/_resources/port1.0/group

Ryan Schmidt ryandesign at macports.org
Thu Jul 24 00:43:37 PDT 2014


On Jul 24, 2014, at 12:43 AM, Mojca Miklavec wrote:

> On Thu, Jul 24, 2014 at 3:18 AM, Ryan Schmidt wrote:
>> 
>> On Jul 23, 2014, at 9:31 AM, mojca at macports.org wrote:
> 
>>> --- trunk/dports/_resources/port1.0/group/perl5-1.0.tcl       2014-07-23 14:29:55 UTC (rev 122520)
>>> +++ trunk/dports/_resources/port1.0/group/perl5-1.0.tcl       2014-07-23 14:31:40 UTC (rev 122521)
>>> @@ -73,7 +73,7 @@
>>> default perl5.bin {${prefix}/bin/perl${perl5.major}}
>>> 
>>> # define installation libraries as vendor location
>>> -default perl5.lib {${prefix}/lib/perl5/vendor_perl/${perl5.version}}
>>> +default perl5.lib {[perl5.extract_config vendorlib]}
>>> default perl5.bindir {${prefix}/libexec/perl${perl5.major}}
>>> default perl5.archlib {${perl5.lib}/${perl5.arch}}
>> 
>> This would require perl to be installed in order to work.
> 
> Before that we had
> 
> default perl5.version {[perl5.extract_config version]}

Oh yes, you're right.

> So I guess that we had the same problem earlier then? Since
> perl5.version had to be properly set in order to have a working
> perl5.lib?

Right.


>> Are you sure no port references ${perl5.lib} in the global part of the portfile, i.e. before perl has necessarily been installed? For example, what about p5-sgmlspm, which uses ${perl5.lib} in build.args? What happens if you try to install e.g. p5.16-sgmlspm before perl5.16 is installed (which is what will happen on the buildbot)?

> So xinstall works properly, but the files are not installed to the proper place.

Ok that's what I expected.


> I can test, but I'm almost sure that it failed to work properly earlier as well.
> 
> I would say that the port needs to be revised in either case. It does
> weird things. I mean ... things like this shouldn't be necessary:
>    reinplace "s|/usr/local/|${destroot}${prefix}/|" ${worksrcpath}/Makefile
> in a nicely working module. "All other" modules do that automatically
> and properly.

Yeah probably this port just needs to be fixed. Looks like there aren't many ports using that variable, and the others are doing it in a phase (post-activate, or destroot) which is fine.



More information about the macports-dev mailing list