On Sun, Apr 16, 2017 at 11:09 PM, Harald Sitter <sit...@kde.org> wrote: > Not particularly related to the issue at hand (which is probably > polkitqt having meh cmake files), but relocating stuff in general is > suuuuper unreliable and I would absolutely advise against it as it can > easily screw up test results and builds alike, often in unobvious ways > (all it takes is a bit of libexec use). Instead, as a general > principle, I would suggest that you get stuff mounted in suitably > stable/consistent/generic paths inside the build containers. > Ultimately what things look like natively on the host file system > shouldn't factor into what they look like in the build environment.
While I have thought of using a consistent path, this would simply workaround the fact that our binaries are frail and have hardcoded paths baked into them. The CI has always run an unusual configuration as part of it's job is to find brittle parts of our codebase and make the breakage visible. Outside of traditionally provided FOSS packaging, relocatable binaries are something we'll need - for Windows packages for instance as users there expect to be able to specify the installation directory (on that note - log for kcoreaddons on Windows is attached with several test failures, and it looks like the logic around ASAN on Windows needs adjustment too). We'll see how things go. > > For example, in neon we simply mount everything into /workspace of our > containers. > > You could have > > /workspace > |_ src/ [on host: /home/jenkins/workspace/polkit-qt-1 kf5-qt5 > XenialQt5.7/ > |_ install/ [on host: /home/jenkins/workspace/polkit-qt-1 kf5-qt5 > XenialQt5.7/install-prefix/] The workspaces are, on the Linux systems at least, thrown away at the completion of a job. The only thing that survives is a tarball archive of the files installed by the job. > > Notably advantage is that relocation issue get entirely eliminated as > the install prefix is always the same, and as an added bonus paths > become much shorter and easier to read in the build logs. > > It also detaches the build tooling from the host tooling. e.g. the > build code at this point no longer needs to care about which path > Jenkins was installed to, or where it was configured to put > workspaces, or what the jenkins job name is, or if jenkins is even > still used. > > Food for thought :) > > HS Cheers, Ben
kcoreaddons-windows-build.log
Description: Binary data
