I came to this page to figure out which header these types (like DWORD) are defined in.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d2c1bff4-be17-2bcc-8017-d4f2d044088c
• Version Independent ID: 2acc8cc4-9a40-ef0a-fd44-4e76d50d4d93
• Content: DWORD
• Content Source: docs/assembler/masm/dword.md
• Product: visual-cpp
• Technology: cpp-masm
• GitHub Login: @corob-msft
• Microsoft Alias: corob

Yes please, parameters for generators would be welcome. The one aspect I don't see mentioned here is that in this case, conan makes assumptions about the settings one uses; and even though there is a default set of settings, it's also possible to customize them, so it should at least be possible to opt in to a different "conan build_type -> CMAKE_BUILD_TYPE" mapping. For example, to customize it:

$ conan install . -g cmake_multi -s build_type=Release -p CMAKE_BUILD_TYPE=RelWithDebInfo

(hopefully that example is clear in the intention)^

After reading the linked issue, I think this is a duplicate of that one, so feel free to close it. I'll comment there.

Thanks. Since I have a script that calls conan anyway, I simply did this (after conan, but before the CMake invocation):

  conanbuildinfo_multi = open("conanbuildinfo_multi.cmake").read()
  conanbuildinfo_multi = conanbuildinfo_multi.replace("_RELWITHDEBINFO", "_RELEASE")
  with open("conanbuildinfo_multi.cmake", "w") as fp:
    fp.write(conanbuildinfo_multi)

if you are using the CMake helper

We are doing this:

  def build(self):
    build_type = "RelWithDebInfo" if self.settings.build_type == "Release" else "Debug"
    cm = CMake(self, build_type=build_type, cmake_system_name=False, parallel=False)

Unfortunately this fails because we call

$ conan install . -g cmake_multi -s build_type=Release

If I instead I did this in the beginning:

$ conan install . -g cmake_multi -s build_type=RelWithDebInfo

I would get an error because RelWithDebInfo is an invalid value in our setup; furthermore, we don't build the dependencies in RelWithDebInfo. We only want to build the application consumes the (Release) deps as RelWithDebInfo.

Environment Details (include every applicable attribute)

• Operating System+version: Windows 10
• Compiler+version: MSVC 2017
• Conan version: 1.21.0
• Python version: 3.6

Steps to reproduce (Include if Applicable)

We have a project that uses Qt and Qt quick. For this reason, we are relying on being able to access the Qt CMake macros. We do find_package(Qt) in our CMake script. We recently upgraded from 1.4.4 to 1.19. I noticed that in this version, I get the following error when using the msvc multi-config generator:

CMake Error at CMakeLists.txt:51 (find_package):
  By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Qt5", but
  CMake did not find one.

  Could not find a package configuration file provided by "Qt5" with any of
  the following names:

    Qt5Config.cmake
    qt5-config.cmake

  Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR"
  to a directory containing one of the above files.  If "Qt5" provides a
  separate development package or SDK, be sure it has been installed.

The relevant parts in our CMake:

set(QT_COMPONENTS Core Concurrent Qml Test Network WebChannel WebEngine Widgets Svg Xml)
find_package(Qt5 COMPONENTS ${QT_COMPONENTS} REQUIRED)
find_package(Qt5QuickCompiler)

Our tooling calls

$ conan install . -g cmake_multi -s build_type=Release ...
$ conan install . -g cmake_multi -s build_type=Debug  ...

Switching back to 1.4.4 immediately solves the issue, without any other changes. I upgraded to 1.20 and 1.21, but those also exhibit the same error.

Then, I went in and bisected the conan releases to identify when this broke, grabbing each version and rerunning each time (and I hope this buys me a beer 🍺😂):

1. 1.4.4 - good, 91 versions left
2. 1.13.2 - good, 46 versions left
3. 1.18.0 - bad, 23 versions left
4. 1.15.1 - good, 12 versions left
5. 1.16.1.dev1574067531 - bad, 6 versions left
6. 1.15.4 - good, 3 versions left
7. 1.15.5 - good, 2 versions left
8. 1.16.0 - bad, 1 version left
9. 1.15.5 - good

