[vlc-devel] State of broken CI for 3.0?

[David Fuhrmann]

> Am 15.06.2021 um 08:21 schrieb Steve Lhomme <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:
>>>> 
>>>> /Users/videolan/builds/puw5iUHi/0/videolan/vlc/extras/package/macosx/..
>>>> /../../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:
>> prefix=/Users/videolanci/builds/o5P11sBb/0/videolan/vlc/contrib/aarch64-apple-darwin19 exec_prefix=/Users/videolanci/builds/o5P11sBb/0/videolan/vlc/contrib/aarch64-apple-darwin19 libdir=/Users/videolanci/builds/o5P11sBb/0/videolan/vlc/contrib/aarch64-apple-darwin19/lib includedir=/Users/videolanci/builds/o5P11sBb/0/videolan/vlc/contrib/aarch64-apple-darwin19/include Other .pc files usually have something like this:
>> prefix=@@CONTRIB_PREFIX@@
>> exec_prefix=${prefix}
>> libdir=@@CONTRIB_PREFIX@@/lib
>> includedir=@@CONTRIB_PREFIX@@/include
> 
> This job [1] 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:
> 
> change_prefix.sh /Volumes/External/videolanci/builds/o5P11sBb/0/videolan/vlc/contrib/aarch64-apple-darwin19 @@CONTRIB_PREFIX@@
> 
> But some of the pathes don't match this path, they have
> /Users/videolanci/builds/o5P11sBb/0/videolan/vlc/contrib/aarch64-apple-darwin19
> instead of
> /Volumes/External/videolanci/builds/o5P11sBb/0/videolan/vlc/contrib/aarch64-apple-darwin19
> 
> 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 ?


Hi,

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…

BR. David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20210615/dfe9ecc7/attachment.html>