Some patches used in Debian openal-soft package

[Andres Mejia]

Hi,

I've attached the patches that are used for building the Debian openal-soft
packages. I've attached them in the order that they are applied so they can be
more easily reviewed. I've ensured that these patches apply cleanly to git HEAD.

The first patch (install-alsoft.conf.patch) is used to optionally install
alsoftrc.sample as a configuration file in /etc/openal/alsoft.conf. It is optional
and must be set so that someone who may be building and installing the openal-
soft libraries directly from a source tarball don't get their alsoft.conf file
overwritten unintentionally.

The second patch applies right after the first and is used to install an openal-
config script and corresponding manpage. I don't know if this is really
necessary, but it seems that there are still programs out there that rely on
openal-config. See [1].

The third patch adds the actual openal-config script. You may need to set the
execute bit on the file after it's applied.

The fourth patch adds the manpage for openal-config.

The fifth patch is used to allow Debian packages to build the static library. I'm
not sure if this is necessary still. In any case, it applies after applying all
other patches.

1. http://www.linuxquestions.org/questions/linux-software-2/openal-config-718012/

--
Regards,
Andres

[install-alsoft.conf.patch]

---

Patch to optionally install alsoft.conf file
==========================================================================
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -35,6 +35,8 @@
 
 OPTION(EXAMPLES  "Build example programs"              ON)
 
+OPTION(ALSOFT_CONFIG "Install alsoft.conf configuration file" OFF)
+
 
 IF(WIN32)
     SET(LIBNAME OpenAL32)
@@ -406,6 +408,13 @@
 INSTALL(FILES "${OpenAL_BINARY_DIR}/admin/pkgconfig/openal.pc"
         DESTINATION "${LIB_INSTALL_DIR}/pkgconfig")
 
+# Install alsoft.conf configuration file
+IF(ALSOFT_CONFIG)
+    INSTALL(FILES alsoftrc.sample DESTINATION /etc/openal
+        RENAME alsoft.conf
+    )
+ENDIF()
+
 IF(EXAMPLES)
     ADD_EXECUTABLE(openal-info examples/openal-info.c)
     TARGET_LINK_LIBRARIES(openal-info ${LIBNAME})

---

[install-openal-config.patch]

---

Modify CMakeLists.txt to install openal-config.
==========================================================================
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -362,13 +362,17 @@
 # This is always available
 SET(BACKENDS  "${BACKENDS} WaveFile")
 
-# Needed for openal.pc.in
+# Needed for openal.pc.in and openal-config
 SET(prefix ${CMAKE_INSTALL_PREFIX})
 SET(exec_prefix "\${prefix}")
 SET(libdir "\${exec_prefix}/${LIB_INSTALL_DIR}")
 SET(bindir "\${exec_prefix}/bin")
 SET(includedir "\${prefix}/include")
 SET(PACKAGE_VERSION "${LIB_VERSION}")
+EXECUTE_PROCESS(COMMAND date +%Y-%m-%d
+                OUTPUT_VARIABLE date_var
+                OUTPUT_STRIP_TRAILING_WHITESPACE)
+SET(DATE ${date_var})
 
 # End configuration
 CONFIGURE_FILE(
@@ -378,6 +382,14 @@
     "${OpenAL_SOURCE_DIR}/admin/pkgconfig/openal.pc.in"
     "${OpenAL_BINARY_DIR}/admin/pkgconfig/openal.pc"
     @ONLY)
+CONFIGURE_FILE(
+    "${OpenAL_SOURCE_DIR}/admin/openal-config.in"
+    "${OpenAL_BINARY_DIR}/admin/openal-config"
+    @ONLY)
+CONFIGURE_FILE(
+    "${OpenAL_SOURCE_DIR}/admin/openal-config.1.in"
+    "${OpenAL_BINARY_DIR}/admin/openal-config.1"
+    @ONLY)
 
 ADD_DEFINITIONS(-DAL_BUILD_LIBRARY)
 
@@ -407,6 +419,10 @@
 )
 INSTALL(FILES "${OpenAL_BINARY_DIR}/admin/pkgconfig/openal.pc"
         DESTINATION "${LIB_INSTALL_DIR}/pkgconfig")
+INSTALL(FILES "${OpenAL_BINARY_DIR}/admin/openal-config"
+        DESTINATION bin)
+INSTALL(FILES "${OpenAL_BINARY_DIR}/admin/openal-config.1"
+        DESTINATION /usr/share/man/man1)
 
 # Install alsoft.conf configuration file
 IF(ALSOFT_CONFIG)