So this started happening in 1.16.0. Diff: https://github.com/conan-io/conan/compare/release/1.15.5...release/1.16.0

This looks like the culprit: https://github.com/conan-io/conan/compare/release/1.15.5...release/1.16.0#diff-4ace401e8414c1a6556986dc05a638d8R720

We are building RelWithDebInfo, but conanbuildinfo_release.cmake never sets CONAN_CMAKE_MODULE_PATH_RELWITHDEBINFO. I assume we would be expected to pass RelWithDebInfo as the build_type, but that's not possible for us. We are building our dependencies in Release configuration and only the projects that consume the deps are built with RelWithDebInfo - this is very intentional and preferred. We don't even have a RelWithDebInfo value for build_type in our settings (nor do we want to add this config and build everything with it). For now, I'm going to patch the generated conanbuildinfo.cmake to make this work again in our tooling, but it would be nice to get a parameter to set the CMAKE_BUILD_TYPE independently from the value of the conan build_type setting. That would also remove assumptions about the values and spellings of the settings used.

https://github.com/VSCodeVim/Vim/issues/4340

Describe the bug Basically the same as https://github.com/VSCodeVim/Vim/issues/3753 (only opening a new issue because that one is closed and unlikely to get attention). Downgrading to 1.11.3 works. I'm not sure if this is the case on other platforms.

To Reproduce Steps to reproduce the behavior:

1. Start vscode
2. Vim mode doesn't load at all - no logs that I could find to indicate any error. For all intents and purposes it is the same behavior as if it's not installed at all.

Expected behavior The extension should load and operate like before.

Environment (please complete the following information):

<!-- Ensure you are on the latest VSCode + VSCodeVim You can use "Report Issue" by running "Developers: Show Running Extensions" from the Command Pallette to prefill these. -->

• Extension (VsCodeVim) version: v1.12.0
• VSCode version: v1.40.2
• OS: Linux

thanks @waitingsong , closing this one as it's a duplicate.

Describe the bug Basically the same as https://github.com/VSCodeVim/Vim/issues/3753 (only opening a new issue because that one is closed and unlikely to get attention). Downgrading to 1.11.3 works. I'm not sure if this is the case on other platforms.

To Reproduce Steps to reproduce the behavior:

1. Start vscode
2. Vim mode doesn't load at all - no logs that I could find to indicate any error. For all intents and purposes it is the same behavior as if it's not installed at all.

Expected behavior The extension should load and operate like before.

Environment (please complete the following information):

<!-- Ensure you are on the latest VSCode + VSCodeVim You can use "Report Issue" by running "Developers: Show Running Extensions" from the Command Pallette to prefill these. -->

• Extension (VsCodeVim) version: v1.12.0
• VSCode version: v1.40.2
• OS: Linux

Yeah, we did not change this code (yet), it's only the conan version bump.

We already upload the recipes first (our build exports and uploads all recipes; then starts building each profile in parallel, i.e. Artifactory the builder nodes can get the recipes from Artifactory).

I'm happy to check the prerelease on testpypi, but last time I tried that, I could not install it because deps of conan were not on testpypi. What can I do to work around that?

Environment Details (include every applicable attribute)

• Operating System+version: Ubuntu 16.04
• Compiler+version: clang 8.0
• Conan version: 1.20.3
• Python version: 3.6.5

Steps to reproduce (Include if Applicable)

I don't really know - this happens rarely during uploads. Might be a race condition.

Logs (Executed commands with output) (Include/Attach if Applicable)

