[107013] trunk/dports/devel

[Ryan Schmidt]

On Jun 15, 2013, at 23:28, Adam Mercer <ram at macports.org> wrote:

> On Sat, Jun 15, 2013 at 8:29 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
>>> Added: trunk/dports/devel/globus-core/Portfile
>>> ===================================================================
>>> --- trunk/dports/devel/globus-core/Portfile                           (rev 0)
>>> +++ trunk/dports/devel/globus-core/Portfile   2013-06-14 12:32:42 UTC (rev 107013)
>>> @@ -0,0 +1,94 @@
>>> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>>> +# $Id$
>>> +
>>> +set perl_vendor_lib [ exec sh -c "eval \"\`perl -V:installvendorlib\`\" ; echo \$installvendorlib" ]
>> 
>> At the time this line is run, you cannot assume that perl has already been installed.
> 
> Is there any way that we can get this information?

You can run the command yourself on the command line, for the version of perl that you want globus-core to use, and then put that value into the portfile (modulo using ${prefix} as usual).

The problem with trying to run it in the portfile is that it's not predictable or repeatable: it depends on what "perl" is. Via the variants of the perl5 port, that can vary on the user's system, or as I mentioned, in the extreme case of not having perl5 installed at all, "perl" is "/usr/bin/perl". That's in fact what happens on the buildbot, because the buildbot never has any ports installed prior to a build. (All ports are uninstalled after every build.) So on the buildbot, 'sh -c "eval \"\`perl -V:installvendorlib\`\" ; echo \$installvendorlib"' is '/Network/Library/Perl/5.12'. And this value gets inserted into the files installed by the port:

/opt/local/sbin/globus-build-doxygen-dependencies:    $perlmoduledir = "/Network/Library/Perl/5.12";
/opt/local/sbin/globus-update-doxygen-index:    $perlmoduledir = "/Network/Library/Perl/5.12";
/opt/local/share/globus/globus-build-env-gcc64pthr.sh:perlmoduledir='/Network/Library/Perl/5.12'
/opt/local/share/globus/globus-build-env-noflavor.sh:perlmoduledir='/Network/Library/Perl/5.12'

What does globus do with this directory? Does it look for MacPorts-installed perl modules there? It will not find them there. Does it try to install its own modules there? That's not a good idea either.

>>> +if {$build_arch == "x86_64" || $build_arch == "ppc64"} {
>>> +    set flavor gcc64pthr
>>> +    set enable64 yes
>>> +} else {
>>> +    set flavor gcc32pthr
>>> +    set enable64 no
>>> +}
>> 
>> What happens when the user selects the universal variant? You may need to use the muniversal portgroup.
> 
> I've looked into building globus universally before and I didn't get
> very far, I recall running into strange build issues. This was for
> gt-5.0.x and the build system has come on a long way in the gt-5.2.x
> series but it's still a little odd. We may need to disable the
> universal variant.

Disabling the universal variant for now would be fine. I just wanted to point out that you're making decisions based on build_arch, which probably aren't valid for the other archs for which you're building when you're building universal, so even if the universal variant currently builds without error, it has probably built faulty software.


>>> +depends_run             port:p5-xml-dom \
>>> +                        port:p5-xml-parser
>>> +
>>> +depends_build           port:grid-packaging-tools \
>>> +                        port:p5-xml-dom \
>>> +                        port:p5-xml-parser \
>>> +                        port:libtool \
>>> +                        port:autoconf \
>>> +                        port:automake
>> 
>> Must depend on the specific subport of the p5-* ports that you want, and probably do something to inform the build system to use that perl. Unless there is a specific requirement for a newer or older version, it should be perl5.12 because that is the default in MacPorts at this time.
> 
> I almost made that change when reviewing it but as globus isn't fussy
> on the version of perl I decided not to.
> 
>>> +pre-configure {
>>> +    file delete -force ${worksrcpath}/autom4te.cache
>>> +    reinplace "s/libtoolize/glibtoolize/g" ${worksrcpath}/bootstrap
>>> +    system "cd ${worksrcpath} && \
>>> +        GLOBUS_LOCATION=${prefix} GPT_LOCATION=${prefix} ./bootstrap"
>>> +}
>> 
>> Should use 'system -W … "…"' instead of 'system "cd … && …"'.
> 
> OK
> 
>>> +post-destroot {
>>> +    # These scripts are intended to be sourced, not executed
>>> +    system "chmod 644 ${destroot}${prefix}/share/globus/globus-build-env-*.sh"
>>> +}
>> 
>> Should use [file attributes -permissions] instead of running a shell to run chmod. [glob] and [eval] may also be helpful.
> 
> Are there any examples of using this, as I can't find reference to
> this in the guide?

Off the top of my head I was going to suggest:

post-destroot {
    eval file attributes [glob ${destroot}${prefix}/share/globus/globus-build-env-*.sh] -permissions 0644
}

That's assuming [file attributes] accepts multiple filenames in a single invocation… which the documentation does not confirm. If that isn't allowed, then an [fs-traverse] loop could be used.