[ardour-dev] mac osx universal binaries compilaton

[Pau Arumi]

En/na Jesse Chappell ha escrit:
> On 12/30/06, Pau Arumi <parumi at iua.upf.edu> wrote:
>
>> i see that you do put together binaries from lib_powerpc/ and lib_i386/
>> with lipo. but i can't find how binaries get produced there.
>> i assume you are using darwinports libraries. is it possible to build 
>> two
>> different versions of each library? (and does g++ allow crosscompiling,
>> after all?)
>
> It is theoretically possible to build all the dependent libraries
> twice, cross compiling one time, but usually we've been too lazy to
> set all that up.  I/we have both ppc and intel macs and do darwinports
> (plus a few extraneous dependencies by hand) on each.  Then running
> the new script finds the dependent libs and copies them in place for
> later lipo'ing as you saw.  It is a bit crude, but it works.
>
i've been chating with taybin and sampo at #ardour about this.
taybin point me this doc that explain how to do what you are saying.
http://developer.apple.com/technotes/tn2005/tn2137.html

for clam we'll have to go the crosscompile way as we only have an intel
box. we'll try to base it on darwinports as much as possible. if we succeed
then i'll try to do the same for ardour, though might be harder since there
are more dependencies here.
actually, i see so many advantages on (totally) automatic packaging
that i'd try hard that way even if i had the two boxes :)

> As for your testing discussion, I don't really see a need to do the
> whole app bundle thing for that.  Automated testing for an app like
> ardour seems a bit ambitious, there are *so* many options and things
> that could be done, and missed.  I know that although potentially
> valuable, the core developers aren't likely to have time to help much
> with that.  But willing contributors like yourself are welcome to give
> it a shot!
covering all the code with unit-testing or all the features with functional
tests this *is* ambitious. well, impossible in the case of ardour :-)
but some specific black-box testing might be pretty easy to set up and yet
could provide some confidence on the stability of code changes. that's my
experience in my daily work. specially that kind of back-to-back test of 
audio
rendering i described in the previous mail.
anyway i will discuss it with core developers (and i know holidays is not a
good time) before spending any minute on this.

best,
  pau



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.