kde4 ports

[Ryan Schmidt]

On Nov 25, 2008, at 13:35, Big O wrote:

> On Mon, Nov 24, 2008 at 2:36 AM, Ryan Schmidt wrote:
>
>> Regarding all the kde4 ports you've committed...
>>
>>
>> You're fetching them all from the Subversion repository. Are  
>> distfiles not
>> available for any of them? If there are distfiles provided, they  
>> should be
>> used. If not, then you need to add svn as a build dependency. I  
>> recommend
>> you declare it as "bin:svn:subversion", that way the Subversion  
>> client that
>> Apple provides in Leopard and later can be used on those systems  
>> since it
>> should be sufficient, and for those using Tiger or earlier or  
>> other OSes
>> without built-in Subversion clients the subversion port will be  
>> built.
>
> Ah yes, actually. distfiles are available. I just find it easier to
> work from svn as I don't have to deal with the checksum section.  I'll
> use those if you want though.

Yes, we do want you to use distfiles when available. Fetching from  
svn is a last resort.


>> What is the idea behind the line "pre-configure { file mkdir $ 
>> {worksrcpath}
>> }"?
>
> I forget. :-) I think it creates the build directory. kde requires out
> of source bids, so we use "build" as that directory. I'll check.

Ok, that sounds fine.


>> I mentioned this earlier regarding qimageblitz but I see now it  
>> applies to
>> all of them: /opt/local should not appear in the ports; the variable
>> ${prefix} should be used.
>
> I'll change that. I forgot about those.

Ok great, thanks.


>> These ports use cmake, and I see several things you've had to do  
>> in each
>> port to accommodate this. Should there be a cmake portgroup? Since  
>> you're
>> gaining familiarity with what cmake needs as a result of these  
>> ports, maybe
>> you could work on such a portgroup.
>
> Sure. What's a portgroup :-)

Read the guide:

http://guide.macports.org/#reference.portgroup

A portgroup encapsulates behavior that would otherwise need to be  
repeated in many ports. Most python 2.5 ports use the python25  
portgroup. Most ports that compile using an xcode project use the  
xcode portgroup. Now that we're having lots of cmake-using ports, it  
might make sense to have a cmake portgroup.


>> For the universal variant, is there a way to make use of
>> ${configure.universal_archs} so that the user's selected  
>> architectures are
>> built, instead of assuming they want ppc and i386?
>
> Well if they are selecting universal don't they want i386 and ppc? I
> don't get it. Are you referring to x86_64 and ppc64 (does that even
> exist) archs being options as well.
> I don't know that cmake supports any options here besides ppc and
> i386. I'll check though.

By default a universal build in MacPorts is i386 ppc. But as of  
MacPorts 1.7.0, the user can select in the macports.conf which  
architectures they want. Maybe they want i386 ppc x86_64 ppc_64.  
Maybe they want just i386 x86_64. The variable $ 
{configure.universal_archs} contains the user's selection, and ports  
should use it. (Actually, hopefully, ports would never need to look  
there and it would happen automatically, which it hopefully would if  
there were a cmake portgroup; it would handle this once so all cmake- 
using ports would benefit from it.)


> CC me. not subscribed :-)

Please subscribe, so that you can post to the list and so that we can  
have conversations with you. If you're developing ports, and  
especially if you're a committer, you really need to be subscribed to  
and reading the lists.