ci build alpine: add workaround for msgpack-c to resolve relative paths

[otegami]

The following error happened when building docker images for Alpine Linux.

• ref: https://github.com/pgroonga/docker/actions/runs/9554591639/job/26335983002

 > [linux/amd64 stage-0 4/4] RUN /build.sh 3.2.0 14.0.2 && rm -f build.sh:
366.6 libtool: error: cannot determine absolute directory name of 'lib'
366.6 make[4]: *** [Makefile:1025: libgroonga.la] Error 1
366.6 make[4]: Leaving directory '/build/groonga-14.0.2/lib'

The cause of this error

Adding --prefix=/usr/local during configuration step, we expected the
libdir path like /user/local/lib. But the actual path is /lib without prefix
because this prefix isn't reflected to pkgconfig file.
This is the same problem is this PR: msgpack/msgpack-c#1119

$ cat /usr/lib/pkgconfig/msgpack-c.pcprefix=/usrexec_prefix=/usrlibdir=libincludedir=includeName: MessagePackDescription: Binary-based efficient object serialization libraryVersion: 6.0.1Libs: -L${libdir} -lmsgpack-cCflags: -I${includedir}

Solution

We re-write the msgpack-c.pc which can handle prefix path as a workaround.
This workaround is referred to this commit: groonga/groonga@8275463.
This problem has already fixed at upstream.
So after new version releasing, we can delete this workaround.

• ref: https://github.com/msgpack/msgpack-c/blob/a5c8a2c845ba43100b7cad7f8a8db0c2ce361d1e/CMakeLists.txt#L33-L42

Additionally, I checked the build step passed here.

• ref: https://github.com/otegami/pgroonga-docker/actions/runs/9610854142/job/26508201198

[otegami]

Additionally, I checked the build step passed here.

• https://github.com/otegami/pgroonga-docker/actions/runs/9610413895

I realized that I couldn't check whether this image could be built or not on CI.
I checked here. https://github.com/otegami/pgroonga-docker/actions/runs/9610854142

[kou]

Can we solve this by using CMake?
We will drop support for GNU Autotools. So using CMake based build system is better than using workaround for GNU Autotools based build system.

[otegami]

Sure. I think it's good timing to use CMake because we can test it at this time too,

[otegami]

I'm going to close this issue and then open a new PR for solving this issue using CMake.