---

[add-openal-config.patch]

---

Add openal-config.in file
==========================================================================
--- /dev/null
+++ b/admin/openal-config.in
@@ -0,0 +1,173 @@
+#!/bin/sh
+
+prefix="@prefix@"
+exec_prefix="@exec_prefix@"
+bindir="@bindir@"
+includedir="@includedir@"
+libdir="@libdir@"
+PACKAGE_VERSION="@PACKAGE_VERSION@"
+
+openal_dynamic_ldflags="-lopenal"
+openal_static_ldflags="-lopenal"
+
+prefix_set=no
+echo_prefix=no
+exec_prefix_set=no
+echo_exec_prefix=no
+bindir_set=no
+echo_bindir=no
+includedir_set=no
+echo_includedir=no
+libdir_set=no
+echo_libdir=no
+echo_version=no
+echo_cflags=no
+static_libs=no
+echo_libs=no
+
+usage()
+{
+  cat <<EOF 1>&2
+Usage: openal-config [OPTIONS]
+Options:
+  --prefix[=DIR]       print/set default prefix
+  --exec-prefix[=DIR]  print/set prefix for machine-specific files
+  --bindir[=DIR]       print/set prefix for executable programs
+  --includedir[=DIR]   print/set prefix for include files
+  --libdir[=DIR]       print/set prefix for libraries
+  --version            print OpenAL package version
+  --cflags             print flags for C compiler
+  --static             specify that static linker flags are wanted
+  --libs               print flags for linker
+EOF
+  exit 1
+}
+
+if test $# -eq 0; then
+  usage
+fi
+
+while test $# -gt 0; do
+  case "$1" in
+  -*=*) optarg=`echo "$1" | sed 's/[-_a-zA-Z0-9]*=//'` ;;
+  *) optarg="" ;;
+  esac
+
+  case $1 in
+    --prefix=*)
+      prefix="${optarg}"
+      prefix_set="yes"
+      ;;
+    --prefix)
+      echo_prefix="yes"
+      ;;
+    --exec-prefix=*)
+      exec_prefix="${optarg}"
+      exec_prefix_set="yes"
+      ;;
+    --exec-prefix)
+      echo_exec_prefix="yes"
+      ;;
+    --bindir=*)
+      bindir="${optarg}"
+      bindir_set="yes"
+      ;;
+    --bindir)
+      echo_bindir="yes"
+      ;;
+    --includedir=*)
+      includedir="${optarg}"
+      includedir_set="yes"
+      ;;
+    --includedir)
+      echo_includedir="yes"
+      ;;
+    --libdir=*)
+      libdir="${optarg}"
+      libdir_set="yes"
+      ;;
+    --libdir)
+      echo_libdir="yes"
+      ;;
+    --version)
+      echo_version="yes"
+      ;;
+    --cflags)
+      echo_cflags="yes"
+      ;;
+    --static)
+      static_libs="yes"
+      ;;
+    --libs)
+      echo_libs="yes"
+      ;;
+    *)
+      usage
+      ;;
+  esac
+  shift
+done
+
+if test "${echo_prefix}" = "yes"; then
+  echo "${prefix}"
+fi
+
+if test "${exec_prefix_set}" = "no" && test "${prefix_set}" = "yes"; then
+  exec_prefix="$prefix"
+  exec_prefix_set="yes"
+fi
+
+if test "$echo_exec_prefix" = "yes"; then
+  echo "${exec_prefix}"
+fi
+
+if test "${bindir_set}" = "no" && test "${exec_prefix_set}" = "yes"; then
+  bindir="${exec_prefix}/bin"
+fi
+
+if test "$echo_bindir" = "yes"; then
+  echo "${bindir}"
+fi
+
+if test "${includedir_set}" = "no" && test "${prefix_set}" = "yes"; then
+  includedir="${prefix}/include"
+fi
+
+if test "$echo_includedir" = "yes"; then
+  echo "${includedir}"
+fi
+
+if test "${libdir_set}" = "no" && test "${exec_prefix_set}" = "yes"; then
+  libdir="${exec_prefix}/lib"
+fi
+
+if test "$echo_libdir" = "yes"; then
+  echo "${libdir}"
+fi
+
+if test "$echo_version" = "yes"; then
+  echo "${PACKAGE_VERSION}"
+fi
+
+if test "$echo_cflags" = "yes"; then
+  if test "${includedir}" = "/usr/include" ; then
+    incpath=""
+  else
+    incpath="-I${includedir}"
+  fi
+  echo "${incpath}"
+fi
+
+if test "$echo_libs" = "yes"; then
+  if test "${libdir}" = "/usr/lib" ; then
+    libpathflag=""
+  else
+    libpathflag="-L${libdir}"
+  fi
+  if test "${static_libs}" = "yes"; then
+     ldflags="${openal_static_ldflags}"
+  else
+     ldflags="${openal_dynamic_ldflags}"
+  fi
+  echo "${libpathflag} ${ldflags}"
+fi