[2019-11-27T11:46:38.974Z] Traceback (most recent call last):
[2019-11-27T11:46:38.974Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/command.py", line 1938, in run
[2019-11-27T11:46:38.974Z]     method(args[0][1:])
[2019-11-27T11:46:38.974Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/command.py", line 1400, in upload
[2019-11-27T11:46:38.974Z]     retry_wait=args.retry_wait, integrity_check=args.check)
[2019-11-27T11:46:38.974Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/conan_api.py", line 81, in wrapper
[2019-11-27T11:46:38.974Z]     return f(api, *args, **kwargs)
[2019-11-27T11:46:38.974Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/conan_api.py", line 881, in upload
[2019-11-27T11:46:38.974Z]     retry, retry_wait, integrity_check, policy, query=query)
[2019-11-27T11:46:38.974Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/cmd/uploader.py", line 89, in upload
[2019-11-27T11:46:38.974Z]     integrity_check, policy, remote, upload_recorder, remotes)
[2019-11-27T11:46:38.974Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/cmd/uploader.py", line 190, in _upload_ref
[2019-11-27T11:46:38.974Z]     self._upload_recipe(ref, conanfile, retry, retry_wait, policy, recipe_remote, remotes)
[2019-11-27T11:46:38.974Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/cmd/uploader.py", line 222, in _upload_recipe
[2019-11-27T11:46:38.974Z]     the_files = self._compress_recipe_files(ref)
[2019-11-27T11:46:38.974Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/cmd/uploader.py", line 326, in _compress_recipe_files
[2019-11-27T11:46:38.974Z]     self._output)
[2019-11-27T11:46:38.974Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/cmd/uploader.py", line 499, in _compress_recipe_files
[2019-11-27T11:46:38.975Z]     add_tgz(EXPORT_TGZ_NAME, export_tgz_path, files, symlinks, "Compressing recipe...")
[2019-11-27T11:46:38.975Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/cmd/uploader.py", line 496, in add_tgz
[2019-11-27T11:46:38.975Z]     tgz_path = compress_files(tgz_files, tgz_symlinks, tgz_name, dest_folder, output)
[2019-11-27T11:46:38.975Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/client/cmd/uploader.py", line 548, in compress_files
[2019-11-27T11:46:38.975Z]     tgz.close()
[2019-11-27T11:46:38.975Z]   File "/usr/local/pyenv/versions/3.6.4/lib/python3.6/contextlib.py", line 88, in __exit__
[2019-11-27T11:46:38.975Z]     next(self.gen)
[2019-11-27T11:46:38.975Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/util/files.py", line 64, in set_dirty_context_manager
[2019-11-27T11:46:38.975Z]     clean_dirty(folder)
[2019-11-27T11:46:38.975Z]   File "/data/jenkins/conan_build/2095192381/conan/lib/conan-1.20.3-71-linux-py36.pyz/conans/util/files.py", line 52, in clean_dirty
[2019-11-27T11:46:38.975Z]     os.remove(dirty_file)
[2019-11-27T11:46:38.975Z] FileNotFoundError: [Errno 2] No such file or directory: '/data/jenkins/conan_build/2095192381/conan/.conan/data/libidn/2.0.5-30/rcombs/eae-license/export/conan_export.tgz.dirty'

I thought I did something incorrectly, but apparently many people are experiencing this.

• RCM Loader one can't inject the 5.0.2 payload
• 5.0.1 and other payloads can be injected fine
• Other methods of injecting the same 5.0.2 work fine (e.g. PC)

See this thread: https://gbatemp.net/threads/cant-inject-hekate-5-0-2-using-the-rcmloader-dongle.548632/

I don't know if this is an issue in this Hekate build or in the loader itself. I tried contacting the vendor, but there was no answer after two weeks, so it's unlikely they will respond. Is there anything that can be done in Hekate to make it work? I don't know how to troubleshoot/debug this, but I'm happy to gather any additional info if possible.

@CTCaer thanks! I can confirm that it works as expected (I never knew you are not supposed to hold power). Since this is already fixed on master, I'll close the issue.

I thought I did something incorrectly, but apparently many people are experiencing this.

• RCM Loader one can't inject the 5.0.2 payload
• 5.0.1 and other payloads can be injected fine
• Other methods of injecting the same 5.0.2 work fine (e.g. PC)

See this thread: https://gbatemp.net/threads/cant-inject-hekate-5-0-2-using-the-rcmloader-dongle.548632/

I don't know if this is an issue in this Hekate build or in the loader itself. I tried contacting the vendor, but there was no answer after two weeks, so it's unlikely they will respond. Is there anything that can be done in Hekate to make it work? I don't know how to troubleshoot/debug this, but I'm happy to gather any additional info if possible.

1.20.3 produces the same.

<!-- What is your question? Please be as specific as possible! -->

Conan version: 1.20.2

I'm running into this error message when building our tree with most (but not all) of our profiles. There are many similar messages with different packages. I'm calling conan create with a lockfile to build the package.

The message comes from here:

https://github.com/conan-io/conan/blob/1.20.2/conans/model/graph_lock.py#L324

The wording "binary" is probably misleading here, but I assume this means that somehow there are multiple nodes in the dependency tree with the same name. We probably have overlap in the tree (i.e. not always just the minimal needed packages are required explicitly, sometimes things that are transitive deps of the top-level dependencies are also required explicitly). But we don't have name collisions in our packages. So what does this error mean exactly and what can I do to resolve it?

• [x] I've read the CONTRIBUTING guide.

Package and Environment Details (include every applicable attribute)

• Package Name/Version: zlib/1.2.11
• Conan version: conan 1.19.1
• Python version: Python 3.7.4

Conan profile

[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=8
compiler.libcxx=libstdc++
build_type=Release
[options]
[build_requires]
[env]

Steps to reproduce (Include if Applicable)

Create conanfile.txt with contents:

[requires]
boost/1.71.0

[generators]
cmake_find_package
cmake_paths

CMakeLists.txt:

include(${CMAKE_BINARY_DIR}/conan_paths.cmake)

find_package(boost REQUIRED)

Run

$ mkdir build && cd build
$ conan install ..
$ cmake ..

Expected: boost is found by CMake.

Actual:

By not providing "Findzlib.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "zlib", but
  CMake did not find one.

I'm pretty sure this is the offending commit: https://github.com/conan-io/conan-center-index/commit/eda6295c4d5cfa725bf2f00a7dd15f35c306018c but I suspect there was a reason for making the change. If I rename FindZLIB.cmake to Findzlib.cmake, it finds the package successfully. This is because the generated Findboost.cmake contains this line:

    find_dependency(zlib REQUIRED)

cc @uilianries

Fair enough!

@SSE4 Thanks for the heads-up, but conan has a stability guarantee for 1.x, and this recipe will be broken with prior versions unless that change is rolled back.

Oh, I see this is the PR: https://github.com/conan-io/conan-center-index/pull/217

I think it would be best to revert that, or rename the zlib package to ZLIB, otherwise everything depending on it will be broken when using the cmake find_package generator.

Package and Environment Details (include every applicable attribute)

• Package Name/Version: zlib/1.2.11
• Conan version: conan 1.19.1
• Python version: Python 3.7.4

Conan profile

[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=8
compiler.libcxx=libstdc++
build_type=Release
[options]
[build_requires]
[env]

Steps to reproduce (Include if Applicable)

Create conanfile.txt with contents:

[requires]
boost/1.71.0

[generators]
cmake_find_package
cmake_paths

CMakeLists.txt:

include(${CMAKE_BINARY_DIR}/conan_paths.cmake)

find_package(boost REQUIRED)

Run

$ mkdir build && cd build
$ conan install ..
$ cmake ..

Expected: boost is found by CMake.

Actual:

By not providing "Findzlib.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "zlib", but
  CMake did not find one.

I'm pretty sure this is the offending commit: https://github.com/conan-io/conan-center-index/commit/eda6295c4d5cfa725bf2f00a7dd15f35c306018c but I suspect there was a reason for making the change. If I rename FindZLIB.cmake to Findzlib.cmake, it finds the package successfully. This is because the generated Findboost.cmake contains this line:

    find_dependency(zlib REQUIRED)

cc @uilianries

Since this is getting a bit of attention, may I plug my more general suggestion: https://github.com/conan-io/conan/issues/1895

Since then, many commands added --json which writes a file. This is workable, but slightly more awkward to program around than just capturing stdout.

Happy to help!

Thank you for handling this quickly!

Conan version: 1.18.5

When using graph build-order in a graph where some dependencies are build_requires, I'm getting a KeyError and an unhandled exception. This is most likely another facet of https://github.com/conan-io/conan/issues/5682 but I'm not able to work around it the same way with that one. I don't entirely understand what's going on, but managed to throw together a repo that reliably reproduces it:

https://github.com/sztomi/build_requires_keyerror

(pretty similar to the others I reported lately, I hope these do help)

This is the traceback:

Traceback (most recent call last):
  File "/home/tamas/src/repros/conan/build_requires_keyerror/.venv/lib/python3.6/site-packages/conans/client/command.py", line 1859, in run
    method(args[0][1:])
  File "/home/tamas/src/repros/conan/build_requires_keyerror/.venv/lib/python3.6/site-packages/conans/client/command.py", line 1748, in graph
    build_order = self._conan.build_order(args.lockfile, args.build)
  File "/home/tamas/src/repros/conan/build_requires_keyerror/.venv/lib/python3.6/site-packages/conans/client/conan_api.py", line 78, in wrapper
    return f(*args, **kwargs)
  File "/home/tamas/src/repros/conan/build_requires_keyerror/.venv/lib/python3.6/site-packages/conans/client/conan_api.py", line 1247, in build_order
    False, False, remotes, recorder)
  File "/home/tamas/src/repros/conan/build_requires_keyerror/.venv/lib/python3.6/site-packages/conans/client/graph/graph_manager.py", line 182, in load_graph
    graph_lock=graph_lock)
  File "/home/tamas/src/repros/conan/build_requires_keyerror/.venv/lib/python3.6/site-packages/conans/client/graph/graph_manager.py", line 290, in _load_graph
    apply_build_requires=apply_build_requires) 
  File "/home/tamas/src/repros/conan/build_requires_keyerror/.venv/lib/python3.6/site-packages/conans/client/graph/graph_manager.py", line 257, in _recurse_build_requires
    processed_profile, graph_lock)
  File "/home/tamas/src/repros/conan/build_requires_keyerror/.venv/lib/python3.6/site-packages/conans/client/graph/graph_builder.py", line 57, in extend_build_requires
    graph_lock.lock_node(node, requires)
  File "/home/tamas/src/repros/conan/build_requires_keyerror/.venv/lib/python3.6/site-packages/conans/model/graph_lock.py", line 252, in lock_node
    locked_pref, locked_id = prefs[require.ref.name]
KeyError: 'fontconfig'

To provide a little background on why we are using build_requires this way:

• Our ffmpeg package is statically compiled and used in different places where it's undesirable to download all the other deps at install time (as they are completely unused in those builds)
• We are cross-compiling ffmpeg and its deps for targeting windows (via mingw running on Linux). This yields packages that have settings.compiler set to gcc. But on Windows, we are using msvc. Our earlier attempts were at collecting these packages and generating a profile that overrides the compiler for these packages so they can be consumed in an MSVC build, but this is not ideal.
• We initially used private requires for this purpose but were advised by your team to use build_requires instead due to faulty design in the former.

Our workaround for now is probably going to be creating a facade package that repackages the real ffmpeg package with the requires and settings that we really want to expose.

To help us debug your issue please explain:

• [x] I've read the CONTRIBUTING guide.
• [x] I've specified the Conan version, operating system version and any tool that can be relevant.
• [x] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

Thanks @memsharded! Are we safe to ignore the assertion if we are using it in the described way (i.e. rebuid only changed recipes in a monorepo with meta-packages at the root)? It seems to work fine so far.

@jgsogo thanks

you are introducing several diamonds in your graph with the meta-package nano recipe, and in your recipe files you are requiring dependencies using the name/version

Hmm, so in other words, the problem is that we are requiring some "root" packages (ones that have no dependencies themselves) as well as others (leaves and stuff in-between)?

Thanks!

Any update on this?

@jgsogo - here is a repro case https://github.com/sztomi/dubious_warnings

Please take a look at the ffmpeg conanfile - I think I found a different bug while I put this together.

Sure - I'll post a repro case in a bit.

Conan version: 1.18.2 Ubuntu 19.04

We have meta-packages that list a subset of all our packages, meant to be built with a set of our configurations (build profiles). In these meta-packages, we list some, but not all of the packages in the tree. In 1.18.2 we are getting lots of warnings about a version being overridden to the same version. I understand this is because these are redundant. However, there isn't a real version collision going on here. I think this warning should be reserved for cases when there is an actual collision. Otherwise it's difficult to dig out the real collisions.

In the following example, nano is one of the meta-packages I mentioned above.

WARN: boost/1.69.0 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: boost/1.69.0 requirement iconv/1.15 overridden by nano/1.0 to iconv/1.15
WARN: libxml2/2.9.8 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: plex-openssl/1.0.2p requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: opencv/2.4.13-07711e4 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: soci/3.0.0-9a9baa1 requirement sqlite/3.26.0 overridden by nano/1.0 to sqlite/3.26.0
WARN: soci/3.0.0-9a9baa1 requirement boost/1.69.0 overridden by nano/1.0 to boost/1.69.0
WARN: soci/3.0.0-9a9baa1 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: soci/3.0.0-9a9baa1 requirement iconv/1.15 overridden by nano/1.0 to iconv/1.15
WARN: curl/7.56.1 requirement plex-openssl/1.0.2p overridden by nano/1.0 to plex-openssl/1.0.2p
WARN: curl/7.56.1 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: libidn/2.0.5 requirement iconv/1.15 overridden by curl/7.56.1 to iconv/1.15
WARN: taglib/1.11.1 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: taglib/1.11.1 requirement boost/1.69.0 overridden by nano/1.0 to boost/1.69.0
WARN: cppnetlib/0.13.0 requirement boost/1.69.0 overridden by nano/1.0 to boost/1.69.0
WARN: cppnetlib/0.13.0 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: cppnetlib/0.13.0 requirement iconv/1.15 overridden by nano/1.0 to iconv/1.15
WARN: minizip/1.2.8 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8

• [x] I've read the CONTRIBUTING guide.
• [x] I've specified the Conan version, operating system version and any tool that can be relevant.
• [x] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

Yep

thanks @sdispater - do you think that publish should fix the configuration automatically when a permanent redirect is detected?

Yeah, that's what I'm pointing out. I guess this is a matter of user expectations. If I ran the same command without the lockfile passed as a parameter, I would get the same output (since the "input profile" is the same). This is confusing to me, because the lockfile is intended to store and apply the "effective profile" (wording by the documentation). It's a great way to think of the lockfile this way, but the fact that it doesn't display the effective profile when the lockfile is passed is pretty confusing to me (i.e. same output with or without the lockfile).

I spoke too soon - I managed to reproduce it. The key is that the options must be defined in the conanfile as defaults. Here is a full repo: https://github.com/sztomi/options_display_error

conanfile:

class FfmpegConan(ConanFile):
    name = "ffmpeg"
    version = "1.0"
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "bar": [True, False]}
    default_options = "shared=False", "bar=True"
    generators = "cmake"

Generated lockfile bits:

   "23066e85-d54d-11e9-822e-645d86dec98e": {
    "pref": "ffmpeg/1.0@_/_#cd7f409375d9d1911124b65611feadf6:d3e70b6d64a9ab72d7d0d46f5d7a15319a30ed12#8b59be09d65d46f9e24cc047c6df2cc8",
    "options": "bar=True\nshared=False\nfontconfig:shared=False\nharfbuzz:shared=False\nzlib:shared=False",
    "modified": "Build",
    "requires": {
     "fontconfig/1.0@_/_#c6e28a260353cd84d81f34f60b18e955": "23066e82-d54d-11e9-822e-645d86dec98e",
     "harfbuzz/1.0@_/_#bfd268132eb937dc5ebd9f3e42e4b412": "23066e83-d54d-11e9-822e-645d86dec98e",
     "zlib/1.0@_/_#0e280695800433574bfb184cc8621b73": "23066e84-d54d-11e9-822e-645d86dec98e"
    }

(note that options are captured correctly)

Displayed:

+ conan create --build missing -tf=None -ne --lockfile ../variant/conan.lock .
Using lockfile: '/home/tamas/src/repros/conan/options_display_error/variant/conan.lock'
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=8
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

(options are not displayed here)

Hmm, definitely seeing it my real packages, but it seems non-trivial to reproduce with a minimal case. I'll keep trying and get back to you.

@danimtb I added the kink to the repro to the initial post in this issue. But here it is: https://github.com/sztomi/cannot_get_latest_package