Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[qtbase] add namespace support #22713

Merged
merged 1 commit into from
Feb 1, 2022
Merged

Conversation

abique
Copy link
Contributor

@abique abique commented Jan 23, 2022

Fixes #22712

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have modified or added at least one portfile where deprecated functions are used.

If you feel able to do so, please consider migrating them to the new functions:
vcpkg_install_cmake -> vcpkg_cmake_install (from port vcpkg-cmake)
vcpkg_build_cmake -> vcpkg_cmake_build (from port vcpkg-cmake)
vcpkg_configure_cmake -> vcpkg_cmake_configure (Please remove the option PREFER_NINJA) (from port vcpkg-cmake)
vcpkg_fixup_cmake_targets -> vcpkg_cmake_config_fixup (from port vcpkg-cmake-config)

In the ports that use the new function, you have to add the corresponding dependencies:

{
  "name": "vcpkg-cmake",
  "host": true
},
{
  "name": "vcpkg-cmake-config",
  "host": true
}

The following files are affected:

  • ports/qtbase/portfile.cmake

You have modified or added at least one vcpkg.json where a "license" field is missing.
If you feel able to do so, please consider adding a "license" field to the following files:

  • ports/qtbase/vcpkg.json

Valid values for the license field are listed at https://spdx.org/licenses/

@dg0yt
Copy link
Contributor

dg0yt commented Jan 23, 2022

This cannot be done as a feature: It changes source compatibility. A consuming port which is not prepared for Qt with namespaces will break when another port requires Qt with namespaces.

@abique
Copy link
Contributor Author

abique commented Jan 23, 2022

This cannot be done as a feature: It changes source compatibility. A consuming port which is not prepared for Qt with namespaces will break when another port requires Qt with namespaces.

So we just check if QT_NAMESPACE is set by the triplet?

The point of the feature is to make it discoverable, but the feature is not part of the defaults and needs QT_NAMESPACE to be set in the triplet to actually take effect.

@abique
Copy link
Contributor Author

abique commented Jan 23, 2022

If you build qt with a namespace, anything linking to Qt6::Core will inherit the compile definition -DQT_NAMESPACE=XXX.

Anyway if no feature and triplet only is good for everyone I'm fine with it too.

@dg0yt
Copy link
Contributor

dg0yt commented Jan 23, 2022

The point of the feature is to make it discoverable.

This is what I assumed. However, the side effects are not so obvious.

If you build qt with a namespace, anything linking to Qt6::Core will inherit the compile definition -DQT_NAMESPACE=XXX.

The problem is that forward declarations need to be wrapped by special macros.

@abique
Copy link
Contributor Author

abique commented Jan 23, 2022

I'd like to add that it is really important for me to be able to set the namespace because if you implement a plugin statically linked to qt on mac, you may end up having symbol clashes with the host or other plugins using Qt due to the few objc classes which rely upon a flat namespace, and the only solution I've found is QT_NAMESPACE.

objc[45644]: Class QNSApplication is implemented in both /Users/abique/develop/clap-examples/builds/ninja-vcpkg/host/Debug/clap-host (0x103a6fb58) and /Users/abique/develop/clap-examples/builds/ninja-vcpkg/plugins/Debug/clap-plugins.clap/Contents/MacOS/clap-plugins (0x110bfffe0). One of the two will be used. Which one is undefined.
objc[45644]: Class QCocoaApplicationDelegate is implemented in both /Users/abique/develop/clap-examples/builds/ninja-vcpkg/host/Debug/clap-host (0x103a6fba8) and /Users/abique/develop/clap-examples/builds/ninja-vcpkg/plugins/Debug/clap-plugins.clap/Contents/MacOS/clap-plugins (0x110c00030). One of the two will be used. Which one is undefined.
objc[45644]: Class QNSColorPanelDelegate is implemented in both /Users/abique/develop/clap-examples/builds/ninja-vcpkg/host/Debug/clap-host (0x103a6fbf8) and /Users/abique/develop/clap-examples/builds/ninja-vcpkg/plugins/Debug/clap-plugins.clap/Contents/MacOS/clap-plugins (0x110c00080). One of the two will be used. Which one is undefined.
(and so on...)

@abique
Copy link
Contributor Author

abique commented Jan 23, 2022

The problem is that forward declarations need to be wrapped by special macros.

True, but if they aren't it is a programing mistake. They should be wrapped by QT_NAMESPACE_BEGIN/END (or something similar).

