@ras0219-msft Do the qt failures look like the -j change?

@Neumann-A Do those qt project failures look like fallout from the -j change that our binary caching scheme hid?

@BillyONeal. Could be. I remember seeing that failure once but cannot remember if the fix was to remove the -j flag. I tried finding a commit which added and then removed the -j flag but couldn't find it.
we could try to add all the commands added in https://stackoverflow.com/questions/5303634/qmake-qmakespec-has-not-been-set
and print the information just to get an idea whats going wrong or simply pass the full path to the spec via -spec or replace the

TargetSpec=win32-msvc
HostSpec=win32-msvc

in the qt_(release|debug).conf with absolute paths to the right directory. It could also be that something else is wrong in the qt.conf but this would be surprising since the build without -j does work.

/azp run microsoft.vcpkg.clean-tombstones

/azp help

/azp list

/azp list

/azp run

@BillyONeal Looks like LLVM is now working! but qt5 still isn't >.<

There are probably races in qt's bits, I just tried installing these locally and they worked :(. So I'll need to revert that :/

There are probably races in qt's bits, I just tried installing these locally and they worked :(. So I'll need to revert that :/

Yeah a problem I know too well. CI fails but locally everything works fine. Did you try it in WSL or real Linux? Was there any speed improvement with the -j flag ?

@Neumann-A I used real Linux. It cut build time for the entire ports tree almost in half.

/azp run

Hmm any way for me to force the failure in CI via a PR or is there no way to do it in a single PR?

@Neumann-A I don't know of a good way to force it, no. I'm going to try one more thing before backing the change out completely...

@BillyONeal Maybe add a ENV variable for it ENV{VCPKG_X_DISABLE_PARALLEL_QT}. So Users still benefit from it but you can disable it in CI.

@Neumann-A If it's going to sporadically fail in CI that means it can for users too and we should back it out. I'm trying a complete archives rebuild in case some of the previous builds were wrong due to the missing disable parallel switch. We'll see how it goes. If that still fails I'm going to revert completely.

If it's going to sporadically fail in CI that means it can for users too and we should back it out

But if there is never an error nobody will try to fix it or will try to add the parallel flag again and we probably won't remember the issue. If we have the escape hatch users which have the issue can use ENV{VCPKG_X_DISABLE_PARALLEL_QT} while the others can benefit from the faster build

Now we're seeing flaky behavior on Windows so I'm totally reverting that :/

fatal error C1001: Internal compiler error.

Nothing Qt can be blamed for.

@Neumann-A Well looks like it wasn't the -j. Any ideas?

@Neumann-A I think I know why it's broken. The qt scripts are trying to form a relative path from the installed directory to the packages directory, which doesn't work when they're both symlinks like this change does.

@BillyONeal: Maybe try asking @Rastaban if he remembers the cannot find mkspec error on linux and changed something in the CI to make it work. Alternatively you could try to make all paths in qt_release.conf and qt_debug.conf absolute. They are setup at

@Neumann-A I tried an alternate method of getting work running in /mnt which doesn't need to create individual symlinks, we'll see if that works.

/azp run