---

[add-openal-config-manpage.patch]

---

Add the openal-config manpage.
==========================================================================
--- /dev/null
+++ b/admin/openal-config.1.in
@@ -0,0 +1,57 @@
+.TH openal-config 1 "@DATE@" "@PACKAGE_VERSION@"
+.SH NAME
+openal-config \- script to get information about the installed version of OpenAL
+.SH SYNOPSIS
+.B openal-config
+[ \-\-prefix=\fIDIR\fR ]
+[ \-\-exec-prefix=\fIDIR\fR ]
+[ \-\-version ] [ \-\-cflags ] [ \-\-libs ]
+.SH DESCRIPTION
+.B openal-config
+is a tool that is used to configure and determine the compiler and linker flags
+that should be used to compile and link programs and libraries that use OpenAL.
+.SH OPTIONS
+.TP
+.B \-\-cflags
+Print the compiler flags that are necessary to compile a program or library that
+uses OpenAL.
+.TP
+.BI \-\-exec\-prefix= DIR
+If specified, use \fIDIR\fR instead of the installation exec prefix that OpenAL
+was built with when computing the output for the \-\-cflags and \-\-libs
+options. This option must be specified before any of the \-\-cflags and \-\-libs
+options.
+.TP
+.B \-\-libs
+Print the linker flags that are necessary to link a program or library that uses
+OpenAL.
+.TP
+.BI \-\-prefix= DIR
+If specified, use \fIDIR\fR instead of the installation prefix that OpenAL was
+built with when computing the output for the \-\-cflags and \-\-libs options.
+If \-\-exec\-prefix was not specified, \fIDIR\fR is also used as exec prefix.
+This option must be specified before any of the \-\-cflags and \-\-libs options.
+.TP
+.B \-\-version
+Prints the currently installed version of OpenAL on standard output.
+.SH EXAMPLES
+.PP
+To compile a C source file for use in an executable program that uses OpenAL,
+type a command like this:
+.IP
+.B gcc $(openal\-config \-\-cflags) \-c main.c \-o main.o
+.PP
+To link the resulting object file into an executable program, use a command like
+the following:
+.IP
+.B gcc \-o my_app main.o util.o $(openal\-config \-\-libs)
+.SH AUTHOR
+OpenAL was written by Juan Carlos Arevalo Baeza, Jonathan Blow, Keith Charley,
+Scott Draeker, John Grantham, Jacob Hawley, Garin Hiebert, Carlos Hasan, Nathan
+Hill, Bill Huey, Mike Jarosch, Jean-Marc Jot, Maxim Kizub, John Kraft, Bernd
+Kreimeier, Ian Ollmann, Rick Overman, Sean L. Palmer, Sven Panne, Pierre
+Phaneuf, Terry Sikes, Joseph Valenzuela, Michael Vance, Carlo Vogelsang, and
+Chris Robinson.
+.PP
+This manual page was written by Thierry Reding for the Debian Project (but may
+be used by others).

---

[static_lib.patch]

---

Support building of static libraries
=====================================================================
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -20,6 +20,9 @@
 
 SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE)
 
+# Add option to build static libraries
+OPTION(BUILD_STATIC "build static library too" OFF)
+
 
 OPTION(ALSA    "Check for ALSA backend"                ON)
 OPTION(OSS     "Check for OSS backend"                 ON)
@@ -406,6 +409,21 @@
 
 TARGET_LINK_LIBRARIES(${LIBNAME} ${EXTRA_LIBS})
 
