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

[Volker Schumacher]

Hi David,

AFAIK, in application bundles should have only one main executable that 
is started when the application bundle is launched.
Usually this has the same name as the bundle (I'm not 100% sure, but I 
believe this is a requirement) and resides in 
MyApp.app/Contents/MacOS/MyApp.

If MyApp uses other binaries, they can be included into the bundle, 
either also in Contents/MacOS or Contents/Framework in case of 
libraries. But other main executables cannot be launched directly by the 
user from outside the bundle in a convenient way.

Libraries installed into an application bundle must have a certain 
install name, which is relative to the main executable and can be 
specified using the @executable_path keyword. So for example instead of 
installing a library into /usr/local/clam/lib/ one can install into 
@executable_path/../Frameworks/. Apple provides a tool for editing the 
linker install names (called something like install_name_tool).

In general I am not a friend of having multiple redundant resources if 
more than one application uses it. Apart from that, I usually include 
only resources within the application bundle which can be hidden from 
the user, such as images used by the user interface or libraries, since 
also the Mac Finder hides the inside of a bundle from the user. For 
other resources such as documentation or examples I prefer to maintain 
these in a unique absolute location. On Mac typically either 
/Library/Application Support/$VENDOR/$PRODUCT (or ~/Library/Application 
Support/... for user dependent resources) is used for this.

The benefit of selfcontained bundles is that they can be moved around in 
the system or to other systems easily. Otherwise an installer should be 
provided, but this is also easy on Mac with the developer tools.
I think the descision may also depend on the development/deployment life 
cycle of a project. For example will all applications related to clam be 
always released together or may situations occur where different clam 
tools depend on different versions of 3rd party projects or other shared 
resources?

In summary I would propose to create an application bundle for any 
application that can be launched by the user and install shared 
resources into [~]/Library/Application Support/CLAM/.

For executables that need to call each other an option would be to keep 
them also in the shared resources location, and use scripts inside the 
application bundles (acting as launcher entry point) which launch the 
executeable. Then applications can find other applications easily 
because of the absolute location. On the other hand, applications can be 
launched via "open -a MyApp" from anywhere since osx knows about its 
available applications.

Best Wishes!
Volker



David García Garzón schrieb:
> 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.
>