[Flac-dev] in progress: Installer Package for Mac OS X (for 1.1.1 binaries)

[Brian Willoughby]

[  > I have created FLAC-1.1.1.pkg.tar.gz, but I would like your
[  > help in making it more complete.
[
[  this is great, I think this is something that would be useful
[  to have ongoing.  if you're willing to sign up as the maintainer,
[  I can host them on sourceforge as part of the regular release
[  process.

Sure, I can do that.  Just send me a reminder if a new FLAC release goes out  
and you don't hear from me shortly afterwards.  I'm on all the FLAC lists, so I  
should be able to stay fairly up-to-date.


[  I would say /usr/share/doc/flac-1.1.1/AUTHORS.
[  same with the COPYRIGHT files.

OK.  The next installer package will place files there.

I still may look into presenting the author and copyright information directly  
to the user in the Installer UI.  Most Apple install packages put the  
copyright in your face so you're aware of what your allowed to do with the  
installation.


[  I think it should go in /usr/share/doc/flac-1.1.1/html

OK.  I'll put together a new package when I get a chance.


[  I don't think it's necessary to have a development version with
[  libraries/headers/etc.  probably most people who need that already
[  have some setup like fink or just compile the sources.

I had not thought about headers, but it sounds like you don't want them.  fink  
sounds rather handy, but I've never used it, so I imagine developers coming  
from the Apple or NeXT world may find packages easier than fink.  Even if fink  
is more automated, it does take some setup time, at least before you use it for  
the first time.

[  in the basic tools pkg, having statically linked binaries really
[  cuts down on the user headache.  I don't see much need to have a
[  flac that can dyload a newer libFLAC since they are released
[  together.

My information may be out of date, but NEXTSTEP and OPENSTEP have shared  
libraries whose code is only loaded into memory once, even when multiple  
processes are linked to that code - the wonders of virtual memory.  If you were  
to run several applications which link to FLAC, a shared library would use  
less memory.  It's not a matter of linking to different versions, since Apple  
has mechanisms to make sure that incompatible libraries are not dynamically  
linked.


[  ah, I see, you're distributing without libFLAC?  I would suggest
[  to statically link also to cut down on the user headache.  I don't
[  really understand why an app maintainer would want to dynamically
[  link libs in most cases.  for libc and big/important stuff I can
[  see it, for apps using libs that may need frequent security
[  updates, yes, but for something like an audio app, why not just
[  static link?  FLAC releases are not that often :)

Actually, I've only distributed to one user besides myself so far.  Someone  
mentioned wanting to do lossless compression at the same time as sample rate  
conversion, using drag and drop.  Since I had already written something for  
myself that does this, I sent him my app, and then found out that I had to get  
libFLAC installed on his machine, too.

See above for my reasoning as to why the apps I've written for myself are  
dynamically linked.  I'm not certain that they're in shared memory, I'm just  
operating on my impressions left over from when I was primarily a  
NEXTSTEP/OPENSTEP developer.  Now that Mac OS X/Darwin has optimization of  
library pre-binding, it may no longer be possible for multiple applications to  
link to the same virtual memory (unless every application is able to use the  
pre-bound addresses and does not have to dynamically link by relocating the  
addresses).

Brian Willoughby
Sound Consulting