Default +universal variant for configure-based ports

[Elias Pipping]

r22321 should fix the problem.

please let me know if it does/doesn't.


Regards,

Elias Pipping


On Feb 26, 2007, at 8:34 AM, Blair Zajac wrote:

> That's a pretty important port, it's at the very bottom of any  
> dependency trees, so I think we should.
>
> This kinda raises the point for me, that maybe we should consider  
> having a build farm of 10.3 and 10.4 PPC and i386 that check  
> submissions, ala a smoke test, and after each Subversion commit,  
> the new Ports are built on all platforms.  If it breaks, the author  
> of the commit gets an email.
>
> I imagine that not everybody has 10.3 around, but I do consider it  
> an important OS X release, as many corporations still haven't  
> upgraded everything to 10.4 yet.
>
> Thanks,
> Blair
>
> Elias Pipping wrote:
>> Well, i could comment it out for now - until 1.4.0 is out. Should  
>> I? that option is indeed needed for +universal to work, though.
>> Regards,
>> Elias Pipping
>> On Feb 26, 2007, at 8:23 AM, Blair Zajac wrote:
>>> And do we have to wait for MacPorts 1.4.0 before using these new  
>>> commands.
>>>
>>> For example, right now libiconv is broken.  If you try to build  
>>> something that depends upon it:
>>>
>>> $ port -v build libxml2
>>> Error: Unable to execute port: invalid command name  
>>> "configure.universal_ldflags-append"
>>>
>>> I'm presuming this is from this line in dports/textproc/libiconv/ 
>>> Portfile:
>>>
>>> +configure.universal_ldflags-append \
>>> +                -isysroot /Developer/SDKs/MacOSX10.4u.sdk
>>>
>>> Regards,
>>> Blair
>>>
>>> Blair Zajac wrote:
>>>> Hi Paul,
>>>> I looked through the diff for r22313 and didn't see anything  
>>>> that checks for OS X versions 10.3 or older, so will this break  
>>>> on older OSes? If it will break things, can you update the code  
>>>> to add this check?
>>>> I support a binary install of MacPorts on a portable firewire  
>>>> drive that runs Apache, MySQL etc and we need to support 10.3  
>>>> clients.
>>>> Regards,
>>>> Blair
>>>> Elias Pipping wrote:
>>>>> That is a lovely addition and I embrace it wholeheartedly.
>>>>>
>>>>> Now more than ever it brings up the need for a database that  
>>>>> contains information on which port builds on what platform and  
>>>>> if its variant +universal works, though.
>>>>>
>>>>> So a port would have these entries e.g.:
>>>>>
>>>>> db44     ppc   i386   universal
>>>>>
>>>>> Panther   ?      ?        ?
>>>>> Tiger     X      ?        X
>>>>> Leopard   ?      ?        ?
>>>>>
>>>>> or something like that. maybe i'm the only one to see it that  
>>>>> way but i find it problematic to just assume away every port  
>>>>> builds on every platform and is perfectly stable. also, is it  
>>>>> really a good idea to keep adding -devel ports instead of  
>>>>> allowing a port to be available as multiple "branches"? like  
>>>>> bash 3.1.17 and 3.2.9 as a 3.1 and a 3.2 branch (yes, i'm  
>>>>> thinking of gentoo - stable, testing, etc)?
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Elias Pipping
>>>>>
>>>>>
>>>>> On Feb 26, 2007, at 5:45 AM, Paul Guyot wrote:
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I've just implemented and committed a default +universal  
>>>>>> variant for configure-based ports. There's been some heat  
>>>>>> about +universal recently and I did not want every port to  
>>>>>> define the same code over and over.
>>>>>>
>>>>>> This variant is more or less equivalent to:
>>>>>> variant universal {
>>>>>>     configure.args-append "--disable-dependency-tracking"
>>>>>>     configure.env-append CFLAGS="-isysroot /Developer/SDKs/ 
>>>>>> MacOSX10.4u.sdk -arch i386 -arch ppc" LDFLAGS="-arch i386 - 
>>>>>> arch ppc"
>>>>>> }
>>>>>>
>>>>>> However, there is some additional magic:
>>>>>> * selecting the variant will fail if the port doesn't invoke  
>>>>>> configure (because user may think they can build the port  
>>>>>> universal while it would be effectless)
>>>>>> * selecting the variant will print a warning message if the  
>>>>>> port already overrides LDFLAGS or CFLAGS in the environment  
>>>>>> for the configure command
>>>>>> * you can add -O -g if the port requires it with just:
>>>>>> configure.universal_cflags-append    -O -g
>>>>>> * you can simply redefine the variant to override the default  
>>>>>> code and provide port-specific handler for the universal variant.
>>>>>>
>>>>>> etc.
>>>>>>
>>>>>> The variant is documented in portfile(7). I tested it with  
>>>>>> several ports and it seems to just work®™.
>>>>>>
>>>>>> I'm considering some future enhancements, but let's see what  
>>>>>> it gives if we start building ports with +universal. Of  
>>>>>> course, the build will probably fail if dependencies were not  
>>>>>> built universal.
>>>>>>
>>>>>> Enjoy!
>>>>>>
>>>>>> Paul