So I don't see it as a valid argument to forbid the feature.

Also you don't specify set(QT_NAMESPACE MyQt) in your triplet by mistake. So it is likely that you really need it, and know what you are doing.

@dg0yt
Copy link
Contributor

dg0yt commented Jan 23, 2022

I'm not arguing that supporting Qt's namespace feature is wrong, or that not using the macros is right. The point is:

  • There are packages and user projects which don't use the macros. If they build without the vcpkg feature enabled, they shall not break with the vcpkg feature enabled.
  • If the vcpkg feature alone doesn't change anything, it is pointless. The task is properly solved by a triplet variable.

It is just the combination of feature and triplet variable which has the potential to create bad user experience, and it can be easily avoided.

Why not add the triplet variable hint to the port's main description?

@abique
Copy link
Contributor Author

abique commented Jan 23, 2022

Why not add the triplet variable hint to the port's main description?

I'm happy with that solution.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have modified or added at least one portfile where deprecated functions are used.

If you feel able to do so, please consider migrating them to the new functions:
vcpkg_install_cmake -> vcpkg_cmake_install (from port vcpkg-cmake)
vcpkg_build_cmake -> vcpkg_cmake_build (from port vcpkg-cmake)
vcpkg_configure_cmake -> vcpkg_cmake_configure (Please remove the option PREFER_NINJA) (from port vcpkg-cmake)
vcpkg_fixup_cmake_targets -> vcpkg_cmake_config_fixup (from port vcpkg-cmake-config)

In the ports that use the new function, you have to add the corresponding dependencies:

{
  "name": "vcpkg-cmake",
  "host": true
},
{
  "name": "vcpkg-cmake-config",
  "host": true
}

The following files are affected:

  • ports/qtbase/portfile.cmake

You have modified or added at least one vcpkg.json where a "license" field is missing.
If you feel able to do so, please consider adding a "license" field to the following files:

  • ports/qtbase/vcpkg.json

Valid values for the license field are listed at https://spdx.org/licenses/

@Neumann-A
Copy link
Contributor

objc[45644]: Class QNSApplication is implemented in both /Users/abique/develop/clap-examples/builds/ninja-vcpkg/host/Debug/clap-host (0x103a6fb58) and /Users/abique/develop/clap-examples/builds/ninja-vcpkg/plugins/Debug/clap-plugins.clap/Contents/MacOS/clap-plugins (0x110bfffe0). One of the two will be used. Which one is undefined.
objc[45644]: Class QCocoaApplicationDelegate is implemented in both /Users/abique/develop/clap-examples/builds/ninja-vcpkg/host/Debug/clap-host (0x103a6fba8) and /Users/abique/develop/clap-examples/builds/ninja-vcpkg/plugins/Debug/clap-plugins.clap/Contents/MacOS/clap-plugins (0x110c00030). One of the two will be used. Which one is undefined.
objc[45644]: Class QNSColorPanelDelegate is implemented in both /Users/abique/develop/clap-examples/builds/ninja-vcpkg/host/Debug/clap-host (0x103a6fbf8) and /Users/abique/develop/clap-examples/builds/ninja-vcpkg/plugins/Debug/clap-plugins.clap/Contents/MacOS/clap-plugins (0x110c00080). One of the two will be used. Which one is undefined.
(and so on...)

you should probably deactivate automatic plugin linkage for your plugin instead of adding unnecessary namespaces

@abique
Copy link
Contributor Author

abique commented Jan 23, 2022

you should probably deactivate automatic plugin linkage for your plugin instead of adding unnecessary namespaces

The plugin can't assume anything about the host. This one may very well be using Qt or not.
I don't think that I can get rid of QNSApplication. Can I?

I think QT_NAMESPACE exists specially for this type of situation: you implement a plugin statically linked to Qt and you want to avoid symbol clash.

@Neumann-A
Copy link
Contributor

you implement a plugin statically linked to Qt

You don't link plugins to plugins which in the static case really means pulling in all the symbols of one plugin into another.

You link plugins to executable and nothing else.

Deactivating plugins is done via setting/adding the target property QT_NO_PLUGINS to the target which should not link plugins.

@JackBoosY JackBoosY added the category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist label Jan 24, 2022
@abique
Copy link
Contributor Author

abique commented Jan 24, 2022

You don't link plugins to plugins which in the static case really means pulling in all the symbols of one plugin into another.

