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

[Steve Lhomme]

On 2021-06-15 10:11, Steve Lhomme wrote:
> 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.

As noted in the MR, the .pc files are already correct in 4.0 but not in 
3.0 for macos-arm64, even after my patch. The x64 macos build has the 
proper values in the .pc files in 3.0. Maybe a different version of cmake ?