Default +universal variant for configure-based ports

[Blair Zajac]

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