Autotools pkgconfig

[schnitzeltony]

These two patches make qmmp/projectm analyser on RaspberryPi3 build and work!! OK a bit slow but this is the first time I see something...

[revmischa]

Yay, thanks for adding pkg-config back! This is great.

I'm very curious how it's compiling at all on raspi. I thought raspi only supported OpenGLES, which does not have any support for the immediate-mode calls - see https://github.com/projectM-visualizer/projectm/blob/master/glES-porting.txt

[revmischa]

These were added here - #53 (diff)
What's the difference? What are the compatibility issues?

[schnitzeltony]

With CMake the files were installed to:

/usr/include/libprojectM

With Autotools all files are installed to

/usr/include

This is what this patch changes to avoid breakages in projects depending on projectM. Unfortunately it breaks make dist (haven't tested - my bad). I will try to fix and come back when I have something better. As said that might last because it is a just for fun issue to me and during the week there is not much time left for pure fun stuff...

How about a resend with pkg-config patch only and see if that passes Travis. If OK you can take that one before.

[revmischa]

the files should definitely all be installed to /usr/include/libprojectM, I'm pretty sure. So if they are now, great! Just update the test and we should be good to go. And do test out make dist if you get a chance.

[revmischa]

👍 💯 yay!

[revmischa]

There is one failing test - https://travis-ci.org/projectM-visualizer/projectm/jobs/366837109#L4317
The command "test -e dist_install/include/projectM.hpp" exited with 1.

Was this file being installed in the wrong place?

Please fix the test and/or add more tests for the new files you're installing (the .pc file and one or two new headers)

[schnitzeltony]

1. The dist part error is caused moving headers back I guess. Will look into and send V2 as soon as I have something. It might last a bit because I cannot check this with Openembedded build easily...
2. RaspberryPi has an open source driver: mesa/VC4. That supports OpenGLES 2.0 AND OpenGL 2.1 (aka desktop OpenGL). Since benchmarks for OpenGL are less than 10% slower than OpenGLES ones, I decided to build qtbase with GL instead GLES. That (and the patches sent) did the trick that qmmp accepts projectm. If you look into qmmp/src/plugins/Visual/projectm/CMakeList.txt there is a check for qtbase GL:

# projectM
MESSAGE(STATUS "Found OpenGL implementation: ${Qt5Gui_OPENGL_IMPLEMENTATION}")
IF(${Qt5Gui_OPENGL_IMPLEMENTATION} STREQUAL GL)
  pkg_search_module(PROJECTM libprojectM>=2.0.0)
  ADD_DEFINITIONS(${PROJECTM_CFLAGS})
ELSE(${Qt5Gui_OPENGL_IMPLEMENTATION} STREQUAL GL)
  MESSAGE(WARNING "Unsuppoted OpenGL implementation, projectM disabled")
ENDIF(${Qt5Gui_OPENGL_IMPLEMENTATION} STREQUAL GL)

Maybe it makes sense to add something similar here for Qt5 frontend - but first let's get this into shape...

[revmischa]

Awesomesauce. Does qmmp use projectM? Feel free to add it on the README!

[revmischa]

Need anything from me?

[schnitzeltony]

Not really - the only thing I need is a bit of time...

If you want you can apply the pkg-config patch. Or shall I send out a V2 with only that patch to get it tested by travis?

[revmischa]

Okay I think this is a simple thing to fix. I'll try it out.