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

Pau Arumi parumi at iua.upf.edu
Thu Dec 28 11:43:00 PST 2006

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.
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 
> 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:

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?


>> 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.

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

More information about the clam-devel mailing list