osgaudio OpenALpp fails to detect openal headers on linux.

[th3flyboy]

OpenALpp appears to be failing to detect the OpenAL headers on Linux.
My suspicion is because the OpenAL headers are under include/AL/*.h
rather than in the openalpp or the root include folder. Does anyone
have any suggestions on how to fix this?

[Paul Martz]

include/AL is one of the path suffixes in FindOpenAL.cmake, so I'm not sure why
CMake isn't finding the header. Do you have OPENALDIR or OPENAL_PATH set
incorrectly in your environment?

On a tangential note, CMake ships with a FindOpenAL.cmake, so I'm not sure we
need our own local copy. Ours does appear to contain some (osgAL-era) mods not
found in the CMake version, but IMO the CMake version should be fixed if it's
broken, and osgAudio should just use the stock CMake scripts when possible.

--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/

[Paul Martz]

On 11/22/2010 7:49 AM, Paul Martz wrote:
> On 11/21/2010 9:36 PM, th3flyboy wrote:
>> OpenALpp appears to be failing to detect the OpenAL headers on Linux.
>> My suspicion is because the OpenAL headers are under include/AL/*.h
>> rather than in the openalpp or the root include folder. Does anyone
>> have any suggestions on how to fix this?
>
> include/AL is one of the path suffixes in FindOpenAL.cmake, so I'm not sure why
> CMake isn't finding the header. Do you have OPENALDIR or OPENAL_PATH set
> incorrectly in your environment?

Sorry, did I misunderstand you? I assumed you meant CMake couldn't find the
headers, but now I'm starting you think that CMake found the header OK, but the
compiler failed to find the header when building openalpp...? If the latter,
then this would have to be a CMake fix, I'd think.

[Doug McCorkle]

I like the idea of switching out scripts.

Doug

[th3flyboy]

I'm trying to build using SCONS. I am encountering this while running
trying to build the application I am working on. CMake seems to detect
it fine, but SCONS isn't working properly. I'm going to investigate
this more when I get home (I'm at school now), however I suspect my
scons may me messed up. The curious thing is that this didn't happen
under osgAL and it's included version of OpenALPP. I am currently
trying to port a program from osgAL to osgAudio, however it seems that
this doesn't want to play nice, as while it detected OpenAL just fine
with osgAL, OpenAL won't detect properly with osgAudio. I suspect I
may have messed up my sconscript in trying to build, and that may be
causing the problem, however it works just fine building using osgAL,
just not osgAudio, which makes me wonder.

[Paul Martz]

Check for this command line param to your compiler:
-I<path-to-openal-install>/include/AL
openalpp requires it.

Comparing osgAL's AudioBase header to osgAudio's AudioBase.h header shows they
both use "#include <al.h>", indicating osgAL has the same -I requirement as
osgAudio. This leads me to believe something is screwed up on your side.
-Paul

[th3flyboy]

I think I found what is causing the problems. OpenALPP was looking for
the include file in the root include folder, and SCONS wasn't working
properly with pkgconfig because openALPP wanted it with no folder
before the file, so it would look for it in the wrong place. I fixed
it by symlinking the include files in to the root include folder.
Personally, I have an idea on a better fix for this, but it will have
to wait for a day or two.

[th3flyboy]

I've uploaded a third version of the package config scripts to the
issue I created for those scripts. This will fix the problems with
OpenAL header detection using pkgconfig when trying to build apps that
use SCONS as a build system with OpenALPP.

[Paul Martz]

Actually, Sukender has recently updated all the CMake find scripts and
submitted it as issue 7:
http://code.google.com/p/osgaudio/issues/detail?id=7

As part of the change, he chose to delete our custom findosg.cmake and
use the stock FindOpenSceneGraph.cmake instead. Not sure why he left
our custom FindOpenAL.cmake... I'm trying his changes this evening,
and am also using the stock FindOpenGL.cmake, and it appears to work
fine for me.

We should probably consider using the stock FindOpenSceneGraph.cmake
for all our projects, as this script dates from way back when CMake
support for finding OSG was pretty cruddy.

[Paul Martz]

Hi -- I met with Chris F2F last week, and we discussed adding CPack support to
osgAudio (and osgWorks, and osgBullet...).

I am not really an expert in CPack or pkgconfig, but my understanding is that
CPack provides a superset of packaging support; it eliminates the need for a
pkgconfig file. For this reason, before we proceed with adding a pkgconfig file
to the osgAudio project, I think we should have a discussion on the best way to
provide this functionality. What would a pkgconfig file provide that could not
be provided by proper CPack support, for example?

Thanks,
-Paul

[Doug McCorkle]

In my mind CPack and pkgconfig are two completely different things. CPack, as I understand it enables users to easily create rpms, exe installers, dmg images, and other binaries for easy packaging and installation of a tool. Pkgconfig on the other hand helps with defining the link, include, and processor defines need to USE a library in a build system. In my mind I think you need both.

Doug

> --
> You received this message because you are subscribed to the Google Groups "osgAudio-users" group.
> To post to this group, send email to osgaudi...@googlegroups.com.
> To unsubscribe from this group, send email to osgaudio-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/osgaudio-users?hl=en.
>

[Paul Martz]

On 11/26/2010 11:26 AM, Doug McCorkle wrote:
> In my mind CPack and pkgconfig are two completely different things. CPack, as I understand it enables users to easily create rpms, exe installers, dmg images, and other binaries for easy packaging and installation of a tool. Pkgconfig on the other hand helps with defining the link, include, and processor defines need to USE a library in a build system. In my mind I think you need both.

Thanks for the info. With this in mind, I've attempted to integrate these
changes. However, they conflict with the recent CMake changes from issue 7,
which predate this issue 8.

I've checked in the pkgconfig changes on a branch:
http://osgaudio.googlecode.com/svn/branches/pc
and I've asked th3flyboy to send me a merged version of CMakeLists.txt, which
I'll then use to reintegrate that branch into trunk. Then I'll delete the branch.