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

[David García Garzón]

Volker, It is nice someone used to MacOSX development. We really need some 
help. I tried to package CLAM some months ago and i got some results [1], but 
after that i got lost on Apple documentation. Then during summer hollydays I 
switched to other issues and when back the Mac Box was moved to other room.

I think we definitelly should locate that hard drive. I have some uncommited 
changes on the scons tool to build dmg and bundles and the way libraries were 
referred. I also managed to compile Qt4 based Annotator using an already 
compiled version[2] as a framework combined with the binary packages Xavi 
Oliver built [3][4] for the rest of the libraries.

[1] http://clam.iua.upf.edu/download/mac/cvssnapshots/
[2] http://naranja.umh.es/~atg/software-qt4.html
[3] http://clam.iua.upf.edu/download/mac/external-libraries-for-CLAM-0.90.dmg
[4] http://iua-share.upf.es/wikis/clam_draft/CLAM_OSX

That's very funny altogether because we all four have tried to build CLAM for 
macosx taking different paths. I think we should join some time soon.


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/86789f9e/attachment.sig>