+# Build static libraries if specified
+IF(BUILD_STATIC)
+  # we can't create a static library with the same name
+  # as the shared one, so we use OUTPUT_NAME
+  ADD_LIBRARY(openal_static STATIC ${OPENAL_OBJS} ${ALC_OBJS})
+  SET_TARGET_PROPERTIES(openal_static PROPERTIES OUTPUT_NAME ${LIBNAME})
+  IF(WIN32)
+      SET_TARGET_PROPERTIES(openal_static PROPERTIES PREFIX "")
+  ENDIF()
+  TARGET_LINK_LIBRARIES(openal_static ${EXTRA_LIBS})
+  INSTALL(TARGETS openal_static
+          ARCHIVE DESTINATION lib
+  )
+ENDIF(BUILD_STATIC)
+
 # Add an install target here
 INSTALL(TARGETS ${LIBNAME}
         RUNTIME DESTINATION bin

---

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

Hi Andres.

Out of curiosity, how many unmaintained projects are there that require
openal-config, and can't be patched by distros to use pkg-config instead?
IIRC, the old OpenAL also used pkg-config, so using that should still work
fine for both the old and new library.

Honestly, I find all the non-centralized *-config scripts to be really messy,
and the less temptation for people to use them, the better, IMO. At least pkg-
config keeps it all tidy and works through an established interface for all
packages, whereas separate *-config scripts sometimes have "unique" options
and behaviors, making things more confusing in the end.

That is, unless someone can convince me otherwise. But the maintenance cost
and usability of such a script, especially when a pkg-config script is already
available, doesn't seem worth it to me.

> The first patch (install-alsoft.conf.patch) is used to optionally install
> alsoftrc.sample as a configuration file in /etc/openal/alsoft.conf. It is
> optional and must be set so that someone who may be building and installing
> the openal- soft libraries directly from a source tarball don't get their
> alsoft.conf file overwritten unintentionally.

Perhaps it would be better to install it as alsoft.conf.example, or something.
The given alsoftrc.sample isn't intended to be used as a "default"
configuration file, but to show and explain how to use the various options.

> The fifth patch is used to allow Debian packages to build the static
> library. I'm not sure if this is necessary still. In any case, it applies
> after applying all other patches.

I've been vocal about this before, but I still do not think it's wise to
build/install a static lib of OpenAL on systems that can use dynamic libs.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Andres Mejia]

On Sunday 17 May 2009 06:12:23 Chris Robinson wrote:

> Hi Andres.
>
> Out of curiosity, how many unmaintained projects are there that require
> openal-config, and can't be patched by distros to use pkg-config instead?
> IIRC, the old OpenAL also used pkg-config, so using that should still work
> fine for both the old and new library.
>
> Honestly, I find all the non-centralized *-config scripts to be really
> messy, and the less temptation for people to use them, the better, IMO. At
> least pkg- config keeps it all tidy and works through an established
> interface for all packages, whereas separate *-config scripts sometimes
> have "unique" options and behaviors, making things more confusing in the
> end.
>
> That is, unless someone can convince me otherwise. But the maintenance cost
> and usability of such a script, especially when a pkg-config script is
> already available, doesn't seem worth it to me.

I don't have any opinion on the use of such a script. I will drop that from the
Debian packages.

> > The first patch (install-alsoft.conf.patch) is used to optionally install
> > alsoftrc.sample as a configuration file in /etc/openal/alsoft.conf. It is
> > optional and must be set so that someone who may be building and
> > installing the openal- soft libraries directly from a source tarball
> > don't get their alsoft.conf file overwritten unintentionally.
>
> Perhaps it would be better to install it as alsoft.conf.example, or
> something. The given alsoftrc.sample isn't intended to be used as a
> "default" configuration file, but to show and explain how to use the
> various options.

