[Flac-dev] 1.0 candidate checked in

Matt Zimmerman mdz at debian.org
Sun Jul 22 02:41:38 PDT 2001


On Sun, Jul 22, 2001 at 12:28:52AM -0700, Josh Coalson wrote:

> 2. Applied Matt's last cleanup patch of 8 files.  I did not apply the patch
> to src/test_unit/main.c since it looks wrong.  main.c is supposed to include
> the local bitbuffer.h, not src/libFLAC/private/bitbuffer.h; I think the
> current version is correct.

Ah, I missed that there was a local bitbuffer.h.  In that case, what I should
have done was add bitbuffer.h to test_unit_SOURCES.

> 6. 'Improved' the flac.sgml rule to fall back to docbook2man if there's no
> docbook-to-man (this should really be handled in configure.in).
> 
> I hope this is all correct!  I had do go back and reread the last 40 mails to
> make sure.  Everything is checked in to CVS.  Now I need Matt's and Ben's
> help again.  Try the latest CVS.  I am guessing it will work for Matt and
> break for Ben.  If it breaks, try using Makefile.in.libtool-1.4b and let me
> know if that works.

Everything works except for VPATH builds.  One thing that got lost was the
addition of -I $(srcdir)/ to the NASM command line, which means nasm.h isn't
found when building outside of srcdir.  Also, since ordinals.h is
autogenerated, we need to add -I $(top_builddir)/include to CFLAGS so it can be
found.  For the same reason, the headers need to use #include <FLAC/blah.h>
instead of #include "blah.h", since they will not necessarily be in the same
directory.  Right now, this only matters for ordinal.h, of course, but for
consistency's sake they should all work this way.

None of this is important enough to delay the release, really.  I've attached a
patch for the first two items which you can apply or not as you see fit.

> If getting the CVS tree is too much pain, I checked in a new tarball in the
> same place:
> 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/flac/junk/flac-1.0-src-candidate.tar.bz2
> 
> Hopefully we're getting closer because within the next couple of days I am
> going to get busy with other things and probably won't be able to put a lot
> of time into this for a few weeks.  I wasn't expecting libtool to blow up in
> my face... it was working so well for a while.

Everything works when I build in the source tree, which is probably what >99%
of users will do.  If you want to release, I don't object.

-- 
 - mdz
-------------- next part --------------
Index: configure.in
===================================================================
RCS file: /cvsroot/flac/flac/configure.in,v
retrieving revision 1.25
diff -u -r1.25 configure.in
--- configure.in	2001/07/22 07:27:45	1.25
+++ configure.in	2001/07/22 09:40:32
@@ -136,7 +136,7 @@
 AC_SUBST(FLaC__USIZE64)
 
 SAVE_CFLAGS="$CFLAGS"
-CFLAGS='-I$(srcdir)/include -I $(top_srcdir)/include -Wall -W'
+CFLAGS='-I$(top_builddir)/include -I$(srcdir)/include -I$(top_srcdir)/include -Wall -W'
 if test x$debug = xtrue; then
 	CFLAGS="$CFLAGS -g -O0 -DDEBUG"
 else
Index: src/libFLAC/ia32/Makefile.am
===================================================================
RCS file: /cvsroot/flac/flac/src/libFLAC/ia32/Makefile.am,v
retrieving revision 1.7
diff -u -r1.7 Makefile.am
--- src/libFLAC/ia32/Makefile.am	2001/07/22 07:26:58	1.7
+++ src/libFLAC/ia32/Makefile.am	2001/07/22 09:40:35
@@ -21,7 +21,7 @@
 STRIP_FPIC = sh $(top_srcdir)/strip_fPIC.sh
 
 .nasm.lo:
-	$(LIBTOOL) --mode=compile $(STRIP_FPIC) $(NASM) -f $(OBJ_FORMAT) -d OBJ_FORMAT_$(OBJ_FORMAT) $< -o $@
+	$(LIBTOOL) --mode=compile $(STRIP_FPIC) $(NASM) -f $(OBJ_FORMAT) -d OBJ_FORMAT_$(OBJ_FORMAT) -I $(srcdir)/ $< -o $@
 
 noinst_LTLIBRARIES = libFLAC-asm.la
 libFLAC_asm_la_SOURCES = \


More information about the Flac-dev mailing list