[Clam-devel] Re: Mac OS X -- Cross Compatibiliy -- ByteOrder Patch

[David García Garzón]

BTW, maybe Volker, or any other mac developer in the room, may give us a hint 
on the issue i got stucked while building clam applications bundles. We have 
some binaries in CLAM which work together sharing resources and i don't have 
any idea on how is the proper way to organize them in bundles. 

For example, NetworkEditor and Prototyper are two programs to be called 
independently but they share the examples, the translations and the 
documentation. Duplicating resources in two bundles? Can both binaries be in 
a single bundle? Extracting 

A similar but different problem happens with the Annotator. Apart from shared 
resurces, here the programs (BocaClient, Annotator and the extractors) call 
each other. How they should refer each other to be run.

I had no previous experience on mac even as user, so i don't know how 
applications typically solve this kind of issues.

Thanks.



On Thursday 28 December 2006 20:43, Pau Arumi wrote:
> En/na Volker Schumacher ha escrit:
> > Hi Pau,
> >
> > I did not get into the scons build system so much, but I will try out.
> > In general I like the idea to have a single build system. With the old
> > build system I had a lot of trouble on Mac, thats why I started with
> > XCode. My biggest problem that time was that I wanted to install all
> > the dependencies via "Fink" or "DarwinPorts", and I couldn't figure
> > out how to tell the old Clam build system to look in the associated
> > default locations (Fink: "/sw" DarwinPorts: "/opt/local") or any
> > custom location for libraries and includes. Using Fink and DarwinPorts
> > is quite popular on Mac. Anyway, maybe that is easier now with scons.
> > I have to learn it.
>
> i did my experiments using darwinports, inspired by this page by taybin
> the mac osx maintainer of ardour.
> http://www.taybin.com/unix-style-development-on-macosx/
> actually for each dependency i checked both fink and darwinport, and the
> second was more complete. moreover it seems that darwinports are more
> flexible since you can change the compiler flags.
>
> changing clam SConstructs so it use /opt/local was very easy. actually i
> have wrote down everything i did in order to write a howto. the problem
> is that i got stuck linking against qt4 and coudn't finish it. hopefully
> tomorrow...
>
> > Scons and XCode do not work together directly, but there is the
> > possibility to have so called "External Targets", where one can
> > specify any command line build tool and pass arguments and so on.
> > Apart from that, XCode acts as an IDE in general including a nice
> > frontend for the GDB debugger, and a lot of Mac developers are used to
> > manage their C++ projects with XCode. So maybe it would make sense to
> > provide an XCode project not as a replacement for scons, but more as
> > an addition for the mac which uses scons.
>
> i agree with the pros you see. i know that scons can automatically
> produce a MSVisual projects. if the same happens with XCode that would
> be perfect.
>
> > I think many new Clam developers get afraid when their first
> > experiments already fail with the build process. Of course errors can
> > happen easily with so many dependencies. Because of that I would vote
> > for maintaining all dependency source projects also within the Clam
> > repository, and integrate them into the clam build system. That would
> > also allow to customize the build settings for the dependency projects
> > with different build configurations (debug, release). Currently I work
> > like this with Clam and XCode, having an XCode project for every
> > dependency project and set up the dependency management within the
> > Clam XCode project.
>
> this approach (import external repos) sometimes is convenient, specially
> when you have to patch the libs. however for me this is not the first
> option i'd first try a more free-software like approach:
> 1. use existing darwin ports, maybe changing PortConf file if we want to
> compile differently.
> 2. write the darwin ports not available (if any) and provide a
> repository for anyone to use. i thing is pretty easy.
> for example, stefan kersten have set up some ardour dependencies:
> http://article.gmane.org/gmane.comp.audio.ardour.devel/3258
>
> of course a good install documentation is a must. i'm for collaborative
> edition at the wiki.
>
> > On the other hand, there is still the option to install Clam and its
> > dependencies in a more convenient way from the binary distribution.
> > Since Mac OS now runs on Intel and PPC as well, it became common to
> > deploy mac binaries as Universal Binaries (UB), so all deployed clam
> > mac binaries should be also provided as UBs, or at least for both
> > Intel and PPC platform.
> > Some time ago I read somewhere that scons does not support UBs.
> > However, it should be still possible to force building for different
> > architectures, and then combine the binaries with tools provided by
> > Apple into one. May be this should be considered in the Clam build
> > system.
>
> this is something to investigate. for example ardour (ups i cited ardour
> again) uses scons and provides UBs.
> i guess is what you say: build with different options + use apple tools
> for combine them.
>
> > Another difference to other operating systems is that on Mac there is
> > an additional popular form of deploying development libraries and
> > SDKs: Frameworks. These are bundles (directory in filesystem), which
> > include the complete infrastructure for the SDK, e.g. Headers,
> > binaries, dependencies, version control. On Mac it it very easy to
> > link against a framework and they are easy to install (either
> > relatively within application bundles, or in an absolute framework
> > location). As I understand the idea of Clam, it should not be limited
> > in the way it is used, so maybe this would be also an switchable build
> > option for clam on mac os. The binary clam distribution for mac could
> > be deployed as UB Framework as a complete package.
>
> and i guess mac-frameworks are much more XCode friendly than unix-like
> libraries... that's a good land for you to contribute i think.
>
> > In general my interests in clam are currently related to the
> > development of open source music effects and instruments, which I want
> > to provide as VST, AudioUnit, and Ladspa plugins form processings or
> > networks. Therefore I adapted the VST and AudioUnit interface similar
> > to the already existing Ladspa integration. This is still very
> > experimental, but works more or less. I will contribute when it is
> > finished. I did not use the Clam UI toolkits that much, because I had
> > problems using QT3 on Mac with AudioUnit plugins. I tried again with
> > QT4, and it seems to work better. Until now I mainly used the "juce"
> > library for user interfaces.
>
> well, that goes very much in our current direction. good! the more
> collaboration we can have, the better. i mean: the lower you can keep
> your delta (with clam svn) the better. from our part, we'll be quick
> commiting patches.
>
> lately we've done some advances with vst (in windows). you can basically
> create a vst dll from a given clamnetwork (xml) file and it works. but
> now we want to use the UI created with qt-designer, as we do in
> stand-alone prototypers. the problem we face is how to integrate a qt4
> ui in vst? do you have some hints about this?
>
> best,
> pau
>
> >> En/na Volker Schumacher ha escrit:
> >>> Dear Clam Team,
> >>>
> >>> Thank you so much for your effort on the Clam project, I really love
> >>> it!
> >>
> >> you're welcomed!
> >> feel free to explain your ideas in using clam are, or directions
> >> where you would like to push the development.
> >>
> >>> I am experimenting around with Clam since about one year on the Mac
> >>> platform.
> >>> But I build the project with XCode instead of your build system, and
> >>> all the dependencies as well. This works fine for me, also some of
> >>> my dependency XCode projects are still a bit messy.
> >>> Some like XCode, others don't, for my needs one of the nice features
> >>> in XCode is that it allows to build Universal Binaries in a
> >>> convenient way.
> >>> Please let me know if u are interested in offering an XCode project
> >>> file with the Clam distribution, maybe I can help you.
> >>
> >> from our (bad) past experience supporting different build systems, we
> >> now want to have a single and cross-platform build system. and scons
> >> is very helpful on keeping platform specifics very small.
> >>
> >> AFAIK, scons and xcode doesn't play good together (correct me if i'm
> >> wrong), so we are not planning to support it. however, it might be
> >> the case that having xcode projects would enable more people to get
> >> into clam hacking, so you're very welcomed to contribute and maintain
> >> this build system.
> >>
> >> xcode projects can be invoked via command-line, right? then we can
> >> add this to the testfarm macosx client (to be set up very soon). so
> >> we can at lease see when a commit causes build regressions.
> >>
> >>> I would like to support the Clam project by helping to take care of
> >>> the mac platform.
> >>
> >> i'm currently working on it (using scons), hopefully today i can
> >> finish it and write the the build instructions including howto get
> >> all clam dependencies.
> >> i'm very new to macosx building and packaging so i'll need all the
> >> help i can get. i'll write more mails on specific issues later.
> >>
> >>> So as a first contribution I have a small issue about byte order and
> >>> Intel-compatibility on Mac:
> >>>
> >>> Since Mac OS may run on both Intel and PPC architectures, Apple
> >>> suggests to use the __BIG_ENDIAN__ and __LITTLE_ENDIAN__ macros to
> >>> distinguish endianess in their transition guide. The File
> >>> Defines/ByteOrder.hxx may then contain something like this:
> >>
> >> thanks for the patch. it will be commited when testfarm is in green
> >> again.
> >>
> >> best,
> >> pau
> >>
> >>
> >> --This message has been scanned for viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >
> > --This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.

-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
(Home) vokimon at telefonica adot net
http://www.iua.upf.edu/~dgarcia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20061229/45fec309/attachment-0001.sig>