Something I see done in such a case is to either have everything commented out
or set the options to the default that would be used by a program anyway. I see
the configuration file is already written with the latter approach in mind. The
configuration file is then installed in the location the program would read for
system wide settings, under /etc/*. It's then up to the user to modify the
configuration file.

The configuration file may certainly be renamed as alsoft.conf.example, but it
means a user has to move the file and then edit the file, as opposed to just
editing the file. This is something I think is unnecessary as alsoft.conf has the
default options enabled anyway.

> > The fifth patch is used to allow Debian packages to build the static
> > library. I'm not sure if this is necessary still. In any case, it applies
> > after applying all other patches.
>
> I've been vocal about this before, but I still do not think it's wise to
> build/install a static lib of OpenAL on systems that can use dynamic libs.

In this case, I'll drop the last patch and building of static libs in the Debian
package as you did supply the ability to create static libs via -DLIBTYPE=STATIC
(I didn't see that before). I suppose anyone wanting the static libs could just
grab the source and build it themselves.

--
Regards,
Andres
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Sunday 17 May 2009 10:17:41 am Andres Mejia wrote:
> Something I see done in such a case is to either have everything commented
> out or set the options to the default that would be used by a program
> anyway. I see the configuration file is already written with the latter
> approach in mind. The configuration file is then installed in the location
> the program would read for system wide settings, under /etc/*. It's then up
> to the user to modify the configuration file.

That can be done, I guess. My only concern would be package managers that
don't like their installed files to be externally modified.. Gentoo, for
example, will not remove a file when uninstalling if the md5sum or some other
property doesn't match what it was installed with. Subsequently, trying to
install a package when the file exists may cause a complaint that existing
files will be overwritten.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Andres Mejia]

On Sunday 17 May 2009 15:35:11 Chris Robinson wrote:

> On Sunday 17 May 2009 10:17:41 am Andres Mejia wrote:
> > Something I see done in such a case is to either have everything
> > commented out or set the options to the default that would be used by a
> > program anyway. I see the configuration file is already written with the
> > latter approach in mind. The configuration file is then installed in the
> > location the program would read for system wide settings, under /etc/*.
> > It's then up to the user to modify the configuration file.
>
> That can be done, I guess. My only concern would be package managers that
> don't like their installed files to be externally modified.. Gentoo, for
> example, will not remove a file when uninstalling if the md5sum or some
> other property doesn't match what it was installed with. Subsequently,
> trying to install a package when the file exists may cause a complaint that
> existing files will be overwritten.

I think most distros have this similar behavior. I know in Debian, configurations
are only removed if you explicitly set to purge the package, as opposed to just
removing. Also, on package upgrades, the configuration file is not overwritten if
it detects that the user edited the configuration file.

Also, I don't know about other distros, but for Debian packaging, files get
installed in a temporary directory, under <top_src_dir>/debian/tmp, and then
from here all the files are moved from here to the corresponding package. Nothing
is ever packaged up from the actual system directories. I would be surprised if
something similar is not done for creating some other distro packages. In this
case, there's never worry that configuration files that have been edited are
overwritten.

With the patch, a user has to set that they want the configuration file installed.
So even for users that build directly from source, they won't be overwriting
their configuration files unless they explicitly set to install them.

--
Regards,
Andres
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Sunday 17 May 2009 1:19:18 pm Andres Mejia wrote:
> I think most distros have this similar behavior. I know in Debian,
> configurations are only removed if you explicitly set to purge the package,
> as opposed to just removing. Also, on package upgrades, the configuration
> file is not overwritten if it detects that the user edited the configuration
> file.

On upgrades, Gentoo tries to merge "trivial" changes, but would otherwise ask
you if you want to keep the old config, use the new one, or manually merge the
two by hand.

> With the patch, a user has to set that they want the configuration file
> installed. So even for users that build directly from source, they won't be
> overwriting their configuration files unless they explicitly set to install
> them.

The config file has been cleaned up/reformatted, and can be installed using
that option, now. The options are listed with their default values, but are
commented out.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Jason Daly]

Chris Robinson wrote:
> Hi Andres.
>
> Out of curiosity, how many unmaintained projects are there that require
> openal-config, and can't be patched by distros to use pkg-config instead?
> IIRC, the old OpenAL also used pkg-config, so using that should still work
> fine for both the old and new library.
>  

I doubt there are many left, however I've seen modern packages (SDL is
one I can think of off the top of my head) still shipping both the .pc
and the -config scripts.  I tend to agree that pkg-config is tidier, but
I'm not sure why it's a maintenance headache to keep both, especially
when they're both automatically generated from .in files anyway.

I'm no package maintainer, so let me know if I'm off base here, but what
about modifying the install process to install the .pc if the host has
pkg-config available and openal-config if not?  I've seen many
auto-configuration scripts (whether autoconf- or cmake-based) that look
for both pkg-config and *-config versions for the same package (in case
one or the other isn't there).  It seems to me that this would maximize
compatibility.

--"J"
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Jason Daly]

Chris Robinson wrote:
> I've been vocal about this before, but I still do not think it's wise to
> build/install a static lib of OpenAL on systems that can use dynamic libs.
>  

What was the reason for that?  I don't recall your vocal objections, I
guess  :-)

--"J"

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Andres Mejia]

On Monday 18 May 2009 05:15:50 Chris Robinson wrote:
> The config file has been cleaned up/reformatted, and can be installed using
> that option, now. The options are listed with their default values, but are
> commented out.

Great, thank you.

--
Regards,
Andres
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Monday 18 May 2009 8:48:33 am Jason Daly wrote:
> I tend to agree that pkg-config is tidier, but
> I'm not sure why it's a maintenance headache to keep both, especially
> when they're both automatically generated from .in files anyway.

The *-config scripts are basically bash/sh scripts, that have a few things
replaced (version number, etc). I'm no expert with bash scripting, though. At
least, not to where I can fully grasp what the script is doing. If something
turns up broken in it, or not working as intended, it would be difficult for
me to fix it. And given that it's preferred to use pkg-config anyway, and
there's little-to-no use for openal-config, it doesn't seem worth it to
include.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Jason Daly]

Chris Robinson wrote:
> The *-config scripts are basically bash/sh scripts, that have a few things
> replaced (version number, etc). I'm no expert with bash scripting, though. At
> least, not to where I can fully grasp what the script is doing. If something
> turns up broken in it, or not working as intended, it would be difficult for
> me to fix it. And given that it's preferred to use pkg-config anyway, and
> there's little-to-no use for openal-config, it doesn't seem worth it to
> include.
>  

It's useful in the cases where the host system doesn't have pkg-config
installed.

If pkg-config is available, I agree it would be the preferred method.  
I'm not convinced it's a good idea to assume that pkg-config is
installed on every machine that OpenAL might be installed on, though.

--"J"
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Andres Mejia]

On Monday 18 May 2009 17:02:34 Jason Daly wrote:

> Chris Robinson wrote:
> > The *-config scripts are basically bash/sh scripts, that have a few
> > things replaced (version number, etc). I'm no expert with bash scripting,
> > though. At least, not to where I can fully grasp what the script is
> > doing. If something turns up broken in it, or not working as intended, it
> > would be difficult for me to fix it. And given that it's preferred to use
> > pkg-config anyway, and there's little-to-no use for openal-config, it
> > doesn't seem worth it to include.
>
> It's useful in the cases where the host system doesn't have pkg-config
> installed.
>
> If pkg-config is available, I agree it would be the preferred method.
> I'm not convinced it's a good idea to assume that pkg-config is
> installed on every machine that OpenAL might be installed on, though.

IMO, the preferred method would be for the build system (whether it be cmake,
autotools, etc.) of whatever program that needs openal cope with finding the
correct information it needs to link with the library, and find the headers.

The pkg-config file may be useful for finding the version, but then again, the
build system of the program should instead be checking the actual functions that
are needed from openal.

--
Regards,
Andres
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Jason Daly]

Andres Mejia wrote:
> IMO, the preferred method would be for the build system (whether it be cmake,
> autotools, etc.) of whatever program that needs openal cope with finding the
> correct information it needs to link with the library, and find the headers.
>
> The pkg-config file may be useful for finding the version, but then again, the
> build system of the program should instead be checking the actual functions that
> are needed from openal.
>  

Well, I think they ideally would do both.  First, use pkg-config (or
whatever) to find it, then do a test for the header and link with a
known symbol to be sure it's there.

Without something like pkg-config, you can only check the usual places
(/usr, /usr/local, ...), which might not catch every case.

--"J"
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Andres Mejia]

On Tuesday 19 May 2009 11:08:17 Jason Daly wrote:

> Andres Mejia wrote:
> > IMO, the preferred method would be for the build system (whether it be
> > cmake, autotools, etc.) of whatever program that needs openal cope with
> > finding the correct information it needs to link with the library, and
> > find the headers.
> >
> > The pkg-config file may be useful for finding the version, but then
> > again, the build system of the program should instead be checking the
> > actual functions that are needed from openal.
>
> Well, I think they ideally would do both.  First, use pkg-config (or
> whatever) to find it, then do a test for the header and link with a
> known symbol to be sure it's there.
>
> Without something like pkg-config, you can only check the usual places
> (/usr, /usr/local, ...), which might not catch every case.

Most build systems are capable of checking various locations for headers and
libraries on different systems. Also, most build systems allow you to specify
where to look for headers and libraries.

I wouldn't want to link to a library that's installed in a non-standard
location.

--
Regards,
Andres
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Jason Daly]

Andres Mejia wrote:
> I wouldn't want to link to a library that's installed in a non-standard
> location.
>  

That's pretty short-sighted.  People may have very good reasons to
install libraries in a non-standard location.

Where I work, we install many of our dependent libraries on an NFS
drive, and link straight to it from there.  This way, we can avoid
having to install 20+ libraries every time we set up a new workstation,
or update two dozen workstations whenever we upgrade a given library.  
It make a lot of sense to do this.

--"J"
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel