flac dev - Jan 2005 - in progress: Installer Package for Mac OS X (for 1.1.1 binaries)

--- Brian Willoughby <brianw@sounds.wa.com> wrote:
> Hello,
> 
> I noticed that there is no convenient installer package for Mac OS X.
>  The  
> various GUI programs that use FLAC seem to only have flac 1.1.0, so
> there is no  
> simple way for a non-developer to install flac 1.1.1, other than
> manually  
> placing the various files where they belong.
> 
> So, 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.
> This package includes the pertinent files from
> flac-1.1.1-osx-ppc.tar.gz,
> but without the AUTHORS and other attribution files.  I don't know
> where to  
> install the attribution files, so I think it would be best to include
> that  
> information in the Installer UI itself.  If anyone would like to
> suggest the  
> appropriate text (possibly a subset of the AUTHORS file, or even the
> whole  
> file), then I will create another package with proper attributions in
> it.
I would say /usr/share/doc/flac-1.1.1/AUTHORS.  same with the
COPYRIGHT files.
> Other issues:
> 
> 1) It's obvious that flac and metaflac belong in /usr/local/bin/ and
> flac.1  
> and metaflac.1 belong in /usr/local/man/man1/, however I am a little
> worried  
> about placing the /html/ directory in /usr/local/share/doc/html/
> because it  
> seems like it might conflict with other Unix tools installed there. 
> When  
> manually installing flac 1.1.0, I just created a subdirectory named  
> /usr/local/share/doc/html/flac-1.1.0/ and moved the flac files there.
>  Any Unix  
> folks out there know what the standard should be for placing files in
> /usr/local/share/doc/html/ such that they do not conflict?
I think it should go in /usr/share/doc/flac-1.1.1/html
> 2) Because flac-1.1.1-osx-ppc.tar.gz has static linked binaries only,
I
> decided to do the same in FLAC-1.1.1.pkg.tar.gz, however there is
> some benefit  
> to having a more extensive Installer package for Mac OS X which
> includes the  
> FLAC and FLAC++ libraries.  That Installer package could easily
> install the  
> dynamically linked binaries since the libraries will be installed at
> the same  
> time.
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.

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.
> I know how to build all of this, but I am asking for feedback on
> whether such  
> a package would be useful.  I've been distributing free programs for
> Mac OS X  
> which use the FLAC library, and I've had to instuct my users on how
> to manually  
> install the FLAC library.  I have incentive to put together a more
> extensive  
> package to make distribution of my software a little easier (I'll
> just tell  
> users to install the FLAC package before my app).
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 :)

Josh



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250

[  > 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