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

[Lyndon Brown]

On Tue, 2021-06-15 at 14:38 +0200, Steve Lhomme wrote:
> 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/p
> > > > > > > > ackage/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/con
> > > > > > trib/aarch64-apple-darwin19 
> > > > > > exec_prefix=/Users/videolanci/builds/o5P11sBb/0/videolan/vl
> > > > > > c/contrib/aarch64-apple-darwin19 
> > > > > > libdir=/Users/videolanci/builds/o5P11sBb/0/videolan/vlc/con
> > > > > > trib/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/c
> > > > > ontrib/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/aarc
> > > > > h64-apple-darwin19 
> > > > > 
> > > > > instead of
> > > > > /Volumes/External/videolanci/builds/o5P11sBb/0/videolan/vlc/c
> > > > > ontrib/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 ?
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


Thanks for the analysis, and to whoever ultimately fixed the problem,
it seems to be working fine now. :)