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

[Volker Schumacher]

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.

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

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!
Volker


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  
> again.
>
> best,
>  pau
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>