Matt Zimmerman wrote:> > This is already being done (by me) for the Debian packages. I create packages > for: > > - The reference encoder/decoder (flac) > - The shared library libFLAC.so.0 (libflac0) > - The development library and headers (libflac-dev) > - The XMMS plugin (xmms-flac) > > Personally, I think this is beyond the scope of the flac source distribution, > and should be left to those who are creating binary packages. The makefiles > should just install the include files. >It seems convenient to have a way to build packages (RPM, deb) from the source itself. Thats how I set it up with the Smurf Sound Font Editor (RPMs only). I usually only see this with RPMs though. If I knew how to automate this with .debs I would do that as well. Why do you think that is beyond the scope of the flac source distribution? Binary packages don't always work and a user often has to compile from source. Its nice to give them the option of doing so in their native package format. What options are available for users building debs themselves from source? I'm really only familiar with RPMs which you can do an "rpm -tb <package.tar.gz>" to build a binary package from a tar source file (looks for the RPM .spec file in the tar.gz) or "rpm --rebuild <package.src.rpm>" to rebuild a source RPM package. Lates.. Josh Green
Matt Zimmerman
2004-Sep-10 16:45 UTC
Binary compatibility (was Re: [Flac-dev] Sound Font FLAC)
On Thu, Jun 14, 2001 at 05:51:43PM -0700, Josh Green wrote:> I managed to create an encoder for the audio chunk of a sound font (have yet > to do any meta data block for gzip compressed non-audio data, there will > probably be 2 METADATA blocks to simplify things, one for before and one for > after the audio chunk). All seems to function alright. I do have a few > comments on the design of the libFLAC API. The FLAC__stream_encoder_init() > function call has quite a lot of parameters. Do you forsee a reason to add > or modify any of these in the future? I would think that creating an init > structure to pass to this function would make sense. Or even better would be > to have some functions for setting parameters in the FLAC encoder instance (I > notice you already have functions for getting parameters). The FLAC encoder > instance could then have default values, and there would be certain > parameters that would be required to set. Not setting an optional parameter > would just cause the default to be used. What do you think? It seems like the > current implimentation will be a nightmare to try to keep a backwards > compatible libFLAC API.I think it's a good idea to create a structure to maintain source level compatibility. This reminded me about the issue of binary compatibility, though. Since libFLAC can be built as a shared library, this is an issue which should be addressed starting with 1.0. The soname version should be incremented (it is currently at 0), and future ABI changes must be accompanied by a soname version number increase. This is required to allow programs dynamically linked against libFLAC to continue to work. -- - mdz
> ... > > In fact, this was part of the patch I submitted to allow 'make dist' > and such > to work, and it appears to be in 0.10 (include/FLAC/Makefile.am). I > wonder > why it isn't working... > > Ah, I must have forgotten to add it in configure.in. Here you go: > > --- configure.in 2001/06/14 20:05:43 1.5 > +++ configure.in 2001/06/14 23:55:44thanks, made the patch. Josh __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/
Josh Coalson wrote:> > Good points. I imagine there should be two separate packages; > one for the command line tools, and one like flac-devel, which > has the libs and the includes. BTW in this scenario the files > that are currently in include/FLAC would go in /usr/include/FLAC > and you would do something like #include "FLAC/stream_encoder.h". > Not sure how to accomplish this with libtool/automake yet since > I'm still kind of weak in this area. >Yes, a flac and flac-devel package would work well. I created the libsndfile RPM packages using audiofile's build system as an example. I might be able to do something like this for FLAC. This should probably be cleared up before 1.0? I managed to create an encoder for the audio chunk of a sound font (have yet to do any meta data block for gzip compressed non-audio data, there will probably be 2 METADATA blocks to simplify things, one for before and one for after the audio chunk). All seems to function alright. I do have a few comments on the design of the libFLAC API. The FLAC__stream_encoder_init() function call has quite a lot of parameters. Do you forsee a reason to add or modify any of these in the future? I would think that creating an init structure to pass to this function would make sense. Or even better would be to have some functions for setting parameters in the FLAC encoder instance (I notice you already have functions for getting parameters). The FLAC encoder instance could then have default values, and there would be certain parameters that would be required to set. Not setting an optional parameter would just cause the default to be used. What do you think? It seems like the current implimentation will be a nightmare to try to keep a backwards compatible libFLAC API. Regarding the sound font compressor I'm creating. I am thinking of naming it simply "Sound Font FLAC" (Sound Font Free Lossless Audio Codec) with a file extension of .sfflac (any other suggestions?). Or do you think I should just keep the .flac extension? Someone mistaking the file for a regular FLAC file would get a single sample (which is actually multiple back to back 16 bit samples) which seems alright. Lates.. Josh Green
--- Josh Green <jgreen@users.sourceforge.net> wrote:> Regarding the sound font compressor I'm creating. I am thinking of > naming it simply "Sound Font FLAC" (Sound Font Free Lossless Audio > Codec) with a file extension of .sfflac (any other suggestions?). Or > do > you think I should just keep the .flac extension? Someone mistaking > the > file for a regular FLAC file would get a single sample (which is > actually multiple back to back 16 bit samples) which seems alright.Hmm... I guess it's your call. If you will be doing all the non-audio stuff in FLAC metadata blocks then technically it is still a valid FLAC file, but there's nothing wrong with using a different extension to differentiate it and avoid confusion. Josh __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/
> > For those of you using CVS, I have added a libFLAC section to the > > documentation page. I'm not sure how detailed to make it but I > > think it's a good start. Let me know if there's anything else > > you'd like to have in there. > > > > >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/flac/flac/doc/documentation.html?rev=HEAD> > > > Also, I'm thinking about splitting the encoder into stream > > and file encoders like the decoders are, so the encoder > > interface might change slightly. This will be pretty minor > > and I'll make sure to do it before 1.0. > > > > Josh > > > > What is the procedure for including libFLAC support in a program. The > documentation mentions the public header files which seem to have > fairly > generic names, and I notice they aren't installed after a "make > install". How then should a program that uses libFLAC find these > header > files? This doesn't seem like the usual setup for a library. > Shouldn't > there be like one header file "libflac.h" or "flac.h" or something > that > gets installed in the system /usr/include? Also perhaps a flac-config > shell script that describes the C and LIBS flags to compile flac > support. As things are right now it looks like one would have to > package > the header files with a program or have the user set a config flag to > point to the flac source header files.Good points. I imagine there should be two separate packages; one for the command line tools, and one like flac-devel, which has the libs and the includes. BTW in this scenario the files that are currently in include/FLAC would go in /usr/include/FLAC and you would do something like #include "FLAC/stream_encoder.h". Not sure how to accomplish this with libtool/automake yet since I'm still kind of weak in this area.> I also noticed that stream_encoder.h isn't in the 0.10 version > release, > is this only in CVS currently?Yes, this was done after 0.10 went out. Josh __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/
On Thu, Jun 14, 2001 at 03:03:57PM -0700, Josh Coalson wrote:> Good points. I imagine there should be two separate packages; > one for the command line tools, and one like flac-devel, which > has the libs and the includes. BTW in this scenario the files > that are currently in include/FLAC would go in /usr/include/FLAC > and you would do something like #include "FLAC/stream_encoder.h". > Not sure how to accomplish this with libtool/automake yet since > I'm still kind of weak in this area.This is already being done (by me) for the Debian packages. I create packages for: - The reference encoder/decoder (flac) - The shared library libFLAC.so.0 (libflac0) - The development library and headers (libflac-dev) - The XMMS plugin (xmms-flac) Personally, I think this is beyond the scope of the flac source distribution, and should be left to those who are creating binary packages. The makefiles should just install the include files. In fact, this was part of the patch I submitted to allow 'make dist' and such to work, and it appears to be in 0.10 (include/FLAC/Makefile.am). I wonder why it isn't working... Ah, I must have forgotten to add it in configure.in. Here you go: --- configure.in 2001/06/14 20:05:43 1.5 +++ configure.in 2001/06/14 23:55:44 @@ -70,5 +70,7 @@ src/plugin_xmms/Makefile \ src/test_streams/Makefile \ src/test_unit/Makefile \ + include/Makefile \ + include/FLAC/Makefile \ test/Makefile \ ) -- - mdz