1. 26 Sep, 2016 1 commit
  2. 04 Sep, 2008 1 commit
  3. 30 Jan, 2008 1 commit
  4. 07 Jun, 2005 1 commit
    • Thomas Vander Stichele's avatar
      - remove AUTOMAKE_OPTIONS from underlying Makefile.am · ac38ce1c
      Thomas Vander Stichele authored
      - make autogen error out on toolchain failures
      - reorder configure.in to get rid of the errors
      - make an AM_CONDITIONAL for FLAC builds so building with flac detected works
      - make heavy use of config.h so we don't have gcc compile lines that are
        1000 characters long
      - make make distcheck pass
      svn path=/trunk/vorbis-tools/; revision=9393
  5. 15 Sep, 2003 1 commit
  6. 24 Jun, 2003 1 commit
    • Ralph Giles's avatar
      Fix the conditional build stuff. · 17e3b7f8
      Ralph Giles authored
      First, do configure substitution on the top-level subdirs, with DIST_SUBDIRS backup to include everything in 'make dist'. This is cleaner than the previous method of conditionalizing the program-specific makefiles.
      Second, switch to configure addition of conditional obj files for optional codec support in ogg123. the AM_CONDITIONAL source method is cleaner for this since the build details are all in the Makefile. However, this only really works in automake 1.7; earlier versions require the matching object files to be in the _LDADD and _DEPENDENCIES lines. If configure is generating these anyway, we might as well simplify the Makefile.am's to rely entirely on substitution.
      Also, check for the OggFLAC library as well as FLAC, since these can be installed independently on some distributions.
      svn path=/trunk/vorbis-tools/; revision=4995
  7. 11 Jul, 2002 1 commit
  8. 04 Jul, 2002 3 commits
  9. 02 Jul, 2002 3 commits
  10. 26 Jan, 2002 1 commit
  11. 21 Dec, 2001 3 commits
  12. 04 Jul, 2001 1 commit
  13. 19 Feb, 2001 1 commit
    • jsquyres's avatar
      This is a horrible compromise just for the sake of getting beta4 out the · 37ea15a1
      jsquyres authored
      door, and it's a more complicated issue than one would think,
      so read everything before you draw any conclusions.  :-)
      The issues:
      It is not a good idea to double-instantiate functions/variables that
      the underlsying OS already provides.  getopt() and friends are a good
      example of this.  However, some systems don't have the getopt-kinds of
      functionality that is used in the tools (i.e., some do, some don't).
      Hence, we include the GNU
      definitions of getopt(), getopt_long(), and their associated global
      variables.  GNU libc systems will effectively nullify our included
      copies due to clever #if statements in the files.  POSIX systems that
      have getopt() (but not getopt_long()) will have a double instantiation
      of getopt() and the global variables.  This appears to not cause any
      problems (but it still isn't Right).
      The short-term solution:
      Copy getopt.c, getopt.h, and getopt1.c into each of the directories in
      the vorbis-tools tree, and let each tool compile and link their own
      local copies.  We do this because we know *it works*, and we need to get
      beta4 out the door.  This commit copies them into
      vorbis-tools/vorbiscomment (they were already in oggenc and ogg123).
      The long-term solution:
      After beta4 is out the door and we have time for proper testing, we'll
      remove the getopt* files from each tool directory and create a new
      directory named "support/", and put them in there.  But with a few
      - getopt() will be commented out.  We don't use it, anyway -- we only
      use getopt_long() (getopt() is not used to implement getopt_long()).
      - tests will be added in configure to check for getopt() on the local
      system.  If it's already there, we won't instantiate the global
      variables in getopt.c (since the OS already provides them).
      - there's still indecision on whether to name the included copy of
      getopt.h to be something different (e.g,. "ov_getopt.h") to prevent a
      name clash with the OS's copy (if it has one).  To be decided later...
      - the relevant .c files will be compiled into a static convenience
      library, libvtsupport.a.
      - each of the tool directories will "-l$(top_builddir)/support
      -lvtsupport" when linking their binaries
      - if other functions come up like this (that exist on some systems but
      not on others), we can add them into libvtsupport.a.
      svn path=/trunk/vorbis-tools/; revision=1319
  14. 25 Jan, 2001 1 commit
    • Ralph Giles's avatar
      · 09997c65
      Ralph Giles authored
      use _LDADD instead of the over-riding _LDFLAGS for ogg, vorbis and ao libs
      improve order for static linking
      Thanks for Jeff Squyres for this one.
      svn path=/trunk/vorbis-tools/; revision=1220
  15. 19 Jan, 2001 1 commit
    • Ralph Giles's avatar
      · 9ae08cff
      Ralph Giles authored
      Added something resembling a cmdline interface to the new vorbiscomment
      example code. You can say
         vorbiscomment [-l] <file>
      and have it dump the comments to stdout, and
         vorbiscomment -w <infile> <outfile>
      and have it read a replacement set of comments from stdin.
      Still needs some polishing, but it's at least marginally useful
      now. I also tried to lay it out so it remained easy to read as
      a code example.
      The Makefile has been changed to build/install vorbiscomment by
      default again, mostly on Monty's approval.
      svn path=/trunk/vorbis-tools/; revision=1173
  16. 17 Jan, 2001 1 commit
    • Michael Smith's avatar
      · 586d3413
      Michael Smith authored
      Killed off vorbiscomment (at last).
      Added a new comment editor.
       vcedit.[ch] is the core of it. Provides a potentially usable API.
       vcomment.c builds a completely useless frontend on top of it, to show how to
           use the API.
      svn path=/trunk/vorbis-tools/; revision=1168
  17. 18 Nov, 2000 1 commit
  18. 04 Nov, 2000 1 commit
  19. 03 Oct, 2000 2 commits
  20. 11 Sep, 2000 2 commits