why does installing wt need to rebuild qt5-base?

[duyanning]

I had installed qt5-base and it took me a lot of time.
next day, i want to install wt.
it surprised me when vcpkg says:
The following packages will be rebuilt:

• harfbuzz[core,glib,ucdn]:x86-windows
• qt5-base[core]:x86-windows

tragedy!
why?

[MVoz]

with the entire support \ dependence

qt5-base[core]

qt5[*]

[JackBoosY]

Hi @duyanning Since the dependent port qt5-base has been updated, qt5-base needs to be rebuilt.

[heydojo]

So much wrong here, I don't know where to start.

• OP is asking a support question in an issues thread.

TBH Microsoft can monetise vcpkg support or offer a means to offer user support elsewhere (for user errors and such) - a bulletin board forum for instance. This prevents developers wasting their time "supporting" instead of developing code. This issues section isn't the place for supporting users with their mistakes when they attempt to use vcpkg.

• OP is building x86 binaries.

Is this really still a thing in 2019 - That x86 binaries are the default instead of the system native architecture. What's so difficult about vcpkg detecting the OS arch and defaulting to it?

• OP is asking a support question which the documentation should be able to explain. In that it appears that OP pulled an update to vcpkg and was not aware of how to do so correctly. They were then shocked when software required rebuilding. If OP has a slow machine (another user issue) the fact that vcpkg builds both release and debug by default (unless you use triplet(s)) means that builds can take a horrendous length of time to complete. Especially for Qt.

Is the documentation not clear enough about what to do and how to do it?
And if not, can it be improved to avoid unconstructive criticism, such as that coming from OP in this issue report, occurring again?

If you visit:
https://github.com/microsoft/vcpkg/tree/master/ports
You will see the message:

Sorry, we had to truncate this directory to 1,000 files. 68 entries were omitted from the list.

and:
https://github.com/microsoft/vcpkg/tree/master/ports/wt
is not displayed. Along with the 68 other entries omitted.

Is it time to subdivide the ports folders into categories or some other such and/or time to speak to the github developers about the folder display limit issue?

[duyanning]

* e then

it's NOT a question. It's a bug report.
I did not 'git pull' between installing qt5-base and installing wt.
I installed qt5-base and go to bed.
the next morning, i want to install wt and vcpkg tell me that qt5-base needs to rebuild.

[JackBoosY]

@Neumann-A Can you have a look? Thanks.

[Neumann-A]

@JackBoosY. I think the problem here is that harfbuzz requires different features for wt and qt as such if harfbuzz is rebuild qt also has to be rebuild
If we look at the output of depend-info:

$ ./vcpkg depend-info wt | findstr harfbuzz 
harfbuzz[glib, ucdn]: freetype, glib, ragel
pango: cairo, fontconfig, freetype, gettext, glib, harfbuzz

$ ./vcpkg depend-info qt5-base | findstr harfbuzz
harfbuzz[ucdn]: freetype, ragel
qt5-base: double-conversion, freetype, harfbuzz, libjpeg-turbo, libpng, libpq, openssl, pcre2, sqlite3, zlib

we see qt5-base requires harfbuzz[ucdn] while wt requires harfbuzz[glib, ucdn] so harfbuzz must be rebuild if qt has been build first and as such qt5-base also requires a rebuild. One note: Since I am missing support for #8269 harfbuzz[glib, ucdn] might make problems with static builds of qt5 due to the glib dependency (dynamic builds should be fine though.)

[JackBoosY]

@Neumann-A I think your answer captures the point.
When different libraries (A, B, C ...) depend on the same library (Z), it is likely that these libraries (A, B, C ...) need different features of the dependent library (Z), and These features are not enabled by default. This will cause the dependent library (Z) to be rebuilt. If the dependent library (Z) is large, a lot of time is wasted.
So I suggest adding all the libraries you want to install in the install command, so vcpkg will automatically analyze the features that need to be enabled and avoid this situation.

To be honest, I have no good way.

@heydojo

OP is asking a support question in an issues thread.

I think the key to this issue is that the generated port does not contain the required features and needs to be rebuilt.

Is this really still a thing in 2019 - That x86 binaries are the default instead of the system native architecture. What's so difficult about vcpkg detecting the OS arch and defaulting to it?

I think choosing the default triplet based on the system architecture is a wrong way. Because the x64 architecture is compatible with x86 binary, and most libraries support the x86 architecture (no need for larger pointers or larger memory support), most engineers choose the x86 architecture as the default generated configuration.

OP is asking a support question which the documentation should be able to explain.
Is the documentation not clear enough about what to do and how to do it?
And if not, can it be improved to avoid unconstructive criticism, such as that coming from OP in this issue report, occurring again?

The documentation for vcpkg is too simple and we need to improve it. Thanks for the suggestion!

Is it time to subdivide the ports folders into categories or some other such and/or time to speak to the github developers about the folder display limit issue?

This needs to be discussed.

[BillyONeal]

The "registries" feature splits the ports tree into a-/ports that start with a, b-/ports that start with b, etc. so that will help a bit

[JackBoosY]

We hope your question was answered to your satisfaction; if it wasn't, you can reopen with more info.