linuxsampler-devel

[Linuxsampler-devel] libgig version macro

[Dalton M. <mes...@gm...>]

Hello,

It seems that there is no way to determine the libgig library version at
preprocessing time in order to conditionally use newer methods and avoid
deprecated methods.

This is an important missing feature for a library, and its absence forces
developers to use hacky build system workarounds like this one that uses
CMake to compile a small program that prints `gig::libraryVersion()`,
parses the output, and creates a config header based on the results:

https://github.com/LMMS/lmms/blob/dfa32440dc47d1758101092d6022316b0a85df7c/cmake/modules/FindGig.cmake#L16:L25
https://github.com/LMMS/lmms/blob/dfa32440dc47d1758101092d6022316b0a85df7c/plugins/GigPlayer/CMakeLists.txt#L6-L17

But even then, this workaround is broken on MSVC apparently.

If instead, macros like these were added to gig.h...

#define LIBGIG_VERSION_MAJOR 4
#define LIBGIG_VERSION_MINOR 5
#define LIBGIG_VERSION_REVISION 1

...the problem would be solved from the next libgig version onward.

Thanks,
Dalton

Re: [Linuxsampler-devel] libgig version macro

[Christian S. <sch...@li...>]

On Wednesday, August 27, 2025 9:05:50 PM CEST Dalton Messmer wrote:
[...]
> If instead, macros like these were added to gig.h...
> 
> #define LIBGIG_VERSION_MAJOR 4
> #define LIBGIG_VERSION_MINOR 5
> #define LIBGIG_VERSION_REVISION 1
> 
> ...the problem would be solved from the next libgig version onward.
> 
> Thanks,
> Dalton

Sure!

The problem is, the release version is set by configure.ac, so wherever those 
macros were generated to a public API header file to (e.g. a dedicated new 
libgig_version.h file), it is supposed to work both with automake builds and 
CMake builds.

Would you have a patch to address this?

/Christian