Let command line util "peaq" load the plugin statically

[mincequi]

...also add initial CMake support and let peaq load arbitrary audio files (not just .wav)

Hi there,
i just added some little extensions. Hope that helps.

BR
Manuel

[martinholters]

Welcome and thanks for the contribution!

I'm on board with using decodebin (unless I remember why I haven't done so already).
I wasn't aware of GST_PLUGIN_STATIC_DECLARE/GST_PLUGIN_STATIC_REGISTER. Does that require static linking as well? I guess so?
I'm not using CMake for anything, so I'm not sold on adding a CMakeLists.txt. But if so, I'd prefer switching completely and getting rid of the autotools stuff.

In any case, I'd like to see this tested by CI, which seems to have bitrotted, so let me look at that first and then come back here. But even then, I guess testing without pointing to the plugin (the --gst-plugin-load in e.g.

gstpeaq/src/runtest-1.0.sh

Line 7 in 0b9315e

ODG=`LC_ALL=C $GSTLAUNCH --gst-disable-segtrap --gst-debug-level=2 --gst-plugin-load=.libs/libgstpeaq.so \

) would be helpful for the static loading part. (That's what should work thanks to this change, right?) And also adding a CMake-based build job to the CI configuration would be good, or replacing the existing ones, actually.

Might be helpful to split this into three PRs for the three relatively unrelated changes, too.

This project has relatively priority for me ATM, so give me a few days for trying to fix CI and coming back here. But please feel free to ping eventually...

[mincequi]

I'm on board with using decodebin (unless I remember why I haven't done so already). I wasn't aware of GST_PLUGIN_STATIC_DECLARE/GST_PLUGIN_STATIC_REGISTER. Does that require static linking as well? I guess so? I'm not using CMake for anything, so I'm not sold on adding a CMakeLists.txt. But if so, I'd prefer switching completely and getting rid of the autotools stuff.

Yes, those macros require static linking. I just added the CMake support for the peaq command line util for now. CMake is nowadays the standard build tool for C/C++ and can replace any other build tool (e.g. autotools, VS, XCode). Well worth considering.

) would be helpful for the static loading part. (That's what should work thanks to this change, right?) And also adding a CMake-based build job to the CI configuration would be good, or replacing the existing ones, actually.

I would have added the CI jobs, but i have no clue about that, yet...i might get deeper into that

Might be helpful to split this into three PRs for the three relatively unrelated changes, too.

Yes, true. I will continue working on my fork and we (or you) can decide, what's worth taking over :)

This project has relatively priority for me ATM, so give me a few days for trying to fix CI and coming back here. But please feel free to ping eventually...

No worries, just take your time. And many thanks for considering my changes.

[martinholters]

Brief update: I have a branch where

• Linux CI is working. Seems like Githubs image for ubuntu-lastest aka. ubuntu-22.04 has some weird issue; it works after updating to ubuntu-24.04 and doing a small adjustment to configure.ac to look for libm. (I hear you about cmake...)
• Windows CI gets a step further. Updating the download link for gstreamer makes download and install succeed but building fails because the glib headers cannot be found. Will have to look into that when at a Windows machine.

And many thanks for considering my changes.

Certainly. I'm happy to see contributions from others.

[martinholters]

Ok, with #26, CI is happy again, but it occurred to me that none of the tests actually call the peaq executable to process WAV files. So none of the changes in this PR would actually be tested. Let me try and change that and then it will finally be time to make further progress here...

[martinholters]

Added said test in #27 and opened #28 for the simplest part of this, switching to decodebin. Hope that's ok for you.