You link plugins to executable and nothing else.

If you want to produce a self-contained DSO and Qt is built statically, then yes you link to the plugins as well.
What you missed I think is that the symbol clash only appears with objective-c. I suppose that objc has its own namespace / symbol table.

@JackBoosY
Copy link
Contributor

If this namespace is not supported by the upstream, we may not accept this.

@abique
Copy link
Contributor Author

abique commented Jan 24, 2022

https://wiki.qt.io/Qt_In_Namespace
@JackBoosY does it answer it?

@JackBoosY
Copy link
Contributor

@Neumann-A What do you think about this?

@Neumann-A
Copy link
Contributor

What do you think about this?

I still think this should currently be simply an overlay

https://wiki.qt.io/Qt_In_Namespace

speaks about different versions of qt and dlopen() (not the same version and static libs)

If you want to produce a self-contained DSO and Qt is built statically, then yes you link to the plugins as well.

"self-contained" would require PRIVATE linkage against Qt not PUBLIC linkage.

Furthermore after reading (Qt unrelated but same problem):
https://github.com/firebase/firebase-ios-sdk/blob/master/docs/firebase_in_libraries.md#using-firebase-sdks-from-static-frameworks
I doubt that your solution is the correct one. For me it seems the problem lies with your usage/setup. So if you want to use your namespace hack please do so in an overlay-port.

@abique
Copy link
Contributor Author

abique commented Jan 24, 2022

I still think this should currently be simply an overlay

Do you mean that I can add a configure option to qtbase from a triplet overlay? Or would it imply to maintain a full copy of the port just for this namespace thing?

speaks about different versions of qt and dlopen() (not the same version and static libs)

You missed the point. The plugin interface is host and plugin vendor neutral. Anyone can implement an host or a plugin. No assumptions can be made about what libs are being used by the host. And the host is actually using dlopen(), and can load multiple plugins in the same process. Also Qt 6.2.0 and Qt 6.2.1 are different versions, even Qt 6.2.0 and Qt 6.2.0 may be incompatible if compiled with different compilers, options, ...

"self-contained" would require PRIVATE linkage against Qt not PUBLIC linkage.

I think we have a different understanding of what PRIVATE and PUBLIC linkage does.

As far as I understand it, this does not affect the exported symbols. It affects which libraries are being pulled during the link phase of another target depending on the previous one.

On linux, I will make every symbols private except my plugin entry by using: target_link_libraries(clap-plugins PRIVATE -Wl,--version-script=${CMAKE_CURRENT_SOURCE_DIR}/linux-clap-plugins.version).
On macos, I'll use: target_link_options(clap-plugins PRIVATE -exported_symbols_list ${CMAKE_CURRENT_SOURCE_DIR}/macos-symbols.txt).

I'll explain again the problem with objective-c. Whatever symbol visibility you've set, the objc's runtime will register the objc's classes into a flat namespace. Which means that within a single objc program, you can't have two objc classes with the same name. The only solution is to use prefix/namespace to avoid name clash.

If you look at https://github.com/qt/qtbase/blob/dev/config_help.txt#L93 you'll see that -qtnamespace is actually a first class citizen of Qt's configure script, and they went through the pain of maintaining it since Qt4. Which shows how important that feature is.

We can continue to argue if what I'm doing is correct or not, and honestly if you can provide a better solution I'd be happy to try it. But here are some facts:

  • I've built the package with a namespace and it solved my issue
  • If Qt has this option and maintains it for years, then it implies that it is useful. They would not be going through this pain otherwise.

@Neumann-A
Copy link
Contributor

Also Qt 6.2.0 and Qt 6.2.1 are different versions, even Qt 6.2.0 and Qt 6.2.0 may be incompatible if compiled with different compilers,

unlikely. PIMPL and bin compat is the strong suite of Qt.

I think we have a different understanding of what PRIVATE and PUBLIC linkage does.
As far as I understand it, this does not affect the exported symbols. It affects which libraries are being pulled during the link phase of another target depending on the previous one.

Your understanding is incomplete. PRIVATE: build requirement; INTERFACE: usage requirement; PUBLIC: both.
How can something be a build requirement only?
Simple, only use the provided stuff in your private headers and sources. This effectively hides away your usage of whatever you link and keeps it out of the link line of consumers, if you are building shared libs (If you build static libs you will still transitively require the linked libs on the link line and cmake will do that for you). As soon as you use something in a public header it is going to be PUBLIC.

