Ben has committed the use of extraPrefix to the builder config...

And I think this broke things for OSX now! See e.g. https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/10/console

Perhaps a rebuild from scratch is needed now!

I don't know the details of extraPrefix, but I just remember [one of René's recent posts on cmake's prefix[(https://lists.macosforge.org/pipermail/macports-users/2015-June/038794.html):

For all ye cmake gurus: have I overlooked the documentation for cmake's `--prefix` option or is it indeed an undocumented feature?
I just discovered that it has an effect that's slightly different from CMAKE_INSTALL_PREFIX ...

Thanks,
R.

Perhaps we revert this change for now and do a clean rebuild of qt5+KF5+apps on a separate CI system to study this more deeply, as from now on all projects will fail on OSX, which is why I am taking down both our builders.

Or remove the macports that already have a system lib?

Or remove the macports that already have a system lib?

I don't understand what you mean.

How will we recover from this now?
OB2 won't be available over the weekend, I have to say, as I am otherwise busy.
Time for some more hardware, again. :-)

Let me know if I can do something without having access to OB2.

Well I tried to remove jpeg from ob1 and we enter a dependency hell problem. It seems to me though that we want to use system libs rather than macports in most cases.
fwiw /opt/local/lib/libjpeg.dylib exists but notice the case is different.

I really don't see a way to proceed without forcing the use of system libs before macports via:
'export CFLAGS="-isystem/opt/local/include" \n' + 'export CXXFLAGS="-isystem/opt/local/include" \n'

But as Ben had me remove that I will have to wait for him to give suggestions. I am going to turn off OSX for the weekend (or until I hear from Ben) So have a good weekend.

Well, whether we're using MacPorts' libs or the system ones is a decision to make!
Right now we have a mix of both anyways.
In some cases it might be better to use the system, in others one has to go for MacPorts version!

Re libjpeg.dylib: Ah, case (in)sensitivity hits us once again! (I had not noticed that yet.)

Your CFLAGS trick seems to be a must at the moment. :(

Yeah, let's wait for him and keep both OBs offline until we come up with a good plan.

BTW, I am happy that I saw this happening right at the beginning and could take both the builders down before an avalanche of build failures arose. :)

Should we perhaps add him to this task?

Now that it is decided that MacPorts is to be isolated totally, we probably need to do something like what Boudewijn does for krita...

Or will we just create even more external projects in the way the CI system already supports now and supplement that with a new feature to create a self-containing application package instead?

Either way is a major undertaking, but unavoidable, as all dependencies should be system and vanilla.

Yet, one thing should not be forgotten in the process, MacPorts is there and would like to deliver all dependencies as it currently does.

As Rene always says: it's the freedom of choice we should keep. That holds for the dependence on tools and libs as well as something like the XDG_* env variables!!!

See T430 regarding removing MacPorts from qt5.