kde4 ports

[Ryan Schmidt]

On Nov 26, 2008, at 15:42, Big O wrote:

> On Wed, Nov 26, 2008 at 12:52 AM, Ryan Schmidt wrote:
>
>> 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.
>
> Done.
>
>>>> 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.
>
> Fixed.
>
>>>> 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
>
> Will look into it after thanksgiving.
>
>> 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?
>
> cmake universal setting separates architechtures with a semi-colon ( ;
> ) so this would requires a lot more work to get right.

It's not too difficult..... ${configure.universal_archs} is the space- 
separated list of architectures, so the semicolon-separated list is  
just [strsed ${configure.universal_archs} "g/ /;/"]


>>> 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.
>
> Subscribed.