Re: [Alephmodular-devel] On integrating preferences...

[Br'fin <br...@ma...>]

On Dec 14, 2003, at 4:23 AM, Aaron Davies wrote:

> On Saturday, December 13, 2003, at 03:44 AM, Br'fin wrote:
>
>> I'm getting nearer and nearer to the point where I can create a 
>> CPreferencesReader/Writer_PList element. At this point I haven't 
>> decided on an XML parsing library. Nor have I decided on how I want 
>> to integrate such external libraries into the project. Do I set 
>> things up like libspeex and liblua for A1 or what?
>
> My take, as I've implied on mdev, is that third-party libraries should 
> be used in as close a manner to OS tradition as possible. In Unix, 
> that means looking for them in a configure script; in Mac OS X, that 
> means including frameworks in the bundle, if they're available, and 
> library binaries, if they're not; in Windows, that probably means 
> including appropriate DLL's with the binary. Yes, this will probably 
> make cross-platform coding a little more difficult, but it makes 
> things much easier for the end user.

I do agree with respect to the end users. If you use dynamically linked 
libraries, include them in the app. Otherwise use statically linked 
libraries. The Application should be as standalone as possible.

The only allowable exception is in the case of a self-compiled build. 
Like if there was a an apt-get version, that would be ok to have 
dynamically linked libraries since the overall mechanism of apt-get 
would do the requisite setup of needed libraries.

On cross-platform:
The only aspect of different library mechanisms that I can see being a 
problem is that a library with a framework prefers #include 
<Framework/Framework.h> and a library without prefers #include 
<Library.h>

SDL seems to cheat by requiring the project have a header search path 
that navigates the SDL
framework internals to locate the appropriate header files so #include 
"SDL.h" always works.

It feels like there should be some middle ground, but I don't know 
where it is.

Beyond that, library setup inclusion is more an aspect of the given 
platform's compiler instead of affecting code.

On frameworks:
If a library has them (ala SDL) Great! It's settled. If a library 
doesn't, I'm mixed on the prospect of trying to setup a framework for 
it. It might be a good idea, and it might be too much hassle too. 
(Proper way of doing it would be to send patches to said project to 
enable the framework to be built.) I admit to being impatient on the 
prospect. Though I suppose I could develop said patch, submit said 
patch, then include patch in a directory of AM's cvs with setup 
instructions of 'download libsource, apply patch, make/make 
framework/make install_framework' (instead of make/make install.)

*ponder* I admit more trouble than I want to go to if there isn't a 
framework already. And then the element with including headers from 
frameworks that I listed above.


I admit to still favoring the way I setup speex and lua for A1 
(Installing versioned directories under /Library/Application Support) 
for handling libraries to be included on OSX without frameworks. Though 
fink support is a good reason to be more flexible, as was the setup for 
cross-compiling A1 for windows.

-Jeremy Parsons