I'll explain again the problem with objective-c. Whatever symbol visibility you've set, the objc's runtime will register the objc's classes into a flat namespace. Which means that within a single objc program, you can't have two objc classes with the same name. The only solution is to use prefix/namespace to avoid name clash.

So you are building Qt6 two times? One time with namespaces and one time without? vcpkg does not have an inconsistent view on stuff so that is really not needed here.

Which shows how important that feature is.

The given reason is invalid for that conclusion.

If Qt has this option and maintains it for years, then it implies that it is useful. They would not be going through this pain otherwise.

Yeah it is useful for vendoring Qt. E.g. If you have a superbuild of paraview and your internal Qt version is different from most systems. Then you can simply vendor Qt yourself add a pv libinfix and do the namespace stuff to get different mangled names. This make sure that your vendored version of Qt gets pulled in and avoids problems with different Qt versions. But that is not the point here.

@abique
Copy link
Contributor Author

abique commented Jan 24, 2022

Also Qt 6.2.0 and Qt 6.2.1 are different versions, even Qt 6.2.0 and Qt 6.2.0 may be incompatible if compiled with different compilers,

unlikely. PIMPL and bin compat is the strong suite of Qt.

I'll give you one scenario:

  • host happen to provide symbols for QtCore only
  • plugin links with both QtCore and QtWidgets, but happens to use QtCore from the host (thanks to the dynamic linker) and QtWidgets from the plugin

If the host uses Qt 6.2 and the plugin Qt 6.3, I would not be so sure that everything is going to be fine.
Also if it happens that some classes in QtWidgets uses the internal parts of QtCore (they call it d-pointer), this one maybe has a different layout depending on the version or the compiler options. I haven't read all the code so I may be wrong here but for sure I would not bet that the compatibility is guaranteed.

I'll explain again the problem with objective-c. Whatever symbol visibility you've set, the objc's runtime will register the objc's classes into a flat namespace. Which means that within a single objc program, you can't have two objc classes with the same name. The only solution is to use prefix/namespace to avoid name clash.

So you are building Qt6 two times? One time with namespaces and one time without? vcpkg does not have an inconsistent view on stuff so that is really not needed here.

I'd make one triplet for the host and one for the plugins so they can work together without clashing. Consider that the host and plugins are made by different vendors, and when you're going to sell the plugin to a customer, you want to be 100% sure that it won't clash with the host or another plugin, and you want your plugin to be a single file that contains all its dependencies.

@dg0yt
Copy link
Contributor

dg0yt commented Jan 25, 2022

I haven't read all the code so I may be wrong here but for sure I would not bet that the compatibility is guaranteed.

Qt is one of the most strict projects with regard to ABI compatibility. However, there are limitations.

I intentionally kept my points short. Offering namespaced Qt via triplet variables is reasonable. However, given that it won't be tested in vcpkg CI, there might be good reasons to be careful with adding this behaviour to the port.

@JackBoosY JackBoosY added the requires:vcpkg-team-review This PR or issue requires someone on the vcpkg team to take a further look. label Jan 25, 2022
@abique
Copy link
Contributor Author

abique commented Jan 25, 2022

I intentionally kept my points short. Offering namespaced Qt via triplet variables is reasonable. However, given that it won't be tested in vcpkg CI, there might be good reasons to be careful with adding this behaviour to the port.

If that helps I can write additional documentation in the port file, and I can add some logging if the QT_NAMESPACE is being used.

We can add a comment that QT_NAMESPACE is here for convenience but its use is not supported nor tested by the CI. From a user perspective, having to maintain a copy of the port, also leads to untested territory.

@alcroito
Copy link
Contributor

Qt offers a QT_NAMESPACE define because some users need it.
I'm not sure what's the correct vcpkg mechanism to expose it, but I don't see why it shouldn't be made available in some form.

And as for CI testing, that's no different from not testing the various combinations of features that the port is already exposing.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

