Default +universal variant for configure-based ports

[Elias Pipping]

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
>
>
> -- 
> Blair Zajac, Ph.D.
> CTO, OrcaWare Technologies
> <blair at orcaware.com>
> Subversion training, consulting and support
> http://www.orcaware.com/svn/