Hi KOS,
I wonder if GStreamer is placing the configuration headers into the
/usr/lib64 directory as a means of having a 32 and 64 versions installed on
the same machine. It's a pretty horrible cludge whatever the reason.
I reminds me a bit of an out of source build of the OSG using CMake where
the out of source build directory contains a local include/osg/Config
rather than place it in the original OpenSceneGraph/include/osg/
directory. If you are building against an OSG that is built this way and
you haven't installed it then you need two include dirs, the Cflags entry
from the gstreamer.pc is where this "magic" happens for your
gstreamer-1.5.2.
I suspect the original FindGStreamer.cmake is setting the
PC_GSTREAMER_INCLUDE_DIRS with all the paths required, but the subsequent
find_path is just looking for the gst/gst.h which it finds in a single
directory so returns that directory rather all the original ones found in
the PC_GSTREAMER_INCLUDE_DIRS variable.
Perhaps one way around the issue is to have two find_path calls, one for
the gst/gst.h and one for the gst/gstconfig.h and then combine the two
results if they don't agree with each other.
The alternative route would be to find a way of changing the INTERNAL
status to a non INTERNAL one. Perhaps simply copying the variables would
be sufficient. i.e.
pkg_check_modules(PC_${_component_prefix} QUIET ${_pkgconfig_name})
set(${_component_prefix}_INCLUDE_DIRS PC_${_component_prefix}_INCLUDE_DIRS)
mark_as_advanced(${_component_prefix}_INCLUDE_DIRS)
I will try out the above and see what happens,
Robert.
On 17 July 2015 at 17:53, Konstantin <[email protected]> wrote:
> Hello :)
>
> Original (old) version of FindGStreamer.cmake can set only one directory
> and set it to
> /usr/include/gstreamer-1.0;
>
> New version of FindGStreamer.cmake (without PC_) set it to this:
> GSTREAMER_INCLUDE_DIRS:INTERNAL=/usr/include/gstreamer-1.0;
> */usr/lib64/gstreamer-1.0/include*
> ;/usr/include/glib-2.0;/usr/lib64/glib-2.0/include
>
> in the new 1.5.2 GStreamer there are some headers in the lib64 directory
> (don't know why... I can fix it by creating two symbolic links etc. ;)
>
>
>
> *# cd /usr/lib64/gstreamer-1.0*
> *# ls -R include*
>
>
>
>
>
>
>
>
> *include/:gstinclude/gst:gl gstconfig.hinclude/gst/gl:gstglconfig.h*
>
>
>
> PS
>
> gstreamer-1.0.pc looks like
>
>
> prefix=/usr
> exec_prefix=${prefix}
> libdir=/usr/lib64
> includedir=${prefix}/include/gstreamer-1.0
> toolsdir=${exec_prefix}/bin
> pluginsdir=/usr/lib64/gstreamer-1.0
> datarootdir=${prefix}/share
> datadir=${datarootdir}
> girdir=${datadir}/gir-1.0
> completionsdir=${datarootdir}/bash-completion/completions
> helpersdir=${datarootdir}/bash-completion/helpers
> typelibdir=${libdir}/girepository-1.0
>
> Name: GStreamer
> Description: Streaming media framework
> Version: 1.5.2
> Requires: glib-2.0, gobject-2.0
> Requires.private: gmodule-no-export-2.0
> Libs: -L${libdir} -lgstreamer-1.0
> *Cflags*: -I${includedir} *-I${libdir}/gstreamer-1.0/include*
>
>
>
> 2015-07-17 20:16 GMT+04:00 Robert Osfield <[email protected]>:
>
>> Hi KOS,
>>
>> I have done a trial merge of your proposed changes to FindGStreamer.cmake
>> and it works on my Kubuntu 14.04 system with gstreamer-1.4.5 installed -
>> gstreamer is found and the gstreamer plugin compiles and links without any
>> errors.
>>
>> However, there is a difference in behaviour that makes me hesitant to
>> merge right away. The old code goes through the extra step of using
>> pkg_check_modules on a PC_ prefixed names, then uses these to use Cmake
>> standard find_path and find_library to set up the actual final cmake
>> variables that the plugin uses. The only reason I can spot for this odd
>> extra step is the CMake standard find_ approach places the set up variables
>> in scale that ccmake can edit, while the pkg_check_modules variables are
>> hidden as they are set to INTERNAL.
>>
>> I presume making the variables visiable and editable in ccmake allows
>> users a an easy way to double check paths and edit where appropriate.
>>
>> Did you found out why the original code was failing in your case?
>>
>> Robert.
>>
>> On 17 July 2015 at 15:50, Konstantin <[email protected]> wrote:
>>
>>> Hello, Robert.
>>>
>>> I've mentioned in the "osg-users" ML about build error with the newest
>>> GStreamer 1.5
>>>
>>> Please, have a look at the attached patch.
>>>
>>> CMakeModules/FindGStreamer.cmake
>>>
>>>
>>> KOS
>>>
>>>
>>>
>>> _______________________________________________
>>> osg-submissions mailing list
>>> [email protected]
>>>
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>>
>>>
>>
>> _______________________________________________
>> osg-submissions mailing list
>> [email protected]
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>>
>
> _______________________________________________
> osg-submissions mailing list
> [email protected]
>
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
