[vlc-devel] State of broken CI for 3.0?
robux4 at ycbcr.xyz
Tue Jun 15 07:19:25 UTC 2021
On 2021-06-15 9:00, David Fuhrmann wrote:
>> Am 15.06.2021 um 08:21 schrieb Steve Lhomme <robux4 at ycbcr.xyz
>> <mailto:robux4 at ycbcr.xyz>>:
>> 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
>> 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
>> instead of
>> 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
>> 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 ?
> I also analysed this issue yesterday evening.
> It is broken for CMake based contribs, working for auto tools based, and
> for FFmpeg pkgconfig, it seems half working, half not working. IIRC they
> have their own sh-based build system...
> I remember that some external drive was recently attached to one /
> some of the macOS builders, (/Volumes/External), and someone wanted to
> include it in the ci builders.
> I am not sure how this was done on the machine, but my first guess is
> that a symlink has been created, which is sometimes resolved, sometimes not.
> I would propose to check again what was done on the mac machine, and
> maybe revert it for now. Or use some alternative solution (bind mount?).
> If it is a symlink, then we can consider patching all contribs to
> support symlinks in the prefix path all the same way, but not sure if
> this is worth the effort…
I modified the CMake contribs to use cmake --install after the build.
The prefix can be forced so hopefully it can be consistent with the one
with have with autotools.
I'll inspect the generated contribs once they are built.
More information about the vlc-devel