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

[Steve Lhomme]

On 2021-06-15 9:19, Steve Lhomme wrote:
> 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:
>>>>>>
>>>>>> /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…
> 
> 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.
> 
> https://code.videolan.org/videolan/vlc/-/merge_requests/259
> 
> I'll inspect the generated contribs once they are built.

It works, taglib.pc for macos-arm64 has prefix=@@CONTRIB_PREFIX@@
That's a 4.0 build but I don't think it should change for 3.0.

I have to fix an issue with AOM but we should be able to fix things with 
this MR.