After committing all other changes, the version database must be updated
git add -u && git commit
git checkout 2e34a79a814551424d9b1a981b3b110e0a8fbdfd -- versions
./vcpkg x-add-version --all
Diff
diff --git a/versions/q-/qtbase.json b/versions/q-/qtbase.json
index d6468a4..b496559 100644
--- a/versions/q-/qtbase.json
+++ b/versions/q-/qtbase.json
@@ -1,7 +1,7 @@
 {
   "versions": [
     {
-      "git-tree": "b4ca465db6819d674343bae9c81bdfeca8843bca",
+      "git-tree": "f85e1985bf8c5b27a2ab67cc1fc14b848a09c2b2",
       "version-semver": "6.2.2",
       "port-version": 4
     },

You have modified or added at least one portfile where deprecated functions are used.

If you feel able to do so, please consider migrating them to the new functions:
vcpkg_install_cmake -> vcpkg_cmake_install (from port vcpkg-cmake)
vcpkg_build_cmake -> vcpkg_cmake_build (from port vcpkg-cmake)
vcpkg_configure_cmake -> vcpkg_cmake_configure (Please remove the option PREFER_NINJA) (from port vcpkg-cmake)
vcpkg_fixup_cmake_targets -> vcpkg_cmake_config_fixup (from port vcpkg-cmake-config)

In the ports that use the new function, you have to add the corresponding dependencies:

{
  "name": "vcpkg-cmake",
  "host": true
},
{
  "name": "vcpkg-cmake-config",
  "host": true
}

The following files are affected:

  • ports/qtbase/portfile.cmake

You have modified or added at least one vcpkg.json where a "license" field is missing.
If you feel able to do so, please consider adding a "license" field to the following files:

  • ports/qtbase/vcpkg.json

Valid values for the license field are listed at https://spdx.org/licenses/

@JackBoosY
Copy link
Contributor

cc @ras0219-msft

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have modified or added at least one portfile where deprecated functions are used.

If you feel able to do so, please consider migrating them to the new functions:
vcpkg_install_cmake -> vcpkg_cmake_install (from port vcpkg-cmake)
vcpkg_build_cmake -> vcpkg_cmake_build (from port vcpkg-cmake)
vcpkg_configure_cmake -> vcpkg_cmake_configure (Please remove the option PREFER_NINJA) (from port vcpkg-cmake)
vcpkg_fixup_cmake_targets -> vcpkg_cmake_config_fixup (from port vcpkg-cmake-config)

In the ports that use the new function, you have to add the corresponding dependencies:

{
  "name": "vcpkg-cmake",
  "host": true
},
{
  "name": "vcpkg-cmake-config",
  "host": true
}

The following files are affected:

  • ports/qtbase/portfile.cmake

You have modified or added at least one vcpkg.json where a "license" field is missing.
If you feel able to do so, please consider adding a "license" field to the following files:

  • ports/qtbase/vcpkg.json

Valid values for the license field are listed at https://spdx.org/licenses/

@abique
Copy link
Contributor Author

abique commented Jan 26, 2022

It seems that the x86_windows failure is due to a vcpkg crash and is unrelated to this PR.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have modified or added at least one portfile where deprecated functions are used.

If you feel able to do so, please consider migrating them to the new functions:
vcpkg_install_cmake -> vcpkg_cmake_install (from port vcpkg-cmake)
vcpkg_build_cmake -> vcpkg_cmake_build (from port vcpkg-cmake)
vcpkg_configure_cmake -> vcpkg_cmake_configure (Please remove the option PREFER_NINJA) (from port vcpkg-cmake)
vcpkg_fixup_cmake_targets -> vcpkg_cmake_config_fixup (from port vcpkg-cmake-config)

In the ports that use the new function, you have to add the corresponding dependencies:

{
  "name": "vcpkg-cmake",
  "host": true
},
{
  "name": "vcpkg-cmake-config",
  "host": true
}

The following files are affected:

  • ports/qtbase/portfile.cmake

You have modified or added at least one vcpkg.json where a "license" field is missing.
If you feel able to do so, please consider adding a "license" field to the following files:

  • ports/qtbase/vcpkg.json

Valid values for the license field are listed at https://spdx.org/licenses/

Copy link
Contributor

@ras0219-msft ras0219-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than the suggested change, I'm happy with this implementation.

LGTM, thanks for the PR!

ports/qtbase/portfile.cmake Outdated Show resolved Hide resolved
@ras0219-msft ras0219-msft added requires:author-response and removed requires:vcpkg-team-review This PR or issue requires someone on the vcpkg team to take a further look. labels Jan 28, 2022
Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

After committing all other changes, the version database must be updated
git add -u && git commit
git checkout 8b62f6fff30c4321945f1e498d85929285d7083a -- versions
./vcpkg x-add-version --all
Diff
diff --git a/versions/q-/qtbase.json b/versions/q-/qtbase.json
index b496559..a91de9e 100644
--- a/versions/q-/qtbase.json
+++ b/versions/q-/qtbase.json
@@ -1,7 +1,7 @@
 {
   "versions": [
     {
-      "git-tree": "f85e1985bf8c5b27a2ab67cc1fc14b848a09c2b2",
+      "git-tree": "2362188815f81dd666df3eaee1d96a208c1a0838",
       "version-semver": "6.2.2",
       "port-version": 4
     },

You have modified or added at least one portfile where deprecated functions are used.

If you feel able to do so, please consider migrating them to the new functions:
vcpkg_install_cmake -> vcpkg_cmake_install (from port vcpkg-cmake)
vcpkg_build_cmake -> vcpkg_cmake_build (from port vcpkg-cmake)
vcpkg_configure_cmake -> vcpkg_cmake_configure (Please remove the option PREFER_NINJA) (from port vcpkg-cmake)
vcpkg_fixup_cmake_targets -> vcpkg_cmake_config_fixup (from port vcpkg-cmake-config)

In the ports that use the new function, you have to add the corresponding dependencies:

{
  "name": "vcpkg-cmake",
  "host": true
},
{
  "name": "vcpkg-cmake-config",
  "host": true
}

The following files are affected:

  • ports/qtbase/portfile.cmake

You have modified or added at least one vcpkg.json where a "license" field is missing.
If you feel able to do so, please consider adding a "license" field to the following files:

  • ports/qtbase/vcpkg.json

Valid values for the license field are listed at https://spdx.org/licenses/

@abique
Copy link
Contributor Author

abique commented Jan 28, 2022

Other than the suggested change, I'm happy with this implementation.

LGTM, thanks for the PR!

Thank you very much @ras0219-msft
I've applied your requested change.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have modified or added at least one portfile where deprecated functions are used.

If you feel able to do so, please consider migrating them to the new functions:
vcpkg_install_cmake -> vcpkg_cmake_install (from port vcpkg-cmake)
vcpkg_build_cmake -> vcpkg_cmake_build (from port vcpkg-cmake)
vcpkg_configure_cmake -> vcpkg_cmake_configure (Please remove the option PREFER_NINJA) (from port vcpkg-cmake)
vcpkg_fixup_cmake_targets -> vcpkg_cmake_config_fixup (from port vcpkg-cmake-config)

In the ports that use the new function, you have to add the corresponding dependencies:

{
  "name": "vcpkg-cmake",
  "host": true
},
{
  "name": "vcpkg-cmake-config",
  "host": true
}

The following files are affected:

  • ports/qtbase/portfile.cmake

You have modified or added at least one vcpkg.json where a "license" field is missing.
If you feel able to do so, please consider adding a "license" field to the following files:

  • ports/qtbase/vcpkg.json

Valid values for the license field are listed at https://spdx.org/licenses/

@JackBoosY
Copy link
Contributor

JackBoosY commented Jan 29, 2022

Note that qt should behave the same with and without this modification, so this changes should not break the user's expected.

@abique
Copy link
Contributor Author

abique commented Jan 31, 2022

@JackBoosY the issue is flagged has require author's response but I think provided all responses already. I've also applied the suggested change.

Should we move forward?

Edit: sorry, when I've wrote this message, I didn't your changes above. Maybe the web page needed a refresh...

@ras0219-msft ras0219-msft merged commit 8f315e8 into microsoft:master Feb 1, 2022
@ras0219-msft
Copy link
Contributor

Thanks!

Note that qt should behave the same with and without this modification, so this changes should not break the user's expected.

Under most circumstances, this is exactly the consideration we should have. However, there is always the need for "if the advanced user knows what they are doing, they can tickle XYZ and they're on their own". Options that must be manually set in a custom triplet are sufficiently obscure that they may violate this (and a user that uses it is largely on their own).

@Neumann-A
Copy link
Contributor

Still this is a global variable and thus needs to be prefixed with VCPKG_ according to the vcpkg cmake guidelines. As such I have renamed it in the Qt 6.2.3 PR.

@abique
Copy link
Contributor Author

abique commented Feb 2, 2022

Thank you very much everyone.

@abique abique deleted the qt-namespace branch May 19, 2022 14:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Qt] Support for -DQT_NAMESPACE=XXX
6 participants