[Flac-dev] in progress: Installer Package for Mac OS X (for 1.1.1
brianw at sounds.wa.com
Thu Jan 27 02:06:31 PST 2005
[ > 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
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
[ 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
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
[ 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
More information about the Flac-dev