[Ardour-Dev] [Ardour-Cvs] r11525 - ardour2/branches/2.0-ongoing/tools

[Robin Gareus]

On 03/07/2012 01:42 PM, Paul Davis wrote:
> On Wed, Mar 7, 2012 at 6:57 AM, Robin Gareus <robin at gareus.org> wrote:
>> On 02/27/2012 03:55 PM, pauld at addisababa.dreamhost.com wrote:
>>> Author: paul
>>> Date: 2012-02-27 06:55:52 -0800 (Mon, 27 Feb 2012)
>>> New Revision: 11525
>>>
>>> Added:
>>>    ardour2/branches/2.0-ongoing/tools/build-gtk-stack
>>> Log:
>>> new script to build (almost) the entire GTK stack from released
>>> tarballs of all dependencies, particularly on OS X
>>
>> Wow, Paul! Chapeau.
>> I wish I had that script 2 years ago.
> 
> i have a new lion server mac mini and i thought it was time to codify things :)

Mountain Lion? ROOAAAR ! be careful it bites; running for the hills
won't help :)

>> When running for the hills I usually curse:
>> CFLAGS="-arch i386 -arch ppc -arch x86_64 -headerpad_max_install_names
>> -isysroot... -mmacosx-version-min=10.5" \
>> ./configure --disable-dependency-tracking \
>>  --enable-shared --disable-static
> 
> isysroot doesn't work on 10.4.
> 
> the headerpad stuff is a good idea, i've been lobbying GNOME to
> include that for OS X compilation. 10.5 is absolutely not the minimum
> version - you'd be suprised how many people are still on Tiger. what
> is true is that 10.5 (or, i think) 10.6 still allows you to build for
> 10.4; 10.7 no longer does without some significant work hacking with 2
> versions of XCode. what does --disable-dependency-tracking do?

it disables automakes's dependency tracking. It is [only] need for
universal builds because Apple's compiler can not create the dependency
graph for universal binary builds.

>> Universal binaries require some special detour for libffi and extra
> 
> i'm not planning ever distributing universals. the extra size is too
> much of a price to pay for "oh, i don't have to guess what
> architecture i'm on".
> 
>> It's probably smarter to create individual ppc, i386 and x86_64 binaries
> 
> at present, i don't even plan on doing an x86_64 distribution.
> probably sometime in the lifecycle of 3.0 i'll start doing that. i'm
> not clear that it offers many benefits, though i am sure there are
> some. if/when that happens it will probably be lion-and-above only.
> 
> --p