Closed hwhsu1231 closed 1 year ago
Steps:
Example Project:
test-multiconfig-windeployqt.zip
Steps:
After completing the installation, we can see that:
D:\.conan\short\477a06\1
D:\.conan\short\e9281e\1
Screenshots:
Steps:
It works successfully. As we can see in the following screenshot, it deploys the application successfully.
Screenshots:
Steps:
However, an error message shows that "Unable to find dependent libraries".
[build] Unable to find dependent libraries of D:\.conan\short\477a06\1\bin\Qt6Widgets.dll :Cannot open 'D:/.conan/short/477a06/1/bin/Qt6Widgets.dll':
As we can see, the target library is inside D:\.conan\short\477a06\1
, which is Debug directory. However, the library name is Release version, which is without suffix d
. This is because we're trying to deploy the Release config of DLLs, but the windeployqt.exe
that we're using is in Debug build directory.
Screenshots:
After comparing with using Qt installed by Official Installer, I found that:
According to README.md
of cmake-conan, the example shows that we can "use foreach()
to iterate different configurations" and then "execute conan install
command respectively" when using Multi-Config generators. In my example project, I use foreach()
to iterate Debug first and then Release. (/cmake/ConanCMakeSetup.cmake
):
Then, I use the following code to print properties of Qt6::windeployqt
:
As we can see, the IMPORTED_LOCATION
property of Qt6::windeployoqt
is using the Debug version.
This is why using Qt installed by "Conan" meets the error.
One of the possible SOLUTION is to provide IMPORTED_LOCATION_<CONFIG>
since the priority of IMPORTED_LOCATION_<CONFIG>
is HIGHER than that of IMPORTED_LOCATION
. That way, using Multi-Config generator should be worked because it will use:
IMPORTED_LOCATION_DEBUG
for Debug config.IMPORTED_LOCATION_RELEASE
for Release config, respectively.
I think this might be solved already by this PR: https://github.com/conan-io/conan/pull/12049/files If you could confirm, it would be very nice. Thanks
@lasote How do I test the result of this PR?
You could add my remote, checkout the branch of the PR and install that conan version:
git remote add lasote https://github.com/conan-io/conan.git
git fetch lasote
git checkout feature/test_cmakedeps_config_mapping
pip install -e .
Then run conan normally and the sources from that branch will be used.
I met an error when executing the git checkout
command:
D:\Test\test-conan>git checkout feature/test_cmakedeps_config_mapping
error: pathspec 'feature/test_cmakedeps_config_mapping' did not match any file(s) known to git
Oh, my mistake, my remote is git remote add lasote https://github.com/lasote/conan.git
BTW, if I install your version of Conan, will it overwrite the original Conan installed on my computer? If so, what should I do to return back to the original?
yes. Ideally you use python virtual environments to do this things.
Otherwise do a pip uninstall conan
and then pip install conan
.
Not working.
First, I install the modified version of Conan.
Before reconfiguring the project, I use conan remove
command to uninstall the qt/6.3.1
packages.
C:\Users\hwhsu1231>conan remove qt/6.3.1
Are you sure you want to delete from 'qt/6.3.1' (yes/no): yes
After completing the installation, IMPORTED_LOCATION_<CONFIG>
is still <NOTFOUND>
.
Thank you for verifying it. I'll investigate.
By the way, the cmake_conan
is not tested with the new tools (like CMakeDeps) and we won't maintain it anymore in Conan 2.X. I'll try to verify if the issue is still present without cmake_conan
and using conan install
manually.
Another thing I see is that the conanfile.py
has to use the CMakeToolchain
when use it CMakeDeps
. The toolchain generated must be used, otherwise the result is unpredictable.
About the CMakePresets.json
, after the conan install
you should use the CMakeUsersPresets.json
generated by the CMakeToolchain
.
I would mark this as not-valid
because the usage of the cmake-conan
and CMakeDeps
without the toolchain is not supported.
Another thing I see is that the
conanfile.py
has to use theCMakeToolchain
when use itCMakeDeps
. The toolchain generated must be used, otherwise the result is unpredictable.
I don't get it. Why does the conanfile.py
need the CMakeToolchain
when using CMakeDeps
?
BTW, if CMakeDeps
has to be used with CMakeToolchain
every time, then why not just combine these two generators into one?
@lasote
I would mark this as
not-valid
because the usage of thecmake-conan
andCMakeDeps
without the toolchain is not supported.
Why not? For me, I can use cmake-conan
with CMakeDeps
generator successfully in Conan 1.X. As you can see in my conanfile.py
, I only specify CMakeDeps
and VirtualRunEnv
these two generators, NOT including CMakeToolchain
.
@lasote
Actually, this issue is related to: https://github.com/conan-io/conan/issues/11540
In that issue, I requested Conan to add IMPORTED_LOCATION
property for Imported Targets generated by CMakeDeps
. And @memsharded replied me that it's already provided in Conan 2.X. (https://github.com/conan-io/conan/issues/11540#issuecomment-1168786623)
After further research in CMake, I found that IMPORTED_LOCATION_<CONFIG>
is more useful and powerful than IMPORTED_LOCATION
. See more details on here. Therefore, I posted this issue.
So I don't know why you marked this issue as invalid
??
That is implemented in the PR that I linked for you. It is invalid because is a non tested behaviour to use cmake-conan that will be deprecated soon and omitting the Conan toolchain when using CMakedeps
So what you said invalid
is to say the PR is invalid, not this issue. Am I correct?
@lasote
I'll try to verify if the issue is still present without
cmake_conan
and usingconan install
manually.
I really think this issue is NOT related to cmake-conan
because it just provides an alternative way to execute conan install
command. That is, conan_cmake_install()
.
The current problem is that those Imported Targets generated by CMakeDeps
don't have IMPORTED_LOCATION_<CONFIG>
property. What does it matter with CMakeToolchain
?
I really think this issue is NOT related to cmake-conan because it just provides an alternative way to execute conan install command. That is, conan_cmake_install().
So I need a simple example of failing using CMakeDeps
and CMakeToolchain
and calling CMake
using the toolchain.
The current problem is that those Imported Targets generated by CMakeDeps don't have IMPORTEDLOCATION
property. What does it matter with CMakeToolchain?
The branch I provided you HAS the IMPORTED_LOCATION_<CONFIG>
. I don't know if it is related to CMakeToolchain
but as you can see we have many issues to attend to, I just cannot prioritize this using a not-supported (invalid) setup.
So I need a simple example of failing using
CMakeDeps
andCMakeToolchain
and callingCMake
using the toolchain.
So you mean you need an example project that:
find_package()
to find those xxx-config.cmake
files generated by CMakeDeps
.conan_toolchain.cmake
file generated by CMakeToolchain
.togehter to prove that this situation also fails. Right?
Yes. Doing first a conan install
to install the dependencies.
We generate a CMakeUserPresets.json
too, so you can try that. It will use the toolchain automatically.
If that fails I can debug until I find something.
@lasote
As I imagined, this issue is "NOT" caused by cmake-conan
.
I tried what you said, doing without cmake-conan
and using the CMakePresets.json
generated by CMakeToolchain
generator. However, it shows the "SAME" result. That is, the IMPORTED_LOCATION_<CONFIG>
is still "EMPTY".
--
Properties for TARGET Qt6::Core:
Qt6::Core.IMPORTED_LOCATION = <NOTFOUND>
Qt6::Core.IMPORTED_LOCATION_DEBUG = <NOTFOUND>
Qt6::Core.IMPORTED_LOCATION_RELEASE = <NOTFOUND>
Properties for TARGET Qt6::windeployqt:
Qt6::windeployqt.IMPORTED_LOCATION = "D:/.conan/short/477a06/1/lib/cmake/Qt6Core/../../../bin/windeployqt.exe"
Qt6::windeployqt.IMPORTED_LOCATION_DEBUG = <NOTFOUND>
Qt6::windeployqt.IMPORTED_LOCATION_RELEASE = <NOTFOUND>
Download and unzip the project:
Create the msvc16-x64-debug
profile:
conan profile new msvc16-x64-debug
conan profile update settings.os=Windows msvc16-x64-debug
conan profile update settings.os_build=Windows msvc16-x64-debug
conan profile update settings.arch=x86_64 msvc16-x64-debug
conan profile update settings.arch_build=x86_64 msvc16-x64-debug
conan profile update settings.build_type=Debug msvc16-x64-debug
conan profile update settings.compiler="Visual Studio" msvc16-x64-debug
conan profile update settings.compiler.version=16 msvc16-x64-debug
Create the build
directory and then change to it:
md build
cd build
Execute the conan install
command to install packages:
conan install .. --install-folder ./conan --profile msvc16-x64-debug --remote conancenter
Copy the CMakePresets.json
generated by CMakeToolchain
genereator to the root directory:
copy .\conan\CMakePresets.json ..\CMakePresets.json
Execute the cmake
command to configure the project:
cmake .. --preset default
This should be fixed by https://github.com/conan-io/conan/pull/12049, for next 1.55
@memsharded
It still doesn't work. Those target properties are still empty:
IMPORTED_LOCATION
IMPORTED_LOCATION_DEBUG
IMPORTED_LOCATION_RELEASE
First of all, I install Conan from the latest develop
branch of conan repository by running the following commands:
git clone https://github.com/conan-io/conan.git
cd conan
pip install -e .
Download and unzip the project: test-imported-location-config.zip
Create and change to the build
subfolder:
md build && cd build
Run conan install
command to install the dependencies:
conan install .. --install-folder ./conan --profile ../msvc16-x64-debug.ini --remote conancenter
Copy the generated CMakePresets.json
to the root folder:
copy .\conan\CMakePresets.json ..\CMakePresets.json
Configure the CMake project:
cmake .. --preset default
What did I miss?
Feature Requests
Recently, I found that it FAILED to use Imported Target
Qt6::windeployqt
to deploy Qt applications when using Multi-Config generators (ex:Ninja Multi-Config
) with cmake-conan. After some research, I think the reason is because it ONLY providesIMPORTED_LOCATION
property. And the possible SOLUTION is to provideIMPORTED_LOCATION_<CONFIG>
.Therefore, I hope Conan can add
IMPORTED_LOCATION_<CONFIG>
for Imported Targets created byCMakeDeps
.Platforms and Versions