[82168] trunk/dports/graphics

[Ryan Schmidt]

On Aug 9, 2011, at 19:57, Blair Zajac wrote:

> On Aug 9, 2011, at 2:59 PM, Ryan Schmidt wrote:
> 
>> On Aug 9, 2011, at 12:16, blair at macports.org wrote:
>> 
>>> Revision: 82168
>>>        http://trac.macports.org/changeset/82168
>>> Author:   blair at macports.org
>>> Date:     2011-08-09 10:16:30 -0700 (Tue, 09 Aug 2011)
>>> Log Message:
>>> -----------
>>> field3d: new port.
>> 
>> 
>>> +homepage                https://sites.google.com/site/field3d/home
>>> +master_sites            https://github.com/imageworks/Field3D/tarball/v${version}
>>> +extract.mkdir           yes
>>> +extract.post_args       "| tar --strip-components=1 -xf -"
>> 
>> This works... The idea is to fix github's unpredictably-named directories. But I've been doing it this way:
>> 
>> post-extract {
>>   move [glob ${workpath}/*] ${worksrcpath}
>> }
>> 
>> I think this is better because it doesn't introduce knowledge into the portfile about the specifics of how the extract phase works. There are some problems with the way the extract phase is currently implemented (e.g. no notification if the decompression program failed), and we may want to change how it works later, so it would probably be better if ports did not assume the extract phase will always be a compression program piped to tar.
> 
> Will that leave some oddly named tarball in $prefix/var/macports/distfiles?

Neither the code you have in the portfile now nor the code I suggested has anything to do with distfiles; they won't be touched. We're only talking about the directory they extract to inside $workpath. In my experience the distfiles from github are reasonably named, but as you found out as well, the directory they extract to has an unreasonable name (including the author's handle and the git revision number) and it's nice not to have to code the author's handle into the portfile nor to have to update the git revision every time the version is updated.


>>> +post-patch {
>>> +    reinplace "s#@PREFIX@#$prefix#g" ${worksrcpath}/BuildSupport.py
>>> +    reinplace "s#@CC@#${configure.cc}#" ${worksrcpath}/SConstruct
>>> +    reinplace "s#@CXX@#${configure.cxx}#" ${worksrcpath}/SConstruct
>>> +}
>> 
>> These reinplaces are good for ensuring we're UsingTheRightCompiler... but what about the right build_arch? May need to do something with ${configure.cc_archflags} too (or [get_canonical_archflags], if universal works).
> 
> Can you provide a link to universal so I know what this is all about?
> 
> I could also tweak the CFLAGS and CXXFLAGS to get additional flags in there.

Well, I mean a universal binary. Building for multiple architectures.

http://en.wikipedia.org/wiki/Universal_binary

We've been doing it for years, since Intel Macs came out.

https://trac.macports.org/wiki/FAQ#universal

In MacPorts this happens via a variant called "universal" which MacPorts adds to most ports for you, and for most ports it works without further maintainer intervention. But your port says "use_configure no" which means MacPorts won't add the standard universal variant. But if a universal build would work, you should add a universal variant. Perhaps along the lines of:


variant universal {}
post-patch {
    reinplace "s#@PREFIX@#${prefix}#g" ${worksrcpath}/BuildSupport.py
    reinplace "s#@CC@#${configure.cc} [get_canonical_archflags]#" ${worksrcpath}/SConstruct
    reinplace "s#@CXX@#${configure.cxx} [get_canonical_archflags]#" ${worksrcpath}/SConstruct
}


I haven't tested this for this port, but this general strategy is often sufficient. Putting the archflags into the CFLAGS and CXXFLAGS and LDFLAGS generally works too, if you prefer.

Just make sure you write "variant universal {}" *before* calling [get_canonical_archflags] otherwise you won't get the right archs.