[Clam-devel] Re: Mac OS X -- Cross Compatibiliy -- ByteOrder Patch
volker at photone.de
Thu Dec 28 10:50:47 PST 2006
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.
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 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.
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
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.
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.
Thanks & Best Wishes!
On Dec 28, 2006, at 1:08 PM, Pau Arumi wrote:
> 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
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
More information about the clam-devel