-
Notifications
You must be signed in to change notification settings - Fork 986
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
[bug] Build of a recipe which has a tool_requires with <host_version>
may fail if build triggered from build context
#14920
Comments
<host_version>
may fail if build triggered from build requirement<host_version>
may fail if build triggered from build requirement
<host_version>
may fail if build triggered from build requirement<host_version>
may fail if build triggered from build context
Thanks for reporting. If the I cannot reproduce this at the moment, this package doesn't work in Windows, and I don't have linux right now. It would be great to have some minimal reproducible case. |
Is there not some hidden bug? Sure it resolves to the correct version, but the build fails because it seems to be slightly different than the same build triggered from host context (this one succeeds), and it shouldn't because I have exactly the same profile in host & build context. This is why I suspect a bug when a build is triggered from build context. And because the same build was working fine before this It's hard to provide a reproducible example except using current RREV of xkbcommon in conancenter. The best I can do is to provide a diff of all files generated in conan folder of build folder, between a regular build of xbkcommon with |
If you are on Windows, you can build xkbcommon in WSL. Step 1: Check that it builds fine with a regular installation:
Step 2: check that it fails if build is triggered from build context. These commands may be sufficient:
Since host & build profile are the same, the second build should be exactly the same, but it fails. |
It seems to work fine in Conan 2.0.13 in WSL:
|
@memsharded I've also ran into this exact issue using Conan V1.
|
Yep |
It seems more probable that this is a bug in xkbcommon than in conan itself, considering the recipes does some different actions at 5 different steps, depending on if there is a build profile or not : https://github.com/search?q=repo%3Aconan-io%2Fconan-center-index+_has_build_profile+path%3A%2F%5Erecipes%5C%2Fxkbcommon%5C%2Fall%5C%2F%2F&type=code |
I've definitely had the same thought, and finally opened issue #14935 to try to simplify this kind of thing, which I should have done a long time ago. |
Still broken in conan 2.0.15 It's not a recipe issue, otherwise why it doesn't fail with |
A couple of summary points here:
|
I think you can create a minimal example by creating a simple Conan package for a command-line tool that depends on xkbcommon. Then, add a test a package to run the tool as a |
Thanks for the feedback @jwillikers I have just tried exactly what you propose with latest Conan 2.0.17 and it works fine, I cannot make it fail. This is why I say that we need something minimal (that is still far from minimal, for a start it only works in Linux, so I cannot test things in my default system which is Windows) to reproduce, like exact steps and commands, even including docker images (I tried using the conanio/gcc11 docker image) |
I forgot to mention that you have to have the option |
Still the same, it seems to work. |
@memsharded Thanks for looking into this. I'll work on getting a minimal example of the issue when I get time, though I haven't checked if the problem occurs with Conan v2 yet. |
Got same wayland errors during Conan v2 install with conan install . --profile:build=changeme_profile --profile:host=changeme_profile -c tools.system.package_manager:mode=install -c tools.system.package_manager:sudo=True --build=missing -o :shared=True -o abseil:shared=False -o boost*:shared=True -o qt*:shared=True -c tools.build:verbosity=verbose -c tools.build:jobs=4 -s compiler.cppstd=gnu17 -c tools.build:skip_test=True -s build_type=Debug NOTE: I had to also add "qt/6.6.1" to tool_requires due to Error logs and conanfile (ignore comments in conanfile) below:
|
Thanks for the details. I have tried it, had to change: def set_version(self):
self.version = "1.0" Then, after that, with the command:
I had to quote the "*". Then I got a normal conflict:
Not the error you are reporting inside the Meson build. Then I used the new 2.1 to resolve the conflict:
and pass it both as host and build profile Then it started to build things, but then I got stuck with:
It seems their server is down at this moment It eventually proceed.
to be able to move forward. I now think that I have been able to identify the issue in |
Submitting a fix in #15763 The fix was quick once we could reproduce it. This highlights the importance of reducing to the very minimum the repro-cases, it helps a lot to expedite the resolution of bugs. I have already tried to backport this to Conan 1.X, but it doesn't seem possible, as the graph model ( Thanks all for the feedback! |
Closed by #15763, it will be in next 2.2 |
Environment details
Steps to reproduce
For example you could add
qt
recipe to build requirements of a recipe on Linux, it will dragxkbcommon
in build context. Also take care of not downloading pre-built binaries from conancenter but build from source, and do not have xkbcommon in host context (or a different flavor likeshared=True
).Build of
xkbcommon
will fail (It was working fine before conan-io/conan-center-index#19983 which has replacedwayland/1.21.0
bywayland/<host_version>
in its build requirements).If you build
xkbcommon
with a simpleconan install --requires xkbcommon/1.5.0 -b
, it works fine.It might be an issue with PkgConfigDeps build_context_activated with
<host_version
in the context of a build triggered from build context, I don't know: https://github.com/conan-io/conan-center-index/blob/8d3eb5dcf5fcf29d971892e156781b5e26e1453a/recipes/xkbcommon/all/conanfile.py#L104-L138see also conan-io/conan-center-index#20542
Logs
The text was updated successfully, but these errors were encountered: