[vlc-devel] State of broken CI for 3.0?
robux4 at ycbcr.xyz
Tue Jun 15 06:21:50 UTC 2021
On 2021-06-15 7:59, Steve Lhomme wrote:
> On 2021-06-15 7:53, Steve Lhomme wrote:
>> On 2021-06-14 19:48, Lyndon Brown wrote:
>>> As I'm sure has been noticed, pipelines started failing across the
>>> board yesterday for mac-arm64 on the 3.0.x branch, with an error
>>> whereby the taglib module could not find taglib.h for some reason:
>>> /../../modules/meta_engine/taglib.cpp:52:10: fatal error: 'taglib.h'
>>> file not found
>>> I've noticed that Felix's MRs (248, 254) are now passing CI
>>> successfully, yet mine still won't, whether I re-run the failed run,
>>> create a new pipeline from a rebase, or whether someone else does (e.g.
>>> 232 by David, 228 by Steve)...
>>> Just wondering what the status/situation is. :)
>> There might be an issue with pkgconfig, the <contrib>/include/taglib
>> should be passed. Or maybe the taglib.h file in the pre-built contrib
>> is bogus. But it is extracted.
> taglib.pc has the pathes hardcoded. So unless it's built on the same
> machine with the same path, it cannot work. This is the content of the
> one used by the image:
> Other .pc files usually have something like this:
This job  created the tarball of contribs. It contains a lot of
prefix=@@CONTRIB_PREFIX@@ but many are kept to their original path as well.
Looking at the job it transforms the contrib pathes to a generic value
before creating the tarball:
But some of the pathes don't match this path, they have
It seems to be the case for all CMake based projects. This seems to be
an issue only on macos. A 3.0 prebuilt contrib for win64 doesn't have an
issue with the CMake based projects (there are some /usr and /usr/local
hardcoded though but they are bogus and useless no matter what).
We either have to fix CMake (long term solution) and add that extra user
path to the translated path. Or maybe there is a way to have always one
or the other ?
More information about the vlc-devel