GitHub repository: conan-io/conan

Issues:
issue_15767: state: open
title: new tools.cmake.cmake_layout:build_folder
body: Changelog: Feature: New ``tools.cmake.cmake_layout:build_folder`` config that allows re-defining ``cmake_layout`` build-folder, including for ``test_package``.
Docs: https://github.com/conan-io/docs/pull/XXXX

user: memsharded
issue_15766: state: open
title: [question] CMake generators don't check compiler version mismatch
body: ### What is your question?

I've just noticed that the Conan v2 Cmake generators don't check that the actual gcc/clang compiler version matches the version specified in the settings.

We use packaged toolchains everywhere, so never have a situation where the wrong compiler version might accidentally be used.

But how do people manage this when using the system compiler? For example, if a machine happens to have gcc 10 installed and I try to compile using a gcc 9 profile, I'd like it to fail rather than silently use the wrong compiler version.

Does everyone just set `tools.build:compiler_executables={ "c": "gcc-9", "cpp": "g++-9" }` in their profiles to ensure this? Or am I missing something obvious?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: PeteAudinate
issue_15764: state: open
title: Fix BazelDeps in the build context
body:               Good catch 👏 

It has to be solved for BazelDeps too.

_Originally posted by @franramirez688 in https://github.com/conan-io/conan/pull/15763#discussion_r1504355537_
            
user: memsharded
issue_15761: state: open
title: Make argparse output positionals before optionals
body: Do not merge, this is just to show the team, it _will_ break
user: RubenRBS
issue_15760: state: open
title: Fix compiler path with meson on Windows when using Android NDK
body: Changelog: Fix | Bugfix): Describe here your pull request
Docs: https://github.com/conan-io/docs/pull/XXXX

- [x] Refer to the issue that supports this Pull Request.
- [ ] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

# Description 

Trying to build `lcms/2.14` on Windows using Android NDK results in a build error.

```
..\src\meson.build:1:0: ERROR: Failed running 'C:\\Users\\edukaj\\.conan2\\p\\b\\andro0a7659df7e598\\p\\bin\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\aarch64-linux-android29-clang', binary or interpreter not executable.
Possibly wrong architecture or the executable bit is not set.
```

The issue is that on Windows the right path for the toolchain should end with `.cmd`. 

I opened an issue on [conan-center-index](https://github.com/conan-io/conan-center-index/issues/22909), and I am proposing a fix here:
user: elvisdukaj
issue_15759: state: open
title: Build botan 3.3  on Windows with gcc
body: Hi all!

It is impossible to build a library under vindows!
`
C:\Users\admin\AppData\Local\Temp\ccFTYqoZ.s: Fatal error: can't write 150 bytes to section .text of build/obj/lib/botan_all.o: 'file too big'

The Window profile contains `CXXFLAGS=-Wa,-mbig-obj`

> [settings]
> os=Windows
> arch=x86_64
> arch_build=x86_64
> compiler=gcc
> compiler.version=11.2
> compiler.libcxx=libstdc++11
> compiler.cppstd=20
> build_type=Release
> [options]
> [build_requires]
> [env]
> botan:CXXFLAGS=-Wa,-mbig-obj
> openssl:CC=c:/MinGW/bin/gcc.exe
> openssl:CXX=c:/MinGW/bin/g++.exe
> [conf]
> tools.env.virtualenv:auto_use=True
> tools.env.environment:auto_use=True
> tools.cmake.cmaketoolchain:generator=Ninja

The Version 2.19.3 was built without problems!

How can I fix this!

user: dix75
issue_15757: state: open
title: [question] Handling libc linker flags between applications and test packages
body: ### What is your question?

I'm working on https://github.com/conan-io/conan-center-index/pull/17528 and I'm not sure how to deal with test packages and applications that want to choose their libc specification.

With `arm-gnu-toolchain` for baremetal, you need an implementation for your libc. There are a couple of them out there but two of the provided compilers are the best for test packages because they get rid of the linker errors. The linker flags are `--specs=nano.specs` and `--specs=nosys.specs`. `nano.specs` defines implementations for memcpy, printf etc and `nonsys.specs` implements the lowest level C libraries for reading and writing to files and gathering memory for malloc. `nosys.specs` simply defines these as calls to abort/exit. It is meant to just fill the gaps and not to be used. This is great for test packages because it allows test packages to build without issue without each test package requiring special cross compiler flags in their cmake files. But my issue is figuring out how to disable this automatic injection for their applications. Here is what I'd like the user to be able to do:

```bash
conan build . -pr lpc4078 -pr arm-gcc-12.3 -s build_type=MinSizeRel
```

The `lpc4078` profile is the target profile and contains information about the chip's architecture and os, etc. Here is what it looks like (the build type is a default for users if they want to override it):

```
[settings]
build_type=MinSizeRel
os=baremetal
arch=cortex-m4f

[options]
*:platform=lpc4078

[buildenv]
LIBHAL_PLATFORM=lpc4078
LIBHAL_PLATFORM_LIBRARY=lpc40
```

The build environment variables are for `make`, `cmake` and any other build system to be used to automatically link to the correct library. Note that `cortex-m4f` is not a arch that is currently available in the conan settings but is available in my user_settings. The `platform` option is something key to my ecosystem.

The `arm-gcc-12.3` looks like this:

```
[settings]
compiler=gcc
compiler.cppstd=23
compiler.libcxx=libstdc++11
compiler.version=12.3

[tool_requires]
arm-gnu-toolchain/12.3
```

I distribute these both so users can select their target microcontroller and their target compiler. They could `include()` them both into a single profile if they wanted to for their project.

`arm-gnu-toolchain` will look at the arch flag and generate compiler & linker flags for the user based on their selection. The linker flags are the issue. The reason removing these is helpful is that `nano.specs` disables exception handling which I need for the software I'm building. I'd prefer to use picolibc or potentially another libc implementation. Here are the things I've tried:

## Using Settings

```
compiler:
  gcc:
    libc: [null, "custom"]
```

This is what I tried. It made sense to me but the issue comes with how to affects packages. If I use this in my profile, none of my packages will have `libc` defined for them. I could recompile them for this, but the issue is that the libc type doesn't change how the binaries are generated. This setting only affects the final binary and how it is linked. So a setting for this doesn't really make sense, even though it would allow the compiler to choose correctly with a host profile.

## Using Options

I tried options but they were never the correct choice for the tool package. Host profile options cannot find their way to the tool package and thus are not set correctly. So to make this work I'd have to add something like this:

```
conan build . -pr lpc4078 -pr arm-gcc-12.3 -pr:b custom-libc -s build_type=MinSizeRel
```

`custom-libc` looks like this:
```
include(default)

[options]
*:custom_libc=True
```

The default is included to get info like your native compiler, native arch, etc. That way I can just append my custom option to the profile. My only issue is that its really easy to forget that last flag. And it looks really strange. Forgetting to add this build profile is a silent failure which is a problem.

## Using the CLI

This works, by adding `-o:b custom_libc=True` but adds even more text for the user and is error prone. It has the same issue as using the build options flag.

## Using environment variables

I haven't tested this out yet but I believe it can work. I add the following to the lpc4078 profile:

```
[buildenv]
ARM_GNU_TOOLCHAIN_CUSTOM_LIBC="custom"
```

This way my compiler's toolchain.cmake file can do the following:

```
if(NOT $ENV{ARM_GNU_TOOLCHAIN_CUSTOM_LIBC} STREQUAL "custom")
  string(APPEND CMAKE_EXE_LINKER_FLAGS "--specs=nano.specs --specs=nosys.specs")
  message(WARNING "Appending nano and nosys libc specs to linker flags!")
endif()
```

This would work and alert the user at the very least, but still not my favorite option. 

## Which is the right path?

I'm not sure which is the right path so I'm asking the conan team for help here. 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: kammce
issue_15754: state: open
title: [feature] Add Bazel 7.x support
body: ### What is your suggestion?

Conan is not working with Bazel 7.x for now. Figure out the needed changes to make it work with Bazel 6.x, and 7.x.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: franramirez688
issue_15752: state: open
title: [bug] Failure to cross-compile OpenSSL for QNX
body: ### Environment details

Operating system: Ubuntu 22 04
GCC: 10.5.0
Conan: 1.59.0
Python: 3.10.12
Cmake: 3.28.1

### Steps to reproduce

1. Download and install QNX SDP toolchain into local system.
2. Source SDP toolchain and capture environment variables
3. Add environment variables to QNX Conan profile.
4. Execute Conan install for cross-compile, using build/host profiles.

**Conan profile build (x86_64)**

```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=10
compiler.libcxx=libstdc++11
build_type=Release
[options]
[build_requires]
[env]
```

**Conan profile host (QNX ARMv8)**

```
[settings]
os=Neutrino
os.version=7.1
compiler=qcc
compiler.version=8.3
compiler.libcxx=cxx
arch=armv8
build_type=Release
[options]
[build_requires]
[env]
CC=qcc
CFLAGS="-Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE"
CXXFLAGS="-Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE"
CXX=q++
MAKEFLAGS=-I/home/mhadley4/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/target/qnx7/usr/include
PATH=/home/mhadley4/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/host/linux/x86_64/usr/bin:/home/mhadley4/.qnx/bin:/home/mhadley4/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/jre/bin:/home/mhadley4/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/host/common/bin:/home/mhadley4/.local/bin:/home/mhadley4/.local/bin:/home/mhadley4/.local/bin:/home/mhadley4/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin
PYTHONDONTWRITEBYTECODE=1
QNX_CONFIGURATION_EXCLUSIVE=/home/mhadley4/.qnx
QNX_CONFIGURATION=/home/mhadley4/.qnx
QNX_HOST=/home/mhadley4/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/host/linux/x86_64
QNX_TARGET=/home/mhadley4/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/target/qnx7
[buildenv]
```

**Simple Conan Install Command**

```
conan install openssl/3.2.1@ -pr:h=conan-profile-host -pr:b=conan-profile-build --build -r conancenter
````

**Results in Error**

```
 "cc: Can't specify -P, -C, -E, -c or -S with -o and have multiple files"
```

Doing the exact same process for many other Yocto based SDK toolchains, they can all build OpenSSL. I have no clue where to go from here, not much to go on from the Internet. Any assistance would be appreciated. Thanks

### Logs

Configuration (profile_host):
[settings]
arch=armv8
build_type=Debug
compiler=qcc
compiler.libcxx=cxx
compiler.version=8.3
jlr_platform_target=cccm
os=Neutrino
os.version=7.1
[options]
[build_requires]
[env]
CC=qcc
CFLAGS=-Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE
CXX=q++
CXXFLAGS=-Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE
MAKEFLAGS=-I/root/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396[351](https://git-gdd.sdo.jlrmotor.com/ONE/obg/obg-shared/-/jobs/10349848#L351)ac9/target/qnx7/usr/include
PATH=/root/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/host/linux/x86_64/usr/bin:/root/.qnx/bin:/root/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/jre/bin:/root/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/host/common/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PYTHONDONTWRITEBYTECODE=1
QNX_CONFIGURATION=/root/.qnx
QNX_CONFIGURATION_EXCLUSIVE=/root/.qnx
QNX_HOST=/root/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/host/linux/x86_64
QNX_TARGET=/root/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/target/qnx7
[conf]
tools.cmake.cmaketoolchain:system_name=QNX
Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11
jlr_platform_target=x86_64
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
openssl/3.2.1: Retrieving from server 'conancenter' 
openssl/3.2.1: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
openssl/3.2.1: Downloaded recipe revision 0
zlib/1.3.1: Retrieving from server 'conancenter' 
zlib/1.3.1: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
zlib/1.3.1: Downloaded recipe revision 0
zlib/1.3.1: Forced build from source
openssl/3.2.1: Forced build from source
Version ranges solved
    zlib/* versions found in 'conancenter' remote
    Version range '>=1.2.11 <2' required by 'openssl/3.2.1' resolved to 'zlib/1.3.1' in remote 'conancenter'
Installing package: openssl/3.2.1
Requirements
    openssl/3.2.1 from 'conancenter' - Downloaded
    zlib/1.3.1 from 'conancenter' - Downloaded
Packages
    openssl/3.2.1:97251b3c4ffb4424af2be180c1c97471dab66[360](https://git-gdd.sdo.jlrmotor.com/ONE/obg/obg-shared/-/jobs/10349848#L360) - Build
    zlib/1.3.1:4db21118e429c251335f35fd1e6bdd64269d69af - Build
Cross-build from 'Linux:x86_64' to 'Neutrino:armv8'
Installing (downloading, building) binaries...
Downloading conan_sources.tgz
zlib/1.3.1: Configuring sources in /root/.conan/data/zlib/1.3.1/_/_/source/src
zlib/1.3.1: 
zlib/1.3.1: Copying sources to build folder
zlib/1.3.1: Building your package in /root/.conan/data/zlib/1.3.1/_/_/build/4db21118e429c251335f35fd1e6bdd64269d69af
zlib/1.3.1: Generator txt created conanbuildinfo.txt
zlib/1.3.1: Calling generate()
zlib/1.3.1: Preset 'debug' added to CMakePresets.json. Invoke it manually using 'cmake --preset debug'
zlib/1.3.1: If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/root/.conan/data/zlib/1.3.1/_/_/build/4db21118e429c251335f35fd1e6bdd64269d69af/build/Debug/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Debug'
zlib/1.3.1: Aggregating env generators
zlib/1.3.1: Calling build()
zlib/1.3.1: Apply patch (conan): separate static/shared builds, disable debug suffix
zlib/1.3.1: CMake command: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/root/.conan/data/zlib/1.3.1/_/_/build/4db21118e429c251335f35fd1e6bdd64269d69af/build/Debug/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Debug" "/root/.conan/data/zlib/1.3.1/_/_/build/4db21118e429c251335f35fd1e6bdd64269d69af/src"
-- Using Conan toolchain: /root/.conan/data/zlib/1.3.1/_/_/build/4db21118e429c251335f35fd1e6bdd64269d69af/build/Debug/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The C compiler identification is QCC 8.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /root/.conan/data/qnx-sdp-vdc-armv8/701/jlr/prd/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/host/linux/x86_64/usr/bin/qcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of off64_t
-- Check size of off64_t - done
-- Looking for fseeko
-- Looking for fseeko - found
-- Looking for unistd.h
-- Looking for unistd.h - found
-- Renaming
--     /root/.conan/data/zlib/1.3.1/_/_/build/4db21118e429c251335f35fd1e6bdd64269d69af/src/zconf.h
-- to 'zconf.h.included' because this file is included with zlib
-- but CMake generates it automatically in the build directory.
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:
    CMAKE_POLICY_DEFAULT_CMP0091
-- Build files have been written to: /root/.conan/data/zlib/1.3.1/_/_/build/4db21118e429c251335f35fd1e6bdd64269d69af/build/Debug
zlib/1.3.1: CMake command: cmake --build "/root/.conan/data/zlib/1.3.1/_/_/build/4db21118e429c251335f35fd1e6bdd64269d69af/build/Debug" '--' '-j8'
[ 18%] Building C object CMakeFiles/zlib.dir/compress.c.o
[ 18%] Building C object CMakeFiles/zlib.dir/deflate.c.o
[ 18%] Building C object CMakeFiles/zlib.dir/adler32.c.o
[ 25%] Building C object CMakeFiles/zlib.dir/crc32.c.o
[ 31%] Building C object CMakeFiles/zlib.dir/gzread.c.o
[ 37%] Building C object CMakeFiles/zlib.dir/gzclose.c.o
[ 43%] Building C object CMakeFiles/zlib.dir/gzwrite.c.o
[ 50%] Building C object CMakeFiles/zlib.dir/gzlib.c.o
[ 56%] Building C object CMakeFiles/zlib.dir/inflate.c.o
[ 62%] Building C object CMakeFiles/zlib.dir/infback.c.o
[ 68%] Building C object CMakeFiles/zlib.dir/inftrees.c.o
[ 75%] Building C object CMakeFiles/zlib.dir/inffast.c.o
[ 81%] Building C object CMakeFiles/zlib.dir/zutil.c.o
[ 87%] Building C object CMakeFiles/zlib.dir/trees.c.o
[ 93%] Building C object CMakeFiles/zlib.dir/uncompr.c.o
[100%] Linking C static library libz.a
[100%] Built target zlib
zlib/1.3.1: Package '4db21118e429c251335f35fd1e6bdd64269d69af' built
zlib/1.3.1: Build folder /root/.conan/data/zlib/1.3.1/_/_/build/4db21118e429c251335f35fd1e6bdd64269d69af/build/Debug
zlib/1.3.1: Generated conaninfo.txt
zlib/1.3.1: Generated conanbuildinfo.txt
zlib/1.3.1: Generating the package
zlib/1.3.1: Package folder /root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af
zlib/1.3.1: Calling package()
zlib/1.3.1: CMake command: cmake --install "/root/.conan/data/zlib/1.3.1/_/_/build/4db21118e429c251335f35fd1e6bdd64269d69af/build/Debug" --prefix "/root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af"
-- Install configuration: "Debug"
-- Installing: /root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/lib/libz.a
-- Installing: /root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/include/zconf.h
-- Installing: /root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/include/zlib.h
zlib/1.3.1 package(): Packaged 1 file: LICENSE
zlib/1.3.1 package(): Packaged 2 '.h' files: zconf.h, zlib.h
zlib/1.3.1 package(): Packaged 1 '.a' file: libz.a
zlib/1.3.1: Package '4db21118e429c251335f35fd1e6bdd64269d69af' created
zlib/1.3.1: Created package revision 8940d3de1cda38dd98a1c6acf0dd56ad
openssl/3.2.1: Configuring sources in /root/.conan/data/openssl/3.2.1/_/_/source/src
openssl/3.2.1: 
openssl/3.2.1: Copying sources to build folder
openssl/3.2.1: Building your package in /root/.conan/data/openssl/3.2.1/_/_/build/97251b3c4ffb4424af2be180c1c97471dab66360
openssl/3.2.1: Generator txt created conanbuildinfo.txt
openssl/3.2.1: Calling generate()
openssl/3.2.1: using target: conan-Debug-Neutrino-armv8-qcc-8.3 -> BASE_unix
openssl/3.2.1: my %targets = (
    "conan-Debug-Neutrino-armv8-qcc-8.3" => {
        inherit_from => [ "BASE_unix" ],
        cflags => add("-fPIC -g"),
        cxxflags => add("-fPIC -g"),
        
        lflags => add(""),
        
        shared_cflag => "-fPIC",
        
        
    },
);
openssl/3.2.1: Aggregating env generators
openssl/3.2.1: Calling build()
openssl/3.2.1: apply_conandata_patches(): No patches defined in conandata
Configuring OpenSSL version 3.2.1 for target conan-Debug-Neutrino-armv8-qcc-8.3
Using os-specific seed configuration
Created configdata.pm
Running configdata.pm
Created Makefile.in
Created Makefile
Created include/openssl/configuration.h
**********************************************************************
***                                                                ***
***   OpenSSL has been successfully configured                     ***
***                                                                ***
***   If you encounter a problem while building, please open an    ***
***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
***   and include the output from the following command:           ***
***                                                                ***
***       perl configdata.pm --dump                                ***
***                                                                ***
***   (If you are new to OpenSSL, you might want to consult the    ***
***   'Troubleshooting' section in the INSTALL.md file first)      ***
***                                                                ***
**********************************************************************
perl "-I." "-Iutil/perl" "-Mconfigdata" "-MOpenSSL::paramnames" "util/dofile.pl" "-oMakefile" crypto/params_idx.c.in > crypto/params_idx.c
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/crypto/bn_conf.h.in > include/crypto/bn_conf.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/crypto/dso_conf.h.in > include/crypto/dso_conf.h
perl "-I." "-Iutil/perl" "-Mconfigdata" "-MOpenSSL::paramnames" "util/dofile.pl" "-oMakefile" include/internal/param_names.h.in > include/internal/param_names.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/asn1.h.in > include/openssl/asn1.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/asn1t.h.in > include/openssl/asn1t.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/bio.h.in > include/openssl/bio.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/cmp.h.in > include/openssl/cmp.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/cms.h.in > include/openssl/cms.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/conf.h.in > include/openssl/conf.h
perl "-I." "-Iutil/perl" "-Mconfigdata" "-MOpenSSL::paramnames" "util/dofile.pl" "-oMakefile" include/openssl/core_names.h.in > include/openssl/core_names.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/crmf.h.in > include/openssl/crmf.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/crypto.h.in > include/openssl/crypto.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/ct.h.in > include/openssl/ct.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/err.h.in > include/openssl/err.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/ess.h.in > include/openssl/ess.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/fipskey.h.in > include/openssl/fipskey.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/lhash.h.in > include/openssl/lhash.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/ocsp.h.in > include/openssl/ocsp.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/opensslv.h.in > include/openssl/opensslv.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/pkcs12.h.in > include/openssl/pkcs12.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/pkcs7.h.in > include/openssl/pkcs7.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/safestack.h.in > include/openssl/safestack.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/srp.h.in > include/openssl/srp.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/ssl.h.in > include/openssl/ssl.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/ui.h.in > include/openssl/ui.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/x509.h.in > include/openssl/x509.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/x509_vfy.h.in > include/openssl/x509_vfy.h
perl "-I." "-Mconfigdata" "util/dofile.pl" "-oMakefile" include/openssl/x509v3.h.in > include/openssl/x509v3.h
make depend && make _build_sw
make[1]: Entering directory '/root/.conan/data/openssl/3.2.1/_/_/build/97251b3c4ffb4424af2be180c1c97471dab66360/src'
make[1]: Leaving directory '/root/.conan/data/openssl/3.2.1/_/_/build/97251b3c4ffb4424af2be180c1c97471dab66360/src'
make[1]: Entering directory '/root/.conan/data/openssl/3.2.1/_/_/build/97251b3c4ffb4424af2be180c1c97471dab66360/src'
qcc  -I. -Iinclude -Iapps/include  -fPIC -g -Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE -fPIC -g -fPIC -DOPENSSLDIR="\"/root/.conan/data/openssl/3.2.1/_/_/package/97251b3c4ffb4424af2be180c1c97471dab66360/res\"" -DENGINESDIR="\"//lib/engines-3\"" -DMODULESDIR="\"//lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DZLIB -I/root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/include -DOPENSSL_TLS_SECURITY_LEVEL=2 -MMD -MF apps/lib/libapps-lib-app_libctx.d.tmp -MT apps/lib/libapps-lib-app_libctx.o -c -o apps/lib/libapps-lib-app_libctx.o apps/lib/app_libctx.c
qcc  -I. -Iinclude -Iapps/include  -fPIC -g -Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE -fPIC -g -fPIC -DOPENSSLDIR="\"/root/.conan/data/openssl/3.2.1/_/_/package/97251b3c4ffb4424af2be180c1c97471dab66360/res\"" -DENGINESDIR="\"//lib/engines-3\"" -DMODULESDIR="\"//lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DZLIB -I/root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/include -DOPENSSL_TLS_SECURITY_LEVEL=2 -MMD -MF apps/lib/libapps-lib-app_params.d.tmp -MT apps/lib/libapps-lib-app_params.o -c -o apps/lib/libapps-lib-app_params.o apps/lib/app_params.c
qcc  -I. -Iinclude -Iapps/include  -fPIC -g -Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE -fPIC -g -fPIC -DOPENSSLDIR="\"/root/.conan/data/openssl/3.2.1/_/_/package/97251b3c4ffb4424af2be180c1c97471dab66360/res\"" -DENGINESDIR="\"//lib/engines-3\"" -DMODULESDIR="\"//lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DZLIB -I/root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/include -DOPENSSL_TLS_SECURITY_LEVEL=2 -MMD -MF apps/lib/libapps-lib-app_provider.d.tmp -MT apps/lib/libapps-lib-app_provider.o -c -o apps/lib/libapps-lib-app_provider.o apps/lib/app_provider.c
qcc  -I. -Iinclude -Iapps/include  -fPIC -g -Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE -fPIC -g -fPIC -DOPENSSLDIR="\"/root/.conan/data/openssl/3.2.1/_/_/package/97251b3c4ffb4424af2be180c1c97471dab66360/res\"" -DENGINESDIR="\"//lib/engines-3\"" -DMODULESDIR="\"//lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DZLIB -I/root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/include -DOPENSSL_TLS_SECURITY_LEVEL=2 -MMD -MF apps/lib/libapps-lib-app_rand.d.tmp -MT apps/lib/libapps-lib-app_rand.o -c -o apps/lib/libapps-lib-app_rand.o apps/lib/app_rand.c
qcc  -I. -Iinclude -Iapps/include  -fPIC -g -Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE -fPIC -g -fPIC -DOPENSSLDIR="\"/root/.conan/data/openssl/3.2.1/_/_/package/97251b3c4ffb4424af2be180c1c97471dab66360/res\"" -DENGINESDIR="\"//lib/engines-3\"" -DMODULESDIR="\"//lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DZLIB -I/root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/include -DOPENSSL_TLS_SECURITY_LEVEL=2 -MMD -MF apps/lib/libapps-lib-app_x509.d.tmp -MT apps/lib/libapps-lib-app_x509.o -c -o apps/lib/libapps-lib-app_x509.o apps/lib/app_x509.c
qcc  -I. -Iinclude -Iapps/include  -fPIC -g -Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE -fPIC -g -fPIC -DOPENSSLDIR="\"/root/.conan/data/openssl/3.2.1/_/_/package/97251b3c4ffb4424af2be180c1c97471dab66360/res\"" -DENGINESDIR="\"//lib/engines-3\"" -DMODULESDIR="\"//lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DZLIB -I/root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/include -DOPENSSL_TLS_SECURITY_LEVEL=2 -MMD -MF apps/lib/libapps-lib-apps.d.tmp -MT apps/lib/libapps-lib-apps.o -c -o apps/lib/libapps-lib-apps.o apps/lib/apps.c
qcc  -I. -Iinclude -Iapps/include  -fPIC -g -Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE -fPIC -g -fPIC -DOPENSSLDIR="\"/root/.conan/data/openssl/3.2.1/_/_/package/97251b3c4ffb4424af2be180c1c97471dab66360/res\"" -DENGINESDIR="\"//lib/engines-3\"" -DMODULESDIR="\"//lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DZLIB -I/root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/include -DOPENSSL_TLS_SECURITY_LEVEL=2 -MMD -MF apps/lib/libapps-lib-apps_opt_printf.d.tmp -MT apps/lib/libapps-lib-apps_opt_printf.o -c -o apps/lib/libapps-lib-apps_opt_printf.o apps/lib/apps_opt_printf.c
qcc  -I. -Iinclude -Iapps/include  -fPIC -g -Vgcc_ntoaarch64le -Y_cxx -D_QNX_SOURCE -fPIC -g -fPIC -DOPENSSLDIR="\"/root/.conan/data/openssl/3.2.1/_/_/package/97251b3c4ffb4424af2be180c1c97471dab66360/res\"" -DENGINESDIR="\"//lib/engines-3\"" -DMODULESDIR="\"//lib/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DZLIB -I/root/.conan/data/zlib/1.3.1/_/_/package/4db21118e429c251335f35fd1e6bdd64269d69af/include -DOPENSSL_TLS_SECURITY_LEVEL=2 -MMD -MF apps/lib/libapps-lib-apps_ui.d.tmp -MT apps/lib/libapps-lib-apps_ui.o -c -o apps/lib/libapps-lib-apps_ui.o apps/lib/apps_ui.c
cc: Can't specify -P, -C, -E, -c or -S with -o and have multiple files
cc: Can't specify -P, -C, -E, -c or -S with -o and have multiple files
cc: Can't specify -P, -C, -E, -c or -S with -o and have multiple files
cc: Can't specify -P, -C, -E, -c or -S with -o and have multiple files
cc: Can't specify -P, -C, -E, -c or -S with -o and have multiple files
cc: Can't specify -P, -C, -E, -c or -S with -o and have multiple files
cc: Can't specify -P, -C, -E, -c or -S with -o and have multiple files
Makefile:3886: recipe for target 'apps/lib/libapps-lib-apps_opt_printf.o' failed
make[1]: *** [apps/lib/libapps-lib-apps_opt_printf.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:[383](https://git-gdd.sdo.jlrmotor.com/ONE/obg/obg-shared/-/jobs/10349848#L383)8: recipe for target 'apps/lib/libapps-lib-app_libctx.o' failed
make[1]: *** [apps/lib/libapps-lib-app_libctx.o] Error 1
cc: Can't specify -P, -C, -E, -c or -S with -o and have multiple files
Makefile:[384](https://git-gdd.sdo.jlrmotor.com/ONE/obg/obg-shared/-/jobs/10349848#L384)6: recipe for target 'apps/lib/libapps-lib-app_params.o' failed
make[1]: *** [apps/lib/libapps-lib-app_params.o] Error 1
Makefile:3878: recipe for target 'apps/lib/libapps-lib-apps.o' failed
make[1]: *** [apps/lib/libapps-lib-apps.o] Error 1
Makefile:3894: recipe for target 'apps/lib/libapps-lib-apps_ui.o' failed
make[1]: *** [apps/lib/libapps-lib-apps_ui.o] Error 1
Makefile:3870: recipe for target 'apps/lib/libapps-lib-app_x509.o' failed
make[1]: *** [apps/lib/libapps-lib-app_x509.o] Error 1
Makefile:[385](https://git-gdd.sdo.jlrmotor.com/ONE/obg/obg-shared/-/jobs/10349848#L385)4: recipe for target 'apps/lib/libapps-lib-app_provider.o' failed
make[1]: *** [apps/lib/libapps-lib-app_provider.o] Error 1
Makefile:[386](https://git-gdd.sdo.jlrmotor.com/ONE/obg/obg-shared/-/jobs/10349848#L386)2: recipe for target 'apps/lib/libapps-lib-app_rand.o' failed
make[1]: *** [apps/lib/libapps-lib-app_rand.o] Error 1
make[1]: Leaving directory '/root/.conan/data/openssl/3.2.1/_/_/build/97251b3c4ffb4[424](https://git-gdd.sdo.jlrmotor.com/ONE/obg/obg-shared/-/jobs/10349848#L424)af2be180c1c97471dab66360/src'
Makefile:2315: recipe for target 'build_sw' failed
make: *** [build_sw] Error 2
openssl/3.2.1: 
openssl/3.2.1: ERROR: Package '97251b3c4ffb[442](https://git-gdd.sdo.jlrmotor.com/ONE/obg/obg-shared/-/jobs/10349848#L442)4af2be180c1c97[471](https://git-gdd.sdo.jlrmotor.com/ONE/obg/obg-shared/-/jobs/10349848#L471)dab66360' build failed
openssl/3.2.1: WARN: Build folder /root/.conan/data/openssl/3.2.1/_/_/build/97251b3c4ffb4424af2be180c1c97471dab66360/build-debug
ERROR: openssl/3.2.1: Error in build() method, line 534
	self._make()
while calling '_make', line 526
	self._run_make()
while calling '_run_make', line [503](https://git-gdd.sdo.jlrmotor.com/ONE/obg/obg-shared/-/jobs/10349848#L503)
	self.run(" ".join(command), env="conanbuild")
	ConanException: Error 2 while executing make -j8
user: MikeyH84
issue_15751: state: open
title: [question] Plans regarding bazeltoolchain generator
body: ### What is your question?

Hello ,

Currently we are using `conan 1.x` as package generator and `cmake` as our `build-tool` with the help of `cmake generators`

We are now evaluating `bazel` as the next build tool and hope to use it similarly like `cmake` with the help of `bazel generators`

1. I am a newbie to bazel and i hit some problems when trying to cross compile using our own custom cross compiler . It seems that `bazel` has to know what is the source of the compiler and where it comes from and has to download on its own . Are you thinking on this usecase to generate a compiler path to conan package in artifactory so that bazel can download it ? 

2. Do you have any thoughts on generating something related to platforms/toolchains ?

3. Any approximate timeline on adding support to `bazel 7.x` ?

Sorry for not keeping the question very specific . 

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: sandeshhardikar
issue_15750: state: open
title: [bug] Bazel Toochain generator cannot access custom tools.google.bazel:bazelrc_path
body: ### Environment details

* Operating System+version: ubuntu 20.04
* Compiler+version: gcc 9.3
* Conan version: 1.63.0
* Python version: 3.8.10


### Steps to reproduce

1. Define a custom toolchain variable in a compiler package recipe in `package_info` method (`self.conf_info.append("tools.google.bazel:bazelrc_path", bazel_toolchain_file_path)`)
2. I tried to print [print("Rc paths", rc_paths)](https://github.com/conan-io/conan/blob/1.63.0/conan/tools/google/bazel.py#L61) , but it returns a empty list . 

From the [comments ](https://github.com/conan-io/conan/blob/1.63.0/conan/tools/google/bazel.py#L58-L60)I understand that you intend to use only 1 toolchain , but the user toolchain should have precedence over toolchain generated ?

### Logs

_No response_
user: sandeshhardikar
issue_15749: state: open
title: How to override dependencies on conan 2.0 
body: ### What is your question?

I can't find the option --require-override in conan 2.0.

At the moment, I am trying to get our packages ready for conan 2.0, but I am missing an important option on the CLI. 
We use a lot of recipes from conan-center, but we need to keep them stable over some years, so we copy them to a on local repository (the change rate is a way to high on the original side).
 
We deploy on an Linux system and need to keep some dependencies on the exact same version (options too) for specific libraries. On Conan 1.x I was using --require-override to do this. How can a achieve this on conan 2.0?  
I don't want to modify all recipes, since transient dependencies are archived by our own conan repository. 
Is that no longer possible? 
I saw the force flag in conanfile.py but is there no option on install or create command? 

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: schmidjo82
issue_15748: state: open
title: Feature/config install from pkg auto
body: Changelog: Feature: Add ``conan config install myconf/[*] --type=pkg`` new configuration inside Conan packages with new ``package_type = "configuration"``
Changelog: Feature: New ``core.package_id:config_mode`` that allows configuration package reference to effect the ``package_id`` of all packages.
Docs: https://github.com/conan-io/docs/pull/XXXX


user: memsharded
issue_15745: state: open
title: [feature] Make git the source of truth for recipes
body: ### What is your suggestion?

Hi! I've spent some time evaluating both Conan and Vcpkg and there are many things that I like about both projects. So far I like Conan a little better overall, so I want to provide feedback to the Conan projeect on things that I think it should borrow from Vcpkg. One of the things that I think Conan should take from Vcpkg is to keep the source packages (recipes) in git and stop publishing them to a separate repository. It sounds like a small thing, but I don't think it is. All development teams have git repositories and are comfortable with the precise tracking of every little change. It is our source of truth. But for Conan recipes there is an intermediate step where recipes have to be published to a Conan repository and we now have to trust *a process* rather than *a tool* that the published packages are correct. We also do not have a commit history for the repos published to the Conan repository, of if we do it is certainly not as accessible to developers as `git log`.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: tsondergaard
issue_15744: state: open
title: [question] Conan recipe for a thrift IDL wrapper
body: ### What is your question?

Hi, how would a recipe look for a thrift IDL wrapper library?

I am migrating an existing conan 1 legacy `cmake` generator recipe to the new generators (as a first step before considering conan 2)

My loose (but probably incorrect) requirements are:
1. It should support local development using the current workflow: `conan install ..`, `conan build ..`, `ctest`
2. It should be able to package: `conan create ..`
3. It should not require extensive changes to our current CI Pipelines (but suggestions are welcome on how to update those in future) 
    - Changes to our pipeline should support both legacy and new generators (we have a lot of repos with the same pipeline, we can't change everything in one go)

What our current recipe and build does:
1. The conan recipe in the `build()` stage
    1. downloads the specific version of the IDL as an archive from an URL and extracts it onto the `build` folder
    2. Modify the downloaded IDL (find-replace that can probably be a patch file)
       - It has no logic, it is a straight forward find and replace that always does the same irrespective of any options or config.
1. The build process (cmake)
    1. Generate the C++ code from the thrift IDL
    2. Build a library wrapper around the generated code
    3. Build some custom C++ code
1. The conan `package()` stage
     1. Package the C++ library for usage down the chain

Our current recipe does the download and patching in the `build()` method, but in the spirit of conan 2 I want to remove functionality from the `build() ` method so that we can start moving to the `conan install ..`, `cmake --preset XXX` workflow.

I have tried to do the `get()` and patching in the `source()` method but could not get any combination of layout settings, destination or anything else to work between `source()` and `generate()` that enables my two workflows without bad hacking.

What is the proper way to try and support this?

See below an obfuscated example of my conanfile


<details><summary>Click to expand conanfile.py</summary>

```
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMakeDeps, CMake, cmake_layout
from conan.tools.files import copy, get, replace_in_file
import glob

class SomeInterface(ConanFile):
    name = "some-interface"
    url = "<url>"
    description = "Some Server Interface"
    topics = ("IDL")
    settings = "os", "compiler", "build_type", "arch"
    package_type = "library"
    version = "4.1.20"

    options = {
            "shared": [True, False],
            "fPIC": [True, False] }
    default_options = {
            "shared": False,
            "fPIC": True }

    default_user = "user"
    default_channel = "testing"

    exports = f"{name}.properties"

    def requirements(self):
        self.requires("thrift/0.17.0")

    def export_sources(self):
        copy(self, "CMakeLists.txt", src=self.recipe_folder, dst=self.export_sources_folder)

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def configure(self):
        if not self.settings.compiler.get_safe("cppstd"):
            self.settings.compiler.cppstd = "20"
        if self.options.shared:
            self.options.rm_safe("fPIC")

    def layout(self):
        cmake_layout(self, 'Multi-Config')

    def export(self):
        pass

    def source(self):
        get(self, "https://some_url/{0}/some_package-{0}.tar.gz".format(self.version), destination="thrift")

        for filename in glob.iglob('thrift/*.thrift', recursive=True):
            replace_in_file(self, filename, search="namespace cpp <original>", replace="namespace cpp <new>")

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()

        deps = CMakeDeps(self)
        deps.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        self.copy("*.h", dst="include", src="./include")
        self.copy("*.h", dst="include/user", src="user", keep_path=True)
        self.copy("*.dll", dst="bin", keep_path=False)
        self.copy("*.lib", dst="lib", keep_path=False)
        self.copy("*.so", dst="lib", keep_path=False)
        self.copy("*.a", dst="lib", keep_path=False)

    def package_info(self):
        self.cpp_info.libs = self.collect_libs
````

</details>

My `CMakeLists.txt` have something in this line
```
set(THRIFT_BASE_DIR ${CMAKE_BINARY_DIR}/thrift/)
```

I would suspect that if I do the correct thing in the conan recipe, I can drop the `set()` command in cmake and replace it with the correc: `tc.variables["THRIFT_BASE_DIR"]` in the `generate()` step, but I could not get the correct combination between the `source()` and `generate()` methods to work.

Any help will be appreciated 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: CJCombrink
issue_15741: state: open
title: add --output-folder to export-pkg
body: Changelog: Feature: Add ``--output-folder`` to ``export-pkg`` command to be used when ``layout()`` is declared.
Docs: https://github.com/conan-io/docs/pull/XXXX

Close https://github.com/conan-io/conan/issues/15732

user: memsharded
issue_15738: state: open
title: [feature] Reduce build/compile output/logging
body: ### What is your suggestion?

Conan prints a lot of stuff while building dependencies, which can be useful for debugging. However, often it clutters the console and even exceeds the maximum log size in a CI pipeline. The logs include configure output, compiler warnings, and sometimes all compiler command lines (most notably with `openssl`, likely due to GNU make or something). It would be nice to have the option to suppress or reduce build output.

While we do have `tools.build:verbosity=quiet` and `tools.compilation:verbosity=quiet`, these are the default values and are not so much quiet as they are just normal, as they just mean "do not pass the verbose flag to the build tool".

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: stevenwdv
issue_15732: state: open
title: [bug] export-pkg in Conan 1 does not work with layout + output folder
body: ### Environment details

* Conan version: 1.62.0

### Steps to reproduce

Create a minimal test project with `layout()` method and cmake_layout and run the following sequence of commands:

```
conan install . -of build -if build
conan build . -bf build -if build
conan export-pkg . -bf build
```

**Expected behaviour**
Successful packaging

**Actual behaviour**
`FileNotFoundError: [Errno 2] No such file or directory: '/home/asaljo/code/sandbox/build/Release'`

**Investigation**
The `export_pkg()` method in `conans/client/cmd/export_pkg.py` calls the following method if layout is enabled:
```
conanfile.folders.set_base_folders(conanfile_folder, output_folder=None)
```
This assumes that no output folder was ever set. If I change this line to
```
conanfile.folders.set_base_folders(conanfile_folder, output_folder=build_folder)
```
my sequence of commands from above work as expected.

**Suggestion**
I don't think that the patch from above should be applied as is. I'd rather like to give the layout handling some more thought in general. The reason why we are running all of these commands with explicit folder arguments is that we get control over the directories used for storing individual artifacts in the local build workflow. We are using the local build workflow in our CI because we need more control over the individual steps and we also need to run additional stages in between those steps (e.g. test suite execution on different build nodes). Layout thwarts our efforts to create a generic pipeline that works across different recipes. There should be _at least_ a possibility to specify a output base directory for all of the commands. The layout within this base directory is not important, it can be controlled by the layout method. Even better would be a way to override layout completely from outside of the recipe. For example, using a layout file as before, which has precedence over the configuration in the recipe. We need a solution for Conan 1 in particular, but it would also make sense to have the same functionality in Conan 2.

### Logs

_No response_
user: jasal82
issue_15730: state: open
title: Replacement for conans.client.conan_api in Conan 2
body: ### What is your question?

We are using `conans.client.conan_api` to download conan packages:
```python
from conans.client.conan_api import Conan
conan, _, _ = Conan.factory()
conan.download(...)
```
Is there a replacement for this functionality in conan2?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: lstoffer
issue_15728: state: open
title: [bug] Incorrect package used when linking (?) different profiles for host/build
body: ### Environment details

Linux Ubuntu Focal
Clang-17
Conan 2.1.0
Python 3.8.10

### Steps to reproduce

This seems hard to reproduce so I captured as much as I could.
I'm building my project like so:
`NOT_ON_C3I=1 conan install . -pr:h=clang-asan -pr:b=clang -s build_type=Debug --build=missing`

Host profile has debug+asan, build profile is just Release.
I'm pretty sure I didn't change the profiles during the build, I don't think I ever has asan in the build profile.

Note that I have `-s build_type=Debug` in the command line, despite having the correct Release/Debug setting in the profiles.  Not sure if that plays a part.

The end result is I had a Release pcre2 trying to link to the Release libbz2.a (this is correct),
but there were linker errors related to asan symbols.
When I checked with `xxd libbz2.a` (correct specific library file from the error), I could see asan symbol names.
That library is in the .conan2 cache, and it's conaninfo.txt has this info:
```
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.version=17
os=Linux
[options]
build_executable=True
fPIC=True
shared=False
```
There is not enough info to see all the profile flags ... unless that IS IT ?
If true, then how did the asan symbols end up in the library?

Note that bzip2 was not built in this particular build run (it had already been built).

### Logs

KEY THINGS from below: pcre2 being build is for the 'build' profile, ie release flags, no asan.
It is trying to link to: `/home/paul/.conan2/p/b/bzip27b557cc7fd54c/p/lib/libbz2.a`

From the conan graph dump at the start (full log below):
```
Requirements:
bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4:80c69de683d89119028faa81cc723e34fa1572fb#e78a144c9ba1b914e2861ee4edda9fde - Cache
```

```
Build requirements:     
bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4:31760d9b53a05c7bca58eebb9fbe9fec51b1db48#0630c212c24894969aea96bf669dddb8 - Cache
```


```
======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Debug
compiler=clang
compiler.libcxx=libc++
compiler.version=17
os=Linux
[conf]
tools.build:cflags=['-fsanitize=address', '-fsanitize=undefined']
tools.build:compiler_executables={'c': '/usr/bin/clang-17', 'cpp': '/usr/bin/clang++-17'}
tools.build:cxxflags=['-fsanitize=address', '-fsanitize=undefined']
tools.build:exelinkflags=['-fsanitize=address', '-fsanitize=undefined']
tools.build:sharedlinkflags=['-fsanitize=address', '-fsanitize=undefined']
tools.cmake.cmaketoolchain:generator=Ninja

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.libcxx=libc++
compiler.version=17
os=Linux
[conf]
tools.build:compiler_executables={'c': '/usr/bin/clang-17', 'cpp': '/usr/bin/clang++-17'}
tools.cmake.cmaketoolchain:generator=Ninja
```


```
Requirements
    autoconf/2.71#00a1e46d8ba5baaf7f10d64c1a6a0342 - Cache
    automake/1.16.5#058bda3e21c36c9aa8425daf3c1faf50 - Cache
    boost/1.82.0@mxrap/fork-2024-02-14#8877fe5af80b10ad04946036dba4328c - Cache
    brotli/1.1.0#d56d7bb9ca722942aba17369cb5c0519 - Cache
    bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4 - Cache
    catch2/3.5.2#9554dc3c4ffcab50daf8f2cac4b79308 - Cache
    cppcsv/1.1#b610f7745e66a09df84c6d0d64492ecd - Cache
    date/3.0.1#032e24ad8bd1fd136dd33c932563d3d1 - Cache
    dav1d/1.2.1#94259c8baa2b1e7ab9976f1c20822be8 - Cache
    detectproxy/1.0#50477780f21ab2d2757429950710aa07 - Cache
    double-conversion/3.3.0#33321c201741cc32b51169c6d2d05e60 - Cache
    eigen/3.4.0#2e192482a8acff96fe34766adca2b24c - Cache
    expat/2.6.0#2f92fb3cf504e9731aba6d20dcd641bf - Cache
    exprtk/0.0.1#3ab94cf4d8edf2154065abe6fe6bba5d - Cache
    fast_float/3.9.0#18511f44fc573907e03e7648bb8f9a22 - Cache
    ffmpeg/6.1#85d65b4d431f9ee9112724c965040eeb - Cache
    flatbuffers/23.5.26#b153646f6546daab4c7326970b6cd89c - Cache
    fmt/10.2.1#9199a7a0611866dea5c8849a77467b25 - Cache
    fontconfig/2.15.0#15a13e5b6d5931ff0144f92b579f6dd5 - Cache
    freetype/2.13.2#fa35264c88edc6421a850d08c67630f4 - Cache
    glew/2.2.0#e5519ddcf52267be816b50d3dfa14a23 - Cache
    glib/2.78.1#6da549beee7208bd9fad0e6141581e8e - Cache
    glm/cci.20230113#c9c89bea128786a245028f0cb4c1936d - Cache
    glu/system#ee50fc2ade0e1c0c8ebb3be3ea60e0f5 - Cache
    harfbuzz/8.3.0#7e7ea00066eaaa818d469d24dbc3a106 - Cache
    hwloc/2.9.3#7b004fab2336e27d686e9ae08dcf4b0d - Cache
    icu/74.2#129a9b08abace8b2c748a567fc9b843a - Cache
    jansson/2.14#42fc601d5b8e236e050e48f2321ef851 - Cache
    jbig/20160605#2d29fa02aacd76902e0d2cbbc24631ef - Cache
    jidac/2.0.0#c3ea07915f779440c6d2c28ab0c23bb8 - Cache
    kissfft/131.1.0#2c2e2135e1e57415db301df1942b2d84 - Cache
    libaom-av1/3.6.1#a569b342c6f8129cf327709e18691072 - Cache
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c - Cache
    libcurl/8.6.0#ff220b1555b8aebbb78440b25d471217 - Cache
    libdeflate/1.19#3ea74a4549efc14d4b1202dc4bfbf602 - Cache
    libelf/0.8.13#4f70a3555809ae50cc8add44f0f84288 - Cache
    libffi/3.4.4#35eb63842b505824b70aedc1baefc916 - Cache
    libiconv/1.17#73fefc1b696e069df90fd1d18aa63edd - Cache
    libjpeg-turbo/3.0.2#1acc4234a921c5c948652e04c77d3d80 - Cache
    libmount/2.39#9b2a81545c28668d2281639cc1657dd5 - Cache
    libpng/1.6.42#fdba4ebf89df3c55d6db0145a2a66a24 - Cache
    libselinux/3.5#776f35e238362c6b893220f437cb89ae - Cache
    libsodium/cci.20220430#cd827332735a7278432659372a1efb77 - Cache
    libsvtav1/1.6.0#2c991425604d80f0db9d47f2c3672fd0 - Cache
    libtiff/4.6.0#26284ca6514a94f6f4905e76708c2155 - Cache
    libtool/2.4.7#08316dad5c72c541ed21e039e4cf217b - Cache
    libvpx/1.13.1#31c5cc0bc9fff2b5baf5a1fac60bd9c9 - Cache
    libwebp/1.3.2#52f69c4a31c5cf033fdd9230d77a8e38 - Cache
    libxml2/2.12.3#071b32ddc1353a239d3697319c68beca - Cache
    lz4/1.9.4#1217a03c990b79aa34ed0faede18f534 - Cache
    m4/1.4.19#b38ced39a01e31fef5435bc634461fd2 - Cache
    md4c/0.4.8#02b5e5d8640a6ef9fbd663134edfa1e4 - Cache
    miniz/3.0.2#6e39a83b94a8951a57a0e29969960170 - Cache
    mx_flann/1.0#4ef9112b36b4e7204b95d89c9af0777f - Cache
    mx_miniball/1.0#50d6a2ea935366f44efe67fea2767e91 - Cache
    mx_qwt/6.3.0#96bf49d1b2566ae0b9c613cc6d0b4eb8 - Cache
    odbc/2.3.11#84d32d803c970271eb2fc58d3e3cc2b5 - Cache
    onetbb/2021.10.0#159e2dde755615b9f4d43b6868cdd1d2 - Cache
    opengl/system#b29589c04d6df84c110d6acb066ab653 - Cache
    openssl/3.2.1#39bd48ed31f1f3fbdcd75a0648aaedcf - Cache
    pcre2/10.42#74a354d74d291503aadffe6453d976f5 - Cache
    pugixml/1.14#c6afdcf73d71858303d8260b0d76ff91 - Cache
    qt/6.6.1#dbfcf92fc905fce82a3642de76f06987 - Cache
    sentry-native/0.7.0#853442ce23f3191454c8195c974171a1 - Cache
    snappy/1.1.10#916523630083f6d855cb2977de8eefb6 - Cache
    sqlite3/3.45.0#3a7911478ffd14e7acc694ac113449b6 - Cache
    sumoodbc/2.1.2#7c9e50fc4119f44fe0dce4587c675228 - Cache
    taocpp-json/1.0.0-beta.14#6625bbc6f81b28f09333efd12ff89e17 - Cache
    taocpp-pegtl/3.2.7#cf957bd2b27d4e03bcd6136ecfcbcf96 - Cache
    utfcpp/4.0.4#6d93b29490c5cba2a9b4c06ae0c89cfd - Cache
    util-linux-libuuid/2.39.2#339f80aea7e5cf507b5b9839a128909f - Cache
    v8/12.1.285.28#cb89122f89e0237bac14202de1f3b9fb - Cache
    vtk/9.3.0#5b8c6fdcf3a78daefbd1f9409cf9501f - Cache
    wayland/1.22.0#44a1f9bf1092bea2f3d38e50db225ea6 - Cache
    xkbcommon/1.5.0#9a5d6acb805f1f7d5c3162dfd45fa23b - Cache
    xkeyboard-config/system#57dd5c08e72ab06bc2ee0e756c0a2c41 - Cache
    xorg/system#c7039fe88e71c34398de15694304f0f0 - Cache
    xz_utils/5.4.5#a26a2d42ab9c3dabc151bbe1bf898e53 - Cache
    zlib/1.3.1#af8f2ef3d8e0fddf1975281d7fe43bf6 - Cache
    zstd/1.5.5#b87dc3b185caa4b122979ac4ae8ef7e8 - Cache
Build requirements
    autoconf/2.71#00a1e46d8ba5baaf7f10d64c1a6a0342 - Cache
    automake/1.16.5#058bda3e21c36c9aa8425daf3c1faf50 - Cache
    b2/4.10.1#a41eecb267963ddf518e3c177eae60e1 - Cache
    bison/3.8.2#ed1ba0c42d2ab7ab64fc3a62e9ecc673 - Cache
    bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4 - Cache
    cmake/3.28.1#92f79424d7b65b12a84a2180866c3a78 - Cache
    expat/2.5.0#91e43e4544923e4c934bfad1fa4306f9 - Cache
    flex/2.6.4#e35bc44b3fcbcd661e0af0dc5b5b1ad4 - Cache
    glib/2.78.1#6da549beee7208bd9fad0e6141581e8e - Cache
    gnu-config/cci.20210814#dc430d754f465e8c74463019672fb97b - Cache
    gperf/3.1#a9335f8833b550f10f655fd243c72978 - Cache
    libelf/0.8.13#4f70a3555809ae50cc8add44f0f84288 - Cache
    libffi/3.4.4#35eb63842b505824b70aedc1baefc916 - Cache
    libiconv/1.17#73fefc1b696e069df90fd1d18aa63edd - Cache
    libmount/2.39#9b2a81545c28668d2281639cc1657dd5 - Cache
    libselinux/3.5#776f35e238362c6b893220f437cb89ae - Cache
    libtool/2.4.7#08316dad5c72c541ed21e039e4cf217b - Cache
    libxml2/2.12.3#071b32ddc1353a239d3697319c68beca - Cache
    m4/1.4.19#b38ced39a01e31fef5435bc634461fd2 - Cache
    meson/1.2.1#8b99e6cc4f6908b594c33d1b85cfa5bd - Cache
    meson/1.2.2#aace9dcc1db58fa42ecb5292f724092d - Cache
    meson/1.2.3#7d2bfe1bfc0c4edd9579e812344d5490 - Cache
    meson/1.3.0#83e9030e0cb3418759e72d3631213a5a - Cache
    meson/1.3.1#23ad39607b5907947ed1a511bc02deee - Cache
    nasm/2.15.05#058c93b2214a49ca1cfe9f8f26205568 - Cache
    ninja/1.11.1#77587f8c8318662ac8e5a7867eb4be21 - Cache
    pcre2/10.42#74a354d74d291503aadffe6453d976f5 - Cache
    pkgconf/2.0.3#f996677e96e61e6552d85e83756c328b - Cache
    pkgconf/2.1.0#27f44583701117b571307cf5b5fe5605 - Cache
    sqlite3/3.45.1#d5f7ab74b4670ea4e2bceb366f491322 - Cache
    wayland/1.22.0#44a1f9bf1092bea2f3d38e50db225ea6 - Cache
    wayland-protocols/1.32#d871f62234751f8d72e90445a44d5e49 - Cache
    yasm/1.3.0#fb800a15413dca19bfaef9e4b5d50694 - Cache
    zlib/1.3.1#af8f2ef3d8e0fddf1975281d7fe43bf6 - Cache
Replaced requires
    libjpeg-turbo/3.0.1: libjpeg-turbo/[>3]
    expat/2.6.0: expat/[>2]
    expat/2.5.0: expat/[>2]
    expat/[=2.6.0]: expat/[>2]
    libjpeg-turbo/[>=2.1.5]: libjpeg-turbo/[>3]
    libjpeg-turbo/3.0.2: libjpeg-turbo/[>3]
Resolved version ranges
    catch2/[>=2.13.9]: catch2/3.5.2
    cmake/[>=3.16 <4]: cmake/3.28.1
    cmake/[>=3.18 <4]: cmake/3.28.1
    cmake/[>=3.21.1 <4]: cmake/3.28.1
    cppcsv/[>=1.1]: cppcsv/1.1
    date/[>=3.0.1]: date/3.0.1
    detectproxy/[>=1.0]: detectproxy/1.0
    eigen/[>=3.4.0]: eigen/3.4.0
    expat/[>2]: expat/2.6.0
    exprtk/[=0.0.1]: exprtk/0.0.1
    ffmpeg/[>=5.1]: ffmpeg/6.1
    flatbuffers/[>=23.1.21]: flatbuffers/23.5.26
    fmt/[>10]: fmt/10.2.1
    glew/[>=2.2.0]: glew/2.2.0
    gperf/[>=3.1]: gperf/3.1
    icu/[>=74.1]: icu/74.2
    jansson/[>=2.14]: jansson/2.14
    jidac/[>=2.0.0]: jidac/2.0.0
    kissfft/[>=131.1.0]: kissfft/131.1.0
    libcurl/[>=7.88.1]: libcurl/8.6.0
    libjpeg-turbo/[>3]: libjpeg-turbo/3.0.2
    libtiff/[>=4.4.0]: libtiff/4.6.0
    lz4/[>=1.9.4]: lz4/1.9.4
    miniz/[>=3.0.2]: miniz/3.0.2
    mx_flann/[>=1.0]: mx_flann/1.0
    mx_miniball/[>=1.0]: mx_miniball/1.0
    mx_qwt/[>=6.3.0]: mx_qwt/6.3.0
    odbc/[>=2.3.11]: odbc/2.3.11
    onetbb/[>=2021.9.0]: onetbb/2021.10.0
    openssl/[>=1.1 <4]: openssl/3.2.1
    pugixml/[>=1.13]: pugixml/1.14
    qt/[>=6.4.2]: qt/6.6.1
    sentry-native/[>=0.7.0]: sentry-native/0.7.0
    snappy/[>=1.1.10]: snappy/1.1.10
    sqlite3/[>=3.41.1]: sqlite3/3.45.1
    sumoodbc/[>=2.1.2]: sumoodbc/2.1.2
    utfcpp/[>=3.2.3]: utfcpp/4.0.4
    v8/[>=11]: v8/12.1.285.28
    vtk/[>=9.2.6]: vtk/9.3.0
    xz_utils/[>=5.4.2]: xz_utils/5.4.5
    zlib/[>=1.2.11 <2]: zlib/1.3.1
    zlib/[>=1.2.13 <2]: zlib/1.3.1
Overrides
    libpng/[>=1.6.40]: ['libpng/1.6.42#fdba4ebf89df3c55d6db0145a2a66a24']

======== Computing necessary packages ========
Requirements
    autoconf/2.71#00a1e46d8ba5baaf7f10d64c1a6a0342:da39a3ee5e6b4b0d3255bfef95601890afd80709#7440f8a166fc2063a7fc2b7bed8eacb3 - Cache
    automake/1.16.5#058bda3e21c36c9aa8425daf3c1faf50:9a4eb3c8701508aa9458b1a73d0633783ecc2270#9719e51a6a62041af6a63e00eef35434 - Cache
    boost/1.82.0@mxrap/fork-2024-02-14#8877fe5af80b10ad04946036dba4328c:91104df280f391ef8a9567fbe20b70e8b32c0cdd - Build
    brotli/1.1.0#d56d7bb9ca722942aba17369cb5c0519:ceb9bc7ad6513df254510720f6844ea3bac97497#c3e709c324fd054620d78f6d257abcf7 - Cache
    bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4:80c69de683d89119028faa81cc723e34fa1572fb#e78a144c9ba1b914e2861ee4edda9fde - Cache
    catch2/3.5.2#9554dc3c4ffcab50daf8f2cac4b79308:4bdefc9501198a3580eed19eeb7e54d07ea22946#e4e92784c782f9240554654ece3b1675 - Cache
    cppcsv/1.1#b610f7745e66a09df84c6d0d64492ecd:bd18d47901a90c44e59196b2ab6e579d12f5fd17#35eb7cf4488656ae3be404d37a299502 - Cache
    date/3.0.1#032e24ad8bd1fd136dd33c932563d3d1:4a2f42c9f39192f60db4aeb3cb875a319d0796d1 - Build
    dav1d/1.2.1#94259c8baa2b1e7ab9976f1c20822be8:06851aa2da8b2e46c40b3162e29de411767b2a3a - Build
    detectproxy/1.0#50477780f21ab2d2757429950710aa07:bd18d47901a90c44e59196b2ab6e579d12f5fd17#1d3808d37bb224e9815c13b91da60b39 - Cache
    double-conversion/3.3.0#33321c201741cc32b51169c6d2d05e60:bd18d47901a90c44e59196b2ab6e579d12f5fd17#eb76fb4a1fb01fb7ed9d5f8a2edfa227 - Cache
    eigen/3.4.0#2e192482a8acff96fe34766adca2b24c:da39a3ee5e6b4b0d3255bfef95601890afd80709#b2e7c2d86c5d1dbefc534889aa72e12c - Cache
    expat/2.6.0#2f92fb3cf504e9731aba6d20dcd641bf:64a31da11ffe6e640b9606e8dfb9ce2db3ec6462#c8be808d7b8811c67baa9039c129355b - Cache
    exprtk/0.0.1#3ab94cf4d8edf2154065abe6fe6bba5d:da39a3ee5e6b4b0d3255bfef95601890afd80709#412bb1dd793ae3588eea073733075d77 - Cache
    fast_float/3.9.0#18511f44fc573907e03e7648bb8f9a22:da39a3ee5e6b4b0d3255bfef95601890afd80709#77e45e66282092c664f6830e32773c3b - Cache
    ffmpeg/6.1#85d65b4d431f9ee9112724c965040eeb:43783b88effa5ed39d8dd399df4455211fe48316 - Build
    flatbuffers/23.5.26#b153646f6546daab4c7326970b6cd89c:54f5f316248bc191405ace910e7d11565dbc82fa#4c5a894c9d11eed1950e85be29a6065e - Cache
    fmt/10.2.1#9199a7a0611866dea5c8849a77467b25:91eb4f2f4864db28a22cbd828e772410492b153e#4ebf198ac8e81f3a747b71a0e0115107 - Cache
    fontconfig/2.15.0#15a13e5b6d5931ff0144f92b579f6dd5:faf7a2fbc4486f67641c406c0728f4ab7ddd1727 - Build
    freetype/2.13.2#fa35264c88edc6421a850d08c67630f4:5172f240a28775a32262dc0d9e5eb68de4e392b0#1da6133ff1018e03335fbf5f3603a099 - Cache
    glew/2.2.0#e5519ddcf52267be816b50d3dfa14a23:2e8dbf91884b2ac31300706641917157ddb894be - Build
    glib/2.78.1#6da549beee7208bd9fad0e6141581e8e:2c028c40c3fd0ee654ad5353afaa33098dd9fe3f - Build
    glm/cci.20230113#c9c89bea128786a245028f0cb4c1936d:da39a3ee5e6b4b0d3255bfef95601890afd80709#6e0f3e7e82ccc211e8cc3c012d8c42ef - Cache
    glu/system#ee50fc2ade0e1c0c8ebb3be3ea60e0f5:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache
    harfbuzz/8.3.0#7e7ea00066eaaa818d469d24dbc3a106:85d4d4e994a07cb598af71787032445c977d3d69 - Build
    hwloc/2.9.3#7b004fab2336e27d686e9ae08dcf4b0d:d3239fddd06926acc0aa1adc21b10aa4f6ae0c56#dc0ed4c633b22c1c21dbfd33fe4470a9 - Cache
    icu/74.2#129a9b08abace8b2c748a567fc9b843a:e7393a738becff161394a967b98eb6ac76e73bdc#6574fa83bc9946cb1be7dd86bb0ce410 - Cache
    jansson/2.14#42fc601d5b8e236e050e48f2321ef851:d089c2d18748cadc7d9e5e91fddad40e367cac56#0282d4dd705432544bd790c8dbf71496 - Cache
    jbig/20160605#2d29fa02aacd76902e0d2cbbc24631ef:78a91b6ca485bda6cf3e62ac55b2265129bf5b52#20b8b0d0c4211d23d1c3afec2fc50e2f - Cache
    jidac/2.0.0#c3ea07915f779440c6d2c28ab0c23bb8:a9acc1ed2c6511881770c6900d30e9a9717402be - Build
    kissfft/131.1.0#2c2e2135e1e57415db301df1942b2d84:7a7825ae5667b7d977d0cbfea9ae8c287596ae3f#a4bff14eab90e0a5132125530604b9c4 - Cache
    libaom-av1/3.6.1#a569b342c6f8129cf327709e18691072:19b212f4ed69d627b5d2283f19312074df2b0fe0#75bcbeafb493ffa42617c007ad47a02b - Cache
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d#6e48c3aa19010c0e7b7f1daa2b339494 - Cache
    libcurl/8.6.0#ff220b1555b8aebbb78440b25d471217:a759bb2f96c916e0a402351a38aefd6de8803a74 - Build
    libdeflate/1.19#3ea74a4549efc14d4b1202dc4bfbf602:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d#5857f479bfbaf4ba74d58c37b00991f5 - Cache
    libelf/0.8.13#4f70a3555809ae50cc8add44f0f84288:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d - Build
    libffi/3.4.4#35eb63842b505824b70aedc1baefc916:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d#6bd1ddf818f5f7367bac2cd13ce61829 - Cache
    libiconv/1.17#73fefc1b696e069df90fd1d18aa63edd:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d#22fc9b68ac54f06de316a13cf760318e - Cache
    libjpeg-turbo/3.0.2#1acc4234a921c5c948652e04c77d3d80:5a7ac12e894a6984b2baa3fc4841d81f34abcb62 - Build
    libmount/2.39#9b2a81545c28668d2281639cc1657dd5:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d#21906a123f82fede044d66853281db15 - Cache
    libpng/1.6.42#fdba4ebf89df3c55d6db0145a2a66a24:253f5a6b83d8ad9dec12ea9d7210d92c7241dcdc#dcb473ca4bdd49c27919853f29e5af4a - Cache
    libselinux/3.5#776f35e238362c6b893220f437cb89ae:5ec22dd531d4441a2579b655cfadefd9430d05d4 - Build
    libsodium/cci.20220430#cd827332735a7278432659372a1efb77:a48f410f2b4b585550252680e514024ab5bc59eb#51793910c567b755daa9083c4bd2c1a9 - Cache
    libsvtav1/1.6.0#2c991425604d80f0db9d47f2c3672fd0:bc0bf7a01697430f47c73712dff4ccd76aeec5c9 - Build
    libtiff/4.6.0#26284ca6514a94f6f4905e76708c2155:81485f011a7b7af2dd17d97f54817703c72cf8a8 - Build
    libtool/2.4.7#08316dad5c72c541ed21e039e4cf217b:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d - Build
    libvpx/1.13.1#31c5cc0bc9fff2b5baf5a1fac60bd9c9:1173811460f1cda7ccd601841cd227eeb81330d5 - Build
    libwebp/1.3.2#52f69c4a31c5cf033fdd9230d77a8e38:028f3880e5f0f236e595b34a54f56fb6cc87164c#00f69b8136cdb2821b2f4ff742106527 - Cache
    libxml2/2.12.3#071b32ddc1353a239d3697319c68beca:3e472b6fca079e2118abd77d4d35e3dba94e33dc - Build
    lz4/1.9.4#1217a03c990b79aa34ed0faede18f534:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d#3fd63114f49027537f23255cfb09c0f5 - Cache
    m4/1.4.19#b38ced39a01e31fef5435bc634461fd2:6c3784688ce1ae7a69d803259982d21dd8171d61#3161ad8b3b0b622dd8e403da1bbe209e - Cache
    md4c/0.4.8#02b5e5d8640a6ef9fbd663134edfa1e4:89c64f669d5c1be48700bb3ec0ee92f6767a4785#431710cebfbdb5db25609839916770e6 - Cache
    miniz/3.0.2#6e39a83b94a8951a57a0e29969960170:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d#7a661a590ba9a30076664f97530a8354 - Cache
    mx_flann/1.0#4ef9112b36b4e7204b95d89c9af0777f:da39a3ee5e6b4b0d3255bfef95601890afd80709#d5aa32dcc8012fbf4afeb353b73456ce - Cache
    mx_miniball/1.0#50d6a2ea935366f44efe67fea2767e91:da39a3ee5e6b4b0d3255bfef95601890afd80709#acc197e0c86f02ebfd2176cc2aee6289 - Cache
    mx_qwt/6.3.0#96bf49d1b2566ae0b9c613cc6d0b4eb8:6c5b333b7b311a2576c35382e8e3fd8473c5f32c - Build
    odbc/2.3.11#84d32d803c970271eb2fc58d3e3cc2b5:eeb898e7a102636cc02f6aaa4a333c1eeac2b7ec - Build
    onetbb/2021.10.0#159e2dde755615b9f4d43b6868cdd1d2:b810e8744b9cde382ac7f5366ccbbcad320e8329 - Build
    opengl/system#b29589c04d6df84c110d6acb066ab653:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache
    openssl/3.2.1#39bd48ed31f1f3fbdcd75a0648aaedcf:d8f548d482dfa20a4de4b7f67dbb821aaa719cc2 - Build
    pcre2/10.42#74a354d74d291503aadffe6453d976f5:ab384aa623575c50c2aba4c7efce6d4c6ca50f5d - Build
    pugixml/1.14#c6afdcf73d71858303d8260b0d76ff91:2af46fefc998757da9f1267c269272cb8d5ce5c0#505aa75f17b849e21a1fd5a44a97c0d3 - Cache
    qt/6.6.1#dbfcf92fc905fce82a3642de76f06987:95c8e4972e207f6ced679994ac21da4e71bfb464 - Build
    sentry-native/0.7.0#853442ce23f3191454c8195c974171a1:04a396d07daffe526a1bd93031ab62df10027620 - Build
    snappy/1.1.10#916523630083f6d855cb2977de8eefb6:ff30f73d6033b37751b0853cb36c7b78048f52be#a970160673dd74bdfffe926ef3f8fee1 - Cache
    sqlite3/3.45.0#3a7911478ffd14e7acc694ac113449b6:352b452ff0c450b0fdae7f69fadcf59ce3daba94#1e2aa0690a3863545826e84d3e58fbd5 - Cache
    sumoodbc/2.1.2#7c9e50fc4119f44fe0dce4587c675228:c5a7951c0d072cb3977589289934b5c392cf3b92 - Build
    taocpp-json/1.0.0-beta.14#6625bbc6f81b28f09333efd12ff89e17:da39a3ee5e6b4b0d3255bfef95601890afd80709#e65661e12c8b140444943769c489af3d - Cache
    taocpp-pegtl/3.2.7#cf957bd2b27d4e03bcd6136ecfcbcf96:da39a3ee5e6b4b0d3255bfef95601890afd80709#6e51780c75b577aa0844220a73c663b0 - Cache
    utfcpp/4.0.4#6d93b29490c5cba2a9b4c06ae0c89cfd:da39a3ee5e6b4b0d3255bfef95601890afd80709#7e44739b8ca92dcceda0a464cdaacaa8 - Cache
    util-linux-libuuid/2.39.2#339f80aea7e5cf507b5b9839a128909f:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d#ac29ad6c4f5c246e1c4ab2203de5bf23 - Cache
    v8/12.1.285.28#cb89122f89e0237bac14202de1f3b9fb:5aedbb9f5ae5fad708974ca0c916c011975cb3b1 - Build
    vtk/9.3.0#5b8c6fdcf3a78daefbd1f9409cf9501f:9692b17b9f7bb18db07cf4542d02d266e2298d18 - Build
    wayland/1.22.0#44a1f9bf1092bea2f3d38e50db225ea6:43b83b40ac8f89c58c0f0db54d2712ad128fd198 - Build
    xkbcommon/1.5.0#9a5d6acb805f1f7d5c3162dfd45fa23b:0ec47c5388ab8956dff9f79750cd01d4a2820bdd - Build
    xkeyboard-config/system#57dd5c08e72ab06bc2ee0e756c0a2c41:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache
    xorg/system#c7039fe88e71c34398de15694304f0f0:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache
    xz_utils/5.4.5#a26a2d42ab9c3dabc151bbe1bf898e53:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d#ee31ae04029654bf8d287b3dcdcc636a - Cache
    zlib/1.3.1#af8f2ef3d8e0fddf1975281d7fe43bf6:2bbbe5e6fe66c9dba6213afa93fb91e2f7f0484d#200a92607557f0f048df58e062fea80e - Cache
    zstd/1.5.5#b87dc3b185caa4b122979ac4ae8ef7e8:5ef4fc2d44b5db736fe553ebaf1fe09e888ede1e#f5c6404c6282d80024b1279b4ab96d9a - Cache
Build requirements
    autoconf/2.71#00a1e46d8ba5baaf7f10d64c1a6a0342:da39a3ee5e6b4b0d3255bfef95601890afd80709#7440f8a166fc2063a7fc2b7bed8eacb3 - Cache
    automake/1.16.5#058bda3e21c36c9aa8425daf3c1faf50:9a4eb3c8701508aa9458b1a73d0633783ecc2270#9719e51a6a62041af6a63e00eef35434 - Cache
    b2/4.10.1#a41eecb267963ddf518e3c177eae60e1:63fead0844576fc02943e16909f08fcdddd6f44b#a31a98f757dcf4d3f03ed629ccde26b7 - Cache
    bison/3.8.2#ed1ba0c42d2ab7ab64fc3a62e9ecc673:17ad4d5c3257f84af9dc4113dcd7d44c6cb127c3 - Build
    bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4:31760d9b53a05c7bca58eebb9fbe9fec51b1db48#0630c212c24894969aea96bf669dddb8 - Cache
    cmake/3.28.1#92f79424d7b65b12a84a2180866c3a78:63fead0844576fc02943e16909f08fcdddd6f44b#501f62ef1d3711dd838dc1d91a2d866e - Cache
    expat/2.5.0#91e43e4544923e4c934bfad1fa4306f9:e2ff88a03ad81f633d1a681f2d4b14e1c07f0aec#0b192003c04d9d8ac22adf20eb5b4cff - Cache
    flex/2.6.4#e35bc44b3fcbcd661e0af0dc5b5b1ad4:2d2cbb55bd688788c0b7abf4e50220b8c123c3f6 - Build
    glib/2.78.1#6da549beee7208bd9fad0e6141581e8e:4b10dba5ede166bc7e698771fe0389320890c63a - Build
    gnu-config/cci.20210814#dc430d754f465e8c74463019672fb97b:da39a3ee5e6b4b0d3255bfef95601890afd80709#22618e30bd9e326eb95e824dc90cc860 - Cache
    gperf/3.1#a9335f8833b550f10f655fd243c72978:3593751651824fb813502c69c971267624ced41a#c608a2587510f59ceb92a1076199e854 - Cache
    libelf/0.8.13#4f70a3555809ae50cc8add44f0f84288:2d2cbb55bd688788c0b7abf4e50220b8c123c3f6 - Build
    libffi/3.4.4#35eb63842b505824b70aedc1baefc916:2d2cbb55bd688788c0b7abf4e50220b8c123c3f6#6f26d45cd9cdfd2d54c9a2f3b117c207 - Cache
    libiconv/1.17#73fefc1b696e069df90fd1d18aa63edd:2d2cbb55bd688788c0b7abf4e50220b8c123c3f6#9090c2a104f1c2c4d5770e85ae01d5a8 - Cache
    libmount/2.39#9b2a81545c28668d2281639cc1657dd5:2d2cbb55bd688788c0b7abf4e50220b8c123c3f6#173a88133087bf10f8ccfd27fa8b2b9b - Cache
    libselinux/3.5#776f35e238362c6b893220f437cb89ae:398b1ccf1e38a4df0e8344e05b87f1bb3d51caa8 - Build
    libtool/2.4.7#08316dad5c72c541ed21e039e4cf217b:2d2cbb55bd688788c0b7abf4e50220b8c123c3f6 - Build
    libxml2/2.12.3#071b32ddc1353a239d3697319c68beca:544b2004f8424bd5f236db74a19be2568ad84ae7 - Build
    m4/1.4.19#b38ced39a01e31fef5435bc634461fd2:3593751651824fb813502c69c971267624ced41a#cd8019a4f9b70880d548f7cc26569604 - Cache
    meson/1.2.1#8b99e6cc4f6908b594c33d1b85cfa5bd:da39a3ee5e6b4b0d3255bfef95601890afd80709#51dbda0520bc1033fd5d946750e9890f - Cache
    meson/1.2.2#aace9dcc1db58fa42ecb5292f724092d:da39a3ee5e6b4b0d3255bfef95601890afd80709#2bfd29b9a8744e08daf4c11bdb43a4ce - Cache
    meson/1.2.3#7d2bfe1bfc0c4edd9579e812344d5490:da39a3ee5e6b4b0d3255bfef95601890afd80709#4becb3f1c11645ff6ca5e0618cef53e7 - Cache
    meson/1.3.0#83e9030e0cb3418759e72d3631213a5a:da39a3ee5e6b4b0d3255bfef95601890afd80709#58c1084c0045f884355e79a276509348 - Cache
    meson/1.3.1#23ad39607b5907947ed1a511bc02deee:da39a3ee5e6b4b0d3255bfef95601890afd80709#63cd3207f6b4bc458239ae82c3e98e8f - Cache
    nasm/2.15.05#058c93b2214a49ca1cfe9f8f26205568:3593751651824fb813502c69c971267624ced41a#b92f40dda62a874cc15bf99a195d87f0 - Cache
    ninja/1.11.1#77587f8c8318662ac8e5a7867eb4be21:3593751651824fb813502c69c971267624ced41a#60e6fc0f973babfbed66a66af22a4f02 - Cache
    pcre2/10.42#74a354d74d291503aadffe6453d976f5:122db34ee0ac7598d8873f57e3976b7cb6ad19f8 - Build
    pkgconf/2.0.3#f996677e96e61e6552d85e83756c328b:c0b621fd4b3199fe05075171573398833dba85f4#625ebc76863307827004d778d898184a - Cache
    pkgconf/2.1.0#27f44583701117b571307cf5b5fe5605:c0b621fd4b3199fe05075171573398833dba85f4#74a82dec52448dda20253a19d65965c7 - Cache
    sqlite3/3.45.1#d5f7ab74b4670ea4e2bceb366f491322:179bf039166cdd360e76da9bdf9e83fd56fb2da9#4cb59f5608fb1ec8bac7c559a104b8f9 - Cache
    wayland-protocols/1.32#d871f62234751f8d72e90445a44d5e49:da39a3ee5e6b4b0d3255bfef95601890afd80709#6746bae53eb0ea0d4a69e958720820d5 - Cache
    wayland/1.22.0#44a1f9bf1092bea2f3d38e50db225ea6:8b4d4ff4abf6195cefa0cc1919cfef036fa43399 - Build
    yasm/1.3.0#fb800a15413dca19bfaef9e4b5d50694:3593751651824fb813502c69c971267624ced41a#de209941eeb4029e79a7a33bfefe9a98 - Cache
    zlib/1.3.1#af8f2ef3d8e0fddf1975281d7fe43bf6:2d2cbb55bd688788c0b7abf4e50220b8c123c3f6 - Build
```



```
-------- Installing package pcre2/10.42 (77 of 112) --------
pcre2/10.42: Building from source
pcre2/10.42: Package pcre2/10.42:122db34ee0ac7598d8873f57e3976b7cb6ad19f8
pcre2/10.42: Copying sources to build folder
pcre2/10.42: Building your package in /home/paul/.conan2/p/b/pcre23332948d523dd/b
pcre2/10.42: Calling generate()
pcre2/10.42: Generators folder: /home/paul/.conan2/p/b/pcre23332948d523dd/b/build/Release/generators
pcre2/10.42: CMakeToolchain generated: conan_toolchain.cmake
pcre2/10.42: CMakeToolchain generated: CMakePresets.json
pcre2/10.42: CMakeToolchain generated: ../../../src/CMakeUserPresets.json
pcre2/10.42: Generating aggregated env files
pcre2/10.42: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
pcre2/10.42: Calling build()
pcre2/10.42: apply_conandata_patches(): No patches defined in conandata
pcre2/10.42: Running CMake.configure()
pcre2/10.42: RUN: cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="/home/paul/.conan2/p/b/pcre23332948d523dd/b/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/paul/.conan2/p/b/pcre23332948d523dd/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/paul/.conan2/p/b/pcre23332948d523dd/b/src"
CMake Deprecation Warning at CMakeLists.txt:106 (CMAKE_MINIMUM_REQUIRED):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Using Conan toolchain: /home/paul/.conan2/p/b/pcre23332948d523dd/b/build/Release/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The C compiler identification is Clang 17.0.6
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/clang-17 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Conan: Target declared 'BZip2::BZip2'
-- Conan: Including build module from '/home/paul/.conan2/p/b/bzip27b557cc7fd54c/p/lib/cmake/conan-official-bzip2-variables.cmake'
-- Conan: Target declared 'ZLIB::ZLIB'
CMake Warning at CMakeLists.txt:129 (FIND_PACKAGE):
  By not providing "FindReadline.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Readline",
  but CMake did not find one.

  Could not find a package configuration file provided by "Readline" with any
  of the following names:

    ReadlineConfig.cmake
    readline-config.cmake

  Add the installation prefix of "Readline" to CMAKE_PREFIX_PATH or set
  "Readline_DIR" to a directory containing one of the above files.  If
  "Readline" provides a separate development package or SDK, be sure it has
  been installed.


CMake Warning at CMakeLists.txt:130 (FIND_PACKAGE):
  By not providing "FindEditline.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Editline",
  but CMake did not find one.

  Could not find a package configuration file provided by "Editline" with any
  of the following names:

    EditlineConfig.cmake
    editline-config.cmake

  Add the installation prefix of "Editline" to CMAKE_PREFIX_PATH or set
  "Editline_DIR" to a directory containing one of the above files.  If
  "Editline" provides a separate development package or SDK, be sure it has
  been installed.


-- Looking for dirent.h
-- Looking for dirent.h - found
-- Looking for sys/stat.h
-- Looking for sys/stat.h - found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for unistd.h
-- Looking for unistd.h - found
-- Looking for windows.h
-- Looking for windows.h - not found
-- Looking for bcopy
-- Looking for bcopy - found
-- Looking for memfd_create
-- Looking for memfd_create - not found
-- Looking for memmove
-- Looking for memmove - found
-- Looking for secure_getenv
-- Looking for secure_getenv - not found
-- Looking for strerror
-- Looking for strerror - found
-- Performing Test HAVE_REALPATH
-- Performing Test HAVE_REALPATH - Success
-- Performing Test HAVE_ATTRIBUTE_UNINITIALIZED
-- Performing Test HAVE_ATTRIBUTE_UNINITIALIZED - Success
-- Performing Test INTEL_CET_ENABLED
-- Performing Test INTEL_CET_ENABLED - Failed
-- 
-- 
-- PCRE2-10.42 configuration summary:
-- 
--   Install prefix .................. : /home/paul/.conan2/p/b/pcre23332948d523dd/p
--   C compiler ...................... : /usr/bin/clang-17
--   C compiler flags ................ : -m64 -O3 -DNDEBUG
-- 
--   Build 8 bit PCRE2 library ....... : True
--   Build 16 bit PCRE2 library ...... : True
--   Build 32 bit PCRE2 library ...... : True
--   Enable JIT compiling support .... : False
--   Use SELinux allocator in JIT .... : OFF
--   Enable Unicode support .......... : ON
--   Newline char/sequence ........... : LF
--   \R matches only ANYCRLF ......... : OFF
--   \C is disabled .................. : OFF
--   EBCDIC coding ................... : OFF
--   EBCDIC coding with NL=0x25 ...... : OFF
--   Rebuild char tables ............. : OFF
--   Internal link size .............. : 2
--   Parentheses nest limit .......... : 250
--   Heap limit ...................... : 20000000
--   Match limit ..................... : 10000000
--   Match depth limit ............... : MATCH_LIMIT
--   Build shared libs ............... : OFF
--   Build static libs ............... : ON
--      with PIC enabled ............. : OFF
--   Build pcre2grep ................. : True
--   Enable JIT in pcre2grep ......... : ON
--   Enable callouts in pcre2grep .... : ON
--   Enable callout fork in pcre2grep. : True
--   Buffer size for pcre2grep ....... : 20480
--   Build tests (implies pcre2test .. : OFF
--                and pcre2grep)
--   Link pcre2grep with libz ........ : True
--   Link pcre2grep with libbz2 ...... : True
--   Link pcre2test with libeditline . : Library not found
--   Link pcre2test with libreadline . : Library not found
--   Support Valgrind .................: OFF
--   Use %zu and %td ..................: AUTO
-- 
-- Configuring done (3.4s)
-- Generating done (0.0s)
-- Build files have been written to: /home/paul/.conan2/p/b/pcre23332948d523dd/b/build/Release

pcre2/10.42: Running CMake.build()
pcre2/10.42: RUN: cmake --build "/home/paul/.conan2/p/b/pcre23332948d523dd/b/build/Release" -- -j8
[1/88] Building C object CMakeFiles/pcre2-8-static.dir/pcre2_chartables.c.o
[2/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_config.c.o
[3/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_error.c.o
[4/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_context.c.o
[5/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_jit_compile.c.o
[6/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_find_bracket.c.o
[7/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_extuni.c.o
[8/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_maketables.c.o
[9/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_match_data.c.o
[10/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_newline.c.o
[11/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_ord2utf.c.o
[12/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_auto_possess.c.o
[13/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_pattern_info.c.o
[14/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_string_utils.c.o
[15/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_serialize.c.o
[16/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_script_run.c.o
[17/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_tables.c.o
[18/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_substring.c.o
[19/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_convert.c.o
[20/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_valid_utf.c.o
[21/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_ucd.c.o
[22/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_substitute.c.o
[23/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_xclass.c.o
[24/88] Building C object CMakeFiles/pcre2-posix-static.dir/src/pcre2posix.c.o
[25/88] Building C object CMakeFiles/pcre2-16-static.dir/pcre2_chartables.c.o
[26/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_study.c.o
[27/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_config.c.o
[28/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_context.c.o
[29/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_error.c.o
[30/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_auto_possess.c.o
[31/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_extuni.c.o
[32/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_find_bracket.c.o
[33/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_jit_compile.c.o
[34/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_maketables.c.o
[35/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_match_data.c.o
[36/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_convert.c.o
[37/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_newline.c.o
[38/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_ord2utf.c.o
[39/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_pattern_info.c.o
[40/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_script_run.c.o
[41/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_serialize.c.o
[42/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_string_utils.c.o
[43/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_study.c.o
[44/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_substitute.c.o
[45/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_tables.c.o
[46/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_substring.c.o
[47/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_dfa_match.c.o
[48/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_ucd.c.o
[49/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_valid_utf.c.o
[50/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_xclass.c.o
[51/88] Building C object CMakeFiles/pcre2-32-static.dir/pcre2_chartables.c.o
[52/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_config.c.o
[53/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_compile.c.o
[54/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_context.c.o
[55/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_auto_possess.c.o
[56/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_error.c.o
[57/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_extuni.c.o
[58/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_find_bracket.c.o
[59/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_jit_compile.c.o
[60/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_convert.c.o
[61/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_maketables.c.o
[62/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_match_data.c.o
[63/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_compile.c.o
[64/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_newline.c.o
[65/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_ord2utf.c.o
[66/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_dfa_match.c.o
[67/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_script_run.c.o
[68/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_pattern_info.c.o
[69/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_serialize.c.o
[70/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_string_utils.c.o
[71/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_substring.c.o
[72/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_study.c.o
[73/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_substitute.c.o
[74/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_tables.c.o
[75/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_valid_utf.c.o
[76/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_xclass.c.o
[77/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_ucd.c.o
[78/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_compile.c.o
[79/88] Building C object CMakeFiles/pcre2-32-static.dir/src/pcre2_dfa_match.c.o
[80/88] Building C object CMakeFiles/pcre2-16-static.dir/src/pcre2_match.c.o
[81/88] Building C object CMakeFiles/pcre2grep.dir/src/pcre2grep.c.o
[82/88] Linking C static library libpcre2-16.a
[83/88] Building C object CMakeFiles/pcre2-8-static.dir/src/pcre2_match.c.o
[84/88] Linking C static library libpcre2-8.a
[85/88] Linking C static library libpcre2-posix.a
[86/88] Linking C executable pcre2grep
FAILED: pcre2grep 
: && /usr/bin/clang-17 -m64 -O3 -DNDEBUG -m64   -rdynamic CMakeFiles/pcre2grep.dir/src/pcre2grep.c.o -o pcre2grep -L/home/paul/.conan2/p/b/zlibfd66b9fe5320a/p/lib   -L/home/paul/.conan2/p/b/bzip27b557cc7fd54c/p/lib -Wl,-rpath,/home/paul/.conan2/p/b/zlibfd66b9fe5320a/p/lib:/home/paul/.conan2/p/b/bzip27b557cc7fd54c/p/lib:  libpcre2-posix.a  libpcre2-8.a  /home/paul/.conan2/p/b/zlibfd66b9fe5320a/p/lib/libz.a  /home/paul/.conan2/p/b/bzip27b557cc7fd54c/p/lib/libbz2.a && :
/usr/bin/ld: /home/paul/.conan2/p/b/bzip27b557cc7fd54c/p/lib/libbz2.a(bzlib.c.o): in function `BZ2_bz__AssertH__fail':
bzlib.c:(.text+0x6d): undefined reference to `__asan_handle_no_return'
```
user: paulharris
issue_15721: state: open
title: A just builded revision is removed from the cash and the dependency cannont be resolved
body: ### What is your question?

Conan version 1.61.0
Python 3.9.2 
gcc (GCC) 11.4.0
Docker Linux 7bc5e2533399 3.10.0-1160.108.1.el7.x86_64 #1 SMP Thu Jan 25 16:17:31 UTC 2024 x86_64 GNU/Linux
debian bullsey

When calling
conan create . master/dev --profile linux_x86_64_gcc11_release
I am getting:

`TMDS_DatabaseScripts/0.4.5@master/dev: WARN: The package TMDS_DatabaseScripts/0.4.5@master/dev:9b4bcd014fea222959933b85507e3c5fa203cc33 doesn't belong to the installed recipe revision, removing folder
`
and a little late this module is missing. 

```
[2024-02-21T15:59:30.500Z] TMDS_DatabaseScripts/0.4.5@master/dev: WARN: Can't find a 'TMDS_DatabaseScripts/0.4.5@master/dev' package for the specified settings, options and dependencies:
[2024-02-21T15:59:30.500Z] - Settings: arch=x86_64, arch_build=x86_64, build_type=Release, compiler=gcc, compiler.cppstd=gnu11, compiler.version=11, os=Linux
[2024-02-21T15:59:30.500Z] - Options: fPIC=True, shared=False, DBGN_Generate:fPIC=True, DBGN_Generate:shared=False, SYVE_Version:fPIC=True, SYVE_Version:shared=False
[2024-02-21T15:59:30.500Z] - Dependencies: DBGN_Generate/0.4.5@master/dev, SYVE_Version/0.4.5@master/dev
[2024-02-21T15:59:30.500Z] - Requirements: DBGN_Generate/0.4.5, SYVE_Version/0.4.5
[2024-02-21T15:59:30.500Z] - Package ID: 9b4bcd014fea222959933b85507e3c5fa203cc33

```

Even if it is available in the remote repo. A curious thing is that i had to force conan to upload it. A normal "conan upload  DBGN_Generate/0.4.5@master/dev --all' does not upload the recepie with the just build profile.

```
conan search DBGN_Generate/0.4.5@master/dev -r artifactory-dev-local

Existing packages for recipe DBGN_Generate/0.4.5@master/dev:

Existing recipe in remote 'artifactory-dev-local':

    Package_ID: 4fda3338ff9db87f8fc041ff024cc67b0420eeac
        [options]
            fPIC: True
            shared: False
        [settings]
            arch: x86_64
            build_type: Release
            compiler: gcc
            compiler.cppstd: gnu11
            compiler.version: 11
            os: Linux
        [requires]
            SYVE_Version/0.4.5@master/dev:800f8f565640878f5c8781b91ff373cc180819df
        Outdated from recipe: False

```


What can be the reason for this?



user: brosmar
issue_15720: state: open
title: [bug] conan profile show fails on Windows
body: ### Environment details

* Operating System+version: Windows 11 Pro 23H2
* Compiler+version: msvc 193
* Conan version: 2.1.0
* Python version: 3.12.2


### Steps to reproduce

1. `conan profile detect`
2. `conan profile show --profile:host default --profile:build default`

Note that I can't reproduce if I completely delete my `~/.conan2` directory.

### Logs

```
$ conan profile show --profile:host default
ERROR: Traceback (most recent call last):
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conan\cli\cli.py", line 281, in main
    cli.run(args)
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conan\cli\cli.py", line 191, in run
    command.run(self._conan_api, args[0][1:])
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conan\cli\command.py", line 158, in run
    sub.run(conan_api, parser, *args)
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conan\cli\command.py", line 172, in run
    info = self._method(conan_api, parent_parser, self._parser, *args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conan\cli\commands\profile.py", line 40, in profile_show
    result = conan_api.profiles.get_profiles_from_args(args)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conan\api\subapi\profiles.py", line 60, in get_profiles_from_args
    cache_settings = self._conan_api.config.settings_yml
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conan\api\subapi\config.py", line 122, in settings_yml
    return Settings(settings)
           ^^^^^^^^^^^^^^^^^^
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conans\model\settings.py", line 189, in __init__
    self._data = {k: SettingsItem(v, "%s.%s" % (name, k))
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conans\model\settings.py", line 35, in __init__
    self._definition[k] = Settings(v, name, k)
                          ^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conans\model\settings.py", line 189, in __init__
    self._data = {k: SettingsItem(v, "%s.%s" % (name, k))
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Quickemu\AppData\Local\Programs\Python\Python312\Lib\site-packages\conans\model\settings.py", line 38, in __init__
    self._definition = [str(v) if v is not None else None for v in definition]
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object is not iterable

ERROR: 'NoneType' object is not iterable
```
user: jwillikers
issue_15715: state: open
title: [feature] CMakeDeps: Support arbitratry component strings
body: ### What is your suggestion?

The experimental check_components_exist property (https://docs.conan.io/2/reference/tools/cmake/cmakedeps.html#check-components-exist) expects the components to be independent libraries.

But there is at least one well known pre-existing example in which the components are just custom strings: https://cmake.org/cmake/help/latest/module/FindCURL.html. curl itself has this information in the pkg-config file (https://github.com/curl/curl/blob/master/libcurl.pc.in#L32) (`pkg-config --variable supported_features libcurl`), and it actually pre-dates even pkg-config by being in curl-config (https://github.com/curl/curl/blob/master/curl-config.in#L44).

Ideally CMakeDeps would allow also such custom strings as components.


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: reddwarf69
issue_15712: state: open
title: [bug] Detecting profile crashes
body: ### Environment details

* GhostBSD 24.01.1, FreeBSD jorisp-ghostbsd 14.0-STABLE FreeBSD 14.0-STABLE GENERIC amd64
* /usr/local/bin/clang++15 (15.0.7) /usr/local/bin/gcc12 (12.2.0)
* Conan version: 2.1.0
* Python version: 3.9.18

### Steps to reproduce

`conan profile detect`

### Logs

ERROR: Traceback (most recent call last):
  File "/home/jorisp/.local/lib/python3.9/site-packages/conan/cli/cli.py", line 281, in main
    cli.run(args)
  File "/home/jorisp/.local/lib/python3.9/site-packages/conan/cli/cli.py", line 191, in run
    command.run(self._conan_api, args[0][1:])
  File "/home/jorisp/.local/lib/python3.9/site-packages/conan/cli/command.py", line 158, in run
    sub.run(conan_api, parser, *args)
  File "/home/jorisp/.local/lib/python3.9/site-packages/conan/cli/command.py", line 172, in run
    info = self._method(conan_api, parent_parser, self._parser, *args)
  File "/home/jorisp/.local/lib/python3.9/site-packages/conan/cli/commands/profile.py", line 68, in profile_detect
    detected_profile = conan_api.profiles.detect()
  File "/home/jorisp/.local/lib/python3.9/site-packages/conan/api/subapi/profiles.py", line 142, in detect
    settings = detect_defaults_settings()
  File "/home/jorisp/.local/lib/python3.9/site-packages/conans/client/conf/detect.py", line 17, in detect_defaults_settings
    compiler, version, compiler_exe = detect_default_compiler()
TypeError: cannot unpack non-iterable NoneType object

ERROR: cannot unpack non-iterable NoneType object

user: jputcu
issue_15708: state: open
title: [feature] Bring some customizability to CMakePresets generated by CMakeToolchain
body: ### What is your suggestion?

Hello,

Currently, Conan's CMakeToolchain allows the use of custom user presets, which is nice.
I can see 2 drawbacks (and corresponding improvements) regarding the way it is handled currently though:
- The CMakePresets written by Conan cannot (AFAIK) be set as _hidden_. This means that when working in an IDE, all the presets will be visible. It would be nice to provide the option to hide the "base" conan presets and only display the user presets inheriting from them. This would improve the UX when working on packages within an IDE.
-  The environment variables defined in a CMakePresets are not extensible from downstream inheriting presets (this is how it's designed in CMake, it's not a Conan issue). This means that, for example, when the Conan test preset sets a value to LD_LIBRARY_PATH, it is not possible to extend this from the user's CMakePresets.json. Could Conan provide a way to set a suffix to its appended environment variables, so that they can be extended from the user's custom preset? This would be something like:
    - Conan's CMakePresets: defines `LD_LIBRARY_PATH${THE_SUFFIX}` variable
    - User's CMakePresets: inherits Conan's preset and defines `LD_LIBRARY_PATH=${SOME_PATH_EXTENSIONS_DESIRED_BY_USER}:${LD_LIBRARY_PATH${THE_SUFFIX}}:${LD_LIBRARY_PATH}`

    > Here I'm using the example of `LD_LIBRARY_PATH` but this would be also nice for `PATH` and other typical env variables set by Conan in the CMakePresets.
    
Please let me know what you think about that,
Thanks the great Conan implementation so far,

Kind regards,
Milan

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: mpll-d
issue_15705: state: open
title: allow self.name/self.version for build_folder_vars
body: Changelog: Feature: Allow ``self.name`` and ``self.version`` in ``build_folder_vars`` attribute and conf.
Docs: https://github.com/conan-io/docs/pull/XXXX

Close https://github.com/conan-io/conan/issues/12326
user: memsharded
issue_15703: state: open
title: [question] retrieve additional information from graph build-order output 
body: ### What is your question?

Hey,

I have a question regarding the output of conan graph build-order. 

I'm trying to filter packages which have set the `upload_policy` to `skip` in order to not build packages in our CI which needs to be rebuild anyway. Beside that I would like to use the output of the build-order json to get all packages which can be promoted from a test remote to a develop remote, when the build in the CI job was successful. It would be possible to get the necessary information by using `graph info` before and afterwards because there the fields `upload_policy` and `binary_remote` are available, which are needed for both use-cases. 

Would it be possible to retrieve the additional information directly from the build-order json as well or do I have to make the additional calls to `graph info` to get them?

I'm using the latest conan version 2.1.

Thanks a lot!

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: nicosmd
issue_15694: state: open
title: [bug] Deployer full_deploy losing the trailing '/' on Virtual Envs generators
body: ### Environment details

* Operating System+version: Windows
* Conan version: 2.0.15
* Python version: 3.9.13


### Steps to reproduce

1. conanfile:

from conan import ConanFile
from conan.tools.layout import basic_layout
from conan.tools.files import copy
from os.path import join as path_join

class DemoRecipe(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    name = "demo_issue"
    version = "1.0.0.0"
    exports_sources = "config/*"

    def layout(self):
        basic_layout(self)

    def package(self):
        copy(self, "config/*", src=self.source_folder, dst=self.package_folder)

    def package_info(self):
        self.cpp_info.includedirs = []
        self.cpp_info.libs = []
        self.cpp_info.bindirs = []
        self.cpp_info.libdirs = []

        self.runenv_info.define_path("MyPackageConfig", path_join(str(self.folders.base_package), "config", ""))

2. run command: conan create .
3. run command: conan install --require demo_issue/1.0.0.0
4. see that 'MyPackageConfig' path includes the trailing slash inside the VirtualRunEnv file.
5. un command: conan install --require demo_issue/1.0.0.0 --deployer=full_deploy.
6. see that 'MyPackageConfig' path lost the trailing slash inside the VirtualRunEnv file.
7. see that 'MyPackageConfig' path includes the trailing slash inside the VirtualRunEnv file.

Thanks

### Logs

_No response_
user: mikirothman
issue_15693: state: open
title: [question] How to bind between custom deployer and an env generator
body: ### What is your question?

Hello

We are writing custom deployer,
it's job is to:
1. copy the artifacts from deps into a single bin folder (dll's / exe's).
2. copy configuration files into folders separated by the dep name (dep/config). 
3. copy assets from the deps into (dep/assets).

The main purpose of the deployer is to Create an installer / docker image.
another purpose is to overcome the windows 'PATH' size limitations... (which we didn't reach yet, but we assume we'll get there soon)

the issue is, when we will implement this deployer, I think we will need to reimplement the VirtualRunEnv generator as well, cause the VirtualRunEnv will still point on the conan cache instead of the newly deployment bin folder (and other possible env vars as well). is this correct ?

how does the default full_deploy deployer achieving the same effect without creating different generator ?  

thanks for any assistance 

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: mikirothman
issue_15689: state: open
title: [bug] path argument no longer position independent for "conan lock create" in Conan 2.1.0
body: ### Environment details

* Operating System+version: Ubuntu 22.04
* Compiler+version: N/A
* Conan version: 2.1.0
* Python version: 3.10.8


### Steps to reproduce

1. ```conan lock create -r myremote -u path/to/conanfile```
2. Conan returns: ```ERROR: Please specify a path to a conanfile or a '--requires=<ref>'```

This doesn't happen if I don't have ```-u``` in the command. It also doesn't happen if I put the path first:
```conan lock create path/to/conanfile -r myremote -u```

This may apply to all commands. I saw it specifically with ```conan lock create```, but after checking, I saw it happen with ```conan create``` as well.

### Logs

_No response_
user: antoinebardoz
issue_15688: state: open
title: [question] How to list outdated dependencies?
body: ### What is your question?

How do I list outdated dependencies required by my recipe? Similar to `npm outdated` for npm.js.
It seems like this is a feature that should exist but search engines and documentation leave me empty-handed.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: stevenwdv
issue_15685: state: open
title: [bug]  "option [...] doesn't exist" when using `[platform_requires]`
body: ### Environment details

* Operating System+version: Linux
* Compiler+version: N/A
* Conan version: 2.1.0
* Python version: 3.10.12

### Steps to reproduce

Specifying package options does not work when these are provided by `[platform_requires]`.

- Create a conanfile with `self.requires('qt/[^6.6.1]', options={'qtnetworkauth': True})`
- Add to your conan profile:
  ```
  [platform_requires]
  qt/6.6.1
  ```
- Execute conan install
- Receive error:
  ```
  ======== Computing dependency graph ========
  ERROR: option 'qtnetworkauth' doesn't exist
  Possible options are []
  ```

I'd expect this to work. Am I missing something? Can I specify in `[platform_requires]` that I have `qtnetworkauth` installed? Adding `qt/6.6.1:qtnetworkauth=True` to that doesn't work.

<details>
<summary><h3>Logs</h3></summary>

```
======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=20
compiler.libcxx=libstdc++11
compiler.version=17
os=Linux
[options]
custom_dependency_opts=True
with_benchmark=True
with_client=True
with_tests=True
[platform_requires]
qt/6.6.1
[conf]
tools.build:compiler_executables={'c': 'clang', 'cpp': 'clang++'}
tools.cmake.cmaketoolchain:generator=Ninja
tools.system.package_manager:mode=check
tools.system.package_manager:tool=apt-get

Profile build:
[settings]
arch=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=20
compiler.libcxx=libstdc++11
compiler.version=17
os=Linux
[platform_requires]
qt/6.6.1
[conf]
tools.build:compiler_executables={'c': 'clang', 'cpp': 'clang++'}
tools.cmake.cmaketoolchain:generator=Ninja
tools.system.package_manager:mode=check
tools.system.package_manager:tool=apt-get


======== Computing dependency graph ========
ERROR: option 'qtnetworkauth' doesn't exist
Possible options are []
```
</details>
user: stevenwdv
issue_15684: state: open
title: [feature] The git clone URL is no longer logged.
body: ### Environment details

* Conan version: >= 2.1.0, specifically any version after https://github.com/conan-io/conan/pull/15514 



### Steps to reproduce

Any Git(self).clone command will no longer log the URL, instead show `<hidden>`.

### Logs

```
user997@ffaebed02c7c:/recipes/boto3$ conan source .
conanfile.py (boto3/1.26.144): Calling source() in /recipes/boto3/src
conanfile.py (boto3/1.26.144): Cloning git repo
conanfile.py (boto3/1.26.144): RUN: git clone "<hidden>" --branch 1.26.144 --depth 1 "."
```

We fork all our thirdparties internally so we have stable URLs in case they disappear and to avoid hitting external servers too much. As a side-effect, we build up our URLs as `https://internalgitserver/our-thirdparties/{name}.git` (and potentially use `git@internalgitserver:our-thirdparites/{name}.git` for local development).
Since Conan 2 removed the authentication options initially (see e.g. https://github.com/conan-io/docs/issues/2918), we are using git credential.helpers which we configure in our CI pipelines, which makes it trivial to provide credentials via Jenkins, GitLab CI, etc.:
```
[credential "https://internaltgitserver"]
    helper = "!f() { test \"$1\" = \"get\" && printf \"username=%s\\npassword=%s\" \"${GIT_USERNAME}\" \"${GIT_PASSWORD}\"; }; f"
```
Thus our credentials are masked by the CI runner already and we do not store them inside the recipes or anything.
However, due to the "dynamic" nature of our URLs, it is nice to actually see them -- with the recent change to hide the URLs, it's always a little bit of guesswork if the URL was actually correct.

As a work-around, I added logs for all recipes now, so it's no big blocker, but if there is need, I would offer to provide a patch to make the url-hiding optional.
user: shoeffner
issue_15682: state: open
title: Bring back metadata deployer test
body: Changelog: Omit
Docs: Omit

As part of https://github.com/conan-io/docs/pull/3589

user: RubenRBS
issue_15680: state: open
title: [question] installing a conanfile.py for exporting a package
body: ### What is your question?

Hello, I'm trying to build an ADK with conan, but I'm getting some troubles.

I'm using conanfile.py for doing that, and I'm executing inside a folder called `build`, once I launch the command `conan install -v -pr macos ..` it basically answer me with this error:
```
ERROR: Manifest folder does not exist: /Applications/Graphisoft Archicad API DevKit 27.3001/build/.conan_manifests
```
This actually happens only if I use the flag `-v`, otherwise it would look like everything was working fine.

The main problem is that it should copy some files inside this `build` folder (I attached the conanfile.py that shows the passages), but this doesn't happen because the `build` folder contains only 4 small files (conan.lock, conanbuildinfo.txt, conaninfo.txt, graph_info.json) which are almost empty.

**conanfile.py**
```python
# Usage:
# archicad_adk/build$ conan install -pr <windows|macos> ..
# archicad_adk/build$ conan export-pkg [--force] .. archicad_adk/24.3009@

#WARNING: The JSON module has wrong include paths. 
#The module is linked however so you can change every failing include from #include "JSON/x.h" to #include "x.h" to make it work.
#Alternatively it may be possible to set an additional include path but this is yet to be done.

#Note: For some reason building the package on macOS doesn't work with a warning that no files were found.
#Copy by hand what package() would do otherwise

# On MacOS: remove quarantine attributes
# cd /Applications/GRAPHISOFT ARCHICAD API DevKit 24.3009/Support/Tools/OSX
# sudo xattr -d com.apple.quarantine ResConv Support/*

# MD5 hashes:
# 190911.v2019Release.3006.FULL.FIN.WIN64.DevKitAPI.tar.gz 369832331047fbf9a2976cb2ce7df759
# 200619.v2020Release.3009.FULL.FIN.WIN64.DevKitAPI.tar.gz 6cd749c0292d37bd6025200dfdcf3efb
# GRAPHISOFT ARCHICAD API DevKit 23.3006.dmg 2b55eea58387a29af4f14551796c9d34
# GRAPHISOFT ARCHICAD API DevKit 24.3009.dmg da11013aa347f56813509e044168eb11

#SHA-256 hashes:
# 210519.v2021Release.3002.FULL.FIN.WIN64.DevKitAPI.tar.gz E2366A58EE2A29AA41C3E28AB7E9C3CAAC83ECC93E25FFD4D62708134764CC42
# 220529.v2022Release.3000.FULL.FIN.WIN64.DevKitAPI.tar.gz F722C5B76ABD0B611FA77F6E8E383997EEEA4D7F50718A53BFED8724ACA7C716
# 210709.v2021Release.3006.FULL.FIN.MAC64.DevKitAPI.tar 3223DD5D2F713BCB5937B84049C28ABF1F482512EA1D55B83DE049A6E3BA90A6
# 220529.v2022Release.3000.FULL.FIN.MAC64.DevKitAPI.tar.gz 1A2299982C90433F99E5C2228692058BF22928A7F5FC1784C4592F2FE11DB9A1

from conans import ConanFile, CMake, tools

class ArchicadAdkConan(ConanFile):
    name = "archicad_adk"
    license = "non-free"
    homepage = "https://archicadapi.graphisoft.com/downloads/api-development-kit"
    url = "https://app.asana.com/0/1199938359399354/board"  # for issues
    description = """With the help of this tool you can develop Add-Ons to extend Archicad’s
       standard functionalities. Also this tool enables you to create I/O interfaces for
       converting Archicad files to different formats."""
    topics = ("CAD", "sdk", "plugin", "addon")
    settings = "os", "arch"

    def package(self):
        src_pattern = "{}/"
        if "Macos" == self.settings.os:
            src_pattern = "/Applications/GRAPHISOFT ARCHICAD API DevKit {}/Support/"
        elif "Windows" == self.settings.os:
            src_pattern = "C:/Program Files/GRAPHISOFT/API Development Kit {}/Support/"
        src = src_pattern.format(self.version)

        self.output.warn(src)
        self.output.warn("current wd : " + os.getcwd())

        self.copy("license.txt")
        self.copy("**/ResConv.exe", src=src, dst="bin", keep_path=False)
        self.copy("**/ResConv", src=src, dst="bin", keep_path=False)
        self.copy("*.lib", src=src, dst="lib", keep_path=False)
        self.copy("*.dll", src=src, dst="bin", keep_path=False)
        self.copy("*.so", src=src, dst="lib", keep_path=False)
        if not self.copy("Frameworks/*.dylib", src=src, dst="bin/Support", keep_path=False):
            self.copy("Tools/*.dylib", src=src, dst="bin/Support", keep_path=False)
        self.copy("*.a", src=src, dst="lib", keep_path=False)
        self.copy("Frameworks/*.framework/*", src=src, dst="lib", symlinks=True)

        include_archicad = "include/Archicad"  # for SonarCloud
        # main headers
        self.copy("*.h", src=src + "Inc", dst=include_archicad)
        self.copy("*.hpp", src=src + "Inc", dst=include_archicad)
        self.copy("*.ico", src=src + "Inc", dst=include_archicad)
        self.copy("*.icns", src=src + "Inc", dst=include_archicad)

        # module headers
        self.copy("*.h", src=src + "Modules", dst=include_archicad)
        self.copy("*.hpp", src=src + "Modules", dst=include_archicad)
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: manuelpagliuca
issue_15677: state: open
title: [question] How to make sure my global custom generator is called last ?
body: ### What is your question?

Hi,

The order in which generators are called seems to vary, which is problematic for my use case. I have a custom generator, NoCMakeUserPresets, intended to execute after all other generators.

This generator's purpose is to remove the CMakeUserPresets.json file created by the CMakeToolchain of my project conanfile, if it exists. Here's the generator's code for reference:

```python
from conan import ConanFile
from conan.tools.files import rm

class NoCMakeUserPresets:
    def __init__(self, conanfile: ConanFile):
        self._conanfile = conanfile

    def generate(self):
        cf = self._conanfile
        rm(cf, "CMakeUserPresets.json", cf.source_folder)
```

I use this generator in my projects with the command `conan install . -g NoCMakeUserPresets` to prevent IDEs like VSCode from prioritizing CMakeUserPresets.json as a settings provider, which is not always desired.

The inconsistency occurs in the execution order of this generator. Sometimes NoCMakeUserPresets is called first, and other times last. This was unexpected, as I assumed that generators specified in the command line would execute after those defined in my project's conanfile.py.

I would appreciate any guidance or resolution for ensuring a consistent execution order for generators.

Thanks!

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: todorico
issue_15676: state: open
title: How can I learn what's missing / wrong for this missing package (Possible defect with 'conan cache save|restore')
body: ### What is your question?

# How can I learn what's missing / wrong for this missing package

I created a `tool_requires` package that is os, compiler, build_type and arch
agnostic. It is a "copy" of all the Windows `.bat` and Linux `.sh` scripts that are
used in our build environment.

The basics for this `tool_requires` package is

```python
class SvBuildToolsRecipe(ConanFile):
    name = "sv_build_tools"
    package_type = "application"

    repo_dir = "BuildTools"

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    python_requires = "stvn_recipes/[>=0.0]"


    def package_id(self):
        del self.info.settings.os
        del self.info.settings.compiler
        del self.info.settings.build_type
        del self.info.settings.arch
```

Documentation indicated that deleting the settings values basically make this a
"clean" `package_id`.

<br>

I created this package on a Windows machine with `eol` set to `lf`.

I exported the package using `conan cache save sv_build_tools`.

I copied the tarball to a Linux Ubuntu 20 machine.

I imported the cache into the local cache using `conan cache restore <tarball>`, and observed that the package is now in my local cache.

However, if I try to _**use**_ the package it fails with the message shown below

```bash
======== Computing dependency graph ========
Graph root
    conanfile.py (zlib/1.2.5): /home/stratarocha/Desktop/TEST-CONAN-PY-REQUIRES/ZLIB/conanfile.py
Build requirements
    sv_build_tools/1.0#e88720518e44ce08bd851c9e74297e7f - Cache
Python requires
    stvn_recipes/1.0#8f709de1bcde37e0554f926191a4bdac - Cache
Resolved version ranges
    stvn_recipes/[>=0.0]: stvn_recipes/1.0
    sv_build_tools/[>=0.0]: sv_build_tools/1.0

======== Computing necessary packages ========
sv_build_tools/1.0: Compatible package ID 67a29b67316ef7c34b92640b41a667c370fb9dd2 equal to the default package ID: Skipping it.
Build requirements
    sv_build_tools/1.0#e88720518e44ce08bd851c9e74297e7f:67a29b67316ef7c34b92640b41a667c370fb9dd2 - Missing

======== Installing packages ========
ERROR: Missing binary: sv_build_tools/1.0:67a29b67316ef7c34b92640b41a667c370fb9dd2

sv_build_tools/1.0: WARN: Can't find a 'sv_build_tools/1.0' package binary '67a29b67316ef7c34b92640b41a667c370fb9dd2' for the configuration:
[python_requires]
stvn_recipes/1.0.Z

ERROR: Missing prebuilt package for 'sv_build_tools/1.0'. You can try:
    - List all available packages using 'conan list sv_build_tools/1.0:* -r=remote'
    - Explain missing binaries: replace 'conan install ...' with 'conan graph explain ...'
    - Try to build locally from sources using the '--build=sv_build_tools/1.0' argument

More Info at 'https://docs.conan.io/2/knowledge/faq.html#error-missing-prebuilt-package'
```

I read the specified web page but it doesn't help me.

The output from the `conan graph explain` follows

```bash

======== Computing dependency graph ========
Graph root
    conanfile.py (zlib/1.2.5): /home/stratarocha/Desktop/TEST-CONAN-PY-REQUIRES/ZLIB/conanfile.py
Build requirements
    sv_build_tools/1.0#e88720518e44ce08bd851c9e74297e7f - Cache
Python requires
    stvn_recipes/1.0#8f709de1bcde37e0554f926191a4bdac - Cache
Resolved version ranges
    stvn_recipes/[>=0.0]: stvn_recipes/1.0
    sv_build_tools/[>=0.0]: sv_build_tools/1.0

======== Computing necessary packages ========
sv_build_tools/1.0: Compatible package ID 67a29b67316ef7c34b92640b41a667c370fb9dd2 equal to the default package ID: Skipping it.
Build requirements
    sv_build_tools/1.0#e88720518e44ce08bd851c9e74297e7f:67a29b67316ef7c34b92640b41a667c370fb9dd2 - Missing

======== Retrieving and computing closest binaries ========
Missing binary: sv_build_tools/1.0
With conaninfo.txt (package_id):
[python_requires]
stvn_recipes/1.0.Z

Finding binaries in the cache
Finding binaries in remote conancenter

======== Closest binaries ========
sv_build_tools/1.0
  sv_build_tools/1.0#e88720518e44ce08bd851c9e74297e7f%1707953883.7342465 (2024-02-14 23:38:03 UTC)
```


From the above output I see:

```bash
# It is looking for this
Build requirements
    sv_build_tools/1.0#e88720518e44ce08bd851c9e74297e7f:67a29b67316ef7c34b92640b41a667c370fb9dd2 - Missing

# but it finds this
sv_build_tools/1.0
  sv_build_tools/1.0#e88720518e44ce08bd851c9e74297e7f%1707953883.7342465 (2024-02-14 23:38:03 UTC)
```

The first part of the hash match but one switches to colon (:) and the other to percent (%).

What can I check for this next?

I do not have the option of building this package locally on the Linux system at this time. I'd like to learn more about this lookup up mechanism and what's causing this confusion/breakage.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: RochaStratovan
issue_15674: state: open
title: Skip adding default remotes if CONAN_NO_DEFAULT_REMOTES is set to True/1
body: Changelog: Feature
Docs: https://github.com/conan-io/docs/pull/3583

If you mostly use Conan to build locally, using conanfiles you're handling (and exporting) yourself, and don't necessary set up a remote, there is no point in adding conancenter as a remote, and having Conan querying it for those.
user: DailyMats
issue_15672: state: open
title: [feature] Have `trim_conandata` not throw when there's no `conandata.yml`
body: ### What is your suggestion?

`trim_conandata` can be used inside a `post_export` hook instead of the `export()` method in recipes, but then we have no control over wether a recipe has an associated `conandata.yml`.

The fix is easy, just `try: ... catch:` it, but feels a bit dirty.
Ideally that could be skipped, but it's true that when used in the `export` method, it might be desirable to have it raise, so we need to give it a thought

Reproducing this is easy: Have a simple recipe without a `conandata.yml` and a `post_export` hook that simply calls `trim_conandata`. That is, this test should pass, which currently does not:

```py
def test_trim_conandata_as_hook_without_conandata():
    c = TestClient()
    c.save_home({"extensions/hooks/hook_trim.py": textwrap.dedent("""
    from conan.tools.files import trim_conandata

    def post_export(conanfile):
        trim_conandata(conanfile)
    """)})

    c.save({"conanfile.py": GenConanfile("pkg")})
    c.run("export . --version=1.0")
    assert c.exported_recipe_revision() == "a9ec2e5fbb166568d4670a9cd1ef4b26"
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: RubenRBS
issue_15670: state: open
title: [question] conan2: How to make path to test shorter?
body: ### What is your question?

Hi, I have problem with conan2.
Path to folder with test_package/conanfile.py is 126 symbols and MSVC compiler can't work with long pathes on Windows yet even with enabled option. Is there some option that will tell conan2 (create/test) to use some other directory for tests? Conan1 had "--test-build-folder" but I don't see it in conan2.

```
FileTracker : error FTK1011: could not create the new file tracking log file: <longpath>\test_package\build\msvc-192-x86_64-17-release\CMakeFiles\CMakeScratch\TryCompile-kf0gqn\cmTC_8460c.dir\Debug\cmTC_8460c.tlog\link.50124-rc.read.1.tlog. The system cannot find the path specified. [<longpath>\test_package\build\msvc-192-x86_64-17-release\CMakeFiles\CMakeScratch\TryCompile-kf0gqn\cmTC_8460c.vcxproj] [....vcxproj]
 ```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Nekto89
issue_15668: state: open
title: Is there a way to fetch package info for the whole conan repository in a single request?
body: ### What is your question?

Hi, we are developing a GUI client to list and install Conan packages. The user should be able to identify each package's type quickly. The package type is determined by the set of "topics" declared in the conan file (conanfile.py). The only way we can fetch the package's topics in Conan2 is by running `conan graph info` on each one of the packages.  This operation may drag the performance of the entire UI down, depending on each package's dependency tree depth. 

We´ve considered a separate working thread that pulls the graph info of each one of the packages of the repository in order to cache them in memory, but I am afraid that the whole idea can take a severe bite on the memory usage and it may be quite slow. 

My question is: is there any way to fetch the information we need for all packages in a repository in a single request?, if there is not such a feature, does it sounds reasonable to implement it?

Thank you very much.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: malonsorightware
issue_15666: state: open
title: [bug] self.info.settings not available in source()
body: ### Environment details

* Operating System+version: Linux Ubuntu
* Compiler+version: gcc11
* Conan version: 2.0.17
* Python version: 3.8.10


### Steps to reproduce

I'm working on a recipe that has a large source download.
The source retrieved depends on the OS.  I know it isn't recommended to switch at source(), but at least during the development phase, I want to switch.

in source() I write `if self.info.settings.os == "MacOS"`,
this works when using `conan create`,
but if I do `conan install .` and `conan source .` it will fail (self.info is set to None)

There are docs that mention `platform.system()`, and that would probably work as long as there is no cross-compiling (that isn't desired for me), so is that the correct approach?

Note that I also need self.info.settings.arch

And, self.info.settings.compiler as it changes some parts of the environment during the source-fetch.
I saw it is instead recommended to fetch the source during build(), which makes sense as the compiler may change.

However, this is for the v8 (javascript engine) recipe, which has a complex way of retrieving the sources.  It takes quite some time to retrieve the source, so it is desirable to do it this other way (for now).

So the chief question is, why I can build with conan-create but I can't use the conan-install + conan-source workflow. Which seems wrong/inconsistent.


### Logs

_No response_
user: paulharris
issue_15663: state: open
title: [question] Mixed profile dependency graph
body: ### What is your question?

Hello!

I am using Conan 1.62.0 and I have a question about the following dependency graph:

![conan_deps](https://github.com/conan-io/conan/assets/25209036/450fe2c4-055a-4b0a-97fd-9db1abf61c2d)

In this graph each box represents a conan repo which generates a package. Each repo has a list of dependencies, such that `xA` depends on `xB`, etc. In this graph there are two profiles, profile `x` which builds for architecture `x`, and profile `y` which builds for architecture `y`. Some repos only build for profile `x` and some only build for profile `y` and one builds for both. 

The difficulty I'm having is that `xB` depends on `yB`. It just wants to get the latest binary package from `yB`. I've been able to do this by doing `self.info.clear()` in the `package_id` function of `yB`. 

However `yA` also depends on `yB`. If `xyA` or `yC` change, I'd like `yA` to know that it must rebuild `yB`. But since the `requires` has been cleared from `yB` in the `package_id` it doesn't know that it must be rebuilt.

How can I set this up such that `xB` is able to grab the binary package from `yB` while also preserving the `requires` info for `yA`?

The only approach I can think of is that `yB` must generate two packages, one with the `requires` info for `yA` and one without for `xB`.

Let me know if there are any better approaches!

Thanks you!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Andre-Heil-Bose
issue_15662: state: open
title: [bug] Can't set GLOBAL visibility for imported targets 
body: ### Environment details

* Operating System+version:
* Compiler+version:
* Conan version: 2.0.17
* Python version:


### Steps to reproduce

1. Make a simple CMake project with one subdirectory (two CMakeLists.txt files).
2. The outer one should do `add_subdirectory()` on the lower one.
3. Do `find_package(<package_name> GLOBAL)` in the inner CMake file
4. Try to use the imported target in the outer CMake file

_At least CMake 3.24 is needed. More details in https://cmake.org/cmake/help/latest/command/find_package.html#basic-signature._

### Logs

_No response_
user: mpusz
issue_15658: state: open
title: [github bug templates] Extra step in bug template report
body: Changelog: omit
Docs: omit
user: franramirez688
issue_15657: state: open
title: [question] conan2: unnecessary build requirements
body: ### What is your question?

Hi! I'm generating conanfile.py from CMake in the form of:

```
from conan import ConanFile
from conan.tools.files import copy

class MyApp(ConanFile):
    name = "app"
    version = "1.0"
    settings = "os", "arch", "compiler", "build_type"

    def requirements(self):
        self.requires("otherpackage1/1.0.0@user/channel#4268a55b9703444e15b9181c6ddaad21", force=True)
        self.requires("otherpackage2/1.0.0@user/channel#53da7d5ae28714ca964ce485e280e1ff", force=True)
        self.requires("otherpackageN/1.0.0@user/channel#9bae105f97adc3e4b0db9d8c6ad965b8", force=True)

    def generate(self):
        for dep in self.dependencies.values():
            if len(dep.cpp_info.bindirs):
                copy(self, "*.dll", dep.cpp_info.bindirs[0], r"C:/app/build_folder/Binaries/Debug")
            if len(dep.cpp_info.libdirs):
                copy(self, "*.dylib*", dep.cpp_info.libdirs[0], r"C:/app/build_folder/Binaries/Debug")
                copy(self, "*.so*", dep.cpp_info.libdirs[0], r"C:/app/build_folder/Binaries/Debug")
```

I've noticed that conan2 installs build requirements even when already built package has been downloaded from remote or is already present in local cache. Is there a way to not download build requirements in this case? I think that conan 1.X didn't have this behavior.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Nekto89
issue_15655: state: open
title: [question] How to cross-build from Linux to Windows using clang?
body: ### What is your question?

Hello,

I would like to create CI jobs that run exclusively on linux runners. Since people in my company use Visual Studio extensively, I have to make my jobs able to create a 1:1 executable that the developers would get when compiling locally on their Windows machines.

I decided to go for clang for that purpose. I had to exclude any mingw-related compilers since (from what I understood), it would only target  x86_64-pc-windows-gnu, while I need to target  x86_64-pc-windows-msvc.

To test just that, I installed the Windows SDK 10.0.22621 on a docker container and created the following test.cpp:
```cpp
#include <iostream>

int main()
{
        std::cout << "Hello World!" << std::endl;
        return 0;
}
```
And indeed, running this command `clang++-16 -v -fcolor-diagnostics -target x86_64-pc-windows-msvc -L/opt/win-sdk/10.0.22621/crt/lib/x86_64 -L/opt/win-sdk/10.0.22621/sdk/lib/ucrt/x86_64 -L/opt/win-sdk/10.0.22621/sdk/lib/um/x86_64 -I/opt/win-sdk/10.0.22621/crt/include -I/opt/win-sdk/10.0.22621/sdk/include/cppwinrt/ -I/opt/win-sdk/10.0.22621/sdk/include/shared/ -I/opt/win-sdk/10.0.22621/sdk/include/ucrt/ -I/opt/win-sdk/10.0.22621/sdk/include/um/ -I/opt/win-sdk/10.0.22621/sdk/include/winrt/ -flto -march=x86-64-v3 -fuse-ld=lld test.cpp` generates the following output and properly creates the executable:



<details>
  <summary>Log</summary>

```bash
clang++-16 -v -fcolor-diagnostics -target x86_64-pc-windows-msvc -L/opt/win-sdk/10.0.22621/crt/lib/x86_64 -L/opt/win-sdk/10.0.22621/sdk/lib/ucrt/x86_64 -L/opt/win-sdk/10.0.22621/sdk/lib/um/x86_64 -I/opt/win-sdk/10.0.22621/crt/include -I/opt/win-sdk/10.0.22621/sdk/include/cppwinrt/ -I/opt/win-sdk/10.0.22621/sdk/include/shared/ -I/opt/win-sdk/10.0.22621/sdk/include/ucrt/ -I/opt/win-sdk/10.0.22621/sdk/include/um/ -I/opt/win-sdk/10.0.22621/sdk/include/winrt/ -flto -march=x86-64-v3 -fuse-ld=lld test.cpp
Debian clang version 16.0.6 (15~deb12u1)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: /usr/bin
 "/usr/lib/llvm-16/bin/clang" -cc1 -triple x86_64-pc-windows-msvc19.20.0 -emit-llvm-bc -flto=full -flto-unit -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64-v3 -mllvm -treat-scalable-fixed-error-as-warning -v -fcoverage-compilation-dir=/workspace -resource-dir /usr/lib/llvm-16/lib/clang/16 -I /opt/win-sdk/10.0.22621/crt/include -I /opt/win-sdk/10.0.22621/sdk/include/cppwinrt/ -I /opt/win-sdk/10.0.22621/sdk/include/shared/ -I /opt/win-sdk/10.0.22621/sdk/include/ucrt/ -I /opt/win-sdk/10.0.22621/sdk/include/um/ -I /opt/win-sdk/10.0.22621/sdk/include/winrt/ -internal-isystem /usr/lib/llvm-16/lib/clang/16/include -fdeprecated-macro -fdebug-compilation-dir=/workspace -ferror-limit 19 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.20 -std=c++14 -fdelayed-template-parsing -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -o /tmp/test-ad3003.o -x c++ test.cpp
clang -cc1 version 16.0.6 based upon LLVM 16.0.6 default target x86_64-pc-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /opt/win-sdk/10.0.22621/crt/include
 /opt/win-sdk/10.0.22621/sdk/include/cppwinrt
 /opt/win-sdk/10.0.22621/sdk/include/shared
 /opt/win-sdk/10.0.22621/sdk/include/ucrt
 /opt/win-sdk/10.0.22621/sdk/include/um
 /opt/win-sdk/10.0.22621/sdk/include/winrt
 /usr/lib/llvm-16/lib/clang/16/include
End of search list.
In file included from test.cpp:1:
In file included from /opt/win-sdk/10.0.22621/crt/include/iostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/istream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ios:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xlocnum:12:
In file included from /opt/win-sdk/10.0.22621/crt/include/cstdio:11:
In file included from /opt/win-sdk/10.0.22621/sdk/include/ucrt/stdio.h:12:
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt_wstdio.h:1486:1: warning: attribute declaration must precede definition [-Wignored-attributes]
__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_2_ARGLIST_EX(
^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt.h:1788:13: note: expanded from macro '__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_2_ARGLIST_EX'
            _CRT_INSECURE_DEPRECATE(_FuncName##_s) _DeclSpec _ReturnType _CC _FuncName(_SalAttributeDst _DstType *_Dst, _TType1 _TArg1, _TType2 _TArg2, ...); \
            ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:355:55: note: expanded from macro '_CRT_INSECURE_DEPRECATE'
        #define _CRT_INSECURE_DEPRECATE(_Replacement) _CRT_DEPRECATE_TEXT(    \
                                                      ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:345:47: note: expanded from macro '_CRT_DEPRECATE_TEXT'
#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
                                              ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt_wstdio.h:1403:33: note: previous definition is here
_CRT_STDIO_INLINE int __CRTDECL __swprintf_l(
                                ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt_wstdio.h:1486:1: warning: attribute declaration must precede definition [-Wignored-attributes]
__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_2_ARGLIST_EX(
^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt.h:1789:13: note: expanded from macro '__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_2_ARGLIST_EX'
            _CRT_INSECURE_DEPRECATE(_SecureVFuncName) _DeclSpec _ReturnType _CC _VFuncName(_SalAttributeDst _DstType *_Dst, _TType1 _TArg1, _TType2 _TArg2, va_list _Args);
            ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:355:55: note: expanded from macro '_CRT_INSECURE_DEPRECATE'
        #define _CRT_INSECURE_DEPRECATE(_Replacement) _CRT_DEPRECATE_TEXT(    \
                                                      ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:345:47: note: expanded from macro '_CRT_DEPRECATE_TEXT'
#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
                                              ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt_wstdio.h:1205:33: note: previous definition is here
_CRT_STDIO_INLINE int __CRTDECL __vswprintf_l(
                                ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt_wstdio.h:1495:1: warning: attribute declaration must precede definition [-Wignored-attributes]
__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1_ARGLIST_EX(
^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt.h:1784:13: note: expanded from macro '__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1_ARGLIST_EX'
            _CRT_INSECURE_DEPRECATE(_SecureFuncName) _DeclSpec _ReturnType _CC _FuncName(_SalAttributeDst _DstType *_Dst, _TType1 _TArg1, ...); \
            ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:355:55: note: expanded from macro '_CRT_INSECURE_DEPRECATE'
        #define _CRT_INSECURE_DEPRECATE(_Replacement) _CRT_DEPRECATE_TEXT(    \
                                                      ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:345:47: note: expanded from macro '_CRT_DEPRECATE_TEXT'
#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
                                              ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt_wstdio.h:1444:33: note: previous definition is here
_CRT_STDIO_INLINE int __CRTDECL _swprintf(
                                ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt_wstdio.h:1495:1: warning: attribute declaration must precede definition [-Wignored-attributes]
__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1_ARGLIST_EX(
^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt.h:1785:13: note: expanded from macro '__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1_ARGLIST_EX'
            _CRT_INSECURE_DEPRECATE(_SecureVFuncName) _DeclSpec _ReturnType _CC _VFuncName(_SalAttributeDst _DstType *_Dst, _TType1 _TArg1, va_list _Args);
            ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:355:55: note: expanded from macro '_CRT_INSECURE_DEPRECATE'
        #define _CRT_INSECURE_DEPRECATE(_Replacement) _CRT_DEPRECATE_TEXT(    \
                                                      ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:345:47: note: expanded from macro '_CRT_DEPRECATE_TEXT'
#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
                                              ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt_wstdio.h:1221:33: note: previous definition is here
_CRT_STDIO_INLINE int __CRTDECL _vswprintf(
                                ^
In file included from test.cpp:1:
In file included from /opt/win-sdk/10.0.22621/crt/include/iostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/istream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ios:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xlocnum:12:
In file included from /opt/win-sdk/10.0.22621/crt/include/cstdio:11:
/opt/win-sdk/10.0.22621/sdk/include/ucrt/stdio.h:1793:1: warning: attribute declaration must precede definition [-Wignored-attributes]
__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1_ARGLIST(
^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt.h:703:5: note: expanded from macro '__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1_ARGLIST'
    __DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1_ARGLIST_EX(_ReturnType, _ReturnPolicy, _DeclSpec, _CC, _FuncName, _FuncName##_s, _VFuncName, _VFuncName##_s, _SalAttributeDst, _DstType, _Dst, _TType1, _TArg1)
    ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt.h:1784:13: note: expanded from macro '__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1_ARGLIST_EX'
            _CRT_INSECURE_DEPRECATE(_SecureFuncName) _DeclSpec _ReturnType _CC _FuncName(_SalAttributeDst _DstType *_Dst, _TType1 _TArg1, ...); \
            ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:355:55: note: expanded from macro '_CRT_INSECURE_DEPRECATE'
        #define _CRT_INSECURE_DEPRECATE(_Replacement) _CRT_DEPRECATE_TEXT(    \
                                                      ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:345:47: note: expanded from macro '_CRT_DEPRECATE_TEXT'
#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
                                              ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/stdio.h:1769:33: note: previous definition is here
_CRT_STDIO_INLINE int __CRTDECL sprintf(
                                ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/stdio.h:1971:1: warning: attribute declaration must precede definition [-Wignored-attributes]
__DEFINE_CPP_OVERLOAD_STANDARD_NFUNC_0_2_ARGLIST_EX(
^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt.h:1830:13: note: expanded from macro '__DEFINE_CPP_OVERLOAD_STANDARD_NFUNC_0_2_ARGLIST_EX'
            _CRT_INSECURE_DEPRECATE(_FuncName##_s) _DeclSpec _ReturnType _CC _FuncName(_SalAttributeDst _DstType *_Dst, _TType1 _TArg1, _TType2 _TArg2, ...); \
            ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:355:55: note: expanded from macro '_CRT_INSECURE_DEPRECATE'
        #define _CRT_INSECURE_DEPRECATE(_Replacement) _CRT_DEPRECATE_TEXT(    \
                                                      ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:345:47: note: expanded from macro '_CRT_DEPRECATE_TEXT'
#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
                                              ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/stdio.h:1952:33: note: previous definition is here
_CRT_STDIO_INLINE int __CRTDECL _snprintf(
                                ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/stdio.h:1971:1: warning: attribute declaration must precede definition [-Wignored-attributes]
__DEFINE_CPP_OVERLOAD_STANDARD_NFUNC_0_2_ARGLIST_EX(
^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/corecrt.h:1831:13: note: expanded from macro '__DEFINE_CPP_OVERLOAD_STANDARD_NFUNC_0_2_ARGLIST_EX'
            _CRT_INSECURE_DEPRECATE(_VFuncName##_s) _DeclSpec _ReturnType _CC _VFuncName(_SalAttributeDst _DstType *_Dst, _TType1 _TArg1, _TType2 _TArg2, va_list _Args);
            ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:355:55: note: expanded from macro '_CRT_INSECURE_DEPRECATE'
        #define _CRT_INSECURE_DEPRECATE(_Replacement) _CRT_DEPRECATE_TEXT(    \
                                                      ^
/opt/win-sdk/10.0.22621/crt/include/vcruntime.h:345:47: note: expanded from macro '_CRT_DEPRECATE_TEXT'
#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))
                                              ^
/opt/win-sdk/10.0.22621/sdk/include/ucrt/stdio.h:1396:33: note: previous definition is here
_CRT_STDIO_INLINE int __CRTDECL _vsnprintf(
                                ^
In file included from test.cpp:1:
In file included from /opt/win-sdk/10.0.22621/crt/include/iostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/istream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ios:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xlocnum:15:
In file included from /opt/win-sdk/10.0.22621/crt/include/streambuf:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xiosbase:11:
In file included from /opt/win-sdk/10.0.22621/crt/include/system_error:13:
In file included from /opt/win-sdk/10.0.22621/crt/include/stdexcept:11:
In file included from /opt/win-sdk/10.0.22621/crt/include/xstring:14:
In file included from /opt/win-sdk/10.0.22621/crt/include/xmemory:12:
In file included from /opt/win-sdk/10.0.22621/crt/include/limits:15:
In file included from /opt/win-sdk/10.0.22621/crt/include/intrin.h:35:
In file included from /opt/win-sdk/10.0.22621/crt/include/immintrin.h:30:
In file included from /opt/win-sdk/10.0.22621/crt/include/wmmintrin.h:31:
In file included from /opt/win-sdk/10.0.22621/crt/include/nmmintrin.h:32:
In file included from /opt/win-sdk/10.0.22621/crt/include/smmintrin.h:32:
In file included from /opt/win-sdk/10.0.22621/crt/include/tmmintrin.h:25:
In file included from /opt/win-sdk/10.0.22621/crt/include/pmmintrin.h:34:
In file included from /opt/win-sdk/10.0.22621/crt/include/emmintrin.h:38:
In file included from /opt/win-sdk/10.0.22621/crt/include/xmmintrin.h:46:
/opt/win-sdk/10.0.22621/crt/include/mmintrin.h:34:26: warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes]
typedef union __declspec(intrin_type) __declspec(align(8)) __m64
                         ^~~~~~~~~~~
In file included from test.cpp:1:
In file included from /opt/win-sdk/10.0.22621/crt/include/iostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/istream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ios:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xlocnum:15:
In file included from /opt/win-sdk/10.0.22621/crt/include/streambuf:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xiosbase:11:
In file included from /opt/win-sdk/10.0.22621/crt/include/system_error:13:
In file included from /opt/win-sdk/10.0.22621/crt/include/stdexcept:11:
In file included from /opt/win-sdk/10.0.22621/crt/include/xstring:14:
In file included from /opt/win-sdk/10.0.22621/crt/include/xmemory:12:
In file included from /opt/win-sdk/10.0.22621/crt/include/limits:15:
In file included from /opt/win-sdk/10.0.22621/crt/include/intrin.h:35:
In file included from /opt/win-sdk/10.0.22621/crt/include/immintrin.h:30:
In file included from /opt/win-sdk/10.0.22621/crt/include/wmmintrin.h:31:
In file included from /opt/win-sdk/10.0.22621/crt/include/nmmintrin.h:32:
In file included from /opt/win-sdk/10.0.22621/crt/include/smmintrin.h:32:
In file included from /opt/win-sdk/10.0.22621/crt/include/tmmintrin.h:25:
In file included from /opt/win-sdk/10.0.22621/crt/include/pmmintrin.h:34:
In file included from /opt/win-sdk/10.0.22621/crt/include/emmintrin.h:38:
/opt/win-sdk/10.0.22621/crt/include/xmmintrin.h:65:26: warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes]
typedef union __declspec(intrin_type) __declspec(align(16)) __m128 {
                         ^~~~~~~~~~~
In file included from test.cpp:1:
In file included from /opt/win-sdk/10.0.22621/crt/include/iostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/istream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ios:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xlocnum:15:
In file included from /opt/win-sdk/10.0.22621/crt/include/streambuf:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xiosbase:11:
In file included from /opt/win-sdk/10.0.22621/crt/include/system_error:13:
In file included from /opt/win-sdk/10.0.22621/crt/include/stdexcept:11:
In file included from /opt/win-sdk/10.0.22621/crt/include/xstring:14:
In file included from /opt/win-sdk/10.0.22621/crt/include/xmemory:12:
In file included from /opt/win-sdk/10.0.22621/crt/include/limits:15:
In file included from /opt/win-sdk/10.0.22621/crt/include/intrin.h:35:
In file included from /opt/win-sdk/10.0.22621/crt/include/immintrin.h:30:
In file included from /opt/win-sdk/10.0.22621/crt/include/wmmintrin.h:31:
In file included from /opt/win-sdk/10.0.22621/crt/include/nmmintrin.h:32:
In file included from /opt/win-sdk/10.0.22621/crt/include/smmintrin.h:32:
In file included from /opt/win-sdk/10.0.22621/crt/include/tmmintrin.h:25:
In file included from /opt/win-sdk/10.0.22621/crt/include/pmmintrin.h:34:
/opt/win-sdk/10.0.22621/crt/include/emmintrin.h:40:26: warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes]
typedef union __declspec(intrin_type) __declspec(align(16)) __m128i {
                         ^~~~~~~~~~~
/opt/win-sdk/10.0.22621/crt/include/emmintrin.h:51:27: warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes]
typedef struct __declspec(intrin_type) __declspec(align(16)) __m128d {
                          ^~~~~~~~~~~
In file included from test.cpp:1:
In file included from /opt/win-sdk/10.0.22621/crt/include/iostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/istream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ios:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xlocnum:15:
In file included from /opt/win-sdk/10.0.22621/crt/include/streambuf:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xiosbase:11:
In file included from /opt/win-sdk/10.0.22621/crt/include/system_error:13:
In file included from /opt/win-sdk/10.0.22621/crt/include/stdexcept:11:
In file included from /opt/win-sdk/10.0.22621/crt/include/xstring:14:
In file included from /opt/win-sdk/10.0.22621/crt/include/xmemory:12:
In file included from /opt/win-sdk/10.0.22621/crt/include/limits:15:
In file included from /opt/win-sdk/10.0.22621/crt/include/intrin.h:35:
/opt/win-sdk/10.0.22621/crt/include/immintrin.h:39:26: warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes]
typedef union __declspec(intrin_type) __declspec(align(32)) __m256 {
                         ^~~~~~~~~~~
/opt/win-sdk/10.0.22621/crt/include/immintrin.h:43:27: warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes]
typedef struct __declspec(intrin_type) __declspec(align(32)) __m256d {
                          ^~~~~~~~~~~
/opt/win-sdk/10.0.22621/crt/include/immintrin.h:47:27: warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes]
typedef union  __declspec(intrin_type) __declspec(align(32)) __m256i {
                          ^~~~~~~~~~~
In file included from test.cpp:1:
In file included from /opt/win-sdk/10.0.22621/crt/include/iostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/istream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ostream:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/ios:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xlocnum:15:
In file included from /opt/win-sdk/10.0.22621/crt/include/streambuf:10:
In file included from /opt/win-sdk/10.0.22621/crt/include/xiosbase:11:
In file included from /opt/win-sdk/10.0.22621/crt/include/system_error:13:
In file included from /opt/win-sdk/10.0.22621/crt/include/stdexcept:11:
In file included from /opt/win-sdk/10.0.22621/crt/include/xstring:14:
In file included from /opt/win-sdk/10.0.22621/crt/include/xmemory:12:
In file included from /opt/win-sdk/10.0.22621/crt/include/limits:15:
In file included from /opt/win-sdk/10.0.22621/crt/include/intrin.h:35:
In file included from /opt/win-sdk/10.0.22621/crt/include/immintrin.h:2467:
/opt/win-sdk/10.0.22621/crt/include/zmmintrin.h:47:26: warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes]
typedef union __declspec(intrin_type) __declspec(align(64)) __m512 {
                         ^~~~~~~~~~~
/opt/win-sdk/10.0.22621/crt/include/zmmintrin.h:51:27: warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes]
typedef struct __declspec(intrin_type) __declspec(align(64)) __m512d {
                          ^~~~~~~~~~~
/opt/win-sdk/10.0.22621/crt/include/zmmintrin.h:55:27: warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes]
typedef union  __declspec(intrin_type) __declspec(align(64)) __m512i {
                          ^~~~~~~~~~~
17 warnings generated.
 "/usr/lib/llvm-16/bin/lld-link" -out:a.exe -defaultlib:libcmt -defaultlib:oldnames -libpath:lib/amd64 -libpath:atlmfc/lib/amd64 -libpath:/opt/win-sdk/10.0.22621/crt/lib/x86_64 -libpath:/opt/win-sdk/10.0.22621/sdk/lib/ucrt/x86_64 -libpath:/opt/win-sdk/10.0.22621/sdk/lib/um/x86_64 -nologo /tmp/test-ad3003.o
```
</details>

For some reason, I get a lot more warnings than I do with clang on Windows, but it still compiles. However, I am unable to reproduce the same with conan. There must be a mistake with my profiles. `conan build core -pr windows-x86_64 -pr:b clang-x86_64 --build=missing`  returns:

```bash
======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.runtime_version=v143
compiler.version=16
os=Windows
[conf]
tools.build:compiler_executables={'c': 'clang-16', 'cpp': 'clang++-16'}
tools.build:cxxflags=['-v -fcolor-diagnostics', '-target x86_64-pc-windows-msvc', '-L/opt/win-sdk/10.0.22621/crt/lib/x86_64 -L/opt/win-sdk/10.0.22621/sdk/lib/ucrt/x86_64 -L/opt/win-sdk/10.0.22621/sdk/lib/um/x86_64', '-I/opt/win-sdk/10.0.22621/crt/include -I/opt/win-sdk/10.0.22621/sdk/include/cppwinrt/ -I/opt/win-sdk/10.0.22621/sdk/include/shared/ -I/opt/win-sdk/10.0.22621/sdk/include/ucrt/ -I/opt/win-sdk/10.0.22621/sdk/include/um/ -I/opt/win-sdk/10.0.22621/sdk/include/winrt/', '-flto -march=x86-64-v3']
tools.build:exelinkflags=['-fuse-ld=lld']
tools.build:sharedlinkflags=['-fuse-ld=lld']
tools.cmake.cmaketoolchain:generator=Ninja
tools.microsoft.msbuild:installation_path="/opt/win-sdk/10.0.22621"
tools.microsoft.msbuild:vs_version=17

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=16
os=Linux
[conf]
tools.build:compiler_executables={'c': 'clang-16', 'cpp': 'clang++-16'}
tools.build:exelinkflags=['-fuse-ld=lld']
tools.build:sharedlinkflags=['-fuse-ld=lld']
tools.cmake.cmaketoolchain:generator=Ninja


======== Computing dependency graph ========
Graph root
    conanfile.py (castcore/1.1): /workspace/core/conanfile.py

======== Computing necessary packages ========

======== Installing packages ========

======== Installing packages ========

======== Finalizing install (deploy, generators) ========
conanfile.py (castcore/1.1): Calling generate()
conanfile.py (castcore/1.1): Generators folder: /workspace/core/build/windows-clang-16-x86_64/Release/generators
conanfile.py (castcore/1.1): CMakeToolchain generated: conan_toolchain.cmake
ERROR: conanfile.py (castcore/1.1): Error in generate() method, line 84
        ct.generate()
        ConanException: VS non-existing installation: Visual Studio 17. If using a non-default toolset from a VS IDE version consider specifying it with the 'tools.microsoft.msbuild:vs_version' conf
```

Could you please indicate me what is wrong? Thanks in advance!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Todiq
issue_15653: state: open
title: To check what to do with version build metadata and prereleases
body: Changelog: Bugfix: Fix version precendence for metadata version ranges
Docs: Omit

I suspect more things are still needed

user: RubenRBS
issue_15650: state: open
title: [bug] semver fails to resolve metadata field correctly
body: ### Environment details

* Operating System+version: Ubuntu 22.04
* Compiler+version: N/A
* Conan version: 2.0.17
* Python version: 3.10.8


### Steps to reproduce

1. Have a package with a version number followed by a "metadata (i.e. preceded by +)" field containing a number. For example: ```1.0.0+2```. NOTE: There cannot be a "larger" version available, such as ```1.0.0+3``` if you want to reproduce this.
2. in a conanfile, require ```>=``` this version. For example: ```self.requires("package/[>=1.0.0+2]")```
3. Try to resolve dependencies. Conan will fail with: ```ERROR: Package 'package/[>=1.0.0+2]' not resolved: Version range '>=1.0.0+2' from requirement 'package/[>=1.0.0+2]' [etc, etc...] ```

I can verify that this should not be the case by running:
```
>>> from conans.model.version import Version
>>> Version("1.0.0+2") >= Version("1.0.0+2")
True
>>> Version("1.0.0+2") >= Version("1.0.0+3")
False
```

Note also that if I set the metadata number to one LESS than the exisiting version, it will be able to find it! If I set ```self.requires("package/[>=1.0.0+1]")``` it will be able to find version ```1.0.0+2```.

This seems like a bug to me?

FYI: we use this field to hold  "build number" in case we run another build without changing the version. It increments after each build. It's useful to us to be able to specify that we should not use a build which is older than some build number.

### Logs

_No response_
user: antoinebardoz
issue_15648: state: open
title: [feature] Provide ``is_mingw()`` recipe helper
body: ### What is your suggestion?

From https://github.com/conan-io/conan/pull/12678. 

The idea:

- Provide a basic helper, with return-fast strategy so it is more readable.
- It will need detailed research of non covered cases so far, like ``clang``

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: memsharded
issue_15646: state: open
title: [feature] stdcpp_library when using static-libstdc++
body: ### What is your suggestion?

Use case:
- Recipe for a library that has compiled C++ code, but a pure C interface (that is, can be called by pure C libraries/applications)
- Is a static library 

For cases like this, when linking the application, the linker won't know that the executable needs to load `libstdc++.so` (unless there were other C++ libraries involved, or the C++ compiler was invoked to do the linker). Thus, some recipes have some logic like this:

```
        if not self.options.shared:
            libcxx = stdcpp_library(self)
            if libcxx:
                self.cpp_info.components["xxx"].system_libs.append(libcxx)
```

where `libcxx` is the `stdc++` library. This mirrors what happens outside of the Conan realm, where a `.pc` file for a library like this will have `-lstdc++` as a linking flag. 

However, there are cases in which the user on the consuming side might wish to link the final executable with the _static_ C++ runtime (`-static-libstdc++`). This is valid - so long as the shared variant is not linked as well. For our static library, the _binary_  package is the same: it assumes that the symbols will be satisfied, but it doesn't really mandate that the executable needs to load the C++ runtime as a shared or a static library. It would be a different case if we had a shared library.


In this PR https://github.com/conan-io/conan-center-index/pull/16236 we get an issue where users wishing to link their executables with `-static-libstdc++` have issues because the recipe logic is adding `-lstdc++` to the linking flags, and that takes precedence.

Given that  the `stdcpp_library` helper is described as:
```
def stdcpp_library(conanfile):
    """ Returns the name of the C++ standard library that can be passed
    to the linker, based on the current settings. Returs None if the name 
    of the C++ standard library file is not known.
    """
```

If this function already has that "something that can be passed to the linker" in mind, and all invocations are protected and only apply to static libraries, we may wish to add a conf such that this outputs nothing and let the consumer user handle it. I don't think we can have this output `-static-libstdc++` because that's a flag, not a linking library, and there are more  possibly more libraries that need to be statically linked in order to get a working executable.



### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: jcar87
issue_15640: state: open
title: [bug] Conan 1.59 compilation stage for test_package fails (missing type) whereas it succeeds in conan2
body: ### Environment details

* Operating System+version: Ubuntu 22.04
* Compiler+version: Ubuntu clang version 15.0.7
* Conan version 1.59.0 / 2.0.17
* Python version: Python 3.10.13 ( in both cases)


### Steps to reproduce

I was testing my conanfile.py for upload to conancenter. The library I'm packaging has an include "utility.hpp" which contains the following statement

```
#ifdef __has_include
  #if __has_include(<source_location>)
    #include <source_location>

namespace lf::detail {
using source_location = std::source_location;
}  // namespace lf::detail

```

Now here's the strange thing: When I execute the following using conan2 it works:

`conan create all/conanfile.py -pr:b=cpp20 -pr:h=cpp20`

However, when I use conan 1.5 with the **exact same** command, it can't build the testpackage, complaining that:

/home/<user>/.conan/data/<lib>/2.1.1/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include/<lib>-2.1.1/<lib>/detail/utility.hpp:37:30: error: no type named 'source_location' in namespace 'std'
using source_location = std::source_location;

Rest assured that the cpp20 profile is also the exact same (I copied it):

```
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=20
compiler.libcxx=libc++
compiler.version=15
os=Linux

[conf]
tools.build:compiler_executables={"cpp": "/usr/bin/clang++-15", "c": "/usr/bin/clang-15"}

[buildenv]
CMAKE_EXPORT_COMPILE_COMMANDS=ON
```

so the only difference seems to be the conan version involved. Now why would it compile in conan2 but not in conan 1.5?

### Logs

_No response_
user: MartyMcFlyInTheSky
issue_15639: state: open
title: [feature] `tools.cmake.cmaketoolchain:conan_preset_file`
body: ### What is your suggestion?

As described in https://docs.conan.io/2/examples/tools/cmake/cmake_toolchain/extend_own_cmake_presets.html Conan provides the means to specify a custom presets file name that can be later on included by the custom `CMakeUserPresets.cmake`. This, however, requires having and changing a `conanfile.py` to provide this functionality.

A current behavior has many limitations:
- will not work with `conanfile.txt`
- a need to change the external project's `conanfile.py` to get this behavior
- a need to update several projects in the corporation when we want to achieve the same consistent behavior among projects
- does not allow customizing per specific repository (the same project in different locations may have different use cases and often, the default behavior would work just fine)

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: mpusz
issue_15638: state: open
title: [bug] Conan tilde and caret range expressions don't work correctly with alphanumeric
body: ### Environment details

* Operating System+version: Windows 11 Pro N
* Compiler+version: n/a
* Conan version: 2.0.17
* Python version: 3.12.1


### Steps to reproduce

# Conan tilde and caret range expressions don't work correctly with alphanumeric

[2.0 Documentation Reference for Range expressions](https://docs.conan.io/2/tutorial/versioning/version_ranges.html#range-expressions)

The documentation for the tilde is

> The tilde ~ operator can be used to define an “approximately” equal version range. requires = "pkg/[~1]" will include versions 1.3 and 1.8.1, but will exclude versions like 0.8 or 2.0. Likewise requires = "pkg/[~2.5]" will include 2.5.0 and 2.5.3, but exclude 2.1, 2.7, 2.8.

Which to summarize means `~<value>` locks in <value> and allows variation after
value.

`~1` translates to 1.* allowing 1.1.1, 1,3, etc. Where `1` is the locked value

Likewise, `~2.5` locks in the `2.5` prefix, allowing 2.5.0, 2.5.1, 2.5.1.9.3, etc.

This doesn't seem to work when using alpha-numeric characters. For example if we applied the rules identified above for `~2.2.0.branch-a` then the expectation is `2.2.0.branch-a` is locked in place and we would allow variability after that such as 2.2.0.branch-a.0, 2.2.0.branch-a.1.0, 2.2.0.branch-a.3.4.99, etc.

However, I found that this isn't working, as explained below.

Adjusting the example below for the caret (^) requires fails in the same way.

## Consumer

I've adapted the excellent version examples from the 2.0 Versioning Tutorial, to play with and discover this. My consumer, `lib2` depends upon two other libraries `lib1a` and `lib1`.

**conanfile.py**:

```python
from conan import ConanFile

class Lib2Recipe(ConanFile):
    name = "lib2"
    requires = ["lib1a/[~2.2.0.branch-a,include_prerelease]",
                "lib1/[~1]"]
```

My goal for the above is to use the latest binary from the `2.2.0.branch-a` versioning. I've included `include_prerelease` because I found it won't resolve without it.

<br>

## Provider lib1a

I've generated several `lib1a` versions to investigate this.

```bash
$ conan list lib1a
Local Cache
  lib1a
    lib1a/2.0.0
    lib1a/2.1.0
    lib1a/2.1.1
    lib1a/2.1.2
    lib1a/2.2.0
    lib1a/2.2.0.branch-a.0     <<<<<
    lib1a/2.2.0.branch-a.0.1   <<<<<
    lib1a/2.2.0.branch-a.1     <<<<<
    lib1a/2.2.0.branch-a.2     <<<<<
    lib1a/2.2.0.branch-b.0
    lib1a/2.2.0.branch-b.1
    lib1a/2.2.0.branch-b.2
```

<br>

## Expectation

Based on the above, I expect that `lib2` would use `lib1a/2.2.0.branch-a.2`. I expect this based on the documentation that explains the tilde usage.

<br>

## Reality

`lib2` is actually using `lib1a/2.2.0.branch-b.2` as illustrated in the following output.

```bash
$ conan install lib2

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows


======== Computing dependency graph ========
Graph root
    conanfile.py (lib2/None): C:\Users\rocha\Desktop\TEST-CONAN\GRAPH\lib2\conanfile.py
Requirements
    lib1/1.2.0#eb9b91e4d2992a84e0d410ae5b8be4b9 - Cache
>>> lib1a/2.2.0.branch-b.2#eb1249058251aa8775aa32737bf08e96 - Cache <<<
Resolved version ranges
    lib1/[~1]: lib1/1.2.0
>>> lib1a/[~2.2.0.branch-a,include_prerelease]: lib1a/2.2.0.branch-b.2 <<<

======== Computing necessary packages ========
Requirements
    lib1/1.2.0#eb9b91e4d2992a84e0d410ae5b8be4b9:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache
>>> lib1a/2.2.0.branch-b.2#eb1249058251aa8775aa32737bf08e96:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache <<<

======== Installing packages ========
lib1/1.2.0: Already installed! (1 of 2)
lib1a/2.2.0.branch-b.2: Already installed! (2 of 2) <<<

======== Finalizing install (deploy, generators) ========
conanfile.py (lib2/None): Generating aggregated env files
conanfile.py (lib2/None): Generated aggregated env files: ['conanbuild.bat', 'conanrun.sh']
Install finished successfully
```


### Logs

_No response_
user: RochaStratovan
issue_15637: state: open
title: [question] What is the recommanded way for branch versions ?
body: ### What is your question?

My question is regarding Conan 2.0 and branch versioning.
With conan 1.X, we used the channel to distinguish between branches for our versions in our remote.
I read conan documentation and I understand that it is not recommended to use channel anymore.

We implemented `set_version` function in our conanfile which uses `git describe` for setting the version. We also use tags in our repositories for labeling the released versions.
for example: we might have a tag `0.7.1` for that version. (major.minor.patch) and we use the number of commits from `git describe` command and the `build`.
so on a development branch we might have the version `0.7.1.45` (45 commits since the tag).
When developers implement something, they branch out to a side branch, do their work, do several commits, for example 10 commit. On their branch the package version is now `0.7.1.55`
but after the squash and merge to the develop branch the version will be `0.7.1.46` 
Which makes it hard for other developer to understand what is the latest version that they want to use.

I though to add the branch name to the build number, for example: `0.7.1.46-the-most-scary-bug-ever`

What do you do at your companies ? how do you get around versioning branches and resolve the version conflicts between the branches ?

Thanks,
  Sagi.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sagi-ottopia
issue_15633: state: open
title: [question] Conan - CMake package development workflow: unit-testing
body: ### What is your question?

Dear Conan Team,

As far as I understood, the unit-testing setup described in Conan help requires to create a separate Conan package to host the tests, that depends on the lib one wants to test. This works well but does not allow for a smooth package development workflow.

## What I want to do
I would like to be able to use CMake integration in IDEs (VSCode/VS2022) in order to smoothly do the cycle _write code - build - test_, without having to go back to any Conan call from the command line.

In other words, I'd like to:
- do a `conan install ...`
- Work only on writing code and calling CMake configure/build/test
- Once I'm happy, I push my changes and let my CI pipeline take care of the `conan create` & `conan update` 

## Why I am stuck
### Finding the built shared objects at tests-runtime
As recommended in the documentation, in my `conanfile.py`, the `build()` step definition is minimal (just `cmake.configure()` & `cmake.build()` calls) and all the setup is made in the `generate()`  function.

The Lib I want to build is a shared lib (let's call it `thelib`), and I want to test it with CTest & GTest.
Conan provides then the `generators/CMakePrestets.json` file with a `testPreset` that sets the `runenv` info of the packages my lib depends on.

Since the `environment` provided in the `testPreset` does not contain the path to the lib runtime location (`thelib.so` or `thelib.dll`), running the test fails. What is the proper way to provide the proper runtime location, so that CTest runs finds `thelib.so`? The `layout` function specifies the location of the libs, maybe it's possible to use this then?

### Finding non-conan-related 3rd party libs
Assuming that I want to be able to specify the location of an external runtime library that is not handled by Conan and append/prepend it to the `LD_LIBRARY_PATH` that Conan will use. 
I would like to have it in an own `CMakeUserPresets.json`. This is possible to set up with `tc.user_presets_path` setting. Unfortunately, if I inherit Conan's `testPreset` and set `LD_LIBRARY_PATH`, this will overwrite (and not extend) the Conan-provided `LD_LIBRARY_PATH`.

Is there a way to specify a prefix/suffix for `CMakeToolchain` to generate a `generators/CMakePresets.json` that has prefixed/suffixed environment variables? For example 
`.../generators/CMakePresets.json`
```
    "testPresets": [
        {
            "name": "conan-relwithdebinfo",
            "configurePreset": "conan-relwithdebinfo",
            "environment": {
                "LD_LIBRARY_PATH_CONAN": "...",
                "PATH_CONAN": "..."
            }
        }
    ]
```

This way I can have in my own `/CMakeUserPresets.json` something like:
```
    "testPresets": [
        {
            "inherits": "conan-relwithdebinfo",
            "name": "conan-extended-ldpath",
            "environment": {
                "LD_LIBRARY_PATH": "some-3rdparty-system-lib/lib:$penv{LD_LIBRARY_PATH_CONAN}:$penv{LD_LIBRARY_PATH}"
            }
        }
    ]
```

Or, is there just a better built-in way than this suffixing idea?

## Sidenotes
### Debugging tests
Debugging tests - on VSCode - cannot rely on CMakePresets. It requires a `launch.json` that may use a `.env` file. It may be nice to have a generator that creates such an `.env` file. Note that this should contain both the dependencies runtime locations _and_ the `thelib.so` location.

### Sidenote on VS2022
VS2022 seems to not well integrate CMakePresets for tests (the _test explorer_ UI does not provide the ability to pick a test preset so tests are "just" run in a console instead of the more readable _test explorer_ display).
Maybe it could help to provide a generator that creates a `.runsettings` file specifying the environment variables for the tests, to be used in place of the `testPreset`.

Thanks for your help and the great work so far with Conan,
Any suggestion of a better way to work with Conan / CMake / CTest is most welcome, don't hesitate to let me know if I'm having anti-patterns that I can eliminate

Best,
M.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: mpll-d
issue_15632: state: open
title: [question] pre install hook
body: ### What is your question?

Hey,

I'm currently trying to implement a hook in order to warn if users haven't installed the latest config version of our config repository based on a version file within the config repo. 
Therefore I would need to hook-in as early as possible and before the configs becoming relevant. Hence, I think, this hook should take action before installing any package but I couldn't find any hook which fits this requirement. Is there a reason it is not possible to create hooks before install and could you recommend which hook would be the best for this use-case? Or is there even maybe a smarter way to achieve this goal?

Thank you very much! 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: nicosmd
issue_15627: state: open
title: [bug] Unable to run Msbuild.exe when using AutotoolsToolchain
body: ### Environment details

* Operating System+version: Windows 11 22H2
* Compiler+version: msvc16 (VS2019)
* Conan version: 2.0.17
* Python version: integrated in Conan release


### Steps to reproduce

When using the AutotoolsToolchain then later calls to MSBuild build helper will fail, because command 'msbuild' is not found.

E.g. in a recipe one could do:

`def generate(self):`
`       tc = AutotoolsToolchain(self)`
`       ...`
`       tc.generate()`
` `
`def build(self):`
`        autotools = Autotools(self)`
`        autotools.configure(...)`
`        autotools.make()`
`        if self.settings.os == "Windows":`
`            if self.options.shared:`
`                msbuild = MSBuild(self)`
`                msbuild.build("merge_module.sln")`

The msbuild command line will be executed in MSYS2 environment.
But inside MSYS2 you cannot call 'msbuild' - that does not exist. You have to call 'msbuild.exe'. That one will be found. I verified this by manually starting MSYS2 bash and executing all generated conanbuild.bat and conanbuild.sh.
In source code of revision 2.0.17 one can find the assembly of msbuild command in msbuild.py line 58.

On the other hand I think it is not necessary to execute Msbuild inside of MSYS2 environment.
Is it possible to set another toolchain for Msbuild build helper?

### Logs

_No response_
user: chr-thien
issue_15620: state: open
title: [question] How is Conan handling different C++ standard libraries? I'm interested in hardened libc++ specifically.
body: ### What is your question?

I want to build against a hardened version of libc++ (with container-aware iterators), so my first thought was that there surely must be a package for that.

There doesn't seem to be one. And from the documentation, I can't figure out how Conan handles different versions of libc++ or even libc++ vs stdlibc++.

So, how exactly does Conan handle the standard library dependency and hardened versions of the standard library?

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: HappyCerberus
issue_15618: state: open
title: [question] Disable transitive COMPILE_DEFINITIONS 
body: ### What is your question?

I am working on a project which involves creating a shared library which links to my own static library MyLib which in turn links to a static version of Boost. The shared library also needs to link to a shared library version of Boost. The shared Boost version is coming from a system wide SDK that I need to link to to generate the shared library, which is a plugin for that SDK.

I already made sure my own Boost version is using a custom namespace so there are not symbol conflicts.
So the dependency graph is as follows.

```
MyLib (static) <- Boost (custom namespace, static)

MyPlugin (shared) <- MyLib
MyPlugin (shared) <- Boost (SDK, shared)
```

In the `conanfile.py` of `MyLib`, I have setup the requirements as follows
```
self.requires("boost/1.82.0@custom", transitive_headers=False)
```

In the `conanfile.py` of `MyPlugin` I have
```
self.requires("mylib/1.0")
```

The problem is that the SDK links to its own boost libraries using the `#pragma lib` however my version of `Boost` has disabled this by defining the `BOOST_ALL_NO_LIB` compiler flag.
This works great for `MyLib` in which I explicitly link to the relevant Boost libraries.
However, the `BOOST_ALL_NO_LIB` also gets set inside the `MyPlugin` build since the `CMakeDeps` still generates a BoostConfig.cmake through the dependency on `boost/1.82.0@custom` with that info (see snippet below).

```
########### VARIABLES #######################################################################
#############################################################################################
set(boost_PACKAGE_FOLDER_RELEASE "C:/Users/Pieter/.conan2/p/boostc6274de64af5d/p")
set(boost_BUILD_MODULES_PATHS_RELEASE )


set(boost_INCLUDE_DIRS_RELEASE )
set(boost_RES_DIRS_RELEASE )
set(boost_DEFINITIONS_RELEASE "-DBOOST_ALL_NO_LIB")
set(boost_SHARED_LINK_FLAGS_RELEASE )
set(boost_EXE_LINK_FLAGS_RELEASE )
set(boost_OBJECTS_RELEASE )
set(boost_COMPILE_DEFINITIONS_RELEASE "BOOST_ALL_NO_LIB")
```

The interesting thing is that it does not set the `boost_INCLUDE_DIRS_RELEASE ` variables because I set `transitive_header=False` but it does still generate the compiled definitions. 

Is there a way to disable the generation of these compile definitions as they are not needed to just link the custom Boost libraries?


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: pkitslaar
issue_15614: state: open
title: [question] Is there a way to create a conan package that combines both Release and Debug in the same package?
body: ### What is your question?

# Is there a way to create a conan package that combines both Release and Debug in the same package?

Conan's package methodology of one build_type (Release, Debug, RelWithDebugInfo, MinSize) per package, breaks CMake's methodology of many configurations may be in a single CMake relocatable package.

This is problematic when we use the relocatable CMake package files that we generate for ourselves and our customers, or when using the CMake package files that 3rd party open source library's provide in combination with Visual Studio's multi-configuration IDE.

I know about the suggested method of

```bash
conan install . -s build_type=Release
conan install . -s build_type=Debug
<cmake commands next>
```

works for Windows Visual Studio multi-configuration when using the conan generated CMake files. However, it does not work when using standard relocatable CMake packages.

I did some digging into this and found that this appears to be a fundamental mismatch between conan and CMake packages.

When we create a relocatable CMake package for release and debug images it is typically done with a folder hierarchy such as:

```bash
<foo-package-root>/
    +--cmake/
    |    +--foo-config-debug.cmake
    |    +--foo-config-release.cmake
    |    +--foo-config.cmake
    |
    +--include/
    |
    +--lib/
         +--fooD.lib
         +--fooR.lib
```

To find the `foo` package it would either be installed to a common root location, or the `CMAKE_MODULE_PATH` value is updated to include the path to `<foo-package-root>`.

When `find_package(foo...)` is invoked it finds this location and has the ability to return one of the two configurations listed.

<br>

If we tried this in the conan world where we have one configuration per package we end up with two separate paths/repos where each one has just one configuration. Such as the following:

```bash
<conan-debug-path>
|   +--cmake/
|   |    +--foo-config-debug.cmake
|   |    +--foo-config.cmake
|   |
|   +--include/
|   |
|   +--lib/
|        +--fooD.lib
<conan-release-path>
    +--cmake/
    |    +--foo-config-release.cmake
    |    +--foo-config.cmake
    |
    +--include/
    |
    +--lib/
         +--fooR.lib
```

This mechanism can never work for a Visual Studio multi-configuration situation because cmakes `find_package(foo...)` stops when it finds the first cmake package with the correct name.

If `CMAKE_MODULE_PATH` has `<conan-debug-path>` listed first then it will stop when it finds `<conan-debug-path>/cmake/foo-config.cmake` and will always and only return the debug version of the library.

This is because it doesn't know about the existence or location of the release library.

<br>

# Why don't we just use the conan generated CMake files?

We don't use the conan generated CMake files because conan doesn't know about any extra logic or variables that we or 3rd party libraries place in our relocatable CMake package files.

<br>

# Workaround

I've found and confirmed the following workaround.

1. Start with a leaf level project that doesn't have any requirements

1. Use the _conan way_ to start a multi configuration toolchain.

   ```bash
   conan install . -s build_type=Release
   conan install . -s build_type=Debug
   ```

1. Generate the cmake build files

   ```bash
   cmake . -B build -A x64 ^
       -DCMAKE_TOOLCHAIN_FILE="<path to toolchain file" ^
       -DCMAKE_POLICY_DEFAULT_CMP0091=NEW
   ```

1. Compile R and D and install to the local INSTALL folder

   ```bash
   cmake --build build --config Release
   cmake --install build --config Release --prefix "%CD%\INSTALL"
   cmake --build build --config Debug
   cmake --install build --config Debug --prefix "%CD%\INSTALL"
   ```

   After this point the INSTALL folder has both R and D libraries as well as
   the relocatable package to work for R and D libraries.

1. Set the `conanfile.py` logic to package the contents of the INSTALL folder
   and to use the relocatable CMake package logic.

1. Export the package

   ```bash
   conan export-pkg . -s build_type=Release
   conan export-pkg . -s build_type=Debug
   ```

At this point we have two conan packages for Release and Debug in the local cache, where each package is a duplicate of the other with both Release and Debug libraries and cmake logic.

When consumers of this package try to set up multi configuration following the _conan way_

```bash
conan install . -s build_type=Release
conan install . -s build_type=Debug
```

The local toolchain is set up for Release and Debug and the package folders that are searched will be able to provide both Debug and Release images.


<br>

# Is there a better conan way to do this?

I've confirmed that this workaround works. But it feels hacky. I don't like it. Is there an better way to do this? A _conan way_ to do this?


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: RochaStratovan
issue_15612: state: open
title: Check handling around `.dirty` usage in file download handlings
body: We found some issues in https://github.com/conan-io/conan/pull/15601

Specifically, `.dirty` files in the local backup cache can be left without their corresponding failed file and never be removed, nor a warning that there was ever a dirty file be printed.

We should look into reviewing this pattern and coming up with a cleaner solution the works for all the current use-cases 
user: RubenRBS
issue_15611: state: open
title: [question] Is cmake_set_interface_link_directories needed?
body: ### What is your question?

Hi, I was investigating the reason for warnings during build after switching to conan2.
https://github.com/conan-io/conan-center-index/issues/22688

I've found out that conan2 always adds library directories to interface (INTERFACE_LINK_DIRECTORIES) in CMakeDeps. So "cmake_set_interface_link_directories" doesn't really control anything. Is it expected? Should this property be removed?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Nekto89
issue_15608: state: open
title: [question] set_version hook and the local repository
body: ### What is your question?

Hi, I have a problem to get my package versioning working correctly. (Using conan 1.62) Basically if I create or export a package initially on my machine, everything is fine. I can get my package version via `gitversion` call in the `set_version` hook (since the recipe_folder resists in my local git repository). Further I set the self.version of my package to the semantic version of gitversion. So far so good.

But as I consume my package and would have to build it from source, the `recipe_folder` now resists in the conan cache folder and therefore I don´t have the chance anymore to get the version information from `gitversion`.
My first thought was, to create a version.json file and export it in the `export_source` hook. But as the `set_version` hook is called from within the cache folder, as far as I know, I don´t have access to the exported sources safely?

I don´t get the idea, why the package version must be set a view times after a package was created / exported. I would prefer to fix the version once a recipe is created. Let´s say I create a package recipe with the version 1.0.0 and upload it to my remote. Anybody who resolves this dependency gets this recipe downloaded in it´s local cache, but before the actual `build` hook, the package could internally change it´s version to e.g. 2.0.0. That does not make any sense to me, or am I misunderstanding the concept at this point?

The behavior which I would love to see would be that the package version can be defined once in the package creation process and therefore reused in every further step. By the way I guess the example provided here: https://docs.conan.io/2/reference/conanfile/methods/set_version.html#set-version using the `Git` tool from `conan.tools.scm` would fail too in the situation where a package must be built from source from within a cache folder?

Does anybody has some experience of versioning the packages with gitversion?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: CrazyDaisyRecords
issue_15606: state: open
title: Is there a way to use USERPROFILE in MSBuildDeps generator?
body: I want to use the $(USERPROFILE) instead of the actual user profile folder path in the generated props file.

I am using conan 2.0.

I have seen feature requests for the same and has been fixed in 1.6. So I am wondering if this can be achieved in conan 2.0 as well.

https://github.com/conan-io/conan/pull/3185

https://github.com/conan-io/docs/pull/660

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sandybhat16
issue_15605: state: open
title: Refactor/deactivate sh env
body: Changelog: (Feature | Fix | Bugfix): Describe here your pull request
Docs: https://github.com/conan-io/docs/pull/XXXX

- [ ] Refer to the issue that supports this Pull Request.
- [ ] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [ ] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ ] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

user: memsharded
issue_15604: state: open
title: [question] Tracking Downloads
body: ### What is your question?

Hi, how can I track how many people are using/downloading my package on Conan?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: mals512
issue_15597: state: open
title: [question] How to disable signing on Xcode
body: ### What is your question?

Hi! I have a question regarding usage of Xcode for building conan packages.
I was using default "Unix Makefiles" generator for some time on macOS but after switching to "Xcode" I'm getting errors. I would like to disable code signing. Is it possible to achieve this natively through conan like other apple-specific options (tools.apple:enable_arc, enable_bitcode, enable_visibility)? For cmake projects it can be done through "-DCMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_ALLOWED=NO" but I would prefer to use more universal way.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Nekto89
issue_15595: state: open
title: [question]Handle precompiled headers in package_info
body: ### What is your question?

Hi, I'm using cmake build-in mechanism to generate export header file:

cmake code:

```
include(GenerateExportHeader)
generate_export_header(${PROJECT_NAME}
    EXPORT_MACRO_NAME LIBRARY_DLL_API
    EXPORT_FILE_NAME ${PROJECT_NAME}_export.h
)

target_precompile_headers(${PROJECT_NAME} 
       INTERFACE $<BUILD_INTERFACE:${PROJECT_BINARY_DIR}/${PROJECT_NAME}_export.h>
       INTERFACE $<INSTALL_INTERFACE:include/${PROJECT_NAME}_export.h>
)
```


When I call cmake install I have (in file libraryTargets.cmake):

```
set_target_properties(<project_name> PROPERTIES
.
.
.
  INTERFACE_PRECOMPILE_HEADERS "include/<project_name>_export.h"
)
```

How can I define **INTERFACE_PRECOMPILE_HEADERS** in conan package_info?

Due to dependencies between projects I'm using conan 1.x (1.62).

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: tomasz-wezyk
issue_15588: state: open
title: fix for msvc toolset version overflow
body: Changelog: Fix: Fix for future ``msvc`` toolset version overflow
Docs: Omit

Close https://github.com/conan-io/conan/issues/15583
user: memsharded
issue_15584: state: open
title: [question] Exporting libs not working on linux
body: ### What is your question?

Hey guys,
I'm having a really strange problem.
I have created a recipe for my CMake 3rd Party.
I'm consuming this thirdparty via my CMake Application using cmake-conan (and latest conan 1.x)
=> However in 1 particular linux build some 3rd Party exports are missing with leads to "unresolved external symbol" linker errors for the SDL dependency.
Strangely another linux build works fine.

We are running Windows, Linux and embedded Target Builds. All of our builda re consuming lots of conan packages.
=> I'd assume that we are using cmake-conan correctly.

All of our application builds are invoked by
`cmake --preset my_preset`

Unfortunately this is not very reproducible. On my WSL all Linux builds work fine, the only issue is when I'm running this inside the docker container (which is used on our jenkins)


My conan recepie looks like this
```

from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMake, cmake_layout
from conan.tools.files import copy, rename, mkdir, load
from conan.tools.microsoft import is_msvc
from conan.tools.scm import Git
from hashlib import sha256
from os import path


class LvglConan(ConanFile):
    name = "lvgl"
    version = "9.0T"
    # Optional metadata
    license = "MIT"
    author = "xxx"
    url = "https://gitlab.cds.xxx/third_party/lvgl"
    description = "LVGL as a conan 3rd party, including drivers and simulator"
    generators = "CMakeDeps"
    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {
        "shared": [True, False],
        "fPIC": [True, False],
        "lv_conf_path": [None, "ANY"],
        "disable_examples": [True, False],
        "disable_demos": [True, False],
        "disable_thorvg": [True, False],
        "driver": [None, "sdl"],
        # set to true if you would like to use sdl from lvgl git repo, set to false if you would
        # like to use sdl from conan center
        "use_packaged_sdl": [True, False],
    }
    default_options = {
        "shared": True,
        "fPIC": True,
        "lv_conf_path": None,
        "disable_examples": True,
        "disable_demos": True,
        "disable_thorvg": True,
        "driver": None,
        "use_packaged_sdl": False,
    }

    def __copy_as(self, src, dst):
        mkdir(self, path.dirname(dst))
        import shutil

        shutil.copy(src, dst)

    def __copy_as_test(self, src, dst):
        mkdir(self, path.dirname(dst))
        copy(self, path.basename(src), path.dirname(src), path.dirname(dst))
        if path.basename(src) != path.basename(dst):
            rename(self, path.join(path.dirname(dst), path.basename(src)), dst)

    def __copy_config_files(self):
        if self.options.lv_conf_path:
            lv_conf_path = self.lv_conf_path
            self.__copy_as(lv_conf_path, path.join(self.source_folder, "lvgl/lv_conf.h"))
        else:
            original_conf_file = "lv_conf_default.h"
            self.__copy_as(
                path.join(self.source_folder, f"lvgl/config/{original_conf_file}"),
                path.join(self.source_folder, "lvgl/lv_conf.h"),
            )

    def requirements(self):
        if self.options.driver == "sdl" and not self.options.use_packaged_sdl:
            self.requires("sdl/2.28.5", transitive_headers=True, transitive_libs=True)

    def configure(self):
        if self.options.driver == "sdl" and not self.options.use_packaged_sdl:
            self.options["sdl"].shared = self.options.shared
            if self.settings.os == "Linux":
                self.options["sdl"].pulse = False
                self.options["sdl"].alsa = False

    def source(self):
        git = Git(self)
        clone_args = [f"-b v{self.version}"]
        if self.options.use_packaged_sdl:
            clone_args.append("--recurse-submodules")
        git.clone(url="git@gitlab.cds.xxx:third_party/lvgl.git", args=clone_args)

    def config_options(self):
        if self.settings.os == "Windows":
            self.options.rm_safe("fPIC")

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)

        tc.cache_variables["LV_CONF_PATH"] = self.source_folder.replace("\\", "/") + "/lvgl/lv_conf.h"
        tc.cache_variables["LV_CONF_BUILD_DISABLE_THORVG_INTERNAL"] = bool(self.options.disable_thorvg)
        if self.options.driver == "sdl":
            tc.cache_variables["BUILD_DRIVERS"] = "ON"
            if self.options.use_packaged_sdl:
                tc.cache_variables["USE_STANDALONE_BUILD"] = "ON"

        tc.cache_variables["BUILD_SHARED_LIBS"] = bool(self.options.shared)
        tc.cache_variables["LV_CONF_BUILD_DISABLE_EXAMPLES"] = bool(self.options.disable_examples)
        tc.cache_variables["LV_CONF_BUILD_DISABLE_DEMOS"] = bool(self.options.disable_demos)
        tc.generate()

    def build(self):
        self.__copy_config_files()
        cmake = CMake(self)
        cmake.configure(build_script_folder="lvgl")
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()

    def __getFilehash(self, filename):
        try:
            text = load(self, filename)
        except FileNotFoundError:
            print(f"File not Found: {filename}")
            raise

        h = sha256()
        bts = bytes(text, "utf8")
        h.update(bts)
        return h.hexdigest()

    def package_id(self):
        if self.options.lv_conf_path:
            self.lv_conf_path = self.info.options.get_safe("lv_conf_path")
            self.info.options.lv_conf_path = self.__getFilehash(self.lv_conf_path)

    # CORRECT ONE
    def package_info(self):
        # Important: Keep the correct linking order!. Examples and demos depend on lvgl, so use them first!
        used_libs = []
        if not self.options.disable_examples:
            example_lib = ["lvgl_examples"]
            used_libs += example_lib

        if not self.options.disable_demos:
            demos_lib = ["lvgl_demos"]
            used_libs += demos_lib

        if not self.options.disable_thorvg:
            thorvg_libs = ["lvgl_thorvg"]
            used_libs += thorvg_libs

        lvgl_lib = ["lvgl"]
        used_libs += lvgl_lib

        if self.options.driver == "sdl" and self.options.use_packaged_sdl:  # Using components
            self.cpp_info.components[f"lib{self.name}"].requires = ["sdl::sdl"]
            self.cpp_info.components[f"lib{self.name}"].libs = used_libs
            self.cpp_info.components[f"lib{self.name}"].includedirs = ["include", "include/lvgl"]
            self.cpp_info.components[f"lib{self.name}"].defines = [
                "LV_CONF_PATH=lvgl/lv_conf.h",
            ]
            if self.settings.os == "Windows" and is_msvc(self):
                self.cpp_info.components[f"lib{self.name}"].defines.append(
                    "LV_ATTRIBUTE_EXTERN_DATA=__declspec(dllimport)"
                )
        else:  # Not using components
            self.cpp_info.libs = used_libs  # Ignored if ``self.options.driver == "sdl"
            self.cpp_info.includedirs = ["include", "include/lvgl"]  # Ignored if ``self.options.driver == "sdl"
            self.cpp_info.defines = [  # Ignored if ``self.options.driver == "sdl"
                "LV_CONF_PATH=lvgl/lv_conf.h",
            ]
            if self.settings.os == "Windows" and is_msvc(self):
                # Ignored if ``self.options.driver == "sdl"
                self.cpp_info.defines.append("LV_ATTRIBUTE_EXTERN_DATA=__declspec(dllimport)")
```

We are running the following commands 
```
export CONAN_USER_HOME=/work
export CONAN_ENABLE_REVISIONS=1
cmake --preset working_preset
cmake --build working_preset_rel
cmake --preset not_working_preset
cmake --build --preset not_working_preset_rel
```


There are 2 lvgl conan packages created (1 for debug and 1 for release) and 2 sdl packages (Debug + Release)
=> so both presets seem to consume the same packages (lvgl + sdl)

I have attached the full console output of the cmake configure stage
When using a diff tool you will notice that the working preset has a

```
conanfile.txt imports(): Copied 1 '.5' file: libSDL2-2.0d.so.0.2800.5
conanfile.txt imports(): Copied 1 '.5' file: libSDL2-2.0.so.0.2800.5
```

and the not working preset doesn't have this.


[not_working.txt](https://github.com/conan-io/conan/files/14143213/not_working.txt)
[working.txt](https://github.com/conan-io/conan/files/14143214/working.txt)


=> so the question is: Why does one preset has this copy stuff and the other doesn't both of them seem to use the same binary.

Could you help me out here

thx guys, I'm a little bit lost :O

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: Ju1He1
issue_15583: state: open
title: [feature] Support new ``msvc`` versioning for VS2022 latest toolsets
body: ### What is your suggestion?

vs2017 -> platform toolset v141 -> msvc 19.1x
vs2019 -> platform toolset v142 -> msvc 19.2x
vs2022 -> platform toolset v143 -> msvc 19.3x
vs2022 , version 17.10 and higher -> platform toolset  v143 ->  msvc toolset 14.40 -> msvc 19.4x

From: https://devblogs.microsoft.com/cppblog/msvc-toolset-minor-version-number-14-40-in-vs-2022-v17-10/

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: memsharded
issue_15578: state: open
title: libvips: conversion to pyramidal files fails
body: Dear all,

when using the C api of libvips/8.15.1, the conversion to pyramidal files does not work at all using the function:

vips_tiffsave( inputImage,
                       filename,
                       "pyramid",
                       true,
                       "tile",
                       true,
                       "compression",
                       VIPS_FOREIGN_TIFF_COMPRESSION_LZW,
                       "bigtiff",
                       true,
                       NULL )

while when using libvips/8.14.2 it seems to work for "smaller" images (e.g., 13811 X 6122). But for "larger" images (e.g., 122880 X 110592) images, the conversion to a pyramidal file fails with this error:

VIPS:ERROR:../src/libvips/iofuncs/target.c:482:vips_target_flush: assertion failed: (target->write_point >= 0)
Bail out! VIPS:ERROR:../src/libvips/iofuncs/target.c:482:vips_target_flush: assertion failed: (target->write_point >= 0)

We suspect there is an issue with the conan build. Please see the discussion at the libvips forum: https://github.com/libvips/libvips/discussions/3828

Is it possible to fix this error with the conan build of libvips?

Thank you,
Bojan.
user: bkocev
issue_15577: state: open
title: Visual Studio test check
body: Waiting for CI
user: RubenRBS
issue_15569: state: open
title: Packaging header only library with conan 2
body: ### What is your question?

Hi! I have a question regarding packaging a header only library with conan2 and cmake:
We have implemented the following `generate()` method to generate the conan_toolchain.cmake file:
```python
def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()
```

The `package()` function looks as follows:
```python
def package(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.install()
```

Using this everything seems to work on linux. However, on Windows we get the following error messages stating that the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER` and `CMAKE_MAKE_PROGRAM` couldn't be found.

```
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
```

The question is, why these settings are even necessary for a header only library. Is there a possibility to configure everything in a way that those are not required? Or are we doing something completely wrong?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: lstoffer
issue_15549: state: open
title: [question] Indexing and building multiple recipes in correct order
body: ### What is your question?

I am converting a large project from plain CMake to be managed by conan. The structure of the project is as follows:

\CMakeLists.txt
\libA\CMakeLists.txt
\libB\CMakeLists.txt
etc..

In the various libA, libB can have dependencies on each other. The way this is currently handled is that in the master CMakeLists.txt there are multiple add_subdirectory(..) calls in the correct order so that dependent libraries are visited first before the library that consumes them.

I am converting this to conan so each libX is a conan package with its own conanfile.py. In the conanfile.py I indicate the dependencies using the requires(...) methods.

Is there a way to easily scan/index the entire project and find all the dependencies between the projects and come up with some superbuild command so all the libraries are build/created in the correct order?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: pkitslaar
issue_15548: state: open
title: [question] How to handle test_package while cross compiling a tool package?
body: ### What is your question?

I am trying to build 7zip recipe on Mac, and get test_package error while building x86_64 version with armv8 build profile, my build profile is:
```
[settings]
os=Macos
arch=armv8
```
my host profile is:
```
[settings]
os=Macos
arch=x86_64

compiler=apple-clang
compiler.cppstd=20
compiler.libcxx=libc++
compiler.version=14.0
```
This leads to error while launching test_package:

> ======== Installing packages ========
> ERROR: Missing binary: 7zip/23.01:dcf68e932572755309a5f69f3cee1bede410e907

The reason is: I am creating a x86_64 package per host profile, but in test_package, 7zip is declared as tool:
`        self.tool_requires(self.tested_reference_str)
`
so it uses build profile to find package.

What's the best practice to handle this scenario? If conan cannot support this scenario, is it possible to skip test_package for this cross-compile scenario?




### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: zhanglin-zhou
issue_15547: state: open
title: [question] Artifactory Integration, mirror source instead of just recipe
body: ### What is your question?

Hi, I am trying out Conan 2.0.17 at my workplace. The firewall forbids our UAT & PROD to communicate with external websites unless explicitly whitelisted. For Conan-Center remote, we have mirrored it using Artifactory to workaround that rule. However, recipes may contain dependencies that are hosted externally, e.g. bzip2 is hosted on sourceware.org, which is not on the whitelist. So whenever I try to install bzip2 it prompts urllib3 failing DNS lookup. While I could apply for a whitelist, it's counter-productive to do so per new dependency host added. Instead, I could see there are two common workarounds that other pkg-manager / build-tools take, yet I am not aware of its counterpart in Conan.

- Is it possible to set artifactory plugins to mirror sources in place of the consumer? 
- Is it possible to manually specify proxy mappings, in our artifactory `github.com` is mapped under `github-release`

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: haleyk10198
issue_15546: state: open
title: [bug] conan create ... , got `ERROR: Specify the 'user' and the 'channel' or neither of them` 
body: ### Environment details

* Operating System+version: Windows 22621.2134
* Compiler+version:
* Conan version: 1.61.0
* Python version: 3.10.10


### Steps to reproduce

execute command 
```bash
conan create . system_api/0.0@gzh/testing
````
I specified user=gzh and channel=testing, but still get 
```bash
ERROR: Specify the 'user' and the 'channel' or neither of them
```

### Logs

```log
DEBUG :conan_api.py   [176]: INIT: Using config 'C:\Users\20536\.conan\conan.conf' [2024-01-29 11:27:13,444]
DEBUG :tracer.py      [156]: CONAN_API: create(name=system_api,version=0.0,user=gzh,channel=testing,profile_names=None,settings=None,conf=None,options=None,env=None,test_folder=None,not_export=False,build_modes=None,keep_source=False,keep_build=False,verify=None,manifests=None,manifests_interactive=None,remote_name=None,update=False,test_build_folder=None,lockfile=None,lockfile_out=None,ignore_dirty=False,profile_build=ProfileData(profiles=None, settings=None, options=None, env=None, conf=None),is_build_require=False,require_overrides=None) [2024-01-29 11:27:13,446]
DEBUG :profile_loader.py[121]: PROFILE LOAD: C:\Users\20536\.conan\profiles\default [2024-01-29 11:27:13,447]
INFO  :settings_preprocessor.py[56]: Setting 'compiler.runtime' not declared, automatically adjusted to 'MDd' [2024-01-29 11:27:13,479]
DEBUG :profile_loader.py[121]: PROFILE LOAD: C:\Users\20536\.conan\profiles\default [2024-01-29 11:27:13,479]
ERROR: Specify the 'user' and the 'channel' or neither of them
```
user: h20282
issue_15544: state: open
title: [feature] support all compiler_executables in tools.build.
body: ### What is your suggestion?

Every cmake compiler executable should be supported in tools.build.  I have custom profile code to workaround the fact that it doesn't, but it'd be a whole lot easier for custom llvm and sanitizer builds if the following was exposed.

```
tools.build.compiler_executables = {
  "cpath": "/opt/include",
  "exelinker": "/opt/bin/lld",
  "as": "/opt/bin/llvm-as",
  "ar": "/opt/bin/llvm-ar",
  "nm": "/opt/bin/llvm-nm",
  "ranlib": "/opt/bin/llvm-ranlib",
}
```

These all exist as cmake variables (except cpath), so `CMAKE_AR`, `CMAKE_AS`,  `CMAKE_NM` and `CMAKE_RANLIB`.  For autoconf, automake, and makefiles the environment variables `AR`, `AS`, `NM`, and `RANLIB`, _usually_ work with some notable exceptions (like the redis Makefile).

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: hoyhoy
issue_15543: state: open
title: [feature] tools.cmake.cmaketoolchain.compile_warning_as_error
body: ### What is your suggestion?

We have a large list of requirements that must compile on PowerPC-based hosts and we need to disable `-Werror` on some of them.  For example, I attempted fix `google_cloud_cpp` recipe in conan-center by just disabling the warnings [here](https://github.com/conan-io/conan-center-index/pull/21808/files), but @uilianries won't merge the patch because his CI doesn't have PowerPC hosts.  Why not just expose the setting in the conan CMakeToolChain instead?  Every useful setting like this should be exposed through the conan config interface.  We've been blocked by conan-center taking months to review and merge patches sent over and were forced to fork nearly every recipe into a user and channel.  If we had these options in the toolchain, it would solve a number of issues for us.

This setting wouldn't fix the `google-cloud-cpp` because they actually rolled their own `CMAKE_COMPILE_WARNING_AS_ERROR`, but it would have prevented me from writing my own implementation.

```
    @property
    def _werror(self):
        return self._get_safe_options_boolean("warnings_as_error")

    def generate(self):
        toolchain = CMakeToolchain(self)
        toolchain.cache_variables["CMAKE_COMPILE_WARNING_AS_ERROR"] = self._werror
```

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: hoyhoy
issue_15542: state: open
title: [question] What is the recommended way to manage SSL certificate with conan for windows and linux
body: ### What is your question?

Hi ! I'm try to setup jfrog artifactory CE as conan remote with https.
I'm a little confused on the way to handle a self certificate both on linux and windows platform.

## Environment details

- Conan version: 2.0.17
- Python version: 3.11.6
- Requests version: 2.31.0

## Here what is working for me now:

### On Linux:
I managed to add my certificate (.crt format)  to system certificates via `update-ca-certificates`  command on debian based distrib and setup conan to use it via `core.net.http:cacert_path=/etc/ssl/certs/ca-certificates.crt` in `.conan2/global.conf`

### On Windows:
I found no better way to use the python package `pip-system-certs` that is a runtime patch to python package `requests` to use system certificate.

## Here what is not working for me:
`core.net.http:cacert_path=/path/to/my_certificate.crt` in `.conan2/global.conf` give me
```
ERROR: HTTPSConnectionPool(host='conan.xxx.com', port=443): Max retries exceeded with url: /artifactory/api/conan/xxx/v1/ping (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1131)')))
```

## My question
What would be the recommended way to manage SSL certificate with conan for windows and linux ?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: MamaTierra
issue_15537: state: open
title: [question] How to run conan server with pipx
body: ### What is your question?

Hi! I have a question regarding running conan_server with pipx.

New distros point to either pipx or venv when dealing with python packages.

```
error: externally-managed-environment

× This environment is externally managed
╰─>
    The system-wide python installation should be maintained using the system
    package manager (apk) only.

    If the package in question is not packaged already (and hence installable via
    "apk add py3-somepackage"), please consider installing it inside a virtual
    environment, e.g.:

    python3 -m venv /path/to/venv
    . /path/to/venv/bin/activate
    pip install mypackage

    To exit the virtual environment, run:

    deactivate

    The virtual environment is not deleted, and can be re-entered by re-sourcing
    the activate file.

    To automatically manage virtual environments, consider using pipx (from the
    pipx package).
    ```
``` 
I consulted the conan docs and for conan I found the instructions here:
https://docs.conan.io/2/installation.html#install-with-pipx

However these settings don't apply to conan_server and the docs for conan_server don't mention pipx.
https://docs.conan.io/1/uploading_packages/running_your_server.html
https://docs.conan.io/2/tutorial/conan_repositories/setting_up_conan_remotes/conan_server.html

I tried using pipx for conan_server as well but ran into two issues:
- I needed to install bash, seems this is a requirement for pipx.
- I was unable to install the requirements.txt, seems that pipx doesn't support that?

I solved my issue with virtualenv, but maybe there's another solution with pipx?
Ideally that would be covered in the docs too. Thanks in advance!


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ErikTempelaarVO
issue_15530: state: open
title: [bug] Suggested replacement of SCM attribute with export/source is broken
body: ### Environment details

* Conan version: 1.62.0

### Steps to reproduce

According to the Conan Migration Guide the SCM attribute should be replaced with export/source methods as follows:

```python
def export(self):
    git = Git(self, self.recipe_folder)
    scm_url, scm_commit = git.get_url_and_commit()
    update_conandata(self, {"sources": {"commit": scm_commit, "url": scm_url}})
 
def source(self):
    git = Git(self)
    sources = self.conan_data["sources"]
    git.clone(url=sources["url"], target=".")
    git.checkout(commit=sources["commit"])
```

However, on Conan 1.62.0 this is obviously broken. In an in-cache build Conan seems to copy `conandata.yml` into the source folder before calling `source()`. This will make `clone()` fail because the directory is not empty. Relocating the source folder by setting `self.folders.source` in the `layout()` method works for in-cache builds but not in the local build workflow, because there we need to match the layout imposed by the repository structure.

This is a blocker for our migration efforts. I haven't been able to find a workaround and I cannot continue work until I have a solution.
user: jasal82
issue_15528: state: open
title: [bug] Many 'token for conan operation' on Conan 1.
body: ### Environment details

* Operating System+version: Linux ubuntu 22.04
* Conan version: 1.52


### Steps to reproduce

_No response_

### Logs

We are using Conan 1.52, and since a few days we see many token apparently automatically "token for conan operation" each time a `conan user -p` is executed in our CI, despit we already are using an identity token.

```
$ conan user -p $ARTIFACTORY_IDENTITY_TOKEN -r my-remote $$ARTIFACTORY_USERNAME
```

![image](https://github.com/conan-io/conan/assets/133498/96646c0c-00fd-41aa-ae76-cfcca42041bd)

Why does it do it when we are already using a token ?

Where is it coded? I do not find it anywhere
user: gsemet
issue_15522: state: open
title: conan.tools.microsoft.VCVars generator does not follow settings.compiler.update
body: [GenericSystemBlock.get_toolset](https://github.com/conan-io/conan/blob/8f86d38b92c22f82ad674ed69a1bf684fe056b32/conan/tools/cmake/toolchain/blocks.py#L696-L700) already has code to combine settings.compiler.version and settings.compiler.update such that compiler.version=193 and compiler.update=7 into a CMakePresets result like

```json
            "toolset": {
                "value": "version=14.37",
                "strategy": "external"
            },
```
(this doesn't quite work because VSCode also wants to see CMAKE_C_COMPILER=cl, but that's already reported in #13136).

However, [conan.tools.microsoft.visual._vcvars_vers](https://github.com/conan-io/conan/blob/8f86d38b92c22f82ad674ed69a1bf684fe056b32/conan/tools/microsoft/visual.py#L290) does not seem to have similar code to consider settings.compiler.update, so generators="VCVars" will only generate calls like `-vcvars_ver=14.3`, never `-vcvars_ver=14.37` vs `-vcvars_ver=14.38`. Which means conanbuild.bat won't necessarily get the same minor version that CMakePresets does... or even one that CMake will accept 

i.e.
```sh
conan new cmake_exe -d name=hello -d version=1.0
conan create . -s compiler.update=7
```

will fail with

> conanvcvars.bat: Activating environment Visual Studio 17 - amd64 - winsdk_version=None - vcvars_ver=14.3
> [vcvarsall.bat] Environment initialized for: 'x64'
> -- Using Conan toolchain: C:/Users/re41236/.conan2/p/b/hello23b22256ffb21/b/build/generators/conan_toolchain.cmake
> -- Conan toolchain: CMAKE_GENERATOR_TOOLSET=version=14.37
> -- Conan toolchain: C++ Standard 14 with extensions OFF
> -- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.
> -- The CXX compiler identification is unknown
> CMake Error at CMakeLists.txt:2 (project):
>   No CMAKE_CXX_COMPILER could be found.

```sh
conan2 create . -s compiler.update=7 -c tools.cmake.cmaketoolchain:generator=Ninja
```

is even worse - it just uses compiler.update=8 despite the settings:
> The CXX compiler identification is MSVC 19.38.33134.0

In both cases this is because the conanvcvars.bat contains
> C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC/Auxiliary/Build/vcvarsall.bat"  amd64 -vcvars_ver=14.3
rather than
> C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC/Auxiliary/Build/vcvarsall.bat"  amd64 -vcvars_ver=14.37

So the environment finds the latest 14.3x (which is 14.38) and then CMake rejects it as not mathching CMAKE_GENERATOR_TOOLSET

Since conan_toolchain.cmake contains `set(CMAKE_GENERATOR_TOOLSET "version=14.37" CACHE STRING "" FORCE)`, the msbuild generator knows this is wrong; ninja (as usual) doesn't actually check, and just goes by PATH.

Similarly, a call like `conan2 create . -s compiler.version=192 -s compiler.update=9 -c tools.microsoft.msbuild:vs_version=17`, which should select C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.29.30133, failed with a CMake error:

_Originally posted by @puetzk in https://github.com/conan-io/conan/issues/13136#issuecomment-1909152616_
user: puetzk
issue_15521: state: open
title: [question] How to manage hotfixes of libraries using Conan 1.x recipes versioned with sourcecode?
body: ### What is your question?

Hi conan team, 

Our project consists of ~60 repositories. Some are library projects and some applications that depends on libraries using conan and conan.cmake integration.
Each repository keeps sourcecode, conanfile.py and CMakeLists.txt and uses release branches in order to be able to easily release hotfixes (several customers use same product but at different versions)
All conanfile.py in repository are for Conan 1.x version

We're looking into moving to Conan 2.0 but I have a doubt.

If we update all recipes and then we move to Conan 2.x, we loose the ability to create hotfixes on old releases because on our machines we will have Conan 2.x installed but when checking out old source versions, every recipe will be in Conan 1.x format.

In this case, what's the best strategy to avoid being killed by breaking changes?




### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: thegwydd
issue_15518: state: open
title: [hiredis] : test_package doesn't honor skip_test and try to run non-host compatible bianry (same for libev)
body: ### Description

I have a profile for an x86-64 host that is not the same as my build machine, everything works except test_package which then try to run the test binary but my build machine doesn't have the libc version required to do so.

Conan "can_run" still return true, but in my profile I set skip_test to try to fix this problem and the hiredis/test_package and libev/test_package both do not look for skip_test and still try to run the binary which is clearly not compatible.

### Package and Environment Details

all of them.

### Conan profile

[options]
tools.build:skip_test=True


### Steps to reproduce

execute conan create on a x86_64 host which is not compatible with the build machine (cross-compilation using different libc version and such)

### Logs

<details><summary>Click to expand log</summary>

```
18:36:22  ======== Testing the package: Executing test ========
18:36:22  hiredis/1.1.0 (test package): Running test()
18:36:22  hiredis/1.1.0 (test package): RUN: ./test_package
18:36:22  ./test_package: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./test_package)
```

</details>

user: ykoehler
issue_15517: state: open
title: [question] Layouts and local build workflow on CI
body: ### What is your question?

Hi. I have a question regarding layouts and the local build workflow. During our migrations efforts we observed the following:
- Conan 1 install always uses the **current working directory** as default install and output folder unless instructed otherwise via `-if` or `-of`
- Conan 2 install always uses the **directory of the conanfile** as default output folder unless instructed otherwise via `-of`
- If a layout method is specified, Conan 1 and 2 create a subdirectory structure in the output folder which is used as a base folder for the updated generators like CMakeDeps for example but not the legacy ones
- Recipes can further configure the subdirectory structure inside the output folder by adding build folder vars which can make the build folder dependent on the settings

Our CI pipeline traditionally uses the local build workflow because we wanted to avoid unnecessary copying of binaries and resources, e.g. for executing the unit test binaries. When using `conan create` these would live in the cache, so we'd have to either deploy artifacts (copy) or directly run from the cache which is not a good idea in Conan 1 because the cache structure is not guaranteed to be stable.

So now with the migration to Conan 2 we're facing the question how to handle this. I want to encourage users to already define a `layout()` method, but by doing this I would break the pipelines because the files are now in a new subtree which might also be settings-specific. Since users can pick any layout for their recipes I cannot reliably deduce the subdirectory structure in the pipeline.

This leads to two different questions:
1. How to achieve Conan 1 backwards compatibility of new `layout()` methods. It should be possible to disable impact of the layout method on the output folder structure. Is there a way to do this other than adding a Conan version dependency in the layout method?
2. What is the recommended CI strategy for Conan 2? We'd really like to switch to a `conan create` approach, but we want to avoid having to copy files in CI or use deployers to access the files to pass between stages. Is it safe to directly grab things from the cache?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jasal82
issue_15515: state: open
title: [bug] Investigate problems login with CONAN_LOGIN_... environment variables
body: Coming from here: https://github.com/conan-io/conan/pull/15388#event-11583234359

That PR only fixed one part:

Trying to fix the ci for artifactory custom command in conan-extensions I found out that the authentication for certain commands is not managed correctly when using environment variables with the remote names in the end like CONAN_LOGIN_USERNAME_EXTENSIONS_PROD. This changes the environment variable management in conan auth but the problem is not solved with this. I still need to investigate it more in deep, leaving this PR here so we don't forget.

I had to change to conan remote login: https://github.com/conan-io/conan-extensions/pull/95#discussion_r1441675667

user: czoido
issue_15512: state: open
title: [bug] Cross building libcurl fails to find OpenSSL
body: ### Environment details

* Operating System+version: Debian 12 (in Docker container)
* Compiler+version: arm-linux-gnueabi-gcc-12 12.2.0-14 (with accompanying g++ and ld)
* Conan version: 2.0.17
* Python version: 3.11.7

### Steps to reproduce

1. Include "libcurl" (version 8.2.0, I've tested others with same result) with OpenSSL (version 3.2.0) in program and try to compile.
2. Compile for default host, which works without problems.
3. Create a separate host profile and try to compile for "armv7" (or v6 or whatever, seems to be same error with anything except default profile).
4. During compilation of "libcurl", it will fail with the mssage "configure: error: --with-openssl was given but OpenSSL could not be detected".

Having a look at the config.log for libcurl (attached) it show that it's looking for OpenSSL within the "/MQTTManager/conan_cache/b/opens43f9edc23fb23/p"-directory, which contains the following:
```
ls -l /MQTTManager/conan_cache/b/opens43f9edc23fb23/p/:
total 16
drwxr-xr-x 2 root root   37 Jan 23 20:20 bin
-rw-r--r-- 1 root root  985 Jan 23 20:20 conaninfo.txt
-rw-r--r-- 1 root root 8777 Jan 23 20:20 conanmanifest.txt
drwxr-xr-x 3 root root   21 Jan 23 20:20 include
drwxr-xr-x 5 root root   91 Jan 23 20:20 lib
drwxr-xr-x 3 root root   41 Jan 23 20:20 licenses


ls -l /MQTTManager/conan_cache/b/opens43f9edc23fb23/p/lib/:
total 21928
drwxr-xr-x 2 root root       52 Jan 23 20:20 cmake
drwxr-xr-x 2 root root        6 Jan 23 20:20 engines-3
-rw-r--r-- 1 root root 17325270 Jan 23 20:20 libcrypto.a
-rw-r--r-- 1 root root  5127166 Jan 23 20:20 libssl.a
drwxr-xr-x 2 root root       38 Jan 23 20:20 ossl-modules
```

To me it seems the environment is set up correctly with variables and the library files for OpenSSL does exist the the directory. It just seems that libcurl isn't finding them though I'm no expert on this.

To fully reproduce this with full code and setup, download the git repo https://github.com/NSPManager/NSPanelManager/tree/2ec12d35a81ce2365cb285973c09b98b8580570f and cd into the "docker" directory. Run the `docker-build_and_run_dev.sh`-script which will create the container and place you on a shell in it. Run `cd /MQTTManager` to get to the directory from where conan is being used. There exists a helper script called "compile_mqttmanager.sh" which will run everything to set it up for compilation. Given no argument, "compile_mqttmanager.sh" will build for the default profile, to cross build run it like `./compile_mqttmanager.sh armv7`.

Conanfile.py:
```
from conan import ConanFile


class CompressorRecipe(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    generators = "CMakeToolchain", "CMakeDeps"

    def requirements(self):
        self.requires("zlib/1.3", override=True)
        self.requires("paho-mqtt-cpp/1.2.0")
        self.requires("spdlog/1.12.0")
        self.requires("libcurl/8.5.0")
        self.requires("nlohmann_json/3.11.3")
        self.requires("ixwebsocket/11.4.3")
        self.requires("tz/2023c")
        self.requires("inja/3.4.0")
        self.requires("boost/1.83.0")

    def build_requirements(self):
        self.tool_requires("cmake/3.22.6")

    def configure(self):
        self.options["boost"].without_stacktrace = False
        self.options["boost"].with_stacktrace_backtrace = True
```

### Logs

relevant section from config.log for libcurl:

configure:26930: result: no
configure:26933: checking OpenSSL linking with -ldl and -lpthread
configure:26951: arm-linux-gnueabi-gcc-12 -o conftest -fPIC -g -Werror-implicit-function-declaration -g -O0 -pedantic -Wall -W -Wpointer-arith -Wwrite-strings -Wunused -Wshadow -Winline -Wnested-externs -Wmissing-declarations -Wmissing-prototypes -Wno-long-long -Wbad-function-cast -Wfloat-equal -Wno-multichar -Wsign-compare -Wundef -Wno-format-nonliteral -Wendif-labels -Wstrict-prototypes -Wdeclaration-after-statement -Wold-style-definition -Wstrict-aliasing=3 -Wattributes -Wdiv-by-zero -Wformat-security -Wmissing-field-initializers -Wmissing-noreturn -Wunreachable-code -Wunused-parameter -Wpragmas -Wredundant-decls -Wcast-align -Waddress -Wtype-limits -Wold-style-declaration -Wmissing-parameter-type -Wempty-body -Wclobbered -Wignored-qualifiers -Wconversion -Wno-sign-conversion -Wvla -ftree-vrp -Wdouble-promotion -Wformat=2 -Warray-bounds=2 -Wshift-negative-value -Wshift-overflow=2 -Wnull-dereference -fdelete-null-pointer-checks -Wduplicated-cond -Wunused-const-variable -Wduplicated-branches -Wrestrict -Walloc-zero -Wformat-overflow=2 -Wformat-truncation=2 -Warith-conversion -Wenum-conversion -Wno-system-headers -I/MQTTManager/conan_cache/b/opens43f9edc23fb23/p/include -I/MQTTManager/conan_cache/b/zlibd743f73676975/p/include -I/MQTTManager/conan_cache/b/zlibd743f73676975/p/include -I/MQTTManager/conan_cache/b/opens43f9edc23fb23/p/include  -L/MQTTManager/conan_cache/b/opens43f9edc23fb23/p/lib -L/MQTTManager/conan_cache/b/zlibd743f73676975/p/lib -L/MQTTManager/conan_cache/b/zlibd743f73676975/p/lib -L/MQTTManager/conan_cache/b/opens43f9edc23fb23/p/lib conftest.c -lcrypto -lz   -lssl -lcrypto -lz -ldl -lpthread -lrt -ldl -lpthread >&5
/usr/lib/gcc-cross/arm-linux-gnueabi/12/../../../../arm-linux-gnueabi/bin/ld: /MQTTManager/conan_cache/b/opens43f9edc23fb23/p/lib/libcrypto.a(libcrypto-lib-threads_pthread.o): in function `CRYPTO_atomic_or':
/MQTTManager/conan_cache/b/opens43f9edc23fb23/b/src/crypto/threads_pthread.c:227: undefined reference to `__atomic_is_lock_free'
/usr/lib/gcc-cross/arm-linux-gnueabi/12/../../../../arm-linux-gnueabi/bin/ld: /MQTTManager/conan_cache/b/opens43f9edc23fb23/b/src/crypto/threads_pthread.c:228: undefined reference to `__atomic_fetch_or_8'
/usr/lib/gcc-cross/arm-linux-gnueabi/12/../../../../arm-linux-gnueabi/bin/ld: /MQTTManager/conan_cache/b/opens43f9edc23fb23/p/lib/libcrypto.a(libcrypto-lib-threads_pthread.o): in function `CRYPTO_atomic_load':
/MQTTManager/conan_cache/b/opens43f9edc23fb23/b/src/crypto/threads_pthread.c:252: undefined reference to `__atomic_is_lock_free'
/usr/lib/gcc-cross/arm-linux-gnueabi/12/../../../../arm-linux-gnueabi/bin/ld: /MQTTManager/conan_cache/b/opens43f9edc23fb23/b/src/crypto/threads_pthread.c:253: undefined reference to `__atomic_load_8'
collect2: error: ld returned 1 exit status
configure:26951: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "curl"
| #define PACKAGE_TARNAME "curl"
| #define PACKAGE_VERSION "-"
| #define PACKAGE_STRING "curl -"
| #define PACKAGE_BUGREPORT "a suitable curl mailing list: https://curl.se/mail/"
| #define PACKAGE_URL ""
| #define DEBUGBUILD 1
| #define CURLDEBUG 1
| #define HAVE_STDIO_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_UNISTD_H 1
| #define STDC_HEADERS 1
| #define HAVE_STDATOMIC_H 1
| #define HAVE_ATOMIC 1
| #define PACKAGE "curl"
| #define VERSION "-"
| #define OS "arm-unknown-linux-gnueabi"
| #define _FILE_OFFSET_BITS 64
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define CURL_DISABLE_LDAP 1
| #define CURL_DISABLE_LDAPS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_CLOCK_GETTIME_MONOTONIC 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_CLOCK_GETTIME_MONOTONIC_RAW 1
| #define HAVE_LIBZ 1
| #define ENABLE_IPV6 1
| #define HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID 1
| /* end confdefs.h.  */
| 
| 
|            #include <openssl/err.h>
| 
| int main (void)
| {
| 
|            ERR_clear_error();
| 
|  ;
|  return 0;
| }
configure:26960: result: no
configure:27331: OPT_OPENSSL: /MQTTManager/conan_cache/b/opens43f9edc23fb23/p
configure:27333: OPENSSL_ENABLED: 
configure:27335: error: --with-openssl was given but OpenSSL could not be detected
user: tpanajott
issue_15503: state: open
title: Add Fish support for environments
body: Changelog: Feature: Add Fish shell command support for environments
Docs: TODO

Tests missing for now, but after like a year when I first had the idea, I finally did it.

Still need to check if the `-g` scope for the variable erasure is ok, and how activating both `:powershell` and `:fish` confs work

user: RubenRBS
issue_15500: state: open
title: tools.env.virtualenv:auto_use missing from conan config list
body: unable to build package due to tools.env.virtualenv:auto_use missing from conan config list
[conan issue.txt](https://github.com/conan-io/conan/files/14016513/conan.issue.tx

is there somekind of solution to this


user: seriousfreedom
issue_15498: state: open
title: [question] How to handle source() in local build workflow
body: ### What is your question?

I've run into a problem with the Conan 2.0 migration. Most of our Conan packages adhere to the "conanfile in source repository" pattern. The current CI pipeline uses the local build workflow (for different reasons), and it also unconditionally runs `conan source`, because some third-party packages required it and our own packages used the `scm` attribute, so they didn't care. Now I tried to replace `scm` with the `export()`/`source()` pattern as described in the migration guide, but this fails in the local build workflow because `source()` cannot checkout the sources (we're using the local workflow and obviously `export()` was never run, so there's no conan_data).

What is the correct way to handle this? Should I detect the local build workflow context somehow and skip the `source()` step? I tried to enclose the clone block in `if self.recipe_folder != self.source_folder`, but it seems that Conan 1.x calls `export()` as part of the `conan source` command which makes the export fail in local builds where the repository is not pristine (which happens all the time during local development). Is there a new pattern for local build workflow that I missed in the documentation?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jasal82
issue_15494: state: open
title: [technical debt] Review the flow after using the `get_apple_sdk_fullname` helper
body: Using this reads weird:
- The ``get_apple_sdk_fullname`` returns a value with the sdk+sdk_version.
- But then, later, this value is passed to ``apple_min_version_flag()`` which requires the sdk_version separately, ignores the value in the ``os_sdk`` and use the ``os.version`` instead.

The whole flow is confusing (it is not because of this PR, it was already confusing)

_Originally posted by @memsharded in https://github.com/conan-io/conan/pull/15465#discussion_r1461171949_
            
user: franramirez688
issue_15490: state: open
title: [question] Access host & target OSs in generate method
body: ### What is your question?

Hello,

I am building a project which contains both .NET & C++ code. For the .NET parts, I am using commands in cmake, such as `dotnet build` and `dotnet publish`.

However, some of the .NET executables need to be built for a target OS, while some others should be built for the "building" OS. Fortunately, conan holds the `host` and `build` OSs info in the matching profiles.

For now, I do something like this:

```python
def generate(self):
	tc = CMakeToolchain(self)
	if self.settings.os == "Windows":
		tc.cache_variables["DOTNET_TARGET_OS"] = "win"
	elif self.settings.os == "Linux":
		tc.cache_variables["DOTNET_TARGET_OS"] = "linux"
	elif self.settings.os == "Macos":
		tc.cache_variables["DOTNET_TARGET_OS"] = "osx"
	tc.generate()
	d = CMakeDeps(self)
	d.generate()
```

But it looks like `self.settings.os`'s content depends on the order of the profiles passed through the CLI. Would it be possible to access the host & build profiles info in order to fill in other variables that would depend specifically on one of these? Something like:

```python
def generate(self):
	tc = CMakeToolchain(self)
	if self.host.settings.os == "Windows":
		tc.cache_variables["DOTNET_TARGET_OS"] = "win"
	elif self.host.settings.os == "Linux":
		tc.cache_variables["DOTNET_TARGET_OS"] = "linux"
	elif self.host.settings.os == "Macos":
		tc.cache_variables["DOTNET_TARGET_OS"] = "osx"
	tc.generate()
	if self.build.settings.os == "Windows":
		tc.cache_variables["DOTNET_BUILD_OS"] = "win"
	elif self.build.settings.os == "Linux":
		tc.cache_variables["DOTNET_BUILD_OS"] = "linux"
	elif self.build.settings.os == "Macos":
		tc.cache_variables["DOTNET_BUILD_OS"] = "osx"
	tc.generate()
	d = CMakeDeps(self)
	d.generate()
```

Thanks in advance

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Todiq
issue_15486: state: open
title: Support AutoTools CC_FOR_BUILD variable
body: ### What is your suggestion?

Hello
Conan 2.0.16

I am cross building various packages.
I have both a build profile and host profile which both has tool_requires to their respective toolchain packages.
These toolchain packages define (among other things) `tools.build:compiler_executables`.
This works well in many cases.
But sometimes I come across packages that build with autotools and uses the `CC_FOR_BUILD` variable to find the compiler for the build host. These packages always find my system installed `gcc`. I do not want that.

I suggest that if I have a build profile that define `tools.build:compiler_executables` in the build context then AutoToolsToolchain should define the `CC_FOR_BUILD` variable to point to the compiler here.

Regards
Klaus

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: klausholstjacobsen
issue_15480: state: open
title: Force a recipe file to always run no matter if there is a current version in cache
body: ### What is your question?

When running conan create on a recipe file is there a way to make it always rerun even though it may exist in conan cache. The build_policy does not seem to have an option of "always"

We have a recipe file that autogenerates a source file with a build id that consist of a timestamp and other data and need it to recompile the source file everytime conan create is used on the recipe file.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: Ed-CMI
issue_15477: state: open
title: ERROR: Version conflict: qt/6.4.1->zlib/1.2.13, None->zlib/1.3.
body: ### What is your question?

conan 2.0.4
ubuntu 22

conanfile.txt

```
[requires]
zlib/[>=1.2.13]
freetype/[>=2.13.2]
qt/6.4.1
libffi/3.4.4
brotli/1.1.0

[generators]
CMakeDeps


```
error:
```shell
Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux


======== Computing dependency graph ========
Graph root
    conanfile.txt: /workspaces/myqt6app/conanfile.txt
Requirements
    brotli/1.1.0#d56d7bb9ca722942aba17369cb5c0519 - Cache
    bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4 - Cache
    freetype/2.13.2#c9ee90dc6f88356febac6fcdba0b2249 - Cache
    libpng/1.6.40#0337b7b87ac125307ed70fd064c31eea - Cache
    qt/6.4.1#37219eaac385e2969ded4b47563c71c2 - Cache
    zlib/1.3#06023034579559bb64357db3a53f88a4 - Cache
Resolved version ranges
    freetype/[>=2.13.2]: freetype/2.13.2
    zlib/[>=1.2.13]: zlib/1.3
ERROR: Version conflict: qt/6.4.1->zlib/1.2.13, None->zlib/1.3.
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: edidada
issue_15472: state: open
title: [question] Meaning of "skip: True" in "conan graph" output
body: ### What is your question?

I'm using Conan v2.0.17 `graph` command to load dependency information into external SCA tool. I've been using the `-c tools.build:download_source=True` argument to force downloading of all sources, which I then pass to SCA tool to do it's job.

However, after (I presume) a recent update of one of the direct dependencies above process broke down because one of the transitive dependency's sources are no longer being downloaded.

Here's the command(s) I've been running and the outputs I'm getting (pay attention to the `jinja2cpp` (direct dep) and `rapidjson` (transitive)):
```
$ conan graph info -pr:b src/conan-el9.profile -pr:h src/conan-el9.profile src -c tools.build:download_source=True

======== Computing dependency graph ========
Graph root
    conanfile.py (zroute/None): /data/work/git/myapp/src/conanfile.py
Requirements
    boost/1.83.0#658a6b1d7aa62a019cbba3f4ae363cb7 - Cache
    c-ares/1.22.1#d030cc7e14b2ebd4d351446ae158488a - Cache
    cctz/2.3#567ed7e4ca84e5380d816228c996e41d - Cache
    cpr/1.9.3#9f5c70878c93ce833074e9d31ff0dd96 - Cache
    expected-lite/0.6.3#262026767cf9d5ab1fdccb25c9bdbac2 - Cache
    fmt/10.2.0#43aafa5364c2359fc45be77d2587ab15 - Cache
    jinja2cpp/1.2.1#643e50d77dfadb2102ae27b9bc3ef60c - Cache
    json-schema-validator/2.1.0#105bcac54ce761c10bce5a1779359e51 - Cache
    libcurl/8.5.0#4fc73f2d68bae7c25d11a8b21d52233d - Cache
    nlohmann_json/3.11.2#1ded6ae5d200a68ac17c51d528b945e2 - Cache
    oatpp/1.3.0#845d8538ed10c5a2d742a87056150e95 - Cache
    openssl/3.2.0#d81e0a8c08372368fe7cb757280e2196 - Cache
    optional-lite/3.5.0#c5c705364f2036db5a3271c9e87e9ab9 - Cache
    rapidjson/cci.20220822#1b9d8c2256876a154172dc5cfbe447c6 - Cache
    string-view-lite/1.7.0#b58c5ddb877597aea1cdf09a9e4f2656 - Cache
    tree-sitter/0.17.3#a6ad43e0c312244858a8af2e9766a5c3 - Cache
    variant-lite/2.0.0#780ff2755d9b871f363162878f2f2e6d - Cache
    xerces-c/3.2.3#5ccde60faff0750c2830568c5526bfe9 - Cache
    zlib/1.2.13#97d5730b529b4224045fe7090592d4c1 - Cache
Test requirements
    catch2/2.13.10#d8541ec3a7e1236ecc46a5952896969e - Cache
    trompeloeil/43#1e21eef8dbb3a6710bcbdad6409c0f05 - Cache
Build requirements
    autoconf/2.71#53be95d228b2dcb30dc199cb84262d8f - Cache
    automake/1.16.5#058bda3e21c36c9aa8425daf3c1faf50 - Cache
    b2/4.10.1#1b290403d8648c79f468f5a6496f829a - Cache
    gnu-config/cci.20210814#dc430d754f465e8c74463019672fb97b - Cache
    libtool/2.4.7#08316dad5c72c541ed21e039e4cf217b - Cache
    m4/1.4.19#b38ced39a01e31fef5435bc634461fd2 - Cache
    meson/1.2.2#aace9dcc1db58fa42ecb5292f724092d - Cache
    ninja/1.11.1#77587f8c8318662ac8e5a7867eb4be21 - Cache
    pkgconf/2.1.0#27f44583701117b571307cf5b5fe5605 - Cache
Resolved version ranges
    libcurl/[>=7.78.0 <9]: libcurl/8.5.0
    openssl/[>=1.1 <4]: openssl/3.2.0
Overrides
    nlohmann_json/3.11.2#1ded6ae5d200a68ac17c51d528b945e2: ['nlohmann_json/3.11.2#1ded6ae5d200a68ac17c51d528b945e2', None]
    nlohmann_json/3.10.5: ['nlohmann_json/3.11.2']

======== Computing necessary packages ========
...
jinja2cpp/1.2.1: Checking 7 compatible configurations
jinja2cpp/1.2.1: Compatible configurations not found in cache, checking servers
jinja2cpp/1.2.1: '55b54255c7f44b0216d6a848fd5a9438d0e636a0': compiler.cppstd=14
jinja2cpp/1.2.1: 'c4f9d70bf105fea2232707734396836202680a33': compiler.cppstd=gnu14
jinja2cpp/1.2.1: '62e3da0592c8a5c2bee3b1b6d5d573dc994d4cbe': compiler.cppstd=17
jinja2cpp/1.2.1: 'f5b1570789848ea796321bc2a4fdc9d09de5cf52': compiler.cppstd=20
jinja2cpp/1.2.1: '5b568eff1a348163f177098fca54614369881f75': compiler.cppstd=gnu20
jinja2cpp/1.2.1: '2518dc757376d921dca1114c1f811cfc5c5b5cd1': compiler.cppstd=23
jinja2cpp/1.2.1: '6fd06c0eb00e0ea8b3fa9275582d7468114e7a86': compiler.cppstd=gnu23
...
Requirements
    boost/1.83.0#658a6b1d7aa62a019cbba3f4ae363cb7:e000b98e46184bbda2ac5c1ec704c5ee13f39906 - Missing
    c-ares/1.22.1#d030cc7e14b2ebd4d351446ae158488a:e3c52a2f5bd5dc2a32df2d25f9f70a04cfd7bea3#adc9883e02a821bc501f765c0ba17388 - Download (conancenter)
    cctz/2.3#567ed7e4ca84e5380d816228c996e41d:53939a69492e42ec7a5c29c2c5dee0ee9a58fe05#79c81c823fbd2b9325b0ccfd475eb0c3 - Download (conancenter)
    cpr/1.9.3#9f5c70878c93ce833074e9d31ff0dd96:f589dccdc84b6d257a402da892773367d2bf99f3 - Missing
    expected-lite/0.6.3#262026767cf9d5ab1fdccb25c9bdbac2:da39a3ee5e6b4b0d3255bfef95601890afd80709#beb7503b67488b722e231f67855dbbf6 - Download (conancenter)
    fmt/10.2.0#43aafa5364c2359fc45be77d2587ab15:ab63c9a7d02c6c3c8452b305f3a53c2446c7322d#d02ceed90a12df85e5eed5dae4019904 - Download (conancenter)
    jinja2cpp/1.2.1#643e50d77dfadb2102ae27b9bc3ef60c:0a20ff0a0fe284b5f2877e666f334f3611bfe68e - Missing
    json-schema-validator/2.1.0#105bcac54ce761c10bce5a1779359e51:9cba398f441678f096be93941431e0b6c4a5f0a4 - Missing
    libcurl/8.5.0#4fc73f2d68bae7c25d11a8b21d52233d:ff3b6bf68ed1ab590223bd337df09d9022c1b694 - Missing
    nlohmann_json/3.11.2#1ded6ae5d200a68ac17c51d528b945e2:da39a3ee5e6b4b0d3255bfef95601890afd80709#2d1a5b1f5d673e1dab536bed20ce000b - Download (conancenter)
    oatpp/1.3.0#845d8538ed10c5a2d742a87056150e95:13be611585c95453f1cbbd053cea04b3e64470ca#ef61ae99aaa4072f45e5ff01f67389c3 - Download (conancenter)
    openssl/3.2.0#d81e0a8c08372368fe7cb757280e2196:517a2f66278c9fbeb4bb0b64fc531fe112929bc9 - Missing
    optional-lite/3.5.0#c5c705364f2036db5a3271c9e87e9ab9:da39a3ee5e6b4b0d3255bfef95601890afd80709#caf9c39526bde4f9b7a724eed9125966 - Download (conancenter)
    string-view-lite/1.7.0#b58c5ddb877597aea1cdf09a9e4f2656:da39a3ee5e6b4b0d3255bfef95601890afd80709#fbd15e2b6dc28e7d39cca01a8a299135 - Download (conancenter)
    tree-sitter/0.17.3#a6ad43e0c312244858a8af2e9766a5c3:b647c43bfefae3f830561ca202b6cfd935b56205#5d3aa51cf09f937941a5549f3b2382ae - Download (conancenter)
    variant-lite/2.0.0#780ff2755d9b871f363162878f2f2e6d:da39a3ee5e6b4b0d3255bfef95601890afd80709#92a9db7116ed47cbcc5951285ddcd4ab - Download (conancenter)
    xerces-c/3.2.3#5ccde60faff0750c2830568c5526bfe9:ca6cd8782efa45a0b0eb714f69f327b26c26a578#ab42fcb4db53f38f9528180f63104969 - Download (conancenter)
    zlib/1.2.13#97d5730b529b4224045fe7090592d4c1:b647c43bfefae3f830561ca202b6cfd935b56205#193bca86926abaf79971c774228e6249 - Download (conancenter)
Test requirements
    catch2/2.13.10#d8541ec3a7e1236ecc46a5952896969e:da39a3ee5e6b4b0d3255bfef95601890afd80709#d747b95b8e7ed466e354429ffd7f048f - Download (conancenter)
    trompeloeil/43#1e21eef8dbb3a6710bcbdad6409c0f05:da39a3ee5e6b4b0d3255bfef95601890afd80709#389432b631b3ca92bc47c1d670fbab3f - Download (conancenter)
Build requirements
Skipped binaries
    rapidjson/cci.20220822, autoconf/2.71, automake/1.16.5, b2/4.10.1, gnu-config/cci.20210814, libtool/2.4.7, m4/1.4.19, meson/1.2.2, ninja/1.11.1, pkgconf/2.1.0
```

And now the actual graph information:
```
======== Basic graph information ========
zroute/None:
  ref: myapp/None
  id: 0
  recipe: Consumer
  package_id: 9af1aba8641972472157f339a7c4190fa190cb5f
  prev: None
  rrev: None
  rrev_timestamp: None
  prev_timestamp: None
  remote: None
  binary_remote: None
  build_id: None
  binary: None
  invalid_build: False
  info_invalid: None
  name: zroute
  user: None
  channel: None
  url: https://github.com/myapp
  license: Copyright (c) 2018-2025 Myapp
  author: None
  description: Myapp
  homepage: None
  build_policy: None
  upload_policy: None
  revision_mode: hash
  provides: None
  deprecated: None
  win_bash: None
  win_bash_run: None
  default_options:
    shared: False
    fPIC: True
    libcurl/*:with_c_ares: True
    boost/*:pch: False
    boost/*:without_filesystem: False
    boost/*:without_atomic: False
    boost/*:without_system: False
    boost/*:without_chrono: True
    boost/*:without_container: True
    boost/*:without_context: True
    boost/*:without_contract: True
    boost/*:without_coroutine: True
    boost/*:without_exception: True
    boost/*:without_fiber: True
    boost/*:without_graph: True
    boost/*:without_graph_parallel: True
    boost/*:without_iostreams: True
    boost/*:without_json: True
    boost/*:without_locale: True
    boost/*:without_log: True
    boost/*:without_math: True
    boost/*:without_mpi: True
    boost/*:without_nowide: True
    boost/*:without_program_options: True
    boost/*:without_python: True
    boost/*:without_random: True
    boost/*:without_regex: True
    boost/*:without_serialization: True
    boost/*:without_stacktrace: True
    boost/*:without_test: True
    boost/*:without_thread: True
    boost/*:without_timer: True
    boost/*:without_type_erasure: True
    boost/*:without_wave: True
  options_description: None
  version: None
  topics: None
  package_type: static-library
  settings:
    os: Linux
    arch: x86_64
    compiler: gcc
    compiler.cppstd: gnu17
    compiler.libcxx: libstdc++11
    compiler.version: 11
    build_type: Release
  options:
    fPIC: True
    shared: False
  options_definitions:
    shared: ['True', 'False']
    fPIC: ['True', 'False']
  generators: []
  python_requires: None
  system_requires:
  recipe_folder: /data/work/git/myapp/src
  source_folder: None
  build_folder: None
  generators_folder: None
  package_folder: None
  cpp_info:
    root:
      includedirs: ['include']
      srcdirs: None
      libdirs: ['lib']
      resdirs: None
      bindirs: ['bin']
      builddirs: None
      frameworkdirs: None
      system_libs: None
      frameworks: None
      libs: None
      defines: None
      cflags: None
      cxxflags: None
      sharedlinkflags: None
      exelinkflags: None
      objects: None
      sysroot: None
      requires: None
      properties: None
  conf_info:
  label: conanfile.py (myapp/None)
  dependencies:
    ...
    30:
      ref: jinja2cpp/1.2.1
      run: False
      libs: True
      skip: False
      test: False
      force: False
      direct: True
      build: False
      transitive_headers: None
      transitive_libs: None
      headers: True
      package_id_mode: minor_mode
      visible: True
    ...
    33:
      ref: rapidjson/cci.20220822
      run: False
      libs: False
      skip: True
      test: False
      force: False
      direct: False
      build: False
      transitive_headers: None
      transitive_libs: None
      headers: False
      package_id_mode: None
      visible: True
    ...
  context: host
  test: False
jinja2cpp/1.2.1#643e50d77dfadb2102ae27b9bc3ef60c:
  ref: jinja2cpp/1.2.1#643e50d77dfadb2102ae27b9bc3ef60c
  id: 30
  recipe: Cache
  package_id: 0a20ff0a0fe284b5f2877e666f334f3611bfe68e
  prev: None
  rrev: 643e50d77dfadb2102ae27b9bc3ef60c
  rrev_timestamp: 1704192585.914
  prev_timestamp: None
  remote: None
  binary_remote: None
  build_id: None
  binary: Missing
  invalid_build: False
  info_invalid: None
  name: jinja2cpp
  user: None
  channel: None
  url: https://github.com/conan-io/conan-center-index
  license: MIT
  author: None
  description: Jinja2 C++ (and for C++) almost full-conformance template engine implementation
  homepage: https://jinja2cpp.dev/
  build_policy: None
  upload_policy: None
  revision_mode: hash
  provides: None
  deprecated: None
  win_bash: None
  win_bash_run: None
  default_options:
    shared: False
    fPIC: True
  options_description: None
  version: 1.2.1
  topics: ['cpp14', 'cpp17', 'jinja2', 'string templates', 'templates engine']
  package_type: static-library
  settings:
    os: Linux
    arch: x86_64
    compiler: gcc
    compiler.cppstd: gnu17
    compiler.libcxx: libstdc++11
    compiler.version: 11
    build_type: Release
  options:
    fPIC: True
    shared: False
  options_definitions:
    shared: ['True', 'False']
    fPIC: ['True', 'False']
  generators: []
  python_requires: None
  system_requires:
  recipe_folder: /home/devenv/.conan2/p/jinjacf87cca18d2bc/e
  source_folder: /home/devenv/.conan2/p/jinjacf87cca18d2bc/s/src
  build_folder: None
  generators_folder: None
  package_folder: None
  cpp_info:
    root:
      includedirs: ['include']
      srcdirs: None
      libdirs: ['lib']
      resdirs: None
      bindirs: ['bin']
      builddirs: None
      frameworkdirs: None
      system_libs: None
      frameworks: None
      libs: None
      defines: None
      cflags: None
      cxxflags: None
      sharedlinkflags: None
      exelinkflags: None
      objects: None
      sysroot: None
      requires: None
      properties: None
  conf_info:
  label: jinja2cpp/1.2.1
  dependencies:
    ...
    33:
      ref: rapidjson/cci.20220822
      run: False
      libs: False
      skip: False
      test: False
      force: False
      direct: True
      build: False
      transitive_headers: None
      transitive_libs: None
      headers: True
      package_id_mode: minor_mode
      visible: True
    ...
  context: host
  test: False
rapidjson/cci.20220822#1b9d8c2256876a154172dc5cfbe447c6:
  ref: rapidjson/cci.20220822#1b9d8c2256876a154172dc5cfbe447c6
  id: 33
  recipe: Cache
  package_id: da39a3ee5e6b4b0d3255bfef95601890afd80709
  prev: a99fd0306f219909b3c1b1059abc47e9
  rrev: 1b9d8c2256876a154172dc5cfbe447c6
  rrev_timestamp: 1705070244.747
  prev_timestamp: 1705070466.44
  remote: None
  binary_remote: conancenter
  build_id: None
  binary: Skip
  invalid_build: False
  info_invalid: None
  name: rapidjson
  user: None
  channel: None
  url: https://github.com/conan-io/conan-center-index
  license: MIT
  author: None
  description: A fast JSON parser/generator for C++ with both SAX/DOM style API
  homepage: http://rapidjson.org
  build_policy: None
  upload_policy: None
  revision_mode: hash
  provides: None
  deprecated: None
  win_bash: None
  win_bash_run: None
  default_options: None
  options_description: None
  version: cci.20220822
  topics: ['rapidjson', 'json', 'parser', 'generator']
  package_type: header-library
  settings:
    os: Linux
    arch: x86_64
    compiler: gcc
    compiler.cppstd: gnu17
    compiler.libcxx: libstdc++11
    compiler.version: 11
    build_type: Release
  options:
  options_definitions:
  generators: []
  python_requires: None
  system_requires:
  recipe_folder: /home/devenv/.conan2/p/rapid67f21ae5216f9/e
  source_folder: None
  build_folder: None
  generators_folder: None
  package_folder: None
  cpp_info:
    root:
      includedirs: ['include']
      srcdirs: None
      libdirs: ['lib']
      resdirs: None
      bindirs: ['bin']
      builddirs: None
      frameworkdirs: None
      system_libs: None
      frameworks: None
      libs: None
      defines: None
      cflags: None
      cxxflags: None
      sharedlinkflags: None
      exelinkflags: None
      objects: None
      sysroot: None
      requires: None
      properties: None
  conf_info:
  label: rapidjson/cci.20220822
  dependencies:
  context: host
  test: False
```

The only thing that stands out to me is the `skip: True` in the global list of dependencies and `source_folder: None`. Can someone please explain to me what is actually happening here? Is `rapidjson` actually a transitive dependency or not? Why it's sources are not being downloaded unlike those of the rest of the dependencies?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: IvanRibakov
issue_15469: state: open
title: [question] Can I use other languages with Conan ?
body: ### What is your question?

Is it possible to use Conan 2.0 with other languages except C and C++ ?
In Conan 1.* python and go are mentioned, but in a new documentation there is nothing about it: https://docs.conan.io/1/howtos/other_languages_package_manager.html
I am wondering why ?
Thank you in advance for your answer. 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: emina-mirvic-bl
issue_15468: state: open
title: [question] Editable packages and public linked libraries
body: ### What is your question?

Following problem: I've got a project that pulls in some packages via Conan 2 and one single private package added via `editable add`, that also uses some packages. The reason for that private package being a Conan package is, that it seems to be the only option to have multiple `conanfile.txt`/`conanfile.py` files (FetchContent + conanfile.txt in the fetched project seems to be not an option).

I export multiple components from that package via:
```python
def package_info(self):
    self.cpp_info.components["c1"].includedirs = ["libs/service/include"]
    self.cpp_info.components["c1"].set_property("cmake_target_name", "mypkg::c1")
    ...
```

The `mypkg` has some `target_link_library(c1 PUBLIC lib-abc)`

Now, if I link to `mypkg::c1`, it seems the INCLUDE_DIRECTORIES property is not set correctly.
The consumer of `mypkg::c1` is unable to see where the public header files of `lib-abc` should come from. Am I doing something completely wrong? Are the target imported via `find_package(mypgk REQUIRED c1)` not the “real” CMake targets, but some targets generated by Conan? I already had to set the `includedirs` property, because the CMake's target properties were set to the Conan default of `include`.

How is it possible to have nested non-Conan projects/libs that each have their own conanfile.txt? A hack would be to scan for each `conanfile.txt` pre-build and merge them, but that won't work with `FetchContent` either… this is really frustrating, any ideas?

Note: I have no `install(...)` instructions in my `mypkg`'s CMake. Are they strictly needed?


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: johannes-wolf
issue_15452: state: open
title: [question] has anyone successfully configured msvc with ninja and cacche?
body: ### What is your question?

I have it mostly working.  vcvars are loading.  I set my windskver, but something isn't quite right because cl.exe by way of ccache is complaining about PDB file errors immediately.

This is the error I'm seeing...

```
FAILED: src/lib/CMakeFiles/c-ares.dir/ares__htable.c.obj
C:\ccache\cl.exe  /nologo -DCARES_STATICLIB -DHAVE_CONFIG_H=1 -DWIN32_LEAN_AND_MEAN -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_SECURE_NO_DEPRECATE -D_WIN32_WINNT=0x0602 -IC:\Users\tperr\.conan2\p\b\c-are55f61936c5eed\b\build\Debug -IC:\Users\tperr\.conan2\p\b\c-are55f61936c5eed\b\src -IC:\Users\tperr\.conan2\p\b\c-are55f61936c5eed\b\src\include -IC:\Users\tperr\.conan2\p\b\c-are55f61936c5eed\b\src\src\lib /FS /DWIN32 /D_WINDOWS /W3 /W3 /we4013 /Zi /Ob0 /Od /RTC1 -MDd /showIncludes /Fosrc\lib\CMakeFiles\c-ares.dir\ares__htable.c.obj /Fdbin\cares.pdb /FS -c C:\Users\tperr\.conan2\p\b\c-are55f61936c5eed\b\src\src\lib\ares__htable.c
C:\Users\tperr\.conan2\p\b\c-are55f61936c5eed\b\src\src\lib\ares__htable.c(388): fatal error C1090: PDB API call failed, error code '23': (0x00000006)
```

I tried setting various compiler flags like /Zf and the like, but I still keep getting this error.

This is my host profile.

```
[settings]
os=Windows
arch=x86_64
compiler=msvc
compiler.cppstd=14
compiler.version=193
compiler.update=9
compiler.toolset=v141_xp

compiler.cppstd=14
compiler.runtime=dynamic
build_type=Debug

[options]
verbose=True

[conf]
tools.build:compiler_executables = { "c" : "C:\ccache\cl.exe", "cpp": "C:\ccache\cl.exe" }
tools.build:cflags = [ "/FS" ]
tools.build:cxxflags = [ "/FS" ]

tools.microsoft:winsdk_version = 10.0.22621.0
tools.microsoft.msbuild:max_cpu_count = 4
tools.cmake.cmaketoolchain:generator=Ninja
```

Cmake is invoking ccache and ccache is calling the correct cl.exe from msvc, but nothing will build.



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: hoyhoy
issue_15451: state: open
title: [feature] Set linker paths
body: ### What is your suggestion?

I use both different versions of gcc and clang on my machine. For this i configured multiple profiles, specifying the compilers explicitly, for example:

```
[conf]
tools.build:compiler_executables={"cpp": "/usr/bin/clang++-15", "c": "/usr/bin/clang-15"}
```

However, I can't seem to configure linker settings. If I want to use either ld or lld how would I pass this information to cmake to link the default program? It would be nice to have a seperate option in [conf] to configure which linker is used (including path, not just setting the compiler flag).

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: MartyMcFlyInTheSky
issue_15448: state: open
title: Conan generators do not generate specific files
body: ### Conan generators do not generate specific files

Hi,

I am trying to create a package from pre-built binaries by following the doc [here](https://docs.conan.io/2/tutorial/creating_packages/other_types_of_packages/package_prebuilt_binaries.html).

I am able to create the package but when I install it using CMakeDeps generators, I do not get specific files that contain configs, path to include dir, etc. Is there anything additional that is required from what I have already done?

Below is my conan recipe:

```
from conan import ConanFile
from conan.tools.files import copy
import os
import shutil

class BoostRecipe(ConanFile):
    name = "boost"
    version = "1.71.0"

    # Optional metadata
    license = "xxx"
    author = "xxx"
    #url = "xxx"
    description = "C++ interface to the boost library."
    
    settings = "os", "compiler", "build_type", "arch"
    
    #exports_sources = "*.hpp", "*.lib"
    
    def layout(self):
        _os = str(self.settings.os).lower()
        _arch = str(self.settings.arch).lower()
        self.folders.build = os.path.join("win32-MSVC19")
        self.folders.source = self.folders.build
        self.cpp.source.includedirs = ["include"]
        self.cpp.build.libdirs = ["lib"]

        
    def package(self):
        local_include_folder = os.path.join(self.source_folder, self.cpp.source.includedirs[0])
        local_lib_folder = os.path.join(self.build_folder, self.cpp.build.libdirs[0])
        copy(self, "*.hpp", local_include_folder, os.path.join(self.package_folder), keep_path=True)
        copy(self, "*.lib", local_lib_folder, os.path.join(self.package_folder), keep_path=True)
        
    def package_info(self):
        self.cpp_info.libs = ["boost"]
```

and I run the command

`conan install . -g CMakeDeps -of "C:\generated\Debug"`

But I get only the below files.

![image](https://github.com/conan-io/conan/assets/143775835/522a2396-7603-4234-b3f2-56f59ebb2b91)


I am expecting something like below:

![image](https://github.com/conan-io/conan/assets/143775835/147b909c-9ca3-4153-9bb7-af602f45b0ef)




### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sandybhat16
issue_15445: state: open
title: [question] conan fetches the wrong binary package on remote jfrog artifact repo (missing package)
body: Hi everybody, I introduce to you a weird issue which is occurring on my GitHub runner.

Basically on a GitHub workflow I'm installing Python 3.11 and Conan 1.62.0, after the installation I call for the `conan install ...` command which downloads the dependencies from a Jfrog Artifactory remote (address specified in the remotes.txt).

Everything works at this point, what I'm trying to to do is to update the boost library from 1.77.0 to 1.82.0. For doing that I build the library locally through the terminal (using the _conanfile.txt_ as explained on [conan.io](https://conan.io/center)) and then upload with `conan upload boost/1.82.0@ -r <REMOTE> --all` command.

Now on the JFrog repository I have both 1.77.0 and 1.82.0 versions of boost, the last step before running the workflow is to update the requirements in the _conanfile.py_ with the newer version of the build.

I encounter the issue after I execute the workflow, what happens is that conan is searching the wrong hash package for boost/1.82.0.

Log:
```
ERROR: Missing binary: boost/1.82.0:cee4397e7ca7990a3e02337e3fe31839e6dee76c
Version ranges solved
boost/1.82.0: WARN: Can't find a 'boost/1.82.0' package for the specified settings, options and dependencies:
    zlib/* versions found in 'jfrog-repo' remote
    Version range '>=1.2.11 <2' required by 'boost/1.82.0' resolved to 'zlib/1.2.11' in remote 'jfrog-repo'
- Settings: arch=x86_64, build_type=MinSizeRel, compiler=apple-clang, compiler.cppstd=17, compiler.libcxx=libc++, compiler.version=14.0, os=Macos, os.version=10.13
- Options: addr2line_location=/usr/bin/addr2line, asio_no_deprecated=False, buildid=None, bzip2=True, debug_level=0, diagnostic_definitions=False, error_code_header_only=False, extra_b2_flags=None, fPIC=True, filesystem_no_deprecated=False, filesystem_use_std_fs=False, filesystem_version=None, header_only=False, i18n_backend=deprecated, i18n_backend_iconv=libiconv, i18n_backend_icu=False, layout=system, lzma=False, magic_autolink=False, multithreading=True, namespace=boost, namespace_alias=False, numa=True, pch=True, python_executable=None, python_version=None, segmented_stacks=False, shared=False, system_no_deprecated=False, system_use_utf8=False, visibility=hidden, with_stacktrace_backtrace=True, without_atomic=False, without_chrono=False, without_container=False, without_context=False, without_contract=False, without_coroutine=False, without_date_time=False, without_exception=False, without_fiber=False, without_filesystem=False, without_graph=False, without_graph_parallel=True, without_iostreams=False, without_json=False, without_locale=False, without_log=False, without_math=False, without_mpi=True, without_nowide=False, without_program_options=False, without_python=True, without_random=False, without_regex=False, without_serialization=False, without_stacktrace=False, without_system=False, without_test=False, without_thread=False, without_timer=False, without_type_erasure=False, without_url=False, without_wave=False, zlib=True, zstd=False, bzip2:build_executable=True, bzip2:fPIC=True, bzip2:shared=False, libbacktrace:fPIC=True, libbacktrace:shared=False, libiconv:fPIC=True, libiconv:shared=False, zlib:fPIC=True, zlib:shared=False

- Dependencies: zlib/1.2.11, bzip2/1.0.8, libbacktrace/cci.20210118, libiconv/1.17
conanfile.py: Installing package
- Requirements: bzip2/1.Y.Z, libbacktrace/cci.20210118, libiconv/1.Y.Z, zlib/1.Y.Z
Requirements
- Package ID: cee4397e7ca7990a3e02337e3fe31839e6dee76c

ERROR: Missing prebuilt package for 'boost/1.82.0'
Use 'conan search boost/1.82.0@ --table=table.html -r=remote' and open the table.html file to see available packages
Or try to build locally from sources with '--build=boost'

More Info at 'https://docs.conan.io/en/latest/faq/troubleshooting.html#error-missing-prebuilt-package'
    boost/1.82.0 from 'jfrog-repo' - Downloaded
    bzip2/1.0.8 from 'jfrog-repo' - Downloaded
    catch2/2.13.6 from 'jfrog-repo' - Downloaded
    fakeit/2.0.9 from 'jfrog-repo' - Downloaded
    fmt/7.1.3 from 'jfrog-repo' - Downloaded
    gsl-lite/0.38.1 from 'jfrog-repo' - Downloaded
    libbacktrace/cci.20210118 from 'jfrog-repo' - Downloaded
    libiconv/1.17 from 'jfrog-repo' - Downloaded
    magic_enum/0.7.3 from 'jfrog-repo' - Downloaded
    range-v3/0.5.0 from 'jfrog-repo' - Downloaded
    spdlog/1.8.5 from 'jfrog-repo' - Downloaded
    zlib/1.2.11 from 'jfrog-repo' - Downloaded
Packages
    boost/1.82.0:cee4397e7ca7990a3e02337e3fe31839e6dee76c - Missing
    bzip2/1.0.8:4dc82e4eb4df7e160d626d5cdd57f1018086c231 - Download
    catch2/2.13.6:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    fakeit/2.0.9:4cb1853ab00b982f8a7126b81a09a10e8ca6531d - Download
    fmt/7.1.3:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    gsl-lite/0.38.1:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    libbacktrace/cci.20210118:0e30462b8bcf39220bbcef8630a1cef905d8a6e3 - Download
    libiconv/1.17:0e30462b8bcf39220bbcef8630a1cef905d8a6e3 - Download
    magic_enum/0.7.3:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    range-v3/0.5.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    spdlog/1.8.5:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    zlib/1.2.11:0e30462b8bcf39220bbcef8630a1cef905d8a6e3 - Download
Build requirements
    cmake/3.22.0 from 'jfrog-repo' - Downloaded
    ninja/1.10.2 from 'jfrog-repo' - Downloaded
    openssl/1.1.1m from 'jfrog-repo' - Downloaded
Build requirements packages
    cmake/3.22.0:f09183e9842a6f79fe164e8fe55452241a8d38d0 - Download
    ninja/1.10.2:967bac59ecd57ec08857874a0d1fa21edb50c85e - Download
    openssl/1.1.1m:d67028d247526d6b44627ffb9518a2c2e68e2d63 - Download

Installing (downloading, building) binaries...

Error: Process completed with exit code 1.
```
Looking up on the repository I found that the hash `cee4397e7ca7990a3e02337e3fe31839e6dee76c` isn't the correct one, this hash is the one of a package of the previous library version, the actual one installed for the newer one is `dd7f5f958c7381cfd81e611a16062de0c827160a `.

<img width="484" alt="image" src="https://github.com/conan-io/conan/assets/1337959/988723a0-accd-4775-9659-50c8d0dcb007">

Actually there are two packages in the new version, while in the previous version of the library are eight.

This problem made me think about a caching issue, so I tried to change the cache key for conan, but this didn't change anything he always asks for that old hash and I can't figure out why.

I can show you also a piece of the workflow:
```yaml
- name: Cache conan packages
  uses: actions/cache@v3
  with:
    path: ~/.conan
    key: ${{ runner.os }}-conan-${{ hashFiles('code/conanfile.py', 'code/conan/config/profile/macos')}}

- name: Install conan
  run: |
    pip3 install --upgrade 'conan==1.60.2'
    echo "/home/runner/.local/bin" >> $GITHUB_PATH

- name: Configure conan, install or build dependencies for plugin and browser
  run: |
    mkdir -p build
    mkdir -p build_Browser
    cd build
    conan config install ../code/conan/config
    conan user -c
    conan user github --remote jfrog-repo --password "${{ secrets.CONAN_TOKEN_GITHUB }}"
    conan install ../code --profile macos --settings build_type=${{ env.BUILD_TYPE }}
    ... continues
```

I also tried using the `--update` flag on the `conan install ../code ...` command, but also this wasn't effective.

Do you have any idea why this is happening? I searched for days on internet but I didn't find anything similar to that.

Thank you in advance :)
user: manuelpagliuca
issue_15440: state: open
title: [bug] Invalid package folder when using editable package with library in subfolder
body: ### Environment details

* Operating System+version: Windows 10
* Compiler+version: MSVC 19.36.32535.0
* Conan version: 2.0.16
* Python version: 3.10.5


### Steps to reproduce

When trying to use a package installed in editable mode, if the package is organized as follows:

```
src/
    CMakeLists.txt
    library.cpp
include/
    library.h
CMakeLists.txt
conanfile.py
```

The library is not found when trying to use it. 

The issue is that the library is built at `build/src/Debug/library.lib` instead of `build/Debug/ilbrary.lib` so `library_LIB_DIRS_DEBUG` is incorrect in the generated `.cmake` file.

The following repository reproduces the issue: https://github.com/Holt59/conan-issue-15440 

```
conan add editable say
cd say
conan install . -s build_type=Debug
cmake --preset conan-default
cmake --build --preset conan-debug
cd ../hello
conan install . -s build_type=Debug
cmake --preset conan-default  # this fails
```

### Logs

_No response_
user: Holt59
issue_15438: state: open
title: [bug] Unable to compile with clang-cl
body: ### Environment details

* Operating System+version: Windows 11 23H2
* Compiler+version: Visual Studio 17.8.4
* Conan version: 2.0.16
* Python version: 3.12.0


### Steps to reproduce

Hello,

Here is my conan profile:

```txt
[settings]
arch={{detect_api.detect_arch()}}
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.version=193
os=Windows

&:build_type=Debug
&:compiler=clang
&:compiler.cppstd=17
&:compiler.version=16

[buildenv]
&:PATH=+(path)C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/Llvm/x64/bin/

[conf]
&:tools.build:compiler_executables={"cpp": "clang-cl"}
&:tools.build:cxxflags=["-fcolor-diagnostics", "-fansi-escape-codes"]
&:tools.build:exelinkflags=["-fuse-ld=lld"]
&:tools.build:sharedlinkflags=["-fuse-ld=lld"]
&:tools.build:skip_test=False
&:tools.env.virtualenv:powershell=True
&:tools.cmake.cmaketoolchain:generator=Ninja Multi-Config
```

Running `conan build .\core --profile:all "windows-clang-debug"` leads to the error underneath.

However, if I load vcvarsall before doing so, the build starts successully. I don't know if it by design, but it looks like conan does not load the Visual Studio Tools environment (or entirely). Thanks in advance for your time.

### Logs

``` powershell
======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows
&:build_type=Debug
&:compiler=clang
&:compiler.cppstd=17
&:compiler.version=16
[conf]
&:tools.build:compiler_executables={'cpp': 'clang-cl'}
&:tools.build:cxxflags=['-fcolor-diagnostics', '-fansi-escape-codes']
&:tools.build:exelinkflags=['-fuse-ld=lld']
&:tools.build:sharedlinkflags=['-fuse-ld=lld']
&:tools.build:skip_test=False
&:tools.env.virtualenv:powershell=True
&:tools.cmake.cmaketoolchain:generator=Ninja Multi-Config
[buildenv]
&:PATH=+(path)C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/Llvm/x64/bin/

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows
&:build_type=Debug
&:compiler=clang
&:compiler.cppstd=17
&:compiler.version=16
[conf]
&:tools.build:compiler_executables={'cpp': 'clang-cl'}
&:tools.build:cxxflags=['-fcolor-diagnostics', '-fansi-escape-codes']
&:tools.build:exelinkflags=['-fuse-ld=lld']
&:tools.build:sharedlinkflags=['-fuse-ld=lld']
&:tools.build:skip_test=False
&:tools.env.virtualenv:powershell=True
&:tools.cmake.cmaketoolchain:generator=Ninja Multi-Config
[buildenv]
&:PATH=+(path)C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/Llvm/x64/bin/


======== Computing dependency graph ========
Graph root
    conanfile.py (castcore/1.1): E:\core\conanfile.py
Requirements
    boost/1.81.0#baee6ce59b430ac2b773acaab5a7c9e3 - Cache
    bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4 - Cache
    icu/72.1#d24b2d30acae3dcb788e139112bcd7c6 - Cache
    libiconv/1.17#9d9082101394d053c67e95d3bc9f1e78 - Cache
    libxml2/2.11.4#b8655993026040c384c5483673921ae4 - Cache
    libxslt/1.1.34#2bdc1f5fe5db1df40f8465e485a19ee4 - Cache
    pugixml/1.13#f615c1fcec55122b2e177d17061276e7 - Cache
    xerces-c/3.2.4#4dd6f8d2ced62cffea421ff28ee5856f - Cache
    zlib/1.3#06023034579559bb64357db3a53f88a4 - Cache
Test requirements
    gtest/1.13.0#8a0bc5b3e159ed45de97260c2bff65b5 - Cache
Build requirements
    b2/4.10.1#1b290403d8648c79f468f5a6496f829a - Cache
    msys2/cci.latest#5a31efa2bde593541fd5ac3bcc50c01c - Cache
Resolved version ranges
    zlib/[>=1.2.11 <2]: zlib/1.3
Overrides
    libxml2/2.11.6: ['libxml2/2.11.4']

======== Computing necessary packages ========
Requirements
    boost/1.81.0#baee6ce59b430ac2b773acaab5a7c9e3:7b33c6bc6df3617d1e12ec6d8366c7a14c56da98#042acaa0d4a69e12c947e40d1befaf3f - Cache
    icu/72.1#d24b2d30acae3dcb788e139112bcd7c6:9f8165f8d74e26bf104abb2a5005a80d1101b198#3cb5da99fe9d01c55d1c5dbf13f35112 - Cache
    libiconv/1.17#9d9082101394d053c67e95d3bc9f1e78:7bfde258ff4f62f75668d0896dbddedaa7480a0f#cd0141994b2858f29ba3ef038bb216c6 - Cache
    libxml2/2.11.4#b8655993026040c384c5483673921ae4:a97693414d91fbdceaa5f32b4f4f78ffd09eca1e#3f699f597052412d1d41bc32879197d1 - Cache
    libxslt/1.1.34#2bdc1f5fe5db1df40f8465e485a19ee4:5ac5ca2f129b9b51e8502e24ee4d2ba5c300cc02#ecc937886bac86f8249f239a99fe8cf8 - Cache
    pugixml/1.13#f615c1fcec55122b2e177d17061276e7:da39a3ee5e6b4b0d3255bfef95601890afd80709#ae530054ed7ac99330514c13a5bfde3a - Cache
    xerces-c/3.2.4#4dd6f8d2ced62cffea421ff28ee5856f:41c4e6767851fe7db56310649912b6259451a38f#5e3c306b33e3dc1648b61395abefccab - Cache
Test requirements
    gtest/1.13.0#8a0bc5b3e159ed45de97260c2bff65b5:e8881c31d7715e9ffccf19b87014654db155beed#85bd6af70b8fab12404260fd5c0a9a1d - Cache
Build requirements
Skipped binaries
    bzip2/1.0.8, zlib/1.3, b2/4.10.1, msys2/cci.latest

======== Installing packages ========

======== Installing packages ========
gtest/1.13.0: Already installed! (1 of 8)
pugixml/1.13: Already installed! (2 of 8)
xerces-c/3.2.4: Already installed! (3 of 8)
boost/1.81.0: Already installed! (4 of 8)
boost/1.81.0: Disabled magic autolinking (smart and magic decisions)
icu/72.1: Already installed! (5 of 8)
libiconv/1.17: Already installed! (6 of 8)
libxml2/2.11.4: Already installed! (7 of 8)
libxml2/2.11.4: Appending PATH environment variable: E:\conan\p\libxm86aacd15388b6\p\bin
libxslt/1.1.34: Already installed! (8 of 8)
WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated:     'cpp_info.names' used in: libxml2/2.11.4, icu/72.1, libxslt/1.1.34, gtest/1.13.0, boost/1.81.0, libiconv/1.17
WARN: deprecated:     'env_info' used in: libxml2/2.11.4, icu/72.1, libiconv/1.17, boost/1.81.0, libxslt/1.1.34
WARN: deprecated:     'cpp_info.filenames' used in: boost/1.81.0, libxml2/2.11.4
WARN: deprecated:     'user_info' used in: boost/1.81.0
WARN: deprecated:     'cpp_info.build_modules' used in: libxml2/2.11.4

======== Finalizing install (deploy, generators) ========
conanfile.py (castcore/1.1): Calling generate()
conanfile.py (castcore/1.1): Generators folder: E:\core\build\windows-clang-16-x86_64\generators
conanfile.py (castcore/1.1): CMakeToolchain generated: conan_toolchain.cmake
conanfile.py (castcore/1.1): Preset 'conan-windows-clang-16-x86_64' added to CMakePresets.json. Invoke it manually using 'cmake --preset conan-windows-clang-16-x86_64' if using CMake>=3.23
conanfile.py (castcore/1.1): If your CMake version is not compatible with CMakePresets (<3.23) call cmake like: 'cmake <path> -G "Ninja Multi-Config" -DCMAKE_TOOLCHAIN_FILE=E:\core\build\windows-clang-16-x86_64\generators\conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW'
conanfile.py (castcore/1.1): CMakeToolchain generated: CMakePresets.json
conanfile.py (castcore/1.1): CMakeToolchain generated: ..\..\..\CMakeUserPresets.json
conanfile.py (castcore/1.1): CMakeDeps necessary find_package() and targets for your CMakeLists.txt
    find_package(LibXslt)
    find_package(ICU)
    find_package(Boost)
    find_package(libxml2)
    find_package(pugixml)
    find_package(XercesC)
    find_package(GTest)
    target_link_libraries(... libxslt::libxslt icu::icu boost::boost LibXml2::LibXml2 pugixml::pugixml XercesC::XercesC gtest::gtest)
conanfile.py (castcore/1.1): Generating aggregated env files
conanfile.py (castcore/1.1): Generated aggregated env files: ['conanbuild.ps1', 'conanrun.ps1']

======== Calling build() ========
conanfile.py (castcore/1.1): Calling build()
conanfile.py (castcore/1.1): Running CMake.configure()
conanfile.py (castcore/1.1): RUN: cmake -G "Ninja Multi-Config" -DCMAKE_TOOLCHAIN_FILE="E:/core/build/windows-clang-16-x86_64/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="E:/core" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "E:\core"
-- Using Conan toolchain: E:/core/build/windows-clang-16-x86_64/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 17 with extensions OFF
-- Conan toolchain: Setting BUILD_SHARED_LIBS = ON
-- The CXX compiler identification is Clang 16.0.5 with MSVC-like command-line
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/Llvm/x64/bin/clang-cl.exe
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/Llvm/x64/bin/clang-cl.exe - broken
CMake Error at E:/python312/Lib/site-packages/cmake/data/share/cmake-3.28/Modules/CMakeTestCXXCompiler.cmake:60 (message):
  The C++ compiler

    "C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/Llvm/x64/bin/clang-cl.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: 'E:/core/build/windows-clang-16-x86_64/CMakeFiles/CMakeScratch/TryCompile-d2y99t'

    Run Build Command(s): E:/python312/Scripts/ninja.exe -v cmTC_3cc22
    [1/2] C:\PROGRA~1\MICROS~2\2022\PROFES~1\VC\Tools\Llvm\x64\bin\clang-cl.exe  /nologo -TP -DCMAKE_INTDIR=\"Debug\"  -m64 -fcolor-diagnostics -fansi-escape-codes /DWIN32 /D_WINDOWS /EHsc  /Zi /Ob0 /Od /RTC1 -std:c++17 -MDd /showIncludes /FoCMakeFiles\cmTC_3cc22.dir\Debug\testCXXCompiler.cxx.obj /FdCMakeFiles\cmTC_3cc22.dir\Debug\ -c -- E:\core\build\windows-clang-16-x86_64\CMakeFiles\CMakeScratch\TryCompile-d2y99t\testCXXCompiler.cxx
    [2/2] C:\Windows\system32\cmd.exe /C "cd . && E:\python312\Lib\site-packages\cmake\data\bin\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_3cc22.dir\Debug --rc=C:\PROGRA~1\MICROS~2\2022\PROFES~1\VC\Tools\Llvm\x64\bin\llvm-rc.exe --mt=CMAKE_MT-NOTFOUND --manifests  -- C:\PROGRA~1\MICROS~2\2022\PROFES~1\VC\Tools\Llvm\x64\bin\lld-link.exe /nologo CMakeFiles\cmTC_3cc22.dir\Debug\testCXXCompiler.cxx.obj  /out:Debug\cmTC_3cc22.exe /implib:Debug\cmTC_3cc22.lib /pdb:Debug\cmTC_3cc22.pdb /version:0.0 -m64 -fuse-ld=lld /machine:x64  /debug /INCREMENTAL /subsystem:console  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
    FAILED: Debug/cmTC_3cc22.exe
    C:\Windows\system32\cmd.exe /C "cd . && E:\python312\Lib\site-packages\cmake\data\bin\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_3cc22.dir\Debug --rc=C:\PROGRA~1\MICROS~2\2022\PROFES~1\VC\Tools\Llvm\x64\bin\llvm-rc.exe --mt=CMAKE_MT-NOTFOUND --manifests  -- C:\PROGRA~1\MICROS~2\2022\PROFES~1\VC\Tools\Llvm\x64\bin\lld-link.exe /nologo CMakeFiles\cmTC_3cc22.dir\Debug\testCXXCompiler.cxx.obj  /out:Debug\cmTC_3cc22.exe /implib:Debug\cmTC_3cc22.lib /pdb:Debug\cmTC_3cc22.pdb /version:0.0 -m64 -fuse-ld=lld /machine:x64  /debug /INCREMENTAL /subsystem:console  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
    MT: command "CMAKE_MT-NOTFOUND /nologo /manifest CMakeFiles\cmTC_3cc22.dir\Debug/intermediate.manifest /out:CMakeFiles\cmTC_3cc22.dir\Debug/embed.manifest /notify_update" failed (exit code 0x0) with the following output:
    no such file or directory
    ninja: build stopped: subcommand failed.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:6 (project)


-- Configuring incomplete, errors occurred!

ERROR: conanfile.py (castcore/1.1): Error in build() method, line 89
        cmake.configure()
        ConanException: Error 1 while executing
```
user: Todiq
issue_15434: state: open
title: Conan install with build_type=Release fails when invoke via CMake
body: ### Conan install with build_type=Release fails when invoke via CMake

I am trying to install boost/gtest with build_type as Release. However it fails when I Call via CMake. It works fien when I call the same command via conan cmdline. Not sure why this happens. It works fine with build_type=Debug. I have tried using both via conan recipe and directly using the `--requirements flag`.

Below is my CMake file:
```
cmake_minimum_required (VERSION 3.5)

add_definitions(-D_SCL_SECURE_NO_WARNINGS)

SET(filter "*.h" "*.cpp")
AutoGenDirStruct(${CMAKE_CURRENT_SOURCE_DIR} filter TRUE SOURCES)

add_library(iTurbAdditionalClasses STATIC ${SOURCES})

SET(Boost_Package_name "boost")
SET(Boost_Version "1.71.0")

SET(Remote_Server "conancenter")
SET(Debug_Output_Folder "${CMAKE_CURRENT_SOURCE_DIR}\\..\\generated\\Debug\\")
SET(Release_Output_Folder "${CMAKE_CURRENT_SOURCE_DIR}\\..\\generated\\Release\\")

message(Generated=${Debug_Output_Folder})

execute_process(COMMAND conan install "${CMAKE_CURRENT_SOURCE_DIR}/../conan/ConanRecipe.py" -s arch=${ARCH} -s build_type=Debug -r ${Remote_Server} -g CMakeDeps -of ${Debug_Output_Folder} -b missing OUTPUT_QUIET)

execute_process(COMMAND conan install "${CMAKE_CURRENT_SOURCE_DIR}/../conan/ConanRecipe.py" -s arch=${ARCH} -s build_type=Release -r ${Remote_Server} -g CMakeDeps -of ${Release_Output_Folder} -b missing OUTPUT_QUIET)

find_package("ZLIB" REQUIRED PATHS ${Debug_Output_Folder} ${Release_Output_Folder})
find_package("BZip2" REQUIRED PATHS ${Debug_Output_Folder} ${Release_Output_Folder})
find_package(${Boost_Package_name} ${Boost_Version} REQUIRED PATHS ${Debug_Output_Folder} ${Release_Output_Folder})

include_directories("${Boost_INCLUDE_DIR}")

SET(GTest_Package_name "gtest")
SET(GTest_Version "1.8.1")

execute_process(COMMAND conan install --requires=${GTest_Package_name}/${GTest_Version} -s arch=${ARCH} -s build_type=Release -r ${Remote_Server} -g CMakeDeps -of ${Release_Output_Folder} -b missing OUTPUT_QUIET)

find_package(${GTest_Package_name} ${GTest_Version} REQUIRED PATHS ${Release_Output_Folder})

include_directories("${GTest_INCLUDE_DIR}")
```

Output from CMake:

> Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.19045.
> Platform target: x86
> Lib path base: C:/Repositories/myProject/src/lib
> ======== Input profiles ========
> Profile host:
> [settings]
> arch=x86
> build_type=Debug
> compiler=msvc
> compiler.cppstd=14
> compiler.runtime=dynamic
> compiler.runtime_type=Debug
> compiler.version=193
> os=Windows
> 
> Profile build:
> [settings]
> arch=x86_64
> build_type=Release
> compiler=msvc
> compiler.cppstd=14
> compiler.runtime=dynamic
> compiler.runtime_type=Release
> compiler.version=193
> os=Windows
> 
> 
> 
> ======== Computing dependency graph ========
> 
> Graph root
>     ConanRecipe.py: C:/Repositories/myProject/src/myModule/../conan/ConanRecipe.py
> Requirements
>     boost/1.71.0#ef4b08d5c6a68541f44d6bbb53d8823f - Cache
>     bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4 - Cache
>     zlib/1.3#06023034579559bb64357db3a53f88a4 - Cache
> Build requirements
>     b2/4.10.1#1b290403d8648c79f468f5a6496f829a - Cache
> Resolved version ranges
>     zlib/[>=1.2.11 <2]: zlib/1.3
> 
> 
> ======== Computing necessary packages ========
> 
> Requirements
>     boost/1.71.0#ef4b08d5c6a68541f44d6bbb53d8823f:0cdaa12812a0ac22ff84ef2bf2b2edfcee9b69b1#724c9b8bf75bfc9fc9c367c7ab747469 - Cache
>     bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4:bf4baf0dcdc1c7941cf842f390e9b276b15ca608#14a162153d8ce768f29597db71b59d76 - Cache
>     zlib/1.3#06023034579559bb64357db3a53f88a4:1c8fded4e0c33eda4eaf967c81b43fde5ab5fdd8#09190c4cf858bdda71f672621d65506e - Cache
> Build requirements
> Skipped binaries
>     b2/4.10.1
> 
> 
> ======== Installing packages ========
> 
> bzip2/1.0.8: Already installed! (1 of 3)
> 
> zlib/1.3: Already installed! (2 of 3)
> 
> boost/1.71.0: Already installed! (3 of 3)
> 
> boost/1.71.0: Disabled magic autolinking (smart and magic decisions)
> 
> WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
> WARN: deprecated:     'cpp_info.names' used in: boost/1.71.0, bzip2/1.0.8, zlib/1.3
> WARN: deprecated:     'cpp_info.build_modules' used in: bzip2/1.0.8
> WARN: deprecated:     'env_info' used in: boost/1.71.0, bzip2/1.0.8
> WARN: deprecated:     'cpp_info.filenames' used in: boost/1.71.0
> WARN: deprecated:     'user_info' used in: boost/1.71.0
> 
> ======== Finalizing install (deploy, generators) ========
> 
> ConanRecipe.py: Writing generators to C:/Repositories/myProject/src/myModule\..\generated\Debug\
> 
> ConanRecipe.py: Generator 'CMakeDeps' calling 'generate()'
> 
> ConanRecipe.py: Calling generate()
> ConanRecipe.py: Generators folder: C:/Repositories/myProject/src/myModule\..\generated\Debug\
> 
> ConanRecipe.py: Generating aggregated env files
> ConanRecipe.py: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
> 
> Install finished successfully
> 
> 
> ======== Input profiles ========
> Profile host:
> [settings]
> arch=x86
> build_type=Release
> compiler=msvc
> compiler.cppstd=14
> compiler.runtime=dynamic
> compiler.runtime_type=Release
> compiler.version=193
> os=Windows
> 
> Profile build:
> 
> [settings]
> arch=x86_64
> build_type=Release
> compiler=msvc
> compiler.cppstd=14
> compiler.runtime=dynamic
> compiler.runtime_type=Release
> compiler.version=193
> os=Windows
> 
> 
> 
> ======== Computing dependency graph ========
> 
> Graph root
>     ConanRecipe.py: C:/Repositories/myProject/src/myModule/../conan/ConanRecipe.py
> Requirements
> 
>     boost/1.71.0#ef4b08d5c6a68541f44d6bbb53d8823f - Cache
>     bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4 - Cache
>     zlib/1.3#06023034579559bb64357db3a53f88a4 - Cache
> Build requirements
>     b2/4.10.1#1b290403d8648c79f468f5a6496f829a - Cache
> Resolved version ranges
>     zlib/[>=1.2.11 <2]: zlib/1.3
> 
> ======== Computing necessary packages ========
> 
> boost/1.71.0: Checking 3 compatible configurations
> 
> boost/1.71.0: Compatible configurations not found in cache, checking servers
> 
> boost/1.71.0: 'a704987b7c2d968599af55ef54d585736260a0cf': compiler.cppstd=17
> 
> boost/1.71.0: '94a3c161d72f2a062214bf13bcc3720e4b97f90c': compiler.cppstd=20
> 
> boost/1.71.0: 'df04052829c2df1fce2e714d0ec6742b7ea346fc': compiler.cppstd=23
> 
> Requirements
> 
>     boost/1.71.0#ef4b08d5c6a68541f44d6bbb53d8823f:8d1d9bb88122a20cc9bd681af7c690b81c72ab73 - Build
>     bzip2/1.0.8#457c272f7da34cb9c67456dd217d36c4:6b8a1fe8cfc7e56f5e35dc6072cbcfba1dfdb27a - Build
>     zlib/1.3#06023034579559bb64357db3a53f88a4:8419bdd2579514d415d70db8caf4318ede661647 - Build
> Build requirements
>     b2/4.10.1#1b290403d8648c79f468f5a6496f829a:522dcea5982a3f8a5b624c16477e47195da2f84f#ac9afe8444d67960c7a12dc72320909b - Cache
> 
> 
> ======== Installing packages ========
> 
> b2/4.10.1: Already installed! (1 of 4)
> 
> 
> -------- Installing package bzip2/1.0.8 (2 of 4) --------
> bzip2/1.0.8: Building from source
> bzip2/1.0.8: Package bzip2/1.0.8:6b8a1fe8cfc7e56f5e35dc6072cbcfba1dfdb27a
> 
> bzip2/1.0.8: Copying sources to build folder
> 
> bzip2/1.0.8: Building your package in C:\Users\myuser\.conan2\p\b\bzip2f0f65c3180d2e\b
> 
> bzip2/1.0.8: Calling generate()
> bzip2/1.0.8: Generators folder: C:\Users\myuser\.conan2\p\b\bzip2f0f65c3180d2e\b\build\generators
> 
> bzip2/1.0.8: CMakeToolchain generated: conan_toolchain.cmake
> 
> bzip2/1.0.8: CMakeToolchain generated: CMakePresets.json
> 
> bzip2/1.0.8: Generating aggregated env files
> bzip2/1.0.8: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
> 
> bzip2/1.0.8: Calling build()
> bzip2/1.0.8: apply_conandata_patches(): No patches defined in conandata
> 

> 
> bzip2/1.0.8: Running CMake.configure()
> 
> bzip2/1.0.8: RUN: cmake -G "Visual Studio 17 2022" -DCMAKE_TOOLCHAIN_FILE="C:/Users/myuser/.conan2/p/b/bzip2f0f65c3180d2e/b/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/myuser/.conan2/p/b/bzip2f0f65c3180d2e/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "C:\Users\myuser\.conan2\p\b\bzip2f0f65c3180d2e\b\src\.."
> 
> bzip2/1.0.8: ERROR: 
> Package '6b8a1fe8cfc7e56f5e35dc6072cbcfba1dfdb27a' build failed
> 
> bzip2/1.0.8: WARN: Build folder C:\Users\myuser\.conan2\p\b\bzip2f0f65c3180d2e\b\build
> 
> *********************************************************
> Recipe 'bzip2/1.0.8' cannot build its binary
> It is possible that this recipe is not Conan 2.0 ready
> If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
> If it is your recipe, check if it is updated to 2.0
> *********************************************************
> 
> 
> ERROR: bzip2/1.0.8: Error in build() method, line 63
> 	cmake.configure(build_script_folder=os.path.join(self.source_folder, os.pardir))
> 	ConanException: Error while running cmd
> Error: [WinError 6] The handle is invalid
> 
> ======== Input profiles ========
> Profile host:
> [settings]
> arch=x86
> build_type=Release
> compiler=msvc
> compiler.cppstd=14
> compiler.runtime=dynamic
> compiler.runtime_type=Release
> compiler.version=193
> os=Windows
> 
> Profile build:
> [settings]
> arch=x86_64
> build_type=Release
> compiler=msvc
> compiler.cppstd=14
> compiler.runtime=dynamic
> compiler.runtime_type=Release
> compiler.version=193
> os=Windows
> 
> 
> 
> ======== Computing dependency graph ========
> 
> Graph root
>     cli
> Requirements
>     gtest/1.8.1#c8a230fc18e7b5103adc986ccd1f6ba6 - Cache
> 
> 
> ======== Computing necessary packages ========
> 
> gtest/1.8.1: Checking 3 compatible configurations
> 
> gtest/1.8.1: Compatible configurations not found in cache, checking servers
> 
> gtest/1.8.1: '74ad6e579d88c522caeca4219ed2a0d244ce4015': compiler.cppstd=17
> 
> gtest/1.8.1: '564672ea94dbc96b1128735d0d4919695ef7533e': compiler.cppstd=20
> 
> gtest/1.8.1: 'c636eef0936a3fe1df7789ea9237d4ab6fd9645f': compiler.cppstd=23
> 
> Requirements
>     gtest/1.8.1#c8a230fc18e7b5103adc986ccd1f6ba6:9aaf3ed1a2b8f7dffcd3d83aa07de960f01c99e7 - Build
> 
> 
> ======== Installing packages ========
> 
> 
> -------- Installing package gtest/1.8.1 (1 of 1) --------
> gtest/1.8.1: Building from source
> gtest/1.8.1: Package gtest/1.8.1:9aaf3ed1a2b8f7dffcd3d83aa07de960f01c99e7
> 
> gtest/1.8.1: Copying sources to build folder
> 
> gtest/1.8.1: Building your package in C:\Users\myuser\.conan2\p\b\gtestde82d8c5eb1bf\b
> 
> gtest/1.8.1: Calling generate()
> gtest/1.8.1: Generators folder: C:\Users\myuser\.conan2\p\b\gtestde82d8c5eb1bf\b\build\generators
> 
> gtest/1.8.1: CMakeToolchain generated: conan_toolchain.cmake
> 
> gtest/1.8.1: CMakeToolchain generated: CMakePresets.json
> 
> gtest/1.8.1: CMakeToolchain generated: ..\..\src\CMakeUserPresets.json
> 
> gtest/1.8.1: Generating aggregated env files
> gtest/1.8.1: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
> 
> gtest/1.8.1: Calling build()
> 
> gtest/1.8.1: Apply patch (conan): add CUSTOM_DEBUG_POSTFIX option
> 
> gtest/1.8.1: Running CMake.configure()
> 
> gtest/1.8.1: RUN: cmake -G "Visual Studio 17 2022" -DCMAKE_TOOLCHAIN_FILE="C:/Users/myuser/.conan2/p/b/gtestde82d8c5eb1bf/b/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/myuser/.conan2/p/b/gtestde82d8c5eb1bf/p" -DCMAKE_POLICY_DEFAULT_CMP0042="NEW" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "C:\Users\myuser\.conan2\p\b\gtestde82d8c5eb1bf\b\src"
> 
> gtest/1.8.1: ERROR: 
> Package '9aaf3ed1a2b8f7dffcd3d83aa07de960f01c99e7' build failed
> gtest/1.8.1: WARN: Build folder C:\Users\myuser\.conan2\p\b\gtestde82d8c5eb1bf\b\build
> 
> *********************************************************
> Recipe 'gtest/1.8.1' cannot build its binary
> It is possible that this recipe is not Conan 2.0 ready
> If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
> If it is your recipe, check if it is updated to 2.0
> *********************************************************
> 
> ERROR: gtest/1.8.1: Error in build() method, line 135
> 	cmake.configure()
> 	ConanException: Error while running cmd
> Error: [WinError 6] The handle is invalid
> 
> CMake Error at myModule/CMakeLists.txt:35 (find_package):
>   Could not find a package configuration file provided by "gtest" (requested
>   version 1.8.1) with any of the following names:
> 
>     gtestConfig.cmake
>     gtest-config.cmake
> 
>   Add the installation prefix of "gtest" to CMAKE_PREFIX_PATH or set
>   "gtest_DIR" to a directory containing one of the above files.  If "gtest"
>   provides a separate development package or SDK, be sure it has been
>   installed.
> 
> 
> Configuring incomplete, errors occurred!

Conan recipe file:
```
import os
from conan import ConanFile

class Recipe(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    
    def requirements(self):
        self.requires("boost/1.71.0")
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sandybhat16
issue_15431: state: open
title: [question] How to Download tgz package in conan2
body: ### What is your question?

Hi,

I want to download conan_package.tgz using conan2.

Previously in conan 1.x, `conan download <package>`  downloads .tgz file in cache
Now in conan2, it just downloads manifest file. Is there a way in conan2 to download .tgz file.

Thanks

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: msk-iit
issue_15430: state: open
title: [feature] gfortran Compiler Support
body: ### What is your suggestion?

Hi! I'm working on a library that is built from Fortran source and redistributed as a Conan package.  I'm using gfortran for that, which is not supported 'out of the box', so here's the content I manually added to the `settings.yml`:
```
compiler:
    ...
    gfortran:
        version: ["4.1", "4.4", "4.5", "4.6", "4.7", "4.8", "4.9", "4.9.1",
                    "5", "5.1", "5.2", "5.3", "5.4", "5.5",
                    "6", "6.1", "6.2", "6.3", "6.4", "6.5",
                    "7", "7.1", "7.2", "7.3", "7.4", "7.5",
                    "8", "8.1", "8.2", "8.3", "8.4", "8.5",
                    "9", "9.1", "9.2", "9.3", "9.4", "9.5",
                    "10", "10.1", "10.2", "10.3", "10.4", "10.5"]
        integer_size: [4, 8, 16]
        real_size: [4, 8, 16]
        underscoring: ["default", "none", "second"]
        fortran_std: ["f95", "f2003", "f2008", "f2018", "f2023"]
```
The version numbers are aligned with the gcc numbering but it's not as far along as you can see.  The last four settings are selectable using compiler flags and impact library consumers. I can push up the changes in a PR if you are interested.  If I found the right spot looks like the defaults go [here](https://github.com/conan-io/conan/blob/2985accf41e9380ba5b12dd8b4392b904abb4c21/conans/client/conf/__init__.py#L15).


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: dnwillia
issue_15429: state: open
title: [bug] AutotoolsToolchain injects flags from build system on macOS
body: ### Environment details

* Operating System+version: macOS 14.2.1
* Compiler+version: Clang 14 from Android NDK r25c / Apple-Clang 14 from Xcode 14.2
* Conan version: 1.62
* Python version: 3.9.6


### Steps to reproduce

1. try cross-compiling to iOS or Android a recipe that uses Autotools like FFmpeg or OpenSSL
2. observe "C compiler is broken" error

### Logs

see https://github.com/conan-io/conan-center-index/issues/20513

Such issue didn't exist in v1.59
user: kambala-decapitator
labels: component: Conan 1.x: Affects only to Conan 1.x
issue_15428: state: open
title: [question] [conan 1.59] :  Build errors in my application build from abseil conan package
body: ### What is your question?

Hello, 
I am getting the following build errors in my application build from abseil conan package. Our application is based on C++14.
![image](https://github.com/conan-io/conan/assets/2928745/2c81bf26-08fc-48b2-b56b-50ef211d9a5e)

From abseil source code, I understand this will happen only if `ABSL_USES_STD_VARIANT` is defined. See screenshot below.
![image](https://github.com/conan-io/conan/assets/2928745/2a22c67a-014d-4f50-a6d5-726e8a93ae75)

My conan file looks like something below. 


```
class AppConan(ConanFile):
    name = "app"
    description = "Application"
    settings = "os", "compiler", "build_type", "arch"
    requires = (
        "gtest/[1.8.x]",
        "fmt/[8.x]",
       ....
        "abseil/20230802.1"
```


Could some one guide me how can I resolve this issue? Do you think using bincrafters package would help?
Looking forward to hearing from you soon.

@memsharded @RubenRBS I would appreciate your valuable thoughts on my above issue.

Thanks,
Honey

Honey Sukesan


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: honey-speaks-tech
issue_15423: state: open
title: [question] How to access an executable target from CMake?
body: ### What is your question?

Hello,

I am using conan 2.0.16

In my project's recipe (let's call it A), I have a `tool_requires` on another project of mine (let's call it B). B produces two executables:
- The first one takes a set of files in input. This set is combination of some from A & B. From them, it generates headers files
- The second only takes a set of files from B and generates a .bin file

These two executables must be called before A's building process.

So far, I've been doing the following in A's recipe. It works great:
```python
def generate(self):
	B = self.dependencies["B"]
	configuration = f"{self.build_folder}/configuration"
	copy(self, "*", src=B.cpp_info.components["FilesForHeaders"].resdirs[0], dst=f"{configuration}")
	copy(self, "*", src=os.path.join(self.recipe_folder, "FilesForHeaders"), dst=f"{configuration}")
	ct = CMakeToolchain(self)
	ct.generate()
	cd = CMakeDeps(self)
	cd.generate()

def build(self):
	bin_input = (self.dependencies["B"]).cpp_info.components["FilesForBin"].resdirs[0]
	configuration = f"{self.build_folder}/configuration"
	self.run(f"bin_generator -i {bin_input} -o {configuration}/my_file.bin")
	self.run(f"header_generator -i {configuration} -o {configuration}/include")
	cmake = CMake(self)
	cmake.configure()
	cmake.build()
```

Now:
- Is it possible to move these copies from the `generate()` method to a CMake equivalent?
For example by doing:
```cmake
file(COPY B::FilesForHeaders DESTINATION "${CMAKE_BINARY_DIR}/configuration")
file(COPY "${CMAKE_SOURCE_DIR}/FilesForHeaders" DESTINATION "${CMAKE_BINARY_DIR}/configuration")
```

- Similar questions regarding `build()`'s generations. Is it possible to access B's executables and files targets to do the following:
```cmake
add_custom_target(GENERATE_REQUIREMENTS ALL
	COMMAND B::bin_generator -i B::bin_input -o ${CMAKE_BINARY_DIR}/configuration/myfile.bin
	COMMAND B::header_generator -i "${CMAKE_BINARY_DIR}/configuration" -o "${CMAKE_BINARY_DIR}/configuration/include"
)
```

- If so, do I have to edit some others cpp_info (other than `resdir`), or do I need further editing through `set_property()` of cmake properties?

Thanks in advance

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Todiq
issue_15421: state: open
title: [question] does conan generate *.cmake files for the whole dependency tree? 
body: ### What is your question?

I've got a problem:
I am building a conan package with my own library. Let us call it MyLib. MyLib depends on a header-only package. Let us call it MyHeader.
Ok, MyLib is built using Cmake, the unit-tests are Ok. But the test-package step of MyLib is failing because the compiler can't find includedir of MyHeader, although it is specified in MyHeader conanfile an is correctly used during MyLib build step. In the test-package generators folder I see only MyLib-config.cmake files and no files, corresponding to MyHeader. MyLib_FIND_DEPENDENCY_NAMES variable is empty and MyHeader is never mentioned in the MyLib-*.cmake files. 
On the other hand, the generate(self) method in the conanfile sees MyHeader dependency as indirect...
Is all that Ok? 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: OlegWorld
issue_15416: state: open
title: [question] How to generate a `compile_commands.json` with conan dependencies?
body: ### What is your question?

## Environments

OS: Windows
Compiler: msvc
Build System: CMake
IDE: VSCode with Clangd extension

## Question

I can run my program correctly from the command line, but VSCode doesn't recognize the includePath, and I need to generate the `compile_commands.json` file. `clangd` use it to find the includePath.

Because `MSBuild` can't use `CMAKE_EXPORT_COMPILE_COMMANDS` to generate a `compile_commands.json` file, so I'm using `Ninja` now.

There is my profile:

```
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=17
compiler.runtime=dynamic
compiler.version=193
os=Windows

[conf]
tools.cmake.cmaketoolchain:generator=Ninja
```

I finally generated the `compile_commands.json` file, but it doesn't seem to include the conan installed dependencies. It only tracks files in my workspace. So I still can't find the includePath of conan dependencies in VSCode.

Also I need to run `conanbuild.bat` before building cmake, otherwise my `Ninja` generator won't find `c1.exe` in my enviroment. I wish it also has another solution.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: nonlinearthink
issue_15413: state: open
title: test to cover test_requires potential loop
body: Changelog: Omit
Docs: Omit

Close https://github.com/conan-io/conan/issues/15412

user: memsharded
issue_15412: state: open
title: [bug] test_requires causing cycle/loop in the dependency graph
body: ### Environment details

* Operating System+version: macos 14.2.1
* Compiler+version: apple-clang 15.0.0
* Conan version: 2.0.16
* Python version: 3.11.7


### Steps to reproduce

It appears that `test_requires` dependencies somehow get leaked and thus causing the cycles/loops when they shouldn't be.

Here is my setup:

`abseil/20230802.1.0@company/stable` **test_requires** `gtest/[~1]@company/stable`
`re2/20231101.0.0@company/stable` **requires** `abseil/[^20230802]@company/stable` and **test_requires** `gtest/[~1]@company/stable`

`gtest/1.11.0@company/stable` has no dependencies
`gtest/1.14.0@company/stable` **requires** both `abseil/[^20230802]@company/stable` and `re2/[^20231101]@company/stable`.

The build order is the following:

- first, we built `gtest/1.11.0@company/stable`
- then, we built `abseil/202300802.1.0@company/stable` which used `gtest/1.11.0@company/stable` for its testing purposes
- then, we built `re2/20231101.0.0@company/stable` which used `gtest/1.11.0@company/stable` for its testing purposes and has a real dependency on `abseil/20230802.1.0@company/stable`
- then, we updated `gtest` to v1.14 and added dependencies to `abseil` and `re2`, and built the new `gtest` package.
- then, an attempt to use `gtest/1.14.0@company/stable` as **test_requires** from some other package (e.g. `opencv`), fails with the following error:

```
|| ERROR: There is a cycle/loop in the graph:
||     Initial ancestor: gtest/1.14.0@company/stable
||     Require: gtest/1.14.0@company/stable
||     Dependency: gtest/1.14.0@company/stable
```

I don't see how this would be a cycle because:

- `opencv` test_requries `gtest`, which requires `abseil` and `re2` (which also requires `abseil`)
- the fact that both `abseil` and `re2` **test_require** `gtest` should not be leaked to `opencv`, as it's not relevant (it may appear in the lock file, but should not enter dependency resolution)

Currently, I can still build `gtest/1.14` without `abseil` and `re2` dependencies as they are still optional, and this is my workaround.

However, Google has [announced](https://github.com/google/googletest?tab=readme-ov-file#coming-soon) that soon gtest will depend on abseil (which itself test-depends on gtest), so this issue needs to be resolved.

### Logs

_No response_
user: DoDoENT
issue_15408: state: open
title: [feature] meson toolchain doesn't support debug built-in option
body: ### What is your suggestion?

Hi

I'm not sure if this is intentional, but is seems the meson toolchain doesn't support the `debug` (i.e. debug info) built-in option. However, it is in the template:
https://github.com/conan-io/conan/blob/35a9d7d9e369662531e2a32d2893e1d7acb13ccc/conan/tools/meson/toolchain.py#L60

but `MesonToolchain._context()` never returns a `debug` property so it's never rendered into the native/cross file, AFAICT.

It looks like meson are starting to rework the buildtype/debug(info) options, so even if unintentional maybe you want to wait for those changes? FWIW, for my own purposes I've just hacked `MesonToolchain._context()` to include:

```py
"debug": to_meson_value(self._debug),
```

such that in my conanfile's `generate()` I can `meson_toolchain._debug = True`. Pretty hacky I'm sure, but at least works for now...

Thanks


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: lukester1975
issue_15405: state: open
title: [feature] Automatically detect compiler toolchain during `conan install`
body: ### What is your suggestion?

Hi! I would like `conan install` to automatically find the default C/C++ compiler toolchain provided by my environment. Instead of having to specify the toolchain when provisioning conan projects.

I have published portable C/C++ projects that use conan to acquire my library dependencies. However, conan's need to be explicitly told the compiler toolchain version, adds friction when supporting different environments. Whether my contributors arrive from Windows, macOS, or another UNIX environment, forces different `conan install` flags to be specified. It's harder to share provisioning steps when they're OS specific.

This also clutters CI/CD pipeline automation.

I think the existing flags would be fine for *overriding* the default toolchain. But ultimately I'd like for conan to take reasonable steps, like cmake, and autodetect at least one common C/C++ toolchain if the cc/c++ commands or an MSVC environment variable are found.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: mcandre
issue_15404: state: open
title: [question] What is the recommended way to enforce cppstd for requirements packages?
body: ### What is your question?

Hi there, I want to enforce the `cppstd` setting for the project and all project dependencies to `17`, as many of the dependencies do not have `gnu17` pre-built wheels available. Below is what I have tried but had no luck with:

1. Command line flags (working but have to educate others)
Enforcing others to edit their default profile or use the correct combination of command line arguments is a bit troublesome in the real world because all of us make mistakes 😅 . 

2. Profiles (Have to specify arch & compiler version)
An alternative way is to use profiles but from my experiments, arch and compiler_version are required fields. It may be intentional and can be good for reproducible builds, but the problem is we are working on different versions of gcc (varies from 9-12) on both x86 and arm machines,  it would only adds complexity to the problem if we have to maintain a long list of profiles or introduce a text preprocessor.

TLDR, I want to **set compiler and compiler.cpp_std for my project dependencies in a configuration file e.g. conanfile.py, with minimal education effort to my colleages, and let conan detect the rest.** 


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: hrz6976
issue_15402: state: open
title: [bug] Weird path separators in zips may trip the client
body:               Let's check in the client if anything can be done about fixing this behaviour :)

_Originally posted by @RubenRBS in https://github.com/conan-io/conan-center-index/pull/21649#discussion_r1443609836_

Not confirmed at all, leaving this here just to double check the actual reason behind the issue

user: RubenRBS
issue_15400: state: open
title: Does conan install support calling external scripts at command line?
body: Hi,

I am using cmake file to install boost. It also builds during the install. However, for building I want to use the bootstrapping script  of boost and  the b2 library from the boost src folder to build it, hence I want to call an external script to build. Is this possible?

Part of my Cmake file:

```
SET(Boost_Package_name "boost")
SET(Boost_Version "1.71.0")
SET(Boost_Header_Only "False")

SET(ARCH "x86")
SET(Remote_Server "conancenter")
SET(Debug_Output_Folder "${CMAKE_CURRENT_SOURCE_DIR}\\..\\generated\\Debug\\")
SET(Release_Output_Folder "${CMAKE_CURRENT_SOURCE_DIR}\\..\\generated\\Release\\")

execute_process(COMMAND conan install --requires=${Boost_Package_name}/${Boost_Version} -o ${Boost_Package_name}*:header_only=${Boost_Header_Only} -s arch=${ARCH} -s build_type=Debug -r ${Remote_Server} -g CMakeDeps -of ${Debug_Output_Folder} -b missing
			OUTPUT_QUIET
		)
```

External script that I want to invoke  from the downloaded boost src folder:

```
bootstrap.bat

b2 --build-dir=build\x86\debug   address-model=32 threading=multi --stagedir=.\bin\x86\debug   --toolset=msvc -j 8 link=static runtime-link=shared --variant=debug
b2 --build-dir=build\x86\release address-model=32 threading=multi --stagedir=.\bin\x86\release --toolset=msvc -j 8 link=static runtime-link=shared --variant=release
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sandybhat16
issue_15393: state: open
title: MesonToolchain: respect can_run when deciding to cross compile
body: Changelog: Bugfix: MesonToolchain: respect can_run when deciding to cross compile
Docs: (trivial bugfix to correct behaviour to better match documentation - no documentation change required)

* #15392: MesonToolchain was only using the cross_building test and not using can_run (which respects the conf value).  Fix this so we can force cross-compilation where the host cannot run the binary despite it seeming like it should be able to.

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

user: kuroneko
issue_15386: state: open
title: [bug] CMakeDeps creates targets with dependency cycles
body: ### Environment details

* Conan version: 2.0.16

### Steps to reproduce

Build the https://github.com/conan-io/conan-center-index/pull/19298 pull request without this patch: https://github.com/conan-io/conan-center-index/blob/c66c8508ebb45572645e8be9ada9d02dde9efa50/recipes/gdal/post_3.5.0/patches/3.7.3/2-allow-cycles-in-cmake-targets.patch

### Logs

https://c3i.jfrog.io/c3i/misc-v2/logs/pr/19298/61-linux-gcc/gdal/3.5.3//248d2058404514fe8cc2a96075d6b66745ab0cea-build.txt

CMake Error at src/cmake/helpers/GdalDriverHelper.cmake:237 (foreach):
  Maximum recursion depth of 1000 exceeded
Call Stack (most recent call first):
  src/cmake/helpers/GdalDriverHelper.cmake:253 (gdal_target_interfaces)
  src/cmake/helpers/GdalDriverHelper.cmake:253 (gdal_target_interfaces)
  src/cmake/helpers/GdalDriverHelper.cmake:253 (gdal_target_interfaces)
  src/cmake/helpers/GdalDriverHelper.cmake:253 (gdal_target_interfaces)
  src/cmake/helpers/GdalDriverHelper.cmake:253 (gdal_target_interfaces)
  src/cmake/helpers/GdalDriverHelper.cmake:253 (gdal_target_interfaces)
...
user: valgur
issue_15385: state: open
title:  [suggestion] "conan remove" command add support for removing empty recipe
body: ### What is your suggestion?

I need to remove all empty recipe (has no package). I suggest adding this feature to "conan remove" command.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: didarpin
issue_15382: state: open
title: Add built in runtime deployer
body: Fix https://github.com/conan-io/conan/issues/15381

This PR is currently a draft, only tested manually on windows with:
```
conan install --requires=zlib/1.3 --requires=cmake/3.28.1 -of C:\Users\florian.degaulejac\tmp\zlib-cmake --deployer runtime_deploy.py -vtrace --deployer-folder C:\Users\florian.degaulejac\tmp\zlib-cmake\deploy -o "zlib/*:shared=True"
```

Remaining tasks that I won't have the time to complete:

- [ ]  write autotest instead of manual test
- [ ] test other env (linux, apple...)
- [ ] symbolic links
- [ ] test with deep hierarchy and check it is flatten

And a weird behavior I observed: dep.cpp_info.bindirs and dep.cpp_info.libdirs are populated with absolute paths instead of relative path like described in the documentation.

Docs: https://github.com/conan-io/docs/pull/XXXX

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ ] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

user: fdgStilla
issue_15381: state: open
title: [feature] add a runtime deployer
body: ### What is your suggestion?

The purposes are:
- ease the conan 2 migration by giving an alternative to the conan import command that was removed
- be able to create an installer, by copying all the .dll into a single folder
- be able to launch the executable on windows, without using the conanrun.sh script (so that you can use the Visual Studio IDE with cmake support more easily) if you have a cmake version that do not allow you to use the cmake presets

The original request come from this PR: https://github.com/conan-io/conan-extensions/pull/94, from @memsharded

> I think, and I have been wanting to have a built-in deployer in conan for runtime (dll, exes). So I think it would be good to move this to the conan repo, and try to contribute this as a built-in:
>- Lets call it runtime_deployer
>- It should target all platform, collecting dlls, dylibs, so and executables (basically the bin folder plus some lib artifacts)
>- It should collect them "flat", all in the same folder
>- I think it should also collect licenses, in different folders so they don't overwrite

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fdgStilla
issue_15380: state: open
title: [bug] PremakeDeps not working for conan 1.62.0
body: ### Environment details

* Operating System+version: Windows 11 Pro (22H2)
* Compiler+version: Visual Studio (I use 10 & 17 but I believe any version will see the same error)
* Conan version: 1.62.0
* Python version: 3.12.1

### Steps to reproduce

Salutations & Happy New Year 🥳,

I have tried using the built-in premake generator for my project to help me generate build files, but I noticed the installation fails when the PremakeDeps generator tries to generate its files. I read the source code for v1.62.0 and noticed the issue occurs on this line of the code, `conan\tools\premake\premakedeps.py: line 52`. I thought this was a user error so I looked at docs and tests as a reference for how to use the generator but nothing helped. 

I've created an example script to repro the issue so you could debug and help me with the bug I've found. Cheers in advance

1. Create an empty directory
2. Run the following command: `conan new -m msbuild_lib pkg/1.0`
3. Update the generated conan recipe's contents to this:
```py
import os

from conan import ConanFile
from conan.tools.microsoft import MSBuildToolchain, MSBuild, vs_layout
from conan.tools.files import copy


class Conan(ConanFile):
    name = "pkg"
    version = "1.0"
    settings = "os", "compiler", "build_type", "arch"
    generators = "PremakeDeps", "MSBuildDeps", "MSBuildToolchain"
    exports_sources = "pkg.sln", "pkg.vcxproj", "src/*", "include/*"
    short_paths = True

    default_options = {
        "fmt:header_only": True
    }

    def layout(self):
        vs_layout(self)

    def requirements(self):
        self.requires("fmt/10.2.0@")

    def generate(self):
        tc = MSBuildToolchain(self)
        tc.generate()

    def build(self):
        msbuild = MSBuild(self)
        msbuild.build("pkg.sln")

    def package(self):
        copy(self, "*.h", os.path.join(self.source_folder, "include"),
             dst=os.path.join(self.package_folder, "include"))
        copy(self, "*.lib", src=self.build_folder, dst=os.path.join(self.package_folder, "lib"),
             keep_path=False)

    def package_info(self):
        self.cpp_info.libs = ["pkg"]

```

4.  Run the conan install command using this profile (any profile should be able to repro the error but use this example).
```txt
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=msvc
compiler.cppstd=20
compiler.runtime=static
compiler.runtime_type=Debug
compiler.version=193
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
CONAN_DISABLE_STRICT_MODE=1
[conf]
tools.microsoft.msbuild:verbosity=Normal
```

### Logs

From the install command
```txt
Conan 1 is on a deprecation path, please consider migrating to Conan 2
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=msvc
compiler.cppstd=20
compiler.runtime=static
compiler.runtime_type=Debug
compiler.version=193
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
CONAN_DISABLE_STRICT_MODE=1
[conf]
tools.microsoft.msbuild:verbosity=Normal

conanfile.py (pkg/1.0): Installing package
Requirements
    fmt/10.2.0 from 'inseinc' - Cache
Packages
    fmt/10.2.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache

Installing (downloading, building) binaries...
fmt/10.2.0: Already installed!
conanfile.py (pkg/1.0): WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
conanfile.py (pkg/1.0): Generator 'MSBuildToolchain' calling 'generate()'
conanfile.py (pkg/1.0): MSBuildToolchain created conantoolchain_debug_x64.props
conanfile.py (pkg/1.0): MSBuildToolchain writing conantoolchain.props
conanfile.py (pkg/1.0): Generator txt created conanbuildinfo.txt
conanfile.py (pkg/1.0): Generator 'PremakeDeps' calling 'generate()'
conanfile.py (pkg/1.0): ERROR: Traceback (most recent call last):
  File "conans\client\generators\__init__.py", line 179, in write_generators
  File "conan\tools\premake\premakedeps.py", line 45, in generate
  File "conan\tools\premake\premakedeps.py", line 80, in content
  File "conan\tools\premake\premakedeps.py", line 52, in _get_cpp_info
  File "conans\model\new_build_info.py", line 106, in __getattr__
AttributeError: '_NewComponent' object has no attribute 'copy'

ERROR: Error in generator 'PremakeDeps': '_NewComponent' object has no attribute 'copy'
```
user: KingKiller100
issue_15379: state: open
title: [feature] Add a "data" package type. 
body: ### What is your suggestion?

Add a "data" package type.

This is a continuation of a conversion started on slack:

https://cpplang.slack.com/archives/C41CWV9HA/p1703102258129209

Frequently when running a C++ program it is necessary to acquire data for applications. It could be map data, graphics / texture data, config files, etc. 

My specific use case is that my application requires a map of an area (robot search / path planning). So the application can run many times using the same map. There can be many areas that the robot operates in, so there can be many independent maps which should be easily selectable at runtime (i.e. when I run the software or reconfigure it while running, I tell it which map to use). 

My current workflow to manage the maps is that I have a folder on a server where all of the map data resides, and then when needed, I rsync that folder to the device that will run the application and then feed the root directory of the data to the application so it knows where to look for it. This is currently all  managed via bash scripts. When the application is run, I tell it which map I want it to use. 

The main disadvantage is that there's not a good way to only rsync the maps I'm interested in. I have to rsync all of them. yes you could specify folders  in the rsync command but that's a little clumsy and doesn't really scale. I would like to use conan for this as I think it would work really well for it. I've done some initial testing and think it works well.  

In addition to data that is required at runtime, I can also see use cases for data that is required during build (data that gets embedded in a binary), and data that is required at test time although I do not have specific experience with these two use-cases. 

The example `conanfile.py` I've used that seems promising is:
```
import os
from conan import ConanFile
from conan.tools.files import  load, copy


class ConanDataPackage(ConanFile):
  name = "data_package"
  license = "my license"
  author = "Jason Beach <jason.m.beach@gmail.com>"

  package_type = "application" # not ideal but sets traits so this package can be found at runtime. 
  exports_sources = "data/*", "version"

  def set_version(self):
    # read version from file if not provided on command line
    self.version = self.version or load(self, "version").strip()

  def package(self):
    copy(self, "*.csv", self.source_folder, self.package_folder)
    copy(self, "*.meta", self.source_folder, self.package_folder)

  def package_info(self):
    self.runenv_info.append_path("MAP_DATA_DIR", os.path.join(self.package_folder, "data"))

``` 

This package can be easily consumed by downstream packages like any other conan package.  The path to the data is exposed via the MAP_DATA_DIR environment variable (in this case)
### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jasonbeach
issue_15376: state: open
title: [feature] Add some magic in AutotoolsToolchain when `tools.android:ndk_path` is set, to be consistent with CMakeToolchain & MesonToolchain
body: ### What is your suggestion?

conan does some magic in `CMakeToolchain` & `MesonToolchain` when `tools.android:ndk_path` is set in profile, but not in `AutotoolsToolchain`.

Given that `AutotoolsToolchain` is by far the second most used toolchain in conancenter (used by popular libs like OpenSSL), it's confusing for users when it breaks if they use the (naive) profile recommended by conan cross-build tutorial: https://docs.conan.io/2/examples/cross_build/android/android_studio.html

See this issue for example: https://github.com/conan-io/conan-center-index/issues/22114

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: SpaceIm
issue_15374: state: open
title: [question] How to add compiler sanitisers to conan
body: ### What is your question?

Hey guys,
I'm invoking conan from Cmake. We are still using conan 1.x since to conan 2.0 cmake wrapper seams to be still a work in progress.

According to this page there are several ways to pass the sanitiser flags to conan.
https://docs.conan.io/1/howtos/sanitizers.html
I decided to go with a custom profile. We are using Ninja MultiConfig with MSVC 17. So we actually have 4 profiles (Debug, Rel, RelWithDeb, MinSizeRel) and we are invoking conan for all 4 configurations (via conan_cmake_configure() and conan_cmake_install())

My profile looks like this

```
[settings]
os=Windows
arch=x86_64
compiler=Visual Studio
compiler.runtime=MDd
compiler.version=17
build_type=Debug
compiler.cppstd=20


[conf]
tools.build:cxxflags=["/fsanitize=address"]
tools.build:cflags=["/fsanitize=address"]
```
But when invoking conan, the compiler output tells me that I'm using ASAN but without /DEBUG. Does build_type=Debug not imply a /DEBUG flag being appended to the c/cxx Fags

How would you modify the profile that ASAN works ?. Thx for your help guys :)

BTW Happy new year :)


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: Ju1He1
issue_15366: state: open
title: Improve the error message when trying to use a `build-scripts` package as a regular requirement
body: It currently fails on an assert with no further context provided in the stack trace. There might be a better place to do this check, though. 

Also, might want to add a check for `PackageType.PYTHON` as well.

Changelog: Fix: Improve the error message when trying to use a `build-scripts` package as a regular requirement
Docs: Omit

- [ ] Refer to the issue that supports this Pull Request.
- [ ] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [ ] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ ] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

user: valgur
issue_15363: state: open
title: [question] Compatibility with bazel 7.0
body: Hi! I have a question regarding the compatibility of `conan` with `bazel`. I tried to make my first steps following [this guide](https://docs.conan.io/2/examples/tools/google/bazeltoolchain/build_simple_bazel_project.html#examples-tools-bazel-toolchain-build-simple-bazel-project), which works fine for `bazel 6.2.0`, but fails for me using `bazel 7.0.0` at the build step with the following error message:
```
❯ bazel --bazelrc=./conan/conan_bzl.rc build --config=conan-config //main:demo
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
WARNING: --enable_bzlmod is set, but no MODULE.bazel file was found at the workspace root. Bazel will create an empty MODULE.bazel file. Please consider migrating your external dependencies from WORKSPACE to MODULE.bazel. For more details, please refer to https://github.com/bazelbuild/bazel/issues/18958.
ERROR: /tmp/examples2/examples/tools/google/bazeltoolchain/string_formatter/WORKSPACE:2:24: //external:fmt: invalid label '/tmp/examples2/examples/tools/google/bazeltoolchain/string_formatter/conan/fmt/BUILD.bazel' in attribute 'build_file' in 'new_local_repository' rule: invalid target name '/tmp/examples2/examples/tools/google/bazeltoolchain/string_formatter/conan/fmt/BUILD.bazel': target names may not start with '/'
WARNING: Target pattern parsing failed.
ERROR: Skipping '//main:demo': error loading package 'main': Encountered error while reading extension file 'cc/defs.bzl': no such package '@@rules_cc//cc': error loading package 'external': Could not load //external package
ERROR: error loading package 'main': Encountered error while reading extension file 'cc/defs.bzl': no such package '@@rules_cc//cc': error loading package 'external': Could not load //external package
INFO: Elapsed time: 4.572s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
```

Getting rid of the warning by passing `--noenable_bzlmod` does not solve the errors and I have now two questions:

* Is is possible (or planned) to support the `bzlmod` mode of `bazel` within the generated files? As it is the new default it looks worthwhile to me.
* How to get rid of the error? Are some adaptions within the generated files necessary? Or do you think it is also in the long-term favorable to have some special configuration for `bazel` (which I don't know, yet...)?

For both it would be great, depending on your preferred solution, to update the linked guide above.

Thanks in advance!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: marlamb
issue_15359: state: open
title: [bug] Cannot fix storage path once corrupted (as result from automation error)
body: ### Environment details

* Operating System+version: Windows 11 Home Version 23H2
* Compiler+version: Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x64
* Conan version: 1.61.0
* Python version: 3.11.4


### Steps to reproduce

1. accidently make an error setting config `storage.path`, such as:
```python
import subprocess
path = 'C:\\'
# notice we forgot f before last string, making it a format string
subprocess.call(['conan', 'config', 'set', 'storage.path={path}\\conanStorage'])
```
2. command succeeds, but all subsequent commands fail as such:
```powershell
> conan --version
Error in Conan initialization: Conan storage path has to be an absolute path
```
even when trying to fix it:
```powershell
> conan config set storage.path=C:\conanStorage
Error in Conan initialization: Conan storage path has to be an absolute path
```
3. Manually inspecting conan.conf reveals the issue
```powershell
> Get-content $Env:CONAN_USER_HOME\.conan\conan.conf | select-string "path"

path = {path}\conanStorage
```
Expectations:
1. Either print the erroneous path (easily revealing where the issue is, perhaps with the config file path), or
2. subsequent `storage.path` commands do succeeds, thus preparing the previous mistake, or
3. fail the original config set command, so as to not "lock out" the user, forcing a manual intervention, or cache clear

### Logs

_No response_
user: Amir-Ti
labels: component: Conan 1.x: Affects only to Conan 1.x
issue_15345: state: open
title: [feature] Improve build tools to support Intel oneAPI compiler
body: ### What is your suggestion?

Hi there,
Is there anything that we can do in order to better support the Intel oneAPI compiler in the [build tools](https://github.com/conan-io/conan/blob/37573eeb176b9d382d999d5b3c45d220727f8702/conan/tools/build/cppstd.py#L111)?
Any suggestion is welcome, I will be happy to contribute.
Thanks.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jakeheke75
issue_15335: state: open
title: [suggestion] System package checks in tools.system.Zypper should be capability-aware
body: ### What is your suggestion?

tl;dr: Conan should add `--whatprovides` to the `check_command` used for Zypper, so that renamed packages can be detected.

Distributions may rename/merge system packages from time. To make sure old install instructions still work, a system called *capabilities* is used to allow the package manager to automatically install the right thing. For example, openSUSE doesn't have a `glproto-devel` package, but instead there's an `xorgproto-devel` package with the `glproto-devel` *capability*. That way, the user can enter `zypper install glproto-devel` to install `xorgproto-devel`. Conan currently is *not* capability-aware, hence system packages always must be referred to by their actual package name.

Conan Center is hitting this problem in `opengl/system`, which has a system package requirement to `glproto-devel`. That requirement is always detected as "not installed" on openSUSE, even if the user manually installs `xorgproto-devel` (see https://github.com/conan-io/conan-center-index/issues/18912). A workaround is to set `tools.system.package_manager:mode=install` and `tools.system.package_manager:sudo=True`, which will still fail the check but will then invoke a no-op `zypper install`.

This is because Conan's `check_command` (conan/tools/system/package_manager.py) uses `rpm -q <package_name>` under the hood, which strictly searches for package names. Luckily, rpm provides a flag to search for capabilities instead: ``rpm -q --whatprovides <package_name>``


### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: neobrain
issue_15326: state: open
title: [question] cpp_info.resdirs = ... are not propagated as config independent variable
body: ### What is your question?

Let's say I open generated files for some random package in the generated folder and for an example it will be icu4c.

There is a block of defined variables like this:
`icu4c-release-armv8-data.cmake`
```
set(icu4c_INCLUDE_DIRS_RELEASE "${icu4c_PACKAGE_FOLDER_RELEASE}/include")
set(icu4c_RES_DIRS_RELEASE "${icu4c_PACKAGE_FOLDER_RELEASE}/res")
set(icu4c_DEFINITIONS_RELEASE "-DU_STATIC_IMPLEMENTATION")
set(icu4c_SHARED_LINK_FLAGS_RELEASE )
set(icu4c_EXE_LINK_FLAGS_RELEASE )
set(icu4c_OBJECTS_RELEASE )
set(icu4c_COMPILE_DEFINITIONS_RELEASE "U_STATIC_IMPLEMENTATION")
set(icu4c_COMPILE_OPTIONS_C_RELEASE )
set(icu4c_COMPILE_OPTIONS_CXX_RELEASE )
set(icu4c_LIB_DIRS_RELEASE "${icu4c_PACKAGE_FOLDER_RELEASE}/lib")
set(icu4c_LIBS_RELEASE icui18n icuio icuuc icudata)
set(icu4c_SYSTEM_LIBS_RELEASE )
set(icu4c_FRAMEWORK_DIRS_RELEASE "${icu4c_PACKAGE_FOLDER_RELEASE}/Frameworks")
set(icu4c_FRAMEWORKS_RELEASE )
set(icu4c_BUILD_DIRS_RELEASE "${icu4c_PACKAGE_FOLDER_RELEASE}/")
```

However, when I look into `icu4c-config.cmake` I see that it provides "aliases" only for a subset of those variables.
```
set(icu4c_VERSION_STRING "0.6.0+71.1")
set(icu4c_INCLUDE_DIRS ${icu4c_INCLUDE_DIRS_RELEASE} )
set(icu4c_INCLUDE_DIR ${icu4c_INCLUDE_DIRS_RELEASE} )
set(icu4c_LIBRARIES ${icu4c_LIBRARIES_RELEASE} )
set(icu4c_DEFINITIONS ${icu4c_DEFINITIONS_RELEASE} )
```

Before using CMakeToolchain+CMakeDeps it worked as conan was declaring config independent variable what could have been used just like any other variable from the second list (${icu4c_INCLUDE_DIRS}, ${icu4c_INCLUDE_DIR}, ...).

But as I'm trying to migrate to CMakeDeps I've encountered that now I have to use some generator expressions to select between ${icu4c_RES_DIRS_RELEASE} and ${icu4c_RES_DIRS_DEBUG} depending on config.

What am I missing there? Was that an intended change and desired? If yes then how do I access _RES_DIR of a target? Only using the generator expressions?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: VladyslavOdobesku-TomTom
issue_15325: state: open
title: [feature] Clarify expected format of `tools.build:compiler_executables` and make it consistent in all toolchains
body: ### What is your suggestion?

Since https://github.com/conan-io/conan/pull/14676, MesonToolchain can accept that each key of `tools.build:compiler_executables` can be a string or a list. But when it's a string, it interprets each space as if it was a separated list of values, breaking compiler paths with spaces (see https://github.com/conan-io/conan-center-index/issues/21848).
In the meantime, it doesn't work like this in CMakeToolchain, and paths with spaces won't be parsed, so that a compiler path with spaces works fine.

So it would be nice to get some consistency, so that user can expect consistent behavior of `tools.build:compiler_executables` irrespective of underlying build system used by recipe.

I would expect that if a key is just a string, spaces are interpreted as spaces in full path to compiler, nothing else, so it's passed as is if build system supports it, otherwise sanitized.
If someone wants to misuse `tools.build:compiler_executables` and extend compiler paths with compiler options and C/C++ flags, then he should use a list (or better pass these options to `tools.build:c_flags` or `tools.build:cxx_flags`).

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: SpaceIm
issue_15322: state: open
title: [feature] Allow specifying versions for system packages
body: ### What is your suggestion?

I think it would be really useful to be able to specify desired version ranges for `system_requirements` packages, e.g. when using apt. This way Conan could check with the output of `dpkg-query` that I have a supported version of a dependency installed. It could also pass the version to `apt install` when installing a missing system dependency, like `apt install 'libmbedtls-dev=2.*'`, if that is desired.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: stevenwdv
issue_15318: state: open
title: [bug] Breaking change between 2.0.14 and 2.0.15 causes "Compatible package ID ... equal to the default package ID: Skipping it."
body: ### Environment details

* Operating System+version: Windows
* Compiler+version: Visual Studio 2022
* Conan version: 2.0.15
* Python version: Github Windows runner (not sure about the exact version here)

I originally posted this as a response on #15293 but I realise that this issue is likely unrelated. Hence the new issue:

Conan 2.0.15 introduces a breaking change. I'm not sure if this is a bug or a bugfix but I wouldn't really expect such a breaking change in a small point release either way. Maybe I'm missing something in the way the package revisions are calculated.

With Conan 2.0.14 this package worked on windows, linux and macos. With Conan 2.0.15 I get the following message:

Conan 2.0.15 (https://github.com/aleya-dev/libaeon/actions/runs/7282180560/job/19844092808):
```
asio/1.29.0@aleya/public: Compatible package ID da39a3ee5e6b4b0d3255bfef95601890afd80709 equal to the default package ID: Skipping it.
```

I ran a build of the exact same thing on conan 2.0.14 (https://github.com/aleya-dev/libaeon/actions/runs/7282554627/job/19845101294):
```
asio/1.29.0@aleya/public#bafe0390378ec0f1c1782cff24ab63c0:cb836a521fc8494ecf80498fd71e4aa2dc66157d#5117d4e3cc2c109e5a78b21adf7ee89c - Download (aleya)
```

Why is the computed hash different? Did something change in Conan 2.0.15 in the way these hashes are computed?

Artifactory with package:
https://artifactory.aleya.dev/ui/repos/tree/General/aleya/aleya/asio

Package itself:
https://github.com/aleya-dev/mirror-package-asio

The change to make the build green:
https://github.com/aleya-dev/libaeon/compare/master...check_conan

user: robindegen
issue_15313: state: open
title: [bug] Unable to use pre-installed msys2 subsystem to build packages
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: clang 8
* Conan version: 2.0.14
* Python version: 3.8.10


### Steps to reproduce

I'm unsure if this is a conan issue or an issue with the conan-center-index openssl recipe. Currently I'm attempting to cross build openssl for android on a Windows 11 machine. I had been running into issues where our CI pipeline would hang when conan attempts to install the msys2 package so I thought to get around that issue by pre-installing it on the system and having the `global.conf` reference it.

build profile
```
[settings]
os=Windows
arch=x86_64
compiler=msvc
compiler.version=192
compiler.runtime=dynamic
build_type=Release
```

host profile
```
{% set api_level = 16 %}
{% set target_host = 'arm-linux-androideabi' %}
{% set clang_host = 'armv7a-linux-androideabi' %}
{% set android_ndk = os.getenv("ANDROID_NDK") %}

[settings]
os=Android
os.api_level={{api_level}}
arch=armv7
compiler=clang
compiler.libcxx=c++_shared
compiler.version=8
build_type=Release

[conf]
# In newer NDK versions (>=21) should only require tools.android:ndk_path to be set
tools.android:ndk_path={{android_ndk}}
tools.gnu:host_triplet={{target_host}}
tools.build:compiler_executables={'c': '{{clang_host}}{{api_level}}-clang', 'cpp': '{{clang_host}}{{api_level}}-clang++'}

[buildenv]
PATH+=(path){{ os.path.join(android_ndk, 'toolchains', 'llvm', 'prebuilt', 'windows-x86_64', 'bin') }}
```

global.conf
```
# Force the installation of required items
tools.system.package_manager:mode=install

# Tell Windows where to find bash 
tools.microsoft.bash:path=C:\msys2\usr\bin\bash.exe
tools.microsoft.bash:subsystem=msys2
```

### Logs

```
-------- Installing package openssl/1.1.1t (3 of 4) --------
openssl/1.1.1t: Building from source
openssl/1.1.1t: Package openssl/1.1.1t:60ec2ce269923046ab34580c8701f1000b99d70f
openssl/1.1.1t: Copying sources to build folder
openssl/1.1.1t: Building your package in C:\Conan\p\b\opens7f7f708f2435a\b
openssl/1.1.1t: Calling generate()
openssl/1.1.1t: Generators folder: C:\Conan\p\b\opens7f7f708f2435a\b\build-debug\conan
openssl/1.1.1t: Generating aggregated env files
openssl/1.1.1t: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
openssl/1.1.1t: Calling build()
openssl/1.1.1t: Apply patch (portability): TVOS and WatchOS don't like fork()
openssl/1.1.1t: gen_info = {'CFLAGS': ['-fPIC', '-g'], 'CXXFLAGS': ['-fPIC', '-g'], 'DEFINES': [], 'LDFLAGS': []}
openssl/1.1.1t: using target: conan-Debug-Android-armv7-clang-8 -> linux-generic32
openssl/1.1.1t: my %targets = (
    "conan-Debug-Android-armv7-clang-8" => {
        inherit_from => [ "linux-generic32" ],
        cflags => add("-fPIC -g"),
        cxxflags => add("-fPIC -g"),

        includes => add(),
        lflags => add(""),







        perlasm_scheme => "void",
    },
);

openssl/1.1.1t: ['"conan-Debug-Android-armv7-clang-8"', 'no-shared', '--prefix=/', '--openssldir="res"', 'no-unit-test', 'threads', 'PERL=perl', 'no-tests', '--debug', '--libdir=lib', ' -D__ANDROID_API__=16', '-fPIC', 'no-md2']
openssl/1.1.1t: RUN: perl ./Configure "conan-Debug-Android-armv7-clang-8" no-shared --prefix=/ --openssldir="res" no-unit-test threads PERL=perl no-tests --debug --libdir=lib  -D__ANDROID_API__=16 -fPIC no-md2
The system cannot find the path specified.

openssl/1.1.1t: ERROR:
Package '60ec2ce269923046ab34580c8701f1000b99d70f' build failed
openssl/1.1.1t: WARN: Build folder C:\Conan\p\b\opens7f7f708f2435a\b\build-debug
*********************************************************
Recipe 'openssl/1.1.1t' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: openssl/1.1.1t: Error in build() method, line 723
        self.run(f'{self._perl} ./Configure {args}')
        ConanException: Error 1 while executing
```
It doesn't seem to give any hints as to what wasn't found?
user: wbehrens-on-gh
issue_15306: state: open
title: [bug] Unexpected propagation of buildenv env vars with host-context transitive deps
body: ### Environment details

* Conan version: 2.0.14

### Steps to reproduce

A minimal example: https://github.com/valgur/conan-buildenv-issue

Using a package with `package_type = "application"` as a host-context `self.requires()` dependency without explicitly adding `run=False` results in buildenv environment variables being added to all downstream packages as well.

This came up when trying to use `gfortran` from a `gcc` package together with its `gfortran` and `quadmath` runtime libraries to build `openblas`. The unexpected silent propagation of `CC` and `CXX` vars from `gcc` was caused some of the downstream package builds to fail.

I suppose this could be considered the intended behavior for `self.requires(..., run=True)`, but it's nevertheless unexpected and looks like an easy pitfall to me.

There are two aspects to this issue:

1. Should buildenv values for host-context dependencies be propagated downstream?
2. Should packages with `package_type = "application"` default to `run=True` when used with `self.requires()`?

Neither of these look like the correct behavior to me.

### Logs

_No response_
user: valgur
issue_15303: state: open
title: [bug] Android cross compilation not working. Targets not getting linked
body: ### Environment details

* Operating System+version:
Fedora 40 / Android 24
* Compiler+version:
clang 17
* Conan version:
2.0.14
* Python version:
Python 3.12.0

### Steps to reproduce

I was mostly following https://docs.conan.io/2/examples/cross_build/android/android_studio.html#examples-cross-build-android-studio except for some fixes i had to do for Conan2:

- Use `build=missing`
- Use `--output-folder` to put the files in the right place
- Only build release packages

My Android profile
```
include(default)

[settings]
os=Android
os.api_level=24
compiler=clang
compiler.version=17
compiler.libcxx=c++_static
compiler.cppstd=17

[conf]
tools.android:ndk_path=/home/stephan/Android/Sdk/ndk/25.1.8937393
```
My build.gradle (relevant portions)
```gradle 
task conanInstall {
    def conanExecutable = "conan" // define the path to your conan installation
    def buildDir = new File("app/build")
    buildDir.mkdirs()
    // Don't build the debug configurations
    ["Release"].each { String build_type ->
        ["armv7", "armv8", "x86", "x86_64"].each { String arch ->
            def cmd = conanExecutable + " install " +
                    "../../../../../../ --profile android -s build_type="+ build_type +" -s arch=" + arch +
                    " --build=missing --output-folder=conan-"+ arch +" -c tools.cmake.cmake_layout:build_folder_vars=['settings.arch']"
            print(">> ${cmd} \n")

            def sout = new StringBuilder(), serr = new StringBuilder()
            def proc = cmd.execute(null, buildDir)
            proc.consumeProcessOutput(sout, serr)
            proc.waitFor()
            println "$sout $serr"
            if (proc.exitValue() != 0) {
                throw new Exception("out> $sout err> $serr" + "\nCommand: ${cmd}")
            }
        }
    }
}

android {
    compileSdkVersion 33
    ndkVersion '25.1.8937393'

    buildFeatures {
        prefab true
    }

    defaultConfig {
        minSdkVersion 24
        targetSdkVersion 33
        versionCode 258
        versionName "6.8.7"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        externalNativeBuild {
            cmake {
                arguments "-DMES_MOBILE_BUILD=TRUE", "-DANDROID_STL=c++_shared", "-DCMAKE_TOOLCHAIN_FILE=./Applications/pocket/client/droid/app/conan_android_toolchain.cmake"
                cppFlags "-DMES_MOBILE_BUILD", "-fsigned-char","-fPIC",
                        "-D_LIBCPP_HAS_NO_OFF_T_FUNCTIONS"
            }
        }
    }

    externalNativeBuild {
        cmake {
            path file('../../../../../CMakeLists.txt')
            version "3.22.1"
        }
    }
    namespace 'org.mes'
}
```

My toolchain:
```cmake
 # During multiple stages of CMake configuration, the toolchain file is processed and command-line
 # variables may not be always available. The script exits prematurely if essential variables are absent.

 if ( NOT ANDROID_ABI )
     message(FATAL_ERROR "Please specify ANDROID_ABI")
     return()
 endif()
 if(${ANDROID_ABI} STREQUAL "x86_64")
     message(STATUS "Using x86_64 toolchain")
     include("${CMAKE_CURRENT_LIST_DIR}/build/conan-x86_64/conan_toolchain.cmake")
 elseif(${ANDROID_ABI} STREQUAL "x86")
     message(STATUS "Using x86 toolchain")
     include("${CMAKE_CURRENT_LIST_DIR}/build/conan-x86/conan_toolchain.cmake")
 elseif(${ANDROID_ABI} STREQUAL "arm64-v8a")
     message(STATUS "Using arm64-v8a toolchain")
     include("${CMAKE_CURRENT_LIST_DIR}/build/conan-armv8/conan_toolchain.cmake")
 elseif(${ANDROID_ABI} STREQUAL "armeabi-v7a")
     message(STATUS "Using armeabi-v7a toolchain")
     include("${CMAKE_CURRENT_LIST_DIR}/build/conan-armv7/conan_toolchain.cmake")
 else()
     message(FATAL "Not supported configuration")
 endif()
 ```

### Logs

_No response_
user: feliwir
issue_15298: state: open
title: [question] how to get QSerialPort via Conan ?
body: ### What is your question?

Hi, this is my first time working with conan, I am trying to convert my colleague's project from qmake to cmake+conan, but ran into the fact that I can't seem to get QSerialPort, although the other parts of QT have been obtained. 

```
Detected profile:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.version=193
os=Windows
```

```
[requires]
qt/5.15.11
[generators]
CMakeDeps
CMakeToolchain
[layout]
cmake_layout
```

```
find_package(Qt5 COMPONENTS Core Widgets Gui SerialPort Network REQUIRED)
add_executable(app ${SOURCES})
target_link_libraries(app Qt5::Core Qt5::Widgets Qt5::Gui Qt5::Network Qt5::SerialPort)
```

![image](https://github.com/conan-io/conan/assets/43905097/44d7996e-e524-4780-ae12-c23da8e03d98)




### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: lpmrfentazis
issue_15291: state: open
title: follow up on `test_source_folder_works` after path changes
body: ### What is your question?

* https://github.com/conan-io/conan/blob/e461acaaf3921c0aa5edc60c7fe0d75892cf72b9/conans/test/unittests/tools/gnu/autotools_test.py
* https://github.com/conan-io/conan/pull/15281

Run an integration test to make sure this test is still correct.


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: jcar87
issue_15290: state: open
title: Issues with Conan Cross-Compiling from macOS (M2) to Raspberry Pi: Wayland Package Errors
body: ### What is your question?

I'm working on a project that requires cross-compiling software from a Mac with an Apple M2 processor (running macOS) to Raspberry Pi Zero and Raspberry Pi 4B. I've been using Conan for local compilations on macOS successfully. However, I'm facing challenges in configuring Conan for cross-compiling to the Raspberry Pi platforms, particularly with certain Linux-specific packages.

### Current Setup:
```bash
$ conan profile show
```
Host profile:
[settings]
arch=armv8
build_type=Release
compiler=apple-clang
compiler.cppstd=gnu17
compiler.libcxx=libc++
compiler.version=15
os=Macos

Build profile:
[settings]
arch=armv8
build_type=Release
compiler=apple-clang
compiler.cppstd=gnu17
compiler.libcxx=libc++
compiler.version=15
os=Macos

#### Target Profile (Raspberry Pi): 
[settings]
os=Linux
arch=armv8
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=10

[buildenv]
CC=arm-linux-gnueabihf-gcc-9
CXX=arm-linux-gnueabihf-g++-9
LD=arm-linux-gnueabihf-ld

### Issue Encountered:
When I run the command:

```bash
conan install --build=missing -pr:b=default -pr:h=../dist/raspberry/conan-profile.txt ../
```

I receive the following error messages:
```bash
ERROR: There are invalid packages:
wayland-protocols/1.31: Invalid: wayland-protocols/1.31 only supports Linux
wayland/1.22.0: Invalid: wayland/1.22.0 only supports Linux
```


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: zlberto
issue_15286: state: open
title: [feature] Help new users find out about tools.microsoft.msbuild:vs_version
body: ### What is your suggestion?

I'm trying to use Conan (2.0.14) on the build server, which has VIsual Studio 2022 installed together with build tools for several previous versions as well.  I'd like to compile using the 2017 build tools and the 2022 visual studio.  My problem is easily solved by the tools.microsoft.msbuild:vs_version setting.  But I had to look through the source code to find that out.

1. My default profile didn't contain the setting.  Please see [Issue 14487](https://github.com/conan-io/conan/issues/14487).  I guess that code change still doesn't generate the setting "out of the box".
2. There is no documentation (that I could find) on the website about this use-case.  That would have really helped me to get started with Conan.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: kip3f
issue_15278: state: open
title: [feature] Consider that CMakeToolchain generates a environment.cmake file
body: Maybe that could be useful for using with a dependency provider like cmake conan that loads the environment, and you don't have to activate manually the environment. This would be an alternative when you don't have a preset already generated because you are only invoking Conan from cmake-conan.

Related: https://github.com/conan-io/conan/pull/15192

user: czoido
issue_15277: state: open
title: [feature] Re consider the install() method 
body: ### What is your suggestion?

This has been appearing again, give it another try

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: memsharded
issue_15273: state: open
title: [question] visible=False makes CMakeDeps generate incorrect files?
body: ### What is your question?

I came across a strange problem, see the attached test case. Unpack it and run `build.bat` - compilation will fail with
```
test.cpp(3,10): error C1083: Cannot open include file: 'opencv2/core.hpp': No such file or directory
```
But if you swap lines
```
        self.requires("opencv/4.5.5", visible=False)
        self.requires("pkg/1.0")
```
in `consumer.py`, compilation will succeed. Both `opencv/4.5.3` and `opencv/4.5.5` are unmodified recipes from conancenter. Looks like a Conan bug? I use Conan 2.0.14.
[test_case.zip](https://github.com/conan-io/conan/files/13670846/test_case.zip)


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: db4
issue_15269: state: open
title: Extract .zip files with recorded file timestamps (#15268)
body: Changelog: (Fix): Extract .zip files with recorded file timestamps

Proposed fix for #15268.

Timestamps need to be set after directories have been populated, because directory timestamps are updated whenever a new file is added to them.

Note that the Windows side of things is not yet addressed. I'm not sure what, if anything, needs to be done differently there. If I can get confirmation that the same approach is workable, I can update this change to use the same `file_timestamps` array for both sides.
user: iskunk
issue_15268: state: open
title: [bug] .zip files are extracted without recorded timestamps
body: ### Environment details

* Operating System+version: Ubuntu Linux 22.04
* Conan version: Git release/2.0 branch
* Python version: 3.11.5


### Steps to reproduce

When a .zip source archive file is extracted, the files are assigned current timestamps, not the ones recorded for them in the .zip file. (Unix source archives in .zip format are not common, but that is what GitHub serves up if you want to download an untagged commit.)

I would not have noticed this but for some alpha SOURCE_DATE_EPOCH code (WIP for #14480) erroring out on the too-new timestamps.

I have a first-draft fix for this, which I'll be submitting in a PR shortly.

### Logs

_No response_
user: iskunk
issue_15256: state: open
title: [bug] Cannot build on MSYS2 Clang64 ("Visual Studio Runtime version not defined")
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: mingw-w64-clang-x86_64-clang 17.0.2
* Conan version: 2.0.14
* Python version: 3.11.6

### Steps to reproduce

1. Install MSYS2 with mingw-w64-clang-x86_64-clang and mingw-w64-clang-x86_64-python-conan
2. Create a Conan profile like [here](https://blog.conan.io/2022/10/13/Different-flavors-Clang-compiler-Windows.html#msys2-clang) (customizing msys64 paths)
3. Add a Conanfile to a project, requiring e.g. `zlib/1.2.11`
4. Run Conan install:
```shell
conan install ./ --output-folder=./build/ --build=missing
```
5. Get unexpected error:
```
ERROR: zlib/1.2.11: Error in generate() method, line 63
        tc.generate()
        ConanException: Visual Studio Runtime version (v140-v143) not defined
```

Similar with Conan installed via pip on Windows:
```
conanfile.txt: ERROR: Traceback (most recent call last):
  File "C:\Users\Steven\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\conans\client\generators\__init__.py", line 94, in write_generators
    generator.generate()
  File "C:\Users\Steven\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\conan\tools\cmake\toolchain\toolchain.py", line 197, in generate
    VCVars(self._conanfile).generate()
  File "C:\Users\Steven\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\conan\tools\microsoft\visual.py", line 125, in generate
    raise ConanException("Visual Studio Runtime version (v140-v143) not defined")
conans.errors.ConanException: Visual Studio Runtime version (v140-v143) not defined

ERROR: Error in generator 'CMakeToolchain': Visual Studio Runtime version (v140-v143) not defined
```

Why is it trying to use Visual Studio? I specified clang as compiler.

### Logs

```
$ conan install ./ --output-folder=./cmake-build-debug/ --build=missing

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=20
compiler.libcxx=libc++
compiler.runtime=dynamic
compiler.runtime_type=Debug
compiler.version=17
os=Windows
[buildenv]
PATH+=(path)C:/msys64/clang64/bin
[runenv]
PATH+=(path)C:/msys64/clang64/bin

Profile build:
[settings]
arch=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=20
compiler.libcxx=libc++
compiler.runtime=dynamic
compiler.runtime_type=Debug
compiler.version=17
os=Windows
[buildenv]
PATH+=(path)C:/msys64/clang64/bin
[runenv]
PATH+=(path)C:/msys64/clang64/bin


======== Computing dependency graph ========
Graph root
    conanfile.py (pep-core/0.0.0): C:/dev/pep/core/conanfile.py
Requirements
    zlib/1.2.11#dc0e384f0551386cd76dc29cc964c95e - Cache
Build requirements
    cmake/3.22.6#32cced101c6df0fab43e8d00bd2483eb - Cache

======== Computing necessary packages ========
Requirements
    zlib/1.2.11#dc0e384f0551386cd76dc29cc964c95e:5cea60b7b9935e77d401ba90fcc99e975259faf5 - Build
Build requirements
    cmake/3.22.6#32cced101c6df0fab43e8d00bd2483eb:522dcea5982a3f8a5b624c16477e47195da2f84f#a9d024f459972755e5a815b775408fff - Cache

======== Installing packages ========
cmake/3.22.6: Already installed! (1 of 2)
cmake/3.22.6: Appending PATH environment variable: C:/Users/Steven/.conan2/p/cmake1927748c2604b/p/bin

-------- Installing package zlib/1.2.11 (2 of 2) --------
zlib/1.2.11: Building from source
zlib/1.2.11: Package zlib/1.2.11:5cea60b7b9935e77d401ba90fcc99e975259faf5
zlib/1.2.11: Copying sources to build folder
zlib/1.2.11: Building your package in C:/Users/Steven/.conan2/p/b/zlib41869a87a668a/b
zlib/1.2.11: Calling generate()
zlib/1.2.11: Generators folder: C:/Users/Steven/.conan2/p/b/zlib41869a87a668a/b/build/Debug/generators
zlib/1.2.11: CMakeToolchain generated: conan_toolchain.cmake
ERROR: zlib/1.2.11: Error in generate() method, line 63
        tc.generate()
        ConanException: Visual Studio Runtime version (v140-v143) not defined
```
user: stevenwdv
labels: staled: The issue has been inactive for a while and will be closed soon
issue_15240: state: open
title: [bug] FFmpeg test package fails to link sndio deps
body: ### Environment details

* Operating System+version: Ubuntu 22.04, x86_64
* Compiler+version: gcc-11
* Conan version: 2.0.14
* Python version: 3.10.12

When I try to `conan create` the ffmpeg package, the test_package fails to build due to a link error relating to the `sndio` library. I've tested this with both the 5.0.3 version and latest 6.1 version, same result.


```bash
# My command:
$conan-center-index/recipes/ffmpeg/all$ conan create . --version 6.1 --build missing

...

[100%] Linking C executable test_package
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/p/lib/libavdevice.a(sndio_dec.o): in function `audio_read_packet':
/opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio_dec.c:68: undefined reference to `sio_read'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio_dec.c:69: undefined reference to `sio_eof'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/p/lib/libavdevice.a(sndio_enc.o): in function `audio_write_trailer':
/opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio_enc.c:76: undefined reference to `sio_write'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/p/lib/libavdevice.a(sndio_enc.o): in function `audio_write_packet':
/opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio_enc.c:61: undefined reference to `sio_write'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio_enc.c:62: undefined reference to `sio_eof'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/p/lib/libavdevice.a(sndio.o): in function `ff_sndio_close':
/opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:117: undefined reference to `sio_close'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/p/lib/libavdevice.a(sndio.o): in function `ff_sndio_open':
/opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:43: undefined reference to `sio_open'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:49: undefined reference to `sio_initpar'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:61: undefined reference to `sio_setpar'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:61: undefined reference to `sio_getpar'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:92: undefined reference to `sio_onmove'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:94: undefined reference to `sio_start'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:107: undefined reference to `sio_close'
collect2: error: ld returned 1 exit status
gmake[2]: *** [CMakeFiles/test_package.dir/build.make:146: test_package] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/test_package.dir/all] Error 2
gmake: *** [Makefile:91: all] Error 2

*********************************************************
Recipe 'ffmpeg/6.1 (test package)' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: ffmpeg/6.1 (test package): Error in build() method, line 21
        cmake.build()
        ConanException: Error 2 while executing
```


### Steps to reproduce

1. Checkout conan-center-index commit: 23c84b31ab953a0ff401f53f91d51d820cd528f1
2. Run:
```bash
$conan-center-index/recipes/ffmpeg/all$ conan create . --version 6.1 --build missing
```

### Logs

```
======== Launching test_package ========

======== Computing dependency graph ========
Graph root
    ffmpeg/6.1 (test package): /home/spiderkeys/z/workspace/conan-center-index/recipes/ffmpeg/all/test_package/conanfile.py
Requirements
    autoconf/2.71#5312af4e8a3f82a7f6454866081de83f - Cache
    automake/1.16.5#27a1996f8e84efd37c1bdacd9c8a5d7b - Cache
    brotli/1.1.0#1d3da62d9f5ab8b335087c7016f78412 - Cache
    bzip2/1.0.8#d4bac033d92db60e1cc04b4f537ad936 - Cache
    ffmpeg/6.1#068aaaa939e24aedf21d0cf558af27e1 - Cache
    flac/1.4.2#53e81edf48941467f42a57473de693f2 - Cache
    freetype/2.13.0#dfcb148d916916d94b8495db0fc912b1 - Cache
    libalsa/1.2.10#bf7284ed6e494ceb57589ee57488511b - Cache
    libcap/2.69#c076309153f498b6c881da151d119373 - Cache
    libfdk_aac/2.0.2#3b068a2838994e88a28350fd362a1b46 - Cache
    libiconv/1.17#80da49fca2bee7160307d39a19feff20 - Cache
    libmp3lame/3.100#da13ecbaf0d06421ae586b7226d985ad - Cache
    libpng/1.6.40#92e774c2383a04742eec3d22df84e206 - Cache
    libsndfile/1.2.2#8325f3ef50cfada831b274a9abc0c801 - Cache
    libtool/2.4.7#45550c309dbf3f03a44ff239e3c58f59 - Cache
    libvpx/1.11.0#79c60ccd77d14a519e2c8e957b46e034 - Cache
    libwebp/1.3.2#2331459d59ca9d64343e2be775081017 - Cache
    libx264/cci.20220602#219c8f26ca3490b99be5596693f1c68b - Cache
    libx265/3.4#af66bb15860f95bcbd4fc94430c3f8c3 - Cache
    m4/1.4.19#87fd6787ab1023734834970edaf2f20f - Cache
    mpg123/1.31.2#ac763d6389e7aa8e1ed91510497fc7ae - Cache
    ogg/1.3.5#00fb0bd978d034d12af5efd5d6921364 - Cache
    openh264/2.3.1#8735c416b224f8cca4e14b815ed2299a - Cache
    openjpeg/2.5.0#9bc933368c3a6317b5076a6ce1567d0a - Cache
    openssl/3.2.0#c345d32f02dbdd943d404cdaa77bff2b - Cache
    opus/1.4#f8826c093568b0bf60e993bd649b3842 - Cache
    pulseaudio/14.2#cac3d381ec56e41193b5406a5e52e815 - Cache
    vaapi/system#9fa40059fb979af4f9b301b84fb2dfa1 - Cache
    vdpau/system#bdd7d010c4e3d8762a8f6f08a3cf6760 - Cache
    vorbis/1.3.7#0400cbb550b491521361a41c889d5c48 - Cache
    xorg/system#f305a1fd0b61725df7f118b57d520b0c - Cache
    xz_utils/5.4.5#56e3eb071afe0b5021eaff18b9a6c193 - Cache
    zlib/1.2.13#416618fa04d433c6bd94279ed2e93638 - Cache
Build requirements
    autoconf/2.71#5312af4e8a3f82a7f6454866081de83f - Cache
    automake/1.16.5#27a1996f8e84efd37c1bdacd9c8a5d7b - Cache
    gettext/0.21#449be1eec865ffc12c32fe24c4772ef6 - Cache
    gnu-config/cci.20210814#12da20e8cf2944f777a9ea286e5adb55 - Cache
    libiconv/1.17#80da49fca2bee7160307d39a19feff20 - Cache
    libtool/2.4.7#45550c309dbf3f03a44ff239e3c58f59 - Cache
    m4/1.4.19#87fd6787ab1023734834970edaf2f20f - Cache
    meson/1.2.2#cbb4b8d147762c87b0f93927d8027136 - Cache
    nasm/2.15.05#bcd9dfc539d94a51ef20dd921d368092 - Cache
    ninja/1.11.1#de85db1490cc53d3353a536dadf1db50 - Cache
    pkgconf/2.0.3#88569c5bf8f6760de238a623a1c4ecad - Cache
    yasm/1.3.0#f8b676849bfc7f0fb8c099374c4dd32e - Cache

======== Computing necessary packages ========
Requirements
    autoconf/2.71#5312af4e8a3f82a7f6454866081de83f:da39a3ee5e6b4b0d3255bfef95601890afd80709#669a93df881e9d7a78cb2f3f162097c4 - Cache
    automake/1.16.5#27a1996f8e84efd37c1bdacd9c8a5d7b:9a4eb3c8701508aa9458b1a73d0633783ecc2270#9719e51a6a62041af6a63e00eef35434 - Cache
    brotli/1.1.0#1d3da62d9f5ab8b335087c7016f78412:5b903b7d3547e48038c8edfc531cf76728b899e8#3875a4dc6da4356f6280042696e4db3c - Cache
    bzip2/1.0.8#d4bac033d92db60e1cc04b4f537ad936:763ddd53d7a4775fe84a285f56005a096d9786fd#af0350bcd1fdf51556a5a26c47b1a32b - Cache
    ffmpeg/6.1#068aaaa939e24aedf21d0cf558af27e1:d281f87689e44a2a536a19f22532a4d6a7f913e3#0cbf8d18f7dd572390fbccdd17fbced4 - Cache
    flac/1.4.2#53e81edf48941467f42a57473de693f2:01fe6dbfc4b61d1b87e784b3d1d1803b74a38466#dbb367f63a0d3b19a654288fa5b5b87b - Cache
    freetype/2.13.0#dfcb148d916916d94b8495db0fc912b1:ab8f5996c60be8ebe57fb0e09d3b8f3b4638d456#69f6a0b5daf3a2922b48272ce4c04fb1 - Cache
    libalsa/1.2.10#bf7284ed6e494ceb57589ee57488511b:5fa9eb432b28b79c0246ad3b98d042ed84a2b1ca#789aab059d4e0e2068d2cd664b792ac7 - Cache
    libcap/2.69#c076309153f498b6c881da151d119373:e394d65b8a668d2483958bc3fb8d1c2c1729493b#e93c71225bedafb67d1f009a5237b0f8 - Cache
    libfdk_aac/2.0.2#3b068a2838994e88a28350fd362a1b46:8631cf963dbbb4d7a378a64a6fd1dc57558bc2fe#2c9fdb28cdd3a024810a49a744d8e4c6 - Cache
    libiconv/1.17#80da49fca2bee7160307d39a19feff20:b647c43bfefae3f830561ca202b6cfd935b56205#fbd617c1c877b4e09c958d977c165986 - Cache
    libmp3lame/3.100#da13ecbaf0d06421ae586b7226d985ad:b647c43bfefae3f830561ca202b6cfd935b56205#27ab192d38ce938c38e1ef9fb707f8fe - Cache
    libpng/1.6.40#92e774c2383a04742eec3d22df84e206:52e28526917bc008177a3c5cf92ea21144c3ecd5#f21fe8f5d69a8d5aaff6ba12af48b5c9 - Cache
    libsndfile/1.2.2#8325f3ef50cfada831b274a9abc0c801:926041235ddaa3a983121414566faad581af0dd5#6057abf349c261f7d2866ff41e153785 - Cache
    libtool/2.4.7#45550c309dbf3f03a44ff239e3c58f59:b647c43bfefae3f830561ca202b6cfd935b56205#657e6f9c3522cd0915f03c7a71dc2dfd - Cache
    libvpx/1.11.0#79c60ccd77d14a519e2c8e957b46e034:e10fb4590c7304b8906c173a647c2c5dd2e61b44#3ccb4210ad13423bb6b27882a75909f6 - Cache
    libwebp/1.3.2#2331459d59ca9d64343e2be775081017:18f01a3f175888d5e3d128efe30c14773afadc83#7d50ae5ea9429a9ef34864109dfa0270 - Cache
    libx264/cci.20220602#219c8f26ca3490b99be5596693f1c68b:8e4079910145c3e45cb15e603514b075788d75c7#68fee516a72a3efaad6564f49ceb28e3 - Cache
    libx265/3.4#af66bb15860f95bcbd4fc94430c3f8c3:3274b8e4cc0184b54606fc1d6486c83926c266f4#53ab7a236d113eb7d4218515a742eb05 - Cache
    m4/1.4.19#87fd6787ab1023734834970edaf2f20f:3593751651824fb813502c69c971267624ced41a#eb16145946d9c9fa95b777969da769ab - Cache
    mpg123/1.31.2#ac763d6389e7aa8e1ed91510497fc7ae:cd3321362832070e917e6965cd88f846ae82dcde#ca67ad0a737e39e14ff6c55759092afe - Cache
    ogg/1.3.5#00fb0bd978d034d12af5efd5d6921364:b647c43bfefae3f830561ca202b6cfd935b56205#4e230e07cd08f3da0bc64900773c0642 - Cache
    openh264/2.3.1#8735c416b224f8cca4e14b815ed2299a:8631cf963dbbb4d7a378a64a6fd1dc57558bc2fe#4d0cdc980f4b4a0c0aef991332eec7d0 - Cache
    openjpeg/2.5.0#9bc933368c3a6317b5076a6ce1567d0a:b647c43bfefae3f830561ca202b6cfd935b56205#ff061986b45bc6ea0415c2de7da35641 - Cache
    openssl/3.2.0#c345d32f02dbdd943d404cdaa77bff2b:517a2f66278c9fbeb4bb0b64fc531fe112929bc9#05181b7efa6b87e77619831404c21bc0 - Cache
    opus/1.4#f8826c093568b0bf60e993bd649b3842:4df585f63ebee00f46c117ab89b69f931e4b3d26#7b4071c3d94ac11c81a8dc93fb1e0bc2 - Cache
    pulseaudio/14.2#cac3d381ec56e41193b5406a5e52e815:f5fa55c89eb35b3f46d01d85c85e9f56067f0c0e#423473ebc152856e15cd7d11e609afbf - Cache
    vaapi/system#9fa40059fb979af4f9b301b84fb2dfa1:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache
    vdpau/system#bdd7d010c4e3d8762a8f6f08a3cf6760:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache
    vorbis/1.3.7#0400cbb550b491521361a41c889d5c48:a7b68b4d31174eb97fff2f0a35ab28a9c1fd5e42#c042656fb1c4ac48edbd850bff96dc86 - Cache
    xorg/system#f305a1fd0b61725df7f118b57d520b0c:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache
    xz_utils/5.4.5#56e3eb071afe0b5021eaff18b9a6c193:b647c43bfefae3f830561ca202b6cfd935b56205#cc711d2f466feca7ce53bf0a534f83ac - Cache
    zlib/1.2.13#416618fa04d433c6bd94279ed2e93638:b647c43bfefae3f830561ca202b6cfd935b56205#bf4a282a2dd184a53eea48132b73b294 - Cache
Build requirements
Skipped binaries
    autoconf/2.71, automake/1.16.5, gettext/0.21, gnu-config/cci.20210814, libiconv/1.17, libtool/2.4.7, m4/1.4.19, meson/1.2.2, nasm/2.15.05, ninja/1.11.1, pkgconf/2.0.3, yasm/1.3.0
vaapi/system: System requirements:  already installed
vdpau/system: System requirements:  already installed
xorg/system: System requirements:  already installed
xorg/system: System requirements:  already installed

======== Installing packages ========
brotli/1.1.0: Already installed! (1 of 33)
bzip2/1.0.8: Already installed! (2 of 33)
libcap/2.69: Already installed! (3 of 33)
libfdk_aac/2.0.2: Already installed! (4 of 33)
libiconv/1.17: Already installed! (5 of 33)
libwebp/1.3.2: Already installed! (6 of 33)
m4/1.4.19: Already installed! (7 of 33)
m4/1.4.19: Appending PATH environment variable: /opt/mr/.conan2/p/b/m4eb603ab1444f2/p/bin
ogg/1.3.5: Already installed! (8 of 33)
openjpeg/2.5.0: Already installed! (9 of 33)
opus/1.4: Already installed! (10 of 33)
vaapi/system: Already installed! (11 of 33)
vdpau/system: Already installed! (12 of 33)
xorg/system: Already installed! (13 of 33)
xz_utils/5.4.5: Already installed! (14 of 33)
zlib/1.2.13: Already installed! (15 of 33)
libmp3lame/3.100: Already installed! (16 of 33)
libvpx/1.11.0: Already installed! (17 of 33)
libx264/cci.20220602: Already installed! (18 of 33)
libx265/3.4: Already installed! (19 of 33)
openh264/2.3.1: Already installed! (20 of 33)
mpg123/1.31.2: Already installed! (21 of 33)
mpg123/1.31.2: Appending PATH environment variable: /opt/mr/.conan2/p/b/mpg1277aabeb8efe90/p/bin
libalsa/1.2.10: Already installed! (22 of 33)
autoconf/2.71: Already installed! (23 of 33)
flac/1.4.2: Already installed! (24 of 33)
flac/1.4.2: Appending PATH environment variable: /opt/mr/.conan2/p/b/flac5df3c5c9b2ac1/p/bin
libpng/1.6.40: Already installed! (25 of 33)
openssl/3.2.0: Already installed! (26 of 33)
vorbis/1.3.7: Already installed! (27 of 33)
automake/1.16.5: Already installed! (28 of 33)
freetype/2.13.0: Already installed! (29 of 33)
libsndfile/1.2.2: Already installed! (30 of 33)
libtool/2.4.7: Already installed! (31 of 33)
libtool/2.4.7: Appending PATH env: bin_path/opt/mr/.conan2/p/b/libto3e58a979fb085/p/bin
libtool/2.4.7: WARN: The use of 'unix_path_legacy_compat' is deprecated in Conan 2.0 and does not perform path conversions. This is retained for compatibility with Conan 1.x and will be removed in a future version.
libtool/2.4.7: WARN: The use of 'unix_path_legacy_compat' is deprecated in Conan 2.0 and does not perform path conversions. This is retained for compatibility with Conan 1.x and will be removed in a future version.
pulseaudio/14.2: Already installed! (32 of 33)
ffmpeg/6.1: Already installed! (33 of 33)
WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated:     'cpp_info.names' used in: libx264/cci.20220602, libfdk_aac/2.0.2, xz_utils/5.4.5, libiconv/1.17, bzip2/1.0.8, zlib/1.2.13, freetype/2.13.0, ogg/1.3.5, libalsa/1.2.10, openjpeg/2.5.0, libsndfile/1.2.2, openssl/3.2.0, flac/1.4.2, vorbis/1.3.7, libwebp/1.3.2, brotli/1.1.0, libpng/1.6.40, opus/1.4, mpg123/1.31.2
WARN: deprecated:     'cpp_info.build_modules' used in: openjpeg/2.5.0, openssl/3.2.0, freetype/2.13.0, xz_utils/5.4.5, bzip2/1.0.8
WARN: deprecated:     'env_info' used in: automake/1.16.5, libsndfile/1.2.2, openssl/3.2.0, freetype/2.13.0, libalsa/1.2.10, mpg123/1.31.2, autoconf/2.71, flac/1.4.2, libtool/2.4.7, libiconv/1.17, bzip2/1.0.8, m4/1.4.19
WARN: deprecated:     'cpp_info.filenames' used in: mpg123/1.31.2, freetype/2.13.0, flac/1.4.2, libfdk_aac/2.0.2
WARN: deprecated:     'user_info' used in: automake/1.16.5, freetype/2.13.0

======== Testing the package ========
Removing previously existing 'test_package' build folder: /home/spiderkeys/z/workspace/conan-center-index/recipes/ffmpeg/all/test_package/build/gcc-11-x86_64-gnu17-release
ffmpeg/6.1 (test package): Test package build: build/gcc-11-x86_64-gnu17-release
ffmpeg/6.1 (test package): Test package build folder: /home/spiderkeys/z/workspace/conan-center-index/recipes/ffmpeg/all/test_package/build/gcc-11-x86_64-gnu17-release
ffmpeg/6.1 (test package): Writing generators to /home/spiderkeys/z/workspace/conan-center-index/recipes/ffmpeg/all/test_package/build/gcc-11-x86_64-gnu17-release/generators
ffmpeg/6.1 (test package): Generator 'VirtualRunEnv' calling 'generate()'
ffmpeg/6.1 (test package): Generator 'CMakeToolchain' calling 'generate()'
ffmpeg/6.1 (test package): CMakeToolchain generated: conan_toolchain.cmake
ffmpeg/6.1 (test package): CMakeToolchain generated: CMakePresets.json
ffmpeg/6.1 (test package): CMakeToolchain generated: ../../../CMakeUserPresets.json
ffmpeg/6.1 (test package): Generator 'CMakeDeps' calling 'generate()'
ffmpeg/6.1 (test package): Generating aggregated env files
ffmpeg/6.1 (test package): Generated aggregated env files: ['conanrun.sh', 'conanbuild.sh']

======== Testing the package: Building ========
ffmpeg/6.1 (test package): Calling build()
ffmpeg/6.1 (test package): Running CMake.configure()
ffmpeg/6.1 (test package): RUN: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/spiderkeys/z/workspace/conan-center-index/recipes/ffmpeg/all/test_package/build/gcc-11-x86_64-gnu17-release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/spiderkeys/z/workspace/conan-center-index/recipes/ffmpeg/all/test_package" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/spiderkeys/z/workspace/conan-center-index/recipes/ffmpeg/all/test_package"
-- Using Conan toolchain: /home/spiderkeys/z/workspace/conan-center-index/recipes/ffmpeg/all/test_package/build/gcc-11-x86_64-gnu17-release/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 17 with extensions ON
-- The C compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Conan: Component target declared 'ffmpeg::avutil'
-- Conan: Component target declared 'ffmpeg::swscale'
-- Conan: Component target declared 'ffmpeg::swresample'
-- Conan: Component target declared 'ffmpeg::postproc'
-- Conan: Component target declared 'ffmpeg::avcodec'
-- Conan: Component target declared 'ffmpeg::avformat'
-- Conan: Component target declared 'ffmpeg::avfilter'
-- Conan: Component target declared 'ffmpeg::avdevice'
-- Conan: Target declared 'ffmpeg::ffmpeg'
-- Conan: Target declared 'LibLZMA::LibLZMA'
-- Conan: Including build module from '/opt/mr/.conan2/p/b/xz_ute1a8167c1bfa9/p/lib/cmake/conan-official-xz_utils-variables.cmake'
-- Conan: Target declared 'Freetype::Freetype'
-- Conan: Target declared 'PNG::PNG'
-- Conan: Target declared 'ZLIB::ZLIB'
-- Conan: Target declared 'BZip2::BZip2'
-- Conan: Including build module from '/opt/mr/.conan2/p/bzip274dd66a247bd5/p/lib/cmake/conan-official-bzip2-variables.cmake'
-- Conan: Component target declared 'brotli::brotlicommon'
-- Conan: Component target declared 'brotli::brotlidec'
-- Conan: Component target declared 'brotli::brotlienc'
-- Conan: Target declared 'brotli::brotli'
-- Conan: Including build module from '/opt/mr/.conan2/p/b/freet053ee0b109fe6/p/lib/cmake/conan-official-freetype-variables.cmake'
-- Conan: Target declared 'openjp2'
-- Conan: Including build module from '/opt/mr/.conan2/p/b/openjd6db0a8e4c204/p/lib/cmake/conan-official-openjpeg-variables.cmake'
-- Conan: Target declared 'openh264::openh264'
-- Conan: Target declared 'libx264::libx264'
-- Conan: Target declared 'libx265::libx265'
-- Conan: Target declared 'libvpx::libvpx'
-- Conan: Component target declared 'FDK-AAC::fdk-aac'
-- Conan: Component target declared 'WebP::webpdecoder'
-- Conan: Component target declared 'WebP::sharpyuv'
-- Conan: Component target declared 'WebP::webp'
-- Conan: Component target declared 'WebP::webpdemux'
-- Conan: Component target declared 'WebP::libwebpmux'
-- Conan: Target declared 'libwebp::libwebp'
-- Conan: Component target declared 'pulseaudio::pulse'
-- Conan: Component target declared 'pulseaudio::pulse-simple'
-- Conan: Target declared 'pulseaudio::pulseaudio'
-- Conan: Target declared 'Iconv::Iconv'
-- Conan: Component target declared 'SndFile::sndfile'
-- Conan: Component target declared 'Vorbis::vorbis'
-- Conan: Component target declared 'Vorbis::vorbisenc'
-- Conan: Component target declared 'Vorbis::vorbisfile'
-- Conan: Component target declared 'vorbis::vorbisenc-alias'
-- Conan: Component target declared 'vorbis::vorbisfile-alias'
-- Conan: Target declared 'vorbis::vorbis'
-- Conan: Component target declared 'Ogg::ogg'
-- Conan: Component target declared 'FLAC::FLAC'
-- Conan: Component target declared 'FLAC::FLAC++'
-- Conan: Target declared 'flac::flac'
-- Conan: Component target declared 'Opus::opus'
-- Conan: Component target declared 'MPG123::libmpg123'
-- Conan: Component target declared 'MPG123::libout123'
-- Conan: Component target declared 'MPG123::libsyn123'
-- Conan: Target declared 'mpg123::mpg123'
-- Conan: Target declared 'libmp3lame::libmp3lame'
-- Conan: Component target declared 'libcap::cap'
-- Conan: Target declared 'libcap::libcap'
-- Conan: Target declared 'libtool::libtool'
-- Conan: Target declared 'automake::automake'
-- Conan: Target declared 'autoconf::autoconf'
-- Conan: Target declared 'm4::m4'
-- Conan: Target declared 'ALSA::ALSA'
-- Conan: Component target declared 'xorg::x11'
-- Conan: Component target declared 'xorg::x11-xcb'
-- Conan: Component target declared 'xorg::fontenc'
-- Conan: Component target declared 'xorg::ice'
-- Conan: Component target declared 'xorg::xau'
-- Conan: Component target declared 'xorg::xaw7'
-- Conan: Component target declared 'xorg::xcomposite'
-- Conan: Component target declared 'xorg::xcursor'
-- Conan: Component target declared 'xorg::xdamage'
-- Conan: Component target declared 'xorg::xdmcp'
-- Conan: Component target declared 'xorg::xext'
-- Conan: Component target declared 'xorg::xfixes'
-- Conan: Component target declared 'xorg::xi'
-- Conan: Component target declared 'xorg::xinerama'
-- Conan: Component target declared 'xorg::xkbfile'
-- Conan: Component target declared 'xorg::xmu'
-- Conan: Component target declared 'xorg::xmuu'
-- Conan: Component target declared 'xorg::xpm'
-- Conan: Component target declared 'xorg::xrandr'
-- Conan: Component target declared 'xorg::xrender'
-- Conan: Component target declared 'xorg::xres'
-- Conan: Component target declared 'xorg::xscrnsaver'
-- Conan: Component target declared 'xorg::xt'
-- Conan: Component target declared 'xorg::xtst'
-- Conan: Component target declared 'xorg::xv'
-- Conan: Component target declared 'xorg::xvmc'
-- Conan: Component target declared 'xorg::xxf86vm'
-- Conan: Component target declared 'xorg::xcb-xkb'
-- Conan: Component target declared 'xorg::xcb-icccm'
-- Conan: Component target declared 'xorg::xcb-image'
-- Conan: Component target declared 'xorg::xcb-keysyms'
-- Conan: Component target declared 'xorg::xcb-randr'
-- Conan: Component target declared 'xorg::xcb-render'
-- Conan: Component target declared 'xorg::xcb-renderutil'
-- Conan: Component target declared 'xorg::xcb-shape'
-- Conan: Component target declared 'xorg::xcb-shm'
-- Conan: Component target declared 'xorg::xcb-sync'
-- Conan: Component target declared 'xorg::xcb-xfixes'
-- Conan: Component target declared 'xorg::xcb-xinerama'
-- Conan: Component target declared 'xorg::xcb'
-- Conan: Component target declared 'xorg::xcb-atom'
-- Conan: Component target declared 'xorg::xcb-aux'
-- Conan: Component target declared 'xorg::xcb-event'
-- Conan: Component target declared 'xorg::xcb-util'
-- Conan: Component target declared 'xorg::xcb-dri3'
-- Conan: Component target declared 'xorg::uuid'
-- Conan: Component target declared 'xorg::sm'
-- Conan: Target declared 'xorg::xorg'
-- Conan: Component target declared 'OpenSSL::Crypto'
-- Conan: Component target declared 'OpenSSL::SSL'
-- Conan: Target declared 'openssl::openssl'
-- Conan: Including build module from '/opt/mr/.conan2/p/b/opense22a70964745a/p/lib/cmake/conan-official-openssl-variables.cmake'
-- Conan: Component target declared 'vaapi::libva'
-- Conan: Component target declared 'vaapi::libva-x11'
-- Conan: Component target declared 'vaapi::libva-drm'
-- Conan: Target declared 'vaapi::vaapi'
-- Conan: Target declared 'vdpau::vdpau'
-- Configuring done
-- Generating done
-- Build files have been written to: /home/spiderkeys/z/workspace/conan-center-index/recipes/ffmpeg/all/test_package/build/gcc-11-x86_64-gnu17-release

ffmpeg/6.1 (test package): Running CMake.build()
ffmpeg/6.1 (test package): RUN: cmake --build "/home/spiderkeys/z/workspace/conan-center-index/recipes/ffmpeg/all/test_package/build/gcc-11-x86_64-gnu17-release" -- -j8
[ 50%] Building C object CMakeFiles/test_package.dir/test_package.c.o
[100%] Linking C executable test_package
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/p/lib/libavdevice.a(sndio_dec.o): in function `audio_read_packet':
/opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio_dec.c:68: undefined reference to `sio_read'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio_dec.c:69: undefined reference to `sio_eof'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/p/lib/libavdevice.a(sndio_enc.o): in function `audio_write_trailer':
/opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio_enc.c:76: undefined reference to `sio_write'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/p/lib/libavdevice.a(sndio_enc.o): in function `audio_write_packet':
/opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio_enc.c:61: undefined reference to `sio_write'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio_enc.c:62: undefined reference to `sio_eof'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/p/lib/libavdevice.a(sndio.o): in function `ff_sndio_close':
/opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:117: undefined reference to `sio_close'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/p/lib/libavdevice.a(sndio.o): in function `ff_sndio_open':
/opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:43: undefined reference to `sio_open'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:49: undefined reference to `sio_initpar'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:61: undefined reference to `sio_setpar'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:61: undefined reference to `sio_getpar'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:92: undefined reference to `sio_onmove'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:94: undefined reference to `sio_start'
/usr/bin/ld: /opt/mr/.conan2/p/b/ffmped2a1b8de57509/b/build-release/src/libavdevice/sndio.c:107: undefined reference to `sio_close'
collect2: error: ld returned 1 exit status
gmake[2]: *** [CMakeFiles/test_package.dir/build.make:146: test_package] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/test_package.dir/all] Error 2
gmake: *** [Makefile:91: all] Error 2

*********************************************************
Recipe 'ffmpeg/6.1 (test package)' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: ffmpeg/6.1 (test package): Error in build() method, line 21
        cmake.build()
        ConanException: Error 2 while executing
```
user: spiderkeys
issue_15237: state: open
title: [question] Cross compiling SDL
body: ### What is your question?

I'm trying to cross compile an application in a Yocto SDK environment. 
I can cross compile executables and dependent conan packages, so the general setup is working.

My Conan version is: 2.0.14

Now, I tried to add `sdl/2.26.1` and things are breaking.

here are my profiles:

```
Profile host:
[settings]
arch=armv8
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
[options]
shared=True
[conf]
tools.build:compiler_executables={'c': 'aarch64-oe4t-linux-gcc', 'cpp': 'aarch64-oe4t-linux-g++'}
tools.build:cflags=[' -march=armv8-a+crc -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/opt/sdk/sysroots/armv8a-oe4t-linux', ' -O2 -pipe -g -feliminate-unused-debug-types ']
tools.build:cxxflags=[' -march=armv8-a+crc -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/opt/sdk/sysroots/armv8a-oe4t-linux', ' -O2 -pipe -g -feliminate-unused-debug-types ']
tools.cmake.cmaketoolchain:user_toolchain=['/opt/sdk/sysroots/x86_64-tdsdk-linux/usr/share/cmake/OEToolchainConfig.cmake']
tools.system.package_manager:mode=report
tools.system.package_manager:tool=apt
tools.cmake.cmake_layout:build_folder_vars=['settings.arch']

[buildenv]
CMAKE_C_COMPILER=aarch64-oe4t-linux-gcc
CMAKE_CXX_COMPILER=aarch64-oe4t-linux-g++
HAVE_GCC=1
HAVE_CXX=1

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
[conf]
tools.system.package_manager:mode=check
tools.system.package_manager:tool=apt
```

What happens, I think, is that `sdl` is creating it's own toolchain file, without respecting neither the `user_toolchain` nor the built/target architectures. Which causes the generated package references to be wrong.
I can `conan install` the dependencies, like `expat`, but if I'm trying to install `sdl` it still want's to compile dependencies like the `expat` one that I just compiled/installed again as the reference now is different, presumable because the arch is not passed properly. 

I'm using this command to install `sdl`:
```
conan install \
    --requires sdl/2.26.1 \
    -vtrace \
    --build=missing \
    -s build_type=Release \
    -pr:b default \
    -pr:h armv8 
```

The error is:
```
-- Using Conan toolchain: /home/vscode/.conan2/p/b/expat08f17334dc219/b/build/Release/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The C compiler identification is GNU 11.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /opt/sdk/sysroots/x86_64-tdsdk-linux/usr/bin/aarch64-oe4t-linux/aarch64-oe4t-linux-gcc
-- Check for working C compiler: /opt/sdk/sysroots/x86_64-tdsdk-linux/usr/bin/aarch64-oe4t-linux/aarch64-oe4t-linux-gcc - broken
CMake Error at /opt/sdk/sysroots/x86_64-tdsdk-linux/usr/share/cmake-3.22/Modules/CMakeTestCCompiler.cmake:69 (message):
  The C compiler

    "/opt/sdk/sysroots/x86_64-tdsdk-linux/usr/bin/aarch64-oe4t-linux/aarch64-oe4t-linux-gcc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/vscode/.conan2/p/b/expat08f17334dc219/b/build/Release/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_8674e/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_8674e.dir/build.make CMakeFiles/cmTC_8674e.dir/build
    gmake[1]: Entering directory '/home/vscode/.conan2/p/b/expat08f17334dc219/b/build/Release/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_8674e.dir/testCCompiler.c.o
    /opt/sdk/sysroots/x86_64-tdsdk-linux/usr/bin/aarch64-oe4t-linux/aarch64-oe4t-linux-gcc   -march=armv8-a+crc -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/opt/sdk/sysroots/armv8a-oe4t-linux   -O2 -pipe -g -feliminate-unused-debug-types    -m64  -fPIE -o CMakeFiles/cmTC_8674e.dir/testCCompiler.c.o -c /home/vscode/.conan2/p/b/expat08f17334dc219/b/build/Release/CMakeFiles/CMakeTmp/testCCompiler.c
    aarch64-oe4t-linux-gcc: error: unrecognized command-line option ‘-m64’
    gmake[1]: *** [CMakeFiles/cmTC_8674e.dir/build.make:78: CMakeFiles/cmTC_8674e.dir/testCCompiler.c.o] Error 1
    gmake[1]: Leaving directory '/home/vscode/.conan2/p/b/expat08f17334dc219/b/build/Release/CMakeFiles/CMakeTmp'
    gmake: *** [Makefile:127: cmTC_8674e/fast] Error 2
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:39 (project)

```

Did anyone come across this?

Thanks
Dom

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: codewithpassion
issue_15235: state: open
title: [bug] conan profile detect and cmake uses /usr/bin/cc instead of /usr/bin/gcc
body: ### Environment details

* Operating System+version: Linux Ubuntu 20.04
* Compiler+version: gcc 9.4.0
* Conan version: 2.0.5
* Python version: 3.8.10


### Steps to reproduce

conan profile detect
build a conan cmake project
grep -r CMAKE_C_COMPILER in the build folder you will see the value /usr/bin/cc

CC is not garanteed to be gcc and the profile generated says that we want gcc not cc, as such the CMAKE_C_COMPILER should be set to gcc not cc.

I was able to go around the problem by forcing a value for the C compiler

tools.build:compiler_executables={"c": "/usr/bin/gcc"}

but that should have been the default behavior of conan/cmake integration, there is no garantee that CC is set to gcc.

likely the same issue exist for the cpp compiler.

### Logs

Log is not useful here, instead I am pasting the result of my grep after the above steps:

build/native/Release/CMakeCache.txt:CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc
build/native/Release/CMakeCache.txt:CMAKE_C_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar-9
build/native/Release/CMakeCache.txt:CMAKE_C_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib-9

I would have expected either:

build/native/Release/CMakeCache.txt:CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc
build/native/Release/CMakeCache.txt:CMAKE_C_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar-9
build/native/Release/CMakeCache.txt:CMAKE_C_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib-9

or

build/native/Release/CMakeCache.txt:CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-9
build/native/Release/CMakeCache.txt:CMAKE_C_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar-9
build/native/Release/CMakeCache.txt:CMAKE_C_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib-9

user: hpe-ykoehler
issue_15232: state: open
title: [question] Create Package from Sources with multiple profiles
body: ### What is your question?

In our CI/CD pipeline I'm creating conan packages, using `conan create .`, for which external sources are required. These sources are fetched via the source() method. Furthermore does these packages contain up to 6 profiles for which they should be created. 

At the moment for every profile the sources are getting downloaded newly. But the sources are always the same and they are quite huge (> 1GB). So it take some time until they are available and unzipped. In conan1 I could use `--keep-sources` but this is quite dangerous. On the one side they are highlighted as "for testing purpose only" and on the other side the package creation will fail if the sources folder is dirty. And I also use the same pipelines for packages where the sources may be different among the profiles. 

I'm now thinking of copying the sources into the git repository folder from where I call `conan create .` and check inside the conan recipe if the sources are already copied. If so it skips downloading the sources once again. What do you think about it?

Do you maybe have a better idea?

How would this behave in conan2?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: aed2fe
issue_15229: state: open
title: [question] Propagate environment variables from transitive dependencies through tool_requires
body: ### What is your question?

I have set of CMake modules that depend on another CMake modules through `requires` (since it's runtime dependency for them). As of now (we use conan 1) we propagate location of CMake modules through `self.env_info.CMAKE_PREFIX_PATH`.

I'm trying to migrate this to conan 2 but faced an issue that environment variables are not propagated from transitive dependencies if I use `tool_requires` in consumer.

Here is the simplest test case that reproduces the scenario:
```shell
mkdir bar-package foo-package consumer

for pkg in bar-package foo-package consumer
do
    cat >$pkg/CMakeLists.txt <<-EOF
    cmake_minimum_required(VERSION 3.20)
    project(test NONE)
    message("$pkg: env{CMAKE_PREFIX_PATH}=\$ENV{CMAKE_PREFIX_PATH}")
EOF
done

cat >bar-package/conanfile.py <<EOF
from conan import ConanFile, conan_version
from conan.tools.scm import Version
from conan.tools.cmake import CMake

class Conan(ConanFile):
    settings = "os", "arch", "compiler", "build_type"
    generators = "CMakeToolchain", "CMakeDeps"
    no_copy_source = True
    exports_sources = "*", "!.?*"  # export all files except hidden (like .git, .github)

    name = "bar-package"
    version = "1.0"

    def package_id(self):
        self.info.clear()
            
    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
        cmake.install()

    def package(self):
        pass

    def package_info(self):
        if conan_version >= Version("2.0"):
            self.buildenv_info.append_path("CMAKE_PREFIX_PATH",f"cmake_prefix/{self.name}")
        else:
            self.env_info.CMAKE_PREFIX_PATH.append(f"cmake_prefix/{self.name}")
EOF

cat >foo-package/conanfile.py <<EOF
from conan import ConanFile, conan_version
from conan.tools.scm import Version
from conan.tools.cmake import CMake

class Conan(ConanFile):
    settings = "os", "arch", "compiler", "build_type"
    generators = "CMakeToolchain", "CMakeDeps"
    no_copy_source = True
    exports_sources = "*", "!.?*"  # export all files except hidden (like .git, .github)
    
    name = "foo-package"
    version = "1.0"
    requires = "bar-package/[>0.0]"

    def package_id(self):
        self.info.clear()
            
    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
        cmake.install()

    def package(self):
        pass

    def package_info(self):
        if conan_version >= Version("2.0"):
            self.buildenv_info.append_path("CMAKE_PREFIX_PATH",f"cmake_prefix/{self.name}")
        else:
            self.env_info.CMAKE_PREFIX_PATH.append(f"cmake_prefix/{self.name}")
EOF

cat >consumer/conanfile.py <<EOF
from conan import ConanFile
from conan.tools.cmake import CMake, CMakeDeps, CMakeToolchain

class Conan(ConanFile):
    settings = "os", "arch", "compiler", "build_type"
    generators = "CMakeToolchain", "CMakeDeps"
    no_copy_source = True
    exports_sources = "*", "!.?*"  # export all files except hidden (like .git, .github)
    
    name = "consumer"
    version = "1.0"
    build_requires = "foo-package/[>0.0]"
            
    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
        cmake.install()
    
    def package(self):
        pass
EOF
```

Commands to create packages:
```shell
conan create bar-package
conan create foo-package
conan create consumer
```

If I use conan 1.62.0, I see `consumer: env{CMAKE_PREFIX_PATH}=cmake_prefix/foo-package;cmake_prefix/bar-package` but if I use conan 2.0.14, I see `consumer: env{CMAKE_PREFIX_PATH}=;cmake_prefix/foo-package`.


I took a look as [this](https://docs.conan.io/2/tutorial/creating_packages/define_package_information.html?highlight=buildenv_info#propagating-environment-or-configuration-information-to-consumers) document but:
- It mentions usage of `conf_info` "so that consumers can use that information" but I couldn't find an example how consumers can use that information and whether it's propagated from transitive dependencies.
- ["To know more about this use case, please check the corresponding example"](https://docs.conan.io/2/examples/conanfile/package_info/package_info_conf_and_env.html#examples-conanfile-package-info-conf-and-env) link goes to empty `TBD` page so there is no example unfortunately. So no luck here as well.

Could you please advise what is recommended way to pass information through `tool_requires` to all consumers (not only immediate ones)?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: andrey-zherikov
issue_15226: state: open
title: [question]: [conan 1.59] Configure clang-tidy analysis source folder through conanfile.py
body: ### What is your question?

Hi all, 
Firstly, my heartfelt condolences to the Conan, Jfrog community, friends and family of Laso here. RIP, eternal soul.

I would appreciate if someone can shed some light into the issue which I face currently. 
I'm working with conan 1.59. 

I'm trying to configure clang-tidy build for our project repository. Issue is clang-tidy analysis happens on a build folder where there are some generated files and conan package files, which we need to exclude from clang-tidy analysis. 

We need to configure clang-tidy to check only project source folder. Any thoughts please anyone, FYI @memsharded @RubenRBS 

Here is the clang-tidy script.
```
#!/bin/bash
set -euo pipefail

PROJECT_DIR=$(cd "$(dirname "$0")/.."; pwd)

mkdir -p build-clang-tidy
(
  cd build-clang-tidy

  "${PROJECT_DIR}"/scripts/init-clang-tidy clang-tidy

  conan build "${PROJECT_DIR}"
  clang-tidy --list-checks
)
```
Here is the excerpt from my conanfile.py
```
#!/usr/bin/env python3
# -*- coding: utf-8 -*-

from conan import ConanFile
from conan.tools.cmake import CMake, CMakeDeps, CMakeToolchain
import os


class MyApp(ConanFile):
    name = "my_app"
    description = "My app"
    settings = "os", "compiler", "build_type", "arch"
    requires = (
        "gtest/[1.8.x]",
        "fmt/[8.x]"
    )

    options = {
        "clang_tidy": [False, True]
    }

    default_options = {
        "clang_tidy": False
    }


    def build_requirements(self):
.....

    def generate(self):
        tc = CMakeToolchain(self)

 ....

        tc.generate()

        deps = CMakeDeps(self)
        deps.generate()

    def generate(self):
        tc = CMakeToolchain(self)
......


        if self.options.clang_tidy:
################ My experiments to configure source folder for clang-tidy ######################            
            source_dir = self.source_folder 
            tc.variables["PROJECT_SOURCE_DIR"] = source_dir
            self.output.info("Source directory: %s" % source_dir)
            source_files = os.path.join(source_dir, "src/*") 
            tc.cache_variables["CMAKE_CXX_CLANG_TIDY"] = f"clang-tidy;--header-filter={source_files}"
################ My experiments to configure source folder for clang-tidy ######################         
            tc.cache_variables["CMAKE_EXPORT_COMPILE_COMMANDS"] = "ON"

        tc.generate()
        deps = CMakeDeps(self)
        deps.generate()


    def build(self):
        cmake = CMake(self)
        cmake.verbose = False
################ My experiments to configure source folder for clang-tidy ######################   
        #cmake.configure()
        cmake.configure(source_folder=self.source_folder)
################ My experiments to configure source folder for clang-tidy ######################   
        cmake.build()

    def configure(self):
...
        self.options["fmt"].header_only = True
################ My experiments to configure source folder for clang-tidy ######################   
        self.no_copy_source = True
################ My experiments to configure source folder for clang-tidy ######################   
  .. 

    def package(self):
        cmake = CMake(self)
        cmake.install()        
```

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: honey-speaks-tech
issue_15225: state: open
title: [question] Future of package signing extension
body: ### Future of package signing extension

We at Silicon Labs (https://www.silabs.com/) are exploring the possibility of using Conan as a package manager in our software stack. I'm trying to understand more about the package signing feature (https://docs.conan.io/2.0/reference/extensions/package_signing.html#package-signing) and was hoping you could provide some clarification.

Is the package signing extension expected to be part of the stable Conan version in the future? If so, is there any estimated timeline for this inclusion?
Are there any major changes expected in Conan's package signing features that we should be aware of?


@RubenRBS @memsharded

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: r-slabs
issue_15223: state: open
title: Sketch to show that populating download cache on conan upload is possible
body: Just to show that it is technically possible, even though right now is hideous - just wanted to have the PR up to quickly show it around.

This PR won't get merged, and it doesn't either mean that proper work on the feature will for sure happen, I just wrote this because I got bored :) 
user: RubenRBS
issue_15220: state: open
title: [bug] conan install --build=never still tries to build on Mac
body: ### Environment details

* Operating System+version: Mac OS Sonara
* Compiler+version: N/A
* Conan version: Conan version 1.60.1
* Python version: 3.10.9


### Steps to reproduce

- here is the command I execute:
```
conan install --build=never --profile /some/path/to/my/profile/conan-profiles/linux-gcc.ini /some/path/to/my/recipe
```

my recipe has only 1 `self.requires`. I need this package and nothing else.

- on a linux (in CI) with the same profile file, it just download the single requires:
 ```
conanfile.py (my-package/0.0.1-pre.20.16235860.gd0c73): Installing package
Requirements
Python requires
    base-cmake-pkg/1.0.2@otherteam/stable
    runtime-base/1.0.3@myteam/stable
    conan-packager/0.9.3@someteam/stable
    mybase/1.0.2@myteam/stable
Packages
Build requirements
    my-wanted-dependency/4.17.1-pre.61.16233726.g5f2c0@testing/dev-gsemet from 'dt-my-repository' - Downloaded
Build requirements packages
    my-wanted-dependency/4.17.1-pre.61.16233726.g5f2c0@testing/dev-gsemet:52cf33e8d00b6568dd8ffebf4f359a609065286d - Download
```

- but on a Mac, it displays all the "build_requires" of the package and try to fetch them, some of them are in "cache" but some are in build, and of course the build fails

**First**: I need to explicitely tell conan: do not try to download build_requires for this package. You do not need it

**Second**: despite `--build=never`, it tries to "build" some package, but there is no the environment locally to build (I only want the file but a "conan download" does not do the job.

Thanks

### Logs

Profile:
```
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=9
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
```

I see in the log on the mac:
```
Building package from source as defined by build_policy='missing'
```

but i have explicitely said "--build=never"
user: gsemet
issue_15219: state: open
title: [question] [conan2] How to use self-signed cert along with system installed certifidates?
body: ### What is your question?

From conan2 document I can use the following config option to use custom certs:
```
core.net.http:cacert_path
```

However, it seems I cannot "append" this to the existing cert list but it "replaces" the list.
So, for example, if I specify self-signed cert path with `core.net.http:cacert_path`, conan fails to verify a cert for `center.conan.io`.

How can I use my cert along with existing cert installed on the system (tested on Windows)?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: davidhjp01
issue_15216: state: open
title: [question] traits propagaton for static library that has runtime loaded plugins
body: ### What is your question?

We have a couple of cases in Conan Center, where at "link" time we have static libraries (that shouldn't propagate), but the implementation of those libraries load a module at runtime (dlopen or similar), from the same package.

Because the `package_type` is `static-library` - the runtime traits never propagates - this is being worked around by setting the relevant environment variable in `package_info()`:

* https://github.com/conan-io/conan-center-index/pull/19606
* https://github.com/conan-io/conan-center-index/pull/18385


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: jcar87
issue_15213: state: open
title: [feature] AutotoolsToolchain make build_type_flags configurable
body: ### What is your suggestion?

Hey, I'm currently investigating how I can set the optimization level generators and build system independent. Therefor, I have set in my profile 

```Text
[conf]
tools.build:cxxflags += ["-Os", "-DNDEBUG"]
```
.

In order to override the default Release flags for CMake I've added:

```Text
tools.cmake.cmaketoolchain:user_toolchain = ['{{ os.path.join(profile_dir, "cmake_vars.cmake") }}']
```

to the conf section of that profile and the `cmake_vars.cmake` basically contains:

```Text
set(CMAKE_CXX_FLAGS_RELEASE "")
```

This works well for CMake in order to transparently set the compiler optimization. For Meson this should also work. But I have noticed that the AutotoolsToolchain has a `build_type_flags` attribute which is set based on the build_type to hardcoded optimization levels, which is always added to the cxxflags export. I think it would make sense to make this somehow configurable in order to be able to override the optimization level for autotools based packages as well. Unfortunately, we have some plain Makefile based packages, hence just setting the build_type to `MinSizeRel` would not affect every package successfully.

Maybe the build_type_flags could be deactivated using a new conf entry for the autotoolsToolchain generator. 

To make a proposal this could look like:

`tools.gnu.autotoolstoolchain:disable_build_type_flags`. 

Another solution I can imagine would be to check if the tools.build:cxxflags/cflags already contains a optimization level and skip the build_type_flags composition in those cases. But I can imagine it would not be super easy to make this fail safe and it's again a case of "trying to be too smart".

Would this be a meaningful feature? Or do you see some different approaches to achieve this goal?

Thank you very much!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: nicosmd
issue_15209: state: open
title: [feature] Extend .conanrc for profiles information
body: ### What is your suggestion?

So we can change which default profiles, including the possibility of specifying multiple profiles, for different projects.

cc/ @maikelvdh 

Might be related to workspaces, we need to check how .conanrc and workspaces connect.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: memsharded
issue_15206: state: open
title: [question] How to specify required option for dependency
body: ### What is your question?

Hello,

I'm working on a package that requires the option of one of its dependency to be a specific value. This package will not build if it's not the case.

I couldn't find any information in the doc on how to properly handle that situation.
I know it's possible to set options of dependencies via `self.options` or `self.default_options` but that it may be overwritten by more upstream packages, which makes sense.

From looking at the source code, it seems that the `self.requires()` function takes an `options` argument. Is that what should be used? I couldn't find much about that argument.

Thanks in advance for your help,
Tom

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: tgurriet
labels: docs: Issues related with improvements in the documentation
issue_15200: state: open
title: [question] Why are tool_requires not reused in the dependency graph?
body: ### What is your question?


Hi,

I currently have the problem, that conan 2 (2.0.14) needs a lot more time to compute the dependency graph (sometimes minutes) than conan 1 did and I suspect this to be related to `tool_requires` bloating the dependency graph, since for every package its `tool_requires` are added as new nodes in the graph instead of reusing existing nodes.

This picture illustrates this for a small example (I obfuscated the package names due to this being a internal company project):
![2023-12-01_11-56](https://github.com/conan-io/conan/assets/4068353/88731954-c5db-417f-a94c-806abafc4188)

I would have expected, that `build_tool`, `compiler` and `another_build_tool` only appear once in the graph, since the revision and package_id is always the same. This seems to happen for regular `requires` as packages `B` and `D` both depend on the same package node `E`.
A detail in case it matters: `build_tool` is a `tool_requires` specified in the respective packages recipe's, while `compiler` is specified as a `tool_requires` from a profile.

Is there a specific reason why tool_requires are handled differently here, or is this a bug?

In bigger graphs with lots of (partially) interdependent `tool_requires`, the graph grows exponentially, which leads to unfeasible dependency graph calculation times.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: pklip
issue_15198: state: open
title: How can VSCode be configured to resolve the Conan imports
body: ### What is your question?

When using VSCode to edit a Conan recipe/package the conanfile.py always shows unresolved Imports as follows.
Is there a way to provide resolve this 
![image](https://github.com/conan-io/conan/assets/68386256/b953ed53-4de6-48d2-824d-c688946c5df4)


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: NotMeGuv
issue_15197: state: open
title: [question] How the Conan revision works
body: ### What is your question?

Hi, there.
I would like ask you for some details how works the revisions in Conan and what is real workflow.
If you have an article with more information than in [revision document](https://docs.conan.io/1/versioning/revisions.html), it might be fair enough.
Anyway I have a few questions related:
- I have some packages in local cache, which I have successfully built day before and now I got info that package [package_ID] is missing in the cache. What is verifying against Artifactory? That new recipe revision exist or new package revision exist? Both?
- When I'll be offline - Conan don't touch Artifactory, can I continue in work without any issue with my local cache? I expect that yes.
- How it works in situation, when I have installed specific revision from Artifactory to local cache and I want to build with this revision, does it won't failed after check that is new revision in Artifactory.

Thanks in advance for your time

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Wizradus
issue_15195: state: open
title: [question] arm64 Linux binaries
body: ### What is your question?

At the moment conancenter provides Linux prebuilt binaries of popular projects only for x86_64 CPU architecture (Intel/AMD 64 bit), e.g. conan 1.58.0 shows:

```
% conan search -r=conancenter openssl/3.2.0@ -q 'os=Linux' | grep arch | uniq 
arch: x86_64
% conan search -r=conancenter boost/1.83.0@ -q 'os=Linux' | grep arch | uniq
arch: x86_64
% conan search -r=conancenter grpc/1.54.3@ -q 'os=Linux' | grep arch | uniq
arch: x86_64
```

The same is confirmed on the web site, e.g.:
https://conan.io/center/recipes/grpc?version=1.54.3
"Available packages" section has "Linux", which shows arch = x86_64

While x86_64 is the de facto standard, a new generation of cloud services have started to offer arm64 (aka AArch64 or armv8) VMs which aim to improve performance and/or cost efficiency. I wish to get arm64 prebuilt binaries from conan that would be compatible with arm64-based VMs of popular cloud providers and CI vendors. 

Questions:

1. Is it up to the conancenter or the package maintainers to build and upload Linux arm64 binaries?
2. If it is controlled by conancenter, are there plans to add Linux arm64 support? What are the considerations and issues with this?
3. Are there any well-known alternative repositories having arm64 builds ready?


### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: battlmonstr
issue_15184: state: open
title: [feature] Conan dependencies package
body: ### What is your suggestion?

Hi! I would like to know all of the dependencies that go in to conan - and all of their sources. Perhaps in a conan c++ package.

See @SSE4's most recent post as of this time
https://github.com/conan-io/conan/issues/15120

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jacobfriedman
issue_15176: state: open
title: [question] Express Transitive Components from package_info
body: ### What is your question?

Hi,

I have something like the following requirements for package "MyPackage":

```
# from package MyPackage
def requirements(self):
   self.requires("a/1.0")
   self.requires("b/2.0")
   self.requires("c/3.0")
```
a, b and c are shared libs packages that creates several libs, and export components information regards them at package info methods, assume:
```
# from package a / b / c
def package_info(self):
     self.cpp_info.components["x"].libdirs = xlibdirs
     self.cpp_info.components["x"].includedirs = xincludedirs
     self.cpp_info.components["x"].bindirs = xbindirs
     self.cpp_info.components["x"].libs = ["x"]

     self.cpp_info.components["y"].libdirs = ylibdirs
     self.cpp_info.components["y"].includedirs = yincludedirs
     self.cpp_info.components["y"].bindirs = ybindirs
     self.cpp_info.components["y"].libs = ["y"]
```
now, MyPackage is a single lib shared library package, which includes c headers at it's own public headers, which means MyPackage consumers should get the transitive c headers propagated from MyPackage, so according to documentation I should do something like:
```
# from package MyPackage
def package_info(self):
    self.cpp_info.requires = ["c::y"]
```
but that fails on package method (MyPackage/x.0.0.0: Calling package()) with the following:
```
ERROR: MyPackage/x.0.0.0: Required package 'a' not in component 'requires'.
```
well, of course some of 'a' components are required, I just don't want them to get to the downstream. so can I state those are private implementation details ? how can I express the true transitivity of my package ?






### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: mikirothman
issue_15175: state: open
title: [question] README is not clear on running tests
body: ### What is your question?

Hi! It seems like core README does not provide full information required to run tests. I've encountered multiple errors with tests failing, the output said something about missing packages. It turns out (after I went to some Jenkins ongoing build) that the actual command for running tests is
```
python -m pip install -r conans/requirements.txt --no-cache-dir --timeout 30 && python -m pip install -r conans/requirements_server.txt --no-cache-dir --timeout 30 && python -m pip install -r conans/requirements_dev.txt --no-cache-dir --timeout 30 && python -m pip install meson --no-cache-dir --timeout 30 && python -m pip install scons --no-cache-dir --timeout 30 && python -m pip install . && conan --version && conan --help && python -m pytest conans/test/unittests -n=4 --durations=20
```
It differs mainly from README mainly in the `meson` and `scons` installation. Maybe add it to readme as well?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sin-diesel
issue_15171: state: open
title: conan profiles
body: ### What is your question?

Hi,

1. Is it mandatory to have profiles in ~/.conan2 dir? I was trying 
![image](https://github.com/conan-io/conan/assets/111378770/52bee7a4-825b-4e75-b0c4-2190f3d1bc7e)

by placing default profile in different dir other than ~/.conan2, it didn't work. 

2. When I created profile with name as myprofile as given in https://docs.conan.io/2.0/reference/config_files/profiles.html
![image](https://github.com/conan-io/conan/assets/111378770/0b134c62-2b67-4c6f-95a4-de166226a7a3)

![image](https://github.com/conan-io/conan/assets/111378770/25d44b21-42d0-4200-891c-35a16b61303b)

commands do not work. Error is

ERROR: the default build profile <~/.conan2/profiles/default' doesn't exist.
You need to create a default profile (type 'conan profile detect' command)
or specify your own profile with '--profile:build=<myprofile>

It works only when I specify both --profile:build and --profile:host 
which is different from what is provided in help of conan profile

Please let me know if I am missing something here.



### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: laxmij-cmd
issue_15165: state: open
title: [question] different behavior when using "tool_requires" in Conan 1.X and Conan 2.X (only in test-package)
body: ### What is your question?

**Description:**
When utilizing tool_requires in a test-package with Conan 1.x, I observe a different behavior compared to Conan 2.x.

**Used profiles:** 
Build profile: 
```
[settings]
arch=x86_64
os=Linux
```

Host-profile:
```
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
os=Linux
os_build=Linux
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=10.3
```

**Conan 1.x Behavior:**
Steps to Reproduce:

- conan create . randomUser/randomChannel -pr:b build-profile -pr:h host-profile
- Using build and host profiles, as outlined above, results in the following output:

`ERROR: protoc/3.18.0_17@randomUser/randomChannel: 'settings.compiler' value not defined`

**Conan 2.x Behavior:**
Steps to Reproduce: 

- conan2 create . --user randomUser --channel randomChannel -pr:b build-profile -pr:h host-profile
- Build successful

With the same profiles, the tool_requires functionality works as expected.

**Conclusion**:
In Conan 1.x it seems to build protoc from the test package. The tool_requires will lead to switching the build and host profiles and therefore not finding a compiler.setting (because we are using a minimal build profile).

In Conan 2.x on the other hand it first build only the protoc package and then the test consumes the created package (as expected). 

To summarize the observations the following question occured: 
* Is this behavior expected?
* Is there a better solution than using "requires" instead "tool_requires"?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: DominikWunderlich
issue_15163: state: open
title: [question] ConanException: 'self.options' access in 'package_id()' method is forbidden
body: ### What is your question?

The [package_id](https://docs.conan.io/2.0/reference/conanfile/methods/package_id.html) documentation provides the following example:

> If you need to implement custom behaviors in your recipes but also need this logic, it must be explicitly declared:
> ```python
> def package_id(self):
>     if conanfile.options.get_safe("header_only") or conanfile.package_type is PackageType.HEADER:
>         conanfile.info.clear()
>     self.info.settings.rm_safe("compiler.libcxx")
>     self.info.settings.rm_safe("compiler.cppstd")
> ```
(`conanfile` needs to be replaced by `self`; probably a copy-paste mistake)

Similarly the [conan-center-index docs](https://github.com/conan-io/conan-center-index/blob/master/docs/adding_packages/conanfile_attributes.md) state:

> Recipes with such option should include the following in their package_id method
> ```python
> def package_id(self):
>    if self.options.header_only:
>       self.info.clear()
> ```
> ensuring that, when the option is active, the recipe ignores all the settings and only one package ID is generated.

But using any of these approaches raises the following error:
```
ConanException: 'self.options' access in 'package_id()' method is forbidden
```

By looking at some conan center recipes and through some trial and error I figured out, that the following works:
```python
if self.info.options.header_only: ...
# or
if self.info.options.get_safe("header_only") or self.package_type is PackageType.HEADER: ...
```
I am fairly new to conan, so I am not quite sure if this is the correct/recommended way? If so, then the docs should be corrected. If not, what is? The documentation of the [info](https://docs.conan.io/2.0/reference/conanfile/attributes.html#info) attribute unfortunately does not provide any information on what methods and attributes it has.

Thanks for your help!

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: petwu
issue_15157: state: open
title: [feature] Predicate extraction filter for tools.get/untargz
body: ### What is your suggestion?

I found myself needing a variant of `tools.get` which would:
1. Play well with the download cache
2. Let me filter extracted entries via code (regex was insufficient, I wanted to exclude examples and docs in various locations within the directory tree)

I've implemented this privately by copying and customizing upstream conan's code inside a locally-developed recipe, and it looks something like this (note the `predicate` argument):
```
def _customized_untargz(filename, destination=".", predicate=None, strip_root=False):
    """
    See conans.client.tools.files.untargz.
    """
    import tarfile
    with tarfile.TarFile.open(filename, 'r:*') as tarredgzippedFile:
        if not predicate and not strip_root:
            tarredgzippedFile.extractall(destination)
        else:
            members = tarredgzippedFile.getmembers()

            if strip_root:
                names = [n.replace("\\", "/") for n in tarredgzippedFile.getnames()]
                common_folder = os.path.commonprefix(names).split("/", 1)[0]
                if not common_folder and len(names) > 1:
                    raise ConanException("The tgz file contains more than 1 folder in the root")
                if len(names) == 1 and len(names[0].split("/", 1)) == 1:
                    raise ConanException("The tgz file contains a file in the root")
                # Remove the directory entry if present
                members = [m for m in members if m.name != common_folder]
                for member in members:
                    name = member.name.replace("\\", "/")
                    member.name = name.split("/", 1)[1]
                    member.path = member.name
                    if member.linkpath.startswith(common_folder):
                        # https://github.com/conan-io/conan/issues/11065
                        linkpath = member.linkpath.replace("\\", "/")
                        member.linkpath = linkpath.split("/", 1)[1]
                        member.linkname = member.linkpath
            if predicate:
                members = list(filter(lambda m: predicate(m.name),
                                      tarredgzippedFile.getmembers()))
            tarredgzippedFile.extractall(destination, members=members)


def _customized_tools_get(
    url, sha256="", destination=".", filename="", predicate=None, strip_root=False
):
    """
    Code copied from conans.tools.get, to customize extraction logic,
    because ortools has a large archive and we'd like to avoid extracting
    unneeded files.
    """
    url_base = url[0] if isinstance(url, (list, tuple)) else url
    if "?" in url_base or "=" in url_base:
        raise ConanException("Cannot deduce file name from the url: '{}'.")
    filename = os.path.basename(url_base)
    if not filename.endswith(".tar.gz"):
        raise ConanException("Unexpected ortools archive format.")

    # Forwarding kwargs in case they have a hash (for download cache).
    tools.download(url=url, sha256=sha256, filename=filename)
    try:
        _customized_untargz(
            filename=filename,
            destination=destination,
            predicate=predicate,
            strip_root=strip_root,
        )

    finally:
        os.unlink(filename)
```

I recall discussing this with conan devs back in June at C++Now, so here's the followup :)

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: nextsilicon-itay-bookstein
issue_15155: state: open
title: [question] How to tell binary in one dependency where to find shared library in another one?
body: ### What is your question?

Hi,

I'm trying to build my own grpc recipe.
This works well, however, when I build its dependency protobuf as shared library and then try to use an executable contained in the grpc package (the grpc cpp plugin for protobuf) from within CMake, there is an error complaining that a shared library contained in the protobuf package cannot be found.

I tried to reduce it to an example that uses the grpc recipe from the conan center (cf. https://github.com/conan-io/conan-center-index/blob/master/recipes/grpc/all/conanfile.py).

I downloaded this recipe and forced protobuf to always be built as shared library (and grpc still as static library - in my opinion this shouldn't make a difference) by adding a line to the end of the `configure` step in the grpc recipe:
```
def configure(self):
    if self.options.shared:
        self.options.rm_safe("fPIC")
        self.options["protobuf"].shared = True

        if cross_building(self):
            self.options["grpc"].shared = True

    # This is the line I added.
    self.options["protobuf"].shared = True
```

I locally built this package by running `conan create . 1.54.3@test/test`.

Then I set up a simple example:
conanfile.txt
```
[requires]
grpc/1.54.3@test/test
protobuf/3.21.12

[generators]
CMakeDeps

[options]
grpc:shared=False
protobuf:shared=True
```

CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.16...3.25 FATAL_ERROR)

project(test_conan VERSION 0.0.1 LANGUAGES CXX)

if(NOT EXISTS "${PROJECT_BINARY_DIR}/conan.cmake")
    file(DOWNLOAD "https://raw.githubusercontent.com/conan-io/cmake-conan/73734d0b7ff3c9bf7e0661e2c6c709b8520926cd/conan.cmake"
           "${PROJECT_BINARY_DIR}/conan.cmake" TLS_VERIFY ON
    )
endif()

include(${PROJECT_BINARY_DIR}/conan.cmake)

conan_cmake_install(PATH_OR_REFERENCE ${PROJECT_SOURCE_DIR} BUILD missing)

list(PREPEND CMAKE_PREFIX_PATH ${PROJECT_BINARY_DIR})

find_package(gRPC CONFIG REQUIRED MODULES cpp_plugiasdn)
find_package(protobuf CONFIG REQUIRED)


set(_protos test.proto)
add_library(test-conan STATIC ${_protos} )

target_link_libraries(test-conan PUBLIC protobuf::libprotobuf  gRPC::grpc)

set(GENERATED_PROTO_DIR "${CMAKE_CURRENT_BINARY_DIR}/include")
file(MAKE_DIRECTORY "${GENERATED_PROTO_DIR}")

# generate datatypes from proto 
protobuf_generate(
    TARGET test-conan
    OUT_VAR PROTO_GENERATED_FILES
    IMPORT_DIRS ${CMAKE_CURRENT_SOURCE_DIR}
    PROTOC_OUT_DIR "${GENERATED_PROTO_DIR}"
)

# generate grpc services from proto   
protobuf_generate(
    TARGET test-conan
    OUT_VAR PROTO_GENERATED_FILES
    LANGUAGE grpc
    GENERATE_EXTENSIONS .grpc.pb.h .grpc.pb.cc
    PLUGIN "protoc-gen-grpc=${GRPC_CPP_PLUGIN_PROGRAM}"
    IMPORT_DIRS ${CMAKE_CURRENT_SOURCE_DIR}
    PROTOC_OUT_DIR "${GENERATED_PROTO_DIR}"
)
```

test.proto
```
syntax = "proto3";
package test.proto;


message Empty {}

message Flag {
    bool active = 1;
}
```

When I try to build the cmake project I get the error:
```
[build] .../.conan/data/grpc/1.54.3/test/test/package/f753eb55d7835e7de1b45861c2f5500409a77b2c/bin/grpc_cpp_plugin: error while loading shared libraries: libprotoc.so.32: cannot open shared object file: No such file or directory
[build] --grpc_out: protoc-gen-grpc: Plugin failed with status code 127.
```

I added the `virtualrunenv` generator to the list of generators in the `conanfile.txt` with no success.
I see that the grpc recipe uses `VirtualRunEnv` and also does some `DYLD_LIBRARY` magic on MacOS.

How can I correctly set the environment variables on Linux and Windows?

Thanks and best regards
oz




### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ottmar-zittlau
issue_15147: state: open
title: [question] Using internal package requires generated files
body: ### What is your question?

Hi,

we have several packages that uses VS + MSBuild as the build system.
we use conan 2.x
let's say on package 'p' we declare 2 components: 'x' and 'y'.

when consumers of p will invoke their generate method they will get x and y data suitable for their build system (assuming we implemented package_info with the data).

but let's say y require x internally ? can we somehow create / consume conan generated files ?
I thought maybe if I declare the components relation in the layout method these data will be generated for me, but it wasn't.

of course for a more modern build system, it is straight forward to declare the relation between the components, but in MSBuild, we need to create props file by hand and maintain it, and when the data is already generated by conan it feels not correct to do so...

is there any existing solution for retrieving the components data within the build context ?



### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: mikirothman
issue_15146: state: open
title: [question] Scons Deps generator within build requirements
body: ### What is your question?

Hi,
I was having some confusion regarding intergrating the sconsdeps or scons generator in the conanfile.py
`
class ZoneRecipe(ConanFile):
    # Package binary configuration
    settings = "os", "compiler", "build_type", "arch"
    package_type = "application"


    def requirements(self):
        self.requires("zlib/1.3")
        self.requires("robin-hood-hashing/3.11.5")
        
        # Add base64 dependency for Windows
        if self.settings.os == "Windows":
            self.requires("base64/0.4.0")

    def build_requirements(self):
        # Use the system's CMake for Windows
        if self.settings.os != "Windows":
            self.tool_requires("SConsDeps/4.3.0")`

This does not seem to work. Can you provide me a work around for this. Any version of scons will work. Basically I want to know how to use scons as a generator in this.

Thanks,
Priyank

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: priyank31malhotra
issue_15145: state: open
title: [question] Cross-compile: why Conan chooses build iso host package
body: ### What is your question?

Hi! I am trying to convert the recipe to package a Yocto SDK that I posted earlier [here](https://github.com/conan-io/conan/issues/5059#issuecomment-696059864) to Conan 2.0.

I basically got it working, the `conan create` command already works fine.

However with a `conan install` command Conan chooses the Boost package from the Yocto SDK i.s.o. the Conan cross-compiled Boost package. That doesn't work because the CCI Boost recipe declares an extra target boost::boost. 
I prevented this by setting `CMAKE_IGNORE_PATH` just before the `find_package(Boost ...)` call:

```
set(CMAKE_IGNORE_PATH ${CMAKE_SYSROOT}/usr/lib/cmake/Boost-1.71.0)
find_package(Boost ${BOOST_MIN_VERSION} REQUIRED COMPONENTS system log unit_test_framework locale)
set(CMAKE_IGNORE_PATH "")
```

This prevents that the SDK Boost is choosen, however Conan then continues to choose the _build_ Boost package i.s.o. the _host_ package and this of course results in a link error:
[ 66%] Linking CXX shared library libdqlog.so
/home/wdobbe/.conan2/p/b/boost4d56ca78cf7bb/p/lib/libboost_locale.so: file not recognized: file format not recognized

Does anyone have an idea why Conan here suddenly chooses a build context package? It chooses the host package for all other dependencies. Some tips how to continue debugging are also appreciated.

Thanks in advance

ps: the recipe to package the Yocto SDK can be found [here](https://github.com/wdobbe/conan-yocto-sdk) but is work-in-progress, still contains some hard-coded stuff.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: wdobbe
issue_15143: state: open
title: [question] Hot to propagate `tool_requires` dependency to consumer packages.
body: ### What is your question?

I have a forked `gtest` conan package which uses a custom tool when defining `ctest` targets ( `add_test` will have this tool as a parameter ). This custom tool is built using conan. It has a `package_type = 'application'` set.

Using this tool with `self.tool_requires('the_tool/[~1]@mycompany/main')` works well and fine when building `gtest` itself, but the issue is that I also need to specify in the consumers of my forked `gtest` package this build dependency. 

If I do not specify this `tool_requires` dependency, the binary cannot be found because it will not be located in the `PATH`.

How can I tell to my consumers that they should use the `build_requires` for this package also. This is an implementation detail in a way, and setting this `tool_requires` to all consumers is cumbersome. 

I am also building for emscripten platform, where this tool is not build as an emscripten application, but must be available to `ctest` as an host application for the device on which the test is ran.

Is there an easy way to transitively propagate the `tool_requires` dependency?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: lmglmg
issue_15142: state: open
title: [bug] lru code broke with 2.0.14
body: ### Environment details

* Operating System+version: MacOS 14, Windows 10
* Compiler+version: various
* Conan version: 2.0.14
* Python version: various


### Steps to reproduce

I can only reproduce it in CI. There Conan 2.0.13 might have ran before on the machine. I'm executing `conan install` with a custom profile.

The following backtrace can be found in the output:
```
[2023-11-20T11:09:44.773Z]    actual-err> ======== Computing dependency graph ========
[2023-11-20T11:09:44.773Z]    actual-err> ERROR: Traceback (most recent call last):
[2023-11-20T11:09:44.773Z]    actual-err>   File "conan\cli\cli.py", line 272, in main
[2023-11-20T11:09:44.773Z]    actual-err>   File "conan\cli\cli.py", line 172, in run
[2023-11-20T11:09:44.773Z]    actual-err>   File "conan\cli\command.py", line 125, in run
[2023-11-20T11:09:44.773Z]    actual-err>   File "conan\cli\commands\install.py", line 58, in install
[2023-11-20T11:09:44.773Z]    actual-err>   File "conan\api\subapi\graph.py", line 148, in load_graph_consumer
[2023-11-20T11:09:44.773Z]    actual-err>   File "conan\api\subapi\graph.py", line 180, in load_graph
[2023-11-20T11:09:44.773Z]    actual-err>   File "conans\client\graph\graph_builder.py", line 51, in load_graph
[2023-11-20T11:09:44.773Z]    actual-err>   File "conans\client\graph\graph_builder.py", line 90, in _expand_require
[2023-11-20T11:09:44.773Z]    actual-err>   File "conans\client\graph\graph_builder.py", line 262, in _create_new_node
[2023-11-20T11:09:44.773Z]    actual-err>   File "conans\client\graph\graph_builder.py", line 210, in _resolve_recipe
[2023-11-20T11:09:44.773Z]    actual-err>   File "conans\client\graph\proxy.py", line 23, in get_recipe
[2023-11-20T11:09:44.773Z]    actual-err>   File "conans\client\graph\proxy.py", line 37, in _get_recipe
[2023-11-20T11:09:44.773Z]    actual-err>   File "conans\client\cache\cache.py", line 60, in recipe_layout
[2023-11-20T11:09:44.773Z]    actual-err>   File "conan\internal\cache\cache.py", line 99, in get_recipe_layout
[2023-11-20T11:09:44.773Z]    actual-err>   File "conan\internal\cache\db\cache_database.py", line 73, in get_recipe
[2023-11-20T11:09:44.773Z]    actual-err>   File "conan\internal\cache\db\recipes_table.py", line 105, in get_recipe
[2023-11-20T11:09:44.773Z]    actual-err> TypeError: _.__new__() missing 1 required positional argument: 'lru'
```

The code in `conan\internal\cache\db\recipes_table.py` was last touched with: 469fb2cf45b2cecbbc58933630622f0e7d1bcf38 (by @memsharded).

### Logs

_No response_
user: gjasny
issue_15134: state: open
title: [feature] Remove Elbrus support
body: ### What is your suggestion?

Elbrus is heavily used by russian government and for military purposes. There are already multiple sanctions against the Russian processor manufacturers across the world. IMO conan shouldn't support this architecture.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Nekto89
issue_15132: state: open
title: [feature] separate migrations for $CONAN_HOME and the local cache
body: ### What is your suggestion?

Currently, conan assumes a 1-1 relationship between $CONAN_HOME directories and local cache directories when 
performing migrations.   I suggest that they are each migrated separately, with their own `version.txt` and `migrations/` files.

this is a followup to: 

https://github.com/conan-io/conan/pull/15130
https://github.com/conan-io/conan/issues/15129

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: smoofra
issue_15122: state: open
title: [feature] Would like a status bar for uploading conan packages 
body: ### What is your suggestion?

# Request Description

It would be really helpful if there were a real time updating status bar indicating the progress and speed/rate of conan package uploads for users. This lets the user know if their system is frozen, or if the server is responding, and approximately how long the upload will take, or if there are issues with the connection speed.

# Prototype work

For my own purposes I inserted a simple prototype of the desired functionality into conans/client/rest/file_uploader.py into the function `_upload_file` using the tqdm library. Introducing this kind of dependency into conan is probably undesirable, but the result is a good example of what is being requested.

```python
def _upload_file(self, url, abs_path,  headers, auth):
        with open(abs_path, mode='rb') as file_handler:
            try:
                filesize = os.path.getsize(abs_path)
                response = self._requester.put(url, 
                                               data=tqdm(file_handler, 
                                                         total=filesize, 
                                                         unit='B',unit_scale=True), 
                                               verify=self._verify_ssl,
                                               headers=headers, auth=auth)
                self._handle_400_response(response, auth)
                response.raise_for_status()  # Raise HTTPError for bad http response status
                return response
            except ConanException:
                raise
            except Exception as exc:
                raise ConanException(exc) 
```

## Prototype Behavior

![image](https://github.com/conan-io/conan/assets/115578984/c08ca239-8fdd-44bb-af4c-a76db78db448)



### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: timviola-cmi
labels: component: ux: No changes to core business logic
issue_15120: state: open
title: [bug] !!!! Release URLs don't specify architecture.
body: ### Environment details

I wouldn't expect this from authors of a multi-arch package manager..

* Operating System+version: Ubuntu 20.04 arm64v8
* Compiler+version:  N/a
* Conan version: 2.0.13
* Python version: N/A

Should there be a conanfile to build conan?


### Steps to reproduce

1. Boot up your favourite arm64 linux 20.04 docker image
2. Go to releases page
3. Download the [debian package for Linux/64](https://github.com/conan-io/conan/releases/download/2.0.13/conan-ubuntu-64.deb)
4. Try to install the .deb package



### Logs

 > [base  8/17] RUN dpkg -i conan-ubuntu-64.deb:
#12 2.001 dpkg: error processing archive conan-ubuntu-64.deb (--install):
#12 2.001  package architecture (amd64) does not match system (arm64)
#12 2.007 Errors were encountered while processing:
#12 2.007  conan-ubuntu-64.deb
user: jacobfriedman
issue_15119: state: open
title: [feature] Add named dependencies 
body: ### What is your suggestion?

Hello!

I noticed that there is some requirements by users to be able have several dependencies with the same name but with differences in versions, options or settings:
https://github.com/conan-io/conan/issues/660
https://github.com/conan-io/conan/issues/4407

I faced with both of this problem: one of my package depends on openssl 3.0 and openssl 1.0 at the same time (in tests). And one of my package depends on some package with different options. There is one workaround for this: include name version or option in name of package. But it still workaround...

I think that this problem can be resolved by adding custom names to dependencies.

```python
self.requires("pkgA/1.0")
self.requires("pkgA/2.0", alias="pkgA_2")
self.requires("pkgA/1.0", options={"option": "value"}, alias="pkgA_modified")
```

So, generators can search this packages by alias names instead of real names, hash of the requirements should contains alias names conaninfo.txt should contain aliases names instead of original package names. 

May be there are some restrictions in implementations of this. But I just want to show you a possible concept.

What do you think about this?

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: lo1ol
issue_15117: state: open
title: [question] buildenv_info confusion
body: ### What is your question?

I'm a bit confused by the new environment handling and the multitude of new variables that have been introduced. I was under the impression that `buildenv_info` should be used to store environment variables required for building. So I changed all of our toolchain SDK recipes so that they do something like

```python
def package_info(self):
  self.buildenv_info.define("CC", "arm-oe-linux-gnueabi-gcc")
  self.buildenv_info.define("CXX", "arm-oe-linux-gnueabi-g++")
  for v in path:
    self.buildenv_info.append_path("PATH", v)
```

instead of the previous approach where we used `env_info`.

The compiler executable names are relative paths so they rely on `PATH` being set correctly. Now when I use this SDK recipe as a `tool_requires` in a consumer, the CMake build fails because `arm-oe-linux-gnueabi-gcc` is not found. I cannot find the `PATH` anywhere in the generated toolchain file, whereas `CC` and `CXX` are transferred correctly to the corresponding CMake settings. However, when I add all `PATH` entries to `cpp_info.bindirs` instead, the CMake build works.

Now the question is if this is intended? Do I have to add an additional `VirtualBuildEnv` generator to the consumer to make it work correctly? I find it a bit illogical that `PATH` is not applied to CMake builds whereas everything else is picked up from `buildenv_info`.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jasal82
issue_15113: state: open
title: [feature] support OpenHarmony System
body: ### What is your suggestion?

Hello, 
    OpenHarmony is an open source project incubated and operated by the OpenAtom Foundation, with the goal of building an intelligent terminal device operating system framework and platform for the all-scene, all-connected and all-intelligent era, and promoting the prosperity and development of the Internet of everything industry.Open source repository address: https://openharmony.gitee.com/
    We used conan to compile the open source library, but found that conan does not support OpenHarmony .Hope to support this system.
Thanks

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fengozl
issue_15107: state: open
title: [bug] conan fails to resolve build_require's requirement range
body: ### Environment details

* Operating System+version: macOS
* Compiler+version: apple-clang
* Conan version: 2.0.13
* Python version: 3.11.4

Consider the following piece of conanfile of `myPkg`:
```
    def requirements(self):
        self.build_requires("package_A/1.4.10")
        self.build_requires("package_B/3.14.1")
```
The recipe of `package_B` contains
```
    def requirements(self):
        self.requires("package_A/[>=1.4.10 <2.0.0]")
```

New version of `package_A` is introduced - `1.4.11`.
Now `myPkg` fails to build without any changes to conanfile.

Looks like, here is the situation, where `build_requires` version of `package_A` (1.4.10) conflicts with resolved `requires` range of `package_B` - 1.4.11. I expected, that `build_requires` version should be overriden (resolved) to 1.4.10, as it requested explicitly.

IMO, is such case, requirements of `pacakge_B` should be treated as `build_requirements` of `myPkg`, as `package_B` itself was requested as `build_require`. And resolved correctly.

Conan exits with error:
```
ERROR: Runtime Error: Could not process 'pacakge_B/3.14.1' with 'package_A/1.4.11'.
```


### Steps to reproduce

_No response_

### Logs

_No response_
user: apyvovar
issue_15100: state: open
title: [question] Transitive handling of options defined in a requirement
body: ### What is your question?

Hi everyone,

I'm using conan 1.61, python 3.10.

I have some questions regarding the handling of options in requirements and downstream conan recipes using those requirements.
I'll try to explain with the option `shared`, because it is common to define it in conanfiles, but it might probably be any other option (see Footnote).

I have three conanfiles.

---
conanfile.py of `lib_a`:
```py
class LibAConanFile(ConanFile):
    name = "lib_a"
    options = { "shared": [True, False] }
    default_options = { "shared": False }
    package_type = "shared-library"
    # [...]
```
Let's say, `lib_a` was created with `shared=False` and `shared=True`, so both variants exist in the conan cache.

---
conanfile.py of `package_a` requiring `lib_a`:
```py
class PackageAConanFile(ConanFile):
    name = "package_a"
    package_type = "shared-library"
    # [...]
    
    def requirements(self):
        self.requires("lib_a/1.0.0")
```
Let's say, `package_a` was created with `lib_a:shared=True`.

---
conanfile.py of `package_b` requiring `package_a`:
```py
class PackageBConanFile(ConanFile):
    name = "package_b"
    package_type = "shared-library"
    # [...]
    
    def requirements(self):
        self.requires("package_a/1.0.0")
```
Let's say, I want to create `package_b` with `lib_a:shared=False`.

To my understanding, the options provided for `lib_a` to create `package_a` and `package_b` collide. So I expected `conan create` to fail for `package_b`. But to my surprise, `conan create` went through successfully.

Could someone clarify why this doesn't fail?
Is the described behavior correct or is this a bug/feature in conan?
Or is there something I'm missing here?

For the concrete example of option `shared`, my thoughts are:
* If `package_a` is built with `lib_a:shared:True` and `package_a` doesn't copy any shared libraries (*.dll, *so) files from the `lib_a` into its own package folder, `lib_a` must exist in the conan cache when linking the library from `package_a`.
* If `package_b` is built with `lib_a:shared=False`, the required symbols for `lib_a` are missing for library `package_a` , because required `lib_a` package only provides the static libraries not built into `package_a`. So, linking `package_b` against `package_a` should fail and thus the given options for `lib_a` collide.

It gets even more _interesting_ if `lib_a` would provide more options (like e.g.. `boost` does with options `without_xxx`).

## Footnote
I tried the scenario with `boost/1.79` and options `boost:zlib=True` and `boost:bzip2=True` for `package_a` and `boost:zlib=False` and `boost:zlib=False` for `package_b`.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: PiJ82
issue_15099: state: open
title: [bug] PkgConfig not using buildenv?
body: ### Environment details

* Conan version: 1.61.0

### Steps to reproduce

When I use `PkgConfig` in a recipe which has a Yocto toolchain package in its build requirements the environment variables set by this package via `buildenv_info` are not visible to `PkgConfig`. However, when I set the same variables with `env_info` it works fine. I think this is not the intended behavior. Yocto toolchains set `PKG_CONFIG_PATH` so that the `pkg-config` executable can find the correct `.pc` files. Without this variable it will query the host system instead.

### Logs

_No response_
user: jasal82
issue_15098: state: open
title: [question] How to set cmake.cmake_layout:build_folder_vars in conan.conf? (Conan 1.x)
body: ### What is your question?

I cannot set `cmake.cmake_layout:build_folder_vars` in conan.conf (Conan 1.x):

```
D:\>conan config set tools.cmake.cmake_layout:build_folder_vars="['settings.compiler', 'options.shared']"

D:\>conan config get tools.cmake.cmake_layout:build_folder_vars
ERROR: 'cmake.cmake_layout:build_folder_vars' doesn't exist in [tools]
```
After `conan config set ...` conan.conf contains the following:
```
[tools]
cmake.cmake_layout:build_folder_vars = ['settings.compiler', 'options.shared']
```
I suspect the problem is in the comma character in the parameter name. Maybe some quoting is required?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: db4
issue_15097: state: open
title: CMake Test command failing for conan 2.0
body: ### What is your question?

Hi folks,

Currently facing the following error whilst running the conan build command

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
        cmake.test()

*********************************************************
Recipe 'conanfile.py (pkg/0.1)' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: conanfile.py (pkg/0.1): Error in build() method, line 51
        cmake.test()
        ConanException: Error 1 while executing


Not sure if I am missing anything in the recipe?  

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ujjwal1002
issue_15096: state: open
title: How to create alias in Conan 2.0
body: ### What is your question?

'alias' is not a Conan command. See 'conan --help'.

How to create alias in Conan 2.0?
Problem:
I have a package that has an option of target. target(-o target=target1) value can be target1 , target2... 5 possible values for my package.
If my current package version is 2.4. I have 5 packages with version 2.4 each package corresponds to one target.
Now some change in code only needed for target 3 I increased version and 2.5 is available for target 3 and 2.4 for other 4 targets. Now if I want to download package for target 1 , version range is resolving to 2.5 but 2.5 target 1 package will now be there. I solved this using alias in Conan 1.0
pkg_name/target_1 -> latest available for that target.
With alias removed for 2.0.My code is broken. How to solve this?
conan -v    
Conan version 2.0.13

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: rajesh-kare
issue_15095: state: open
title: [question] How to do override through CLI arguments?
body: ### What is your question?

Hi,

I'm currently trying to migrate to conan 2.
I want to be able to download specific requirements. Versions that I want to use are different from the ones in the recipe. In conanv1 I was using "--require-override REQUIRE_OVERRIDE" option. In conanv2 "--requires" analogue doesn't seem to be working in the same way. Do I need to create conanfile.py for this and explicitly mark `self.requires("....", override=True)`?

```
conan install --requires=xsimd/11.1.0 --requires=xtl/0.7.4 "--options:host=xsimd/*:xtl_complex=True"

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=20
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows
[options]
xsimd/*:xtl_complex=True

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=20
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows


======== Computing dependency graph ========
xsimd/11.1.0: Not found in local cache, looking in remotes...
xsimd/11.1.0: Checking remote: conancenter
xsimd/11.1.0: Downloaded recipe revision 9d638743dfece5733e79be50af650645
Graph root
    cli
Requirements
    xsimd/11.1.0#9d638743dfece5733e79be50af650645 - Downloaded (conancenter)
ERROR: Version conflict: Conflict between xtl/0.7.5 and xtl/0.7.4 in the graph.
Conflict originates from xsimd/11.1.0

Run conan graph info with your recipe and add --format=html to inspect the graph errors in an easier to visualize way.

```



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Nekto89
issue_15094: state: open
title: What's the proper Conan 2.0 way of storing additional attributes in conan packages?
body: ### What is your question?

Hi everybody!

In our company, we used to use the `self.user_info` field in the ``def package_info(self)` method to store additonal attributes of our packages (conan 1.x). They are file system paths into the package folder where we store meta-info such as path to a license info file (SPDX JSON); something like that:

```python
def package_info(self):
            self.user_info.license_spdx_file_path = <some path into the package>
```

We were then later able to collect all of these files in the dependency tree to, for example, build a list of open source licenses used in our software product by inspecting the `deps_user_info` array in the package consuming all of the other ones.

What would the proper conan 2.x way of doing something like this look like? We could of course use some conventions on those special files so we can scan the package folders without having an attribute in the conanfile.py, but maybe you have a much better solution in mind...

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jegabe
issue_15087: state: open
title: [question] Problems with installing Poco through Conan
body: ### What is your question?

Hi, The last couple of days i have been trying to install Poco with the help of Conan. have been following the official guide [Build a simple CMake project using Conan](https://docs.conan.io/2/tutorial/consuming_packages/build_simple_cmake_project.html). Conan seems to be able to download Poco, but the setup of the libraries seems to be missing? The final steps gives me either the error that PocoFoundation.lib cannot be found/open, or the error that it cannot find or include 'Poco/..... I have tried searching for the library PocoFoundation.lib in my entire system, but it does not seem to exist. I am using Windows OS (windows 11) and Visual Studio 2022.

Conan version 2.0.13
cmake version 3.26.4-msvc4

Commands:

`conan install . --output-folder=build --build=missing
`
`cd .\build\
`
`cmake .. --preset conan-default -DCMAKE_BUILD_TYPE=Release
`
`cmake --build .
`

The final steps produces: 
```
PS C:\Users\ronnimad\source\repos\PWYPWebcrawler\build>  cmake --build .
MSBuild version 17.7.2+d6990bcfa for .NET Framework

  Checking Build System
  Building Custom Rule C:/Users/ronnimad/source/repos/PWYPWebcrawler/CMakeLists.txt
  PWYPWebcrawler.cpp
C:\Users\ronnimad\source\repos\PWYPWebcrawler\PWYPWebcrawler\PWYPWebcrawler.cpp(6,10): fatal  error C1083: Cannot open include file: 'Poco/Net/HTTPClien
tSession.h': No such file or directory [C:\Users\ronnimad\source\repos\PWYPWebcrawler\build\PWYPWebcrawler.vcxproj]
```

I have also gotten a different error:
`LINK : fatal error LNK1104: cannot open file 'PocoFoundation.lib' [C:\Users\ronnimad\source\repos\PWYPWebcrawler\build\PWYPWebcrawler.vcxproj]`

Is there some extra steps that i am missing?


[CMakeLists.txt](https://github.com/conan-io/conan/files/13328445/CMakeLists.txt)
[conanfile.txt](https://github.com/conan-io/conan/files/13328446/conanfile.txt)




### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: MadeleineKongshavn
issue_15084: state: open
title: [question] How to deal with duplicated find_package(packageFoo) on a large project
body: ### What is your question?

I maintain the conan integration on a big, private monorepo. Some portions of the monorepo are submodules that can be built standalone or as a part of the big monolith, so we have duplicated `find_package()` calls, in situations where a submodule and the monolith depend on the same library.

The old, deprecated generators were fine with it. E.g. when using `cmake_find_package` and `cmake_find_package_multi`, for this code:
```cmake
find_package(GTest REQUIRED)
message("\n\n")
find_package(GTest REQUIRED)
message("\n\n")
include(GoogleTest)
```
I get:
```
conanfile.txt: Generated graphinfo
-- Conan: Using autogenerated FindGTest.cmake
-- Found GTest: 1.13.0 (found version "1.13.0") 
-- Library gtest_main found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest_main.a
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest_main.a
-- Library gmock_main found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock_main.a
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock_main.a
-- Library gmock found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock.a
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock.a
-- Library gtest found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest.a
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest.a
-- Library gtest found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest.a
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest.a
-- Library gmock found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock.a
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock.a
-- Library gmock_main found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock_main.a
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock_main.a
-- Library gtest_main found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest_main.a
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest_main.a





-- Conan: Using autogenerated FindGTest.cmake
-- Library gtest_main found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest_main.a
-- Skipping already existing target: CONAN_LIB::GTest_gtest_main
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest_main.a
-- Library gmock_main found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock_main.a
-- Skipping already existing target: CONAN_LIB::GTest_gmock_main
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock_main.a
-- Library gmock found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock.a
-- Skipping already existing target: CONAN_LIB::GTest_gmock
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock.a
-- Library gtest found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest.a
-- Skipping already existing target: CONAN_LIB::GTest_gtest
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest.a
-- Library gtest found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest.a
-- Skipping already existing target: CONAN_LIB::GTest_gtest_gtest
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest.a
-- Library gmock found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock.a
-- Skipping already existing target: CONAN_LIB::GTest_gmock_gmock
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock.a
-- Library gmock_main found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock_main.a
-- Skipping already existing target: CONAN_LIB::GTest_gmock_main_gmock_main
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock_main.a
-- Library gtest_main found /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest_main.a
-- Skipping already existing target: CONAN_LIB::GTest_gtest_main_gtest_main
-- Found: /home/eriff/.conan/data/gtest/1.13.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest_main.a
```
It is not ideal because we search for the package twice, but it works. Is there a reason why we don't cache the first search? We do cache the transitive dependencies. Gtest doesn't have any but for some other packages that do have I get stuff like
```
-- Conan: Dependency Eigen3 already found
-- Conan: Dependency Boost already found
```
Caching the searches would improve performance on large repos with duplicated find_packages calls.

Anyways, when I use the modern `CMakeDeps` generator, I get warnings for the same code.
```
conanfile.txt: Generated conaninfo.txt
conanfile.txt: Generated graphinfo
-- Conan: Component target declared 'GTest::gtest'
-- Conan: Component target declared 'GTest::gtest_main'
-- Conan: Component target declared 'GTest::gmock'
-- Conan: Component target declared 'GTest::gmock_main'
-- Conan: Target declared 'gtest::gtest'
-- Found GTest: 1.13.0 (found version "1.13.0") 



CMake Warning at _build/conan/module-GTestTargets.cmake:25 (message):
  Target name 'GTest::GTest' already exists.
Call Stack (most recent call first):
  _build/conan/FindGTest.cmake:16 (include)
  CMakeLists.txt:41 (find_package)


CMake Warning at _build/conan/module-GTestTargets.cmake:31 (message):
  Target name 'GTest::Main' already exists.
Call Stack (most recent call first):
  _build/conan/FindGTest.cmake:16 (include)
  CMakeLists.txt:41 (find_package)
```
I found the guard where warning is coming from on the generated cmake files:
```cmake
if(NOT TARGET GTest::GTest)
    add_library(GTest::GTest INTERFACE IMPORTED)
    set_property(TARGET GTest::GTest PROPERTY INTERFACE_LINK_LIBRARIES GTest::gtest)
else()
    message(WARNING "Target name 'GTest::GTest' already exists.")
endif()
```
Is there a reason for this warning? Could we cache the find_package calls just like we cache the ones for the transitive dependencies? It would remove this warning and also speed up the cases where the same package is searched for many times.

Thanks,

Eric.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ericriff
issue_15079: state: open
title: [question] Forwarding env_info / buildenv_info to cmake using CMakeDeps
body: ### What is your question?

Hello, I am updating a legacy recipe that declared some `env_info` variables. In the past, consuming with `cmake_find_package_multi`, calling a `find_package` on the target would import the variables in cmake.

I am not able to reproduce this anymore. I tried `buildenv_info` and debugging with `VirtualBuildEnv`, I get to the point where the vars are in the `bat` script. But that's as far as I got.

Using conan 1 CMakeDeps (+ CMakeToolchain), how do you forward environment variables from a dependency recipe to the final cmake configure script?

ty!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: p-groarke
issue_15078: state: open
title: [bug] lock create ignore build options (conan 1.x)
body: ### Environment details

Operating System+version: windows 10
Compiler+version: msvc v142
Conan version: 1.61.0
Python version: 3.10.10


### Steps to reproduce

Hi I found that when using `conan lock create` with some package in both host and build context with different options, package in build context in lock file have options from host context rather that option defined for build context. 
Probably same issue happen when using package in build context with non default option.

Example:
```
conan lock create ... --options:host protobuf:shared=False --options:build protobuf:shared=True
```

I debug into [extend_build_requires](https://github.com/conan-io/conan/blob/develop/conans/client/graph/graph_builder.py#L73), here are created `new_options` that will later applied on package to create lock graph.
```
new_options = node.conanfile.build_requires_options._reqs_options
```
Only assignment to `build_requires_options` is in [graph_binaries.py](https://github.com/conan-io/conan/blob/develop/conans/client/graph/graph_binaries.py#L338). Based on that, these are backup of host options. But build options stored in `profile_build` are never accessed in `extend_build_requires`.
```
        # There might be options that are not upstream, backup them, might be for build-requires
        conanfile.build_requires_options = conanfile.options.values
```

I try to apply build options from `profile_build` on `new_options` [here](https://github.com/conan-io/conan/blob/develop/conans/client/graph/graph_builder.py#L83) and it works as expected
```
        if profile_build:  # Apply the fix only for the 2 profile scenario
            for k, v in profile_build.options._reqs_options.items():
                if k in new_options:
                    new_options[k].update(v)
                else:
                    new_options[k] = v
```

I'm not sure if this is proper fix and how to work with Options in profile without accessing private `_reqs_options` member.

### Note

I'm using conanfile.py as meta-package instead of conanfile.txt and it will be nice if build options can be accessed in `config_options` like host options (`self.options[<package>].<option-name> = value`). Similar to `settings` vs `settings_build` attribute.
user: hekrdla
issue_15076: state: open
title: Migrating the recipe to Conan 2.0, getting an error in the Ninja generator
body: ### What is your question?

Hi,

I am really new to the Conan developer framework,I wish to migrate my recipe to Conan 2, not sure how I can use Ninja with CMake, could you please help?

I am getting the following error

*********************************************************
Recipe 'conanfile.py (InterviewPrep/1.1.0)' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: conanfile.py (InterviewPrep/1.1.0): Error in build() method, line 59
        cmake.build()
        ConanException: Error 1 while executing



-------------------------------------------------------------------------------------------------------
conanfile.py
-------------------------------------------------------------------------------------------------------

```python
from conan import ConanFile
from conan.tools.cmake import CMake,CMakeToolchain,CMakeDeps,cmake_layout

from functools import lru_cache


class InterviewPrepConan(ConanFile):
    name = "InterviewPrep"
    version = "1.1.0"
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of Mylib here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False],}
    default_options = {"shared": False, "fPIC": True} # if shared is true, we would have this as a shared library
    
    generators="CMakeDeps","CMakeToolchain"
    exports_sources = (
        "CMakeLists.txt"
    )
    no_copy_source = True
    #The below method would be triggered iff you unset the no_copy_source variable
    #def export_source(self):
    #    self.copy("*")
    
#    def build_requirements(self):
#        self.build_requires("C:\DevSoft\Ninja\ninja-win")
    #def layout(self): # run this after adding cmake install code
        #cmake_layout(self,src_folder=self.source_folder)
    def test_requirements(self):
        self.test_requires("gtest/1.12.1")
    @property
    @lru_cache(1)
    def _cmake(self):
        cmake = CMake(self)
        if self.options.coverage:
            cmake.definitions["COVERAGE"]=True
        return cmake
    def build_requirements(self):
        self.requires("boost/1.79.0")
        self.requires("systemc/2.3.3")
        self.requires("magic_enum/0.8.1",override=True)
        self.requires("dlib/19.24")
        self.requires("hdf5/1.13.1")
        self.requires("xtensor/0.24.2")
        ##self.requires("SystemCVerification/2.0.1@minres/stable")
    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC
    def generator(self): #Preprocessor
        tc = CMakeToolchain(self)
        tc.generate()
        CMakeDeps(self).generate() #creates findBoost.cmake

    def build(self):
        cmake = CMake(self,generator='Ninja')
        cmake.configure(source_folder=self.source_folder)
        cmake.build()
        cmake.test(build_dir=self.build_folder,output_on_failure=True)
        # Explicit way:
        # self.run('cmake %s/hello %s'
        #          % (self.source_folder, cmake.command_line))
        # self.run("cmake --build . %s" % cmake.build_config)

    def package(self):
        self._cmake.install()
    def package_id(self):
        self.info.requires["systemc"].full_package_mode()
    def package_info(self):
        self.cpp_info.libs = ["hello"] 
```
### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ujjwal1002
issue_15069: state: open
title: [bug] Logging information missing from documentation
body: ### Environment details

_No response_

### Steps to reproduce

1. Visit Conan V2 [documentation](https://docs.conan.io/2/).
2. You will notice that there is no equivalent for the [V1 Logging Page](https://docs.conan.io/1/mastering/logging.html).

### Logs

_No response_
user: nadenf
issue_15057: state: open
title: [question] Conan packages 1.x <-> 2.x compatibility
body: ### What is your question?

Hi,
we are working doing the switch from Conan 1.x to Conan 2.x. As we have a lot of packages created and in use, I would like to clarify the back and forth compatibility of the packages consumed by the opposite Conan version.
The comment in the documentation leaves some room for interpretation, maybe you can specify it a little sharper for us.

_Also, a lot of effort has been made to backport necessary things to Conan 1.X to make the upgrade easier: Recipes using latest 1.X integrations will be compatible with Conan 2.0, and binaries for both versions will not collide and be able to live in the same server repositories._

Internally we fixed the Conan version to 1.51 means all packages should be created with the Conan API of that version. A quick try of consuming a package of this version with Conan v2.x failed.

Can you state since which version the compatibility should work seamlessly? 

many Thanks, Sam



### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: Tricksam
issue_15047: state: open
title: Correct encoding of make_program path for AutoTools + msys2
body: Changelog: (Bugfix): AutoTools  Describe here your pull request (fixes #15046)

- [x] Refer to the issue that supports this Pull Request. (fixes #15046)
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.
  I'd be happy to, but I'm not sure what docs would need to be updated
user: nmasseyKM
issue_15046: state: open
title: [bug] AutoTools.make() fails under MSYS2 with custom make program
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: Visual Studio 2022
* Conan version: 1.61.0
* Python version: 3.11.0


### Steps to reproduce

1. Choose an existing `autoconf` project as target. I used `libexif`
2. Modify `build_requirements()` to use current `make` package. Code snippet:
~~~
    def build_requirements(self):
        if self._settings_build.os == "Windows":
            self.win_bash = True
            if not self.conf.get("tools.microsoft.bash:path", check_type=str):
                self.tool_requires("msys2/cci.latest")
            else:
                self.tool_requires("make/4.4")

    def build(self):
        autotools = Autotools(self)
        autotools.configure()
        autotools.make()
~~~
3. Execute `conan create conanfile.py nmassey/devel`

### Logs

Sections of output
~~~
$ conan create conanfile.py nmassey/devel
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=Visual Studio
compiler.runtime=MDd
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
[conf]
tools.microsoft.bash:path=C:\msys64\usr\bin\bash.exe
tools.microsoft.bash:subsystem=msys2
libexif/0.6.24@nmassey/devel: Forced build from source
Build requirements
    make/4.4 from local cache - Cache
Build requirements packages
    make/4.4:01edd76db8e16db9b38c3cca44ec466a9444c388 - Cache
Installing (downloading, building) binaries...
make/4.4: Already installed!
libexif/0.6.24@nmassey/devel: Applying build-requirement: make/4.4
libexif/0.6.24@nmassey/devel: WARN: Build folder is dirty, removing it: C:\.build\37392e\1
libexif/0.6.24@nmassey/devel: Copying sources to build folder
libexif/0.6.24@nmassey/devel: Building your package in C:\.build\37392e\1
libexif/0.6.24@nmassey/devel: Generator txt created conanbuildinfo.txt
libexif/0.6.24@nmassey/devel: Calling generate()
libexif/0.6.24@nmassey/devel: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
libexif/0.6.24@nmassey/devel: Aggregating env generators
libexif/0.6.24@nmassey/devel: Calling build()
libexif/0.6.24@nmassey/devel: Calling:
 > "/c/.build/37392e/1/src/configure" --disable-shared --enable-static --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include --disable-docs --disable-nls --disable-rpath --disable-dependency-tracking 
----Running------
> "C:\.build\37392e\1\build-debug\conan\conanbuild.bat" && "C:\.build\37392e\1\build-debug\conan\msys2_mode.bat" && C:\msys64\usr\bin\bash.exe --login -c ^". \^"C:\.build\37392e\1\build-debug\conan\conanbuild.sh\^" ^&^& \^"/c/.build/37392e/1/src/configure\^" --disable-shared --enable-static --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include --disable-docs --disable-nls --disable-rpath --disable-dependency-tracking ^"
-----------------
~~~
Lots of config output
~~~
Configuration (libexif 0.6.24):
  Build
    Source code location:          /c/.build/37392e/1/src
    Compiler:                      /c/.build/37392e/1/src/compile cl -nologo
    Ship binaries in tarball:      false
    Use translations:              no
You may run "make" and "make install" now.
----Running------
> "C:\.build\37392e\1\build-debug\conan\conanbuild.bat" && "C:\.build\37392e\1\build-debug\conan\msys2_mode.bat" && C:\msys64\usr\bin\bash.exe --login -c ^". \^"C:\.build\37392e\1\build-debug\conan\conanbuild.sh\^" ^&^& C:\.build\c9af77\1\bin\gnumake.exe -j2^"
-----------------
~~~
...
~~~
[vcvarsall.bat] Environment initialized for: 'x64'
/usr/bin/bash: line 1: C:.buildc9af771bingnumake.exe: command not found
libexif/0.6.24@nmassey/devel: 
libexif/0.6.24@nmassey/devel: ERROR: Package '164640aad040835ac8988[239](https://dev2.sec.kmbs.us/dispatcher-phoenix/conan/libexif/-/jobs/254246#L239)3a96d89200694f04' build failed
libexif/0.6.24@nmassey/devel: WARN: Build folder C:\.build\37392e\1\build-debug
ERROR: Traceback (most recent call last):
  File "C:\Python311\Lib\site-packages\conans\errors.py", line 34, in conanfile_exception_formatter
    yield
  File "C:\Python311\Lib\site-packages\conans\client\conanfile\build.py", line 16, in run_build_method
    conanfile.build()
  File "C:\.conan\data\libexif\0.6.24\nmassey\devel\export\conanfile.py", line 104, in build
    autotools.make()
  File "C:\Python311\Lib\site-packages\conan\tools\gnu\autotools.py", line 58, in make
    self._conanfile.run(command)
  File "C:\Python311\Lib\site-packages\conans\model\conan_file.py", line 464, in run
    raise ConanException("Error %d while executing %s" % (retcode, command))
conans.errors.ConanException: Error 127 while executing C:\.build\c9af77\1\bin\gnumake.exe -j2
~~~
user: nmasseyKM
issue_15040: state: open
title: [question] Problem understanding a dependency in conancenter
body: ### What is your question?

For a while now, I try to get a new version of _mold_ into conancenter (see PR conan-io/conan-center-index#19152). The problem is, that one dependency seems to be missing. The package requires _onetbb/2021.3.0_, which in turn requires _hwloc/2.9.3_. But the _mold_ build cannot find the correct _onetbb_ package it's looking for (i.e. the one depending on exactly _hwloc/2.9.3_, see below for details).

Weirdly, the existing prebuilt _onetbb_ package on conancenter requires _hwloc/2.9.Z_, which conflicts with the following section in the documentation if I understand it correctly:

> **Embed mode**: When an application or a shared library depends on a header-only or a static-library, the dependencies binaries are copied or partially copied (depending on the linker) in the consumer binary. Also when a static library depends on a header-only library, it is considered that there will be embedding in the consumer binary of such headers, as they will also contain the implementation, it is impossible that they are a pure interface.

Unfortunately, nobody over there seems to know what's going on. Maybe somebody here can explain to me what's the problem and how to solve it?

This is the existing _onetbb_ packages on conancenter:
```
fbd41063c30b49345892a94c8747c6efed28b489
  info
    settings
      arch: x86_64
      build_type: Release
      compiler: gcc
      compiler.cppstd: 17
      compiler.libcxx: libstdc++11
      compiler.version: 11
      os: Linux
    options
      shared: True
      tbbbind: True
      tbbmalloc: True
      tbbproxy: True
    requires
      hwloc/2.9.Z
```

But this is the dependency, the _mold_ build expects:
```
onetbb/2021.3.0: WARN: Can't find a 'onetbb/2021.3.0' package binary 'd7a9f73b4f7a501a35ebea3234d4801bf5740350' for the configuration:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
[options]
shared=True
tbbbind=True
tbbmalloc=True
tbbproxy=True
[requires]
hwloc/2.9.3#30511a65bbe6044dab2139ab73cbbe2c:f651771e3392d8c689d4fdd4b39be363dfe184d3
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fschoenm
issue_15039: state: open
title: [bug] Cannot build cppcheck/2.12.1 in debug on Windows with Visual Studio 2022 compiler
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: Visual Studio 2022 17.7.4 (cl.exe 19.37.32824)
* Conan version: 2.0.13
* Python version:3.11.2




### Steps to reproduce

Sorry if I'm missing something. I'm also not sure if this is a me issue, a conan issue, or a cppcheck recipe issue.

Run the command specified in the Logs section. The build fails with the error
```
pcre dependency for RULES has not been found
```

I traced this to an cppcheck's `findDependencies.cmake` script is attempting to find `pcre` instead of `pcred`. The [conan recipe](https://github.com/conan-io/conan-center-index/blob/master/recipes/cppcheck/all/conanfile.py) attempts to work around this by applying a [patch ](https://github.com/conan-io/conan-center-index/blob/master/recipes/cppcheck/all/patches/0004-pcre-debuglib-name-2.12.patch) (if I understand how this works) to correct this limitation.

That patch does not appear to be working, and the build fails.

I could work around this if Conan would let me build cppcheck in release mode, regardless of my application build profile. IMO `tool_requires` dependencies should always build in Release by default.




### Logs

Command:
```
conan install --requires=cppcheck/2.12.1 --build=cppcheck* --settings build_type=Debug --settings compiler=msvc
```

Output:
```
CMake Error at cmake/findDependencies.cmake:36 (message):
  pcre dependency for RULES has not been found
Call Stack (most recent call first):
  CMakeLists.txt:15 (include)


-- Configuring incomplete, errors occurred!

cppcheck/2.12.1: ERROR:
Package 'd8a6306c2d70cd3e48ed9adc4a696e54bbf194ba' build failed
cppcheck/2.12.1: WARN: Build folder C:\Users\user\.conan2\p\b\cppcha3f024742435c\b\build\Debug
*********************************************************
Recipe 'cppcheck/2.12.1' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: cppcheck/2.12.1: Error in build() method, line 51
        cmake.configure()
        ConanException: Error 1 while executing
```
user: NightWulfe
issue_15037: state: open
title: [bug] find_package can't find all the dependencies
body: ### Environment details

* Operating System+version: ubuntu 22
* Compiler+version: 11.2
* Conan version: 2.0.13
* Python version: 3.10.12
*


### Steps to reproduce

In the config file, compile all libraries as dynamic libraries
```bash
[settings]
os=Linux
arch=armv8
compiler=gcc
compiler.cppstd=gnu17
compiler.version=11
compiler.libcxx=libstdc++11
build_type=Release

[options]
*:shared=True
```
build a conan package, for example ffmpeg/5.0, You can see that ffmpeg depends on x264
```bash
File: /home/lw/.conan2/p/b/ffmped7cdc6fda969b/p/lib/libavcodec.so.60.3.100

Dynamic section at offset 0xa736e8 contains 34 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libswresample.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libavutil.so.58]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libx264.so.164]
 0x0000000000000001 (NEEDED)             Shared library: [libx265.so.192]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libavcodec.so.60]
```
Using find_package in cmake depends on ffmpeg, but there is no libx264 library when link.
```bash
find_package(ffmpeg REQUIRED)

target_link_libraries(${PROJECT_NAME} PUBLIC 
    magic_enum::magic_enum 
    spdlog::spdlog_header_only
    zlmediakit::zlmediakit
    mpp::mpp 
    libsrtp::libsrtp 
    openssl::openssl 
    usrsctp::usrsctp
    ffmpeg::ffmpeg
    readerwriterqueue::readerwriterqueue
)
```
How to solve this issue, thanks

### Logs

```bash
/home/lw/Workspace/StreamServer/toolchain/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-g++ -O3 -DNDEBUG CMakeFiles/StreamServer.dir/application/main.cpp.o CMakeFiles/StreamServer.dir/application/sources/VideoCapture.cpp.o CMakeFiles/StreamServer.dir/application/sources/VideoEncoder.cpp.o CMakeFiles/StreamServer.dir/application/sources/StreamServer.cpp.o CMakeFiles/StreamServer.dir/application/sources/StreamSink.cpp.o -o StreamServer   -L/home/lw/.conan2/p/b/fmt4d76687e3ed16/p/lib  -L/home/lw/.conan2/p/b/zlmed2c9057539529b/p/lib  -L/home/lw/.conan2/p/b/libsrfade138bd1240/p/lib  -L/home/lw/.conan2/p/b/opens44f1dc79c108f/p/lib  -L/home/lw/.conan2/p/b/usrsc38dd4aaffa4c2/p/lib  -L/home/lw/.conan2/p/b/mpp20573945ccadf/p/lib  -L/home/lw/.conan2/p/b/ffmped7cdc6fda969b/p/lib  -L/home/lw/.conan2/p/b/libx2be607e4f6a3f6/p/lib  -L/home/lw/.conan2/p/b/libx2a34b793d4d073/p/lib  -Wl,-rpath,/home/lw/.conan2/p/b/fmt4d76687e3ed16/p/lib:/home/lw/.conan2/p/b/zlmed2c9057539529b/p/lib:/home/lw/.conan2/p/b/libsrfade138bd1240/p/lib:/home/lw/.conan2/p/b/opens44f1dc79c108f/p/lib:/home/lw/.conan2/p/b/usrsc38dd4aaffa4c2/p/lib:/home/lw/.conan2/p/b/mpp20573945ccadf/p/lib:/home/lw/.conan2/p/b/ffmped7cdc6fda969b/p/lib:/home/lw/.conan2/p/b/libx2be607e4f6a3f6/p/lib:/home/lw/.conan2/p/b/libx2a34b793d4d073/p/lib /home/lw/.conan2/p/b/fmt4d76687e3ed16/p/lib/libfmt.so /home/lw/.conan2/p/b/zlmed2c9057539529b/p/lib/libmk_api.so /home/lw/.conan2/p/b/mpp20573945ccadf/p/lib/librockchip_mpp.so /home/lw/.conan2/p/b/mpp20573945ccadf/p/lib/librockchip_vpu.so /home/lw/.conan2/p/b/ffmped7cdc6fda969b/p/lib/libavdevice.so /home/lw/.conan2/p/b/ffmped7cdc6fda969b/p/lib/libavfilter.so /home/lw/.conan2/p/b/ffmped7cdc6fda969b/p/lib/libavformat.so /home/lw/.conan2/p/b/ffmped7cdc6fda969b/p/lib/libavcodec.so -lrt -lstdc++ /home/lw/.conan2/p/b/ffmped7cdc6fda969b/p/lib/libswresample.so /home/lw/.conan2/p/b/ffmped7cdc6fda969b/p/lib/libswscale.so /home/lw/.conan2/p/b/ffmped7cdc6fda969b/p/lib/libavutil.so -ldl -lm -lpthread 

```
user: liwang54321
issue_15034: state: open
title: [question] Cross compiling with Clang
body: ### What is your question?

Hi! I want to cross compile for an `armv8` Linux host using `clang` on Linux.

I have tried to follow the documentation, but I'm having the problem that several recipes are built for `x86_64` instead. I suspect this is because my `clang` compiler supports both `x86_64` (the default) and `armv8`, and the target needs to be specified using the `--target` flag. However, if I add this flag to my build profile via CXXFLAGS it breaks other recipes that need to build native tools.

I noticed that the documentation seems to be assuming "gcc-style" cross compilation where you have a separate compiler named `aarch64-linux-gnu-gcc` or something. Does conan actually support this "clang-style" cross compiling?

I have set up the profile like this:

File (linux-base)
```
C_COMPILER_NAME=clang
CXX_COMPILER_NAME=clang++
COMPILER_VERSION=16
[settings]
os=Linux
compiler=$C_COMPILER_NAME
compiler.version=$COMPILER_VERSION
compiler.libcxx=libstdc++11
[options]
[build_requires]
[env]
CC=$C_COMPILER_NAME-$COMPILER_VERSION
CXX=$CXX_COMPILER_NAME-$COMPILER_VERSION

[conf]
tools.build:jobs=18
```

File (linux-base-armv8)
```
include(./linux-base)

target_host=aarch64-linux-gnu
toolchain=/usr/aarch64-linux-gnu

[settings]
arch=armv8

[env]
CONAN_CMAKE_FIND_ROOT_PATH=$toolchain  # Optional, for CMake to find things in that folder
CONAN_CMAKE_SYSROOT=$toolchain  # Optional, if we want to define sysroot
```

I am using conan 1.61 for now, but may consider updating to 2.0 if that supports my use case.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: johningve
issue_15031: state: open
title: [bug] test utils subpackage not usable because test.assets not exported with conan package
body: ### Environment details

N/A

### Steps to reproduce

Hi Team,

It currently doesn't seem to be possible to import the conan test client for the purpose of unit testing our custom commands. When I attempt to do so through `from conans.test.utils.tools import TestClient`, I'm greeted with a "module not found" error associated with line 43: https://github.com/conan-io/conan/blob/84e5faef3c81aaa4a1582e090707fc3de3bb3a7f/conans/test/utils/tools.py#L43

This appears to be because `conans.test.assets` is not exported with the package because of this package logic: https://github.com/conan-io/conan/blob/84e5faef3c81aaa4a1582e090707fc3de3bb3a7f/setup.py#L15-L19

Is this intentional? The comment there is that the test utils are used by conan-package-tools, but I can't see how that could be possible with the current import issues one would face.

Even if it is intentional, it would be incredibly useful to us when writing our own custom extensions to be able to use the test utilities you've developed rather than copying/writing our own.

Otherwise, if I'm trying to use these incorrectly please advise of correct usage.

Cheers,

### Logs

_No response_
user: samuel-emrys
issue_15030: state: open
title: How to handle transitive dependencies?
body: ### What is your question?

I am writing a library that I want to use in my local package index.

This library uses another library from the conan center.

In my libraries `conanfile.py`:

```
def requirements(self):
  self.requires("yaml-cpp/0.7.0", transitive_headers=True)
```

I then called `conan create .` to put this library in my local pckage folder.

When i now want to consume this library I use 

```
def requirements(self):
    self.requires("mylib/0.1.0")
```

in my clients `conanfile.py` file and class `conan install .`

That works and I can see the generated `Find` files for `cmake`

But when I then want to compile it i get the following error.

```
fatal error: yaml-cpp/yaml.h: No such file or directory
   12 | #include <yaml-cpp/yaml.h>
      |          ^~~~~~~~~~~~~~~~~
```

Shouldnt the `transitive_headers=True` attribute forward the dependencies for my library to the client? 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: KabelitzJ
issue_15027: state: open
title: AutotoolsToolchain: Honor `tools.apple:enable_bitcode` & `tools.apple:enable_arc`
body: Changelog: (Feature): Honor `tools.apple:enable_bitcode` & `tools.apple:enable_arc` in `AutotoolsToolchain`.
Docs: https://github.com/conan-io/docs/pull/XXXX

closes https://github.com/conan-io/conan/issues/12197

Similar to https://github.com/conan-io/conan/pull/10985 but for AutotoolsToolchain., except that nothing is done for `tools.apple:enable_visibility` because I consider that this conf is useless and doesn't make sense.
In a sense `tools.apple:enable_bitcode` & `tools.apple:enable_arc` shouldn't have been added I think, but since they are here and implemented in `CMakeToolchain`, conan should be consistent in all toolchains (unless you want to deprecate these conf).

Also it's worth noting that https://github.com/conan-io/conan/issues/12197#issuecomment-1257286686 is incorrect (or not correct anymore). openssl recipe uses AutootoolsToolchain in order to collect flags for configure step.

- [x] Refer to the issue that supports this Pull Request.
- [ ] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ ] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

user: SpaceIm
issue_15024: state: open
title: [question] Constant dependency conflicts even when I don't change libraries.
body: ### What is your question?

I have a project that pulls in a handful of libraries using conan. They all specify exact versions. ie.
```
	def requirements(self):
		self.requires("sdl/2.26.5")
		self.requires("sdl_image/2.0.5")
		self.requires("sdl_ttf/2.20.2")
		self.requires("nlohmann_json/3.11.2")
		...
```
But every time I commit to my CI machine, conan will try to pull the libraries and complain that there are version conflicts. I'll fix the issue by explicitly providing overrides for these dependencies, ie. `self.requires("libwebp/1.3.2", override=True)` etc. which will allow the build to complete, then a week later I'll make another commit and there will be another library conflict.

I would have thought that these libraries I'm pulling in would mostly be unchanging since I'm pulling specific libraries, but it seems like these libraries are constantly changing their own dependencies which leads to me having to troubleshoot and figure out what versions to pull again.

Whats the point in having specific versions if the versioned library continually changes it's own dependencies? I'm spending just as much time debugging my conan builds as I am doing my own development.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: instinkt900
issue_15020: state: open
title: [question] What is the purpose of `--build-require` argument? 
body: ### What is your question?

I don't understand what using `--build-require` does to a conan create. I read the documentation (https://docs.conan.io/2/reference/commands/create.html?highlight=--format#using-conan-create-with-build-requirements), which states that it

> allows to create the package using the configuration and settings of the “build” context, as it was a build_require 

but I don't really get what implications that has.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: pklip
issue_15018: state: open
title: Conan config install failing randomly for parallel builds. 
body: Hi, 

Conan config install is failing randomly for parallel builds. 

Command used: conan config install ${ARTIFACTORY_BASEURL}/artifactory/conanrepo/config.zip
----------------------------------------------------------------------------
[2023-10-24T23:42:43.945Z] Trying to download  https://artifactory-pd.com/artifactory/conanrepo/config.zip
[2023-10-24T23:42:43.945Z] ERROR: Failed conan config install: Error while installing config from https://artifactory-pd.com/artifactory/conanrepo/config.zip
[2023-10-24T23:42:43.945Z] [Errno 2] No such file or directory: '/home/bangbuild/.conan/tmp_config_install/config.zip'
script returned exit code 1

oR 

[2023-10-24T17:45:47.087Z] ERROR: Failed conan config install: [Errno 17] File exists: '/home/bangbuild/.conan/tmp_config_install'
script returned exit code 1

We are running builds in parallel inside docker containers. Conan cache is under /home/bangbuild (/home/bangbuild path in host is mounted inside the Docker container).

Regards,
Mohan 




### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: mkjkec2005
issue_15017: state: open
title: [bug] 'Manifest mismatch' error when uploading a 'cmake' package taken from 'conancenter'
body: ### Environment details

* Operating System+version: **_Windows 11 Enterprise_** (OS Version: `10.0.20348` Build `2031`)
* Compiler+version: -
* Conan version: `2.0.13`
* Python version: `3.11.6`

### Description

Hi,
We need to make some 'official' _Conan-packages_ of the **CMake** tool available from a repository on our Artifactory server (with 'official' I mean 'taken from _conancenter_'). This is because our build servers don't have direct access to 'conancenter' due to internal company policies that limit access to the Internet.
For transferring (copying) the needed packages we use sequences of `conan download` and `conan upload` commands as shown below (section **Steps to reproduce**).
This fails with a `Manifest mismatch` message (along with a final `corrupted artifacts` message) as shown below (section **Logs**).
Instead, omitting the `--check` flag the `upload` command succeeds.

Seemingly, the binary package in question is the one for `os: Macos` (package `9e5323c65b94ae38c3c733fe12637776db0119a5`).
I'm not sure whether this is a possible bug in the `upload` command or more probably some issue in the package creation itself, so I might possibly have created this bug report in the wrong place. If so, I apologize for that.

Best regards

#### PS
I tried with a few different versions of _CMake_ packages from _conancenter_, with the same result.
And I've made an attempt right now with package _make/4.2.1_, in this case without any issue.

### Steps to reproduce

```
conan download -r conancenter cmake/3.26.3
conan upload cmake/3.26.3 -r conanlocal --confirm --check
```

### Logs

```
cmake/3.26.3: Integrity checked: ok
cmake/3.26.3:522dcea5982a3f8a5b624c16477e47195da2f84f: Integrity checked: ok
cmake/3.26.3:63fead0844576fc02943e16909f08fcdddd6f44b: Integrity checked: ok
ERROR: cmake/3.26.3:9e5323c65b94ae38c3c733fe12637776db0119a5: Manifest mismatch
ERROR: Folder: C:\Users\VssAdministrator\.conan2\p\cmakee0f8cc1ef0e11\p
ERROR:     'CMake.app/Contents/Frameworks/QtCore.framework/Resources' (manifest: None, file: e58c4cf10cc7c8ef7d7167ccb641aeb4)
ERROR:     'CMake.app/Contents/Frameworks/QtGui.framework/Resources' (manifest: None, file: e58c4cf10cc7c8ef7d7167ccb641aeb4)
ERROR:     'CMake.app/Contents/Frameworks/QtPrintSupport.framework/Resources' (manifest: None, file: e58c4cf10cc7c8ef7d7167ccb641aeb4)
ERROR:     'CMake.app/Contents/Frameworks/QtWidgets.framework/Resources' (manifest: None, file: e58c4cf10cc7c8ef7d7167ccb641aeb4)
Traceback (most recent call last):
  File "C:\hostedtoolcache\windows\Python\3.11.6\x64\Lib\site-packages\conan\cli\cli.py", line 172, in run
    command.run(self._conan_api, args[0][1:])
  File "C:\hostedtoolcache\windows\Python\3.11.6\x64\Lib\site-packages\conan\cli\command.py", line 125, in run
    info = self._method(conan_api, parser, *args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\hostedtoolcache\windows\Python\3.11.6\x64\Lib\site-packages\conan\cli\commands\upload.py", line 102, in upload
    conan_api.cache.check_integrity(package_list)
  File "C:\hostedtoolcache\windows\Python\3.11.6\x64\Lib\site-packages\conan\api\subapi\cache.py", line 62, in check_integrity
    checker.check(package_list)
  File "C:\hostedtoolcache\windows\Python\3.11.6\x64\Lib\site-packages\conan\internal\integrity_check.py", line 28, in check
    raise ConanException("There are corrupted artifacts, check the error logs")
conans.errors.ConanException: There are corrupted artifacts, check the error logs

ERROR: There are corrupted artifacts, check the error logs
```
user: marausch
issue_15009: state: open
title: [question] Add CFLAGS and CPPFLAGS from the command line
body: ### What is your question?

Hello,

I have a query concerning the utilization of compiler flags via the command line when utilizing Conan recipes. My objective is to employ the provided Conan recipes while having the flexibility to spontaneously add compiler flags from the command line.

Based on my understanding, this can be achieved using the -c flag in the conan install command. I attempted to do so with the argument -c tools.build:cflags="[\"/O1\"]". However, upon inspecting my build logs, it became evident that the /O1 flag was not utilized during the compilation process.

I am seeking clarification on whether I might be making an error in my approach or if the -c flag is not intended for changing compiler flags as described. Any insights or guidance on this matter would be greatly appreciated.

Thank you.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: dev-89
issue_15001: state: open
title: [question] Conditional transitive packages
body: ### What is your question?

We have the following problem: Our firmware application builds target an embedded distro that we build with Yocto. The target RFS usually already has an OpenSSL library installed, so we don't want to build it from source (for build time and target image size considerations). However, if the firmware build adds 3rd party packages like `grpc` from Conan Center as a requirement, then we get an implicit dependency to the OpenSSL package. Our previous workaround was to provide a modified recipe for OpenSSL that detects the target environment, validates the requested version against the available one and enables linking against the system library if necessary, instead of building itself. However, I don't like this solution as it doesn't scale very well. In particular, I want to avoid having to maintain changes to the original recipes.

Ideally, there should be a native solution for this in Conan, but I'm not aware of one. So I was thinking that a proxy package could be a valid workaround. If we export the actual `openssl` recipe as `openssl_upstream` and a proxy recipe with auto detection as `openssl`, then depending on the detected environment the proxy recipe could add `openssl_upstream` as a dependency to the graph, or not. However, it is not clear to me how to pass the package info through in such a case so that downstream is linked against `openssl` (as provided by `openssl_upstream`).

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jasal82
issue_14999: state: open
title: [question] skip test package if the package is downloaded?
body: ### What is your question?

Hi,

when calling `conan create` and an already build package is found/downloaded in artifactory, wouldn't it make sense to skip the test package?
This was already done when uploading the package in the first place, so skipping should be fine?

Just realized this in our 3rd-party pipeline that a lot of test packages are build although they are only downloade.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: tbsuht
issue_14998: state: open
title: [question] How to handle PATH variable in windows
body: ### What is your question?

Hello,

we use mainly windows for our applications,
in some of them, we are using large dependency graph where all packages contribute to the PATH env-var (SHARED_LIBS).
so the run environment is pretty large, currently we are not using any custom conan cache folder, or any custom deployer.

for our build environment, we use cmake + ninja + vcvars which adds many Visual studio folders to the path.

now, we've added ctest support, so we need both build environment and run environment to our builds.
this combination exceeds the PATH size limit, and we are looking for a solution.

as for the runenv we start by set conan cache closer to C drive, we don't have a solution to shorter the build envieonment.
do you have any recommendations on that issue ?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: mikirothman
issue_14994: state: open
title: Conan patches work incorrectly 
body: Hi @memsharded 
A few questions regarding Conan patches:
- I observe that I cannot change the same file via patch multiple times - is it expected? Once the first patch is applied, the second one fails.
- In current patch I move files to subfolder, but it does not work and I still see after patch applying:
```
[ 85%] Running C++ protocol buffer compiler (protobuf::protoc) on src/frontends/tensorflow/src/proto/reader_base.proto
ov_tensorflow/tensor_shape.proto: File not found.
```
that files are used by old location `proto/reader_base.proto` (while must be `proto/ov_tensorflow/reader_base.proto`). Don't you use git to apply patch? the same patches perfectly work in `vcpkg`

UPDATE: original comment https://github.com/conan-io/conan-center-index/pull/20728/files#r1367797232
user: ilya-lavrenov
issue_14990: state: open
title: [question] How to make system packages from CCI work with an alternative sysroot, i.e. Yocto
body: ### What is your question?

When using system packages from Conan Center, i.e. `opengl/system` or `xorg/system`, it is not possible to skip the package manager and use an alternative sysroot to generate the pkg-config files from without forking the CCI packages and modifying them.

I'm using a Yocto SDK and it is always installed to the same absolute location. I'd like to not have to fork each individual `/system` package just to add `pkg_config_path` to the `PkgConfig` constructor and delete the calls to `conan.tools.system.package_manager`.
Would it instead be possible to supply a sysroot and disable the `package_manager` calls entirely through `conf` variables?

I believe #14982 is asking a very similar question.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: jwillikers
issue_14989: state: open
title: [feature] Running test() method without build
body: ### What is your suggestion?

Hi, I think my issue relates #1629

> So it will just run the test(), without building the consumer project inside test_package folder?What would be the use case?

Yep, it's my case. Sometimes you need to run test executable with a lot of arguments. It's much be easier to debug such cases without rebuild _test_package_. It's very annoying for me because rebuilding _test_package_ takes ~5 minutes.
Maybe it would be great to something like old flag for ```create()``` method ```--keep-build```. I do not understand why this flag was removed in v2.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Jihadist
issue_14988: state: open
title: [bug] CMAKE_OSX_DEPLOYMENT_TARGET may be overridden by CMake projects which set it as cache variable before the first project command
body: ### What is your suggestion?

The CMakeToolchain currently defines `CMAKE_OSX_DEPLOYMENT_TARGET` as a cache variable. This seems the correct approach according to Professional CMake:

> Furthermore, CMAKE_OSX_DEPLOYMENT_TARGET needs to be a cache variable if it is being set directly in the top level CMakeLists.txt file, otherwise it will be overwritten by the compiler checks performed by the project() command

Qt also sets this variable as a cache variable in Qt 6.6.0, but before the first call to the `project` command which overrides Conan's definition of the variable as a cache variable in the toolchain file. Refer to issue conan-io/conan-center-index#20589.



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jwillikers
issue_14987: state: open
title: [bug] MesonToolchain does not handle tools.build:sysroot
body: ### What is your suggestion?

The `tools.build:sysroot` conf variable is not used by the MesonToolchain. A `--sysroot` compiler flag should be added to the compiler and linker flags. Additionally, Meson has a `sys_root` cross file property that should be defined by the MesonToolchain for locating pkg-config files. This variable is documented [here](https://mesonbuild.com/Cross-compilation.html#properties).

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jwillikers
issue_14982: state: open
title: [question] Setting tools.build:sysroot when using system_requirements()
body: ### What is your question?

I have a compiler package that brings along its own sysroot. It also sets `tools.build:sysroot` for consuming packages. Now one of our consumers uses dependencies from conan-center that have system requirements (e.g. _qt_, which uses _xorg/system_). 

Of course the system requirements cannot be found in the sysroot folder of my package but in `/usr/lib`, which probably isn't part of the default linker search paths anymore.

Is there a recommended solution for this problem or is this an unsolvable problem because of the opposite requirements of having a non-default sysroot and using system requirements?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fschoenm
issue_14981: state: open
title: [bug] Conan generates non-deterministic hashes in .conan2/p folder
body: ### Environment details

* Operating System+version: Ubuntu 22.04
* Compiler+version: /usr/bin/riscv64-linux-gnu-g++
* Conan version: 2.0.13
* Python version: 3.11

We have builds with Conan in our CI, which is run in docker container.
Build procedure utilizes sccache to speed up the product build. But Conan generates different include paths each time even if conan.lock file is used and sscache does not work:

**Build 1:**
```
Requirements
    ade/0.1.2c#8c03c130df6dc35186b38ba73a40a71d - Downloaded (conancenter)
    flatbuffers/23.5.26#b153646f6546daab4c7326970b6cd89c - Downloaded (conancenter)
    gflags/2.2.2#48d1262ffac8d30c3224befb8275a533 - Downloaded (conancenter)
    ittapi/3.24.0#9246125f13e7686dee2b0c992b71db94 - Downloaded (conancenter)
    nlohmann_json/3.11.2#a35423bb6e1eb8f931423557e282c7ed - Downloaded (conancenter)
    onetbb/2021.10.0#cbb2fc43088070b48f6e4339bc8fa0e1 - Downloaded (conancenter)
    onnx/1.14.1#d95f4e64bedf3dc6898253847ac69005 - Downloaded (conancenter)
    opencl-clhpp-headers/2023.04.17#7c62fcc7ac2559d4839150d2ebaac5c8 - Downloaded (conancenter)
    opencl-headers/2023.04.17#3d98f2d12a67c2400de6f11d5335b5a6 - Downloaded (conancenter)
    opencl-icd-loader/2023.04.17#5f73dd9f0c023d416a7f162e320b9c77 - Downloaded (conancenter)
    protobuf/3.21.12#d9f5f4e3b86552552dda4c0a2e928eeb - Downloaded (conancenter)
    pugixml/1.13#f615c1fcec55122b2e177d17061276e7 - Downloaded (conancenter)
    pybind11/2.10.4#dd44c80a5ed6a2ef11194380daae1248 - Downloaded (conancenter)
    rapidjson/cci.20220822#8ca51918340f3a21127822258e95ec0f - Downloaded (conancenter)
    snappy/1.1.10#916523630083f6d855cb2977de8eefb6 - Downloaded (conancenter)
    xbyak/6.73#250bc3bc73379f90f255876c1c00a4cd - Downloaded (conancenter)
    zlib/1.2.13#97d5730b529b4224045fe7090592d4c1 - Downloaded (conancenter)
Build requirements
    autoconf/2.71#53be95d228b2dcb30dc199cb84262d8f - Downloaded (conancenter)
    automake/1.16.5#058bda3e21c36c9aa8425daf3c1faf50 - Downloaded (conancenter)
    cmake/3.27.4#a7e78418b024dccacccc887f049f47ed - Downloaded (conancenter)
    flatbuffers/23.5.26#b153646f6546daab4c7326970b6cd89c - Downloaded (conancenter)
    gnu-config/cci.20210814#15c3bf7dfdb743977b84d0321534ad90 - Downloaded (conancenter)
    libtool/2.4.6#9ee8efc04c2e106e7fba13bb1e477617 - Downloaded (conancenter)
    m4/1.4.19#c1c4b1ee919e34630bb9b50046253d3c - Downloaded (conancenter)
    meson/1.0.0#15586c0ac6f682805875ef903dbe7ee2 - Downloaded (conancenter)
    ninja/1.11.1#77587f8c8318662ac8e5a7867eb4be21 - Downloaded (conancenter)
    patchelf/0.13#0eaada8970834919c3ce14355afe7fac - Downloaded (conancenter)
    pkgconf/1.9.5#743ca0d41d35a84b1f89af337ddaa1a0 - Downloaded (conancenter)
    protobuf/3.21.9#515ceb0a1653cf84363d9968b812d6be - Downloaded (conancenter)
    protobuf/3.21.12#d9f5f4e3b86552552dda4c0a2e928eeb - Downloaded (conancenter)
    zlib/1.2.13#97d5730b529b4224045fe7090592d4c1 - Downloaded (conancenter)

[648/5083] sccache /usr/bin/riscv64-linux-gnu-g++ -DIE_BUILD_POSTFIX=\"\" -DIE_THREAD=IE_THREAD_SEQ -DIMPLEMENT_OPENVINO_API -DIN_OV_COMPONENT -DIN_OV_CORE_LIBRARY -DOPENVINO_STATIC_LIBRARY -DOV_BUILD_POSTFIX=\"\" -DOV_NATIVE_PARENT_PROJECT_ROOT_DIR=\"openvino\" -DOV_THREAD=OV_THREAD_SEQ -I/__w/openvino/openvino/openvino/src/core/include -I/__w/openvino/openvino/openvino/src/core/src -I/__w/openvino/openvino/openvino/src/core/builder/include -I/__w/openvino/openvino/openvino/src/core/reference/include -I/__w/openvino/openvino/openvino/src/core/dev_api -I/__w/openvino/openvino/openvino/src/common/util/include -I/github/home/.conan2/p/b/pugix02fd5af4c82dd/p/include -I/__w/openvino/openvino/openvino/src/core/shape_inference/include -I/__w/openvino/openvino/openvino/src/frontends/common/include -I/__w/openvino/openvino/openvino/src/common/transformations/include -I/__w/openvino/openvino/openvino/src/common/itt/include -I/__w/openvino/openvino/openvino/src/common/conditional_compilation/include -Wsuggest-override -Wno-deprecated-declarations -fsigned-char -ffunction-sections -fdata-sections -fdiagnostics-show-option -Wall -Wundef -Wmissing-declarations -O3 -DNDEBUG  -Wformat -Wformat-security -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fno-delete-null-pointer-checks -fwrapv -fstack-protector-strong -s -ffile-prefix-map=/__w/openvino/openvino/openvino/= -ffile-prefix-map=../openvino/= -std=gnu++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wabi=11 -MD -MT src/core/CMakeFiles/ngraph_obj.dir/src/op/util/activation_functions.cpp.o -MF src/core/CMakeFiles/ngraph_obj.dir/src/op/util/activation_functions.cpp.o.d -o src/core/CMakeFiles/ngraph_obj.dir/src/op/util/activation_functions.cpp.o -c /__w/openvino/openvino/openvino/src/core/src/op/util/activation_functions.cpp
```
**Build 2:**
```
Requirements
    ade/0.1.2c#8c03c130df6dc35186b38ba73a40a71d - Downloaded (conancenter)
    flatbuffers/23.5.26#b153646f6546daab4c7326970b6cd89c - Downloaded (conancenter)
    gflags/2.2.2#48d1262ffac8d30c3224befb8275a533 - Downloaded (conancenter)
    ittapi/3.24.0#9246125f13e7686dee2b0c992b71db94 - Downloaded (conancenter)
    nlohmann_json/3.11.2#a35423bb6e1eb8f931423557e282c7ed - Downloaded (conancenter)
    onetbb/2021.10.0#cbb2fc43088070b48f6e4339bc8fa0e1 - Downloaded (conancenter)
    onnx/1.14.1#d95f4e64bedf3dc6898253847ac69005 - Downloaded (conancenter)
    opencl-clhpp-headers/2023.04.17#7c62fcc7ac2559d4839150d2ebaac5c8 - Downloaded (conancenter)
    opencl-headers/2023.04.17#3d98f2d12a67c2400de6f11d5335b5a6 - Downloaded (conancenter)
    opencl-icd-loader/2023.04.17#5f73dd9f0c023d416a7f162e320b9c77 - Downloaded (conancenter)
    protobuf/3.21.12#d9f5f4e3b86552552dda4c0a2e928eeb - Downloaded (conancenter)
    pugixml/1.13#f615c1fcec55122b2e177d17061276e7 - Downloaded (conancenter)
    pybind11/2.10.4#dd44c80a5ed6a2ef11194380daae1248 - Downloaded (conancenter)
    rapidjson/cci.20220822#8ca51918340f3a21127822258e95ec0f - Downloaded (conancenter)
    snappy/1.1.10#916523630083f6d855cb2977de8eefb6 - Downloaded (conancenter)
    xbyak/6.73#250bc3bc73379f90f255876c1c00a4cd - Downloaded (conancenter)
    zlib/1.2.13#97d5730b529b4224045fe7090592d4c1 - Downloaded (conancenter)
Build requirements
    autoconf/2.71#53be95d228b2dcb30dc199cb84262d8f - Downloaded (conancenter)
    automake/1.16.5#058bda3e21c36c9aa8425daf3c1faf50 - Downloaded (conancenter)
    cmake/3.27.4#a7e78418b024dccacccc887f049f47ed - Downloaded (conancenter)
    flatbuffers/23.5.26#b153646f6546daab4c7326970b6cd89c - Downloaded (conancenter)
    gnu-config/cci.20210814#15c3bf7dfdb743977b84d0321534ad90 - Downloaded (conancenter)
    libtool/2.4.6#9ee8efc04c2e106e7fba13bb1e477617 - Downloaded (conancenter)
    m4/1.4.19#c1c4b1ee919e34630bb9b50046253d3c - Downloaded (conancenter)
    meson/1.0.0#15586c0ac6f682805875ef903dbe7ee2 - Downloaded (conancenter)
    ninja/1.11.1#77587f8c8318662ac8e5a7867eb4be21 - Downloaded (conancenter)
    patchelf/0.13#0eaada8970834919c3ce14355afe7fac - Downloaded (conancenter)
    pkgconf/1.9.5#743ca0d41d35a84b1f89af337ddaa1a0 - Downloaded (conancenter)
    protobuf/3.21.9#515ceb0a1653cf84363d9968b812d6be - Downloaded (conancenter)
    protobuf/3.21.12#d9f5f4e3b86552552dda4c0a2e928eeb - Downloaded (conancenter)
    zlib/1.2.13#97d5730b529b4224045fe7090592d4c1 - Downloaded (conancenter)

[652/5082] sccache /usr/bin/riscv64-linux-gnu-g++ -DIE_BUILD_POSTFIX=\"\" -DIE_THREAD=IE_THREAD_SEQ -DIMPLEMENT_OPENVINO_API -DIN_OV_COMPONENT -DIN_OV_CORE_LIBRARY -DOPENVINO_STATIC_LIBRARY -DOV_BUILD_POSTFIX=\"\" -DOV_NATIVE_PARENT_PROJECT_ROOT_DIR=\"openvino\" -DOV_THREAD=OV_THREAD_SEQ -I/__w/openvino/openvino/openvino/src/core/include -I/__w/openvino/openvino/openvino/src/core/src -I/__w/openvino/openvino/openvino/src/core/builder/include -I/__w/openvino/openvino/openvino/src/core/reference/include -I/__w/openvino/openvino/openvino/src/core/dev_api -I/__w/openvino/openvino/openvino/src/common/util/include -I/github/home/.conan2/p/b/pugixc3e2f13550eb0/p/include -I/__w/openvino/openvino/openvino/src/core/shape_inference/include -I/__w/openvino/openvino/openvino/src/frontends/common/include -I/__w/openvino/openvino/openvino/src/common/transformations/include -I/__w/openvino/openvino/openvino/src/common/itt/include -I/__w/openvino/openvino/openvino/src/common/conditional_compilation/include -Wsuggest-override -Wno-deprecated-declarations -fsigned-char -ffunction-sections -fdata-sections -fdiagnostics-show-option -Wall -Wundef -Wmissing-declarations -O3 -DNDEBUG  -Wformat -Wformat-security -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fno-delete-null-pointer-checks -fwrapv -fstack-protector-strong -s -ffile-prefix-map=/__w/openvino/openvino/openvino/= -ffile-prefix-map=../openvino/= -std=gnu++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wabi=11 -MD -MT src/core/CMakeFiles/ngraph_obj.dir/src/op/util/activation_functions.cpp.o -MF src/core/CMakeFiles/ngraph_obj.dir/src/op/util/activation_functions.cpp.o.d -o src/core/CMakeFiles/ngraph_obj.dir/src/op/util/activation_functions.cpp.o -c /__w/openvino/openvino/openvino/src/core/src/op/util/activation_functions.cpp
```

We can see that requirements are the same, but different include paths are used for pugixml from build to build: `/github/home/.conan2/p/b/pugix02fd5af4c82dd/p/include` and `/github/home/.conan2/p/b/pugixc3e2f13550eb0/p/include`

### Steps to reproduce

--

### Logs

https://github.com/openvinotoolkit/openvino/actions/runs/6574820077/job/17860637323 and https://github.com/openvinotoolkit/openvino/actions/runs/6580535392/job/17878718011
user: ilya-lavrenov
issue_14962: state: open
title: [feature] Add `tools.gnu:build_triplet` to conf
body: ### What is your suggestion?

Related to https://github.com/conan-io/conan/issues/14947

Instead of changing the recipe, it'd be great to have a conf mechanism to change the build triplet like:

```
[conf]
tools.gnu:build_triplet="build_triplet"
```
For now, it's only used by AutotoolsToolchain. The question is: Should the rest of the toolchains read that conf/s too?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: franramirez688
issue_14960: state: open
title: [bug] Harfbuzz/7.1.0 build fails
body: ### Environment details

* Operating System+version: macOS Sonoma 14.0 on Apple Silicon (arm64)
* Compiler+version: Apple clang version 15.0.0 (clang-1500.0.40.1)
* Conan version: Unknown, presumably latest?
* Python version: 3.11.6


### Steps to reproduce

1. Have a AS Mac
2. Run `npm i node-imagemagick`
3. Encounter build issue with harfbuzz

### Logs

```
❯ npm install node-magickwand
npm ERR! code 1
npm ERR! path /Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand
npm ERR! command failed
npm ERR! command sh -c node-pre-gyp install --fallback-to-build && node scripts/gen-es6.js lib/index.mjs
npm ERR! Failed to execute '/opt/homebrew/Cellar/node@18/18.17.1/bin/node /opt/homebrew/Cellar/node@18/18.17.1/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js configure --fallback-to-build --module=/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand/lib/binding/darwin-arm64/node-magickwand.node --module_name=node-magickwand --module_path=/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand/lib/binding/darwin-arm64 --napi_version=9 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v108' (1)
npm ERR! node-pre-gyp info it worked if it ends with ok
npm ERR! node-pre-gyp info using node-pre-gyp@1.0.11
npm ERR! node-pre-gyp info using node@18.17.1 | darwin | arm64
npm ERR! node-pre-gyp info check checked for "/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand/lib/binding/darwin-arm64/node-magickwand.node" (not found)
npm ERR! node-pre-gyp http GET https://github.com/mmomtchev/node-magickwand/releases/download/v0.9.7/darwin-arm64.tar.gz
npm ERR! node-pre-gyp ERR! install response status 404 Not Found on https://github.com/mmomtchev/node-magickwand/releases/download/v0.9.7/darwin-arm64.tar.gz 
npm ERR! node-pre-gyp WARN Pre-built binaries not installable for node-magickwand@0.9.7 and node@18.17.1 (node-v108 ABI, unknown) (falling back to source compile with node-gyp) 
npm ERR! node-pre-gyp WARN Hit error response status 404 Not Found on https://github.com/mmomtchev/node-magickwand/releases/download/v0.9.7/darwin-arm64.tar.gz 
npm ERR! gyp info it worked if it ends with ok
npm ERR! gyp info using node-gyp@9.3.1
npm ERR! gyp info using node@18.17.1 | darwin | arm64
npm ERR! gyp info ok 
npm ERR! gyp info it worked if it ends with ok
npm ERR! gyp info using node-gyp@9.3.1
npm ERR! gyp info using node@18.17.1 | darwin | arm64
npm ERR! gyp info find Python using Python version 3.11.6 found at "/opt/homebrew/opt/python@3.11/bin/python3.11"
npm ERR! gyp info spawn /opt/homebrew/opt/python@3.11/bin/python3.11
npm ERR! gyp info spawn args [
npm ERR! gyp info spawn args   '/opt/homebrew/Cellar/node@18/18.17.1/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',
npm ERR! gyp info spawn args   'binding.gyp',
npm ERR! gyp info spawn args   '-f',
npm ERR! gyp info spawn args   'make',
npm ERR! gyp info spawn args   '-I',
npm ERR! gyp info spawn args   '/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand/build/config.gypi',
npm ERR! gyp info spawn args   '-I',
npm ERR! gyp info spawn args   '/opt/homebrew/Cellar/node@18/18.17.1/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',
npm ERR! gyp info spawn args   '-I',
npm ERR! gyp info spawn args   '/Users/jackmatthews/Library/Caches/node-gyp/18.17.1/include/node/common.gypi',
npm ERR! gyp info spawn args   '-Dlibrary=shared_library',
npm ERR! gyp info spawn args   '-Dvisibility=default',
npm ERR! gyp info spawn args   '-Dnode_root_dir=/Users/jackmatthews/Library/Caches/node-gyp/18.17.1',
npm ERR! gyp info spawn args   '-Dnode_gyp_dir=/opt/homebrew/Cellar/node@18/18.17.1/lib/node_modules/npm/node_modules/node-gyp',
npm ERR! gyp info spawn args   '-Dnode_lib_file=/Users/jackmatthews/Library/Caches/node-gyp/18.17.1/<(target_arch)/node.lib',
npm ERR! gyp info spawn args   '-Dmodule_root_dir=/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand',
npm ERR! gyp info spawn args   '-Dnode_engine=v8',
npm ERR! gyp info spawn args   '--depth=.',
npm ERR! gyp info spawn args   '--no-parallel',
npm ERR! gyp info spawn args   '--generator-output',
npm ERR! gyp info spawn args   'build',
npm ERR! gyp info spawn args   '-Goutput_dir=.'
npm ERR! gyp info spawn args ]
npm ERR! WARNING: Skipping /opt/homebrew/lib/python3.11/site-packages/pycparser-2.21.dist-info due to invalid metadata entry 'name'
npm ERR! WARNING: Skipping /opt/homebrew/lib/python3.11/site-packages/cffi-1.16.0.dist-info due to invalid metadata entry 'name'
npm ERR! DEPRECATION: Loading egg at /opt/homebrew/lib/python3.11/site-packages/mtkclient-1.6.3-py3.11.egg is deprecated. pip 23.3 will enforce this behaviour change. A possible replacement is to use pip for package installation..
npm ERR! WARNING: Skipping /opt/homebrew/lib/python3.11/site-packages/pycparser-2.21.dist-info due to invalid metadata entry 'name'
npm ERR! WARNING: Skipping /opt/homebrew/lib/python3.11/site-packages/cffi-1.16.0.dist-info due to invalid metadata entry 'name'
npm ERR! WARNING: Skipping /opt/homebrew/lib/python3.11/site-packages/pycparser-2.21.dist-info due to invalid metadata entry 'name'
npm ERR! WARNING: Skipping /opt/homebrew/lib/python3.11/site-packages/cffi-1.16.0.dist-info due to invalid metadata entry 'name'
npm ERR! WARNING: Skipping /opt/homebrew/lib/python3.11/site-packages/pycparser-2.21.dist-info due to invalid metadata entry 'name'
npm ERR! WARNING: Skipping /opt/homebrew/lib/python3.11/site-packages/cffi-1.16.0.dist-info due to invalid metadata entry 'name'
npm ERR! 
npm ERR! [notice] A new release of pip is available: 23.2.1 -> 23.3
npm ERR! [notice] To update, run: python3.11 -m pip install --upgrade pip
npm ERR! WARN: openexr/3.1.5: requirement zlib/[>=1.2.11 <2] overridden by your conanfile to zlib/1.2.13 
npm ERR! WARN: freetype/2.13.0: requirement libpng/1.6.40 overridden by fontconfig/2.14.2 to libpng/1.6.39 
npm ERR! WARN: freetype/2.13.0: requirement zlib/[>=1.2.10 <2] overridden by fontconfig/2.14.2 to zlib/1.2.13 
npm ERR! WARN: freetype/2.13.0: requirement brotli/1.1.0 overridden by fontconfig/2.14.2 to brotli/1.0.9 
npm ERR! WARN: libpng/1.6.39: requirement zlib/[>=1.2.11 <2] overridden by freetype/2.13.0 to zlib/1.2.13 
npm ERR! WARN: glib/2.78.0: requirement zlib/[>=1.2.11 <2] overridden by your conanfile to zlib/1.2.13 
npm ERR! WARN: pcre2/10.42: requirement zlib/[>=1.2.11 <2] overridden by glib/2.78.0 to zlib/1.2.13 
npm ERR! WARN: harfbuzz/7.1.0: requirement glib/2.77.0 overridden by your conanfile to glib/2.78.0 
npm ERR! WARN: libheif/1.13.0: requirement libde265/1.0.12 overridden by your conanfile to libde265/1.0.11 
npm ERR! WARN: libraw/0.21.1: requirement libjpeg-turbo/2.1.5 overridden by your conanfile to libjpeg-turbo/3.0.0 
npm ERR! WARN: libtiff/4.6.0: requirement zlib/[>=1.2.11 <2] overridden by your conanfile to zlib/1.2.13 
npm ERR! WARN: libxml2/2.10.4: requirement zlib/[>=1.2.11 <2] overridden by your conanfile to zlib/1.2.13 
npm ERR! WARN: libzip/1.9.2: requirement zlib/[>=1.2.11 <2] overridden by your conanfile to zlib/1.2.13 
npm ERR! WARN: libzip/1.9.2: requirement xz_utils/5.4.2 overridden by your conanfile to xz_utils/5.4.4 
npm ERR! WARN: openssl/3.1.3: requirement zlib/[>=1.2.11 <2] overridden by libzip/1.9.2 to zlib/1.2.13 
npm ERR! harfbuzz/7.1.0: WARN: Package binary is corrupted, removing: 4b6a6193d24485c01c73fda8ce1844d971a9fd4b
npm ERR! WARN: pcre2/10.42: requirement zlib/[>=1.2.11 <2] overridden by glib/2.78.0 to zlib/1.2.13 
npm ERR! CMake Deprecation Warning at CMakeLists.txt:10 (cmake_minimum_required):
npm ERR!   Compatibility with CMake < 3.5 will be removed from a future version of
npm ERR!   CMake.
npm ERR! 
npm ERR!   Update the VERSION argument <min> value or use a ...<max> suffix to tell
npm ERR!   CMake that the project does not need compatibility with older versions.
npm ERR! 
npm ERR! 
npm ERR! harfbuzz/7.1.0: WARN: Build folder is dirty, removing it: /Users/jackmatthews/.conan/data/harfbuzz/7.1.0/_/_/build/4b6a6193d24485c01c73fda8ce1844d971a9fd4b
npm ERR! harfbuzz/7.1.0: ERROR: Package '4b6a6193d24485c01c73fda8ce1844d971a9fd4b' build failed
npm ERR! harfbuzz/7.1.0: WARN: Build folder /Users/jackmatthews/.conan/data/harfbuzz/7.1.0/_/_/build/4b6a6193d24485c01c73fda8ce1844d971a9fd4b/build-release
npm ERR! ERROR: harfbuzz/7.1.0: Error in build() method, line 161
npm ERR!        meson.configure()
npm ERR!        ConanException: Error 1 while executing meson setup --native-file "/Users/jackmatthews/.conan/data/harfbuzz/7.1.0/_/_/build/4b6a6193d24485c01c73fda8ce1844d971a9fd4b/build-release/conan/conan_meson_native.ini" "/Users/jackmatthews/.conan/data/harfbuzz/7.1.0/_/_/build/4b6a6193d24485c01c73fda8ce1844d971a9fd4b/build-release" "/Users/jackmatthews/.conan/data/harfbuzz/7.1.0/_/_/build/4b6a6193d24485c01c73fda8ce1844d971a9fd4b/src" -Dprefix="/Users/jackmatthews/.conan/data/harfbuzz/7.1.0/_/_/package/4b6a6193d24485c01c73fda8ce1844d971a9fd4b"
npm ERR! gyp: Call to '(pip3 install --user "conan<2.0.0" && cd build && python3 -m conans.conan install .. -pr:b=default -of build --build=missing --build=openjpeg) > /dev/null' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
npm ERR! gyp ERR! configure error 
npm ERR! gyp ERR! stack Error: `gyp` failed with exit code: 1
npm ERR! gyp ERR! stack     at ChildProcess.onCpExit (/opt/homebrew/Cellar/node@18/18.17.1/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:325:16)
npm ERR! gyp ERR! stack     at ChildProcess.emit (node:events:514:28)
npm ERR! gyp ERR! stack     at ChildProcess._handle.onexit (node:internal/child_process:291:12)
npm ERR! gyp ERR! System Darwin 23.0.0
npm ERR! gyp ERR! command "/opt/homebrew/Cellar/node@18/18.17.1/bin/node" "/opt/homebrew/Cellar/node@18/18.17.1/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "configure" "--fallback-to-build" "--module=/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand/lib/binding/darwin-arm64/node-magickwand.node" "--module_name=node-magickwand" "--module_path=/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand/lib/binding/darwin-arm64" "--napi_version=9" "--node_abi_napi=napi" "--napi_build_version=0" "--node_napi_label=node-v108"
npm ERR! gyp ERR! cwd /Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand
npm ERR! gyp ERR! node -v v18.17.1
npm ERR! gyp ERR! node-gyp -v v9.3.1
npm ERR! gyp ERR! not ok 
npm ERR! node-pre-gyp ERR! build error 
npm ERR! node-pre-gyp ERR! stack Error: Failed to execute '/opt/homebrew/Cellar/node@18/18.17.1/bin/node /opt/homebrew/Cellar/node@18/18.17.1/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js configure --fallback-to-build --module=/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand/lib/binding/darwin-arm64/node-magickwand.node --module_name=node-magickwand --module_path=/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand/lib/binding/darwin-arm64 --napi_version=9 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v108' (1)
npm ERR! node-pre-gyp ERR! stack     at ChildProcess.<anonymous> (/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/@mapbox/node-pre-gyp/lib/util/compile.js:89:23)
npm ERR! node-pre-gyp ERR! stack     at ChildProcess.emit (node:events:514:28)
npm ERR! node-pre-gyp ERR! stack     at maybeClose (node:internal/child_process:1091:16)
npm ERR! node-pre-gyp ERR! stack     at ChildProcess._handle.onexit (node:internal/child_process:302:5)
npm ERR! node-pre-gyp ERR! System Darwin 23.0.0
npm ERR! node-pre-gyp ERR! command "/opt/homebrew/Cellar/node@18/18.17.1/bin/node" "/Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build"
npm ERR! node-pre-gyp ERR! cwd /Users/jackmatthews/Projects/DecorProject/decor-server/node_modules/node-magickwand
npm ERR! node-pre-gyp ERR! node -v v18.17.1
npm ERR! node-pre-gyp ERR! node-pre-gyp -v v1.0.11
npm ERR! node-pre-gyp ERR! not ok

npm ERR! A complete log of this run can be found in: /Users/jackmatthews/.npm/_logs/2023-10-18T04_48_25_721Z-debug-0.log
```
user: FieryFlames
issue_14951: state: open
title: [bug] Semicolon not escaped when CMakeDeps generates target properties
body: ### Environment details

* Operating System+version: Ubuntu 18.04
* Compiler+version: gcc 7.5
* Conan version: conan 1.61.0
* Python version: Python 3.6.9


### Steps to reproduce

conanfile.py (standard with "mariadb-connector-c/3.3.3" as a dependency)
```python
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMakeDeps, CMake, cmake_layout


class TestMariadbConan(ConanFile):
    name = "test_mariadb"
    version = "0.1.0"

    # Optional metadata
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of TestMariadb here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"

    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "CMakeLists.txt"

    requires = ["mariadb-connector-c/3.3.3"]

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()
        deps = CMakeDeps(self)
        deps.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()

    def package_info(self):
        self.cpp_info.libs = ["test_mariadb"]
```

CMakeLists.txt:
```cmake
find_package(mariadb-connector-c REQUIRED)

get_target_property(output mariadb-connector-c::mariadb-connector-c INTERFACE_INCLUDE_DIRECTORIES)
message(STATUS "${output}")
```

Run:
* `conan install .`
* `conan build .`

### Logs

Running `conan build .` displays the following output (trimming the irrelevant warnings):

```
-- Using Conan toolchain: /home/poxa151/tmp/test_mariadb/build/Release/generators/conan_toolchain.cmake
-- Conan: Target declared 'mariadb-connector-c::mariadb-connector-c'
-- Conan: Target declared 'ZLIB::ZLIB'
-- Conan: Component target declared 'CURL::libcurl'
-- Conan: Component target declared 'OpenSSL::Crypto'
-- Conan: Component target declared 'OpenSSL::SSL'
-- Conan: Target declared 'openssl::openssl'
-- Conan: Including build module from '/home/poxa151/.conan/data/openssl/3.1.3/_/_/package/c606a0dd8a0c8668b09aa21600e0d8423899894a/lib/cmake/conan-official-openssl-variables.cmake'
-- $<$<CONFIG:Release>:/home/poxa151/.conan/data/mariadb-connector-c/3.3.3/_/_/package/66c5704ea4604600bea83076580ec10d77f539f9/include;/home/poxa151/.conan/data/mariadb-connector-c/3.3.3/_/_/package/66c5704ea4604600bea83076580ec10d77f539f9/include/mariadb>
```

The issue is the last line, showing the content of the generated INTERFACE_INCLUDE_DIRECTORIES of the `mariadb-connector-c::mariadb-connector-c`, generated by CMakeDeps.
The semicolon in the middle can cause trouble when one loops over the variable.
In a generator expression like this, it should be escaped/replaced with `$<SEMICOLON>` (doc: https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#escaped-characters).

Instead of generating:
```
$<$<CONFIG:Release>:/home/poxa151/.conan/data/mariadb-connector-c/3.3.3/_/_/package/66c5704ea4604600bea83076580ec10d77f539f9/include;/home/poxa151/.conan/data/mariadb-connector-c/3.3.3/_/_/package/66c5704ea4604600bea83076580ec10d77f539f9/include/mariadb>
```
generate
```
$<$<CONFIG:Release>:/home/poxa151/.conan/data/mariadb-connector-c/3.3.3/_/_/package/66c5704ea4604600bea83076580ec10d77f539f9/include$<SEMICOLON>/home/poxa151/.conan/data/mariadb-connector-c/3.3.3/_/_/package/66c5704ea4604600bea83076580ec10d77f539f9/include/mariadb>
```
user: dalaen
issue_14946: state: open
title: [feature] Please add qmake generator for Conan v2
body: ### What is your suggestion?

I have huge project depending on qmake. It blocks me from moving to Conan v2. I dont have the knowledge to create the generator by myself.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: spakarl
issue_14943: state: open
title: [feature] Improves AutotoolsToolchain cross-building flow
body: It would be great to have a better way to enter/change host/build triplets in case of cross-building flow:

```python
        if cross_building(self) and is_msvc(self):
            # tc.cross_build could contain all the information (like MesonToolchain)
            host_arch = tc.cross_build["host"]["arch"]
            build_arch = tc.cross_build["build"]["arch"]
            # Let's trust that AutotoolsToolchain is getting the correct GNU arch
            if host_arch and build_arch:
                tc.cross_build["host"]["triplet"] = f"{host_arch}-w64-mingw32"
                tc.cross_build["build"]["triplet"] = f"{build_arch}-w64-mingw32"
```
(very similar to MesonToolchain approach)

_Originally posted by @franramirez688 in https://github.com/conan-io/conan-center-index/pull/18058#discussion_r1360383992_
            
user: franramirez688
issue_14937: state: open
title: [question] Why does export_sources copy to the repository root?
body: ### What is your question?

Using Conan 1.61, I have a project structure like this:

```
all/
    patches/
    conanfile.py
```

The conanfile contains an `exports_sources` attribute and also implements a `source()` to pull some files from Artifactory.

`exports_sources = "patches/*"`

My package also defines a `self.layout` with:

```python
    def layout(self):
        self.folders.root = os.pardir
        self.folders.source = 'src'
        self.folders.build = 'build'
```

When executing the `conan source` command, I want Conan to copy the exported source (`patches/*`) into the `src/` folder, like this:

```
all/
    patches/
    conanfile.py
src/
    src_from_artifactory/
    patches/
```

However, it copies it into the root of the project instead:

```
all/
    patches/
    conanfile.py
patches/
src/
    src_from_artifactory/
```

I see the similar behavior in the cache when calling `conan create`, where `patches/` is adjacent to the `src/` directory instead of within it:

```
export_source/
    patches/
source/
    patches/
    src/
```

I believe the code that causes this behavior is this:
https://github.com/conan-io/conan/blob/release/1.61/conans/client/source.py#L65

What's the rationale, or what should I be doing differently?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jastich
issue_14935: state: open
title: [bug] PkgConfigDeps: Separate pkg-config files between the host and build contexts by directory
body: ### What is your suggestion?

Currently, the PkgConfigDeps generator allows placing only specific dependencies in the build context by opting to explicitly indicate them as such and even requires renaming them when used in both the build and host contexts.
This functionality is primarily used by Meson projects which use pkg-config files to find build tools, such as how `xkbcommon` and `wayland` find the `wayland-scanner` program provided by the `wayland` package.
The current approach is problematic for multiple reasons.

1. It requires explicitly defining which `tool_requires` packages should be available in the build context for PkgConfigDeps, which requires more work effort in the `conanfile.py`.
1. Renaming pkg-config files _always_ requires a corresponding patch to the consumer's build system to find the renamed pkg-config file.
1. It's potentially necessary to manually work out the dependencies of all packages placed in the build context and to add each of the dependencies to `build_context_activated` to ensure that all dependencies are found properly by pkg-config. Currently, everything falls apart here when renaming an individual package with a build context suffix, as the dependencies listed as `Requires` of the renamed pkg-config files are not themselves renamed, resulting in pkg-config files in the build context requiring pkg-config files in the host context.
    Here's an example of `wayland-scanner_BUILD.pc` demonstrating this predicament.
    ```
    prefix=/home/jordan/.conan/data/wayland/1.22.0/_/_/package/3bac7fb7b73d7ba4f2368553fe0e26308f7b9f0b
    # Custom PC content
    datarootdir=${prefix}/res
    pkgdatadir=${datarootdir}/wayland
    bindir=${prefix}/bin
    wayland_scanner=${bindir}/wayland-scanner

    Name: wayland-scanner_BUILD
    Description: Conan component: wayland_BUILD-wayland-scanner_BUILD
    Version: 1.22.0
    Libs: 
    Cflags: 
    Requires: expat libxml-2.0
    ```
    Note that it requires `expat` while `expat.pc` is in the host context and not the build context.
    No `expat_BUILD.pc` is generated automatically, either.
1. In Meson, it's necessary to explicitly define `tc.project_options["build.pkg_config_path"] = self.generators_folder` to add the generators directory to the pkg-config search path for native packages.

An alternative approach is to separate the pkg-config files for the host and build contexts by directory rather than by renaming pkg-config files.
This solves the three problems with the current approach.

1. The pkg-config files can be safely generated for all build and host requirements automatically.
1. The generated pkg-config files can safely use the same names, as they are placed in separate directories. No patching is necessary.
1. The pkg-config files for all dependencies can be produced automatically.
1. The Meson generator can automatically define the `build.pkg_config_path` to point to the directory containing the pkg-config files in the build context.

There are a couple of drawbacks to this approach.

1. It can result in the generation of extraneous pkg-config files which are not required when building a package, especially when building non-Meson projects which don't appear - in my limited experience - to find dependencies in the build context in this manner.
1. Changes to PkgConfigDeps must not break existing packages, requiring careful consideration of how this is implemented.
1. The MesonToolchain generator needs to be aware when pkg-config directories are being used for both the build and host contexts so that it can define `pkg_config_path` and `build.pkg_config_path` appropriately.

To address the concerns, perhaps the implementation could follow a similar approach to `VirtualBuildEnv` and `VirtualRunEnv` where separate generators are used per context or the existing `PkgConfigDeps` could be modified to provide a different constructor or to provide an option to generate pkg-config files for build dependencies in a separate directory from host dependencies.
The implementation could still require consumers to declare specific dependencies to provide in the build context, if desired, to reduce the number of pkg-config files generated, but dependencies of any such package should automatically have pkg-config files generated in the build context as well to ensure that transitive dependencies can be found if needed.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jwillikers
issue_14934: state: open
title: [bug] Tool not available during generate stage
body: ### Environment details

* Operating System+version: ubuntu 22.04
* Compiler+version:  gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
* Conan version: 2.0.13
* Python version: 3.10.12


### Steps to reproduce

Running
```
conan create .
```
I've provided a cut down example
https://gist.github.com/ashley-b/8af36621c0c476b13b4583e64cecff9d#file-conanfile-py


### Logs

During the generate stage it find the systems cmake version 3.22.1, then during build it finds cmake version 3.27.7 which is provided the the tool_requires
```
--> RUN conan create .

======== Exporting recipe to the cache ========
my_test/1.0.0: Exporting package recipe: /home/appuser/src/conanfile.py
my_test/1.0.0: Copied 1 '.py' file: conanfile.py
my_test/1.0.0: Copied 1 '.txt' file: CMakeLists.txt
my_test/1.0.0: Exported to cache folder: /home/appuser/.conan2/p/my_tefc3c8247911d1/e
my_test/1.0.0: Exported: my_test/1.0.0#03ef367afc3883c11d8f231dec9ec2cc (2023-10-14 13:54:39 UTC)

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux


======== Computing dependency graph ========
cmake/3.27.7: Not found in local cache, looking in remotes...
cmake/3.27.7: Checking remote: conancenter
cmake/3.27.7: Downloaded recipe revision 6e11610a238b9292dffda14c34bb53e6
Graph root
    cli
Requirements
    my_test/1.0.0#03ef367afc3883c11d8f231dec9ec2cc - Cache
Build requirements
    cmake/3.27.7#6e11610a238b9292dffda14c34bb53e6 - Downloaded (conancenter)
Resolved version ranges
    cmake/[>=3.23 <4]: cmake/3.27.7

======== Computing necessary packages ========
my_test/1.0.0: Forced build from source
Requirements
    my_test/1.0.0#03ef367afc3883c11d8f231dec9ec2cc:8631cf963dbbb4d7a378a64a6fd1dc57558bc2fe - Build
Build requirements
    cmake/3.27.7#6e11610a238b9292dffda14c34bb53e6:63fead0844576fc02943e16909f08fcdddd6f44b#9583e30af903650c949bb4ebeaa67180 - Download (conancenter)

======== Installing packages ========

-------- Downloading 1 package --------
cmake/3.27.7: Retrieving package 63fead0844576fc02943e16909f08fcdddd6f44b from remote 'conancenter' 
cmake/3.27.7: Downloading 42.4MB conan_package.tgz
cmake/3.27.7: Decompressing 42.4MB conan_package.tgz
cmake/3.27.7: Package installed 63fead0844576fc02943e16909f08fcdddd6f44b
cmake/3.27.7: Downloaded package revision 9583e30af903650c949bb4ebeaa67180
cmake/3.27.7: Appending PATH environment variable: /home/appuser/.conan2/p/cmake857e6d21f32d2/p/bin

-------- Installing package my_test/1.0.0 (2 of 2) --------
my_test/1.0.0: Building from source
my_test/1.0.0: Package my_test/1.0.0:8631cf963dbbb4d7a378a64a6fd1dc57558bc2fe
my_test/1.0.0: Copying sources to build folder
my_test/1.0.0: Building your package in /home/appuser/.conan2/p/b/my_te6c49ee2eb2830/b
my_test/1.0.0: Calling generate()
my_test/1.0.0: Generators folder: /home/appuser/.conan2/p/b/my_te6c49ee2eb2830/b/build/Release/generators
my_test/1.0.0: RUN: echo $PATH
/home/appuser/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

my_test/1.0.0: RUN: cmake --version
cmake version 3.22.1

CMake suite maintained and supported by Kitware (kitware.com/cmake).

my_test/1.0.0: CMakeToolchain generated: conan_toolchain.cmake
my_test/1.0.0: CMakeToolchain generated: CMakePresets.json
my_test/1.0.0: CMakeToolchain generated: ../../../CMakeUserPresets.json
my_test/1.0.0: Generating aggregated env files
my_test/1.0.0: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
my_test/1.0.0: Calling build()
my_test/1.0.0: RUN: echo $PATH
/home/appuser/.conan2/p/cmake857e6d21f32d2/p/bin:/home/appuser/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

my_test/1.0.0: RUN: cmake --version
cmake version 3.27.7

CMake suite maintained and supported by Kitware (kitware.com/cmake).

my_test/1.0.0: Running CMake.configure()
my_test/1.0.0: RUN: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/appuser/.conan2/p/b/my_te6c49ee2eb2830/b/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/appuser/.conan2/p/b/my_te6c49ee2eb2830/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/appuser/.conan2/p/b/my_te6c49ee2eb2830/b"
-- Using Conan toolchain: /home/appuser/.conan2/p/b/my_te6c49ee2eb2830/b/build/Release/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- Conan toolchain: C++ Standard 17 with extensions ON
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The CXX compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.3s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_POLICY_DEFAULT_CMP0091


-- Build files have been written to: /home/appuser/.conan2/p/b/my_te6c49ee2eb2830/b/build/Release

my_test/1.0.0: Running CMake.build()
my_test/1.0.0: RUN: cmake --build "/home/appuser/.conan2/p/b/my_te6c49ee2eb2830/b/build/Release" -- -j4

my_test/1.0.0: Package '8631cf963dbbb4d7a378a64a6fd1dc57558bc2fe' built
my_test/1.0.0: Build folder /home/appuser/.conan2/p/b/my_te6c49ee2eb2830/b/build/Release
my_test/1.0.0: Generating the package
my_test/1.0.0: Packaging in folder /home/appuser/.conan2/p/b/my_te6c49ee2eb2830/p
my_test/1.0.0: Calling package()
my_test/1.0.0: Running CMake.install()
my_test/1.0.0: RUN: cmake --install "/home/appuser/.conan2/p/b/my_te6c49ee2eb2830/b/build/Release" --prefix "/home/appuser/.conan2/p/b/my_te6c49ee2eb2830/p"
-- Install configuration: "Release"

my_test/1.0.0: package(): WARN: No files in this package!
my_test/1.0.0: Created package revision 50b61b7a5f22ea7e0a14e1fc13cf180f
my_test/1.0.0: Package '8631cf963dbbb4d7a378a64a6fd1dc57558bc2fe' created
my_test/1.0.0: Full package reference: my_test/1.0.0#03ef367afc3883c11d8f231dec9ec2cc:8631cf963dbbb4d7a378a64a6fd1dc57558bc2fe#50b61b7a5f22ea7e0a14e1fc13cf180f
my_test/1.0.0: Package folder /home/appuser/.conan2/p/b/my_te6c49ee2eb2830/p
WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated:     'env_info' used in: cmake/3.27.7
```
user: ashley-b
issue_14929: state: open
title: Behaviour with conan.lock and source method
body: ### What is your question?

Hi, I would like to use the conan 2.0 lockfile to pin the recipes to use when building executables and libraries. The recipes specify a custom source method that uses git to clone the repository. The conan.lock is committed to the repository to align every developer to the same version of the dependencies. CI will build, export and upload the executable and libraries to an artifactory instance.
When a user, not a developer, downloads the recipe from artifactory, the conan.lock file does not exist because the user has not yet downloaded the sources.
The question I have is regarding this behaviour: how can I ensure that an end user will resolve the dependencies using the same conan.lock file used by the developers? Can I use export_sources alongside the source method?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: alessiosacco
issue_14925: state: open
title: [feature] allow ignoring untracked files in Git.is_dirty()
body: ### What is your suggestion?

Hi,
In our internal projects we use the `tools.scm.Git` object with `set_version()` to determine package version from git tags.

With a bit of custom logic this works great, however: 
the value of `Git.is_dirty()` returns True, even if the repository is clean, if that repository also contains untracked files.

I would note this is different to the behaviour of setting e.g. "revision_mode=scm" or "revision_mode=scm_folder" which do not consider untracked files to make the repository dirty.

Thus, for example, I end up with a package (whose revision mode is "scm_folder") but which ends up getting a version attribute of project/0.3.3-dev.13+0c9b7c4-dirty.


I propose either:
   - changing behaviour of `tools.scm.Git.is_dirty()` to use `git status -s -u no` so that it ignores untracked files and returns True  when untracked files are present to align behaviour with revision mode (understand this probably isn't allowed due to compatibility
   - adding an optional parameter to `tools.scm.Git.is_dirty()` (e.g. `consider_untracked: bool`) so that users can choose this behaviour with default value of True which would retain the existing behaviour

Happy to open PR for that latter if it is the preferred option.

THanks






### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: weatherhead99
issue_14922: state: open
title: [question] Best practices for libraries that are configured using targets with specific names and headers
body: ### What is your question?

I know that Conan has limited support for microcontrollers and that the world of libraries for microcontrollers is lagging quite far behind in terms of tooling support so I'd like figure out how to best deal with the additional complexities a library such as [FreeRTOS-kernel](https://github.com/FreeRTOS/FreeRTOS-Kernel) introduces. If you look at the way that CMake is set up it requires a target `freertos_config` to be defined. This target generally just needs to be an interface target with some specific header files. Most of the time this is just a file called `FreeRTOSConfig.h` but depending on the architecture in use it might also need a file called `secure_context.h`. I am not sure whether other architectures require additional files. These files would normally be highly tied to the platform the application is running on so the need to configure it correctly per platform is critical. Thus I would like to know if there are any best practices for dealing with a situation like this.

My current solution is to download and unpack the specified release in `source()` into a subfolder. Then in the root I have a `CMakeLists.txt` in which I declare the `freertos_config` target. Crucially I also generate the headers in `build()` based on various settings and options. This is quite cumbersome as there are a fair number of [configuration options](https://www.freertos.org/a00110.html) that might need to be set. This approach works well until one of the configuration values need to depend on variable defined in the vendors SDK of the platform. Another downside to this is that the list of options becomes very long and most of the accepted values are set to `["ANY"]` or `["ANY", None]` (This is tangential to this, but based on my current understanding of conan I think replacing the current options model with a `TypedDict` implementation could fix this). 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ohunter
issue_14910: state: open
title: [bug] Backport the fix for defining compiler_executables as a list for Meson to Conan V1
body: ### Environment details

Please backport #14676 to Conan V1.
It's necessary to use the compiler executables with Meson in this way in order to cross-compile the `libsystemd` package due to bug  #10288.

### Steps to reproduce

_No response_

### Logs

_No response_
user: jwillikers
issue_14908: state: open
title: [feature] Add option to pylint recipe on export
body: ### What is your suggestion?

It would be useful to optionally lint on export to catch errors early. I tried:
```
python -m pylint --errors-only --load-plugins=conans.pylint_plugin conanfile.py
```
and got:
```
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Users\rob.conde\AppData\Roaming\Python\Python311\site-packages\pylint\__main__.py", line 10, in <module>
    pylint.run_pylint()
  File "C:\Users\rob.conde\AppData\Roaming\Python\Python311\site-packages\pylint\__init__.py", line 34, in run_pylint
    PylintRun(argv or sys.argv[1:])
  File "C:\Users\rob.conde\AppData\Roaming\Python\Python311\site-packages\pylint\lint\run.py", line 155, in __init__
    linter.load_plugin_modules(self._plugins)
  File "C:\Users\rob.conde\AppData\Roaming\Python\Python311\site-packages\pylint\lint\pylinter.py", line 380, in load_plugin_modules
    module = astroid.modutils.load_module_from_name(modname)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\rob.conde\AppData\Roaming\Python\Python311\site-packages\astroid\modutils.py", line 194, in load_module_from_name
    module = importlib.import_module(dotted_name)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Program Files\Python311\Lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 940, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "C:\Program Files\Python311\Lib\site-packages\conans\pylint_plugin.py", line 7, in <module>
    from pylint.interfaces import IRawChecker
ImportError: cannot import name 'IRawChecker' from 'pylint.interfaces' (C:\Users\rob.conde\AppData\Roaming\Python\Python311\site-packages\pylint\interfaces.py)
Traceback (most recent call last):
  File "D:\dev\ff1\Conan\scripts\export_recipes.py", line 246, in <module>
    cmds = get_cmds()
           ^^^^^^^^^^
  File "D:\dev\ff1\Conan\scripts\export_recipes.py", line 75, in get_cmds
    subprocess.check_call(cmd, shell=True)
  File "C:\Program Files\Python311\Lib\subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'python -m pylint --errors-only --load-plugins=conans.pylint_plugin D:\dev\ff1\Conan\recipes/actipro/conanfile.py' returned non-zero exit status 1.
```
and I also tried without the plugin, which worked for some cases but broke on recipes using:
```
get(self, **self.conan_data["sources"][self.version], strip_root=True)
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: rconde01
issue_14907: state: open
title: [question] Which binaries are provided by conan-center-index
body: ### What is your question?

Hi! I have a question regarding conan-center-index.

For a project for which we plan a release, we think about fixing the revisions of the recipes inside the conanfile.txt.

My question is: Will conan-center-index provide binaries built with this revision of the recipe, or does conan-center-index only provide binaries built with the most recent revision?
Because in the latter case, this would mean that at some point, all packages would need to be built locally, because the binaries won't be available on conan-center-index anymore, right?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Jean1995
issue_14904: state: open
title: OpenCV doesn't install
body: ### Environment details

* Operating System+version: Linux
* Compiler+version:
* Conan version: 2
* Python version:

Tried following guide at https://docs.conan.io/2/tutorial/consuming_packages/build_simple_cmake_project.html to install OpenCV.

Following is my CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.15)
project(project)
find_package(opencv REQUIRED )
add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} PRIVATE opencv::opencv)
```

Howver on `cmake --build .` I get follwing error:
```
.conan2/p/libx2b6c9cdb10bd18/p/lib/libx265.a(common.cpp.o): in function `x265::x265_qp2qScale(double)':
common.cpp:(.text+0x2e5): undefined reference to `__exp2_finite'
collect2: error: ld returned 1 exit status
gmake[2]: *** [CMakeFiles/gurkha.dir/build.make:179: gurkha] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/gurkha.dir/all] Error 2
gmake: *** [Makefile:91: all] Error 2
```


### Steps to reproduce

conanfile.txt:
```
[requires]
opencv/4.5.5

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

```

`conan profile detect --force`


```$ cd build
$ cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release
$ cmake --build .````

### Logs

_No response_
user: deepwilson
issue_14901: state: open
title: [question] VirtualRunEnv does not take tool_requires into account?
body: ### What is your question?

Hi, I am currently migrating to Conan 2 (i.e. 2.0.12) and facing issues with the `VirtualRunEnv` generator when using `gcc` as a conan package which is obviously needed in the `buildenv` but also in the `runenv`, since it also provides libs like e.g. `libstdc++.so` and the like. 
My understanding was that in Conan 2 the generator automatically takes care of propagating `libdirs` to `LD_LIBRARY_PATH` in the `runenv`. But this is apparently not the case for `tool_requires`, although I expected this to be the reason why `tool_requires` sets the trait `run=True`.

Specifically I first encountered the issue when building `geographiclib` (https://github.com/conan-io/conan-center-index/blob/master/recipes/geographiclib/all/test_package/conanfile.py). I provide the compiler dependency using a profile like this:
```
[settings]
compiler=gcc
compiler.version=11.4
compiler.libcxx=libstdc++11

[tool_requires]
gcc/11.4.0@me/testing
```

Building `geographiclib` works fine, but executing the test package leads to the following error:

```
======== Testing the package: Executing test ========
geographiclib/1.52@me/testing (test package): Running test()
geographiclib/1.52@me/testing (test package): RUN: ./test_package
./test_package: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /home/me/.conan2/p/b/geogr35b2f1e80aeb9/p/lib/libGeographic.so.19)

ERROR: geographiclib/1.52@me/testing (test package): Error in test() method, line 26
        self.run(bin_path, env="conanrun")
        ConanException: Error 1 while executing
```

Obviously the `libdir` of `gcc` is not part of the `LD_LIBRARY_PATH` and instead of the `libstdc++.so` provided by the conan package the system one is found during runtime, which does not match the version from compilation.

This can be mitigated by hacking an explicit runtime dependency into the test package like `self.requires("gcc/11.4.0@me/stable", run=True)`. Then executing the test executable in the `conanrun` env works. But this is just a hack.

From looking at the code in `conan/tools/env/virtualrunenv.py` in the `environment()` method, I see that only `host` and `test` dependencies are taken into account for the env: 

```
        host_req = self._conanfile.dependencies.host
        test_req = self._conanfile.dependencies.test
        for require, dep in list(host_req.items()) + list(test_req.items()):
            if dep.runenv_info:
                runenv.compose_env(dep.runenv_info)
            if require.run:  # Only if the require is run (shared or application to be run)
                _os = self._conanfile.settings.get_safe("os")
                runenv.compose_env(runenv_from_cpp_info(dep, _os))
```

But those `host` and `test` properties directly filter for `build=False` which obviously does not take `tool_requires` into account which use `build=True`. See `conans/model/dependencies.py` line 138:

```
    @property
    def host(self):
        return self.filter({"build": False, "test": False, "skip": False})

    @property
    def test(self):
        # Not needed a direct_test because they are visible=False so only the direct consumer
        # will have them in the graph
        return self.filter({"build": False, "test": True, "skip": False})
```

Now, is there a misunderstanding on my side? I would have expected that since `tool_requires` sets `run=True`, those should also be reflected in the `VirtualRunEnv`. Generally I think all dependecies with `run=True` should be reflected in the `VirtualRunEnv`.
Indeed changing the code in `conan/tools/env/virtualrunenv.py` to something like this, makes is work as I expected:
```
        host_req = self._conanfile.dependencies.host
        test_req = self._conanfile.dependencies.test
        run_req = self._conanfile.dependencies.filter({"run": True})
        for require, dep in list(host_req.items()) + list(test_req.items()) + list(run_req.items()):
            if dep.runenv_info:
                runenv.compose_env(dep.runenv_info)
            if require.run:  # Only if the require is run (shared or application to be run)
                _os = self._conanfile.settings.get_safe("os")
                runenv.compose_env(runenv_from_cpp_info(dep, _os))
```

What is the best practice here for dependencies needed during build and run?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: pklip
issue_14900: state: open
title: [feature] Support MSVC Preview
body: ### What is your suggestion?

When trying to build conan packages on Windows (i.e. `install --build missing`) as well as creating a profile with detection (`profile create --detect`) conan fails to recognize / find a fully working and installed Visual Studio Preview Version. As such when building packages it fails claiming that the compiler cannot be found.

conan should be able to utilize preview builds of MSVC that are installed.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Sil3ntStorm
issue_14899: state: open
title: On using requires() - Installing my own created recipe dependencies do not download the included bin file(zip), just the recipes
body: ### What is your question?

Hi! I'm trying to utilize Conan's dependency handling.

I created multiple packages that don't need to compile anything, just contains a zipped bin file in each of them (included through 'exports_sources', path is same folder as recipe).

Ex: 
Package A (contains zipped bin file A )
Package B (contains zipped bin file B)

When I install them individually, they successfully download both the recipe and the zipped bin file.
But when I make them reference each other, say Package A requires Package B (self.requires), I get the following result:
-Recipe for Package B is downloaded, zipped bin file is not 
-Recipe and zipped bin file for Package A are both downloaded

I saw somewhere that when we don't compile the exports_sources, they wont be downloaded when included as package dependency through self.requires of a package.

Any thoughts are appreciated!


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: exitingtheloop
issue_14896: state: open
title: Package name for dependencies while resolving/calling find_package()
body: ### What is your question?

Here is the scenario.
A conan lib package with name 'nanopb' exists.  Also provides FindNanopb.cmake (MODULE mode).

When it's included as dependent library and searched using find_package(Nanopb), able to find 'FindNanopb.cmake' and rest works fine.  Assume this library as libabc

  Now, when 'libabc' is included as dependent lib in another conan repo (say xyz), things fail.  Reason being it tries to look for 'Find**nanopb**.cmake' (Please note the spelling) and fails.

Further analysis shows that, first dependency list is built for libabc which includes the names as 'nanopb' in this case.  Then, libabc-config.cmake tries to find the module for each of the names in the dependency list i.e. triggers module find for 'nanopb' and hence tries to search Findnanopb.cmake.  But expected, this file doesn't exists (FindNanopb.cmake exists).

foreach(_DEPENDENCY ${libabc_FIND_DEPENDENCY_NAMES} )
     22     # Check that we have not already called a find_package with the transitive dependency
     23     if(NOT ${_DEPENDENCY}_FOUND)
     24         find_dependency(${_DEPENDENCY} REQUIRED ${${_DEPENDENCY}_FIND_MODE})     >>>>>>>>>
     25     endif()
     26 endforeach(

One the ways is to keep the name of package and Findxxx same i.e. nanopb in this case.  

But, just wondering if conan provides a way to address such scenarios where behavior is different when find_package() is called directly or indirectly via another package.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: vithalsm
issue_14895: state: open
title: [question] Replacement for self.copy(root_package)
body: ### What is your question?

I found `self.copy(root_package)` useful in v1 when doing imports. Is there a replacement in v2?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: rconde01
issue_14894: state: open
title: [question] How to make a single tool package for debug and release builds in Conan 2.0
body: ### What is your question?

I have a package which builds a tool. I always want a release build of this tool despite what the consumer is using. I am using `CMakeToolchain` and `CMake` classes. I think I can force `CMAKE_BUILD_TYPE` in `CMakeToolchain`, but `CMake` is insisting the package needs a `build_type` setting - which would mean I need to duplicate the package for debug/release. Is there a way to accomplish what I want?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: rconde01
issue_14893: state: open
title: [bug] Incorrect behavior with CMakeToolchain when package doesn't contain compiler setting
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: Visual Studio 2022
* Conan version: 2.0.13
* Python version: 3.11.5


### Steps to reproduce

Run `python repro.py` in the attached file.

The recipe doesn't include `compiler` in the settings, because in this case it was building a tool, and I didn't care what compiler was used...only the os. `CMakeToolchain` can't find a compiler and also ends up selecting the "MinGW MakeFiles" generator. It seems like the [code](https://github.com/conan-io/conan/blob/4650e1260c7ae2b681dcef1107716d2520871585/conan/tools/cmake/toolchain/toolchain.py#L212) should be handling this situation but it doesn't. At the least it would have been helpful for the `CMakeToolchain` generator to report an error indicating the issue here, but I think potentially `CMakeToolchain` should work without a compiler setting - but either way is ok.

### Logs

```
======== Exporting recipe to the cache ========
test/1.0: Exporting package recipe: D:\dev\third_party_bug_reports\conan\cmaketoolchain_vcvars\recipe\conanfile.py
test/1.0: Copied 1 '.py' file: conanfile.py
test/1.0: Copied 1 '.txt' file: CMakeLists.txt
test/1.0: Copied 1 '.cpp' file: main.cpp
test/1.0: Exported to cache folder: D:\dev\third_party_bug_reports\conan\cmaketoolchain_vcvars\conan_home\p\test4ee0011e56607\e
test/1.0: Exported: test/1.0#73e719f5d98fb94f0d56ecad1bc77a24 (2023-10-08 17:40:15 UTC)

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows


======== Computing dependency graph ========
Graph root
    cli
Requirements
    test/1.0#73e719f5d98fb94f0d56ecad1bc77a24 - Cache

======== Computing necessary packages ========
test/1.0: Forced build from source
Requirements
    test/1.0#73e719f5d98fb94f0d56ecad1bc77a24:ebec3dc6d7f6b907b3ada0c3d3cdc83613a2b715 - Build

======== Installing packages ========

-------- Installing package test/1.0 (1 of 1) --------
test/1.0: Building from source
test/1.0: Package test/1.0:ebec3dc6d7f6b907b3ada0c3d3cdc83613a2b715
test/1.0: Copying sources to build folder
test/1.0: Building your package in D:\dev\third_party_bug_reports\conan\cmaketoolchain_vcvars\conan_home\p\b\testc973b6df452c0\b
test/1.0: Calling generate()
test/1.0: Generators folder: D:\dev\third_party_bug_reports\conan\cmaketoolchain_vcvars\conan_home\p\b\testc973b6df452c0\b
test/1.0: CMakeToolchain generated: conan_toolchain.cmake
test/1.0: CMakeToolchain generated: CMakePresets.json
test/1.0: Generating aggregated env files
test/1.0: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
test/1.0: Calling build()
test/1.0: Running CMake.configure()
test/1.0: RUN: cmake -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE="D:/dev/third_party_bug_reports/conan/cmaketoolchain_vcvars/conan_home/p/b/testc973b6df452c0/b/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="D:/dev/third_party_bug_reports/conan/cmaketoolchain_vcvars/conan_home/p/b/testc973b6df452c0/p" -DCMAKE_SH="CMAKE_SH-NOTFOUND" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "D:\dev\third_party_bug_reports\conan\cmaketoolchain_vcvars\conan_home\p\b\testc973b6df452c0\b"
-- Using Conan toolchain: D:/dev/third_party_bug_reports/conan/cmaketoolchain_vcvars/conan_home/p/b/testc973b6df452c0/b/conan_toolchain.cmake
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also "D:/dev/third_party_bug_reports/conan/cmaketoolchain_vcvars/conan_home/p/b/testc973b6df452c0/b/CMakeFiles/CMakeOutput.log".

test/1.0: ERROR:
Package 'ebec3dc6d7f6b907b3ada0c3d3cdc83613a2b715' build failed
test/1.0: WARN: Build folder D:\dev\third_party_bug_reports\conan\cmaketoolchain_vcvars\conan_home\p\b\testc973b6df452c0\b
*********************************************************
Recipe 'test/1.0' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: test/1.0: Error in build() method, line 18
        cmake.configure()
        ConanException: Error 1 while executing
Traceback (most recent call last):
  File "D:\dev\third_party_bug_reports\conan\cmaketoolchain_vcvars\repro.py", line 16, in <module>
    subprocess.check_call("conan create ./recipe -pr:b win_release_profile -pr:h win_release_profile ")
  File "C:\Program Files\Python311\Lib\subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'conan create ./recipe -pr:b win_release_profile -pr:h win_release_profile ' returned non-zero exit status 1.
```
user: rconde01
issue_14888: state: open
title: [question] Transitive dependencies stop working when using components
body: ### What is your question?

I don't know if this is a bug or I haven't understand something about using components. I have two libs (both packaged in conan) and a test package with the following dependencies: _base_ <- _mm_ <- test_package. Now the _mm_ lib is very complex, so I want to use components. But as soon as I start defining my components, all the transitive dependencies seem to disappear.

The _base_ lib is required by _mm_ with transitive headers like this: `self.requires("base/[]@trs/stable", transitive_headers=True)`

Below I added some log files, one for the run without any components and the second for the run after defining components. For simplicity, I only changed the `package_info()` and linked against the "main" target of the _mm_ lib in my test_package, but if I use a component target instead, it behaves the same way.

Maybe I'm missing something essential when using components?

### Not using components
Build output (with empty `package_info()`). As you can see, the compile command contains include headers for my transitive dependencies:
```
x86_64-linux-gnu-g++ -DVCSBASE_BUILD_WITH_CMAKE -isystem /home/fschoenm/.conan2/p/b/vcsmm095c3d253d25f/p/include -isystem /home/fschoenm/.conan2/p/b/vcsba295d957b646a4/p/include -isystem /home/fschoenm/.conan2/p/boost4a36ef436b330/p/include -m64 -g -MD -MT CMakeFiles/vcsmm-test.dir/main.cpp.o -MF CMakeFiles/vcsmm-test.dir/main.cpp.o.d -o CMakeFiles/vcsmm-test.dir/main.cpp.o -c /home/fschoenm/devel/vcsmm/test_package/main.cpp
```
Target-debug.cmake when not using components. I don't know if it matters but this seems to be where the dependency to other conan packages is declared:
```
set_property(TARGET vcsmm_DEPS_TARGET
             PROPERTY INTERFACE_LINK_LIBRARIES
             $<$<CONFIG:Debug>:${vcsmm_FRAMEWORKS_FOUND_DEBUG}>
             $<$<CONFIG:Debug>:${vcsmm_SYSTEM_LIBS_DEBUG}>
             $<$<CONFIG:Debug>:vcsbase>
             APPEND)
```

### After declaring components
Build output now only links against the _mm_ lib, there are no includes of any other dependencies anymore. The compilation fails with a missing header file:
```
x86_64-linux-gnu-g++ -isystem /home/fschoenm/.conan2/p/b/vcsmm6c0496d88f2b9/p/include -m64 -g -MD -MT CMakeFiles/vcsmm-test.dir/main.cpp.o -MF CMakeFiles/vcsmm-test.dir/main.cpp.o.d -o CMakeFiles/vcsmm-test.dir/main.cpp.o -c /home/fschoenm/devel/vcsmm/test_package/main.cpp
In file included from /home/fschoenm/devel/vcsmm/test_package/main.cpp:1:
/home/fschoenm/.conan2/p/b/vcsmm6c0496d88f2b9/p/include/vcsmm/base/Assert.h:8:10: fatal error: vcsbase/Assert.h: No such file or directory
    8 | #include <vcsbase/Assert.h>
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.
```
Target-debug.cmake when using components. It only defines dependencies to the components but the dependency to my other conan package(s) is missing:
```
set_property(TARGET vcsmm_DEPS_TARGET
             PROPERTY INTERFACE_LINK_LIBRARIES
             $<$<CONFIG:Debug>:${vcsmm_FRAMEWORKS_FOUND_DEBUG}>
             $<$<CONFIG:Debug>:${vcsmm_SYSTEM_LIBS_DEBUG}>
             $<$<CONFIG:Debug>:vcsmm::base;vcsmm::gpualgs>
             APPEND)
```
My `package_info()`:
```
    def package_info(self):
        self.cpp_info.components["base"].libs = ["vcsmm-base"]
        self.cpp_info.components["gpualgs"].libs = ["vcsmm-gpualgs"]
        self.cpp_info.components["gpualgs"].requires = ["base"]
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fschoenm
issue_14885: state: open
title: [question] Should dependencies with `visible=False` be visible in downstream lockfiles?
body: ### What is your question?

I'm creating a package that contains only an executable. Since it's a binary, I don't want it rebuilt every time downstream overrides some of its dependencies.

Therefore, I required the dependencies with `package_id_mode='unrelated_mode'` and `visible=False`.

However, when I then run `conan lock create --tool-requires mypackage/<version>`, the generated lockfile still contains all dependencies.

Is that supposed to happen or should the lockfile contain only `mypackage/<version>#hash`, without its dependencies, as they should not be visible?

I'm using conan 2.0.13.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: DoDoENT
issue_14875: state: open
title: [discussion] Xcode is a broken software, help make it become better
body: ### What is your suggestion?

I've been working on an iOS app that uses C++ dependencies via conan. I've been using `XcodeDeps` and `XcodeToolchain` generators to generate the `conan_config.xcconfig` and all other files it depends on.

My use case has 3 build types (Debug, RelWithDebInfo, Release), 2 SDKs (iphoneos, iphonesimulator), and 2 architectures for the simulator (x86_64 and arm64). In total, there are 9 `conan install` calls. The lockfile lists a bit over 40 packages, where some have components. This means that `XcodeDeps` generates almost 400 files with hundreds of variables, each and every one containing versions for iPhone vs. simulator, debug vs. release vs. rel_with_deb_info, arm64 vs. x86_64.

Finally, I created a single xcconfig file that includes all 9 generated `conan_deps.xcconfig` files and added that to my Xcode project.

The result: Xcode freezes. After restart, it no longer is able to load the project - it freezes every time. And if I try running `xcodebuild build` directly from the CLI, it first freezes for a minute or so and then crashes.

It appears that the sheer amount of variables is simply too much for xcode. I've tried with both Xcode 14.3 and Xcode 15 - both of them have the same behavior.

Then, I wrote a small python script that "flattens" all those files into a single xcconfig file that exposes just variables `SYSTEM_HEADER_SEARCH_PATHS, GCC_PREPROCESSOR_DEFINITIONS, OTHER_CFLAGS, OTHER_CPLUSPLUSFLAGS, FRAMEWORK_SEARCH_PATHS, LIBRARY_SEARCH_PATHS, OTHER_LDFLAGS` in all their combinations - similarly to what the `xcode` generator from Conan V1 did. And this works flawlessly.

Here is the script in case someone else stumbles upon the same problem:

```python
import argparse
import string
import os

all_variables = {}
visited = set()
non_inheritable_vars = set([
    'MACOSX_DEPLOYMENT_TARGET',
    'CLANG_CXX_LIBRARY',
])


def default_for_var(varname: str) -> str:
    if varname in non_inheritable_vars:
        return ''
    else:
        return '$(inherited)'


def extract_name(varname) -> str:
    lpos = 0
    for c in varname:
        if c == '_' or c in string.ascii_uppercase:
            lpos += 1
        else:
            break
    if varname[lpos-1] == '_':
        lpos -= 1
    return varname[:lpos]


def find_varname_end(line: str, bracket_pos: int) -> int:
    index = bracket_pos
    while True:
        close_bracket_pos = line.find(']', index)
        if line[close_bracket_pos + 1] == '[':
            index = close_bracket_pos + 1
        else:
            return close_bracket_pos


def process_assignment_line(line: str):
    bracket_pos = line.find('[')

    if line.startswith('PACKAGE_ROOT'):
        # ignore PACKAGE_ROOT, and thus minimize number of xcode variables, as it struggles when there are lots of them
        return

    # ignore aggregation variables
    if bracket_pos >= 0:
        varname = extract_name(line)
        varname_end = find_varname_end(line, bracket_pos)

        assignment_pos = line.find('=', varname_end)
        key = line[:assignment_pos]
        value = line[assignment_pos+1:].strip()
        # don't bother with processing when value is empty
        if value == '':
            return

        rname = key[bracket_pos:].strip()
        full_var_name = varname + rname
        old_val = all_variables.get(full_var_name, default_for_var(varname))
        all_variables[full_var_name] = (old_val + ' ' + value).strip()


def process_file(path: str):
    visited.add(path)
    basename = os.path.dirname(path)
    with open(path, 'rt', encoding='utf-8') as file:
        for line in file:
            if line.startswith('//'):  # comment
                continue
            if line.startswith('#include'):
                begin = line.find('"')
                end = line.find('"', begin+1)
                included_file = os.path.join(basename, line[begin + 1:end])
                if included_file not in visited and os.path.exists(included_file):
                    process_file(included_file)
            elif '=' in line:
                process_assignment_line(line)


def render(path: str):
    with open(path, 'wt', encoding='utf-8') as file:
        for key, value in all_variables.items():
            file.write(key)
            file.write(' = ')
            file.write(value)
            file.write('\n\n')


if __name__ == "__main__":
    parser = argparse.ArgumentParser()

    parser.add_argument(
        "src",
        action="store",
    )
    parser.add_argument(
        "dst",
        action="store",
    )

    parsed_args = parser.parse_args()

    process_file(parsed_args.src)
    render(parsed_args.dst)
```

Now, it could be possible to create yet another Xcode generator, akin to the one from Conan V1, that generates everything "flat" just like the output of my script, but I'm not sure this is a good step forward.

In general, Xcode should be fixed, but Apple does not care much about a non-Swift ecosystem with giant xcconfig files with hundreds of variables.

Has anyone else had a similar problem? What was your solution?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: DoDoENT
issue_14873: state: open
title: [feature] add switch to make export of same latest recipe revision a non-op
body: ### What is your suggestion?

Given an architecture where you keep your custom conan recipes all together in a repo, it can be convenient to write a wrapper script which exports all of them. In v1 this was ok as the revision would stay the same on multiple exports. However in v2 the lock file captures the timestamp of export as well, I assume because now you can have multiple revisions in the cache and you need to know which one is the latest. However in the special case where the latest revision is also the same as the revision you’re exporting, it would be good to have a switch which makes this a non-op. This way a subsequent lock would generate the same result. Maybe this should be the default?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: rconde01
issue_14870: state: open
title: [bug] Conan build missing deps always uses default profile
body: ### Environment details

* Operating System+version:  ubuntu 22.04
* Compiler+version:  Clang-14
* Conan version: Conan version 2.0.11
* Python version:   Python 3.10.13


### Steps to reproduce

When running 
```
conan install project_folder -of=project_folder/cmake-build-debug-clang/conan -pr project_folder/cmake-build-debug-clang/conan_host_profile -pr:b project_folder/cmake-build-debug-clang/conan_host_profile --build=missing -g CMakeDeps
```
or even when specifying the build profile to be explicitly the same as the host profile
```
conan install project_folder -of=project_folder/cmake-build-debug-clang/conan -pr project_folder/cmake-build-debug-clang/conan_host_profile -pr:b project_folder/cmake-build-debug-clang/conan_host_profile --build=missing -g CMakeDeps
``` 
conan will not build with the compiler specified in this profile. The profile specifies `clang-14`, but `fmt` is always attempted to be built with `GCC-11`, the default profile's compiler.

Am I missing sth else that I have to specify to be able to build the missing dependencies with the same profile as the host?

To be clear, I am sidestepping the `conan-clion-plugin` by entering the commands that fail manually. The above command is executed by the plugin - which does not specify the build profile - and fails with the same error of compiler incompatibility with compile options. I am using conan manually, instead of relying on the plugin, because the plugin refuses to read neither my `.zshenv` file in which I set `CONAN_USER_HOME` nor the same environment variable set in CLion (but this is besides the point right now).

### Logs

```
conan install /work/rleap1/michael.aichmueller/projects/hpl/Relational-Neural-Network -of=/work/rleap1/michael.aichmueller/projects/hpl/Relational-Neural-Network/cmake-build-debug-clang/conan -pr /work/rleap1/michael.aichmueller/projects/hpl/Relational-Neural-Network/cmake-build-debug-clang/conan_host_profile -pr:b /work/rleap1/michael.aichmueller/projects/hpl/Relational-Neural-Network/cmake-build-debug-clang/conan_host_profile --build=missing -g CMakeDeps

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=14
os=Linux
[conf]
tools.cmake.cmaketoolchain:generator=Ninja

Profile build:
[settings]
arch=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=14
os=Linux
[conf]
tools.cmake.cmaketoolchain:generator=Ninja


======== Computing dependency graph ========
Graph root
    conanfile.py: /work/rleap1/michael.aichmueller/projects/hpl/Relational-Neural-Network/conanfile.py
Requirements
    boost/1.80.0#71df56209b367a0a25d66a85bda50689 - Cache
    bzip2/1.0.8#411fc05e80d47a89045edc1ee6f23c1d - Cache
    fmt/10.1.1#cd63809a79574a2f9eb73ca35f16a243 - Cache
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c - Cache
    nlohmann_json/3.11.2#a35423bb6e1eb8f931423557e282c7ed - Cache
    tclap/1.2.5#45f82ed5226d2bd854214839e544ef46 - Cache
    zlib/1.2.13#97d5730b529b4224045fe7090592d4c1 - Cache
Build requirements
    b2/4.9.6#53783bdbbdbb6c13732b25f1f6ea6c58 - Cache

======== Computing necessary packages ========
fmt/10.1.1: Checking 9 compatible configurations:
fmt/10.1.1: 'e0eec628aef8fd4e2ae554dbb95c03846134612f': compiler.cppstd=11
fmt/10.1.1: '000733ea1afd532e0950d89a9080d3480afe13f1': compiler.cppstd=gnu11
fmt/10.1.1: '7c7d0ab2b83045e32d36b6034517f2ecb31891a5': compiler.cppstd=14
fmt/10.1.1: 'f66373932ad80b34e21936f59a364884e70843f4': compiler.cppstd=gnu14
fmt/10.1.1: 'b4e571ee38638b9afadae2cf8e18dcfbfeb786d3': compiler.cppstd=17
fmt/10.1.1: '9047148181437d538680424be70ec60e58beee2f': compiler.cppstd=20
fmt/10.1.1: '9ceedc57ca32e2f45586c20526c5282504f6dbeb': compiler.cppstd=gnu20
fmt/10.1.1: 'b21f0bee15b533a907c533d64a2f190146205e75': compiler.cppstd=23
fmt/10.1.1: '92a8db261110742d67959dbcc2fdf6fbf449fb92': compiler.cppstd=gnu23
boost/1.80.0: Checking 9 compatible configurations:
boost/1.80.0: 'ca2654985d8ba80893650edbfc386a19956d2e06': compiler.cppstd=11
boost/1.80.0: '5ca2f05f3952ad053df4ca2e7977bb85a121d127': compiler.cppstd=gnu11
boost/1.80.0: 'eb530e37659924285c2de8e0ea6f591e51d7e339': compiler.cppstd=14
boost/1.80.0: 'c51f19ed11d8f01d5182992e7b37060c6f5cce62': compiler.cppstd=gnu14
boost/1.80.0: '49f0d2c39c0cee4a063ea8f2cec1ad29a2dce370': compiler.cppstd=17
boost/1.80.0: 'a3ae5c46674ab1cb667559df5e7a984526e66e0f': compiler.cppstd=20
boost/1.80.0: 'ff03687c2183f1e45edb94593f0b3cdc76042571': compiler.cppstd=gnu20
boost/1.80.0: '8f5524a32a6152a1260e99b5592b57feb4ec3636': compiler.cppstd=23
boost/1.80.0: '403c37b318688ce3f0f854d5b1e9b65aef3c965a': compiler.cppstd=gnu23
Requirements
    boost/1.80.0#71df56209b367a0a25d66a85bda50689:c069dc5a01c8064c31fba0e5b019d308f1c2ec4c - Build
    bzip2/1.0.8#411fc05e80d47a89045edc1ee6f23c1d:c5ee68cf77f800ef6078811d56f303205347ce88#15ccfbbf4a2d7f8720c1f8f293e42f8c - Cache
    fmt/10.1.1#cd63809a79574a2f9eb73ca35f16a243:42d37e1d1ecc6266a68d398b5ad01a140fade1fd - Build
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c:046020b178d2d077cb7774244cccbd7c96ea989d - Build
    nlohmann_json/3.11.2#a35423bb6e1eb8f931423557e282c7ed:da39a3ee5e6b4b0d3255bfef95601890afd80709#2d1a5b1f5d673e1dab536bed20ce000b - Cache
    tclap/1.2.5#45f82ed5226d2bd854214839e544ef46:da39a3ee5e6b4b0d3255bfef95601890afd80709#102884fe2d857cd28e869ef15b2feeb2 - Cache
    zlib/1.2.13#97d5730b529b4224045fe7090592d4c1:046020b178d2d077cb7774244cccbd7c96ea989d - Build
Build requirements
    b2/4.9.6#53783bdbbdbb6c13732b25f1f6ea6c58:63fead0844576fc02943e16909f08fcdddd6f44b#07e7cfb1a52c516a8bc2ff6109366e4e - Cache

======== Installing packages ========
b2/4.9.6: Already installed! (1 of 8)
bzip2/1.0.8: Already installed! (2 of 8)

-------- Installing package fmt/10.1.1 (3 of 8) --------
fmt/10.1.1: Building from source
fmt/10.1.1: Package fmt/10.1.1:42d37e1d1ecc6266a68d398b5ad01a140fade1fd
fmt/10.1.1: Copying sources to build folder
fmt/10.1.1: Building your package in /u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/b
fmt/10.1.1: Calling generate()
fmt/10.1.1: Generators folder: /u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/b/build/Debug/generators
fmt/10.1.1: CMakeToolchain generated: conan_toolchain.cmake
fmt/10.1.1: CMakeToolchain generated: CMakePresets.json
fmt/10.1.1: CMakeToolchain generated: ../../../src/CMakeUserPresets.json
fmt/10.1.1: Generating aggregated env files
fmt/10.1.1: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
fmt/10.1.1: Calling build()
fmt/10.1.1: apply_conandata_patches(): No patches defined in conandata
fmt/10.1.1: Running CMake.configure()
fmt/10.1.1: RUN: cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="/u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/b/build/Debug/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/p" -DFMT_DOC="OFF" -DFMT_TEST="OFF" -DFMT_INSTALL="ON" -DFMT_LIB_DIR="lib" -DFMT_OS="ON" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Debug" "/u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/b/src"
-- CMake version: 3.22.1
-- Using Conan toolchain: /u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/b/build/Debug/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- Conan toolchain: C++ Standard 17 with extensions ON
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The CXX compiler identification is GNU 11.4.0     <----------------------- This should be clang and not GCC
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ - broken
CMake Error at /usr/share/cmake-3.22/Modules/CMakeTestCXXCompiler.cmake:62 (message):
  The C++ compiler

    "/usr/bin/c++"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/b/build/Debug/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/usr/bin/ninja cmTC_a4ca9 && [1/2] Building CXX object CMakeFiles/cmTC_a4ca9.dir/testCXXCompiler.cxx.o
    FAILED: CMakeFiles/cmTC_a4ca9.dir/testCXXCompiler.cxx.o 
    /usr/bin/c++   -m64 -stdlib=libstdc++  -fPIE -std=gnu++17 -o CMakeFiles/cmTC_a4ca9.dir/testCXXCompiler.cxx.o -c /u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/b/build/Debug/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
    c++: error: unrecognized command-line option ‘-stdlib=libstdc++’
    ninja: build stopped: subcommand failed.
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:137 (project)


-- Configuring incomplete, errors occurred!
See also "/u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/b/build/Debug/CMakeFiles/CMakeOutput.log".
See also "/u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/b/build/Debug/CMakeFiles/CMakeError.log".

fmt/10.1.1: ERROR: 
Package '42d37e1d1ecc6266a68d398b5ad01a140fade1fd' build failed
fmt/10.1.1: WARN: Build folder /u/michael.aichmueller/.conan2/p/b/fmta37c5b855079c/b/build/Debug
*********************************************************
Recipe 'fmt/10.1.1' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: fmt/10.1.1: Error in build() method, line 94
        cmake.configure()
        ConanException: Error 1 while executing
```
user: maichmueller
issue_14869: state: open
title: [feature] Would it be possible/make sense to centralize the calculation of the dependencies for the conan.tools XXXDeps generators?
body: ### What is your suggestion?

IMO, it seems that all the generators would have this kind of structure:

```python
class XXXXX:

    def __init__(self, conanfile):
        self._conanfile = conanfile
        # Activate the build XXXX files for the specified libraries
        self.build_context_activated = []
        # If specified, the files/requires/names for the build context will be renamed appending
        # a suffix. It is necessary in case of the same require and build_require and will cause an error
        self.build_context_suffix = {}

    def _validate_build_requires(self, host_req, build_req):
        """
        Check if any package exists at the host and build context at the same time, and
        it doesn't have any suffix to avoid any name collisions

        :param host_req: list of host requires
        :param build_req: list of build requires
        """
        activated_br = {r.ref.name for r in build_req.values()
                        if r.ref.name in self.build_context_activated}
        common_names = {r.ref.name for r in host_req.values()}.intersection(activated_br)
        without_suffixes = [common_name for common_name in common_names
                            if self.build_context_suffix.get(common_name) is None]
        if without_suffixes:
            raise ConanException(f"The packages {without_suffixes} exist both as 'require' and as"
                                 f" 'build require'. You need to specify a suffix using the "
                                 f"'build_context_suffix' attribute at the XXXXXXXX generator.")

    @property
    def content(self):
        # Get all the dependencies
        host_req = self._conanfile.dependencies.host
        build_req = self._conanfile.dependencies.build  # tool_requires
        test_req = self._conanfile.dependencies.test

        # Check if it exists both as require and as build require without a suffix
        self._validate_build_requires(host_req, build_req)

        for require, dep in list(host_req.items()) + list(build_req.items()) + list(test_req.items()):
            # Require is not used at the moment, but its information could be used,
            # and will be used in Conan 2.0
            # Filter the build_requires not activated with XXXXXXX.build_context_activated
            if require.build and dep.ref.name not in self.build_context_activated:
                continue
```

The question is whether all the generators should have the same logic for getting the dependencies. Even the use of `get_transitive_requires` too.


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: franramirez688
issue_14859: state: open
title: [bug] compatibility plugin ignores compatible binary when package ID depends on cmake generator
body: ### Environment details

* Operating System+version: macos
* Compiler+version: apple clang 14.0.3
* Conan version: 2.0.13
* Python version: 3.11


### Steps to reproduce

I've got a simple tool package that looks something like this:

```python
class CompressUtilityConan(ConanFile):
    name = "compress_utility"

    package_type = 'application'

    # ... actual building and packaging

    def package_id(self):
        if self.info.settings.os == 'Macos':
            cmake_generator = self.conf.get('tools.cmake.cmaketoolchain:generator', default='Xcode')
            if cmake_generator == 'Xcode':
                self.info.settings.arch = 'universal'

```

On MacOS, the package is built using `Xcode`, so it has `arch=universal`. Additionally, in my global compatibility plugin, I've got:

```python
def compatibility(conanfile):
    result = []
    os = conanfile.settings.get_safe('os')
    if os in ['Macos', 'iOS']:
        arch = conanfile.settings.get_safe('arch')
        if arch == 'armv8':
            result = [{"settings": [("arch", a)]} for a in ("armv8", "universal")]
        elif arch == 'x86_64':
            result = [{"settings": [("arch", a)]} for a in ("x86_64", "universal")]

    return result
```

Now, when I require this package without setting `tools.cmake.cmaketoolchain:generator` to `Xcode`, I get the following error:

```
$ conan install --requires compress_utility/1.0.1@microblink/main -pr:h ../profs/host

======== Input profiles ========
Profile host:
[settings]
arch=armv8
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=14.0.3
os=Macos
[tool_requires]
*: mb_foundation/1.0.0@microblink/main
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
tools.cmake.cmake_layout:build_folder_vars=['settings.os', 'settings.os.sdk', 'settings.arch', 'settings.compiler', 'settings.compiler.version', 'settings.compiler.sanitizers', 'settings.compiler.link_time_optimization']
tools.files.download:retry=25
tools.files.download:retry_wait=2

Profile build:
[settings]
arch=armv8
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=14.0.3
os=Macos
[tool_requires]
*: mb_foundation/1.0.0@microblink/main
[conf]
tools.cmake.cmake_layout:build_folder_vars=['settings.os', 'settings.os.sdk', 'settings.arch', 'settings.compiler', 'settings.compiler.version', 'settings.compiler.sanitizers', 'settings.compiler.link_time_optimization']
tools.files.download:retry=25
tools.files.download:retry_wait=2
tools.cmake.cmaketoolchain:generator=Xcode

(...) hash calculation omitted

======== Computing necessary packages ========

(...)

compress_utility/1.0.1@microblink/main: Compatible package ID 6eaa79c4269fde5020a8beda83d01d0fb1b6cd56 equal to the default package ID: Skipping it.
compress_utility/1.0.1@microblink/main: Checking 1 compatible configurations
compress_utility/1.0.1@microblink/main: Compatible configurations not found in cache, checking servers
compress_utility/1.0.1@microblink/main: '6ea4080a661dd09a28d10e70731ce53a2a727335': arch=universal
Requirements
    compress_utility/1.0.1@microblink/main#c92678d2d798491f5e0287af2ce43c1f:6eaa79c4269fde5020a8beda83d01d0fb1b6cd56 - Missing
Test requirements
Build requirements
    mb_foundation/1.0.0@microblink/main#35c07845b5016aa7915b8d7df86ae8b9:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache
Skipped binaries
    (lot's of internal packages not important for this issue)

======== Installing packages ========
ERROR: Missing binary: compress_utility/1.0.1@microblink/main:6eaa79c4269fde5020a8beda83d01d0fb1b6cd56

compress_utility/1.0.1@microblink/main: WARN: Can't find a 'compress_utility/1.0.1@microblink/main' package binary '6eaa79c4269fde5020a8beda83d01d0fb1b6cd56' for the configuration:
[settings]
arch=armv8
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=14.0.3
os=Macos
```

Now, I can explicitly rebuild `compress_utilty` for both armv8 and x86_64 for Mac, but why is this failing? All other packages have the same approach in package_id and they work normally. The only difference is that those other packages contain static libraries, while this one contains a prebuilt executable.

### Logs

_No response_
user: DoDoENT
issue_14854: state: open
title: [question] Dependency graph with components
body: ### What is your question?

I have a question regarding components and indirect dependencies. Say I have a `lib` package with a small and large library (respectively `lib::small` and `lib::large` components).

The `lib::large` component is actually depending on `boost` to provide higher-level utilities than the `lib::small` component that does not depend on anything.

Now, consumers of my `lib` package might only want to consume `lib::small` and not care about `lib::large`. If I understand correctly, by defining the component requirements in the `package_info()` method the large component will not be linked if using CMake for example, and that's good.

However, I'm also interested in letting consumers of my package free of downloading boost if they do not use `lib::large`. As far as I understand this is not possible and boost is always in the dependency graph of the consumer packages. Below is the ideal dependency graph for the situation with an `exe` consuming only `lib::small`.

``` mermaid 
graph TD
    exe --> lib::small
    lib::large --> lib::small
    lib::large --> boost
    subgraph LibPackage
       lib::small
       lib::large 
    end
    subgraph ExePackage
       exe
    end
```

To be more precise on what I would expect, here is what I tried:
``` python
# Recipe for lib, with a 'small' and 'large' components
def package_info(self):
    self.cpp_info.components["small"].libs = ["small_lib"]
    self.cpp_info.components["large"].libs = ["large_lib"]
    self.cpp_info.components["small"].requires = []
    self.cpp_info.components["large"].requires = ["small", "boost::boost"]

# Recipe for exe, trying to depend only on the small component and not depend on boost
def package_info(self):
    self.cpp_info.requires = ["lib::small"]
```

I'm aware that in all cases the 'lib' package must be fetched as a whole including the `lib::large` component library, I would simply like indirect dependencies to be removed from the graph if no dependency to `lib::large` is declared in the consumer recipe (and if a dependency to `lib::small` is explicitly declared).

The use case is mainly, in a large code base, to avoid having too many packages and still allowing the dependency graph to be reasonable with this additional granularity provided by conan's components.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: docbrown1955
issue_14847: state: open
title: [question] How to handle configuration files for dependencies?
body: ### What is your question?

Hi,

I'm currently struggling (at least in my mind) how I can solve the following situation in a good Conan-like way:

- I'm having a dependency that requires configuration headers and other files that need to be provided by the consumer
- The dependency is provided as Conan package (of course without binary packages in that case)
- My "main" conanfile defines this dependency in the usual way, however how to hand over the configuration file?

![image](https://github.com/conan-io/conan/assets/32196505/066f5521-e4b0-4a62-b465-c075961055a7)

I first thought that the configuration file shall be provided as separate Conan package, but these configuration files are so highly coupled to the "main" component that I want to have them in a single Git repository and maintain them together. My "main" component would then need to publish the latest version of this Conan configuration-only package during the dependency resolution step which is a bit too much and too complicated from my point of view. The other way would be to provide the dependant files as kind of option for the dependency, e.g. a folder option or something like that. But this way doesn't look Conan-like for me.

Is there any approach or solution that I missed to know?

As a side-node I have not only one of these dependencies, but many of them :-(. And due to complexity it is impossible to create binary packages for all possible configurations - there would be thousands of possibilities to generate.

Many thanks for your help.

Best regards,
gpxricky

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: gpxricky
issue_14844: state: open
title: [question] Unable to consume shared libraries in CI
body: ### What is your question?

I had an issue trying to consume at runtime a shared library installed with conan.
I did this reproductive and smaller repository: https://github.com/VincentRouvreau/play_with_conan
It works fine on my linux machine, and on a Windows machine that I have when I (almost) follow [consuming packages tutorial ](https://github.com/conan-io/examples2/tree/main/tutorial/consuming_packages/different_configurations)

But on [my CI](https://github.com/VincentRouvreau/play_with_conan/actions/runs/6339744493/job/17219548284) you can see that it fails. The error seems to be a link error with the boost shared library.

The build works fine, but the run fails, and I have no real clue on how I could debug this.

And by the way, thanks for the great work !

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: VincentRouvreau
issue_14843: state: open
title: [question] linked in shared libraries do not hide its dependencies
body: ### What is your question?

I am trying to link a shared library with another build type into a consumer.
In short: this works fine if the shared library has no dependencies.
However, if the shared library has dependencies (staticly linked in), it only works by always taken into account these dependencies.

I took one of the examples from the conan center with hello and hello-say.
I duplicated hello-say to hello-say2 and made hello-say dependent on hello-say2:

say conanfile is now:
```
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMake, cmake_layout


class SayConan(ConanFile):
    name = "say"
    version = "0.1"

    # Optional metadata
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of Say here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}

    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "CMakeLists.txt", "src/*", "include/*"

    def requirements(self):
        self.requires("say_2/0.1")

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()

    def package_info(self):
        self.cpp_info.libs = ["say"]
```

conanfile for say_2:
```
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMake, cmake_layout


class SayConan(ConanFile):
    name = "say_2"
    version = "0.1"

    # Optional metadata
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of Say here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}

    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "CMakeLists.txt", "src/*", "include/*"

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()

    def package_info(self):
        self.cpp_info.libs = ["say2"]
```

say is created as a shared library
say_2 is created as a static library which is embedded into say.
hello takes say as a shared library

```
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMake, cmake_layout, CMakeDeps


class HelloConan(ConanFile):
    name = "hello"
    version = "0.1"

    # Optional metadata
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of Say here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    default_options = {"say/*:shared": True}

    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "CMakeLists.txt", "src/*", "include/*"

    def requirements(self):
        self.requires("say/0.1")

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()
        deps = CMakeDeps(self)
        deps.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()
```

I created now all packages.

Now the behaviour I would expect since say_2 is hidden for hello and should not be needed.
If I delete say_2 package from my cache I get the following error when building hello:

```
conan create conanfile.py -pr:h vs2022_x64_profile_debug -pr:b vs2022_x64_profile -s "&:build_type=Debug" -s "&:compiler.runtime_type=Debug" -s build_type=Release -s compiler.runtime_type=Release

======== Exporting recipe to the cache ========
hello/0.1: Exporting package recipe: D:\dev\conan\examples2\features\editable\cmake\hello\conanfile.py
hello/0.1: Copied 1 '.py' file: conanfile.py
hello/0.1: Copied 1 '.txt' file: CMakeLists.txt
hello/0.1: Copied 1 '.cpp' file: hello.cpp
hello/0.1: Exported to cache folder: D:\I\.conan2\p\hello9f76b36503c8c\e
hello/0.1: Exported: hello/0.1#dfa794329ef4570aa9af41efe25bab86 (2023-09-28 12:17:30 UTC)

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=20
compiler.runtime=static
compiler.runtime_type=Release
compiler.version=193
os=Windows
&:build_type=Debug
&:compiler.runtime_type=Debug
[conf]
tools.files.download:retry=5
tools.files.download:retry_wait=5
tools.cmake.cmaketoolchain:generator=Ninja
[buildenv]
CTEST_OUTPUT_ON_FAILURE=1

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=20
compiler.runtime=static
compiler.runtime_type=Release
compiler.version=193
os=Windows
[conf]
tools.files.download:retry=5
tools.files.download:retry_wait=5
tools.cmake.cmaketoolchain:generator=Ninja
[buildenv]
CTEST_OUTPUT_ON_FAILURE=1


======== Computing dependency graph ========
Graph root
    cli
Requirements
    hello/0.1#dfa794329ef4570aa9af41efe25bab86 - Cache
    say/0.1#2b36c03bf3a15383599f90fc834de257 - Cache
    say_2/0.1#b912806546969aff17d1377ff3374660 - Cache

======== Computing necessary packages ========
hello/0.1: Forced build from source
Requirements
    hello/0.1#dfa794329ef4570aa9af41efe25bab86:d54a1f48e72e6af08f13625a27c0a1d869b7e326 - Build
    say/0.1#2b36c03bf3a15383599f90fc834de257:731d5f987d436709c05f50a3589e1be25b51955d#a0ffb5c2d2be74c9b397056959f00927 - Cache
Skipped binaries
    say_2/0.1

======== Installing packages ========
say/0.1: Already installed! (1 of 2)

-------- Installing package hello/0.1 (2 of 2) --------
hello/0.1: Building from source
hello/0.1: Package hello/0.1:d54a1f48e72e6af08f13625a27c0a1d869b7e326
hello/0.1: Copying sources to build folder
hello/0.1: Building your package in D:\I\.conan2\p\b\hello35c6a61b072b4\b
hello/0.1: Calling generate()
hello/0.1: Generators folder: D:\I\.conan2\p\b\hello35c6a61b072b4\b\build\Debug\generators
hello/0.1: CMakeToolchain generated: conan_toolchain.cmake
hello/0.1: CMakeToolchain generated: CMakePresets.json
hello/0.1: CMakeToolchain generated: ..\..\..\CMakeUserPresets.json
hello/0.1: Generating aggregated env files
hello/0.1: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
hello/0.1: Calling build()
hello/0.1: Running CMake.configure()
hello/0.1: RUN: cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="D:/I/.conan2/p/b/hello35c6a61b072b4/b/build/Debug/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="D:/I/.conan2/p/b/hello35c6a61b072b4/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Debug" "D:\I\.conan2\p\b\hello35c6a61b072b4\b"
conanvcvars.bat: Activating environment Visual Studio 17 - amd64 - vcvars_ver=14.3
[vcvarsall.bat] Environment initialized for: 'x64'
-- Using Conan toolchain: D:/I/.conan2/p/b/hello35c6a61b072b4/b/build/Debug/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 20 with extensions OFF
-- The C compiler identification is MSVC 19.34.31944.0
-- The CXX compiler identification is MSVC 19.34.31944.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: Target declared 'say::say'
-- Configuring done (3.5s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_POLICY_DEFAULT_CMP0091


-- Build files have been written to: D:/I/.conan2/p/b/hello35c6a61b072b4/b/build/Debug

hello/0.1: Running CMake.build()
hello/0.1: RUN: cmake --build "D:\I\.conan2\p\b\hello35c6a61b072b4\b\build\Debug" -- -j12
conanvcvars.bat: Activating environment Visual Studio 17 - amd64 - vcvars_ver=14.3
[vcvarsall.bat] Environment initialized for: 'x64'
[2/2] Linking CXX executable hello.exe

hello/0.1: Package 'd54a1f48e72e6af08f13625a27c0a1d869b7e326' built
hello/0.1: Build folder D:\I\.conan2\p\b\hello35c6a61b072b4\b\build\Debug
hello/0.1: Generating the package
hello/0.1: Packaging in folder D:\I\.conan2\p\b\hello35c6a61b072b4\p
hello/0.1: Calling package()
hello/0.1: Running CMake.install()
hello/0.1: RUN: cmake --install "D:\I\.conan2\p\b\hello35c6a61b072b4\b\build\Debug" --prefix "D:/I/.conan2/p/b/hello35c6a61b072b4/p"
conanvcvars.bat: Activating environment Visual Studio 17 - amd64 - vcvars_ver=14.3
[vcvarsall.bat] Environment initialized for: 'x64'
-- Install configuration: "Debug"

hello/0.1: package(): WARN: No files in this package!
hello/0.1: Created package revision 3a4f9ea965d66396f26d42494b9e49c3
hello/0.1: Package 'd54a1f48e72e6af08f13625a27c0a1d869b7e326' created
hello/0.1: Full package reference: hello/0.1#dfa794329ef4570aa9af41efe25bab86:d54a1f48e72e6af08f13625a27c0a1d869b7e326#3a4f9ea965d66396f26d42494b9e49c3
hello/0.1: Package folder D:\I\.conan2\p\b\hello35c6a61b072b4\p
320141492@NLYBSTQVP4NB8XU /d/dev/conan/examples2/features/editable/cmake/hello (master)
λ  /d/venv2/Scripts/conan remove "say_2"
Remove the recipe and all the packages of 'say_2/0.1#b912806546969aff17d1377ff3374660'? (yes/no): y
Remove summary:
Local Cache
  say_2/0.1#b912806546969aff17d1377ff3374660: Removed recipe and all binaries
320141492@NLYBSTQVP4NB8XU /d/dev/conan/examples2/features/editable/cmake/hello (master)
λ  /d/venv2/Scripts/conan create conanfile.py -pr:h vs2022_x64_profile_debug -pr:b vs2022_x64_profile -s "&:build_type=Debug" -s "&:compiler.runtime_type=Debug" -s build_type=Release -s compiler.runtime_type=Release

======== Exporting recipe to the cache ========
hello/0.1: Exporting package recipe: D:\dev\conan\examples2\features\editable\cmake\hello\conanfile.py
hello/0.1: Copied 1 '.py' file: conanfile.py
hello/0.1: Copied 1 '.txt' file: CMakeLists.txt
hello/0.1: Copied 1 '.cpp' file: hello.cpp
hello/0.1: Exported to cache folder: D:\I\.conan2\p\hello9f76b36503c8c\e
hello/0.1: Exported: hello/0.1#dfa794329ef4570aa9af41efe25bab86 (2023-09-28 12:19:27 UTC)

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=20
compiler.runtime=static
compiler.runtime_type=Release
compiler.version=193
os=Windows
&:build_type=Debug
&:compiler.runtime_type=Debug
[conf]
tools.files.download:retry=5
tools.files.download:retry_wait=5
tools.cmake.cmaketoolchain:generator=Ninja
[buildenv]
CTEST_OUTPUT_ON_FAILURE=1

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=20
compiler.runtime=static
compiler.runtime_type=Release
compiler.version=193
os=Windows
[conf]
tools.files.download:retry=5
tools.files.download:retry_wait=5
tools.cmake.cmaketoolchain:generator=Ninja
[buildenv]
CTEST_OUTPUT_ON_FAILURE=1


======== Computing dependency graph ========
say_2/0.1: Not found in local cache, looking in remotes...
say_2/0.1: Checking remote: innersource-local
say_2/0.1: Checking remote: innersource
say_2/0.1: Checking remote: appengine
Graph root
    cli
Requirements
    hello/0.1#dfa794329ef4570aa9af41efe25bab86 - Cache
    say/0.1#2b36c03bf3a15383599f90fc834de257 - Cache
ERROR: Package 'say_2/0.1' not resolved: Unable to find 'say_2/0.1' in remotes.
```
I think we at least need the package recipe in the cache?

If I want to use say to be Release and my package to be debug (with still say_2 in the cache):

This works:
```
conan create conanfile.py -pr:h vs2022_x64_profile_debug -pr:b vs2022_x64_profile -s "&:build_type=Debug" -s "&:compiler.runtime_type=Debug" -s build_type=Release -s compiler.runtime_type=Release
```
This is however inconvenient because on windows, if I have static dependencies and dynamic dependencies, I have no option to easily say that all my direct static dependencies need to be Debug.

This works:
```
conan create conanfile.py -pr:h vs2022_x64_profile_debug -pr:b vs2022_x64_profile -s say/0.1:build_type=Release -s say/0.1:compiler.runtime_type=Release -s say_2/0.1:build_type=Release -s say_2/0.1:compiler.runtime_type=Release
```
This is however also inconvenient because now I need to specify all the dependencies of my shared library (which I hoped to be hidden) on the command line. 


This fails:
```
conan create conanfile.py -pr:h vs2022_x64_profile_debug -pr:b vs2022_x64_profile -s say/0.1:build_type=Release -s say/0.1:compiler.runtime_type=Release 
```
This is actually what I wanted:
* say needs to be in Release because it takes to much time to run.
* its dependencies are hidden for the consumer.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: edwardvandevorst-philips
issue_14838: state: open
title: [question] Conan 2 rejects upload due to manifest mismatch due to __pycache__
body: ### What is your question?

Hi! I am currently migrating towards Conan 2.x and saw an unexpected behavior while trying to build and upload the package [`meson` from the `conan-center-index`](https://github.com/conan-io/conan-center-index/tree/master/recipes/meson/all) with only one adaptation from my side, using a different version of `ninja`.
I am using the Conan version 2.0.12 in a Python environment of version 3.10.13.

From the previous behavior of Conan 1.x and after reading the issues #7789 #4961 and #5404 I was under the impression that Conan deliberately ignores cache files (which makes sense in my opinion).
However, for Conan 2 it complains during the upload about a manifest mismatch and lists then all files residing in a `__pycache__`, which are created during the execution of the `test_package`.

I am using the following commands
```
conan create <path_to_conanfile> --user me --channel testing --format json
conan upload <ref:package_id#prev> --check --confirm --remote <my_remote>
```

My question is: Is this behavior for Conan 2.x expected, e.g. by a different default workflow (e.g. not executing the `test_package` before an upload - which would feel wrong to me)? Or is this some kind of degradation compared to the behavior of Conan 1.x?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: marlamb
issue_14832: state: open
title: [question] How to resolve a collision between fixed dependency and a that is determined with a range?
body: ### What is your question?

The selection of versions when there is an accepted range generates a severe problem. For example, in the case of the compilation of the [Pango package](https://github.com/conan-io/conan-center-index/pull/17655), this package has a dependency on the libpng package that supports a range of versions of the [zlib dependency](https://github.com/conan-io/conan-center-index/blob/24e52e90d904d7fc4eec7e4633b68694c5fcde47/recipes/libpng/all/conanfile.py#L95) and selects typically the last one, which does not match the one They have neither glib nor Cairo. It does not allow the compilation to continue.

How do we solve this error by setting the version of the libpng package to a concrete version, setting the range in all libraries, and adjusting everything to the same version?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: mjimenofluendo
issue_14831: state: open
title: [bug] ERROR: Object of type _PackageOption is not JSON serializable
body: ### Environment details

* Conan version: 2.0.12 (also happens with 2.0.11 and 2.0.10, as far as I tested)
* Python version: 3.11




### Steps to reproduce

Executing `conan install --requires my_package/version@company/channel --build missing --format=json` fails with the following stack trace:

```
ERROR: Traceback (most recent call last):
  File "/Users/dodo/Desktop/conan2-venv/lib/python3.11/site-packages/conan/cli/cli.py", line 272, in main
    cli.run(args)
  File "/Users/dodo/Desktop/conan2-venv/lib/python3.11/site-packages/conan/cli/cli.py", line 172, in run
    command.run(self._conan_api, args[0][1:])
  File "/Users/dodo/Desktop/conan2-venv/lib/python3.11/site-packages/conan/cli/command.py", line 128, in run
    self._format(parser, info, *args)
  File "/Users/dodo/Desktop/conan2-venv/lib/python3.11/site-packages/conan/cli/command.py", line 94, in _format
    formatter(info)
  File "/Users/dodo/Desktop/conan2-venv/lib/python3.11/site-packages/conan/cli/formatters/graph/graph.py", line 143, in format_graph_json
    json_result = json.dumps({"graph": serial}, indent=4)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/python@3.11/3.11.5/Frameworks/Python.framework/Versions/3.11/lib/python3.11/json/__init__.py", line 238, in dumps
    **kw).encode(obj)
          ^^^^^^^^^^^
  File "/opt/homebrew/Cellar/python@3.11/3.11.5/Frameworks/Python.framework/Versions/3.11/lib/python3.11/json/encoder.py", line 202, in encode
    chunks = list(chunks)
             ^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/python@3.11/3.11.5/Frameworks/Python.framework/Versions/3.11/lib/python3.11/json/encoder.py", line 432, in _iterencode
    yield from _iterencode_dict(o, _current_indent_level)
  File "/opt/homebrew/Cellar/python@3.11/3.11.5/Frameworks/Python.framework/Versions/3.11/lib/python3.11/json/encoder.py", line 406, in _iterencode_dict
    yield from chunks
  File "/opt/homebrew/Cellar/python@3.11/3.11.5/Frameworks/Python.framework/Versions/3.11/lib/python3.11/json/encoder.py", line 406, in _iterencode_dict
    yield from chunks
  File "/opt/homebrew/Cellar/python@3.11/3.11.5/Frameworks/Python.framework/Versions/3.11/lib/python3.11/json/encoder.py", line 406, in _iterencode_dict
    yield from chunks
  [Previous line repeated 3 more times]
  File "/opt/homebrew/Cellar/python@3.11/3.11.5/Frameworks/Python.framework/Versions/3.11/lib/python3.11/json/encoder.py", line 439, in _iterencode
    o = _default(o)
        ^^^^^^^^^^^
  File "/opt/homebrew/Cellar/python@3.11/3.11.5/Frameworks/Python.framework/Versions/3.11/lib/python3.11/json/encoder.py", line 180, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type _PackageOption is not JSON serializable

ERROR: Object of type _PackageOption is not JSON serializable
```

It didn't happen before with other packages. I'm still trying to figure out what is specific to this package. However, I hope the stack trace can help finding and fixing the issue.

### Logs

_No response_
user: DoDoENT
issue_14829: state: open
title: [question] `self.dependencies[...].package_folder` in package_info()
body: ### What is your question?

[The docs](https://docs.conan.io/2/reference/conanfile/methods/generate.html#dependencies-interface) wanted me to open an issue :) 

I'm packaging clang for (cross-)compiling for Windows. I have always been using this package as a `tool_requires` inside the host profile.

Now, to make this work universally, I have added a sysroot package for Visual Studio which contains the MSVCRT, WinSDK, DIA SDK. Outside of conan, this setup is well-tested and working for cross-compiling from Linux or compiling from windows without a specific VS version installed.

I'm handling this as follows:
```
def requirements(self):
        if self.settings.os == "Windows":
            self.requires(self._VISUALSTUDIO_SYSROOT_REFERENCE, build=False)
```
this makes sense since the host profile is Windows and these are all libraries needed by that.

Here comes the problem:
```python
def package_info():
          # This is used for setting the profile info automatically by the package
          [...]
            vs_sysroot = Path(self.dependencies[self._VISUALSTUDIO_SYSROOT_REFERENCE].package_folder)
            cflags = [
                "/permissive-",  # No microsoftisms
                "/Zc:preprocessor",  # Use the standard conforming preprocessor
                "/volatile:iso",  # Use the standard conforming volatile behaviour
                "-fuse-ld=lld",  # this is implicitly lld-link if the frontend is clang-cl
                f'/winsdkdir {vs_sysroot.joinpath("sdk").resolve().as_posix()}'
                f'/vctoolsdir {vs_sysroot.joinpath("crt").resolve().as_posix()}',
            ]
            self.conf_info.define("tools.build:cflags", cflags)
            self.conf_info.define("tools.build:cxxflags", cflags)
```
the first line breaks[1] since `package_folder` is `None` _when this clang package is used as tool_requires_.

If I understand the issue correctly, a workaround could be to have these flags be set by the sysroot package itself.
I think there was a similar issue about this already but I can't find it.

1: this is the case when using a test_package that has clang in its tool_requires. I'd need that to ensure the packaged clang works. I'll also try from a profile.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sykhro
issue_14821: state: open
title: [question] How should 'conan upload xyz' behave
body: ### What is your question?

We came across the following scenario.
(conan 2.0.11 / artifactory 7.68.11)

1. we upload a **correctly working** recipe to artifactory
2. we upload an incorrect recipe with _the identical version number_ to artifactory
3. after we found the issue, we revert the changes and try to upload the older recipe again with _the identical version number_
4. the upload was skipped by conan with `already in server, skipping upload`
5. but all consumer still get the defective recipe when we try to install the package with the option `--update`

We would expect that it is possible to overwrite the "last" recipe, or that the upload skip check only considers the last recipe version.
 

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: NoWiseMan
issue_14820: state: open
title: [bug] Error copying sources to build folder
body: ### Environment details

* Operating System+version: Ubuntu 22.04
* Compiler+version: GCC-11
* Conan version: 1.60.2
* Python version:  Python 3.11.4  (also Python 3.9.18)

When installing packages conan is unable to unpack sources into a build folder, crashing in the process. However, Conan succeeds installing when it can download pre-binaries. I unfortunately cannot use pre-built binaries with every compiler I am using (e.g. for clang it needs to build some packages)
This problem does not occur on my private desktop machine, so I am rather certain it has to do with the fact that the home directory (where conan is meant to install into) is a mounted network drive at work (the drive has more than 20GB of storage left, so it's not a storage limit issue). Any tips on what might trigger this?



### Steps to reproduce

1. Install conan in a conda env
2. Use the conanfile.txt:
```
 [requires]
gtest/1.13.0
pybind11/2.10.4
range-v3/0.12.0
fmt/10.1.1
xtensor/0.24.3
openblas/0.3.20
spdlog/1.12.0
frozen/1.1.1

[generators]
cmake
cmake_find_package
cmake_paths

[layout]
cmake_layout
```
3. Run `conan install conanfile.txt -pr=default -pr:b=default -s build_type=Release -s compiler=gcc -s compiler.version=11 -s compiler.libcxx=libstdc++11 -g=cmake --build`
4. Watch it fail :(
5. Run instead `conan install conanfile.txt -pr=default -pr:b=default -s build_type=Release -s compiler=gcc -s compiler.version=11 -s compiler.libcxx=libstdc++11 -g=cmake --build=missing`
6. Conan succeeds

### Logs

```
/work/rleap1/michael.aichmueller/miniconda/bin/conan install /u/michael.aichmueller/GitProjects/reinforce/deps/conanfile.txt -pr=default -pr:b=default -s build_type=Release -s compiler=gcc -s compiler.version=11 -s compiler.libcxx=libstdc++11 -g=cmake --build

Configuration (profile_host):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=11
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

fmt/10.1.1: Forced build from source
frozen/1.1.1: Forced build from source
gtest/1.13.0: Forced build from source
nlohmann_json/3.11.2: Forced build from source
openblas/0.3.20: Forced build from source
pybind11/2.10.4: Forced build from source
range-v3/0.12.0: Forced build from source
xsimd/11.1.0: Forced build from source
xtl/0.7.5: Forced build from source
spdlog/1.12.0: Forced build from source
xtensor/0.24.3: Forced build from source
conanfile.txt: Installing package
Requirements
    fmt/10.1.1 from 'conancenter' - Cache
    frozen/1.1.1 from 'conancenter' - Cache
    gtest/1.13.0 from 'conancenter' - Cache
    nlohmann_json/3.11.2 from 'conancenter' - Cache
    openblas/0.3.20 from 'conancenter' - Cache
    pybind11/2.10.4 from 'conancenter' - Cache
    range-v3/0.12.0 from 'conancenter' - Cache
    spdlog/1.12.0 from 'conancenter' - Cache
    xsimd/11.1.0 from 'conancenter' - Cache
    xtensor/0.24.3 from 'conancenter' - Cache
    xtl/0.7.5 from 'conancenter' - Cache
Packages
    fmt/10.1.1:2c09c8f84c016041549fcee94e4caae5d89424b6 - Build
    frozen/1.1.1:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Build
    gtest/1.13.0:4fefe176018d6564b5e2144163a209c027be31c5 - Build
    nlohmann_json/3.11.2:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Build
    openblas/0.3.20:1611de3a5677d1d94d77e7279247aa09f53735bb - Build
    pybind11/2.10.4:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Build
    range-v3/0.12.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Build
    spdlog/1.12.0:44fdd9f52bc6b25f679e19e16c208cd5449ebaf9 - Build
    xsimd/11.1.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Build
    xtensor/0.24.3:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Build
    xtl/0.7.5:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Build

Installing (downloading, building) binaries...
fmt/10.1.1: Copying sources to build folder
ERROR: [('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/std.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/std.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/std.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/core.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/core.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/core.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/ostream.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/ostream.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/ostream.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/format.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/format.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/format.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/format-inl.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/format-inl.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/format-inl.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/os.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/os.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/os.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/chrono.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/chrono.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/chrono.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/ranges.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/ranges.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/ranges.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/args.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/args.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/args.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/printf.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/printf.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/printf.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/color.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/color.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/color.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/compile.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/compile.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/compile.h'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/include/fmt/xchar.h', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/xchar.h', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt/xchar.h'"), (<DirEntry 'fmt'>, '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/include/fmt', (LOADS OF THE SAME, COMMENT LIMIT REACHED.........) "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd/conf.py'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/support/rtd/theme/layout.html', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd/theme/layout.html', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd/theme/layout.html'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/support/rtd/theme/theme.conf', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd/theme/theme.conf', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd/theme/theme.conf'"), (<DirEntry 'theme'>, '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd/theme', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd/theme'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/support/rtd/index.rst', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd/index.rst', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd/index.rst'"), (<DirEntry 'rtd'>, '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/rtd'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/support/manage.py', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/manage.py', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/manage.py'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/support/Android.mk', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/Android.mk', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/Android.mk'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/support/Vagrantfile', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/Vagrantfile', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/Vagrantfile'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/support/printable.py', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/printable.py', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support/printable.py'"), (<DirEntry 'support'>, '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/support'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/LICENSE.rst', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/LICENSE.rst', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/LICENSE.rst'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/src/format.cc', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/src/format.cc', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/src/format.cc'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/src/fmt.cc', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/src/fmt.cc', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/src/fmt.cc'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/src/os.cc', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/src/os.cc', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/src/os.cc'"), (<DirEntry 'src'>, '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/src', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/src'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source/src/ChangeLog.rst', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/ChangeLog.rst', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src/ChangeLog.rst'"), (<DirEntry 'src'>, '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6/src'"), ('/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/source', '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6', "[Errno 5] Input/output error: '/u/michael.aichmueller/.conan/data/fmt/10.1.1/_/_/build/2c09c8f84c016041549fcee94e4caae5d89424b6'")]
Error copying sources to build folder
```
user: maichmueller
issue_14809: state: open
title: [question] self.cpp_info.defines does not affect package ID of the consumer - how to enforce that?
body: ### What is your question?

Create the following chain of packages:

```python
class First(ConanFile):
    name = 'first'
    version = '1.0'

    options = {
        'option': ['One', 'Two', 'Three'],
    }

    default_options = {
        'option': 'One',
    }

    def generate(self):
        tc = CMakeToolchain(self)
        tc.cache_variables = {
            'SOME_CMAKE_OPTION': self.options.option,
        }
        tc.generate()

       # also make sure CMake propagates SOME_CMAKE_OPTION to MY_DEFINE as shown in the package_info below

    def package_info(self):
        self.cpp_info.libs = ["first"]

        self.cpp_info.defines = [
            'MY_DEFINE_One=1',
            'MY_DEFINE_Two=2',
            'MY_DEFINE_Three=3',
            f'MY_DEFINE=MY_DEFINE_{self.options.option}',
        ]
```

Also, add a simple header that defines function that simply prints the integer value of `MY_DEFINE`.

Now, create packages `Second` and `Third` like this:

```python
from conan import ConanFile


class Second(ConanFile):
    name = 'second'
    version = '1.0'

    def requirements(self):
        self.requires('first/1.0', transitive_headers=True)

    def package_info(self):
        self.cpp_info.libs = ["second"]
```

```python
from conan import ConanFile


class Third(ConanFile):
    name = 'third'
    version = '1.0'

    def requirements(self):
        self.requires('second/1.0', transitive_headers=True)

    def package_info(self):
        self.cpp_info.libs = ["third"]
```

In both `Second` and `Third` create functions that will print the value of `MY_DEFINE`

Finally, create the consumer package `App`:

```python
from conan import ConanFile


class App(ConanFile):
    requires = 'third/1.0'
```

And let it call printing functions from both `first`, `second`, and `third`.

Create all packages and install the app dependencies and run the exe. `1` should be printed 3 times.

Now, go to folder of the `app`, and run `conan install . -o first/*:option=Two --build missing`.

This now builds only a new flavor of `first`, but not the `second` and `third`, causing a bug. Running the app now will print `2 1 1`, yet `2 2 2` is expected, as well as rebuilding of both `second` and `third` packages.

Namely, since `second` depends on `first`, and `first` defines custom define flags in its `self.cpp_info.defines`, it impacts the produced binary of the `second`. Thus, the changed option of `first` should also change the package ID of the `second`, as it's `defines` is "just like" the public header, i.e. it impacts the binary of the `second`. Furthermore, since `first` is `transitive_headers` dependency of the `second`, this should also be propagated to `third` and thus `third` rebuilt.

Is there a way for `first` to communicate downstream that its `self.cpp_info.defines` should be used in package ID calculation? Is there a way for a package to enforce a package ID change of all downstream packages whenever its option is changed?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: DoDoENT
issue_14806: state: open
title: [question] How to handle dependencies on Python modules in Conan packages?
body: ### What is your question?

Suppose there is a C++ lib `X` that requires some Python module `Y` to be built. The simplest use case is that it uses `Y` for code generation or transformation, by running some Python script during CMake config or build. How should one approach providing / specifying such dependency in a recipe for `X`?

(_[Here](https://github.com/ros2/rcutils/blob/rolling/CMakeLists.txt#L95-L114) is the example from the library we are currently trying to package - it runs `python -c "import em ; em.invoke(...)"` during CMake configuration to do some codegen and requires package `empy` to be installed for that_)

Conan has some automation to work with system package managers like `apt` or `pacman` - which is nice because one can control their behavior, as to whether or not it should actually install something (even using `sudo`), or just notify of missing packages and fail. Is there anything like that for `pip` with similar configuration possibilities? If not, what would be the preferred method to install the package "unconditionally"?

There is [this SO answer](https://stackoverflow.com/a/54574007/5232529) by @uilianries from 2019, which suggests to just `import pip ; pip.main(['install', 'Y'])` - which feels slightly unsafe and is probably outdated by now. Even if it is not, I believe the proper way would be to `subprocess.check_call([sys.executable, '-m', 'pip', 'install', 'Y'])`, as the `pip.main` approach generates warnings from Python:
```
[2023-09-22T08:45:09.348Z] WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.
[2023-09-22T08:45:09.348Z] Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.
[2023-09-22T08:45:09.348Z] To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.
[2023-09-22T08:45:09.348Z] Defaulting to user installation because normal site-packages is not writeable
```

Additionaly one might as well want to separate "build-time module dependency" from "runtime module dependency". For example, if `Y` is only used for code generation, it might make sense to install it into a separate virtual environment - and do that only when you build the package from sources. But if `X` would actually require Python for its runtime, then `Y` should be installed to the same Python that is being used by the rest of the project...

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: IgorIvanov-Kudan
issue_14799: state: open
title: [feature] Explore ways to speedup compatibility checks
body: ### What is your suggestion?

There's been internal discussion on how we could improve the time it takes to process the lookup of compatible packages. Opening this issue for treacability

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: RubenRBS
issue_14792: state: open
title: [bug] Unable to compile boost python on Windows with clang
body: ### Environment details

* Operating System+version: Windows 10 22H2
* Compiler+version: clang 16.0.5
* Conan version: 2.0.11
* Python version: 3.11.5


### Steps to reproduce

Hello ! I logged everything in this ticket https://github.com/conan-io/conan-center-index/issues/19941

I have no idea whether it is a bug in the recipe or from the conan client.

Could you please help me out? Thanks in advance.

### Logs

_No response_
user: Todiq
issue_14790: state: open
title: [question]How to config and link indirect dependence automatic in Conan2 with cmake
body: ### What is your question?

I have a project `A` require a static lib `B`, and B require another static lib `C`, how can I link the indirect dependence  `C` automatic by `find_package(B)` or `target_link_libraries(A public B)`.
ps: use custom cmake script by cpp_info.set_property["cmake_build_modules"] seems possible, but I still want to know is there any other easier way

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: lxrui
issue_14788: state: open
title: [feature] CMakeDeps generates incorrect CMake variables
body: ### What is your suggestion?

Hi, I found issue with opencv package using openjpeg (`opencv:with_jpeg2000=openjpeg`). After my investigation, I have suggestion to new feature into Conan. Here are both issue and my suggestion in details.

## Environment

Conan 1.61.0
Windows msvc builds

## Issue

Official [OpenJPEGConfig.cmake](https://github.com/uclouvain/openjpeg/blob/master/cmake/OpenJPEGConfig.cmake.in) is using UPPERCASE naming (`OPENJPEG`) for odlschool CMake variables like `OPENJPEG_INCLUDE_DIRS` even when package name is in CamelCase (`OpenJPEG`). This is pretty common style, even for CMake built-in [finders](https://cmake.org/cmake/help/v3.6/manual/cmake-modules.7.html)
So packages like `opencv` (and a lot more) using these oldschool cmake variables, expect official naming.

But Conan [CMakeDeps](https://github.com/conan-io/conan/blob/7ac7a89905f0695b350313f0d49a9396c67e25f3/conan/tools/cmake/cmakedeps/templates/config.py#L68) use file_name aka CMake PackageName to generate these variables. So they not match with official Config.cmake
```
set({{ file_name }}_VERSION_STRING "{{ version }}")
set({{ file_name }}_INCLUDE_DIRS {{ '${' + pkg_name + '_INCLUDE_DIRS' + config_suffix + '}' }} )
set({{ file_name }}_INCLUDE_DIR {{ '${' + pkg_name + '_INCLUDE_DIRS' + config_suffix + '}' }} )
set({{ file_name }}_LIBRARIES {{ '${' + pkg_name + '_LIBRARIES' + config_suffix + '}' }} )
set({{ file_name }}_DEFINITIONS {{ '${' + pkg_name + '_DEFINITIONS' + config_suffix + '}' }} )
```

Conan recipes deal with this, by patching sources in consuming packages, like in opencv. This complicates these recipes, it probably cost a lot effort to do it, will cost a lot effort to maintain this within updates to new versions and mainly it's easy to miss something, like in example bellow.

Conan workaroud [recipes/opencv/4.x/conanfile.py](https://github.com/conan-io/conan-center-index/blob/master/recipes/opencv/4.x/conanfile.py#L1353-L1357)
```
tc.variables["OPENJPEG_MAJOR_VERSION"] = openjpeg_version.major
tc.variables["OPENJPEG_MINOR_VERSION"] = openjpeg_version.minor
tc.variables["OPENJPEG_BUILD_VERSION"] = openjpeg_version.patch
```
for this [opencv/CMakeLists.txt](https://github.com/opencv/opencv/blob/4.x/CMakeLists.txt#L1413)
```
if(HAVE_OPENJPEG)
  status("    JPEG 2000:" OpenJPEG_FOUND
      THEN "OpenJPEG (ver ${OPENJPEG_MAJOR_VERSION}.${OPENJPEG_MINOR_VERSION}.${OPENJPEG_BUILD_VERSION})"
      ELSE "build (ver ${OPENJPEG_VERSION})"
  )
```
But there is no patch for usage in [opencv/modules/imgcodecs/CMakeLists.txt](https://github.com/opencv/opencv/blob/4.x/modules/imgcodecs/CMakeLists.txt#L54)
```
if(HAVE_OPENJPEG)
  ocv_include_directories(${OPENJPEG_INCLUDE_DIRS})
  list(APPEND GRFMT_LIBS ${OPENJPEG_LIBRARIES})
endif()
```
like it is for [jasper](https://github.com/conan-io/conan-center-index/blob/master/recipes/opencv/4.x/conanfile.py#L1147)
```
replace_in_file(self, os.path.join(self.source_folder, "modules", "imgcodecs", "CMakeLists.txt"), "JASPER_", "Jasper_")
```
So `OPENJPEG_INCLUDE_DIRS` and `OPENJPEG_LIBRARIES` not exists

I think that Conan needs to address root cause of this issue, not patching every package affected by this. So `CMakeDeps` should be enhanced to generate proper variables. There is my proposal

## What is your suggestion?

New CMake tools already support property for `<PackageName>Config.cmake` and/or `Find<PackageName>.cmake` file name:
```python
self.cpp_info.set_property("cmake_file_name", "OpenJPEG")
```

So there should be also something like: - *name reflect CMake [Result Variables](https://cmake.org/cmake/help/v3.6/module/FindCurses.html#result-variables) chapter in documentation*
```python
self.cpp_info.set_property("cmake_result_variables_name", "OPENJPEG")
```
with usage like this:
```python
result_variables_prefix = self.get_property("cmake_result_variables_name", dep) or self.get_property("cmake_file_name", dep)
```
This will work for most packages, but there are exceptions like [FindPythonLibs](https://cmake.org/cmake/help/v3.6/module/FindPythonLibs.html), where is used `PYTHON_` vs `PYTHONLIBS_`
```
PYTHONLIBS_FOUND           - have the Python libs been found
PYTHON_LIBRARIES           - path to the python library
PYTHON_INCLUDE_PATH        - path to where Python.h is found (deprecated)
PYTHON_INCLUDE_DIRS        - path to where Python.h is found
PYTHON_DEBUG_LIBRARIES     - path to the debug library (deprecated)
PYTHONLIBS_VERSION_STRING  - version of the Python libs found (since CMake 2.8.8)
```
so property to define name for version related variables may be useful
```python
self.cpp_info.set_property("cmake_version_variables_name", "PYTHONLIBS")
```
with usage like this:
```python
version_variables_prefix = self.get_property("cmake_version_variables_name", dep) or result_variables_prefix
```
But because CMake [find_package](https://cmake.org/cmake/help/latest/command/find_package.html) provides version related variables like `<PackageName>_VERSION_MAJOR`, packages like OpenJPEG also explicitely set uppercase versions like `<PACKAGE_NAME>_VERSION_MAJOR`. So in case that `version_variables_prefix` not match with `PackageName` (`file_name`) Conan should set these as well. And probably also `<PACKAGE_NAME>_FOUND` variant

I would also consider to add `<PackageName>_LIBRARY`. Some package set this one and if not, nobody will use it.

Last issue with this enchancement is, that there are already patches in conan recipes to deal with this and they will be invalid with fixed Config.cmake. Also depricated cmake tools will not support this. And there are also packages like [libwebp](https://github.com/webmproject/libwebp/blob/main/cmake/WebPConfig.cmake.in) that supports both naming styles.
So current variables named based on `cmake_file_name` needs to be generated as well. I'm not sure, if this should be supported always or somehow configurable.

## All toghether
```python
generate_file_name_variables = True # TODO: optional?
```
New optional properies:
```python
self.cpp_info.set_property("cmake_result_variables_name", "PYTHON")
self.cpp_info.set_property("cmake_version_variables_name", "PYTHONLIB")
```
With defaults like:
```python
file_name = self.get_property("cmake_file_name", dep)
result_variables_prefix = self.get_property("cmake_result_variables_name", dep) or file_name
version_variables_prefix = self.get_property("cmake_version_variables_name", dep) or result_variables_prefix
```
And usage in [CMakeDeps](https://github.com/conan-io/conan/blob/7ac7a89905f0695b350313f0d49a9396c67e25f3/conan/tools/cmake/cmakedeps/templates/config.py#L68)
```
{% if generate_file_name_variables and version_variables_prefix != file_name %}
set({{ file_name }}_VERSION_STRING "{{ version }}")
{% endif %}
{% if generate_file_name_variables and result_variables_prefix != file_name %}
set({{ file_name }}_INCLUDE_DIRS {{ '${' + pkg_name + '_INCLUDE_DIRS' + config_suffix + '}' }} )
set({{ file_name }}_INCLUDE_DIR {{ '${' + pkg_name + '_INCLUDE_DIRS' + config_suffix + '}' }} )
set({{ file_name }}_LIBRARIES {{ '${' + pkg_name + '_LIBRARIES' + config_suffix + '}' }} )
set({{ file_name }}_DEFINITIONS {{ '${' + pkg_name + '_DEFINITIONS' + config_suffix + '}' }} )
{% endif %}

set({{ version_variables_prefix }}_VERSION_STRING "{{ version }}")
{% if version_variables_prefix != file_name %}
set({{ version_variables_prefix }}_VERSION "{{ version }}")
set({{ version_variables_prefix }}_VERSION_MAJOR "{{ version.major or 0 }}")
set({{ version_variables_prefix }}_VERSION_MINOR "{{ version.minor or 0 }}")
set({{ version_variables_prefix }}_VERSION_PATCH "{{ version.patch or 0 }}")
set({{ version_variables_prefix }}_VERSION_TWEAK "{{ version.micro or 0 }}")
set({{ version_variables_prefix }}_VERSION_COUNT "{{ len(version.items) }}")
set({{ version_variables_prefix }}_FOUND 1)
{% endif %}
set({{ result_variables_prefix }}_INCLUDE_DIRS {{ '${' + pkg_name + '_INCLUDE_DIRS' + config_suffix + '}' }} )
set({{ result_variables_prefix }}_INCLUDE_DIR {{ '${' + pkg_name + '_INCLUDE_DIRS' + config_suffix + '}' }} )
set({{ result_variables_prefix }}_LIBRARIES {{ '${' + pkg_name + '_LIBRARIES' + config_suffix + '}' }} )
set({{ result_variables_prefix }}_LIBRARY {{ '${' + pkg_name + '_LIBRARIES' + config_suffix + '}' }} )
set({{ result_variables_prefix }}_DEFINITIONS {{ '${' + pkg_name + '_DEFINITIONS' + config_suffix + '}' }} )
```

I not check how Conan generates `Find<PackageName>.cmake` files, but this should be considered for this case as well.

# Usage in conan recipes

__PackeName == Resutl Variables == Version Variables__: no change
```python
    name = "postgre-sql"

    def package_info(self):
        self.cpp_info.set_property("cmake_file_name", "PostgreSQL")
```

__PackeName != Resutl Variables == Version Variables__: use `cmake_result_variables_name`
```python
    name = "openjpeg"

    def package_info(self):
        self.cpp_info.set_property("cmake_file_name", "OpenJPEG")
        self.cpp_info.set_property("cmake_result_variables_name", "OPENJPEG")
```

__PackeName != Resutl Variables != Version Variables__: use `cmake_result_variables_name` and `cmake_version_variables_name`
```python
    name = "pythonlib"

    def package_info(self):
        self.cpp_info.set_property("cmake_file_name", "Python")
        self.cpp_info.set_property("cmake_result_variables_name", "PYTHON")
        self.cpp_info.set_property("cmake_version_variables_name", "PYTHONLIB")
```

__PackeName != Resutl Variables == Version Variables + extra variables__: use `cmake_result_variables_name` + `conan-official-{name}-variables.cmake`
```python
    name = "openssl"

    def package_info(self):
        self.cpp_info.set_property("cmake_file_name", "Python")
        self.cpp_info.set_property("cmake_result_variables_name", "OPENSSL")

    def _create_cmake_module_variables(self, module_file):
        content = textwrap.dedent("""\
            if(DEFINED OpenSSL_Crypto_LIBS)
                set(OPENSSL_CRYPTO_LIBRARY ${OpenSSL_Crypto_LIBS})
                set(OPENSSL_CRYPTO_LIBRARIES ${OpenSSL_Crypto_LIBS}
                                             ${OpenSSL_Crypto_DEPENDENCIES}
                                             ${OpenSSL_Crypto_FRAMEWORKS}
                                             ${OpenSSL_Crypto_SYSTEM_LIBS})
            elseif(DEFINED openssl_OpenSSL_Crypto_LIBS_%(config)s)
                set(OPENSSL_CRYPTO_LIBRARY ${openssl_OpenSSL_Crypto_LIBS_%(config)s})
                set(OPENSSL_CRYPTO_LIBRARIES ${openssl_OpenSSL_Crypto_LIBS_%(config)s}
                                             ${openssl_OpenSSL_Crypto_DEPENDENCIES_%(config)s}
                                             ${openssl_OpenSSL_Crypto_FRAMEWORKS_%(config)s}
                                             ${openssl_OpenSSL_Crypto_SYSTEM_LIBS_%(config)s})
            endif()
            if(DEFINED OpenSSL_SSL_LIBS)
                set(OPENSSL_SSL_LIBRARY ${OpenSSL_SSL_LIBS})
                set(OPENSSL_SSL_LIBRARIES ${OpenSSL_SSL_LIBS}
                                          ${OpenSSL_SSL_DEPENDENCIES}
                                          ${OpenSSL_SSL_FRAMEWORKS}
                                          ${OpenSSL_SSL_SYSTEM_LIBS})
            elseif(DEFINED openssl_OpenSSL_SSL_LIBS_%(config)s)
                set(OPENSSL_SSL_LIBRARY ${openssl_OpenSSL_SSL_LIBS_%(config)s})
                set(OPENSSL_SSL_LIBRARIES ${openssl_OpenSSL_SSL_LIBS_%(config)s}
                                          ${openssl_OpenSSL_SSL_DEPENDENCIES_%(config)s}
                                          ${openssl_OpenSSL_SSL_FRAMEWORKS_%(config)s}
                                          ${openssl_OpenSSL_SSL_SYSTEM_LIBS_%(config)s})
            endif()
        """% {"config":str(self.settings.build_type).upper()})
        save(self, module_file, content)
```


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: hekrdla
issue_14784: state: open
title: [feature] debugging symbols management
body: ### What is your suggestion?

Symbols are critical in development life, as we debug day to day.

Imaging a software distributed to customers, shipped with dump collecting tool like crashpad. We would get dump in case the app crashed. Thus we need symbols to backtrace the stack.

Currently, there is no guarantee that the recipes in conan center are designed to build with symbol and pack symbols into the pre-built binary packages, nor a machanism to obtain the infomation about whether these binary packges ship symbols or not.

As a result, we cannot feel free to use the Conan Center, because we want to ensure that the executable binaries we distribute to the end user have symbols to keep track.

I hope conan add some machanisms to deal with symbols. Some could be considered are:

* an option like `shared` `fPIC`
* a way to know whether a binary package has symbols or not, if not, the package consumer could reject to use that binary package and build that package with symbols locally
* normalize the symbols file layout in binary package, may be `info.libdir` and `info.bindir`. e.g. library compiled with `msvc` would have pdbs, for shared-build, the pdb files can be placed anywhere, but for static-build, the pdb files should stay togather with the `.lib` file.
* recipes in Conan Center will default to build with symbols and the pre-built binary packages (library type) all ship with symbols.
* a deployer helper to deploy symbols

The key is, we can get symbols from Conan Center when consuming recipes on Conan Center. Even Conan Center didn't default to have symbols, the consumer should be able to opt in.
 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: X1aomu
issue_14778: state: open
title: Why does conan create tmp_config_install folder in cache?
body: ### What is your question?

Hi,

I would like to know, why conan creates `tmp_config_install` folder in cache?
The reason why I am asking this question is because of error that occurs in Jenkins pipeline when building projects.
`ERROR: Failed conan config install: Cannot change permissions for C:\***\.conan\tmp_config_install\test\ Exception info: (<class 'OSError'>, OSError(41, 'The directory is not empty'), <traceback object at 0x000001D1C788ED40>)`

My projects are so configured that `conan config install` is executed as a pre step and then the projects are built. When executing mentioned cmd, `tmp_config_install` is created in conan cache for a short time and then deleted. Conan settings are retrieved from `gerrit` repository. 
It seems that 'tmp_config_install' is locked/accessed by some other process and conan can not delete it. There are no concurrent jobs running.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Melkjot
issue_14773: state: open
title: [question] How to set CMAKE_BUILD_TYPE to a specific value (CMakeToolchain generator)?
body: ### What is your question?

Hello, I would like to enforce that my conanfile always builds with a specific `CMAKE_BUILD_TYPE` when using `CMakeToolchain` generator. How can I do this?

I would expect this test to pass:
```
def test_cmake_presets_build_type():
    client = TestClient()
    profile = textwrap.dedent("""
        [settings]
        os = Linux
        arch = x86_64
        compiler=gcc
        compiler.version=8
        compiler.libcxx=libstdc++11
    """)
    
    conanfile = textwrap.dedent("""
        from conan import ConanFile
        from conan.tools.cmake import CMakeToolchain

        class Conan(ConanFile):
            settings = "os", "arch", "compiler", "build_type"

            def generate(self):
                toolchain = CMakeToolchain(self)
                toolchain.cache_variables["CMAKE_BUILD_TYPE"] = "MinSizeRel"
                toolchain.generate()
    """)
    
    client.save({"conanfile.py": conanfile, "profile": profile})
    client.run("create . mylib/1.0@ -s build_type=Release --profile:h=profile")
    client.run("install mylib/1.0@ -g CMakeToolchain -s build_type=Release --profile:h=profile")
    presets = json.loads(client.load("CMakePresets.json"))
    assert len(presets["configurePresets"]) == 1
    cache_variables = presets["configurePresets"][0]["cacheVariables"]
    assert cache_variables["CMAKE_BUILD_TYPE"] == 'MinSizeRel'
```

It seems that `cache_variables["CMAKE_BUILD_TYPE"]` is always overwritten by the value of setting "build_type".
Ref: https://github.com/conan-io/conan/blob/release/2.0/conan/tools/cmake/presets.py#L103 
Is this behavior intended?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: thorsten-klein
issue_14772: state: open
title: [feature] Provide instruction to get conan_server in PATH
body: ### What is your suggestion?

After installing conan from source with pip, I only get a `conan` CLI and I can't find the `conan_server` handy. Please provide instructions in the README.md as to how to get the `conan_server` command in the `PATH`.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: gl-yziquel
issue_14769: state: open
title: [question] How to best package internal dependencies for use by external developers
body: ### What is your question?

Hi everybody,

We're using conan and Artifactory for internal software development. We now want to outsource some of the work and need a way to distribute the dependencies from our internal Artifactory instance in a way that is compatible with the existing build scripts built around conan.

I'm now looking for a way to transfer the build dependencies of our main application in binary form to our external developers so that they can further develop the main application.

### I can't

- Make the Artifactory server available to the external team
- Share the source code of the dependencies of our main application

Mostly because of concerns around security/intellectual property.

### I can
- Modify the conan packages as needed
- Share the source code of the main application with the external team

### What I'm looking for is

- A way to use conan to combine all dependencies and transistive dependencies of a given build configuration into an archive (e.g. zip file)
- Share this archive with our external team (E.g. USB-Stick, E-Mail, FTP)
- A command that lets the external team import the dependencies and build the main application from source

Can I just move the content of my fresh conan home to the external team to achieve this effect?
Does anyone have any other idea how I could achieve that?

### Notes
It seems that https://github.com/conan-io/conan/issues/2197 was also going in that direction, but was closed due to resource constraints. In my case the dependencies are only a few MB so I don't think that's problematic at all.

Currently my projects are at conan 1.6, but it shouldn't be a problem to move to 2.0 if it's easier to get that working there.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: creiter64
issue_14768: state: open
title: [bug] Error when compiling boost/1.76.0 on Windows with clang
body: ### Environment details

* Operating System+version: Windows 10
* Compiler+version:
![image](https://github.com/conan-io/conan/assets/3659986/44da7507-dca2-4949-8de9-4c35cf42c546)
* Conan version: 1.59.0
* Python version: 3.9.12


### Steps to reproduce

1. A profile for `clang` version 16:
```
[settings]
os=Windows
os_build=Windows   
arch=x86_64        
compiler=clang     
compiler.version=16
build_type=Debug   
[options]
[conf]
[build_requires]
[env]
```
I call it `ninja`
2. run `conan install boost/1.76.0@ -pr ninja --build missing`
3. build failes

### Logs

```
boost/1.76.0: Applying build-requirement: b2/4.8.0
boost/1.76.0: WARN: Build folder is dirty, removing it: C:\.conan\caa543\1
boost/1.76.0: Building your package in C:\.conan\caa543\1
boost/1.76.0: Generator txt created conanbuildinfo.txt
boost/1.76.0: Aggregating env generators
boost/1.76.0: Calling build()
WARN: replace_in_file didn't find pattern '/* thread_local */' in 'C:\.conan\707580\1\source_subfolder\boost\stacktrace\detail\libbacktrace_impls.hpp' file.
WARN: replace_in_file didn't find pattern '/* static __thread */' in 'C:\.conan\707580\1\source_subfolder\boost\stacktrace\detail\libbacktrace_impls.hpp' file.
WARN: replace_in_file didn't find pattern 'local generic-os = [ set.difference $(all-os) : aix darwin vxworks solaris osf hpux ] ;' in 'C:\.conan\707580\1\source_subfold
er\tools\build\src\tools\gcc.jam' file.
WARN: replace_in_file didn't find pattern 'local no-threading = android beos haiku sgi darwin vxworks ;' in 'C:\.conan\707580\1\source_subfolder\tools\build\src\tools\gc
c.jam' file.
WARN: replace_in_file didn't find pattern '    <conditional>@numa' in 'C:\.conan\707580\1\source_subfolder\libs\fiber\build\Jamfile.v2' file.
boost/1.76.0: WARN: Patching user-config.jam
boost/1.76.0: WARN: 
using zlib : 1.2.12 : <include>"C:/Users/palli/.conan/data/zlib/1.2.12/_/_/package/c438badecc47e97cbd11f575a8aec4917a7cdf1f/include" <search>"C:/Users/palli/.conan/data/
zlib/1.2.12/_/_/package/c438badecc47e97cbd11f575a8aec4917a7cdf1f/lib" <name>zlib ;
using bzip2 : 1.0.8 : <include>"C:/Users/palli/.conan/data/bzip2/1.0.8/_/_/package/476df88c4386fb875187aee83f02b4ff597c4a04/include" <search>"C:/Users/palli/.conan/data/
bzip2/1.0.8/_/_/package/476df88c4386fb875187aee83f02b4ff597c4a04/lib" <name>bz2 ;
using "clang-win" :  :  C:/Program Files/LLVM/bin/clang++.exe :
 ;
boost/1.76.0: WARN: b2.exe -q numa=on target-os=windows architecture=x86 address-model=64 binary-format=pe abi=ms --layout=system --user-config=C:\.conan\707580\1\source
_subfolder\tools\build\user-config.jam -sNO_ZLIB=0 -sNO_BZIP2=0 -sNO_LZMA=1 -sNO_ZSTD=1 boost.locale.icu=off --disable-icu boost.locale.iconv=off --disable-iconv threadi
ng=multi visibility=hidden link=static variant=debug --with-atomic --with-chrono --with-container --with-context --with-contract --with-coroutine --with-date_time --with
-exception --with-fiber --with-filesystem --with-graph --with-iostreams --with-json --with-locale --with-log --with-math --with-nowide --with-program_options --with-rand
om --with-regex --with-serialization --with-stacktrace --with-system --with-test --with-thread --with-timer --with-type_erasure --with-wave toolset=clang-win pch=on link
flags="-stdlib=None" cxxflags="-fPIC -stdlib=None" install --prefix=C:\.conan\b742d1\1 -j8 --abbreviate-paths -d0 --debug-configuration --build-dir="C:\.conan\caa543\1" 
notice: found boost-build.jam at C:/.conan/707580/1/source_subfolder/boost-build.jam
notice: loading B2 from C:/.conan/707580/1/source_subfolder/tools/build/src/bootstrap.jam
warning: mismatched versions of B2 engine and core
warning: B2 engine (b2.exe) is 4.8.0
warning: B2 core (at C:/.conan/707580/1/source_subfolder/tools/build/src) is 4.4-git
notice: Searching 'C:\Users\palli' 'C:\Users\palli' 'C:/.conan/707580/1/source_subfolder/tools/build/src' 'C:/.conan/707580/1/source_subfolder/tools/build/src/kernel' 'C
:/.conan/707580/1/source_subfolder/tools/build/src/util' 'C:/.conan/707580/1/source_subfolder/tools/build/src/build' 'C:/.conan/707580/1/source_subfolder/tools/build/src
/tools' 'C:/.conan/707580/1/source_subfolder/tools/build/src/contrib' 'C:/.conan/707580/1/source_subfolder/tools/build/src/.' for site-config configuration file 'site-co
nfig.jam'.
notice: Configuration file 'site-config.jam' not found in 'C:\Users\palli' 'C:\Users\palli' 'C:/.conan/707580/1/source_subfolder/tools/build/src' 'C:/.conan/707580/1/sou
rce_subfolder/tools/build/src/kernel' 'C:/.conan/707580/1/source_subfolder/tools/build/src/util' 'C:/.conan/707580/1/source_subfolder/tools/build/src/build' 'C:/.conan/7
07580/1/source_subfolder/tools/build/src/tools' 'C:/.conan/707580/1/source_subfolder/tools/build/src/contrib' 'C:/.conan/707580/1/source_subfolder/tools/build/src/.'.   
notice: Loading explicitly specified user configuration file:
    C:\.conan\707580\1\source_subfolder\tools\build\user-config.jam
notice: Searching 'C:\.conan\707580\1\source_subfolder\tools\build' for user-config configuration file 'user-config.jam'.
notice: Loading user-config configuration file 'user-config.jam' from 'C:/.conan/707580/1/source_subfolder/tools/build'.
notice: [zlib] Using pre-installed library
notice: [zlib] Condition
notice: [bzip2] Using pre-installed library
notice: [bzip2] Condition
notice: [msvc-cfg] msvc-14.2 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x64\cl.exe'
notice: [msvc-cfg] msvc-14.1 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\bin\Hostx64\x64\cl.exe'
warning: toolset clang-win initialization:
warning: can not find user-provided command 'C:/Program' 'Files/LLVM/bin/clang++.exe'
warning: initialized from C:\.conan\707580\1\source_subfolder\tools\build\user-config.jam:5
C:/.conan/707580/1/source_subfolder/tools/build/src/tools\clang-win.jam:74: in clang-win.init from module clang-win
error: Cannot configure toolset clang-win: no 'clang-cl.exe' command found or given
C:/.conan/707580/1/source_subfolder/tools/build/src/build\toolset.jam:44: in toolset.using from module toolset
C:/.conan/707580/1/source_subfolder/tools/build/src/build\project.jam:1104: in using from module project-rules
C:\.conan\707580\1\source_subfolder\tools\build\user-config.jam:5: in modules.load from module user-config
C:/.conan/707580/1/source_subfolder/tools/build/src\build-system.jam:255: in load-config from module build-system
C:/.conan/707580/1/source_subfolder/tools/build/src\build-system.jam:449: in load-configuration-files from module build-system
C:/.conan/707580/1/source_subfolder/tools/build/src\build-system.jam:607: in load from module build-system
C:/.conan/707580/1/source_subfolder/tools/build/src/kernel\modules.jam:295: in import from module modules
C:/.conan/707580/1/source_subfolder/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module
C:/.conan/707580/1/source_subfolder/boost-build.jam:17: in module scope from module

boost/1.76.0: 
boost/1.76.0: ERROR: Package '94827d0ba849bed27351c49199c8a58f222aed1b' build failed
boost/1.76.0: WARN: Build folder C:\.conan\caa543\1
ERROR: boost/1.76.0: Error in build() method, line 875
        self.run(full_command, run_environment=True)
        ConanException: Error 1 while executing b2.exe -q numa=on target-os=windows architecture=x86 address-model=64 binary-format=pe abi=ms --layout=system --user-conf
ig=C:\.conan\707580\1\source_subfolder\tools\build\user-config.jam -sNO_ZLIB=0 -sNO_BZIP2=0 -sNO_LZMA=1 -sNO_ZSTD=1 boost.locale.icu=off --disable-icu boost.locale.iconv
=off --disable-iconv threading=multi visibility=hidden link=static variant=debug --with-atomic --with-chrono --with-container --with-context --with-contract --with-corou
tine --with-date_time --with-exception --with-fiber --with-filesystem --with-graph --with-iostreams --with-json --with-locale --with-log --with-math --with-nowide --with
-program_options --with-random --with-regex --with-serialization --with-stacktrace --with-system --with-test --with-thread --with-timer --with-type_erasure --with-wave t
oolset=clang-win pch=on linkflags="-stdlib=None" cxxflags="-fPIC -stdlib=None" install --prefix=C:\.conan\b742d1\1 -j8 --abbreviate-paths -d0 --debug-configuration --bui
ld-dir="C:\.conan\caa543\1"
```
user: Drllap
issue_14767: state: open
title: Capitalisation (?) mismatch between conan and CMake
body: ### Environment details

* Operating System+version: macOS 13.3.1
* Compiler+version: XCode/Apple Clang 14.0.3
* Conan version: 2.0.10
* Python version: 3.11.5
* CMake version: 3.27.5


### Steps to reproduce

I'm not 100% sure if this is a configuration issue or a bug.
I made the following profile:
```
[settings]
arch=armv8
build_type=Release
compiler=apple-clang
compiler.cppstd=gnu20
compiler.libcxx=libc++
compiler.version=14
os=iOS
os.version=16.0
os.sdk_version=16.0
os.sdk=iphoneos
```

Inside of the conanfile I set the generator to Xcode with the CMakeToolchain class in generate

When I try to build with this profile I get:

```
CMake Error at /usr/local/Cellar/cmake/3.27.5/share/cmake/Modules/Platform/iOS-Initialize.cmake:4 (message):
  iphoneos16.0 is not an iOS SDK
```

If I look inside of this file:
```
if(NOT _CMAKE_OSX_SYSROOT_PATH MATCHES "/iPhone(OS|Simulator)")
  message(FATAL_ERROR "${CMAKE_OSX_SYSROOT} is not an iOS SDK")
endif()
```

It seems like this is case sensitive? Or maybe it expects to start with a / for some reason?
however Conan sets it to be lowercase in the conan_toolchain.cmake file:
```
set(CMAKE_OSX_SYSROOT iphoneos16.0 CACHE STRING "" FORCE)
```

Can I disable setting the sysroot? Or should this be fixed inside of conan?

On this specific system I tested without setting the sysroot and this builds just fine:
```
cmake -G Xcode -B build \
    -DCMAKE_SYSTEM_NAME=iOS \
    -DCMAKE_OSX_DEPLOYMENT_TARGET=16.0
xcodebuild -target zlibstatic -project build/zlib.xcodeproj
```

Though without setting it i'm not really sure how to select the simulator 

### Logs

_No response_
user: robindegen
issue_14766: state: open
title: [bug] tools.env.virtualenv:powershell=True prevents program from compiling
body: ### Environment details

* Operating System+version: Windows 10 22H2
* Compiler+version: clang-cl 16.0.5
* Conan version: 2.0.11
* Python version: 3.11.5


### Steps to reproduce

1. Use the following profile:

```txt
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.version=16
compiler.cppstd=23
compiler.runtime=dynamic
compiler.runtime_version=v143
os=Windows

[conf]
tools.cmake.cmaketoolchain:generator=Ninja Multi-Config
tools.env.virtualenv:powershell=True
```

2. Run `conan new cmake_lib -d name=hello -d version=1.0`
3. Try to build it with `conan build .`

This issue must be related to (or consequence of) https://github.com/conan-io/conan/issues/14765/

### Logs

```powershell
======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=23
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.runtime_version=v143
compiler.version=16
os=Windows
[conf]
tools.cmake.cmaketoolchain:generator=Ninja Multi-Config
tools.env.virtualenv:powershell=True

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=23
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.runtime_version=v143
compiler.version=16
os=Windows
[conf]
tools.cmake.cmaketoolchain:generator=Ninja Multi-Config
tools.env.virtualenv:powershell=True


======== Computing dependency graph ========
Graph root
    conanfile.py (hello/1.0): D:\Documents\CAST\test\conanfile.py

======== Computing necessary packages ========

======== Installing packages ========

======== Installing packages ========

======== Finalizing install (deploy, generators) ========
conanfile.py (hello/1.0): Calling generate()
conanfile.py (hello/1.0): Generators folder: D:\Documents\CAST\test\build\generators
conanfile.py (hello/1.0): CMakeToolchain generated: conan_toolchain.cmake
conanfile.py (hello/1.0): Preset 'conan-default' added to CMakePresets.json. Invoke it manually using 'cmake --preset conan-default' if using CMake>=3.23
conanfile.py (hello/1.0): If your CMake version is not compatible with CMakePresets (<3.23) call cmake like: 'cmake <path> -G "Ninja Multi-Config" -DCMAKE_TOOLCHAIN_FILE=D:\Documents\CAST\test\build\generators\conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW'
conanfile.py (hello/1.0): CMakeToolchain generated: CMakePresets.json
conanfile.py (hello/1.0): CMakeToolchain generated: ..\..\CMakeUserPresets.json
conanfile.py (hello/1.0): Generating aggregated env files
conanfile.py (hello/1.0): Generated aggregated env files: ['conanbuild.bat', 'conanbuild.ps1', 'conanrun.ps1']

======== Calling build() ========
conanfile.py (hello/1.0): Calling build()
conanfile.py (hello/1.0): Running CMake.configure()
conanfile.py (hello/1.0): RUN: cmake -G "Ninja Multi-Config" -DCMAKE_TOOLCHAIN_FILE="D:/Documents/CAST/test/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="D:/Documents/CAST/test" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "D:\Documents\CAST\test"
conanvcvars.bat: Activating environment Visual Studio 17 - amd64 - vcvars_ver=14.3
[vcvarsall.bat] Environment initialized for: 'x64'
-- Using Conan toolchain: D:/Documents/CAST/test/build/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 23 with extensions OFF
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The CXX compiler identification is MSVC 19.37.32824.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.37.32822/bin/Hostx64/x64/cl.exe
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.37.32822/bin/Hostx64/x64/cl.exe - broken
CMake Error at D:/Documents/CAST/python3.11/Lib/site-packages/cmake/data/share/cmake-3.27/Modules/CMakeTestCXXCompiler.cmake:60 (message):
  The C++ compiler

    "C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.37.32822/bin/Hostx64/x64/cl.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: 'D:/Documents/CAST/test/build/CMakeFiles/CMakeScratch/TryCompile-0w0knt'

    Run Build Command(s): D:/Documents/CAST/python3.11/Scripts/ninja.exe -v cmTC_6f395
    ninja: error: CMakeFiles\common.ninja:23: loading 'CMakeFiles\rules.ninja': Le fichier spécifié est introuvable.

    include CMakeFiles\rules.ninja
                                  ^ near here





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!

*********************************************************
Recipe 'conanfile.py (hello/1.0)' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter, report it at https://github.com/conan-io/conan-center-index/issues
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: conanfile.py (hello/1.0): Error in build() method, line 44
        cmake.configure()
        ConanException: Error 1 while executing
```
user: Todiq
issue_14763: state: open
title: [question] Should defines follow the same rules as `transitive_headers` trait
body: ### What is your question?

I've encountered and issue where a define was transitivly propagated to the source file, but the header was not. I would just like to ask if this is an intended behavior or a bug.
The header was not not propagated to the source file bacause a dependency in between did not propagate the header of the package from which the define originated. The define was propagated because the dependency in between did propagate the define which caught me by surprise.

For example:

There is a package which defines a `PROTECT` define

```python
class ProtectionConan(ConanFile):
    def package_info(self):
        # ...
        self.cpp_info.components['protection'].defines = ['PROTECT']
```

There is a consumer of the package `protection` which does not tranistivly propagate headers of the package `protection`.

```python
class ConsumerConan(ConanFile):
    def requirements(self):
        self.requires('protection/[~2]@microblink/main')
```

The issue occurs in the test package of the `consumer` because of the following code:

```cpp
#ifdef PROTECT
#include <some-header-from-protection.hpp>
// Some protection specific code
#endif
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: lmglmg
issue_14762: state: open
title: Is this library subject to US EAR (Encryption and Export administration regulations)?
body: ### What is your question?

First, thank you so much for developing this open-source software which is powerful and feature-rich but also simple and easy to use. I prepare to use it in my projects. However, I wonder whether this software is subject to the Export Administration Regulations (EAR).
In case of being controlled by EAR, would you please tell me which classification number (ECCN) does it come under? Are there any restrictions or specific license requirements? May I know in which country or region did your team compile it? And does the software have encryption function? In case that encryption function is included, has the filing information been submitted according to EAR§742.15(b)? 

I need this information to comply with the Export Administration Regulations (EAR), and I'm sure other users of this software would benefit from this information as well.

Thanks and best wishes

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: ztest-dev
issue_14758: state: open
title: [bug] CMakeDeps: files in `cmake_build_modules` of build requirements listed in `build_context_activated` are not included in generated config files
body: ### Environment details

* Operating System+version: macOS Ventura
* Compiler+version: apple-clang 14
* Conan version: 2.0.10
* Python version: 3.11.5


### Steps to reproduce

- checkout https://github.com/conan-io/conan-center-index/tree/fd03d6808dda34c7488399e36b31e1b5d0306caf/recipes/btyacc/all
- cd to `recipes/btyacc/all`, and run `conan create . --version 3.0`

### Logs

```
======== Testing the package: Building ========
btyacc/3.0 (test package): Calling build()
btyacc/3.0 (test package): Running CMake.configure()
btyacc/3.0 (test package): RUN: cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="/Users/spaceim/github-projects/conan-center-index/recipes/btyacc/all/test_package/build/macos-x86_64-apple-clang-14/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/Users/spaceim/github-projects/conan-center-index/recipes/btyacc/all/test_package" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/Users/spaceim/github-projects/conan-center-index/recipes/btyacc/all/test_package"
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Using Conan toolchain: /Users/spaceim/github-projects/conan-center-index/recipes/btyacc/all/test_package/build/macos-x86_64-apple-clang-14/Release/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 20 with extensions OFF
-- The C compiler identification is AppleClang 14.0.3.14030022
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Conan: Target declared 'btyacc::btyacc'
CMake Error at CMakeLists.txt:8 (message):
  BTYACC_EXECUTABLE is not defined
```

- `BTYACC_EXECUTABLE` is a custom CMake variables defined in a file listed in `cmake_build_modules` property of `btyacc` recipe (see https://github.com/conan-io/conan-center-index/blob/fd03d6808dda34c7488399e36b31e1b5d0306caf/recipes/btyacc/all/conanfile.py#L50-L70).
- test package properly defines `build_context_activated` of `CMakeDeps` (see https://github.com/conan-io/conan-center-index/blob/fd03d6808dda34c7488399e36b31e1b5d0306caf/recipes/btyacc/all/test_package/conanfile.py#L9-L20), and indeed a `btyacc-config.cmake` file is generated.

But in this generated config file, I can't see any include of the file defined in `cmake_build_modules`, leading to this error (CMakeLists of test package checks whether this variable is defined after `find_package(btyacc REQUIRED CONFIG)`: https://github.com/conan-io/conan-center-index/blob/fd03d6808dda34c7488399e36b31e1b5d0306caf/recipes/btyacc/all/test_package/CMakeLists.txt#L6-L9)
user: SpaceIm
issue_14755: state: open
title: [bug] Error not thrown when detected compiler does not match profile
body: ### Environment details

* Operating System+version: Arch Linux
* Compiler+version: clang 16.0.6
* Conan version: 2.0.10
* Python version: 3.11.1


### Steps to reproduce

1. Install clang 16.0.6
2. Set default conan profile to the following, noting that `compiler.version=15`
```
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=20
compiler.libcxx=libstdc++11
compiler.version=15
os=Linux
[conf]
tools.build:compiler_executables={'c': '/usr/bin/clang', 'cpp': '/usr/bin/clang++'}

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=20
compiler.libcxx=libstdc++11
compiler.version=15
os=Linux
[conf]
tools.build:compiler_executables={'c': '/usr/bin/clang', 'cpp': '/usr/bin/clang++'}

```
4. `conan new cmake_lib -d name=test -d version=0.1.0`
5. `conan build .`
6. Observe no error is thrown. This always used to be the case.

### Logs

```
$ conan --version
Conan version 2.0.10
$ conan new cmake_lib -d name=test -d version=0.1.0
File saved: CMakeLists.txt
File saved: conanfile.py
File saved: include/test.h
File saved: src/test.cpp
File saved: test_package/CMakeLists.txt
File saved: test_package/conanfile.py
File saved: test_package/src/example.cpp
$ clang++ --version
clang version 16.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ which clang++
/usr/bin/clang++
$ conan build .

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=20
compiler.libcxx=libstdc++11
compiler.version=15
os=Linux
[conf]
tools.build:compiler_executables={'c': '/usr/bin/clang', 'cpp': '/usr/bin/clang++'}

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=20
compiler.libcxx=libstdc++11
compiler.version=15
os=Linux
[conf]
tools.build:compiler_executables={'c': '/usr/bin/clang', 'cpp': '/usr/bin/clang++'}


======== Computing dependency graph ========
Graph root
    conanfile.py (test/0.1.0): /home/user/projects/test/conan-compiler-error-check/conanfile.py

======== Computing necessary packages ========

======== Installing packages ========

======== Installing packages ========

======== Finalizing install (deploy, generators) ========
conanfile.py (test/0.1.0): Calling generate()
conanfile.py (test/0.1.0): Generators folder: /home/user/projects/test/conan-compiler-error-check/build/Release/generators
conanfile.py (test/0.1.0): CMakeToolchain generated: conan_toolchain.cmake
conanfile.py (test/0.1.0): Preset 'conan-release' added to CMakePresets.json. Invoke it manually using 'cmake --preset conan-release' if using CMake>=3.23
conanfile.py (test/0.1.0): If your CMake version is not compatible with CMakePresets (<3.23) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/home/user/projects/test/conan-compiler-error-check/build/Release/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
conanfile.py (test/0.1.0): CMakeToolchain generated: CMakePresets.json
conanfile.py (test/0.1.0): CMakeToolchain generated: ../../../CMakeUserPresets.json
conanfile.py (test/0.1.0): Generating aggregated env files
conanfile.py (test/0.1.0): Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']

======== Calling build() ========
conanfile.py (test/0.1.0): Calling build()
conanfile.py (test/0.1.0): Running CMake.configure()
conanfile.py (test/0.1.0): RUN: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/user/projects/test/conan-compiler-error-check/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/user/projects/test/conan-compiler-error-check" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/user/projects/test/conan-compiler-error-check"
-- Using Conan toolchain: /home/user/projects/test/conan-compiler-error-check/build/Release/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- Conan toolchain: C++ Standard 20 with extensions OFF
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The CXX compiler identification is Clang 16.0.6
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.3s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_POLICY_DEFAULT_CMP0091


-- Build files have been written to: /home/user/projects/test/conan-compiler-error-check/build/Release

conanfile.py (test/0.1.0): Running CMake.build()
conanfile.py (test/0.1.0): RUN: cmake --build "/home/user/projects/test/conan-compiler-error-check/build/Release" -- -j24
[ 50%] Building CXX object CMakeFiles/test.dir/src/test.cpp.o
[100%] Linking CXX static library libtest.a
[100%] Built target test

```
user: samuel-emrys
issue_14753: state: open
title: [bug] ModuleNotFoundError: No module named 'distro'
body: ### Environment details

* Operating System+version: Alpine Linux 3.18, Debian "bookworm" 12.1 
* Compiler+version: N/A
* Conan version: 2.0.10
* Python version: 3.10.13, 3.9.17


### Steps to reproduce

1. Use the following `Pipfile`:
```
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
conan = "~=2.0"
```
2. `pipenv install`
3. `pipenv run conan --version`

This results in an error `ModuleNotFoundError: No module named 'distro'`. The culprit is line 167 in `conans/client/cache/cache.py`:

```
                if platform.system() in ["Linux", "FreeBSD"]:
                    import distro
```

I'd expect distro to be declared as a dependency of conan (if needed) when installing via pip or pipenv. Our current workaround is installing distro manually.

### Logs

```
Traceback (most recent call last):
  File "/tmp/builds/0/conan-recipe/KsHsZjTr/0/conan_recipe/.venv/bin/conan", line 8, in <module>
    sys.exit(run())
  File "/tmp/builds/0/conan-recipe/KsHsZjTr/0/conan_recipe/.venv/lib/python3.9/site-packages/conans/conan.py", line 7, in run
    main(sys.argv[1:])
  File "/tmp/builds/0/conan-recipe/KsHsZjTr/0/conan_recipe/.venv/lib/python3.9/site-packages/conan/cli/cli.py", line 244, in main
    conan_api = ConanAPI()
  File "/tmp/builds/0/conan-recipe/KsHsZjTr/0/conan_recipe/.venv/lib/python3.9/site-packages/conan/api/conan_api.py", line 41, in __init__
    check_required_conan_version(self.cache_folder)
  File "/tmp/builds/0/conan-recipe/KsHsZjTr/0/conan_recipe/.venv/lib/python3.9/site-packages/conans/client/conf/required_version.py", line 29, in check_required_conan_version
    cache = ClientCache(cache_folder)
  File "/tmp/builds/0/conan-recipe/KsHsZjTr/0/conan_recipe/.venv/lib/python3.9/site-packages/conans/client/cache/cache.py", line 47, in __init__
    self._store_folder = self.new_config.get("core.cache:storage_path") or \
  File "/tmp/builds/0/conan-recipe/KsHsZjTr/0/conan_recipe/.venv/lib/python3.9/site-packages/conans/client/cache/cache.py", line 167, in new_config
    import distro
ModuleNotFoundError: No module named 'distro'
```
user: s-ker-s
issue_14751: state: open
title: [feature] Introduce default components
body: ### What is your suggestion?

Currently, Conan packages can have various components, and users can cherry-pick which ones they want to use. However, if a consumer package doesn't explicitly specify which components it needs, it ends up including all of them. This can lead to issues, especially when some components are hefty or are meant only for testing.

Now, here's my idea: Let's introduce the concept of default components in Conan, somewhat akin to how Rust's default features work. In Rust, crates (packages) have features (components), and each crate can specify default features. When users import a crate, they automatically get the default features along with any features they manually select. And if users want to skip the default features, they can simply specify `default-features = false` in their `Cargo.toml` file.

I believe we can adopt a similar mechanism in Conan, where we define default components for packages. Here's how it could work:

1. Defining Default Components: Package creators can specify which components should be considered default for their packages. This information would be stored in the package recipe.

2. User-Friendly Defaults: When users pull in a Conan package, they'd automatically get the default components, making it easier for them to get started without specifying every component individually.

3. Manual Component Selection: Users can still manually select the components they need, just like they do now. This won't change.

4. Opting Out of Defaults: For backward compatibility, if no default components are specified in the package recipe, we can consider all components as default components. This ensures that existing packages still work seamlessly.

This approach simplifies the Conan package usage for common scenarios, making it more user-friendly while retaining the flexibility for advanced use cases.

Rust features documentation : https://doc.rust-lang.org/cargo/reference/features.html

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: lmglmg
issue_14748: state: open
title: [question] Does CMakeToolchain generator have to set `CMAKE_PREFIX_PATH`?
body: ### What is your question?

Hello, 
`CMakeToolchain` generator sets `CMAKE_PREFIX_PATH`  and also `CMAKE_LIBRARY_PATH`, `CMAKE_PROGRAM_PATH` and `CMAKE_INCLUDE_PATH`. 
Unfortunately `CMAKE_PREFIX_PATH` affects each cmake `find_xxx()` command and in most cases it is is even preferred, e.g. `CMAKE_PREFIX_PATH/include` is preferred over `CMAKE_INCLUDE_PATH`.

Ref:
- https://cmake.org/cmake/help/latest/command/find_path.html
- https://cmake.org/cmake/help/latest/command/find_program.html
- https://cmake.org/cmake/help/latest/command/find_file.html
- https://cmake.org/cmake/help/latest/command/find_path.html
- https://cmake.org/cmake/help/latest/command/find_package.html

Wouldn't it make sense to use `CMAKE_FRAMEWORK_PATH` instead of `CMAKE_PREFIX_PATH`?
Benefit: `CMAKE_FRAMEWORK_PATH` is taken into account by the `find_xxx()`, but it is not preferred. `CMAKE_PREFIX_PATH` is always searched first, which is why `CMAKE_LIBRARY_PATH` / `CMAKE_INCLUDE_PATH` / `CMAKE_PROGRAM_PATH` do not have any effect.

If `CMAKE_PREFIX_PATH` is not set anymore, then it would be:
-  `CMAKE_FRAMEWORK_PATH` is searched by `find_package()` 
-  `CMAKE_LIBRARY_PATH` is preferred by `find_library()`, then searching in `CMAKE_FRAMEWORK_PATH`
-  `CMAKE_INCLUDE_PATH` is preferred by `find_path()` / `find_file()`, then searching in `CMAKE_FRAMEWORK_PATH`
-  `CMAKE_PROGRAM_PATH` is preferred by `find_program()`

Is there any specific reason why the generator sets `CMAKE_PREFIX_PATH`?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: thorsten-klein
issue_14746: state: open
title: CMakeToolchain generator sets `CMAKE_FRAMEWORK_PATH`
body: Changelog: (Feature): CMakeToolchain generator sets CMAKE_FRAMEWORK_PATH to host package roots

Let cmake `find_package()` do its default search procedure instead of maintaining a list of directories as `cpp_info.builddirs`.

With this change users need to maintain only cmake module paths in `cpp_info.builddirs` (containing `FindXXX.cmake`).
cmake config paths (containing `XXX-Config.cmake`) do not need to be maintained anymore.
conan will add each host package root path automatically to `CMAKE_FRAMEWORK_PATH`, which allows cmake to find them automatically when doing its default search procedure 
(Ref: https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure)

Statement from Kitware:
```
The CMAKE_FRAMEWORK_PATH variable will be used by find_* commands, on all platforms. 
The main difference is that by default, on non-Mac platforms, find_* will first look for 
CMAKE_PREFIX_PATH variable entries and then  CMAKE_FRAMEWORK_PATH. 
Order is inverted on Mac by default. 
```

Ref: #14334 

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [x ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

user: thorsten-klein
issue_14745: state: open
title: xray scanning on Conan package
body: ### What is your question?

I am using Conan 1.60.2. I have followed https://blog.conan.io/2021/09/07/Conan-XRay-Integration.html to upload openssl package to my jfrog artifactory server. But the xray report is not generated. It shows In Progress state and remains the same. Even I have followed https://stackoverflow.com/questions/65888471/conan-artifactory-jenkins-integration-fails to publish build artifact and upload conan package from Jenkins. The build is successful but the xray report is In Progress state for uploaded package. The jfrog artifactory is enterprise version. Can you guide me on this?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: psamadda
issue_14742: state: open
title: [feature] JSON output for conan profile show
body: ### What is your suggestion?

Along the lines of https://github.com/conan-io/conan/issues/5937

It would be swell if we could output a conan profile as a json formatted object. `conan profile show --format json my-amazing-profile-unicorns`

We use conan profiles to drive our build matrices, which mean we end up converting them manually in many places to interact with other pipeline systems. It would also allow easy parsing in cmake (which can parse json natively).

The addition would help conan profiles be our "single source of truth", enabling consumption in virtually any language out there. Obviously this isn't pressing, just a nice to have :]

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: p-groarke
issue_14733: state: open
title: [question] GNUInstallDirs not working as expected with conan build and conan export-pkg
body: ### What is your question?

Dear Conan Folks,

Conan Version: 2.0.5
I was using all this while conan create and with that all the GNUInstallDirs were somehow defined.
However, when I use the command conan build + conan export-pkg like this:
```
conan build . -of outputBuild --user autosar --channel featuresamefolder -pr:b=default -pr:h=kdp -c tools.build:skip_test=True
```
I see some definitions are not set : ${CMAKE_INSTALL_LIBDIR} , ${CMAKE_INSTALL_INCLUDEDIR} .
My recipe uses : cmake.build and cmake.install()
The documentation of CMake looks different from 1.x to 2.x: 
https://docs.conan.io/2.0/reference/tools/cmake/cmake.html
 https://docs.conan.io/1/reference/build_helpers/cmake.html?highlight=cmake_install_libdir

Recipe looks like this:
```
from conan import ConanFile
from conan.tools.files import copy
from conan.tools.scm import Git
from conan.tools.cmake import CMake, CMakeToolchain, CMakeDeps


class mytest(ConanFile):
    name = 'mytest'
    url = 'https://github.com/Rad6XX/mytest.git'
    exports_sources = "src/*", "archi/*", "doc/*", "inc/*", "test/*", "CMakeLists.txt", "report/*"
    settings = "os", "compiler", "arch", "build_type"

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
        if not self.conf.get("tools.build:skip_test", default=False):
            print("Tests are set to:", self.conf.get("tools.build:skip_test"))
            self.run("ctest --verbose --output-on-failure")
        cmake.install()


    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()
        deps = CMakeDeps(self)
        deps.generate()

    def package_info(self):
        self.cpp_info.includedirs = ['include']
        self.cpp_info.libdirs = ['lib']
        self.cpp_info.objects = [os.path.join("lib", "mytest.c.obj")]
        self.cpp_info.srcdirs = ['src']
# EOF
```
And cmakelists looks like this:
 ```
cmake_minimum_required(VERSION 3.21.1)


project(mytest LANGUAGES C)
set(CMAKE_SYSTEM_NAME Generic)

add_library(mytest OBJECT ${CMAKE_CURRENT_SOURCE_DIR}/src/mytest.c)
target_include_directories(mytest PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/inc)
set(OBJS $<TARGET_OBJECTS:mytest>)
set_target_properties(mytest PROPERTIES PUBLIC_HEADER ${CMAKE_CURRENT_SOURCE_DIR}/inc/mytest.h)
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/mytest.dir/src/  DESTINATION ${CMAKE_INSTALL_LIBDIR}/lib FILES_MATCHING PATTERN "*.obj")
install(FILES ${CMAKE_SOURCE_DIR}/inc/mytest.h DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/)
install(FILES ${CMAKE_SOURCE_DIR}/src/mytest.c DESTINATION src/)

```

Do I need to specify somewhere in some method explicitly?
Could someone please help me?

Thanks for your help!
Br
Maitrey

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: maitrey
issue_14726: state: open
title: [bug] Conan 1.60.0 uses python_requires to compute package_id, but does not list them in requirements when errors occur
body: ### Environment details

* Operating System+version: Ubuntu 22.04
* Compiler+version: N/A
* Conan version: 1.60.0
* Python version: 3.10.8


### Steps to reproduce

1. Build package DEP, which has a python_require PYDEP with a version range (not fixed)
2. Create a new version of PYDEP
3. Try to build a package which depends on DEP

 Notice in the log below how the package lists zero dependencies, even though there IS a dependency: PYDEP

This caused several hours of debugging, since we had no idea what we were looking for. I don't believe this would have been an issue with Conan 2, as I've seen Conan 2 list python requires in such situations.

### Logs

```
ERROR: Missing binary: DEP/0.0.1@company/latest:76777cd535eb9e2203d7321abd74929798755a4f

DEP/0.0.1@company/latest: WARN: Can't find a 'DEP/0.0.1@company/latest' package for the specified settings, options and dependencies:
- Settings: arch=armv8, build_type=Release, compiler=gcc, compiler.libcxx=libstdc++11, compiler.version=10, os=Linux
- Options: fPIC=True, shared=False
- Dependencies: 
- Requirements: 
- Package ID: 76777cd535eb9e2203d7321abd74929798755a4f
```
user: antoinebardoz
labels: component: ux: No changes to core business logic
issue_14725: state: open
title: [question] Conan with Visual Studio
body: ### What is your question?

I would like to make a Conan install of my Visual Studio solution. 
I tried to make the conan install from a powershell script which is launched when we start a build. The problem is, when I start Visual Studio with my solution, the script is automaticaly launched by Visual Studio and I don't know why ...

I create an project and add a custom build step which launch my powershell script before a CICompile.

I don't know if this is the good way or not.

Any help/suggest are welcome


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: yekmen
labels: component: Build: Build helpers, build systems..
issue_14724: state: open
title: Feature/premake 
body: **Feature**: Premake5 tool for Conan2

**Changelog**:

I have changed the implementation of the `Premake` tool to properly support the invocation of premake5 based on the conanfile and optional parameters. It's now also possible to directly call build on the `Premake` object. The build function will forward the call based on the OS and target configurations (`MSBuild` on Windows, `XcodeBuild` on OSX and a direkt `make` call on Linux)

The next step for better premake5 support would now be a proper package that exposes the premake5 executable. Maybe it's possible to adapt [the existing one](https://github.com/conan-io/conan-center-index/blob/master/recipes/premake/5.x/conanfile.py) or implement a new one `premake5-prebuild`. I had my issues with the existing one back in conan 1.x days (As it seems the build is not integrating all required resources, and thus the executable was not able to correctly generate project files), and now it's also not even 2.x compatible, and the premake version is outdated. Since premake5 offers a ready-to-use pre-build version for all compatible systems on their homepage, i don't see the point in compiling it on the conan infrastructure. 

**Docs**: 

Please let me know as soon as we can move forward towards documentation and proper support of premake5. Currently, I see the following things holding us back:

- Feedback on what it takes to properly add documented support 
- Premake5 conan2 compatible package on conan-center-index (I will probably try to take a look at this soon) so that preamke5 is not required in the system's path
- Proper unit testing of the `Premake` tool and the `PremakeDeps` generator.
- Documentation of the integration

**Checklist**:

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.
user: Ohjurot
issue_14719: state: open
title: [bug] can't override version conflict in tool_requires
body: ### Environment details

* Operating System+version: Ubuntu 22.04
* Compiler+version: gcc/12.2.0
* Conan version: 2.0.10



### Steps to reproduce

create a file requirements.txt

[tool_requires]
gcc/12.2.0
make/4.3
cmake/3.24.2
gmp/6.3.0

conan install requirements.txt --build missing

### Logs

```

======== Computing dependency graph ========
gmp/6.3.0: Not found in local cache, looking in remotes...
gmp/6.3.0: Checking remote: conancenter
gmp/6.3.0: Downloaded recipe revision f925bd29cb8f70972507c699d681de85
m4/1.4.19: Not found in local cache, looking in remotes...
m4/1.4.19: Checking remote: conancenter
m4/1.4.19: Downloaded recipe revision c1c4b1ee919e34630bb9b50046253d3c
gcc/12.2.0: Not found in local cache, looking in remotes...
gcc/12.2.0: Checking remote: conancenter
gcc/12.2.0: Downloaded recipe revision e2965d35782138942e42af8e7da1faf7
mpc/1.2.0: Not found in local cache, looking in remotes...
mpc/1.2.0: Checking remote: conancenter
mpc/1.2.0: Downloaded recipe revision 3eb7f548f869fd782601e22fcf196a8c
Graph root
    requirements.txt: /requirements.txt
Build requirements
    gcc/12.2.0#e2965d35782138942e42af8e7da1faf7 - Downloaded (conancenter)
    gmp/6.3.0#f925bd29cb8f70972507c699d681de85 - Downloaded (conancenter)
    m4/1.4.19#c1c4b1ee919e34630bb9b50046253d3c - Downloaded (conancenter)
    mpc/1.2.0#3eb7f548f869fd782601e22fcf196a8c - Downloaded (conancenter)
ERROR: Version conflict: mpc/1.2.0->gmp/6.3.0, gcc/12.2.0->gmp/6.2.1.
```

user: AndreyMlashkin
issue_14707: state: open
title: Should `conan cache clean <ref>` remove the local backup files for that reference?
body: Basically the title so we can discuss it at some point:

If a backup only contains that reference in its associated json file, should it be deleted if I run `conan cache clean`?

Edit: Just realized I just tested with the default flags. Maybe -s does that! Will check as soon as I can
user: RubenRBS
issue_14706: state: open
title: Add support for zstd compression
body: Changelog: (Feature): Add support for zstd compression
Docs: Will create one if this PR is acceptable

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

As discussed in issue #648, this change adds zstd support to conan in the following ways:

1. The person or build running `conan upload` can set a config value `core.upload:compression_format = zstd` to upload binaries using zstd instead of gzip.
2. The zstd compression is done entirely in Python using a combination of `tarfile` and `python-zstandard`. Then the file is uploaded as normal.
3. When downloading packages, if a .tar.zst file is encountered, the extraction code uses `tarfile` and `python-zstandard` to extract.
4. Adds a test to cover zstd compression and decompression.

I chose python-zstandard as the library because that is what urllib3 uses. The package has not yet hit 1.0 but urllib3 is a mature package and it says a lot to me that they chose python-zstandard.

I apologize in advance if I'm missing important parts of the developer workflow. If this approach is acceptable, I'll create a docs PR as requested.

Developer docs on all branches say to open pull requests against `develop` but AFAICT that is Conan 1.x. I'm opening this against `develop2` instead because that appears to be Conan 2.x; I hope that's the right thing to do.

user: grossag
issue_14698: state: open
title: [feature] Default for --build
body: ### What is your suggestion?

Apologies in advance, I'm pretty sure I read a similar issue to this asking about `core.package_id:default_build_mode` where it was pointed out that that only applies to the package itself, not its deps, but I can't find it now. I don't think #14222 is it...

Anyway: a way to specify `--build=missing` as default behaviour (to save typing again...), but I can't see a way.

I have a feeling wherever I read a similar request concluded with it not being something that was going to be implemented, but thought I'd ask.

If not currently possible and viable, I'm happy to have a go. Quick initial hack https://github.com/lukester1975/conan/commit/24e3248195d53d5795bbb7dc732793a2d781eb09 but aside from the factoring out, probably needs thought about it being a list (or maybe the conf option should just support one value).

Thanks


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: lukester1975
issue_14691: state: open
title: [question] New MakeDeps generator and transitive dependencies
body: ### What is your question?

To illustrate the problem consider the following conanfile.txt:
```
[requires]
cairo/1.17.4
```
For it `conan install . -g MakeDeps` generates the following fragment:
```
# cairo/1.17.4
CONAN_NAME_CAIRO = cairo
CONAN_VERSION_CAIRO = 1.17.4
CONAN_REFERENCE_CAIRO = cairo/1.17.4
CONAN_ROOT_CAIRO = D:/.conan2/b/cairo1902eee45304e/p

CONAN_INCLUDE_DIRS_CAIRO = $(CONAN_INCLUDE_DIR_FLAG)$(CONAN_ROOT_CAIRO)/include

CONAN_LIB_DIRS_CAIRO = $(CONAN_LIB_DIR_FLAG)$(CONAN_ROOT_CAIRO)/lib
...
```
Why CONAN_INCLUDE_DIRS_CAIRO doesn't include dependencies include dirs?

Of course, the problem is not specific to cairo package. MakeDeps never includes transitive dependencies to CONAN_INCLUDE_DIRS_pkg, CONAN_LIB_DIRS_pkg, CONAN_LIBS_pkg etc.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: db4
issue_14690: state: open
title: [question] ERROR: Missing prebuilt package for boost/1.71.0…
body: ### What is your question?

Hello,
I am trying to set up a C++ repository for vivoka. For this I need Conan and a version lower than 2.0. I installed it according to the documentation, but when I run the compiler I always get the error 'Still the error:
ERROR: Missing prebuilt package for boost/1.71.0@vivoka/customer',
*vsdk/8.0.0@vivoka/customer,
*vsdk-csdk/4.0.1@vivoka/customer',
use conan search boost/1.71.00vivoka/customer --table-table.html
vsdk-exception/1.2.6@vivoka/customer
-p=remote
and open the file table.html to see the available packages
Or try building locally from source with '--build-boost --build=vsdk --build=vsdk-csdk --build=vsdk-exception'.
More info at https://docs.conanio/en/latest/faq/troubleshooting-html#error-missing-prebuilt-package'". Every conceivable attempt to fix the error has failed so far.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: LukasBecks
issue_14683: state: open
title: [question] How to generate merged CppInfo data (libs, libdirs etc.) for a given package component? (Conan 2.0)
body: ### What is your question?

Say, I require "opencv/4.5.3" and need to fully resolve `includedirs`, `libs`, and `libdirs` for `opencv::opencv_imgproc` component. For the entire dependency, it's quite easy: ~~`cpp_info = self.dependencies["opencv"].cpp_info.aggregated_components()`~~
Edit: not exactly, see the corrected code below.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: db4
issue_14680: state: open
title: [question] Add own toolchain file into generator
body: ### What is your question?

Hi everyone,

this might be a stupid question, but I did not find the correct answer yet in the documentation.
I am using Conan 1.60.2 with tool packages that contain an own toolchain file. When I use now the toolchain file generator, it is also picking all of them up, adding them as an include to the `conan_toolchain.cmake`. 
Depending now on the compiler used (I have one for static testing and one for the native build) I want to add here 1 of 2 additional toolchain files to the `conan_toolchain.cmake`.
Is this an intended usecase?
How can I do that?

Thanks in advance

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: KarstenErnert
issue_14669: state: open
title: [bug] conan remote auth doesn't recognise if user is unauthenticated
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: N/A
* Conan version: 2.0.9
* Python version: 3.9.7


### Steps to reproduce

1. Log in to Artifactory
2. Wait for auth to expire (30 days?)
3. `conan remote auth remote_name`

### Logs

```sh
$ conan remote auth remote-name
remote-name:
    user: me@example.com
(error code = 0)
```

I would expect:
- Some indication that the user isn't authenticated
- A non-zero return code

The `list-users` command correctly flags that the user isn't authenticated:
```sh
$ conan remote list-users
remote-name:
  Username: me@example.com
  authenticated: False
```
user: PeteAudinate
issue_14651: state: open
title: [question] Xcode Not showing header suggestions 
body: ### Xcode not showing header suggestions in project 

Hey! I believe I might be doing something wrong. 

[DESCLAMER: THIS IS MY FIRST TIME USING CONAN, AND I ALSO AM A JUNIOR DEV] 

## Trying to build a basic rendering engine that can build both on Visual Studio and Xcode, and later I want to expand it to other editors if necessary. 

for some reason, I don't get header suggestions for Xcode but on visual studio it's fine. 

my Conan file is done like this 

```python
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMake, cmake_layout

class VulkanGFXConan(ConanFile):
    name = "Cross-Platform-VulkanGFX"
    version = "0.0.1b"
    settings = "os", "compiler", "build_type", "arch"
    requires = [
        "vulkan-loader/1.3.239.0",
        "glm/cci.20230113",
        "glfw/3.3.8"
    ]
    generators = "CMakeDeps", "CMakeToolchain" 

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package_info(self):
        self.cpp_info.includedirs = ["include", "other_include"]

    def build_requirements(self):
        self.tool_requires("cmake/3.22.6") 
  ```
        
  and my CMakeLists.txt is 
  ```
        # Set Minimum requirements for the project 
cmake_minimum_required(VERSION 3.5)

cmake_policy(SET CMP0091 NEW)
cmake_policy(SET CMP0048 NEW)

# Set the project name
project(Cross-Platform-VulkanGFX VERSION 0.1.0)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_EXTENSIONS OFF)

# Set the include directories via conan dependencies
include(${CMAKE_BINARY_DIR}/conan_toolchain.cmake)

# Recursively find all source files
file(GLOB_RECURSE SOURCE_FILES ${CMAKE_SOURCE_DIR}/Source/*.cpp ${CMAKE_SOURCE_DIR}/Source/*.h ${CMAKE_SOURCE_DIR}/Source/*.hpp)

# Use the natural file system in Xcode
source_group(TREE "${CMAKE_SOURCE_DIR}/Source" PREFIX "Source" FILES ${SOURCE_FILES})

# Include dependencies from Conan
list(APPEND CMAKE_MODULE_PATH ${CMAKE_BINARY_DIR})
find_package(Vulkan REQUIRED)
find_package(glm REQUIRED)
find_package(glfw3 REQUIRED)

set(CMAKE_SKIP_RPATH TRUE)

# Add executable
add_executable(Cross-Platform-VulkanGFX ${SOURCE_FILES})

# Set C++ standard
# set_property(TARGET Cross-Platform-VulkanGFX PROPERTY CXX_STANDARD 11)

# set Cross-Platform-VulkanGFX as the startup project
set_property(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY VS_STARTUP_PROJECT Cross-Platform-VulkanGFX)

# Link Conan libraries
target_link_libraries(${PROJECT_NAME} PUBLIC Vulkan::Vulkan glm::glm glfw)
target_compile_features(${PROJECT_NAME} PUBLIC cxx_std_11)
target_include_directories(${PROJECT_NAME} PUBLIC ${CMAKE_SOURCE_DIR}/Source)
``` 

for some reason, my XCode headers don't show up in the suggestions but work well on visual studio on Windows. I have no idea what I am doing wrong. 

This is my repo and the commands I am running are here 
https://github.com/jaibeer72/VulkanGFX/blob/main/MakeProject.sh 



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jaibeer72
issue_14649: state: open
title: [question] profile environment not applied for conan run
body: ### What is your question?

Attempting to build qt on Linux I was greeted with an invalid configuration referencing conan-io/conan-center-index#13472 alongside the suggestion to set an environment variable.
I tried setting said environment variable in the profile used, however conan still throws the InvalidConfigurationError from the qt recipe.

Isn't the `[env]` section of profiles supposed to apply to conan runs? If not then when and where are those environment variables applied to?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Sil3ntStorm
issue_14648: state: open
title: [question] CMakeFiles/zlib.dir/all] Error 2
body: ### What is your question?

I'm trying to cross-compile zlib from `os=Linux` to `os=Windows` using Clang in Conan 2.
This is my profile:
```
[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=gnu14
compiler.libcxx=libstdc++11
compiler.version=10
os=Windows

[conf]
tools.build:compiler_executables = {'c':'/usr/bin/clang','cpp':'/usr/bin/clang++'}
tools.build:cflags = ['--target=x86_64-w64-mingw32','-fuse-ld=/usr/bin/x86_64-w64-mingw32-ld','-v']
tools.build:cxxflags = ['--target=x86_64-w64-mingw32','-fuse-ld=/usr/bin/x86_64-w64-mingw32-ld','-v']

[buildenv]
{% set mingw="x86_64-w64-mingw32" %}
CHOST={{mingw}}
AR={{mingw}}-ar
AS={{mingw}}-as
RANLIB={{mingw}}-ranlib
CC={{mingw}}-gcc
CXX={{mingw}}-g++
STRIP={{mingw}}-strip
RC={{mingw}}-windres
```
When i run `conan create` , i encountered a problem :
```
...
ignoring nonexistent directory "clang -cc1 version 10.0.0/usr/x86_64-w64-mingw32/sys-root/mingw/includeclang -cc1 version 10.0.0 based upon "
clang -cc1 version 10.0.0 based upon LLVM 10.0.0 based upon LLVM 10.0.0 default target #include "..." search starts here:
LLVM 10.0.0 default target x86_64-pc-linux-gnu#include <...> search starts here:
 default target 
x86_64-pc-linux-gnu x86_64-pc-linux-gnu
/root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release
ignoring nonexistent directory "
/usr/x86_64-w64-mingw32/sys-root/mingw/include "
/root/.conan2/p/b/zliba6cf76b385bf5/b/src
 /usr/lib/llvm-10/lib/clang/10.0.0/include
ignoring nonexistent directory " #include "..." search starts here:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/usr/x86_64-w64-mingw32/include#include <...> search starts here:
ignoring nonexistent directory ""

 /usr/x86_64-w64-mingw32/sys-root/mingw/include /root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release"
/usr/include#include "..." search starts here:


#include <...> search starts here:
 End of search list.
#include "..." search starts here:
 /root/.conan2/p/b/zliba6cf76b385bf5/b/src#include <...> search starts here:
/root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release
 
 /root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release /usr/lib/llvm-10/lib/clang/10.0.0/include
/root/.conan2/p/b/zliba6cf76b385bf5/b/src
 
 /root/.conan2/p/b/zliba6cf76b385bf5/b/src /usr/x86_64-w64-mingw32/include
/usr/lib/llvm-10/lib/clang/10.0.0/include
ignoring nonexistent directory " 
 /usr/x86_64-w64-mingw32/sys-root/mingw/include/usr/lib/llvm-10/lib/clang/10.0.0/include ignoring nonexistent directory "/usr/include"

/usr/x86_64-w64-mingw32/include/usr/x86_64-w64-mingw32/sys-root/mingw/include
 
"
End of search list.
#include "..." search starts here:
/usr/x86_64-w64-mingw32/include #include <...> search starts here:

#include "..." search starts here:
/usr/include  #include <...> search starts here:

/root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release/usr/include End of search list.


/root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release End of search list.

/root/.conan2/p/b/zliba6cf76b385bf5/b/src 
/root/.conan2/p/b/zliba6cf76b385bf5/b/src 
/usr/lib/llvm-10/lib/clang/10.0.0/include 
/usr/lib/llvm-10/lib/clang/10.0.0/include 
/usr/x86_64-w64-mingw32/include 
/usr/x86_64-w64-mingw32/include 
/usr/include 
/usr/includeEnd of search list.

End of search list.
ignoring nonexistent directory "ignoring nonexistent directory "/usr/x86_64-w64-mingw32/sys-root/mingw/include/usr/x86_64-w64-mingw32/sys-root/mingw/include"
"
ignoring nonexistent directory "/usr/x86_64-w64-mingw32/sys-root/mingw/include"
#include "..." search starts here:
#include "..." search starts here:
#include <...> search starts here:
#include <...> search starts here:
 #include "..." search starts here:
 /root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release#include <...> search starts here:
/root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release
 
 /root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release /root/.conan2/p/b/zliba6cf76b385bf5/b/src
/root/.conan2/p/b/zliba6cf76b385bf5/b/src
 
 /root/.conan2/p/b/zliba6cf76b385bf5/b/src /usr/lib/llvm-10/lib/clang/10.0.0/include
/usr/lib/llvm-10/lib/clang/10.0.0/includeignoring nonexistent directory "
 
/usr/x86_64-w64-mingw32/sys-root/mingw/include ignoring nonexistent directory "ignoring nonexistent directory "/usr/lib/llvm-10/lib/clang/10.0.0/include "
/usr/x86_64-w64-mingw32/include/usr/x86_64-w64-mingw32/sys-root/mingw/include/usr/x86_64-w64-mingw32/sys-root/mingw/include
/usr/x86_64-w64-mingw32/include
"
"
 #include "..." search starts here:

 /usr/x86_64-w64-mingw32/include#include <...> search starts here:
 /usr/include#include "..." search starts here:
#include "..." search starts here:

 /usr/include
#include <...> search starts here:
#include <...> search starts here:
 /root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release
End of search list.
  /usr/include
End of search list.
/root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release/root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release
 

End of search list.
/root/.conan2/p/b/zliba6cf76b385bf5/b/src  
/root/.conan2/p/b/zliba6cf76b385bf5/b/src/root/.conan2/p/b/zliba6cf76b385bf5/b/src 

/usr/lib/llvm-10/lib/clang/10.0.0/include  
/usr/lib/llvm-10/lib/clang/10.0.0/include/usr/lib/llvm-10/lib/clang/10.0.0/include 

/usr/x86_64-w64-mingw32/include  
/usr/x86_64-w64-mingw32/include/usr/x86_64-w64-mingw32/include 

/usr/include  
/usr/include/usr/includeEnd of search list.


End of search list.
End of search list.
[ 78%] Linking C static library libzlibstatic.a
make[1]: *** [CMakeFiles/Makefile2:221: CMakeFiles/zlib.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 78%] Built target zlibstatic
make: *** [Makefile:141: all] Error 2
...
```
I suspect it could be an issue with `windres`. [For reference, `windres` cannot handle spaces in include paths either. This is known by CMake's test suite](https://gitlab.kitware.com/cmake/cmake/-/issues/22479). We can see spaces in the output log.:
```
/usr/x86_64-w64-mingw32/sys-root/mingw/include /root/.conan2/p/b/zliba6cf76b385bf5/b/build/Release"
/usr/include#include "..." search starts here:
```
But when i use gcc as the compiler, `windres` works well.
Do you have any experience with this issue? 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: BrainLyh
issue_14647: state: open
title: Windows bash using WSL2
body: Conan has some support for using WSL as the subsystem for bash on Windows. The configuration value `tools.microsoft.bash:subsystem=wsl` is recognised and is at least partly implemented. I tested this using WSL2.

List of issues found while testing the `libiconv` package build:
* https://github.com/conan-io/conan/blob/develop2/conans/client/subsystems.py#L105
  Here the use of MSYS is assumed. While using WSL, the correct options would be something like `-e bash -- -c`.
* In the generated conanbuild environment scripts some absolute paths such as `script_folder` use Windows paths (`C:/...`) instead of the corresponding WSL paths (`/mnt/c/...`).
* In WSL Windows executables such as `cl.exe`, despite being in path, are not found using the name `cl` without the extension as they are on Windows. Perhaps generating forwarding scripts in a separate directory and appending that directory to path could solve this issue neatly.

There are still more issues that I was not yet able to work around. I will update this issue if I do.
user: vasama
issue_14632: state: open
title: [bug] conan removes duplicated entries from self.cpp_info.components[""].libs
body: ### Environment details

* Operating System+version: macOS 13.x
* Compiler+version: clang (arm64-apple-darwin22.6.0)
* Conan version: 2.0.9
* Python version: 3.11


### Steps to reproduce

We have a product with plugin architecture where `CORE` library can load `PLUGIN_A`, `PLUGIN_B` in runtime.
Our product can also be built for static libraries configuration. In this case, `CORE` library explicitly have entry points `ENTRY_POINT_A`, `ENTRY_POINT_B` which references to symbols in `PLUGIN_A`, `PLUGIN_B` respectively. 

In this case, when users statically links with `CORE`, it statically depends on `PLUGIN_A` and `PLUGIN_B` and can create their instances via those symbols. Also note, that some common functionality is used by `PLUGIN_A` and `PLUGIN_B` from `CORE` library. So, we have a cyclic dependency here and cmake can perfectly export such targets (`install(EXPORT ..)`) and they are used by 3rd party projects.

But with Conan I cannot resolve such scheme with cyclic dependencies, because I have to fill `self.cpp_info.components["CORE"].libs` with `["CORE", "PLUGIN_A", "PLUGIN_B", "CORE"]`, but last `"CORE"` is removed by Conan for some reason. Why does Conan do it?

Last `"CORE"` is required, because `"CORE"` simply speaking contains of two parts: user API and developer API. First one represent set of symbols used by public users, developer API is for `PLUGIN_<x>`s. And during static linkage, developer API is removed by linker, because it's not used by final application and we have unresolved symbols in `PLUGIN_A` and `PLUGIN_B`. So, last `"CORE"` is required to resolve those symbols for `PLUGINS_<x>`s. And cmake generates similar sequence where `CORE` is faced multiple times in linker command.

Could you please remove filtering out of duplicated libraries, because it's really required for cyclic dependencies?

### Logs

N/A
user: ilya-lavrenov
issue_14629: state: open
title: Not able to create a conan package from a reference folders as source
body: ### What is your question?

I am trying to create a conan package from a third party library(boost). I am not trying to build the entire boost here, rather just package the header files as only those are used in most of our projects. Hence I want to package the boost directly as it is. I have the boost downloaded and extracted it into a folder. The extracted folder structure looks like this:

C:\Users\xxxxx\Downloads\source\third_party\boost_1_70_0\boost\accumulators.....(many sub folders and files)

I want to create a package with only the contents from the 'boost' folder. I have already tried a recipe but for some reason it copies the folder from 'third_party'.

The conan recipe(conanfile.py) is at the same level as that of 'third_party'.

I am new to conan so there might be something that I am missing.

Below is the recipe.

```
from conan import ConanFile
from conan.tools.files import copy
import os

class BoostRecipe(ConanFile):
    name = "boost"
    version = "1.70.0"

    # Optional metadata
    license = "xxx"
    author = "xxx"
    url = "xxx"
    description = "C++ interface to the boost library."

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}

    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "contents/boost_1_70_0/*"
    
    def layout(self):
        self.folders.source = "contents/boost_1_70_0"

    def package(self):
        copy(self, pattern="*", dst="boost", src=self.folders.source, keep_path=False)

    def package_info(self):
        self.cpp_info.libs = ["Boost"]
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sandybhat16
issue_14628: state: open
title: can't build flex with intel oneapi
body: ### Environment details

* Operating System+version: ubuntu 2204
* Compiler+version: intel oneapi 2023.2.1
* Conan version: 1.57.0
* Python version: 3.10.6

conan profile:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=intel-cc
compiler.libcxx=libstdc++11
compiler.mode=dpcpp
compiler.version=2021.3
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
CC=/opt/intel/oneapi/compiler/2023.2.1/linux/bin/icx
CXX=/opt/intel/oneapi/compiler/2023.2.1/linux/bin/icpx
[conf]
tools.intel:installation_path=/opt/intel/oneapi
tools.intel:setvars_args=--force

ERROR:
flex/2.6.4: Copying sources to build folder
flex/2.6.4: Building your package in /home/pqy/.conan/data/flex/2.6.4/_/_/build/e31da26cd5dad39490668f9df7d1c39762739b22
flex/2.6.4: Generator txt created conanbuildinfo.txt
flex/2.6.4: Calling generate()
ERROR: flex/2.6.4: Error in generate() method, line 71
        at.generate()
        TypeError: can only concatenate list (not "str") to list

### Steps to reproduce

_No response_

### Logs

_No response_
user: tufeigunchu
issue_14624: state: open
title: [feature] Aggregate duplicate directories for components when using `MSBuildDeps` generator
body: ### What is your suggestion?

Hi there,

One slight annoyance I've noticed since updating our private recipes to use the new `MSBuildDeps` generator is that when a requirement that provides multiple components such as `boost` is used, it will lead to MSBuild using duplicated directories for the includes, libdirs etc of each component in the package (assuming that you're including the generated `conandeps.props` in the project). 

While this doesn't cause any functional issues, it is quite spammy in build logs and other places within Visual Studio that display such AdditionalIncludeDirectories etc e.g.

```C:\BuildTools\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\CL.exe /c /IC:\work\src\ /I"C:/.conan2/p/g-tes30877b48c0cd3/p/include" /I"C:/.conan2/p/g-tes30877b48c0cd3/p/include/googlemock/include" /I"C:/.conan2/p/g-tes30877b48c0cd3/p/include/googletest/include" /IC:/.conan2/p/webso4cd9b92a77bce/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/booste13af8dfe6c0b/p/include /IC:/.conan2/p/zlib0c4591880ed8f/p/include /IC:/.conan2/p/opens3e5919e9ca0df/p/include /IC:/.conan2/p/opens3e5919e9ca0df/p/include /I"C:/.conan2/p/ssl-w90b4489a3701b/p/include" /IC:/.conan2/p/rapidcba706a2b9d1d/p/include/include /IC:/.conan2/p/micro24db803c0d533/p/include```

Evidently this occurs because an individual props file is generated for each component of `boost` and they are all declaring the same additive values for `<AdditionalIncludeDirectories/>` etc.

I don't know if there's any possibility to prevent this e.g. via aggregation using the [Distinct item functions](//learn.microsoft.com/en-us/visualstudio/msbuild/item-functions) or maybe adding a [Condition](https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditions?view=vs-2022) which checks if the path already exists in the target property?

It's a minor niggle, but would be nice if there was a cleaner implementation.

Thanks!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: santhonisz
labels: component: Build: Build helpers, build systems..
issue_14618: state: open
title: [workspaces] - cant generate graph - "not found in cache"
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: Visual Studio 2022
* Conan version: 1.60.2
* Python version: 3.11


### Steps to reproduce

1. Using the example Workspace folder from the example github repo, leverage workspaces to amend large number of dependencies and consumer repository more easily.
2. After running `conan install ... ` successfully, ensure that packages have been created as expected.
3. Try to generate a graph of the workspace consumer package by using `conan info . --graph=blah.dot`

This may not be a bug but rather a feature; since this capability might need to be implemented within the "workspace" area (since its purpose is to not build packages into cache) 

### Logs

Not found in local cache, looking in remotes...
Unable to find '' in remotes
user: timmay54
issue_14617: state: open
title: [feature] consider adding ability to specify override in conanfile.txt
body: ### What is your suggestion?

Ability to specify `,override=True` in a dependency in `conanfile.txt`, to allow an override to resolve a conflict, without encoding a direct dependency


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: jcar87
issue_14613: state: open
title: [question] Ignore local cache when creating lock file
body: ### What is your question?

I see that `conan lock create` has option `--no-remote` which prevents the use of the remote and resolves exclusively in the cache. But is there a way to exclusively use remotes, without a local cache?

I see that even by defining specific remotes the local cache is consulted. This is problematic as a developer who is working on updating the lock file may have local packages that don't exist in the remote and then the lock file is generated with respect to them. When such a lock file is then used on the CI or by other developers, conan fails because it can't resolve locked recipe IDs.

Note: I'm using lock API from a custom command using the code below, but I think the question still remains the same:

```python
    remotes = conan_api.remotes.list()

    graph = conan_api.graph.load_graph_consumer(
        path=conanfile_path,
        name=None,
        version=None,
        user=None,
        channel=None,
        profile_host=profile_host,
        profile_build=profile_build,
        lockfile=None,  # don't use old lockfile as basis
        remotes=remotes,
        update=True,
    )
    if parsed_args.verbose:
        print_graph_basic(graph)
    graph.report_graph_error()

    conan_api.graph.analyze_binaries(
        graph,
        None,
        remotes=remotes,
    )
    if parsed_args.verbose:
        print_graph_packages(graph)
    lockfile = conan_api.lockfile.update_lockfile(
        lockfile=None,  # don't use old lockfile as basis
        graph=graph,
        # only recipe should be locked, not the package ID, which depends on arch, os, and build type
        lock_packages=False,
        clean=True,
    )
```

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: DoDoENT
issue_14611: state: open
title: [question] `tools.gnu:pkg_config` influences CMakeToolchain Generator
body: ### What is your question?

Hey, I'm a bit curious about the following behavior: 

When I set tools.gnu:pkg_config config it is also influencing the CMakeToolchain Generator, in the way that it is adding 

```
set(PKG_CONFIG_EXECUTABLE  ...)
```

to the generated conan_toolchain.cmake.

In the documentation it is not documented, that CMakeToolchain Generator considers the tools.gnu:pkg_config config as well. Furthermore, I'm wondering if this should be the right behavior? From my understanding tools.gnu:pkg_config should only influence the PkgConfig helper and it is at least for me now an unwanted side effect that it also changes the behavior of CMakeToolchain. The reason is that generally the find_package(PkgConfig) and the following module searches are replaced by conan CMakeDeps Find modules in most packages. But sometimes there might be some package-internally used *.pc files which are read during the cmake configuration step and there I don't want to use the pkg-config defined by `tools.gnu:pkg_config` but want to use the default. If someone wants to use a different PkgConfig in CMake context it should be configurable more explicitly in my opinion. Or has it use cases I'm currently missing? 

Thanks a lot!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: nicosmd
issue_14607: state: open
title: [feature] CMakeDeps: define `IMPORTED_LINK_INTERFACE_LANGUAGES` in case of static C++ lib
body: ### What is your suggestion?

Config files generated by `CMakeDeps` have several flaws compared to regular CMake config files generated by CMake.
One of them is that they miss `IMPORTED_LINK_INTERFACE_LANGUAGES "CXX"` property in case of C++ static lib (see also this summary I made in https://github.com/conan-io/conan/issues/13560#issuecomment-1545947074).

When this property is missing, linking a static C++ lib with C API into a pure C executable or shared lib can't work out of the box -while it should with a proper CMake config file (information comes transitively from imported target linked into C executable or shared lib)- because CMake doesn't know that it should use C++ linker.

Currently, package_info() doesn't provide a way to specify which lib in a recipe is a C++ lib, nor if it's static or not (though for this one there is the global shared option, or package_type value eventually but it's not sufficient when there are components which might not be all shared or static), so it's a little bit hard to implement such feature without some improvements in package_info() and an abstraction allowing to specify if a component refers to a C or C++ lib.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: SpaceIm
issue_14606: state: open
title: [bug] conan_package_library_targets does not set IMPORTED_CONFIGURATIONS
body: ### Environment details

* Operating System+version: macOS
* Conan version: 1.60
* Python version: 3.11

### Steps to reproduce

Install TBB with Conan and observe `cmakedeps_macros.cmake` file. It contains 
```cmake
function(conan_package_library_targets libraries package_libdir deps_target out_libraries_target config_suffix package_name)
    set(_out_libraries_target "")

    foreach(_LIBRARY_NAME ${libraries})
        find_library(CONAN_FOUND_LIBRARY NAMES ${_LIBRARY_NAME} PATHS ${package_libdir}
                     NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
        if(CONAN_FOUND_LIBRARY)
            message(VERBOSE "Conan: Library ${_LIBRARY_NAME} found ${CONAN_FOUND_LIBRARY}")

            # Create a micro-target for each lib/a found
            # Allow only some characters for the target name
            string(REGEX REPLACE "[^A-Za-z0-9.+_-]" "_" _LIBRARY_NAME ${_LIBRARY_NAME})
            set(_LIB_NAME CONAN_LIB::${package_name}_${_LIBRARY_NAME}${config_suffix})
            if(NOT TARGET ${_LIB_NAME})
                # Create a micro-target for each lib/a found
                add_library(${_LIB_NAME} UNKNOWN IMPORTED)
            endif()
            # Link library file
            set_target_properties(${_LIB_NAME} PROPERTIES IMPORTED_LOCATION${config_suffix} ${CONAN_FOUND_LIBRARY})
            list(APPEND _out_libraries_target ${_LIB_NAME})
            message(VERBOSE "Conan: Found: ${CONAN_FOUND_LIBRARY}")
        else()
            message(FATAL_ERROR "Library '${_LIBRARY_NAME}' not found in package. If '${_LIBRARY_NAME}' is a system library, declare it with 'cpp_info.system_libs' property")
        endif()
        unset(CONAN_FOUND_LIBRARY CACHE)
    endforeach()

    # Add the dependencies target for all the imported libraries
    foreach(_T ${_out_libraries_target})
        set_property(TARGET ${_T} PROPERTY INTERFACE_LINK_LIBRARIES ${deps_target} APPEND)
    endforeach()

    set(${out_libraries_target} ${_out_libraries_target} PARENT_SCOPE)
endfunction()
```
Which sets `IMPORTED_LOCATION_<config>`, but does not set `IMPORTED_CONFIGURATIONS`. 

As a I users, sometimes I need an access to library location. So, I have to understand imported configurations and then take appropriate `IMPORTED_LOCATION_<config>`, but Conan does not do it.

It's a good practice to set this property (done by cmake automatically)

### Logs

_No response_
user: ilya-lavrenov
issue_14604: state: open
title: [bug] $<TARGET_RUNTIME_DLLS:tgt> doesn't work with GLFW: 'Cannot locate shared library: glfw3dll'
body: ### Environment details

* Operating System+version: Windows 10
* Compiler+version: Visual Studio 2022
* Conan version: 2.0.9
* Python version: 3.10.4


### Steps to reproduce

Create a simple project with `conanfile.txt` as follows:
```
[requires]
glfw/3.3.8
libusb/1.0.26

[generators]
CMakeDeps
CMakeToolchain

[options]
glfw/*:shared=True
libusb/*:shared=True
```
CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.22)


set(CMAKE_CXX_STANDARD 20 CACHE STRING "C++ standard")
set(CMAKE_CXX_STANDARD_REQUIRED on)

project(Conantest VERSION 1.0 DESCRIPTION "Conantest")

set_property(GLOBAL PROPERTY USE_FOLDERS ON)

find_package(glfw3 CONFIG REQUIRED)
find_package(libusb CONFIG REQUIRED)

add_executable(Conantest
    "app.cpp"
)

set_target_properties(Conantest PROPERTIES OUTPUT_NAME "Conantest")

target_link_libraries(Conantest glfw libusb::libusb)

install(TARGETS Conantest DESTINATION "Conantest")
install(FILES $<TARGET_RUNTIME_DLLS:Conantest> DESTINATION "Conantest")
```
Build it:
```sh
conan install . --output-folder=build --build=missing -s build_type=Release
cd build
cmake .. -G "Visual Studio 17 2022" --debug-output --preset conan-default
cmake --build . --target ALL_BUILD --config Release
cmake --install . --prefix install
```
CMake outputs a warning:
```
-- Cannot locate shared library: glfw3dll
   Called from: [5]     .../build/cmakedeps_macros.cmake
                [4]     .../build/glfw3-Target-release.cmake
                [3]     .../build/glfw3Targets.cmake
                [2]     .../build/glfw3-config.cmake
                [1]     .../CMakeLists.txt
```

The generated `build/cmake_install.cmake` will also not contain any mention of the `glfw3.dll` file, but it will contain an installation command for `libusb-1.0.dll`. The installation directory contains the libusb DLL, but not the glfw one, even though it *is* available in `~/.conan2`.

I guess this is because the glfw DLL is called `glfw3.dll` while the import library is called `glfw3dll.lib`. The [glfw recipe](https://github.com/conan-io/conan-center-index/blob/522a8f740a09a37a75ec02adf55b54b16cacb7a5/recipes/glfw/all/conanfile.py#L136) defines one `glfw3dll` library in `cpp_info`.

### Logs

_No response_
user: Erlkoenig90
issue_14603: state: open
title: [feature] add possibility to check if MFC and ATL modules of MSVC are installed
body: ### What is your suggestion?

relates to https://github.com/conan-io/conan-center-index/issues/19415

Some libs may require MFC or ATL support on MSVC. It would be good to have a possibility to check if these modules are installed in validate() method

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: AndreyMlashkin
issue_14598: state: open
title: [question] Unable to build crc32c: c1xx: fatal error C1083: Cannot open source file: '': No such file or directory
body: ### What is your question?

Hi,

I'm unable to cross-compile https://github.com/google/crc32c using MSVC. However, normal build without Conan works

Steps
1. Create conanfile.py from below
2. run `conan source .`
3. run `conan install . -pr:h /workspace/conan/profiles/msvc-x64 -pr:b default`
4. `conan build .`

Output
```
-- Using Conan toolchain: /root/crc32c/build/Release/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 17 with extensions OFF
-- The C compiler identification is MSVC 19.29.30133.0
-- The CXX compiler identification is MSVC 19.29.30133.0
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Searching 16 bit integer - Using unsigned short
-- Check if the system is big endian - little endian
-- Performing Test CRC32C_HAVE_NO_DEPRECATED
-- Performing Test CRC32C_HAVE_NO_DEPRECATED - Failed
-- Performing Test CRC32C_HAVE_NO_SIGN_COMPARE
-- Performing Test CRC32C_HAVE_NO_SIGN_COMPARE - Failed
-- Performing Test CRC32C_HAVE_NO_UNUSED_PARAMETER
-- Performing Test CRC32C_HAVE_NO_UNUSED_PARAMETER - Failed
-- Performing Test CRC32C_HAVE_NO_MISSING_FIELD_INITIALIZERS
-- Performing Test CRC32C_HAVE_NO_MISSING_FIELD_INITIALIZERS - Failed
-- Performing Test HAVE_BUILTIN_PREFETCH
-- Performing Test HAVE_BUILTIN_PREFETCH - Failed
-- Performing Test HAVE_MM_PREFETCH
-- Performing Test HAVE_MM_PREFETCH - Failed
-- Performing Test HAVE_SSE42
-- Performing Test HAVE_SSE42 - Failed
-- Performing Test HAVE_ARM64_CRC32C
-- Performing Test HAVE_ARM64_CRC32C - Failed
-- Performing Test HAVE_STRONG_GETAUXVAL
-- Performing Test HAVE_STRONG_GETAUXVAL - Failed
-- Performing Test HAVE_WEAK_GETAUXVAL
-- Performing Test HAVE_WEAK_GETAUXVAL - Failed
-- Configuring done
-- Generating done
-- Build files have been written to: /root/crc32c/build/Release
conanfile.py (crc32c/1.1.2): CMake command: cmake --build "/root/crc32c/build/Release" '--' '-j12'
[ 20%] Building CXX object CMakeFiles/crc32c_arm64.dir/src/crc32c_arm64.cc.obj
[ 40%] Building CXX object CMakeFiles/crc32c_sse42.dir/src/crc32c_sse42.cc.obj

c1xx: fatal error C1083: Cannot open source file: '': No such file or directory
crc32c_sse42.cc
Generating Code...
make[2]: *** [CMakeFiles/crc32c_sse42.dir/build.make:76: CMakeFiles/crc32c_sse42.dir/src/crc32c_sse42.cc.obj] Error 2
make[2]: *** Deleting file 'CMakeFiles/crc32c_sse42.dir/src/crc32c_sse42.cc.obj'
make[1]: *** [CMakeFiles/Makefile2:113: CMakeFiles/crc32c_sse42.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

c1xx: fatal error C1083: Cannot open source file: '': No such file or directory
crc32c_arm64.cc
Generating Code...
make[2]: *** [CMakeFiles/crc32c_arm64.dir/build.make:76: CMakeFiles/crc32c_arm64.dir/src/crc32c_arm64.cc.obj] Error 2
make[2]: *** Deleting file 'CMakeFiles/crc32c_arm64.dir/src/crc32c_arm64.cc.obj'
make[1]: *** [CMakeFiles/Makefile2:87: CMakeFiles/crc32c_arm64.dir/all] Error 2
make: *** [Makefile:124: all] Error 2
ERROR: conanfile.py (crc32c/1.1.2): Error in build() method, line 36
	cmake.build()
	ConanException: Error 2 while executing cmake --build "/root/crc32c/build/Release" '--' '-j12'
```

The problem comes from `HAVE_MM_PREFETCH - Failed` and `HAVE_SSE42 - Failed`. When building without Conan, they were both `Success`.


Conan file
```
from conan import ConanFile
from conan.tools.cmake import CMake, CMakeToolchain, cmake_layout
from conan.tools.scm import Git


class crc32cConan(ConanFile):
    name = "crc32c"
    description = "CRC32C implementation with support for CPU-specific acceleration instructions"
    topics = ("crc32c", "crc")
    homepage = "https://github.com/google/crc32c"
    license = "BSD-3-Clause"

    version = "1.1.2"

    package_type = "library"
    settings = "os", "arch", "compiler", "build_type"

    def layout(self):
        cmake_layout(self)

    def source(self):
        git = Git(self)
        git.clone(url="https://github.com/google/crc32c", args=[f"--branch {self.version}", "--depth 1"])

    def generate(self):
        tc = CMakeToolchain(self)
        tc.variables["CRC32C_BUILD_TESTS"] = False
        tc.variables["CRC32C_BUILD_BENCHMARKS"] = False
        tc.variables["CRC32C_INSTALL"] = True
        tc.variables["CRC32C_USE_GLOG"] = False
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure(build_script_folder="crc32c")
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()

    def package_info(self):
        self.cpp_info.set_property("cmake_file_name", "Crc32c")
        self.cpp_info.set_property("cmake_target_name", "Crc32c::crc32c")
```

msvc-x64
```
[settings]
os=Windows
arch=x86_64
# Clang is only used as a placeholder, since we are hacking for cross-compiling
compiler=clang
compiler.libcxx=libstdc++11
compiler.cppstd=17
compiler.version=10
build_type=Release

[options]

[tool_requires]
toolchain_msvc-x64/0.1.0

[conf]
tools.env.virtualenv:auto_use=True

[buildenv]
CXXFLAGS="/EHsc"
```

toolchain `toolchain_msvc-x64`
```
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_VERSION 10.0)
set(CMAKE_SYSTEM_PROCESSOR AMD64)

set(MSVC_BASE "/opt/msvc/vc/tools/msvc")
set(MSVC_VER "14.29.30133")
set(WINSDK_BASE "/opt/msvc/kits/10")
set(WINSDK_VER "10.0.19041.0")
set(WINSDK_ARCH "x64")

set(MSVC_INCLUDE "${MSVC_BASE}/${MSVC_VER}/include")
set(MSVC_LIB "${MSVC_BASE}/${MSVC_VER}/lib")
set(WINSDK_INCLUDE "${WINSDK_BASE}/include/${WINSDK_VER}")
set(WINSDK_LIB "${WINSDK_BASE}/lib/${WINSDK_VER}")

if(NOT EXISTS "${MSVC_BASE}" OR
   NOT EXISTS "${MSVC_INCLUDE}" OR
   NOT EXISTS "${MSVC_LIB}")
  message(SEND_ERROR
          "CMake variable MSVC_BASE must point to a folder containing MSVC "
          "system headers and libraries")
endif()

if(NOT EXISTS "${WINSDK_BASE}" OR
   NOT EXISTS "${WINSDK_INCLUDE}" OR
   NOT EXISTS "${WINSDK_LIB}")
  message(SEND_ERROR
          "CMake variable WINSDK_BASE and WINSDK_VER must resolve to a valid "
          "Windows SDK installation")
endif()

if(NOT EXISTS "${WINSDK_INCLUDE}/um/windows.h")
  message(SEND_ERROR "Cannot find Windows.h")
endif()

set(CMAKE_C_COMPILER "/opt/msvc/bin/${WINSDK_ARCH}/cl" CACHE FILEPATH "")
set(CMAKE_CXX_COMPILER "/opt/msvc/bin/${WINSDK_ARCH}/cl" CACHE FILEPATH "")
set(CMAKE_LINKER "/opt/msvc/bin/${WINSDK_ARCH}/link" CACHE FILEPATH "")
set(CMAKE_RC_COMPILER "/opt/msvc/bin/${WINSDK_ARCH}/rc" CACHE FILEPATH "")

set(CMAKE_C_COMPILER_FORCED TRUE) # forces CMake to skip compiler checks
set(CMAKE_CXX_COMPILER_FORCED TRUE)
set(CMAKE_SIZEOF_VOID_P 8) # sets CMake bitness to 64bit

set(COMPILE_FLAGS
    /I "${MSVC_INCLUDE}"
    /I "${WINSDK_INCLUDE}/ucrt"
    /I "${WINSDK_INCLUDE}/shared"
    /I "${WINSDK_INCLUDE}/um"
    /I "${WINSDK_INCLUDE}/winrt")

string(REPLACE ";" " " COMPILE_FLAGS "${COMPILE_FLAGS}")

# We need to preserve any flags that were passed in by the user. However, we
# can't append to CMAKE_C_FLAGS and friends directly, because toolchain files
# will be re-invoked on each reconfigure and therefore need to be idempotent.
# The assignments to the _INITIAL cache variables don't use FORCE, so they'll
# only be populated on the initial configure, and their values won't change
# afterward.
set(_CMAKE_C_FLAGS_INITIAL "${CMAKE_C_FLAGS}" CACHE STRING "")
set(CMAKE_C_FLAGS "${_CMAKE_C_FLAGS_INITIAL} ${COMPILE_FLAGS} $ENV{CFLAGS}" CACHE STRING "" FORCE)
set(_CMAKE_CXX_FLAGS_INITIAL "${CMAKE_CXX_FLAGS}" CACHE STRING "")
set(CMAKE_CXX_FLAGS "${_CMAKE_CXX_FLAGS_INITIAL} ${COMPILE_FLAGS} $ENV{CXXFLAGS}" CACHE STRING "" FORCE)

set(LINK_FLAGS
    # Prevent CMake from attempting to invoke mt.exe. It only recognizes the slashed form and not the dashed form.
    /manifest:no

    /LIBPATH:"${MSVC_LIB}/${WINSDK_ARCH}"
    /LIBPATH:"${WINSDK_LIB}/ucrt/${WINSDK_ARCH}"
    /LIBPATH:"${WINSDK_LIB}/um/${WINSDK_ARCH}"
    /DEFAULTLIB:user32)

string(REPLACE ";" " " LINK_FLAGS "${LINK_FLAGS}")

# See explanation for compiler flags above for the _INITIAL variables.
set(_CMAKE_EXE_LINKER_FLAGS_INITIAL "${CMAKE_EXE_LINKER_FLAGS}" CACHE STRING "")
set(CMAKE_EXE_LINKER_FLAGS "${_CMAKE_EXE_LINKER_FLAGS_INITIAL} ${LINK_FLAGS}" CACHE STRING "" FORCE)

set(_CMAKE_MODULE_LINKER_FLAGS_INITIAL "${CMAKE_MODULE_LINKER_FLAGS}" CACHE STRING "")
set(CMAKE_MODULE_LINKER_FLAGS "${_CMAKE_MODULE_LINKER_FLAGS_INITIAL} ${LINK_FLAGS}" CACHE STRING "" FORCE)

set(_CMAKE_SHARED_LINKER_FLAGS_INITIAL "${CMAKE_SHARED_LINKER_FLAGS}" CACHE STRING "")
set(CMAKE_SHARED_LINKER_FLAGS "${_CMAKE_SHARED_LINKER_FLAGS_INITIAL} ${LINK_FLAGS}" CACHE STRING "" FORCE)
```

Note that this toolchain works when building other libraries.

Conan 1.5.8

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: cocoza4
issue_14590: state: open
title: [question] Why does CMakeToolchain's `cache_variables` convert recipe options to CMake bool but `variables` converts them to strings?
body: ### What is your question?

Hello,

While exploring the files generated by the CMakeToolchain generator, I realized that when assigning an option to `cache_variables`, it resulted in a CMake `boolean` variable in the `CMakePresets.json`, wherease passing the same option to `variables` generated a CMake `string` variable in the `conan_toolchain.cmake`.

Is there a reason for that difference? I couldn't find anything in the doc about this.

The recipe:
```
from conan import ConanFile
from conan.tools.cmake import CMakeDeps, CMakeToolchain, cmake_layout

class helloRecipe(ConanFile):
    name = "my_lib"
    version = "1.0"

    settings = "os", "compiler", "build_type", "arch"
    options = {"option": [True, False]}
    default_options = {"option": True}
    exports_sources = "CMakeLists.txt", "src/*", "include/*"

    def layout(self):
        cmake_layout(self)

    def generate(self):
        dep = CMakeDeps(self)
        dep.generate()

        tc = CMakeToolchain(self)
        tc.variables["option"] = self.options.get_safe("option")
        tc.cache_variables["option"] = self.options.get_safe("option")
        tc.variables["option2"] = self.options.option
        tc.cache_variables["option2"] = self.options.option
        tc.variables["option3"] = True
        tc.cache_variables["option3"] = True
        tc.generate()
```

The generated CMakePresets.json:
```
...
"cacheVariables": {
  "option": "ON",
  "option2": "ON",
  "option3": "ON",
  "CMAKE_POLICY_DEFAULT_CMP0091": "NEW",
  "CMAKE_BUILD_TYPE": "Debug"
},
...
```
The generated conan_toolchain.cmake:
```
...
# Variables
set(option "True" CACHE STRING "Variable option conan-toolchain defined")
set(option2 "True" CACHE STRING "Variable option2 conan-toolchain defined")
set(option3 ON CACHE BOOL "Variable option3 conan-toolchain defined")
...
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: tgurriet
issue_14589: state: open
title: [feature] Report progress of unpacking source files
body: ### What is your suggestion?

When building a dependency, the source files are downloaded with an upfront message that tells you how large the download is and there are regular updates on the progress printed in the terminal. However, there is no final message when the download is done, and also no message at all about the unpacking process.

When I tried to build `qt/5.15.10`, the download was seemingly stuck near the end. Checking the Task Manager (as I'm on Windows) showed that Python is maxing out one core, and the Resource Monitor showed a lot of I/O activity in `%USERPROFILE%\.conan2\p\` which I assume was caused by Conan unpacking the source files, which can [take a while](https://github.com/conan-io/conan/issues/5209).

It would be great to have an initial message about the unpacking and ideally continuous updates about the progress similar to the download.

(Observed on Windows 11 with Conan 2.0.9)

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Simran-B
labels: component: ux: No changes to core business logic
issue_14586: state: open
title: [Conan remote cleanup] Delete based on usage and/or upload time in artifactory
body: ### What is your question?

Do we have a procedure for how to delete the files based on specific criteria, like not used in x days or uploaded x days before? This is for Conan remote as artifactory. 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: nagag08
issue_14585: state: open
title: [bug] `avr` architecture isn't specific enough to build and identify compatible libraries
body: ### Environment details

I am currently able to develop for AVR by extending the `avr` architecture with the required `mcu`, e.g. :

~~~~
> cat ~/.conan2/settings_user.yml
arch:
    avr:
        mcu: [atmega64, atmega128, atmega2560, atmega328p]
~~~~

This solution doesn't scale due to the large number of AVR targets and users need to make changes to their conan settings.

So, one improvement would be to replace the `avr` architecture in `settings.yml` with the above list, same like with `ARM`:
~~~~
> cat ~/.conan2/settings.yml:
....
arch: [.... avr25  avr35  avr51 avr4   avr6 avr31  avr5 avrxmega2  avrxmega5 avrxmega3  avrxmega6  avrtiny  avrxmega4  avrxmega7...]
~~~~

This is good for creating the libraries, but insufficient for linking the final firmware, this requires the actual mcu name like **atmega64**.

Perhaps adding support for ad-hoc architectures would be nice but `arch: atmega128` doesn't know it can link to libraries of `arch: avr51` and would unnecessary create a new binary package. (although this would still be acceptable, they will never by big)

* Operating System+version:Windows & Linux
* Compiler+version:avr-gcc-7.3
* Conan version: 2.0.9



### Steps to reproduce

_No response_

### Logs

_No response_
user: jputcu
issue_14582: state: open
title: [bug] conan2 chooses incompatible version of catch2 dependency
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: MSVC 193
* Conan version: 2.0.6
* Python version: 3.11


### Steps to reproduce

In my `conanfile.txt` I am declaring catch2 as a dependency:

`catch2/[~3]`

Upon running conan2 with the following command line:

`conan.exe install --update --settings=build_type=Release -vverbose --build=missing --output-folder=. path/to/source`

conan resolves the catch2 dependency in the following way:

```
======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=20
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows
[conf]
tools.cmake.cmaketoolchain:generator=Ninja

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=20
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows

======== Computing necessary packages ========
...
catch2/3.4.0: Checking 3 compatible configurations:
catch2/3.4.0: '256d8e24411ffc8da15f42452ef405d7117905dc': compiler.cppstd=14
catch2/3.4.0: Current package revision is newer than the remote one
catch2/3.4.0: Main binary package 'b85eb13063d5472984e2a54461fae73d82585560' missing. Using compatible package '256d8e24411ffc8da15f42452ef405d7117905dc'
...
```

Conan2 selects the compatible package `256d8e24411ffc8da15f42452ef405d7117905dc` which is *not* compatible at all.
Since it is compiled for `cppstd=14`, it misses all the extensions that Catch2 adds when it is compiled for C++17 or newer. This make the build fail upon linking.

I tried to force conan2 to build catch2 from source by adding `--build=[catch2*] ` to the command line. That however seems to be completely ignored by conan2.

### Logs

_No response_
user: sakra
issue_14581: state: open
title: Parallel conan upload to artifactory fail
body: ### Environment details

* OS: Ubuntu 20.04
* Conan 2.0.6:
* Artifactory: 7.49.5 




### Steps to reproduce

I have 3 parallel gitlab pipeline jobs building packages for the same conan recipe (same rrev due to `revision_mode = "scm"`) to different platforms, and uploading these to my artifactory remote.

Upload command: `conan upload myrecipe/1.0.0 --confirm --remote my-virtual-remote`
Sometimes the upload fails with a very strange error:
```
Preparing artifacts to upload
Compressing recipe sources...
Compressing None:conan_sources.tgz
Compressing package...
Uploading artifacts
Uploading recipe 'myrecipe/1.0.0#f0885d238a01f6416656eec66a8b696e84ae384d'
ERROR: 502 Server Error: Bad Gateway for url: https://[hidden]/v2/conans/myrecipe/1.0.0/_/_/revisions/f0885d238a01f6416656eec66a8b696e84ae384d/files/conan_sources.tgz
Waiting 5 seconds to retry...
ERROR: 
Error uploading file: conan_sources.tgz, '502 Server Error: Bad Gateway for url: https://[hidden-url]/v2/conans/myrecipe/1.0.0/_/_/revisions/f0885d238a01f6416656eec66a8b696e84ae384d/files/conan_sources.tgz'
ERROR: Permission denied for user: 'myuser': 403: Not enough permissions to delete/overwrite artifact 'my-virtual-remote:myrecipe/_/1.0.0/_/f0885d238a01f6416656eec66a8b696e84ae384d/export/conanmanifest.txt' (user: 'myuser' needs DELETE permission).. [Remote: my-virtual-remote]
```

I can read the error message, but I am pretty sure it has nothing to do with permissions as the jobs often succeeds.
My own theory is that it happens when 2 of the parallel jobs finish and uploads at the same time and fails because the upload is not an atomic operation, causing some kind of race condition, but it is all just speculation.

What could be wrong?

Regards
Klaus

user: klausholstjacobsen
issue_14580: state: open
title: [question] For a missing package what is the best way to find out what settings/options are different from prebuilt packages 
body: ### What is your question?

Hello,

for a library im building that depends on Qt i get an error message that pre-built package is not available. By looking at the huge list of options (see below) it is not possible to find out what is exactly is different for the required package from the ones that are already prebuilt (especially those with the same settings)

What is the best way to find out what is exactly different? 
Is there a way to do a diff between _qt/version:required_ and _qt/version:prebuilt_package_
Or maybe even have it displayed in the html file generate by **conan search --table**? by highlighting the differences in red?

Conan: 1.60.2
Docker: conanio/gcc9

- Settings: arch=x86_64, build_type=Release, compiler=gcc, compiler.libcxx=libstdc++11, compiler.version=9, os=Linux
- Options: commercial=False, config=None, cross_compile=None, device=None, gui=True, multiconfiguration=False, opengl=desktop, openssl=True, qt3d=False, qtandroidextras=False, qtcharts=False, qtconnectivity=False, qtdatavis3d=False, qtdeclarative=False, qtdoc=False, qtgamepad=False, qtgraphicaleffects=False, qtimageformats=False, qtlocation=False, qtlottie=False, qtmultimedia=False, qtnetworkauth=False, qtpurchasing=False, qtquick3d=False, qtquickcontrols=False, qtquickcontrols2=False, qtquicktimeline=False, qtremoteobjects=False, qtscript=False, qtscxml=False, qtsensors=False, qtserialbus=False, qtserialport=False, qtspeech=False, qtsvg=False, qttools=False, qttranslations=False, qtvirtualkeyboard=False, qtwayland=False, qtwebchannel=False, qtwebengine=False, qtwebglplugin=False, qtwebsockets=False, qtwebview=False, qtx11extras=False, qtxmlpatterns=False, shared=False, sysroot=None, widgets=True, with_dbus=False, with_doubleconversion=True, with_fontconfig=True, with_freetype=True, with_glib=False, with_gssapi=False, with_harfbuzz=False, with_icu=True, with_libjpeg=libjpeg, with_libpng=True, with_md4c=True, with_mysql=True, with_odbc=True, with_pcre2=True, with_pq=True, with_sqlite3=True, with_vulkan=False, with_x11=True, with_zstd=True, brotli:enable_debug=False, brotli:enable_log=False, brotli:enable_portable=False, brotli:enable_rbit=True, brotli:endianness=None, brotli:fPIC=True, brotli:shared=False, brotli:target_bits=None, bzip2:build_executable=True, bzip2:fPIC=True, bzip2:shared=False, double-conversion:fPIC=True, double-conversion:shared=False, expat:char_type=char, expat:fPIC=True, expat:large_size=False, expat:shared=False, fontconfig:fPIC=True, fontconfig:shared=False, freetype:fPIC=True, freetype:shared=False, freetype:subpixel=False, freetype:with_brotli=True, freetype:with_bzip2=True, freetype:with_png=True, freetype:with_zlib=True, icu:dat_package_file=None, icu:data_packaging=archive, icu:fPIC=True, icu:shared=False, icu:with_dyload=True, icu:with_extras=False, icu:with_icuio=True, libffi:fPIC=True, libffi:shared=False, libiconv:fPIC=True, libiconv:shared=False, libjpeg:fPIC=True, libjpeg:shared=False, libmysqlclient:fPIC=True, libmysqlclient:shared=False, libpng:api_prefix=, libpng:fPIC=True, libpng:shared=False, libpng:sse=True, libpq:disable_rpath=False, libpq:fPIC=True, libpq:shared=False, libpq:with_openssl=False, libtool:fPIC=True, libtool:shared=False, libuuid:fPIC=True, libuuid:shared=False, libxml2:c14n=True, libxml2:catalog=True, libxml2:fPIC=True, libxml2:ftp=True, libxml2:html=True, libxml2:http=True, libxml2:iconv=True, libxml2:icu=False, libxml2:include_utils=True, libxml2:iso8859x=True, libxml2:legacy=True, libxml2:lzma=False, libxml2:mem-debug=False, libxml2:output=True, libxml2:pattern=True, libxml2:push=True, libxml2:python=False, libxml2:reader=True, libxml2:regexps=True, libxml2:run-debug=False, libxml2:sax1=True, libxml2:schemas=True, libxml2:schematron=True, libxml2:shared=False, libxml2:threads=True, libxml2:tree=True, libxml2:valid=True, libxml2:writer=True, libxml2:xinclude=True, libxml2:xpath=True, libxml2:xptr=True, libxml2:zlib=True, lz4:fPIC=True, lz4:shared=False, md4c:encoding=utf-8, md4c:fPIC=True, md4c:shared=False, odbc:fPIC=True, odbc:shared=False, odbc:with_libiconv=True, openssl:386=False, openssl:enable_weak_ssl_ciphers=False, openssl:fPIC=True, openssl:no_aria=False, openssl:no_asm=False, openssl:no_async=False, openssl:no_bf=False, openssl:no_blake2=False, openssl:no_camellia=False, openssl:no_cast=False, openssl:no_chacha=False, openssl:no_cms=False, openssl:no_comp=False, openssl:no_ct=False, openssl:no_deprecated=False, openssl:no_des=False, openssl:no_dgram=False, openssl:no_dh=False, openssl:no_dsa=False, openssl:no_dso=False, openssl:no_ec=False, openssl:no_ecdh=False, openssl:no_ecdsa=False, openssl:no_engine=False, openssl:no_filenames=False, openssl:no_fips=False, openssl:no_gost=False, openssl:no_idea=False, openssl:no_legacy=False, openssl:no_md2=True, openssl:no_md4=False, openssl:no_mdc2=False, openssl:no_module=False, openssl:no_ocsp=False, openssl:no_pinshared=False, openssl:no_rc2=False, openssl:no_rc4=False, openssl:no_rc5=False, openssl:no_rfc3779=False, openssl:no_rmd160=False, openssl:no_seed=False, openssl:no_sm2=False, openssl:no_sm3=False, openssl:no_sm4=False, openssl:no_sock=False, openssl:no_srp=False, openssl:no_srtp=False, openssl:no_sse2=False, openssl:no_ssl=False, openssl:no_ssl3=False, openssl:no_stdio=False, openssl:no_threads=False, openssl:no_tls1=False, openssl:no_ts=False, openssl:no_whirlpool=False, openssl:no_zlib=False, openssl:openssldir=None, openssl:shared=False, pcre2:build_pcre2_16=True, pcre2:build_pcre2_32=True, pcre2:build_pcre2_8=True, pcre2:build_pcre2grep=True, pcre2:fPIC=True, pcre2:grep_support_callout_fork=True, pcre2:shared=False, pcre2:support_jit=False, pcre2:with_bzip2=True, pcre2:with_zlib=True, sqlite3:build_executable=True, sqlite3:disable_gethostuuid=False, sqlite3:enable_column_metadata=True, sqlite3:enable_dbpage_vtab=False, sqlite3:enable_dbstat_vtab=False, sqlite3:enable_default_secure_delete=False, sqlite3:enable_default_vfs=True, sqlite3:enable_explain_comments=False, sqlite3:enable_fts3=False, sqlite3:enable_fts3_parenthesis=False, sqlite3:enable_fts4=False, sqlite3:enable_fts5=False, sqlite3:enable_json1=False, sqlite3:enable_math_functions=True, sqlite3:enable_preupdate_hook=False, sqlite3:enable_rtree=True, sqlite3:enable_soundex=False, sqlite3:enable_unlock_notify=True, sqlite3:fPIC=True, sqlite3:max_blob_size=None, sqlite3:max_column=None, sqlite3:max_variable_number=None, sqlite3:omit_deprecated=False, sqlite3:omit_load_extension=False, sqlite3:shared=False, sqlite3:threadsafe=1, sqlite3:use_alloca=False, wayland:enable_dtd_validation=True, wayland:enable_libraries=True, wayland:fPIC=True, wayland:shared=False, xkbcommon:fPIC=True, xkbcommon:shared=False, xkbcommon:with_wayland=True, xkbcommon:with_x11=True, xkbcommon:xkbregistry=True, zlib:fPIC=True, zlib:shared=False, zstd:fPIC=True, zstd:shared=False, zstd:threading=True
- Dependencies: zlib/1.2.13, openssl/3.1.1, pcre2/10.42, double-conversion/3.3.0, freetype/2.13.0, fontconfig/2.14.2, icu/73.2, libjpeg/9e, libpng/1.6.40, sqlite3/3.42.0, libmysqlclient/8.0.31, libpq/15.3, odbc/2.3.11, xkbcommon/1.5.0, xorg/system, opengl/system, zstd/1.5.5, md4c/0.4.8
- Requirements: double-conversion/3.Y.Z, fontconfig/2.Y.Z, freetype/2.Y.Z, icu/73.Y.Z, libjpeg/9e, libmysqlclient/8.Y.Z, libpng/1.Y.Z, libpq/15.Y.Z, md4c/0.4.8, odbc/2.Y.Z, opengl/system, openssl/3.Y.Z, pcre2/10.Y.Z, sqlite3/3.Y.Z, xkbcommon/1.Y.Z, xorg/system, zlib/1.Y.Z, zstd/1.Y.Z
- Package ID: ab96a265ac568c1a253f796f9f74e7b8d5fe7eed

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ibrawada
issue_14570: state: open
title: [feature] Add an ability to build dependencies in parallel
body: ### What is your suggestion?

Hi Conan community,

I know there is an ability to download packages in parallel via general.parallel_download. I have a use case, where "conan install" builds a large number of dependency packages. In my case build means downloading/decompressing those from my company's share drive containing non-conan builds.
I would like to see a feature for the parallel build of dependency packages during conan install/create stage. This might significantly improve dependency installation time.

Thanks, Michal

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: MichalCermakx
issue_14568: state: open
title: [question] cacheVariables data type mismatch in generated CMakePresets.json
body: ### What is your question?

If I define CMake Cache like the following in conanfile.py, CLion's CMake Presets Integration will not work.

```Python
         tc.cache_variables["CELIX_ERR_BUFFER_SIZE"] = self.options.celix_err_buffer_size

         v = Version(self.version)
        tc.cache_variables["CELIX_MAJOR"] = v.major.value
        tc.cache_variables["CELIX_MINOR"] = v.minor.value
        tc.cache_variables["CELIX_MICRO"] = v.patch.value
```

The root cause is analyzed by JetBrains engineer in https://youtrack.jetbrains.com/issue/CPP-34818:

> pure technically the project generates preset file which violates cmake-presets specification:

> cacheVariables
An optional map of cache variables. The key is the variable name (which may not be an empty string), and the value is either null, a boolean (which is equivalent to a value of "TRUE" or "FALSE" and a type of BOOL), a string representing the value of the variable (which supports macro expansion), or an object with the following fields:

> Field might be either null or boolean or string or an object, though in generated presets file the value is a number

```
"CELIX_ERR_BUFFER_SIZE": 512,
```

A fix is relatively straight forward:

```Python
        tc.cache_variables["CELIX_ERR_BUFFER_SIZE"] = str(self.options.celix_err_buffer_size)

        v = Version(self.version)
        tc.cache_variables["CELIX_MAJOR"] = str(v.major.value)
        tc.cache_variables["CELIX_MINOR"] = str(v.minor.value)
        tc.cache_variables["CELIX_MICRO"] = str(v.patch.value)
```

I notice Conan's documentation does not mention this data type mismatch issue.
It would be better to avoid this kind of issue at the first place. 
That is, Conan guarantees to generate CMakePresets.json compliant to the specification.


### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: PengZheng
issue_14564: state: open
title: [question] How to download / copy from repo to repo all packageids of a given package
body: ### What is your question?

Hello

My use case is simple:
- i have a package with several precompiled packageids
- i want to duplicate all of them to another repository

if I use conan download, it only fetch 1 packageid (matching the current env I guess).

I am using conan 1.6x

in the source artifactory repository i have

![image](https://github.com/conan-io/conan/assets/133498/acdaf8e0-c7fe-4c94-abfb-05fd72972fb0)

I want both of these packageid to be copied to another repo.

Example:
```
conan download gtest-multilib/1.0.4@myuser/stable -r myproject-remote 
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
gtest-multilib/1.0.4@myuser/stable: Getting the complete package list from 'gtest-multilib/1.0.4@myuser/stable#6e1f2596377ea1bdd89d9de16dc60c86'...
gtest-multilib/1.0.4@myuser/stable: Downloading binary packages in 4 parallel threads
gtest-multilib/1.0.4@myuser/stable: Downloading gtest-multilib/1.0.4@myuser/stable:47d6e19a11aa76d4a7f5d55e469c19d8eb43d22c
gtest-multilib/1.0.4@myuser/stable: Retrieving package 47d6e19a11aa76d4a7f5d55e469c19d8eb43d22c from remote 'myproject-remote' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
gtest-multilib/1.0.4@myuser/stable: Package installed 47d6e19a11aa76d4a7f5d55e469c19d8eb43d22c
gtest-multilib/1.0.4@myuser/stable: Downloaded package revision 10a9b6ff139695e06c83b77bdc735be5
```

How can I do this duplicate completely without having to request packageid by packageid ?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: gsemet
issue_14562: state: open
title: can't find 'opencv/4.1.2@sim/stable' in remotes
body: ### What is your question?

i am a new coder. my company use conan to manage packages，some errors occurred when i execute this command
`conan install ../conanfile-insource.py --build missing -if ./`

errors message is:
`opencv/4.1.2@sim/stable: Not found in local cache, looking in remotes...`
`opencv/4.1.2@sim/stable: Trying with 'conancenter'...`
`ERROR: Failed requirement 'opencv/4.1.2@sim/stable' from 'conanfile-insource.py'`
`ERROR: Unable to find 'opencv/4.1.2@sim/stable' in remotes`

part of conanfile-insource.py is:
`    def requirements(self):
        if self.options.using_its800_opencv == False:
            self.requires.add("opencv/4.1.2@sim/stable")`

 My conan's default profile is:
`[settings]`
`os=Linux`
`os_build=Linux`
`arch=x86_64`
`arch_build=x86_64`
`compiler=gcc`
`compiler.version=7`
`compiler.libcxx=libstdc++11`
`build_type=Release`
`[options]`
`[build_requires]`
`[env]`

so why does it happened? i am very confused.



### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: SwordJoe
issue_14553: state: open
title: [question]  OperatingSystem-specific patches in a CCI recipe
body: ### What is your question?

In an CCI recipe:
What is the proper way to store `.patch` files that should only be applied for a certain OS?

For example, given this existing `conandata.yml`:
```
patches:
  "6.3.0":
    - patch_file: "patches/0001-msvc-dumpbin-yasm-wrapper.patch"
    - patch_file: "patches/6.x.x-0001-fix-MSVC-next-prime-error.patch"
  "6.2.1":
    - patch_file: "patches/0001-msvc-dumpbin-yasm-wrapper.patch"
    - patch_file: "patches/6.x.x-0001-fix-MSVC-next-prime-error.patch"
```

Is it possible to:

```
patches:
  "6.3.0":
    - patch_file: "patches/0001-msvc-dumpbin-yasm-wrapper.patch"
    - patch_file: "patches/6.x.x-0001-fix-MSVC-next-prime-error.patch"
  "6.2.1":
    - patch_file: "patches/0001-msvc-dumpbin-yasm-wrapper.patch"
    - patch_file: "patches/6.x.x-0001-fix-MSVC-next-prime-error.patch"
  "Emscripten":
    - patch_file: "patches/0001-emscripten-specific.patch"
    - patch_file: "patches/0002-emscripten-specific.patch"
```

?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fpelliccioni
issue_14551: state: open
title: AutotoolsToolchain: support custom configure command
body: ### What is your suggestion?

Currently, `AutotoolsToolchain` helper has method `configure()`, which always invokes hard-coded `configure` command. it works for 99% of projects, however, there are some exceptions:

- Emscripten recommends to use `emconfigure` wrapper
- ICU uses `runConfigureICU` script
- OpenSSL uses `Configure` (NOTE capital C)
- TensorFlow uses `configure.py`

I suggest to add new parameter `configure_command`, with default `configure` (as currently).

Related with: https://github.com/conan-io/conan/issues/4915

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fpelliccioni
issue_14550: state: open
title: [question] Why is CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON by default?
body: ### Environment details

* Operating System+version: Ubuntu2
* Compiler+version: irrelevant
* Conan version: 1.60.1
* Python version: 3.8.10


### Steps to reproduce

CMakeToolchain generator sets by default `set(CMAKE_FIND_PACKAGE_PREFER_CONFIG ON)`.
This causes issues during different builds. E.g. QT provides some own cmake modules

Ref: https://github.com/qt/qtbase/tree/fa522eb8becba3243aae8bee191f6f60672434f2/cmake

Since conan sets `set(CMAKE_FIND_PACKAGE_PREFER_CONFIG ON)`, cmake won't consider those modules first and the build will fail (e.g. since the original clang ClangConfig.cmake is found first). 
This enforces users to actively set `tc.variables["CMAKE_FIND_PACKAGE_PREFER_CONFIG"]="ON"`, or the global conf `tools.cmake.cmaketoolchain:find_package_prefer_config=False`. 

Is this intended?

I will create a test for this. 

### Logs

_No response_
user: thorsten-klein
issue_14543: state: open
title: [feature] order of `prepend_path` can be specified
body: ### What is your suggestion?

I am facing some issue with `buildenv_info.prepend_path` and `buildenv_info.append_path`.
The `append_path` is added behind the original system PATH. `prepend_path` is always prepended before system PATH.

Since we always want to prefer conan packages (=add paths in front of the system PATH), we must use `prepend_path`. 
But when using `prepend_path` everywhere, the order is not influencable. It seems to be random order (at least not alphabetical and not according to the order at command line).

It would be nice to have an optional parameter  for `prepend_path` and `append_path` to specify some "`priority`". With this users can influence if the package path will be in front or not.

Solution 1: 
`priority` could be a number. By this it is very generic. Default: 0. Drawback: maintainers of packages must decide if the package is more important or not

Solution 2:
The package itself has some attribute like `self.package_type="sysroot"`. 
There could be some conf like `tools.env.virtualenv:prefer_sysroot`. 

- If set to `True`, then first the `prepend_path` of the sysroot package will be applied. Then the other ones. 
- If set to `False`, then the `prepend_path` of the sysroot package will be applied last (but before system `$PATH`.

Advantage of Solution 2: The user can set the behavior.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: thorsten-klein
issue_14542: state: open
title: [question] How to get host/target settings in tool package?
body: ### What is your question?

Just a quick question: I have a clang compiler package that I want to use with `tool_requires`. For cross-compilation, I want to set the CMAKE_SYSTEM_PROCESSOR correctly. Because Clang can compile/cross-compile to multiple architectures, I want to have just one package and tried to put that into the `package_id()` and `package_info()` methods of my clang package like this:

```
    def package_id(self):
        self.info.settings_target = self.settings_target
        self.info.settings_target.rm_safe("arch")
        self.info.settings_target.rm_safe("build_type")
        self.info.settings_target.rm_safe("compiler")

    def package_info(self):
        self.conf_info.define("tools.build:compiler_executables", compilers)
        self.conf_info.define("tools.cmake.cmaketoolchain:system_name", self.settings.get_safe("os"))
        self.conf_info.define("tools.cmake.cmaketoolchain:system_processor", self.settings.get_safe("arch"))
```
And I want to use it like this (one profile for the Clang toolchain, one profile for the target system):
```
$ conan install --requires 'tinyxml2/[~9]' -s build_type=Debug -pr toolchain-clang15 -pr target-arm -s os.glibc=2.31 -b 'tinyxml2*'

======== Input profiles ========
Profile host:
[settings]
arch=armv8
arch.crypto=True
arch.simd=True
build_type=Debug
compiler=clang
compiler.libcxx=libc++
compiler.version=15
os=Linux
os.glibc=2.31
[options]
*:shared=True
[tool_requires]
*: clang/[~15]@trs/stable
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
[buildenv]
CXXFLAGS=-stdlib=libc++
LDFLAGS=-stdlib=libc++

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=10
os=Linux
os.glibc=2.35
[conf]
tools.cmake.cmaketoolchain:generator=Ninja

[...]

======== Installing packages ========
clang/15.0.6: Already installed! (1 of 2)
clang/15.0.6: conf_info: tools.cmake.cmaketoolchain:user_toolchain=['/home/fschoenm/.conan2/p/b/clang8e75d58062a86/p/toolchain.cmake']
tools.cmake.cmaketoolchain:system_processor=x86_64
tools.cmake.cmaketoolchain:system_name=Linux
tools.build:compiler_executables={'asm': 'clang-as', 'c': 'clang', 'cpp': 'clang++'}
clang/15.0.6: conf_info: tools.cmake.cmaketoolchain:user_toolchain=['/home/fschoenm/.conan2/p/b/clang8e75d58062a86/p/toolchain.cmake']
tools.cmake.cmaketoolchain:system_processor=x86_64
tools.cmake.cmaketoolchain:system_name=Linux
tools.build:compiler_executables={'asm': 'clang-as', 'c': 'clang', 'cpp': 'clang++'}

```

However, when `package_info()` is run during the build, `self.settings` seems to refer to the build context instead of the host context (see debug output of the `conf_info` property above). How do I get in this method the target architecture and set it correctly? Is that possible?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fschoenm
issue_14539: state: open
title: [feature] Create lock files based on date and time
body: ### What is your suggestion?

conan lock create has a --update parameter

What would be good is that based on a past commit date and time in git, we could generate lock files for that commit, the nearest revision of conan dependency recipes earlier than the git commit.

This would be e.g. very helpful in projects where these used to be no lock files at a certain point of time, so builds would be otherwise difficult to reproduce.

At the moment, I end up checking all the dependencies manually to pin them by conan -r foo -rev Bar/X.YZ@... and then manually pick the corresponding pin from the list, but it is struggle to do this manually for all the dependencies. It is also error prone.

It sounds like this could be automated?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: lpapp-foundry
issue_14509: state: open
title: Can not set tools.build.cross_builing:can_run
body: ### What is your question?

I'm trying to cross build application on Linux arm.
1 of the dependencies is HDF5 which has a call to can_run.
I should be able set tools.build.cross_building:can_run.
I have tried 
- conan config set tools.build.cross_building:can_run=True
  which returns an error if i use conan config get ...

- conan config set tools.build.cross_building:can_run=True
  which does return True with Get but it still returns False when hdf5 runs can_run

- conan config set build.cross_building:can_run=True
- conan config set cross_building:can_run=True
- conan config set can_run=True

But can_run still returns False and hdf5 is marked as invalid

> ERROR: There are invalid packages (packages that cannot exists for this configuration):
> hdf5/1.8.21: Invalid ID: Current recipe doesent't support cross-builing (yet)

hdf5 recipe snippet
```python
def validate(self):
       if not can_run(self):
           # While building it runs some executables like H5detect
           raise ConanInvalidConfiguration("Current recipe doesn't support cross-building (yet)")
```

Conan version : 1.57 and/or 1.60.2
System : wsl ubuntu 18.04

command used for conan
> conan install ../.. --profile:build=x86_64 --profile:host=aarch64 -if conaninfo --build=missing

x86_64 profile
```
[settings]
os=Linux
os_build=linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=9
compiler.libcxx=libstdc++11
build_type=Release
[options]
[build_requires]
[env]
```

aarch64 profile
```
target_host=aarch64-linux-gnu

[env]
CHOST=$target_host
AR=$target_host-ar
AS=$target_host-as
RANLIB=$target_host-ranlib
CC=$target_host-gcc-9
CXX=$target_host-g++-9

[buildenv]
CHOST=$target_host
AR=$target_host-ar
AS=$target_host-as
RANLIB=$target_host-ranlib
CC=$target_host-gcc-9
CXX=$target_host-g++-9

[settings]
os=Linux
os_build=linux
arch=armv8
arch_build=armv8
compiler=gcc
compiler.version=9
compiler.libcxx=libstdc++11
build_type=Release

[options]
[build_requires]
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: botn365
issue_14506: state: open
title: [question] Usage of  self.deps_cpp_info in conan version 2
body: ### What is your question?

I am new to conan  and  trying to migrate conan 1.0 recipe file to conan 2.0.

**Environment Details:** 

OS Version: Red Hat Enterprise Linux 8.5 (Ootpa)
Conan Version: 2.0.7
Python Version: 3.6.8

In my conan 1.0 recipe file `self.deps_cpp_info` is used in` imports () `.

As in the conan 2.0 documentation` imports () ` method and `self.deps_cpp_info` removed from the conan 2.0.

How can I migrate `self.deps_cpp_info` to conan 2.0?

As an example, 
My sample conan 1.0 recipe file:

Solution compressor/2.0 package that depends on product zlib/1.0. The zlib recipe defines as follows. And zlib/1.0 is uploaded to the artifactory.
```
import os, yaml, shutil, subprocess, re
from conans import ConanFile, tools
from distutils.dir_util import copy_tree

class Compressor(ConanFile):
    name = "compressor"

   product_component_directory = "zlib/src/"
   exclude_files = ['*.build_conf', 'build_config/CMakeLists.txt', 'build_config/conanfile.py', 'build_config/readme', 
                               'build_config/relman.h', 'build_config/version.cpp', 'build_config/version.h']
   sourcecode_directory = "product_sourcecode"
   copy_directory = "../admin_SysGuard_Auth/src/"

   def imports(self):
        if not os.path.exists(self.sourcecode_directory):
			os.makedirs(self.sourcecode_directory)

	target_folder = self.sourcecode_directory + "/" + self.product_component_directory
	self.output.info("Executing imports() method")
	self.output.info(self.deps_cpp_info["zlib"].rootpath)
	self.copy("*", excludes=self.exclude_files, dst=target_folder, 
                             src=self.deps_cpp_info["zlib"].rootpath+'/../../export_source/src', folder=False)
	copy_tree(target_folder, self.copy_directory)
```

How do I use  `self.deps_cpp_info["tech_Secure_MAuth"].rootpath` this in `generate ()` in conan 2.o 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: AroshikaFernando
issue_14488: state: open
title: [bug] Either wrong documentation or missing feature : generate() bindirs which respect layout()
body: ### Environment details

* Operating System+version: win11
* Compiler+version: VS 2022
* Conan version: 2.0.9
* Python version: none


### Steps to reproduce

Lets assume a CMake recipe, using the default `cmake_layout`.

The migration documentation for `imports` removal states: we should copy our shared libraries in the `generate()` method.
https://github.com/conan-io/conan/issues/14487
```
from conan.tools.files import copy

def generate(self):
    for dep in self.dependencies.values():
        copy(self, "*.dylib", dep.cpp_info.libdirs[0], self.build_folder)
        copy(self, "*.dll", dep.cpp_info.libdirs[0], self.build_folder)
```

On msvc, `self.build_folder` will point to `awesome_project/build`. However, with varying layouts, this isn't the correct location for your dlls. The correct location is either `awesome_project/build/Release` or `awesome_project/build/Debug`.

These "final" output folders need to be accessible programmatically, and they are, through `self.cpp.build.bindirs[0]`.

However, the `self.cpp` doc states these attributes are only valid during the `layout()` method.
https://docs.conan.io/2/reference/conanfile/attributes.html#cpp

> cpp
> 
> Object storing all the information needed by the consumers of a package: include directories, library names, library paths… Both for editable and regular packages in the cache. **It is only available at the layout() method.**

So either, the doc is incorrect : 
- The migration guide should demonstrate `self.cpp.build.bindirs[0]`.
- The `self.cpp` doc should be updated to clarify these attributes can be read in other methods. Potentially what is meant is that they are only *writeable* in `layout()`?

Or, we need an equivalent:
- Something along the lines of `self.bin_folder`, which is guaranteed to point to whichever binary directory has been selected, according to `layout` or `--output-folder` or any other setting that can affect binary output location.

Ty!

### Logs

_No response_
user: p-groarke
issue_14486: state: open
title: [question] Skipped binaries & compatible configurations
body: ### What is your question?

When a binary of a C++ package is skipped during a conan install (for example because it's a tool requires of a package already available in cache), I see that there is still a compatible configuration check of this skipped package. These checks are very slow (when I have many C++ dependencies I really want to remove compiler.cppstd from my profile honestly) and the only way to speed up conan install in this case is to install these skipped binaries in cache so that compatible configuration is not run anymore for these packages, but it defeats a little bit the concept of skipped binaries.

Could these compatible configurations checks be skipped if conan already knows that package is not necessary?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: SpaceIm
issue_14482: state: open
title: [bug] PremakeDeps fails in Conan v1
body: ### Environment details

* Operating System+version: Windows
* Conan version: 1.60.2 (worked without issues in 2.0.9)
* Python version: 3.11


### Steps to reproduce

1. Add `PremakeDeps(self).generate()` to some recipe.
I was trying to use it with https://github.com/conan-io/conan-center-index/pull/18853
2. Run `conan create` on the recipe.

### Logs

```
yojimbo/1.2.1: Calling generate()
Traceback (most recent call last):
  File "C:\Users\martin\.conan\data\yojimbo\1.2.1\_\_\export\conanfile.py", line 73, in generate
    tc.generate()
  File "C:\Users\martin\miniconda3\envs\conan1\Lib\site-packages\conan\tools\premake\premakedeps.py", line 45, in generate
    generator_files = self.content
                      ^^^^^^^^^^^^
  File "C:\Users\martin\miniconda3\envs\conan1\Lib\site-packages\conan\tools\premake\premakedeps.py", line 80, in content
    deps = _PremakeTemplate(self._get_cpp_info())
                            ^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\martin\miniconda3\envs\conan1\Lib\site-packages\conan\tools\premake\premakedeps.py", line 52, in _get_cpp_info
    dep_cppinfo = dep.cpp_info.copy()
                  ^^^^^^^^^^^^^^^^^
  File "C:\Users\martin\miniconda3\envs\conan1\Lib\site-packages\conans\model\new_build_info.py", line 106, in __getattr__
    return getattr(self.components[None], attr)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: '_NewComponent' object has no attribute 'copy'
```

Fails here: https://github.com/conan-io/conan/blob/8695925f3ab0f3968665c17aadc50159e5a8d303/conan/tools/premake/premakedeps.py#L49-L57
user: valgur
issue_14480: state: open
title: [feature] Obtain timestamp from unzip routines for SOURCE_DATE_EPOCH
body: ### What is your suggestion?

This is related to #5152, but addresses one specific aspect of the issue.

Best practices for reproducible builds related to the use of `SOURCE_DATE_EPOCH` indicate that this should be set to a well-defined timestamp associated with the source code being compiled. For a source tarball, this could be the latest timestamp among its files; for a Git tree (or other VCS), this could be the commit timestamp. I am particularly concerned with the former case, but the latter might be considered in scope as well.

Since Conan takes care of unpacking source archives itself, rather than calling out to external programs, it is in a good position to grab timestamps of files as it iterates through them. It can then return a useful value from that information, e.g. the most recent timestamp across all of them.

Automatically setting `SOURCE_DATE_EPOCH` from that result is a potential user-configurable convenience, and perhaps might even be considered as a future default. For now, however, the focus of this issue is to add the logic necessary to obtain that timestamp in the first place, across the different source archive-unpacking implementations in the codebase. Once that information is available, how it is used will be a different story.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: iskunk
issue_14475: state: open
title: [question] search.py: search_recipes，why always call cache.all_refs, cost too much time!
body: ### What is your question?

Operating System+version:ubuntu20.04
Compiler+version:gcc9.3
Conan version:1.59
Python version:3.8

hi，I have a few question about conans/search/search.py.
in this function, it always call cache.all_refs(), but get the same result, it may be a waste of time.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Anytious
issue_14471: state: open
title: Conan 2.0 cmake tutorial doesn't build
body: ### Environment details

* Operating System+version: Mac os 13.5
* Compiler+version: native mac clang 
* Conan version: 2.0.9 (but doc website is 2.0) installed from 'homebrew'
* Python version: unk


### Steps to reproduce

Run the CMake tutorial instructions from a machine that has not had conan 2 installed before.

The zlib library is built in Debug configuration but the test application is built in Release.  So the application builds but cannot link.

It's a single word fix so I think not worth making a fix + pull request (plus I don't know which you prefer to change).

### Logs

_No response_
user: dvhwgumby
issue_14455: state: open
title: strip_root behaviour with pattern differs between tools.unzip and tools.untargz
body: ### Environment details

Conan version 1.57.0

### Steps to reproduce

Consider an archive with a structure like this

- root_dir/a.txt
- root_dir/b.txt

This is compressed once as .tar.gz and once as .zip. I would expect this command:

`conans.tools.unzip("archive.XXX", pattern="a.txt", strip_root=True)`

to extract a.txt. But this only happens for the .tar.gz archive. For the zip, I need to specify root_dir in the pattern.

Both behaviours can be argued for (though I'd say if I pass strip_root, I have expressed I do not care about the root directory, and do not want to pass its name in my pattern -- that's half the point of the option) but it should certainly be consistent.

### Logs

_No response_
user: scummos
issue_14447: state: open
title: [bug][feature] Make full_deploy configurable like the cmake build folder
body: ### Environment details

* Operating System+version: all
* Compiler+version: n/a
* Conan version: 2.0.9
* Python version: 3.11


### Steps to reproduce

We're trying to use conan for a project that does not depend on conan yet with the new `full_deploy` deployer, following this article: https://docs.conan.io/2/examples/extensions/deployers/dev/development_deploy.html#examples-extensions-builtin-deployers-development

* In the documentation it says:
  > The binary variability is limited to Release/Debug. The generated files are exclusively for the current configuration, changing any other setting (os, compiler, architecture) will require a different deploy

  This does not seem to be correct because `arch` **is** used for the name of deployment folder.

* In reality: The output directory seems to depend on `arch` and `build_type` but not on `os` or `compiler`.

At first I thought it's a bug that only some settings are used for the deployment folder but now I wonder if that's an oversight or what's the idea behind using only `build_type` or `arch` and `build_type` but not other variables. I think that at least the documentation and the implementation should match.

My feature proposal is to add a configuration value similar to `tools.cmake.cmake_layout:build_folder_vars` that allows specifying which settings (and options) should be used in the path of the deployment folder. (At the same time, the `full_deploy` name could be changed into a variable.) It would make the integration of a deployment folder into an existing project feel more natural if you can somewhat configure where the dependencies are located instead of insisting on a pretty strict/inflexible directory structure.


### Logs

_No response_
user: fschoenm
issue_14445: state: open
title: [bug] include in profile files are ambiguous
body: ### Environment details

* Operating System+version: liunx
* Compiler+version: clang
* Conan version: 1.x
* Python version: 3.10


### Steps to reproduce
```bash
#!/bin/bash
clear
#Problem: conan profiles are not resolved as expected
create_and_check() {
  output=$(conan create -pr:b=./.profiles/clang-linux-release -pr:h=./.profiles/clang-linux-release --build=mypackage .)
  echo $?
  #
  if echo "$output" | grep -q 'CFLAGS=-Weverything'; then
      echo "Found 'CFLAGS=-Weverything' in the output."
  else
      echo "Not Found 'CFLAGS=-Weverything' in the output."
  fi
}

set -e
if [ -d "x" ]; then
    rm -r "x"
fi
mkdir x
pushd x
export CONAN_USER_HOME=./x
conan new mypackage/1.0 -c -s

mkdir .profiles
conan profile list

# create a project-specific profile file so I can manage the in git.
echo 'cc_compiler=clang
cxx_compiler=clang++
c_flags=-Weverything

[settings]
compiler=clang
compiler.version=10
compiler.libcxx=libstdc++11
arch=x86_64
os=Linux

[env]
CC                = $cc_compiler
CXX               = $cxx_compiler
CFLAGS            = $c_flags' > .profiles/clang-linux

echo 'include(clang-linux)

[settings]
build_type=Release' > .profiles/clang-linux-release

echo "Step 1. works as expected. CFLAGS=-Weverything is used"
create_and_check


echo "Step 2. now if a create the same named file in conan but now CFLAGS=-Weverything are finaly is not set ..."
# I agree that this does not make much sense to have a file with the same name in .conan/profiles and in the folder of the referenced profile .profiles/. But could happen and happened in our case. one was int git the other file was delivered through docker in the conan home.

conan profile new clang-linux --detect
conan profile list
cat .conan/profiles/clang-linux
create_and_check
echo "Step 2. ... CFLAGS=-Weverything is not set"
echo "the reason is that include(clang-linux) uses the profile clang-linux from ./x/.conan/profiles/clang-linux and not ./x/.profiles/clang-linux"
echo "/x/.profiles/clang-linux is not even parsed. you can test it in case you make an intentional error in the file"

echo "Step 3 if I change the include(clang-linux) to include(./clang-linux) then the file ./x/.profiles/clang-linux is used and not the ./x/.conan/profiles/clang-linux\n"
sed -i '1s/.*/include(.\/clang-linux)/' .profiles/clang-linux-release
cat .profiles/clang-linux-release
create_and_check
echo "Step 3. ... CFLAGS=-Weverything is now set again"


echo "Here is my complaint. In the case include(...) is not unambiguously conan should fail. Now it does not and it was a bit hard to understand conans behavior"
echo "As written above. Our setup was not ideal but for a stable solution the behavior should be unambiguous"
```

### Logs

_No response_
user: stefaneicher
issue_14438: state: open
title: [question] when conan install is called inside a dockerfile, cmake cannot resolve dependencies
body: ### What is your question?

I have a project where I call conan install inside a dockerfile so that I have the dependencies needed to compile with cmake inside the docker container. However, after install is called when starting the container, the call to cmake results in `Library XXX not found in package`. If I then delete the build folder and call conan install again, cmake can then find the dependencies. What might cause this?

conan install called in dockerfile
`conan install . --build="*" -s compiler.cppstd=gnu20`

conan profile inside container
```
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu14
compiler.libcxx=libstdc++
compiler.version=10
os=Linux
```

conan profile outside container
```
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
```

conanfile.py
```
import os
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMake, cmake_layout
from conan.tools.files import get
from conan.tools.build import check_min_cppstd

class ProjectRecipe(ConanFile):
    name = 'data-fusion-engine'

    settings = 'os', 'compiler', 'build_type', 'arch'
    options = {
        'shared': [True, False],
        'fPIC': [True, False]
    }

    default_options = {
        'shared': False,
        'fPIC': True
    }

    generators = 'CMakeDeps'

    exports_sources = 'CMakeLists.txt', 'src/*'

    def validate(self):
        check_min_cppstd(self, '20')

    def requirements(self):
        self.requires('cspice/0067')

    def build_requirements(self):
        self.tool_requires('cmake/3.27.0')

    def config_options(self):
        if self.settings.os == 'Windows':
            del self.options.fPIC

    def configure(self):
        if self.options.shared:
            self.options.rm_safe('fPIC')

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
        if not self.conf.get('tools.build:skip_test', default=False):
            import os

    def package(self):
        cmake = CMake(self)
        cmake.install(self)

    def package_info(self):
        self.cpp_info.libs = ['project']
        self.cpp_info.includedirs = ['include']
        self.cpp_info.libdirs = ['lib']
```

I have tried:
- implementing a conan.lock
- deleting the build folder inside the dockerfile before calling conan install
- cleaning the conan cache inside the dockerfile
- matching the conan profiles in and outside the container via -s flags in the conan install command

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sdeadric
issue_14437: state: open
title: [question] lib/lib64 inconsistency in local dev workflow
body: ### What is your question?

Hi,

I have a question regarding PR #10672 (also related to #10393) on the install paths given to the CMake toolchain and in particular concerning the install destination of archives. 

As I understand the `OutputDirsBlock` block that has been added for the CMake toolchain, it will never been triggered in local dev workflow (source, install, build, export-pkg) because of the condition on the existence of the `package_folder` attribute:
``` python
    def context(self):
        if not self._conanfile.package_folder:
            return {}
        return {"package_folder": self._conanfile.package_folder.replace("\\", "/"),
                "default_bin": self._get_cpp_info_value("bindirs"),
                "default_lib": self._get_cpp_info_value("libdirs"),
                "default_include": self._get_cpp_info_value("includedirs"),
                "default_res": self._get_cpp_info_value("resdirs")}
```

This however has the consequence that some recipes might be broken when using the local dev workflow, and not when using `conan create` or the build from source.

I have at least one example: the [expat recipe](https://github.com/conan-io/conan-center-index/tree/master/recipes/expat/all) that cannot work for local dev workflow on RHEL-x64 (Debian is fine). This is because on RHEL-x64 the default `GNUInstallDirs` lib destination is `lib64`, which is not listed in `cpp_info`, therefore causing undefined references at the test package stage:

```
[2/2] Linking C executable test_package
FAILED: test_package 
: && /opt/rh/gcc-toolset-10/root/usr/bin/cc -m64 -O3 -DNDEBUG -m64   -rdynamic CMakeFiles/test_package.dir/test_package.c.o -o test_package -L/root/.conan2/p/b/ame_e193e31ec79706/p/lib -Wl,-rpath,/root/.conan2/p/b/ame_e193e31ec79706/p/lib  -lm && :
/opt/rh/gcc-toolset-10/root/usr/bin/ld: CMakeFiles/test_package.dir/test_package.c.o: in function `main':
test_package.c:(.text.startup+0x8): undefined reference to `XML_ParserCreate'
/opt/rh/gcc-toolset-10/root/usr/bin/ld: test_package.c:(.text.startup+0x20): undefined reference to `XML_SetUserData'
/opt/rh/gcc-toolset-10/root/usr/bin/ld: test_package.c:(.text.startup+0x32): undefined reference to `XML_SetElementHandler'
/opt/rh/gcc-toolset-10/root/usr/bin/ld: test_package.c:(.text.startup+0x3a): undefined reference to `XML_ParserFree'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
```

I understand that it is not desirable to handle the lib/lib64 difference in conan directly, and I also know that minor fixes to recipes can solve the issue. 

My question is simply: is it expected that in this particular case the local dev workflow is broken ?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: docbrown1955
issue_14436: state: open
title: [feature] Allow parameter addition for SystemPackageManagerTool
body: ### What is your suggestion?

Hello, when using conan and its SystemPackageManagerTool to install debian packages via apt-get, it would be nice to have the option to add flags. 

Mainly interesting for us would be the "--allow-downgrades" option.

I guess, this would affect mainly the code here in the SystemPackageManager class:
![image](https://github.com/conan-io/conan/assets/52745439/92f989e4-f455-4f2d-8f4b-690b53c8c4fa)

Is it feasible to introduce such a feature for Conan v1 (since my company still uses v1)?

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: mh-ka
issue_14431: state: open
title: [question] add flags for configure
body: ### What is your question?

Hello everyone!

I'm writting a simple concurancy project with gtest. I need a diffrent sanitizers for test (thread, memory, etc). I use conan2 for downloading gtest from conan-center. I like this simplicity. But for the sanitizers to work correctly, I need to build gtest with certain flags. I can use conan to build gtest, but I haven't found how I can set the flags I need.
I suppose that here we can set it:
```
    def configure(self):
        if self.options.shared:
            self.options.rm_safe("fPIC")
        if self.settings.compiler == "clang":
            if self.settings.build_type == "Debug":
                pass
 ```
Can you help me?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: k-morozov
issue_14428: state: open
title: Fix pkgconfig name collision on Windows
body: Changelog: (Bugfix): Fix pkgconfig name collision on Windows

This fix is related to https://github.com/conan-io/conan/issues/10341. The previous fix did not take into account cases insensitive filesystems. As a result the issue was still present on Windows. OpenEXR 2.x is an example of affected recipe. The "OpenEXR.pc" file for the "openexr_ilmimf" component was overwritten by "openexr.pc" created based on package name.

- [ ] Refer to the issue that supports this Pull Request.
- [ ] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [ ] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

user: domin144
issue_14425: state: open
title: [bug] `tools.gnu:host_triplet` ignored for build context
body: ### Environment details

* Operating System+version: Macos 13.4.1
* Compiler+version: apple clang 14.0.3
* Conan version: 2.0.9
* Python version: 3.11


### Steps to reproduce

Attempt to cross build any autotools-based recipe from conan center, such as libbacktrace/cci.20210118, while having `[conf]` section in your build profile. The flags and settings get leaked into the host context.

From the logs below, you can clearly see:

in the `Requirements` section:

```
libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c:8d4455ce70884ca03fcc6d108c197cdbacfe5775 - Build
```

In the `Build requirements` section:

```
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c:86b93d2aa3f84474082e36a0af8c4ed16d409469#d6903dbe0b9443b55fb55cc86ee1afcd - Cache
```

So, only `libbacktrace` for the host context (Android) should be built.

Yet, I get the error

```
ERROR: libbacktrace/cci.20210118: Error in generate() method, line 72
	tc = AutotoolsToolchain(self)
	ConanException: Unknown 'x86_64_haswell' machine, Conan doesn't know how to translate it to the GNU triplet, please report at  https://github.com/conan-io/conan/issues
```

which should not happen when building for Android.

### Logs

```
======== Input profiles ========
Profile host:
[settings]
arch=armv8
build_type=DevRelease
compiler=clang
compiler.libcxx=c++_static
compiler.libcxx.version=2
compiler.version=14.0.7
os=Android
os.api_level=21
[tool_requires]
*: android_ndk/r25c@microblink/stable
[conf]
tools.cmake.cmake_layout:build_folder_vars=['settings.os', 'settings.os.sdk', 'settings.arch', 'settings.compiler', 'settings.compiler.version', 'settings.compiler.sanitizers', 'settings.compiler.link_time_optimization']
tools.files.download:retry=5
tools.files.download:retry_wait=2
tools.cmake.cmaketoolchain:generator=Ninja

Profile build:
[settings]
arch=x86_64_haswell
build_type=Release
compiler=clang
compiler.libcxx=libc++v2
compiler.version=16.0.5
os=Linux
[tool_requires]
*: mb_foundation/0.1.0@microblink/stable
[conf]
tools.cmake.cmake_layout:build_folder_vars=['settings.os', 'settings.os.sdk', 'settings.arch', 'settings.compiler', 'settings.compiler.version', 'settings.compiler.sanitizers', 'settings.compiler.link_time_optimization']
tools.files.download:retry=5
tools.files.download:retry_wait=2
tools.cmake.cmaketoolchain:generator=Ninja
tools.build:compiler_executables={'c': '/usr/bin/clang', 'cpp': '/usr/bin/clang++'}
tools.cmake.cmaketoolchain:system_name=Linux
tools.cmake.cmaketoolchain:system_processor=x86_64
tools.build:cflags=['-mavx', '-march=haswell', '-mtune=haswell', '-mavx2']
tools.build:cxxflags=['-mavx', '-march=haswell', '-mtune=haswell', '-mavx2']
tools.build:sharedlinkflags=['-Wl,-rpath,/usr/local/lib/x86_64-unknown-linux-gnu']
tools.build:exelinkflags=['-Wl,-rpath,/usr/local/lib/x86_64-unknown-linux-gnu']


======== Computing dependency graph ========
android_ndk/r25c@microblink/stable: Not found in local cache, looking in remotes...
android_ndk/r25c@microblink/stable: Checking remote: mbtemp
android_ndk/r25c@microblink/stable: Downloaded recipe revision b13140059da04a09f3fdd1adbc080408
Graph root
    conanfile.py (ml_models_image_capture/1.0.0): /opt/jenkins/android-arm64-samsung-s21-ultra/root/E0/b/core-nn-models-image-capture/conanfile.py
Requirements
    adv_obfuscator/20170904.0@nenad/testing#35b6a767471e030de9640d6676d3035b - Cache
    boost/1.80@nenad/testing#b5f6784ab18ef24bc1423972f4d4c54e - Cache
    cmake_build/0.1.0@nenad/testing#40d33964dbe3f77e4f766bb8c34afd82 - Cache
    concurrent_queue/0.1.0@nenad/testing#63dcb9780d5aec456a2a83217fa55d79 - Cache
    config_ex/0.1.0@nenad/testing#8ac20ee44de37e4bcf5dc764d5d9f9fb - Cache
    core_utils/1.0.0@nenad/testing#5a16b213ec5f90cf8c61e4590efd82b0 - Cache
    cpuinfo/20230428.1@nenad/testing#c1e17d1098c745caa4462abaef85f8c6 - Cache
    eigen/3.4.0@nenad/testing#f0f42f40b9dcd259bae0b92feacca4f5 - Cache
    err/1.0.0@nenad/testing#deb27027360b5937da47ff192cdeb3e4 - Cache
    functionoid/0.1.0@nenad/testing#c1f5773dcea65d05d27a7f83075c777a - Cache
    gtest/1.11.0@nenad/testing#b86e737a89c05fb7e92eeb24dcfd4e05 - Cache
    hash/1.0.0@nenad/testing#5ec3db8c88c4a679e5d5ad6c6b0e1fe4 - Cache
    kiwaku/20230522.1@nenad/testing#caab153f2877dacbbaf89b0b8fb46de0 - Cache
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c - Cache
    libjpeg_turbo/2.1.4.1@nenad/testing#328a17322058cd185ed6a6c4899b9e2e - Cache
    libpng/1.6.38.1@nenad/testing#7c45891acf66fd0e7b9c6f136c8ccfbe - Cache
    log_and_timer/0.1.0@nenad/testing#6346bb0a705637150950be0af5af33ad - Cache
    micro_ecc/1.0.0@nenad/testing#e3617d4b177b9e352ae1fde6839839fe - Cache
    mmap/1.0.0@nenad/testing#3aafec364b424c5b266a7bae5938b6a7 - Cache
    nlohmann_json/3.10.4#2d3ba0c641692cca9fb4514e05154688 - Cache
    opencv/4.6.0.2@nenad/testing#a037b128042b4e7f9d5ff6663bcb61ed - Cache
    protection/1.0.0@nenad/testing#a4005e34e83d1701812c8194f66c2fa2 - Cache
    protobuf/3.21.7@nenad/testing#4968cc8799438f3746a0ffef6f8c267a - Cache
    range-v3/0.12.0#abb9932b80d96eaf8fc992debe3870ed - Cache
    rapidjson/1.1.5@nenad/testing#d9cb20226d91dc7437d38f4433f0072c - Cache
    runner/1.0.0@nenad/testing#b266af8dce15521fa423ae03cc117d72 - Cache
    std_fix/1.0.0@nenad/testing#49129ddf1d1a32deef32ba86f2897bde - Cache
    sweater/1.0.0@nenad/testing#5aa855c096711beb6d24b207f7c13d90 - Cache
    utfcpp/3.2.1@nenad/testing#a1f070448470fee48fe8377c5e64e08b - Cache
    version_and_paths/0.1.0@nenad/testing#1d4ece2deec299f3dc8594539e89328a - Cache
    xnnpack/20230525.0@nenad/testing#2d11e64818e995d6376f3e7f9a3a75ed - Cache
    zlib/1.2.13@nenad/testing#73ea6005846950a84f51347ff7e13b99 - Cache
Test requirements
    boost/1.80@nenad/testing#b5f6784ab18ef24bc1423972f4d4c54e - Cache
    cmake_build/0.1.0@nenad/testing#40d33964dbe3f77e4f766bb8c34afd82 - Cache
    config_ex/0.1.0@nenad/testing#8ac20ee44de37e4bcf5dc764d5d9f9fb - Cache
    functionoid/0.1.0@nenad/testing#c1f5773dcea65d05d27a7f83075c777a - Cache
    gtest/1.11.0@nenad/testing#b86e737a89c05fb7e92eeb24dcfd4e05 - Cache
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c - Cache
    log_and_timer/0.1.0@nenad/testing#6346bb0a705637150950be0af5af33ad - Cache
    tensorflow/1.13.1@nenad/testing#611bd2364b1c74efbeb058065a492f2c - Cache
    version_and_paths/0.1.0@nenad/testing#1d4ece2deec299f3dc8594539e89328a - Cache
Build requirements
    adv_obfuscator/20170904.0@nenad/testing#35b6a767471e030de9640d6676d3035b - Cache
    android_ndk/r25c@microblink/stable#b13140059da04a09f3fdd1adbc080408 - Downloaded (mbtemp)
    boost/1.80@nenad/testing#b5f6784ab18ef24bc1423972f4d4c54e - Cache
    cmake_build/0.1.0@nenad/testing#40d33964dbe3f77e4f766bb8c34afd82 - Cache
    concurrent_queue/0.1.0@nenad/testing#63dcb9780d5aec456a2a83217fa55d79 - Cache
    config_ex/0.1.0@nenad/testing#8ac20ee44de37e4bcf5dc764d5d9f9fb - Cache
    core_utils/1.0.0@nenad/testing#5a16b213ec5f90cf8c61e4590efd82b0 - Cache
    cpuinfo/20230428.1@nenad/testing#c1e17d1098c745caa4462abaef85f8c6 - Cache
    eigen/3.4.0@nenad/testing#f0f42f40b9dcd259bae0b92feacca4f5 - Cache
    err/1.0.0@nenad/testing#deb27027360b5937da47ff192cdeb3e4 - Cache
    functionoid/0.1.0@nenad/testing#c1f5773dcea65d05d27a7f83075c777a - Cache
    gtest/1.11.0@nenad/testing#b86e737a89c05fb7e92eeb24dcfd4e05 - Cache
    hash/1.0.0@nenad/testing#5ec3db8c88c4a679e5d5ad6c6b0e1fe4 - Cache
    kiwaku/20230522.1@nenad/testing#caab153f2877dacbbaf89b0b8fb46de0 - Cache
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c - Cache
    libjpeg_turbo/2.1.4.1@nenad/testing#328a17322058cd185ed6a6c4899b9e2e - Cache
    libpng/1.6.38.1@nenad/testing#7c45891acf66fd0e7b9c6f136c8ccfbe - Cache
    log_and_timer/0.1.0@nenad/testing#6346bb0a705637150950be0af5af33ad - Cache
    mb_foundation/0.1.0@microblink/stable#694630970e79763bcf52a829122aba69 - Cache
    micro_ecc/1.0.0@nenad/testing#e3617d4b177b9e352ae1fde6839839fe - Cache
    ml_models_image_capture/1.0.0 - Editable
    mmap/1.0.0@nenad/testing#3aafec364b424c5b266a7bae5938b6a7 - Cache
    nasm/2.14#d4c0f102da173fe6ea0fe5c486a29709 - Cache
    nlohmann_json/3.10.4#2d3ba0c641692cca9fb4514e05154688 - Cache
    opencv/4.6.0.2@nenad/testing#a037b128042b4e7f9d5ff6663bcb61ed - Cache
    protection/1.0.0@nenad/testing#a4005e34e83d1701812c8194f66c2fa2 - Cache
    protobuf/3.21.7@nenad/testing#4968cc8799438f3746a0ffef6f8c267a - Cache
    range-v3/0.12.0#abb9932b80d96eaf8fc992debe3870ed - Cache
    rapidjson/1.1.5@nenad/testing#d9cb20226d91dc7437d38f4433f0072c - Cache
    runner/1.0.0@nenad/testing#b266af8dce15521fa423ae03cc117d72 - Cache
    std_fix/1.0.0@nenad/testing#49129ddf1d1a32deef32ba86f2897bde - Cache
    sweater/1.0.0@nenad/testing#5aa855c096711beb6d24b207f7c13d90 - Cache
    tensorflow/1.13.1@nenad/testing#611bd2364b1c74efbeb058065a492f2c - Cache
    utfcpp/3.2.1@nenad/testing#a1f070448470fee48fe8377c5e64e08b - Cache
    version_and_paths/0.1.0@nenad/testing#1d4ece2deec299f3dc8594539e89328a - Cache
    xnnpack/20230525.0@nenad/testing#2d11e64818e995d6376f3e7f9a3a75ed - Cache
    zlib/1.2.13@nenad/testing#73ea6005846950a84f51347ff7e13b99 - Cache
Python requires
    conanfile_utils/0.1.0@nenad/testing#22e39d9779ab95f144c79a6c34b21146 - Cache
Resolved version ranges
    boost/[~1.80]@nenad/testing: boost/1.80@nenad/testing
    boost/[~1]@nenad/testing: boost/1.80@nenad/testing
    cmake_build/[~0]@nenad/testing: cmake_build/0.1.0@nenad/testing
    conanfile_utils/[~0]@nenad/testing: conanfile_utils/0.1.0@nenad/testing
    concurrent_queue/[~0]@nenad/testing: concurrent_queue/0.1.0@nenad/testing
    config_ex/[~0]@nenad/testing: config_ex/0.1.0@nenad/testing
    core_utils/[~1]@nenad/testing: core_utils/1.0.0@nenad/testing
    cpuinfo/[~20230428]@nenad/testing: cpuinfo/20230428.1@nenad/testing
    eigen/[~3.4.0]@nenad/testing: eigen/3.4.0@nenad/testing
    err/[~1]@nenad/testing: err/1.0.0@nenad/testing
    functionoid/[~0]@nenad/testing: functionoid/0.1.0@nenad/testing
    gtest/[~1]@nenad/testing: gtest/1.11.0@nenad/testing
    hash/[~1]@nenad/testing: hash/1.0.0@nenad/testing
    kiwaku/[~20230522]@nenad/testing: kiwaku/20230522.1@nenad/testing
    libjpeg_turbo/[~2.1]@nenad/testing: libjpeg_turbo/2.1.4.1@nenad/testing
    libpng/[~1.6]@nenad/testing: libpng/1.6.38.1@nenad/testing
    log_and_timer/[~0]@nenad/testing: log_and_timer/0.1.0@nenad/testing
    micro_ecc/[~1]@nenad/testing: micro_ecc/1.0.0@nenad/testing
    mmap/[~1]@nenad/testing: mmap/1.0.0@nenad/testing
    opencv/[~4.6.0]@nenad/testing: opencv/4.6.0.2@nenad/testing
    protection/[~1]@nenad/testing: protection/1.0.0@nenad/testing
    protobuf/[~3.21]@nenad/testing: protobuf/3.21.7@nenad/testing
    runner/[~1.0]@nenad/testing: runner/1.0.0@nenad/testing
    std_fix/[~1]@nenad/testing: std_fix/1.0.0@nenad/testing
    sweater/[~1]@nenad/testing: sweater/1.0.0@nenad/testing
    tensorflow/[~1.13.1]@nenad/testing: tensorflow/1.13.1@nenad/testing
    version_and_paths/[~0]@nenad/testing: version_and_paths/0.1.0@nenad/testing
    xnnpack/[~20230525]@nenad/testing: xnnpack/20230525.0@nenad/testing
    zlib/[~1.2]@nenad/testing: zlib/1.2.13@nenad/testing

======== Computing necessary packages ========
android_ndk/r25c@microblink/stable: Checking 1 compatible configurations:
android_ndk/r25c@microblink/stable: '63fead0844576fc02943e16909f08fcdddd6f44b': 
android_ndk/r25c@microblink/stable: Main binary package 'f8da2d2d1af868e90384529932ffe9297cc1e8d7' missing. Using compatible package '63fead0844576fc02943e16909f08fcdddd6f44b'
Requirements
    adv_obfuscator/20170904.0@nenad/testing#35b6a767471e030de9640d6676d3035b:df6c97fde094ef9a36f63e81c41e5253e72a2977#f6396f5a866f840a971e62c438a902c0 - Cache
    boost/1.80@nenad/testing#b5f6784ab18ef24bc1423972f4d4c54e:da39a3ee5e6b4b0d3255bfef95601890afd80709#e41614b4db81f145a4b79617850f5bbd - Cache
    cmake_build/0.1.0@nenad/testing#40d33964dbe3f77e4f766bb8c34afd82:da39a3ee5e6b4b0d3255bfef95601890afd80709#3334e37fc79ace9b71783a931daa8c77 - Cache
    concurrent_queue/0.1.0@nenad/testing#63dcb9780d5aec456a2a83217fa55d79:df6c97fde094ef9a36f63e81c41e5253e72a2977#56ccfaee0337bf802fe05933fc1f305e - Cache
    config_ex/0.1.0@nenad/testing#8ac20ee44de37e4bcf5dc764d5d9f9fb:df6c97fde094ef9a36f63e81c41e5253e72a2977#164af33db0fcc9a504d31c2febdf22c9 - Cache
    core_utils/1.0.0@nenad/testing#5a16b213ec5f90cf8c61e4590efd82b0:ef2bf8c999dad9e209db0f2020f6ee975fc652ad - Build
    cpuinfo/20230428.1@nenad/testing#c1e17d1098c745caa4462abaef85f8c6:5aa986688f6e4e13d9e383ef3dfd613a396c09a3 - Build
    eigen/3.4.0@nenad/testing#f0f42f40b9dcd259bae0b92feacca4f5:df6c97fde094ef9a36f63e81c41e5253e72a2977#738c6d38c60eb26068fb3b50f6515107 - Cache
    err/1.0.0@nenad/testing#deb27027360b5937da47ff192cdeb3e4:df6c97fde094ef9a36f63e81c41e5253e72a2977#c1027d4c74ecbba68b5cb484f089cb8b - Cache
    functionoid/0.1.0@nenad/testing#c1f5773dcea65d05d27a7f83075c777a:df6c97fde094ef9a36f63e81c41e5253e72a2977#0cba0b5c615a0f448595e7a90e2ec147 - Cache
    gtest/1.11.0@nenad/testing#b86e737a89c05fb7e92eeb24dcfd4e05:5d65b33c7889f56c6f3c52e81fd88d81b103ddbd - Build
    hash/1.0.0@nenad/testing#5ec3db8c88c4a679e5d5ad6c6b0e1fe4:78bfac62eaab7fb1213eed941901bf5558635451 - Build
    kiwaku/20230522.1@nenad/testing#caab153f2877dacbbaf89b0b8fb46de0:df6c97fde094ef9a36f63e81c41e5253e72a2977#f27f47dab2e797fd663ef896604ac62b - Cache
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c:8d4455ce70884ca03fcc6d108c197cdbacfe5775 - Build
    libjpeg_turbo/2.1.4.1@nenad/testing#328a17322058cd185ed6a6c4899b9e2e:5aa986688f6e4e13d9e383ef3dfd613a396c09a3 - Build
    libpng/1.6.38.1@nenad/testing#7c45891acf66fd0e7b9c6f136c8ccfbe:7069828a1d8e420b2d2c54294ab52e9216db12cf - Build
    log_and_timer/0.1.0@nenad/testing#6346bb0a705637150950be0af5af33ad:aa007c40036e973d39810eabbf08d5ac5a5f5d29 - Build
    micro_ecc/1.0.0@nenad/testing#e3617d4b177b9e352ae1fde6839839fe:f843e0d308f88029a3d875223da5b535db8ea8b3 - Build
    mmap/1.0.0@nenad/testing#3aafec364b424c5b266a7bae5938b6a7:df6c97fde094ef9a36f63e81c41e5253e72a2977#94044f158bc9243777bd77bbbfc276f4 - Cache
    nlohmann_json/3.10.4#2d3ba0c641692cca9fb4514e05154688:da39a3ee5e6b4b0d3255bfef95601890afd80709#c778d4e6040abc2114a46c9599471b3c - Cache
    opencv/4.6.0.2@nenad/testing#a037b128042b4e7f9d5ff6663bcb61ed:910803cdd71c277b4566e4d8e6c7987bf1398ffd - Build
    protection/1.0.0@nenad/testing#a4005e34e83d1701812c8194f66c2fa2:bc06166cdec6c251469b9791ebb23446ae9b275c - Build
    protobuf/3.21.7@nenad/testing#4968cc8799438f3746a0ffef6f8c267a:5aa986688f6e4e13d9e383ef3dfd613a396c09a3 - Build
    range-v3/0.12.0#abb9932b80d96eaf8fc992debe3870ed:da39a3ee5e6b4b0d3255bfef95601890afd80709#ecc6172c3cd6694c36d1cd98a702deb0 - Cache
    rapidjson/1.1.5@nenad/testing#d9cb20226d91dc7437d38f4433f0072c:df6c97fde094ef9a36f63e81c41e5253e72a2977#b3ae0ec1d159c57de4e34638419ec47c - Cache
    runner/1.0.0@nenad/testing#b266af8dce15521fa423ae03cc117d72:4070ae2a77e8190d34c6e1eff11944077888289b - Build
    std_fix/1.0.0@nenad/testing#49129ddf1d1a32deef32ba86f2897bde:df6c97fde094ef9a36f63e81c41e5253e72a2977#cd264f67a39b435409963d56bd6c3950 - Cache
    sweater/1.0.0@nenad/testing#5aa855c096711beb6d24b207f7c13d90:c1c2c609d8c15b15d2301bd418abd520bf1d90f3 - Build
    utfcpp/3.2.1@nenad/testing#a1f070448470fee48fe8377c5e64e08b:df6c97fde094ef9a36f63e81c41e5253e72a2977#aa77a3eefd1f6446a6b836fb887cd13e - Cache
    version_and_paths/0.1.0@nenad/testing#1d4ece2deec299f3dc8594539e89328a:df6c97fde094ef9a36f63e81c41e5253e72a2977#23c2fcf758f23e8b428195b19d8f5713 - Cache
    xnnpack/20230525.0@nenad/testing#2d11e64818e995d6376f3e7f9a3a75ed:e31783176ae1ccda6d16addc01b5988d5648a8dd - Build
    zlib/1.2.13@nenad/testing#73ea6005846950a84f51347ff7e13b99:df6c97fde094ef9a36f63e81c41e5253e72a2977 - Build
Test requirements
    boost/1.80@nenad/testing#b5f6784ab18ef24bc1423972f4d4c54e:da39a3ee5e6b4b0d3255bfef95601890afd80709#e41614b4db81f145a4b79617850f5bbd - Cache
    cmake_build/0.1.0@nenad/testing#40d33964dbe3f77e4f766bb8c34afd82:da39a3ee5e6b4b0d3255bfef95601890afd80709#3334e37fc79ace9b71783a931daa8c77 - Cache
    config_ex/0.1.0@nenad/testing#8ac20ee44de37e4bcf5dc764d5d9f9fb:df6c97fde094ef9a36f63e81c41e5253e72a2977#164af33db0fcc9a504d31c2febdf22c9 - Cache
    functionoid/0.1.0@nenad/testing#c1f5773dcea65d05d27a7f83075c777a:df6c97fde094ef9a36f63e81c41e5253e72a2977#0cba0b5c615a0f448595e7a90e2ec147 - Cache
    gtest/1.11.0@nenad/testing#b86e737a89c05fb7e92eeb24dcfd4e05:5d65b33c7889f56c6f3c52e81fd88d81b103ddbd - Build
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c:8d4455ce70884ca03fcc6d108c197cdbacfe5775 - Build
    log_and_timer/0.1.0@nenad/testing#6346bb0a705637150950be0af5af33ad:aa007c40036e973d39810eabbf08d5ac5a5f5d29 - Build
    tensorflow/1.13.1@nenad/testing#611bd2364b1c74efbeb058065a492f2c:999d473973a6dcba20e8b20b357a85267c486456 - Build
    version_and_paths/0.1.0@nenad/testing#1d4ece2deec299f3dc8594539e89328a:df6c97fde094ef9a36f63e81c41e5253e72a2977#23c2fcf758f23e8b428195b19d8f5713 - Cache
Build requirements
    adv_obfuscator/20170904.0@nenad/testing#35b6a767471e030de9640d6676d3035b:df6c97fde094ef9a36f63e81c41e5253e72a2977#f6396f5a866f840a971e62c438a902c0 - Cache
    android_ndk/r25c@microblink/stable#b13140059da04a09f3fdd1adbc080408:63fead0844576fc02943e16909f08fcdddd6f44b#8a6c129c2da8535c1a07d908217d6f12 - Download (mbtemp)
    boost/1.80@nenad/testing#b5f6784ab18ef24bc1423972f4d4c54e:da39a3ee5e6b4b0d3255bfef95601890afd80709#e41614b4db81f145a4b79617850f5bbd - Cache
    cmake_build/0.1.0@nenad/testing#40d33964dbe3f77e4f766bb8c34afd82:da39a3ee5e6b4b0d3255bfef95601890afd80709#3334e37fc79ace9b71783a931daa8c77 - Cache
    concurrent_queue/0.1.0@nenad/testing#63dcb9780d5aec456a2a83217fa55d79:df6c97fde094ef9a36f63e81c41e5253e72a2977#56ccfaee0337bf802fe05933fc1f305e - Cache
    config_ex/0.1.0@nenad/testing#8ac20ee44de37e4bcf5dc764d5d9f9fb:df6c97fde094ef9a36f63e81c41e5253e72a2977#164af33db0fcc9a504d31c2febdf22c9 - Cache
    core_utils/1.0.0@nenad/testing#5a16b213ec5f90cf8c61e4590efd82b0:b3d926b711cd4173db90a3e923829177ce00214d#40d8bad28622a03a9f1e2a79bc701a81 - Cache
    cpuinfo/20230428.1@nenad/testing#c1e17d1098c745caa4462abaef85f8c6:b96f121ae7bd050c9399376b94893e2f54ce9299#a76278c339e464f644f17a7fc9929b06 - Cache
    eigen/3.4.0@nenad/testing#f0f42f40b9dcd259bae0b92feacca4f5:df6c97fde094ef9a36f63e81c41e5253e72a2977#738c6d38c60eb26068fb3b50f6515107 - Cache
    err/1.0.0@nenad/testing#deb27027360b5937da47ff192cdeb3e4:df6c97fde094ef9a36f63e81c41e5253e72a2977#c1027d4c74ecbba68b5cb484f089cb8b - Cache
    functionoid/0.1.0@nenad/testing#c1f5773dcea65d05d27a7f83075c777a:df6c97fde094ef9a36f63e81c41e5253e72a2977#0cba0b5c615a0f448595e7a90e2ec147 - Cache
    gtest/1.11.0@nenad/testing#b86e737a89c05fb7e92eeb24dcfd4e05:b4173e2804c8ce49cbcd21f9a1251a7966f95167#2c49b8edd26b6381766d4a7f183bc18c - Cache
    hash/1.0.0@nenad/testing#5ec3db8c88c4a679e5d5ad6c6b0e1fe4:94d72d24d1af678894cad1ad9b8a4442f011c087#5568f352385b9e870ff6621c81f61bef - Cache
    kiwaku/20230522.1@nenad/testing#caab153f2877dacbbaf89b0b8fb46de0:df6c97fde094ef9a36f63e81c41e5253e72a2977#f27f47dab2e797fd663ef896604ac62b - Cache
    libbacktrace/cci.20210118#ec1aa63bbc10145c6a299e68e711670c:86b93d2aa3f84474082e36a0af8c4ed16d409469#d6903dbe0b9443b55fb55cc86ee1afcd - Cache
    libjpeg_turbo/2.1.4.1@nenad/testing#328a17322058cd185ed6a6c4899b9e2e:b96f121ae7bd050c9399376b94893e2f54ce9299#b5983eb32817b48f752056d74b892f91 - Cache
    libpng/1.6.38.1@nenad/testing#7c45891acf66fd0e7b9c6f136c8ccfbe:017119d1da71621e9af75c24e5a157f751dc61db#97c6a0206415f8cc81186c555135543e - Cache
    log_and_timer/0.1.0@nenad/testing#6346bb0a705637150950be0af5af33ad:fa5b7f87a8cf8383c0ffc14f3a637a3913e3f07c#fd1c26048cc65d25199ce1d9ec808ded - Cache
    mb_foundation/0.1.0@microblink/stable#694630970e79763bcf52a829122aba69:da39a3ee5e6b4b0d3255bfef95601890afd80709#0ba8627bd47edc3a501e8f0eb9a79e5e - Cache
    micro_ecc/1.0.0@nenad/testing#e3617d4b177b9e352ae1fde6839839fe:183c369df0ed4efa9c7b3e7da65ed9e0cf816606#50ac186d10e15a79b8d4a1f29deaf5fe - Cache
    ml_models_image_capture/1.0.0:40cdecf828f48a804236057917c280a8193fe5fe - Editable
    mmap/1.0.0@nenad/testing#3aafec364b424c5b266a7bae5938b6a7:df6c97fde094ef9a36f63e81c41e5253e72a2977#94044f158bc9243777bd77bbbfc276f4 - Cache
    nlohmann_json/3.10.4#2d3ba0c641692cca9fb4514e05154688:da39a3ee5e6b4b0d3255bfef95601890afd80709#c778d4e6040abc2114a46c9599471b3c - Cache
    opencv/4.6.0.2@nenad/testing#a037b128042b4e7f9d5ff6663bcb61ed:e812f5fbe94601006590a4d102e51a1de0171f37#2bd2be58e4ccb75224702f63f6ae997b - Cache
    protection/1.0.0@nenad/testing#a4005e34e83d1701812c8194f66c2fa2:d6a9d4677a97cf47a385487f540a6e23dec49160#f07f5f6f48f81de6618644ea17b61fb2 - Cache
    protobuf/3.21.7@nenad/testing#4968cc8799438f3746a0ffef6f8c267a:b96f121ae7bd050c9399376b94893e2f54ce9299#b240c97e0dd9cb75bd65710281600540 - Cache
    range-v3/0.12.0#abb9932b80d96eaf8fc992debe3870ed:da39a3ee5e6b4b0d3255bfef95601890afd80709#ecc6172c3cd6694c36d1cd98a702deb0 - Cache
    rapidjson/1.1.5@nenad/testing#d9cb20226d91dc7437d38f4433f0072c:df6c97fde094ef9a36f63e81c41e5253e72a2977#b3ae0ec1d159c57de4e34638419ec47c - Cache
    runner/1.0.0@nenad/testing#b266af8dce15521fa423ae03cc117d72:979fcda0da91a193b86d245ed659d1265c9fce32#54271c0de5361746a1478e330901d406 - Cache
    std_fix/1.0.0@nenad/testing#49129ddf1d1a32deef32ba86f2897bde:df6c97fde094ef9a36f63e81c41e5253e72a2977#cd264f67a39b435409963d56bd6c3950 - Cache
    sweater/1.0.0@nenad/testing#5aa855c096711beb6d24b207f7c13d90:c91164e3f83aaf1c19e4680a3c61aa5f8db30c79#25c702e7622497f45cae731fd61b9957 - Cache
    tensorflow/1.13.1@nenad/testing#611bd2364b1c74efbeb058065a492f2c:b2207d92bee23a1659ae98a9c501e4da07ba2aa5#0a8c719ad29ba680e9c9c17981b89131 - Cache
    utfcpp/3.2.1@nenad/testing#a1f070448470fee48fe8377c5e64e08b:df6c97fde094ef9a36f63e81c41e5253e72a2977#aa77a3eefd1f6446a6b836fb887cd13e - Cache
    version_and_paths/0.1.0@nenad/testing#1d4ece2deec299f3dc8594539e89328a:df6c97fde094ef9a36f63e81c41e5253e72a2977#23c2fcf758f23e8b428195b19d8f5713 - Cache
    xnnpack/20230525.0@nenad/testing#2d11e64818e995d6376f3e7f9a3a75ed:d275fb051f4b37146e93133cd39b52f98189a710#83e469c56840afbbd4698052313b51ba - Cache
    zlib/1.2.13@nenad/testing#73ea6005846950a84f51347ff7e13b99:b96f121ae7bd050c9399376b94893e2f54ce9299#efdfda960271f52b4425ce17b9c344cc - Cache
Skipped binaries
    nasm/2.14

======== Installing packages ========

-------- Downloading 1 package --------
android_ndk/r25c@microblink/stable: Retrieving package 63fead0844576fc02943e16909f08fcdddd6f44b from remote 'mbtemp' 
android_ndk/r25c@microblink/stable: Downloading 542.9MB conan_package.tgz
android_ndk/r25c@microblink/stable: Downloaded 371.2MB 68% conan_package.tgz
android_ndk/r25c@microblink/stable: Decompressing 542.9MB conan_package.tgz
android_ndk/r25c@microblink/stable: Package installed 63fead0844576fc02943e16909f08fcdddd6f44b
android_ndk/r25c@microblink/stable: Downloaded package revision 8a6c129c2da8535c1a07d908217d6f12
mb_foundation/0.1.0@microblink/stable: Already installed! (1 of 53)
adv_obfuscator/20170904.0@nenad/testing: Already installed! (2 of 53)
android_ndk/r25c@microblink/stable: Creating CC environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang
android_ndk/r25c@microblink/stable: Creating CXX environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang++
android_ndk/r25c@microblink/stable: Creating LD environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/ld
android_ndk/r25c@microblink/stable: Creating AR environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-ar
android_ndk/r25c@microblink/stable: Creating AS environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-as
android_ndk/r25c@microblink/stable: Creating RANLIB environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-ranlib
android_ndk/r25c@microblink/stable: Creating STRIP environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-strip
android_ndk/r25c@microblink/stable: Creating ADDR2LINE environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-addr2line
android_ndk/r25c@microblink/stable: Creating NM environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-nm
android_ndk/r25c@microblink/stable: Creating OBJCOPY environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-objcopy
android_ndk/r25c@microblink/stable: Creating OBJDUMP environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-objdump
android_ndk/r25c@microblink/stable: Creating READELF environment variable: /home/jenkins/.conan2/p/andro1d3264d3db6a1/p/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-readelf
boost/1.80@nenad/testing: Already installed! (4 of 53)
cmake_build/0.1.0@nenad/testing: Already installed! (5 of 53)
nlohmann_json/3.10.4: Already installed! (6 of 53)
range-v3/0.12.0: Already installed! (7 of 53)
version_and_paths/0.1.0@nenad/testing: Already installed! (8 of 53)
concurrent_queue/0.1.0@nenad/testing: Already installed! (9 of 53)
libbacktrace/cci.20210118: Already installed! (10 of 53)

-------- Installing package libbacktrace/cci.20210118 (11 of 53) --------
libbacktrace/cci.20210118: Building from source
libbacktrace/cci.20210118: Package libbacktrace/cci.20210118:8d4455ce70884ca03fcc6d108c197cdbacfe5775
libbacktrace/cci.20210118: Copying sources to build folder
libbacktrace/cci.20210118: Building your package in /home/jenkins/.conan2/p/b/libba5b588ccef091f/b
libbacktrace/cci.20210118: Calling generate()
libbacktrace/cci.20210118: Generators folder: /home/jenkins/.conan2/p/b/libba5b588ccef091f/b/build-devrelease/conan
ERROR: libbacktrace/cci.20210118: Error in generate() method, line 72
	tc = AutotoolsToolchain(self)
	ConanException: Unknown 'x86_64_haswell' machine, Conan doesn't know how to translate it to the GNU triplet, please report at  https://github.com/conan-io/conan/issues
```
user: DoDoENT
issue_14424: state: open
title: [question] Handling different versions of tools for packages
body: ### What is your question?

Dear Conan Folks,

I have a question with respect to tool packages. Our use-case is:
- We use matlab and define some toolbox packages which are used by different other packages. 
Question is about handling different matlab versions.
We thought of two different possibilities:
1- Use options for the matlab toolbox packages , options for different versions of matlab. However, this leads to all dependnecies upwards to include options in their recipes.
2- Use different packages for different matlab versions. However, this leads to maintenence of same code build differently for different matlab versions.

Could you please help me what is the suitable approach for this use case?
Thanks!


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: maitrey
issue_14422: state: open
title: [question] tool requirements not available on package_info(), how do we handle pkg_config.fill_cpp_info if pkgconf is not installed on the OS?
body: ### What is your question?

This is on Conan 1.x.

I'm trying to build `libudev/system` which on the `package_info()` method calls `pkg_config.fill_cpp_info()` which relies on the `pkg-conf` executable.

Since I don't have it on my OS, I decided to include it as a `tool_requirement()`. But that doesn't work for 2 reasons:
1. The `pkgconf` recipe provides an app named `pkgconf` but `fill_cpp_info()` expects it to be called `pkg-conf`. No big deal, that can be overridden with `tools.gnu:pkg_config = 'pkgconf'`, but I thought it was an interesting inconsistency.
2. The `PATH` from the `tool_requirements` doesn't get set on `package_info()`, so even if I add `pkgconf` as a build requirement and set the name of the executable on the profile as mentioned above, the recipe still fails to build.

Diff:
```diff
diff --git a/recipes/libudev/all/conanfile.py b/recipes/libudev/all/conanfile.py
index 46c164d11..b73f8ace7 100644
--- a/recipes/libudev/all/conanfile.py
+++ b/recipes/libudev/all/conanfile.py
@@ -27,6 +27,9 @@ class LibUDEVConan(ConanFile):
     def package_id(self):
         self.info.clear()
 
+    def build_requirements(self):
+        self.build_requires("pkgconf/1.9.5")
+
     def system_requirements(self):
         dnf = package_manager.Dnf(self)
         dnf.install(["systemd-devel"], update=True, check=True)
@@ -43,8 +46,10 @@ class LibUDEVConan(ConanFile):
         zypper = package_manager.Zypper(self)
         zypper.install_substitutes(["libudev-devel"], ["systemd-devel"], update=True, check=True)
 
+
     def package_info(self):
         self.cpp_info.includedirs = []
         self.cpp_info.libdirs = []
+        breakpoint()
         pkg_config = PkgConfig(self, "libudev")
         pkg_config.fill_cpp_info(self.cpp_info)
```
Error message:
```
ERROR: libudev/system@test/test: Error in package_info() method, line 54
	pkg_config = PkgConfig(self, "libudev")
	ConanException: pkg-config command ['"pkgconf"', '--print-provides', 'libudev', '--print-errors'] failed with error: Command '\"pkgconf\" --print-provides libudev --print-errors' returned non-zero exit status 127.
/bin/sh: 1: "pkgconf": not found
```
And
```
ls /home/eriff/.conan/data/pkgconf/1.9.5/_/_/package/24647d9fe8ec489125dfbae4b3ebefaf7581674c/bin
aclocal  pkgconf
```

How do we work around this? Will we have to install pkgconf on the OS alongside conan to make all the recipes that rely on `fill_cpp_info` build?

Thanks, Eric.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: ericriff
issue_14417: state: open
title: conandata.yml and exports_sources
body: ### What is your question?

Hi,
I have to repackage tcl 8.6.11 using conana 2.0. While doing so I have to add dir "cmake" where conanfile.py is. I have tried doing by adding exports_sources in  conanfile.py of tcl

I added lines 30-31 :

![image](https://github.com/conan-io/conan/assets/111378770/98449827-277a-4fd1-a6d8-b9a1a02604c0)

but it is not working. It works only when I remove conandata.yml. 

How can I use both -- exports_sources and conandata.yml?


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: laxmij-cmd
issue_14406: state: open
title: [question] Propagate a variable to dependency package 
body: ### What is your question?

Have a conan package, p1 that dependent on another conan package p2.   Dependency is defined using requires() i
>>p1/conanfile.py defines
    def requirements()
      <set-and-export-a-variable>, say ptype="c"
       requires("p2").

Now, p1 wants to define a variable, and export it to p2.  p2/conanfile.py needs to access the same under 'requirement()' method.
>> p2/conanfile.py
     def requirements()
         <get-and-ref-the-variable-here>
         if (ptype=="c") 
            requires("xyz")
         else
            requires("abc")

As shown above, dependent recipe defines 'requirements' based on a variable set by the consumer.
Please let me know how to achieve this.  Whether through a variable as  shown above or any other methods that conan provides.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: vithalsm
issue_14387: state: open
title: Fix CMakeToolchain generator if used with CMAKE_SYSROOT
body: Issue #14386

Changelog: Bugfix: Fix CMakeToolchain generator if used with CMAKE_SYSROOT
Docs: https://github.com/conan-io/docs/pull/XXXX

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

user: thorsten-klein
issue_14386: state: open
title: [bug] CMakeToolchain generator does not work in combination with CMAKE_SYSROOT
body: ### Environment details

* Operating System+version: Ubuntu 20
* Compiler+version: irrelevant
* Conan version: 1.60.1
* Python version: 3.8.10


### Steps to reproduce

If we use conf `tools.build:sysroot` then `find_package()` in cmake does not find the conan packages properly.

```
def test_cmaketoolchain_path_find_package_override_sysroot():
    """ make sure a package in editable mode that contains a xxxConfig.cmake file can find that
    file in the user folder
    """
    client = TestClient(path_with_spaces=False)
    
    find_sysroot = textwrap.dedent("""
        MESSAGE(FATAL_ERROR "this hello should not be found")
        """)
    conanfile_sysroot = textwrap.dedent("""
        from conan import ConanFile
        class TestConan(ConanFile):
            name = "sysroot"
            version = "0.1"
            exports_sources = "*"
            def package(self):
                self.copy(pattern="*")
            def package_info(self):
                self.conf_info.define("tools.build:sysroot", self.package_folder)
        """)
    conanfile_hello = textwrap.dedent("""
        from conan import ConanFile
        class TestConan(ConanFile):
            settings = "os", "compiler", "arch", "build_type"
            exports_sources = "*"
            def package(self):
                self.copy(pattern="*")
            def package_info(self):
                self.cpp_info.builddirs.append("cmake")
        """)
    find_hello = textwrap.dedent("""
        SET(hello_FOUND 1)
        MESSAGE("HELLO FROM THE hello FIND PACKAGE!")
        """)
    conanfile_consumer = textwrap.dedent("""
        [requires]
        hello/0.1
        [generators]
        CMakeToolchain
        """)
    cmake_consumer = textwrap.dedent("""\
        cmake_minimum_required(VERSION 3.15)
        project(MyHello CXX)
        set(CMAKE_FIND_DEBUG_MODE TRUE)
        find_package(hello REQUIRED)
        """)
    profile_sysroot = textwrap.dedent("""
        [tool_requires]
        sysroot/0.1@
        """)
    client.save({"sysroot/conanfile.py": conanfile_sysroot,
                 "sysroot/lib/cmake/hello/helloConfig.cmake": find_sysroot,
                 "dep/conanfile.py": conanfile_hello,
                 "dep/cmake/helloConfig.cmake": find_hello,
                 "consumer/conanfile.txt": conanfile_consumer,
                 "consumer/CMakeLists.txt": cmake_consumer,
                 "consumer/sysroot.profile": profile_sysroot,
                 })

    with client.chdir("sysroot"):
        client.run("create . sysroot/0.1@")
    with client.chdir("dep"):
        client.run("export . hello/0.1@")
    with client.chdir("consumer"):
        client.run("install . -pr:h=default -pr:h=sysroot.profile --build=missing")
        with client.chdir("build"):
            client.run_command("cmake .. -DCMAKE_TOOLCHAIN_FILE=../conan_toolchain.cmake")
    assert "HELLO FROM THE hello FIND PACKAGE!" in client.out
```

### Logs

```
CMake Error at /home/EU.BSHG.COM/kleint/.docker-build-scripts/tmp/tmpoqlucgwcconans/pathwithoutspaces/data/sysroot/0.1/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/lib/cmake/hello/helloConfig.cmake:2 (MESSAGE):

this hello should not be found
```
user: thorsten-klein
issue_14374: state: open
title: ERROR: openssl/1.1.1i: Error in build() method, line 762 self._make() while calling '_make', line 684
body: ### Environment details

ubuntu: 20.04
* gcc 9.4
* Conan version:1.57
* Python version : 3.8

### Steps to reproduce

I am try to build a source code in ubuntu20.04 with
conan 1.57
cmake 3.13.2
gcc: 9.4.0
gstreamer

i get the below error

openssl/1.1.1i: ERROR: Package '8faa1e71bc57b8654248632a449b4c6957f7dcd5' build failed
openssl/1.1.1i: WARN: Build folder /home//AlexaSDK_4_0/alexa-auto-sdk-4.0/builder/.builder/.conan/data/openssl/1.1.1i///build/8faa1e71bc57b8654248632a449b4c6957f7dcd5
ERROR: openssl/1.1.1i: Error in build() method, line 762
self._make()
while calling '_make', line 684
self.run('{perl} ./Configure {args}'.format(perl=self._perl, args=args), win_bash=self._win_bash)
ConanException: Error 1 while executing perl ./Configure "conan-Release-Android-armv8-clang-8" no-shared --prefix=

### Logs

_No response_
user: daisyvincent
issue_14373: state: open
title: [question] can CMakeDeps generate multiple xxxConfig.cmake files?
body: ### What is your question?

Hello,

Is this possible to define a package that will generate multiple Config.cmake files when used with CMakeDeps generator?

My use case is the following:
- I want to make my own private package of intel-mkl (regarding [this](https://github.com/conan-io/conan/issues/14288)). This library provides several components like BLAS, LAPACK, SCALAPACK, etc.
- The consumer of this package use CMake and look for components with `find_package(LAPACK)`, `find_package(SCALAPACK)`.

In order to keep upstream files of the consumer unmodified, I would like CMakeDeps to generate LAPACKConfig.cmake and SCALAPACKConfig.cmake. Is it possible, maybe using some properties of components in `package_info()`?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: forthib
issue_14369: state: open
title: [question] inspect in ConanAPI V2
body: ### What is your question?

Hi, I was using conan api to upload and install Conan packages with Artifactory. 
In the past I was using Conan 1.51.0 for that which has the inspect function to have an easy access on the version and other information from the conanfile.
Now that I want to upgrade on Conan v2, I struggle to find either the inspect or equivalent function in the ConanAPI from v2. Is their any?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Tricksam
issue_14366: state: open
title: [question] How to define cross-compiler compatibility
body: ### What is your question?

I have a GCC package for cross-compiling to ARM that I can include in my build process via `tool_requires`. Now I don't know  exactly how many ARM versions the package supports, but I'd like to have at least only one package for all armv8 version no matter the subversion or the extensions.

My gcc package looks like this:
```
$ conan list 'gcc:*'
Local Cache
  gcc
    gcc/10.3.0@sdk/stable
      revisions
        6570701e6b5b0e62d3fb119070fc519c (2023-07-25 13:19:59 UTC)
          packages
            c64dd33cfe2ca3ccd3e78daaaa645db9cac00a77
              info
                settings
                  arch: x86_64
                  os: Linux
                  os.glibc: 2.35
                settings_target
                  arch: armv8
                  os: Linux
                  os.glibc: 2.31
```

One possible host profile however looks like this (we have settings_user.yml for some extensions):
```
[settings]
arch=armv8.2
arch.crypto=True
arch.simd=True
os=Linux
os.glibc=2.31
```

I tried but so far wasn't successful in writing a compatibility function to use the existing gcc package for that profile.

Some questions:
* How do `compatibility()` in the conanfile and in the extensions folder work together? Are they additive or does one override the other mechanism?
* Is it correct to return `["settings_target: ["arch": "armv8"]]` in this case? I tried but I wasn't successful so far and this isn't mentioned in the documentation.
* How can I ignore the extension settings (`arch.crypto` and `arch.simd`) when selecting the correct package. Do I have to return every combination of settings (for 2^n combinations in case of bool flags) or is there an easier way?

Or is the whole approach untenable? Any other recommendations?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fschoenm
issue_14365: state: open
title: [feature] Ability to hide host or build dependencies from conan graph info output
body: ### What is your suggestion?

When executing:

```
conan graph info --requires mylib/x.y.z -f html > mylib.html
```

The resulting graph can be very difficult to view when there are a lot of upstream dependencies of `mylib`, and each has a lot of build requirements. These, understandably do not resolve to common versions (as they don't influence each other) in the same way that host requirements do, and so the tree can become very cluttered and difficult to navigate/reason about.

It would be useful to be able to hide the build dependencies from such a tree in order to be able to understand the host dependencies better. There may also be a use case here for being able to hide host dependencies to better understand the build dependencies of the tree, though one doesn't immediately jump out at me.

Something like:

```
conan graph info --requires mylib/x.y.z --exclude-build-deps -f html > mylib.html
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: samuel-emrys
labels: component: ux: No changes to core business logic
issue_14353: state: open
title: [question/feature request] Optional requirement trait
body: ### What is your question?

I'm working on a package with semantics similar to the open-source gRPC package. Notably, building the package needs to generate some tools on the build machine (they are dynamically generated, so they can't be in another package) that will then generate some files required for the successful build of the package.

Just like in the gRPC package in the [conan-center](https://github.com/conan-io/conan-center-index/blob/master/recipes/grpc/all/conanfile.py#L125), my package depends on itself in the build context when cross-compiling. And this works flawlessly when I'm building the package or when downstream consumes the package and builds it by dependency (`--build missing`).

However, the problem is when I want to develop the code within the package, i.e. when I'm actually just installing the package's dependencies for local development, the package still doesn't exist, so installation fails for cross-compilation targets. I'm searching for a good solution to this problem.

So far, I've considered the following:

- make the package editable. This works but is messy. It requires the developer to put the package into the editable mode, and not forget to remove it from editable mode after work is done. This is also not elegant for CI testing, as the CI server would have to do the same.
- add special option "local_development" to my package, and add a dependency on itself only if `local_development==False`.  Although this could be made easier to use than an editable package, the option would be leaked to the package users, which is not elegant and any `conan install` wrapper scripts would always have to invoke `conan install` with `-o '*':local_development=True` when initializing the development environment.

This brings me to the "feature request" part. Would it be possible to add an `optional` trait to the `requires` method. If set to `True`, it would mean that it will not be a hard error if conan fails to resolve that dependency, and then it's up to the `generate` + build system to handle that situation.

Besides solving my situation, I think such a trait could also benefit packages in conan-center - they could be more robust to removal of packages from conan-center and packages like `opencv` would not need to have dozens of `with_something` options - a feature would be enabled if the dependency can be resolved (of course, the desired behavior will be package specific - sometimes we want conan to fail if dependency resolving fails).

What are your thoughts on this?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: DoDoENT
issue_14345: state: open
title: [question] /bin/sh: 1: /root/.conan2/p/b/xxx/b/src/configure: Permission denied
body: ### What is your question?

Hi,Can i control the permission about the file in /root/.conan2/... when i run `conan create conanfile.py --version=1.0.1 --build=missing`?

This is the error output:

```
-------- Installing package ffmpeg/5.1.3 (37 of 37) --------
ffmpeg/5.1.3: Building from source
ffmpeg/5.1.3: Package ffmpeg/5.1.3:c495e5045744b639a36c3a6326ab19f1b14d16bc
ffmpeg/5.1.3: Copying sources to build folder
ffmpeg/5.1.3: Building your package in /root/.conan2/p/b/ffmpe7541d15a0b2fb/b
ffmpeg/5.1.3: Calling generate()
ffmpeg/5.1.3: Generators folder: /root/.conan2/p/b/ffmpe7541d15a0b2fb/b/build-release/conan
ffmpeg/5.1.3: Generating aggregated env files
ffmpeg/5.1.3: Generated aggregated env files: ['conanbuild.sh']
ffmpeg/5.1.3: Calling build()
ffmpeg/5.1.3: apply_conandata_patches(): No patches defined in conandata
ffmpeg/5.1.3: Calling:
 > "/root/.conan2/p/b/ffmpe7541d15a0b2fb/b/src/configure" --disable-shared --enable-static --prefix=/ '--bindir=${prefix}/bin' '--libdir=${prefix}/lib' --pkg-config-flags=--static --disable-doc --disable-cross-compile --enable-asm --disable-shared --enable-static --enable-pic --enable-avdevice --enable-avcodec --enable-avformat --enable-swresample --enable-swscale --enable-postproc --enable-avfilter --enable-bzlib --enable-zlib --enable-lzma --enable-iconv --enable-libopenjpeg --enable-libopenh264 --enable-libvorbis --enable-libopus --disable-libzmq --disable-sdl2 --enable-libx264 --enable-libx265 --enable-libvpx --enable-libmp3lame --enable-libfdk-aac --enable-libwebp --enable-openssl --enable-alsa --enable-libpulse --enable-vaapi --enable-vdpau --enable-libxcb --enable-libxcb-shm --enable-libxcb-shape --enable-libxcb-xfixes --disable-appkit --disable-avfoundation --disable-coreimage --disable-audiotoolbox --disable-videotoolbox --disable-securetransport --disable-cuda --disable-cuvid --enable-nonfree --enable-gpl --enable-vulkan --arch=x86_64 --cc=gcc --cxx=g++ '--extra-cflags=-m64 -fPIC -O3' --extra-ldflags=-m64 
ffmpeg/5.1.3: RUN: "/root/.conan2/p/b/ffmpe7541d15a0b2fb/b/src/configure" --disable-shared --enable-static --prefix=/ '--bindir=${prefix}/bin' '--libdir=${prefix}/lib' --pkg-config-flags=--static --disable-doc --disable-cross-compile --enable-asm --disable-shared --enable-static --enable-pic --enable-avdevice --enable-avcodec --enable-avformat --enable-swresample --enable-swscale --enable-postproc --enable-avfilter --enable-bzlib --enable-zlib --enable-lzma --enable-iconv --enable-libopenjpeg --enable-libopenh264 --enable-libvorbis --enable-libopus --disable-libzmq --disable-sdl2 --enable-libx264 --enable-libx265 --enable-libvpx --enable-libmp3lame --enable-libfdk-aac --enable-libwebp --enable-openssl --enable-alsa --enable-libpulse --enable-vaapi --enable-vdpau --enable-libxcb --enable-libxcb-shm --enable-libxcb-shape --enable-libxcb-xfixes --disable-appkit --disable-avfoundation --disable-coreimage --disable-audiotoolbox --disable-videotoolbox --disable-securetransport --disable-cuda --disable-cuvid --enable-nonfree --enable-gpl --enable-vulkan --arch=x86_64 --cc=gcc --cxx=g++ '--extra-cflags=-m64 -fPIC -O3' --extra-ldflags=-m64 
/bin/sh: 1: /root/.conan2/p/b/ffmpe7541d15a0b2fb/b/src/configure: Permission denied

ffmpeg/5.1.3: ERROR: 
Package 'c495e5045744b639a36c3a6326ab19f1b14d16bc' build failed
ffmpeg/5.1.3: WARN: Build folder /root/.conan2/p/b/ffmpe7541d15a0b2fb/b/build-release
*********************************************************
Recipe 'ffmpeg/5.1.3' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter check: https://conan.io/cci-v2.html
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: ffmpeg/5.1.3: Error in build() method, line 675
        autotools.configure()
        ConanException: Error 126 while executing

root@1f980fa2a4a6:~/.conan2/p/b/ffmpe7541d15a0b2fb/b/src# ls -la
total 712
drwxr-xr-x 17 root root   4096 Jul 21 17:16 .
drwxr-xr-x  4 root root   4096 Jul 21 17:16 ..
-rw-r--r--  1 root root  74753 Jul 21 17:16 Changelog
drwxr-xr-x 11 root root   4096 Jul 21 17:16 compat
-rw-r--r--  1 root root 269320 Jul 21 17:16 configure
```

I not sure whether i'm right if changed `global.conf`:
```
tools.system.package_manager:mode = install
tools.system.package_manager:sudo = True
```

but set `tools.system.package_manager:sudo = True`,will meet error in my docker env.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: BrainLyh
issue_14343: state: open
title: Boost in yocto SDK and in .conan2
body: ### What is your question?

I am using conan 2.0.8 and imports an yocto SDK containing a toolchain and some fundamental applications used in the platform.
I have made a host profile that points to the compiler. In this operation the tools.build:sysroot is set in the conf section. 
This seems to generate some problems, since some libraries exists in both .conan2 and in the SDK, including the BoostConfig.cmake (among others).

During the build process the "wrong" BoostConfig.cmake is found in the SDK, but I would like to use the version in the conan2 system. If a rename the BoostConfig.cmake in the SDK the correct BoostConfig.cmake is found but this seems a "wrong" solution.

I have tried several solutions and read quite a lot of posts/docs but have not found a good solutions so what is the recommended method to import an SDK.

I have some idea's
1) Make a recipe for the SDK and and this as an requirement. This is inspired by this post.
https://github.com/conan-io/conan/issues/7431#issuecomment-1270533535 
This seems to be a valid path since stuff can be defined in components and special libraries can be masked.
2) Somehow define the CMAKE_PREFIX_PATH order or remove the path to the libraries.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: AndersGnistrup
issue_14336: state: open
title: [question] package depending on "sub-packages"
body: ### What is your question?

Hello, 
this question is mainly about workflow complexity. The situation is the following:
We have a fairly large internal project, which has a few different "components" (NOT components in either the CMake sense, nor the conan sense, just different libraries and applications some of which depend on each other etc). 

ALL the code for the central components is in one repo. However, each component has its own CMake buildsystem. We migrated to conan originally in about 2018, and still have a requirement (though it's rarely used nowadays) that in principle one can build all this just with cmake and without conan. The modern transparent CMake integrations are much appreciated from that point of view.

Anyhow, one can build each component separately (the component "core" for example, has a CMakeLists.txt file that can be built and installed independently), but we also had an "overall" CMake file that could descend into each directory and build each component (basically using cmake's ExternalProject_Add functionality).  This "overall" CMake build is quite literally NEVER used anymore and we plan to remove it. 

What I *would* like instead is a high level conan build. I can create a conanfile.py that simply depends on all the sub-package components, and, *provided they are already exported* thus knows how to build them etc. 

However, it seems to me that at the moment the only way to actually do this, is to write a script that first goes through all the components and exports their individual conanfiles, then call "build" on the top level package. This is quite clean, however at the moment the only way I can find to actually do that is through external scripting. Because one cannot safely call "conan" from within a conanfile, and also it seems that one cannot safely access the python API from within a conanfile. 

This is quite confusing for people new to the project since the documentation for how to obtain a "first build" of all components is rather long. What are the recommended ways of dealing with this?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: weatherhead99
issue_14334: state: open
title: [bug] Conan 1.x: `CMAKE_PREFIX_PATH` cannot be set to `self.package_folder`
body: ### Environment details

* Operating System+version: Ubuntu 20
* Compiler+version: irrelevant
* Conan version: 1.60.1
* Python version: 3.8.10


### Steps to reproduce

I am using `CMakeToolchain` generator.

`conanfile.py` (mylib)
```
def package_info(self):
        self.cpp_info.builddirs.append(self.package_folder)
```

`CMakeLists.txt` (test_package)
```
message(STATUS "CMAKE_PREFIX_PATH '${CMAKE_PREFIX_PATH}'"
```

I can see that the explicitly specified `self.cpp_info.builddirs` is not added to `CMAKE_PREFIX_PATH`.
According to the comments in `blocks.py` it `# The explicitly defined "builddirs" of "host" context dependencies must be in PREFIX_PATH`

### Logs

_No response_
user: thorsten-klein
issue_14329: state: open
title: [question] download cache lock issue (potential bug)
body: ### What is your question?

Following setup/situation:

- Conan 1.60.1 used.
- A download cache is configured on a very slow location (e.g. network share).
- The same download cache location is used by many machines/conan processes.
- Many machines/conan processes want to "download" the exact same package at the same time in parallel.
- The package is already present in the download cache (no need to download (again) from a remote)
- The package size is much bigger than the bandwidth to the download cache location for a second (e.g. bandwidth 10 MB/s, package size 1 GB -> "download" (means: copying) from download cache to local conan cache would take around 100 seconds)

Observed behaviour:

The first machine/conan process gets a lock on the download cache and starts copying from download cache to local conan cache.
During that time (e.g. in the mentioned 100s time window) all other parallel running machines/conan process also want to get the same lock, but have to wait.
Once the first machine/conan process has finished copying, the lock on the download cache is released.
Now ALL other waiting machines/conan processes get the lock AT THE SAME TIME (they do not have to wait for each other).

Expected behaviour:

After the first machine/conan process has released the lock only ONE other waiting machine/conan process gets the lock and all other remaining waiting machines/conan processes have to wait further for getting the lock.

Hint: The lock mentioned is in the file conans/client/downloaders/cached_file_downloader.py, line 45.

Can you confirm this? Is there a bug?


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: SzBosch
issue_14321: state: open
title: [question] run ./boostrap command
body: ### What is your question?

Hi,

At the beginning I would like to apologize for asking so many questions.

I want to create a package from the library that requires to call ./boostrap before configure and make.
What is the preferable way to do it?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: damian-tomczak
issue_14318: state: open
title: [question] 2.0 migration - install and deploying dev tools "globally"
body: ### What is your question?

Hi,

I'm evaluating conan 2.0 at the moment and struggling to replace existing functionality that relied on some conan 1.x constructs.

At our company we use conan 1.x to deploy some basic dev tools/scripts to all developers by just

`conan install some-tool/1.2.3@user/channel`

This was independent of any project directory or conanfile.py and did not create any files in the current directory. Just plain installing something into the local conan cache. As a last step the recipes deploy() method implemented copying/symlinking the executable or script to a path such as ~/.local/bin

So with an easy install command every developer had this tool available on command line
`$ some-tool --some-option ...`

With 2.0 the install command seems to be strictly tied to some project/package directory, always generating conan specific files into it. Furthermore the recipes deploy() method has gone. The above command would transform into something like
`conan install --requires=some-tool/1.2.3@user/channel --deployer my-custom-deployer ...`

This always creates some files, needs a custom deployer. Apparently the install command with conan 2.0 is not supposed to do things like that, maybe never was even on 1.0 leaving the above solution as some kind of hack.

Is there another (canonical) way to install and deploy tools and scripts with conan 2.0 like described above? Installing things without package/project context?

PS: some packages just distribute Dockerfiles and call `docker build` in the deploy() method on that Dockerfile. Bad idea?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: mcsquared
issue_14300: state: open
title: [bug] conan install --tool-requires should work together with path argument
body: ### Environment details

* Operating System+version: n/a
* Compiler+version: n/a
* Conan version: 2.0.7
* Python version: 3.11


### Steps to reproduce

(Not sure if feature or bug but it's unexpected behavior so I file it as a bug.)

`conan install` allows to use either a path or `--requires` arguments. If you use both at the same time, you get the error message _ERROR: --requires and --tool-requires arguments are incompatible with [path] '.' argument_.

However, it is possible to add additional tool requirements via the `[tool_requires]` section in the profile (see [docs](https://docs.conan.io/2/reference/config_files/profiles.html#tool-requires)). So in my opinion it just makes sense to allow `--tool-requires` on the command line to be merged with the requirements of the conanfile. First of all, the functionality to add tool requirements at runtime is already there and works just fine, second it might not make sense (or take a lot of effort) to provide profiles for every possible tool requirement (combination) that you'd like to add at runtime.

### Logs

_No response_
user: fschoenm
issue_14299: state: open
title: [question] Some dependencies show package_folder as None
body: ### What is your question?

I've been using conan for a little while now and we've been using it with a CI/CD setup, currently I've been trying to figure out how to make a full copy of all of the dependency packages into a local folder (so they can then be exported as job artifacts). I've noticed that full_deploy gets close to what I want, but is not quite exactly what I'm looking for, but gives me enough of a baseline to go off of. 

Either way my major issue is that some of the dependencies of the dependencies report a package_folder of type None, which means I can't locate the package to copy their files over. Is there a way to force conan to report the recipe and package folders of ALL the dependencies?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: retroandchill
issue_14292: state: open
title: [bug] Multiple issues with proxy configuration in global.conf
body: ### Environment details

* Operating System+version: Windows 10
* Compiler+version: n/a
* Conan version: 2.0.7
* Python version: 3.11


### Steps to reproduce

I had multiple issues with the proxy configuration in Conan 2:

1. `core.net.http:no_proxy_match` only works if you don't use the system proxy, i.e. you have to configure `core.net.http:proxies` for it to even be considered. 
2. The value has to be a list, which is documented but not checked. It just silently fails if you accidentally use a string. It would actually be helpful to also allow a string for single values but at least there should be an error.
3. The match is not calculated against the host name of the URL but the complete URL including the path, which does not make a lot of sense (and is also not how it works in any other NO_PROXY configuration as far as I know). It's not possible to define proxies for different paths on the same server. Please change it to only check against the hostname.
4. `fnmatch()`, which you're using, only matches the **complete** value. This is also not how NO_PROXY usually works. Most (all?) implementations automatically match subdomains (see https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/ for reference.) Only in conan you have to set `*.company.com` instead of `company.com`.
5. If `core.net.http:clean_system_proxy=True` is **not** set, all of the above still doesn't work. Not sure what happens internally, but the configured proxies in _global.conf_ are not used, the `no_proxy_match` is evaluated but not applied, and the system proxy is used after all.

(I tried all that on Windows. Not sure if it behaves differently on Linux.)

### Logs

_No response_
user: fschoenm
issue_14291: state: open
title: [feature] conan install --build should support building packages that are only compatible and not an exact match
body: ### What is your suggestion?

The new compatibility function allows `conan install` to use compatible packages instead of an exact match. However, I think it should work together with the `--build` parameter to force building packages that are only compatible (but use e.g. an older C++ standard or an older libc version). A more exact matching package might have performance or other advantages over using only a compatible package.

It could be called `--build compatible` or something similar.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fschoenm
issue_14287: state: open
title: [question] How to do custom generators and get all required dependency information
body: ### What is your question?

How is one supposed to do custom generators now (with the generate function and all that being the new hot thing), without having to do everything manually every time in the generate function?

Also how does one get every dependency for each individual component of all the packages and get all the information regarding the components and associate them with the packages?

It seems there is very little information about that documentation wise (at least that I could find).

Looking at the (very complex) CMakeDeps generator, it looks like there are very many special cases and lots of different paths one has to check to get everything?

Would love to have some information about how to do these things nowadays, ideally being compatible with both 1.60+ and 2.0+

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: Sil3ntStorm
issue_14286: state: open
title: [question] Package with the tool requirement.
body: ### What is your question?

Hi,

I struggling with how to handle makefile package that requires tool built from the source.

So ./configure of this package checks if on the system is installed tool - exactly this tool: https://github.com/libbpf/bpftool.git

but I have no idea how to handle it. Should I create another package if so have the conanfile.py of this package should look like?

If something is misunderstand please me know.

Best Regards
Thanks in advance.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: damian-tomczak
issue_14281: state: open
title: [question] How to distribute different content to different consumers 
body: ### What is your question?

Dear Conan Folks,

We have a use case for example a component has a simulink model , we generate code at build time and compile it , generate the executable package it in 3 different variants(3 different compilers). 
Now we have a requirement:
- Some customer of us , wants the model but other customers should not have access to the model.
- Some customers want to have the executable(thats easy take it from the artifactory)
What would be the right way to proceed:
1. One option that I thought is package the model only as a variant but this leads to unnecessary building and testing of package. Additionally, artifactory does not have fine grained access to packages meaning that you have either access to the artifactory repository or not.
2. Second option that I thought is every customer shall have its own remote. When we package the compoennt  we package the model, executable and the header. We create then another package from the contents of this package and re-package the model and upload it to another artifactory repository where customer has access and can get his model.  This could be tricky as if package has many package revisions how do we map what we distribute?
Is there a better way to handle such a use-case?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: maitrey
issue_14266: state: open
title: [question] find_package fails to find the package for Android build
body: ### What is your question?

Hi there,
I'm trying to create a Conan 2.0 package, and I'm encountering an issue when building the test package for Android. The sources are attached.
The build is successful for other platforms such as Win64, iOS, MacOS, Linux(x86, x64, armv7, and armv8). However, I'm getting the following error:
```
CMake Error at CMakeLists.txt:4 (find_package):
  Could not find a package configuration file provided by "isa-l" with any of
  the following names:

    isa-lConfig.cmake
    isa-l-config.cmake

  Add the installation prefix of "isa-l" to CMAKE_PREFIX_PATH or set
  "isa-l_DIR" to a directory containing one of the above files.  If "isa-l"
  provides a separate development package or SDK, be sure it has been
  installed.

ERROR: isa-l/2.30.0_0@****/testing_NETW-263_demo (test package): Error in build() method, line 61
	cmake.configure()
	ConanException: Error 1 while executing cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/devel/****/workspace/isa-l_NETW-263_demo/test_package
```
I'm using the following configuration:
```
[settings]
arch=armv7
arch_build=x86_64
build_type=Release
compiler=clang
compiler.cppstd=17
compiler.libcxx=libc++
compiler.version=14
os=Android
os.api_level=22
os_build=Linux

[options]
[build_requires]
[env]
ANDROID_NDK=/opt/android-ndk
ANDROID_NDK_HOME=/opt/android-ndk
ANDROID_NDK_ROOT=/opt/android-ndk
CONAN_CMAKE_ANDROID_NDK=/opt/android-ndk
CONAN_CMAKE_SYSTEM_NAME=Android
CONAN_CMAKE_TOOLCHAIN_FILE=/opt/android-ndk/build/cmake/android.toolchain.cmake
CONAN_MAKE_PROGRAM=/opt/android-ndk/prebuilt/linux-x86_64/bin/make
CXXFLAGS=-frtti -fexceptions
PATH=[/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin,/opt/android-ndk/prebuilt/linux-x86_64/bin]

cmake version 3.22.1
conan version 1.59.0
GNU Make 4.3
```
I would appreciate it if someone could review this configuration and let me know if I'm missing any Android-specific configuration or if this issue might be a bug.

I attempted to resolve the issue by including the isa-l-config.cmake file in the package, but unfortunately, it did not solve the problem. I would like to know if the isa-l-config.cmake file is the root cause of the issue, and if so, what should be the content of the file and where should it be placed within the package. Additionally, I'm curious to understand why the package builds successfully on other platforms but it needs this config.cmake file for Android.

Thanks in advance.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: htonakanya
issue_14249: state: open
title: [question] Setting android api level in conan 2?
body: ### What is your question?

I have the following profile when trying to cross compile using ndk r19
```
{% set api_level = '21' %}
{% set target_host = 'aarch64-linux-android' %}
{% set android_ndk = os.getenv("ANDROID_NDK") %}

[settings]
os=Android
os.api_level={{api_level}}
arch=armv8
compiler=clang
compiler.libcxx=c++_shared
compiler.version=8
build_type=Release

[conf]
tools.android:ndk_path={{android_ndk}}
tools.cmake.cmaketoolchain:generator=Ninja

[buildenv]
PATH=[{{android_ndk}}/toolchains/llvm/prebuilt/linux-x86_64/bin]
CHOST={{target_host}}
ANDROID_STL=c++_shared
AR={{target_host}}-ar
AS={{target_host}}-as
LD={{target_host}}-ld
STRIP={{target_host}}-strip
RANLIB={{target_host}}-ranlib
CC={{target_host}}{{api_level}}-clang
CXX={{target_host}}{{api_level}}-clang++

CONAN_MAKE_PROGRAM={{android_ndk}}/prebuilt/linux-x86_64/bin/make
CONAN_CMAKE_TOOLCHAIN_FILE={{android_ndk}}/custom/custom.android.toolchain.armv8.api21.cmake
```

when I try and do `conan create` I'm hit with `ERROR: Error reading 'clang8-android-armv8' profile: Error while parsing line 2: 'api_level=21'`

has the way you set android api level changed in conan 2? I didn't notice a change in the docs. 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: wbehrens-on-gh
issue_14242: state: open
title: Necessary cases for tools.apple:sdk_path
body: > I think the xcrun has that relative SDK path hardcoded as the default search location when it was compiled, but I'm not totally sure.

On a semi-related note, I do need to explicitly set `tools.apple:sdk_path` for some CMake logic to work properly - would it be worth it to have the CMakeToolchain tool query XCRun for the SDK path if it's not explicitly configured?

_Originally posted by @sfackler in https://github.com/conan-io/conan/pull/14195#discussion_r1254454799_
            
user: memsharded
issue_14241: state: open
title: [question] How to handle multiple isolated branches in CI with Conan 2
body: ### What is your question?

We are currently in the process of migrating our CI to conan 2 and we are looking for a good solution for how to handle component branches in the CI with conan 2.0.

To illustrate the problem that we are trying to solve lets take a really simple dependency graph of 4 components:

A <- B <- C <- D

You can think of A through C to be shared library conan packages and D is a conan package with an application using lib C directly (and B and A transitively).
To begin with, all souce code comes from the master branch and the CI has built all packages and exported them to the central remote.

As this is CI and we have several hundred components, we do not want to change the conan recipes of the downstreams whenever there is a new build of an upstream component. So we plan to use version ranges in all conanfiles. Actually "[>0]" everywhere. All components reside in their individual source code repositories and whenever a new version is pushed to the VCS server, a build of the component is triggered automatically and a new conan package is being built and uploaded to the central remote. Then the direct downstreams are also being triggered, so that those conan packages pick up the changed conan package (and by building and running the tests we check correctness and usability) and finally (on success) the CI creates a new lockfile for the complete dependency tree (i. e. containing the new versions of A through D.)

So as an exampe: if a change is made for B, its conan package will be rebuilt and a new package for C will also be built. Then a new lockfile will be generated, that contains the old versions of A and D and the new ones for B and C, so the new set of components can be deployed and used.

So far so good. Now, what we want to enable is that developent for example in B can be done in a branch. So a developer checks out B, creates a branch in the VCS changes the code and pushes the new branch to the VCS server. The CI shall now build the branch version into a conan package. The CI shall then also build the direct downstreams of B (i. e. C in this case) with B's branch package and create a new C conan package. But these branch packages shall not interfere with the master branches of the components. So if someone takes the (master-) sources of D and builds them, they should still get the latest master version of B and C, not the branch version packages.

But a developer who explicity wants to develop in the branch shall also be able to do "something" that makes his local environment use the branch versions of B and C together with the master versions of A and D.

The question is: how can this best be achieved? Our initial idea was to use conan's "user" field for that: all conan packages would get the name of the branch as the "user" field. So the master versions of e. g. "B" would have the reference `B/1.0.0@master` while the branch version would be `B/1.0.1@my_branch`.

But for that to work with the downstreams, we would have to branch all downstreams of any branched component and change their recipes from using `B/[>0]@master` to `B/[>0]@my_branch`. Not much of a problem with four components, but a big problem with 20 or more per branched component.

So we arrived at another possible solution which runs along the lines of what has already been discussed in [this](https://github.com/conan-io/conan/issues/13742) question by @samuel-emrys.

Actually, as we understand it, the user/channel fields of conan currently don't actually serve any practical purpose. They are more or less just part of the component name.

But we think, one could put the user/channel part to some use to solve our problem. (And if I understood it correctly that's close to the idea that @samuel-emrys had, too): What if you could tell conan to prefer packages from a specific user/channel to others. So what we are thinking about would be that our recipes would require their upstreams via `A/[>0]@master` or completely without user/channel: `A/[>0]` and when creating, building or on lockfile creation, you could tell conan, that you would prefer packages from specific user/channels, if available. So maybe there could be options for `conan install`, `conan lock` and `conan build` like this:

```
$ conan create --prefer-user-channel my_branch --prefer-user-channel master .
$ conan lock create --prefer-user-channel my_branch --prefer-user-channel master --requires D/[>0]
```
And then for all references needed from any package in the dependency graph, conan would first try to look for a `...@my_branch` package. If that is nowhere to be found (in the cache and in any active remote) it will try `...@master` and if that is not found it will search for the package without "user/channel" fields (or for the user/channel that is specified in the recipe).
Of course, for this to work, the binary package ids would need to be independent of the user/channel part, which might be a breaking change.

Would this be feasable?
Or is there another / better solution for our problem?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: fourbft
issue_14232: state: open
title: [bug] CMake Error at CMakeLists.txt:3 (project):   No CMAKE_CXX_COMPILER could be found.
body: ### Environment details

* Operating System+version: Win11
* Compiler+version: msvc 2019,2022
* Conan version: 2.0.7
* Python version: 3.10


### Steps to reproduce

1. run `conan profile detect --force` to generate a default profile
2. add a line  `*:tools.cmake.cmaketoolchain:generator=Ninja` in profile to use Ninja as generator
3. run `conan install . -of build -b missing -s build_type=Debug` 
4. run `cmake --preset conan-debug`, then errors comes up with:
```
-- Conan toolchain: C++ Standard 14 with extensions OFF
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:3 (project):
  No CMAKE_CXX_COMPILER could be found.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!
```

### Logs

profile
```
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.version=193
os=Windows

[conf]
*:tools.cmake.cmaketoolchain:generator=Ninja
```

conanfile.txt
```
[requires]
boost/1.78.0

[generators]
CMakeDeps
CMakeToolchain
```

CMakelists.txt
```
cmake_minimum_required(VERSION 3.17)

project(network-assist LANGUAGES CXX)
...
```


user: aiyolo
issue_14230: state: open
title: [question] Is get_gnu_triplet private in 2.x? 
body: ### What is your question?

We had used the function `get_gnu_triplet` quite often in Conan 1.x recipes in order to deal with libraries that are packaged using the triplet. The code is here: https://github.com/conan-io/conan/blob/release/1.60/conans/client/tools/oss.py#L513

In Conan 2.x, the method is now called [_get_gnu_triplet](https://github.com/conan-io/conan/blob/release/1.60/conan/tools/gnu/get_gnu_triplet.py), implying this is a private method. We can still call it but since it appears to be private we worry it can be moved/removed at any point, breaking our recipes. Was there a reason to limit use of it? 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jens-totemic
issue_14229: state: open
title: [question] How to Transition use of PkgConfig from 1.x to 2.x
body: ### What is your question?

For transitioning from conan 1 to conan 2 we need to update the use of the `PkgConfig` class. The old class at  
https://github.com/conan-io/conan/blob/release/1.60/conans/client/tools/pkg_config.py
supported the option: `variables` which allowed us to define a dictionary of pkg-config variables (passed to the pkg-config tool as --define-variable=VARIABLENAME=VARIABLEVALUE).

The new class at 
https://github.com/conan-io/conan/blob/release/1.60/conan/tools/gnu/pkgconfig.py does not seem to support this option anymore. (the new `variables` "property" does something else). Is there a different way of how to do this? If not, would you consider bringing back this option?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jens-totemic
issue_14228: state: open
title: [bug] Unexpected gtest pattern match
body: ### Environment details

* Operating System+version: ubuntu22
* Compiler+version: gcc11
* Conan version: 2.0.7
* Python version: 3.10.6


### Steps to reproduce

Run `conan install --tool-requires "gtest/[>=1.13.0]"`

This matches against the `gtest/cci.20210126` package even though this is older than `1.13.0`.  It looks like pattern matching works strictly on alphabetical order.  I believe that this means that any version that starts with a letter will always be considered newer than any semver versioned package.

I know that you can't magically know that `1.13.0` is newer than the other version, but maybe the `>=` could only apply to semver style version names (or at least not mixing the search between versions that start with numbers vs letters)

### Logs

```
conan install --tool-requires "gtest/[>=1.13.0]"

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
os.distro=Ubuntu22.04
[conf]
tools.system.package_manager:mode=install
tools.system.package_manager:sudo=True
tools.build:jobs=6

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
os.distro=Ubuntu22.04
[conf]
tools.system.package_manager:mode=install
tools.system.package_manager:sudo=True
tools.build:jobs=6


======== Computing dependency graph ========
Graph root
    cli
Build requirements
    gtest/cci.20210126#dafbdf84b58cd687075ace7314651c1a - Cache
Resolved version ranges
    gtest/[>=1.13.0]: gtest/cci.20210126

======== Computing necessary packages ========
gtest/cci.20210126: Checking 9 compatible configurations:
gtest/cci.20210126: '56a52efa35140eb5207ec825a0bb891b949cb615': compiler.cppstd=11
gtest/cci.20210126: '5b58b26bab3b604200b3120eac772627b2d8c6b9': compiler.cppstd=gnu11
gtest/cci.20210126: 'd85bc90be65eb77509ff219bf6fa4d97cfbb5c39': compiler.cppstd=14
gtest/cci.20210126: '068a098979e0fbce80ada5dd1bef5f4ba13d93ef': compiler.cppstd=gnu14
gtest/cci.20210126: '5005402964adccc23074a5ec72c621050a153327': compiler.cppstd=17
```
user: jsallay
issue_14222: state: open
title: [feature] override all customized package id mode
body: ### What is your suggestion?

We would like to have an attribute in the global.conf to override all package id mode set in conanfile.py, so that our build can be fully deterministic. Otherwise, we would have to "search and remove" all the traits that set the package id mode to a value other than "full_mode".

https://github.com/conan-io/conan/blob/release/2.0/conans/model/requires.py#L340


    def deduce_package_id_mode(self, pkg_type, dep_node, non_embed_mode, embed_mode, build_mode,
                               unknown_mode):
        # If defined by the ``require(package_id_mode=xxx)`` trait, that is higher priority
        # The "conf" values are defaults, no hard overrides
        if self.package_id_mode:
            return

        if self.test:
            return  # test_requires never affect the binary_id
        dep_conanfile = dep_node.conanfile
        dep_pkg_type = dep_conanfile.package_type
        if self.build:
            build_mode = getattr(dep_conanfile, "build_mode", build_mode)
            if build_mode and self.direct:
                self.package_id_mode = build_mode
            return

        if pkg_type is PackageType.HEADER:
            self.package_id_mode = "unrelated_mode"
            return


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sophieeihpos
issue_14221: state: open
title: [bug] options in conanfile.txt are not applied to build requirements
body: ### Environment details

* Operating System+version: rhel7
* Compiler+version: not used
* Conan version: 2.0.6
* Python version: 3.7.5


### Steps to reproduce

#### level_0/conanfile.py:



from conan import ConanFile

class BasicConanfile(ConanFile):
    name = "level_0"
    description = "A basic recipe"
    license = "<Your project license goes here>"
    homepage = "<Your project homepage goes here>"
    options = {
         "copy_header": [True, False],
     }
    default_options = {
        "copy_header": True,
    }
    def export_sources(self):
        pass

    def requirements(self):
        pass

    def build_requirements(self):
        pass

    def generate(self):
        pass

    def build(self):
        pass

    def package(self):
        pass

#### level_1/conanfile.py:



from conan import ConanFile

class BasicConanfile(ConanFile):
    name = "level_1"
    description = "A basic recipe"
    license = "<Your project license goes here>"
    homepage = "<Your project homepage goes here>"

    def requirements(self):
        pass

    def build_requirements(self):
        self.tool_requires("level_0/1.0.0")

    def generate(self):
        pass

    def build(self):
        pass

    def package(self):
        pass


#### conanfile.txt:
[requires]
level_1/1.0.0
[options]
*:copy_header=False

#### Reproduce:
conan export level_0 --version 1.0.0
conan export level_1 --version 1.0.0
conan install --profile:build default--profile:host default --build=missing conanfile.txt

Package for level_0 has option copy_header set to True although requested False in conanfile.txt


### Logs

_No response_
user: sophieeihpos
issue_14217: state: open
title: [question] isysroot is missing in asflags
body: ### What is your question?

Hi! I am building a static library version of x264 for ios on macos these days. The library is compiled without any issue, but it fails to link.

After some debugging, I found that `-isysroot` flag isn't in `asflags` and the compiled assembly objects are actually for macos. So the library is just a mixture of ios and macos objects. I guess that `clang` wants `-isysroot` or `-target` flag to be set in order to select correct object file target.

Is it by designed that `-isysroot` flag should not be in `asflags` in this case, and user need to take care of the option explicitly, or just a minor bug in conan?


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: chimojs
issue_14216: state: open
title: [question] Set specific remotes to only pull recipes
body: ### What is your question?

Kinda the opposite of `conan upload --only-recipe`, is there a way in the `remotes.json` file to only pull the recipes from a specific remote but not the binaries? like the following.
```json
{
   "remotes": [
      {
         "name": "conancenter",
         "url": "https://center.conan.io",
         "use_binaries": false,
         "verify_ssl": true,
      }
   ]
}
```
The environment I'm working in we'd like to use the recipes from conan center but due to other requirements must build all 3rd party libraries on our machines. This way we wouldn't be repeating work  other then what's required.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: wbehrens-on-gh
issue_14207: state: open
title: [question] Package immutability and user/channel inconsistencies?
body: ### What is your question?

Hello.

I think I can understand why is that so important to have package immutability on Conan 2, but do you have a clear article or part in the documentation that explain in detail why Conan really wanted this?

I give a quick summary of my use case:
- I have a set of various inside packages, some open source package, mostly company internal conan 1 packages
- user/channel are really a mess, without clear convention. So, **first question,** is there recommendation for package naming inside a company that may have several departments working on different subject, sometime wanting to share some packages, sometime having more "business oriented" custom packages? I will propose a convention for official packages user/channel to follow `<mainprogram>_<department>_<platform>/channel`, so one department can "easy" import packages from another one in their repositories and there won't be conflicts neither a single folder will all packages. But is there better convention ?
- so, today we have a mess with user/channel on existing packages, and I need to reuse some in my new projects. And I would like it to be cleaner.

Importing some package (ie copy into our working repository) directly will result in copying the mess, but even using "conan copy" in Conan 1 would not save the dependency problem. I need basically a way to tell "everything that were in "baduser/badchannel", once imported, you will find them into "gooduser/goodchannel". I see no use to change the package name or version.

As I understand, the philosophy of Conan2 is to have immutable package, and in this case it will help because all the requirements or tools_requirements will "stay" the same without adaptation. And I understand in theory I would have to "create new package" in order to fit my old packages into the new structure.

So my $1000 question is: is there a way to "import" an existing package by copying everything it contains (recipe, name, version, binaries, ...) but just change its user/channel (that would be the equivalent of "conan copy" but also "replace" all it dependencies reference to my "user/channel"? Even if this mean to rebuild from source or change the package_id/revision_id, I think this is acceptable. The goal is to control better the user/channel section in the new structure.

Or I have to do a reimplementation from scratch, recopying the whole original recipe ? Of course, I know I need to do it for each transitivie dependencies, so if the "import recipe" is pretty easy to implement, I guess this is some i can manually do for each of its depedencies (there are not so many, most of our packages share the same single dependency).

Thanks for your anwser
Gaetan

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: gsemet
issue_14206: state: open
title: [feature] Type Hints in Conan API
body: ### What is your suggestion?

Hi! I started migrating our codebase from Conan v1 to Conan v2 and the python interface is a lot nicer for sure.

It would be even more awesome if the API's had type hints! It will likely increase productivity of your team (definitely for developers like me), and would also eliminate a whole class of bugs 👍 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: stackfun
issue_14204: state: open
title: [question] Using executables compiled as part of package
body: ### What is your question?

Many of the libraries I work with build tools along with the library, for example https://conan.io/center/openexr can build and install some useful utilities that I would like to use. 

Is there a recommended workflow for making these available as part of the package install process? 

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: anderslanglands
issue_14189: state: open
title: [question] Read/Forward system requirements
body: ### What is your question?

Hi, I implemented a custom deployer for my project to create a debian package. 

My application requires some packages that have system requirements, in my case OpenCV which depends on GTK/system.
Is there a way to read out the system requirements and forward them be dependencies of my debian packge?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: TTrambi
issue_14182: state: open
title: [question] Managing internal dependencies with versions handled by CI system
body: ### What is your question?

Hello, I wonder if you have a recommendation for handling the following scenario:

Imagine we have two repos _libA_ and _libB_. _libB_ depends on _libA_. Out CI system checks out both repos, usually on the master branch but it can be any tag or branch, configured in the CI system. Then we build both libs together manually.

I now want to create a conan package of _libA_ and consume the package in _libB_. However, I'm not sure how to correctly use the version of _libA_. What's the best approach here?

* Should I just set a custom version like "1.0" or even "latest" and depend on that version in _libB_?
* Or is there a way to give a more reasonable version to the package? Ideally I'd like to use the branch/tag (e.g. `libA/master`) name but then I don't know how to refer to the correct version in _libB_.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fschoenm
issue_14180: state: open
title: [question] XcodeDeps possible to leave linker options empty?
body: ### What is your question?

I have an Xcode project with multiple targets (libs, executables). Correct me if I'm wrong, but it is my understanding that conan wants me to create a `conanfile.py` for each target. Something like this:
```
testproject
├── bin1
│  └── conanfile.py
├── bin2
│  └── conanfile.py
└── bin3
   └── conanfile.py
```
Is that right?

conan's XcodeDeps generator sets the linker flags e.g. `-lfmt` for the variable `OTHER_LDFLAGS`. Is it possible to not do that so that I can manage what's actually linked in Xcode? I want to leave the `OTHER_LDFLAGS` variable unset.
1. I'd prefer to see all my linked libs in one place (Xcode), 
2. this would allow me to get away with only one conanfile (although it's admittedly not as clean, but good enough for my use case)


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: wAuner
issue_14175: state: open
title: [question] Concurrent uploads fail in CI/CD - Good practices in CI/CD
body: Hi,

I have an issue on a Gitlab CI/CD pipeline building and uploading a simple C++ package. I have 4 parallel jobs (they do not share any data, in particular they have **independent conan caches**) that all build & upload the same package with different configurations (typically debug/release + static/shared library).

By doing so, I randomly get failing jobs returning a "needs DELETE permission" error at the `conan upload` step. Sometimes all jobs pass, sometimes one or two are failing with the same error:
![image](https://github.com/conan-io/conan/assets/92524713/c68cd4ca-21b6-4f4c-b628-607b814ce170)

**When re-run independently, these failed jobs are successful**. To be more specific: the error arises during the upload of sources (`conan_sources.tgz`), that is the same between all four jobs (only the build config is different). Example of error I get at when doing `conan upload`:
``` bash
   conan upload -c test_parallel_ci* -r conan_remote
   Checking which revisions exist in the remote server
   Preparing artifacts to upload
   Compressing recipe sources...
   Compressing package...
   Uploading artifacts
   Uploading recipe 'test_parallel_ci/0.1.0#408bd9e0d39fd1700f55e5daf4dc2221'
   ERROR: Permission denied for user: '[MASKED]': 403: Not enough permissions to delete/overwrite artifact 
   'conan-local:_/test_parallel_ci/0.1.0/_/408bd9e0d39fd1700f55e5daf4dc2221/export/conan_sources.tgz' 
   (user: '[MASKED]' needs DELETE permission)..
```

It seems to be a concurrency issue on the (artifactory) server side, and I naturally wonder if my use of conan is well defined or not. Having completely independent jobs firing uploads of a **same recipe revision** at the same time might not be a good idea, although it is supposed to happen in general. Is there a good practice I am missing here to automate the upload of *several* conan packages ? Otherwise I guess I have to dig into the artifactory server configuration ?

**OS:** Linux
**Docker image:** conanio/gcc10
**Conan version:** 2.0.7
**Minimal example to reproduce the bug:** I used the template project given by `conan new cmake_lib -d name=test_parallel_ci -d version=0.1` and a minimal gitlab CI with 4 independent parallel jobs building debug/release, static/shared versions of the library.

NB: I have no particular knowledge on the artifactory server I am using.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: docbrown1955
issue_14174: state: open
title: [feature] Allow specifying the linker in tools.build:compiler_executables
body: ### What is your suggestion?

There are use cases for using a linker other than the system default, such as cross-compilation and link-time optimization.
Currently, users must specify the linker through build-system dependent environment variables using the `[buildenv]` section.

Build systems do not uniformly make use of the `LD` environment variable to define the linker, which leads to confusion.
Meson, for instance, uses different environment variables than the common `LD` environment variable, which has lead to the issues #13824 and #14028.
Furthermore, build systems may provide more robust methods of specifying the linker than using environment variables.
Meson, for instance, allows defining the linker in cross and native files, which are already generated by Conan.
This is described [here](https://mesonbuild.com/howtox.html#set-linker).
Allowing a linker to be specified via `tools.build:compiler_executables` would unify specification of the linker and reduce confusion and duplication.

Meson allows defining a linker for both the C and C++ languages, so I would propose that we do the same in `tools.build:compiler_executables`, i.e. `c_ld` and `cpp_ld`.
CMake and Autotools toolchains should be able to make use of these values as well.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jwillikers
issue_14173: state: open
title: [question] How to ensure packages are build locally (`--build`) but not rebuild on each install?
body: ### What is your question?

I want to make sure that I build all packages locally.
To do so I use a policy: https://docs.conan.io/1/mastering/policies.html#build-policies (`--build will build all requirements from sources`).
On a clean system with Conan it builds everything fine. But the next time I do `conan install...` with all settings and options are the same I want to skip builds for packages that are already present (and I know were build locally). 

Is there a way to achieve this? 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ngrodzitski
issue_14163: state: open
title: Fix absolute build folder location (#14162)
body: Changelog: Bugfix: Allow setting absolute path for build folder in package layout (#14162)
Docs: N/A

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.
user: iskunk
issue_14162: state: open
title: [bug] Cannot set absolute directory for self.folders.build
body: ### Environment details

* Operating System+version: Ubuntu Linux 22.04
* Conan version: 2.0.7
* Python version: 3.10.6


### Steps to reproduce

In the `layout()` method of `conanfile.py`, if you set `self.folders.source = "/tmp/foo"` and build a package, then the package source will be placed in `/tmp/foo`.

If you set `self.folders.generators = "/tmp/foo"`, then the generator will write into `/tmp/foo`.

But if you set `self.folders.build = "/tmp/foo"`, the setting is ignored. Conan will proceed to build the package in the default `~/.conan2/p/b/mumblemumble/b` location.

This is due to the somewhat chicken-and-egg nature of how the `build_folder` path is calculated. I have a straightforward fix for this in `_PackageBuilder.__init__()` that does not affect the (normal) use of relative paths.

(I want to build packages in a specific absolute directory because the build location gets baked into the artifacts in one way or another. Running `strings -a libfoo.so` should not turn up any `~/.conan2` paths.)

### Logs

_No response_
user: iskunk
issue_14159: state: open
title: [bug] conan.tools.scm.Git.commit_in_remote returns fails for tags in a multibranch Jenkins pipeline
body: ### Environment details

* Operating System+version: ubuntu 22.04
* Conan version: 1.60.1
* Python version: 3.10.6
* Jenkins version: Jenkins 2.387.2

### Steps to reproduce

1. Use the normal [github-branch-source](https://plugins.jenkins.io/github-branch-source/) plugin, enabling `Discover tags` so it indexes tags as well as branches/PRs.
2. Have a tag containing a default `checkout scm` step
3. Use `conan export` on a recipe that follows the guidelines of https://docs.conan.io/2/examples/tools/scm/git/capture_scm/git_capture_scm.html?highlight=export%20scm

Result: 
Branches and PRs will use the public URL in their conandata.yml, but tags will instead use the local filesystem path (to a jenkins workspace on the agent). 

The problem seems to be the refspecs used by Jenkins vs the logic of commit_in_remote:
https://github.com/conan-io/conan/blob/81b195262350a13525a44a0b079c9a4eab9fb1cd/conan/tools/scm/git.py#L81

`git branch -r --contains`, is basically searching the ancestry of local refs named `refs/remotes/*`. I would propose that this should also consider `git tag --contains <hash>` an acceptable match, on the basis that tags are a pretty clear indication of "intent to publish this commit", even though they are a global namespae rather than 1:1 associated with a particular URL like a remote-tracking branch is.

If really necessary, one could use `git ls-remote {remote} {tag}` to confirm that a particular tag was present on that remote, but that's a network roundtrip. I think it's sane enough to just assume that tags will eventually end up being pushed; if this exports a conandata.yml referring to a tag that isn't pushed to a particular remote yet, that's easily fixed (by pushing it) and in any case less broken than an uploaded recipe containing a local filesystem link (which is a recipe revision that could never work anywhere else).

### Logs


the `.git/config` generated by jenkins uses refspecs that look like:

For a branch:
```
[remote "origin"]
        url = https://github.com/org/repo.git
        fetch = +refs/heads/master:refs/remotes/origin/master
```

For a PR:
```
[remote "origin"]
        url = https://github.com/org/repo.git
        fetch = +refs/pull/74/head:refs/remotes/origin/PR-74
        fetch = +refs/heads/master:refs/remotes/origin/master
```

For a tag
```
[remote "origin"]
        url = https://github.com/org/repo.git
        fetch = +refs/tags/v0.14.0-rc.2:refs/tags/v0.14.0-rc.2
```

So the issue is that Jenkins, like a default `git clone`, fetches tags into refs/tags/* (a shared global namespace) rather than displacing them per-remote into refs/remotes/*.
user: puetzk
issue_14151: state: open
title: [question] buildenv_info and generate method
body: ### What is your question?

Dear Conan Folks,

I am using conan-2.0.6 and in the context of Windows. 
For one of my packages, that is a tool , I set the environment variable in the package_info method:
```
def package_info(self):
        self.buildenv_info.define_path("TOOLS_FORMATS", os.path.join(self.package_folder))
```
In the consumer package , I would like to access the above variable in the generate method as I have to copy it to a certain location.
What is the way to fulfill this use case?
I can see the variable set in the consumer package in the conanbuildenv.bat but how to get the contents in order to copy to a desired location in the generate method ?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: maitrey
issue_14145: state: open
title: [feature] `conan list merge` command
body: ### What is your suggestion?

This is akin to `conan lock merge`.

This is useful when you create a package and immediately build multiple binaries for it, with different configurations (e.g. debug, release, various options) and you want to upload all binaries in a single `conan upload` call so that you benefit from Conan's parallel upload feature.

The flow would be something like this (avoiding multiple `conan create` calls because each call creates a different revision for some reason).

```
conan export . --name pkg --version 1.0

conan install --requires pkg/1.0 -s build_type=Debug --format=json > graph-debug.json
conan install --requires pkg/1.0 -s build_type=Release --format=json > graph-release.json

conan list --graph=graph-debug.json --graph-binaries=build --format=json > built-debug.json
conan list --graph=graph-release.json --graph-binaries=build --format=json > built-release.json

conan list merge --list=built-debug.json --list=built-release.json --list-out=built.json

conan upload -r myremote -c --list=built.json
```

Of course, this can be implemented as a  custom command (but not as `conan list merge` because `list` command is already reserved). However, I think that having this command by default would be a good value.
user: DoDoENT
issue_14144: state: open
title: [feature] Add support for creating MultiPackagesList from graph
body: ### What is your suggestion?

Currently, it's possible to create this object from [graph file](https://github.com/conan-io/conan/blob/release/2.0/conan/api/model.py#L75), however conan graph API returns the [graph object](https://github.com/conan-io/conan/blob/release/2.0/conan/api/subapi/graph.py#L141).

Now, in order to use `MultiPackagesList` to filter the graph and obtain the list of packages that have been built by dependency I need to serialize the graph object into the file and then load it. This is inefficient.

I'm currently working on a custom command that will:
- invoke `conan install --build missing` for each and every build type that we use in the company
- invoke `cmake --preset <generated-preset>` to automatically create the cmake project with installed dependencies

The idea is for this command to also return the list of packages that have been built by dependency, so I need to filter those packages from each and every dependency graph (for each build type), merge everything into a single PackageList, and serialize that into JSON using formatters so that the produced JSON is then compatible with `conan upload` command.

The custom command is intended to be used both by developers (in which case, the JSON pkglist of built dependencies is not important) and CI, where I would like to use the pkglist to upload the built binaries to the Artifactory server, similar to [this example in the Conan documentation](https://docs.conan.io/2/examples/commands/pkglists.html#building-and-uploading-packages).

Currently, I can copy the implementation of the linked code into my custom command, but it uses Conan's private API (in the `conans` package), which I'm not very comfortable using, as even a minor change in the conan version can break it.

Alternative workarounds are also welcome.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: DoDoENT
issue_14142: state: open
title: Gettting import error while running build with conan 
body: ### What is your question?

Please find the error details below:

-- PACKAGE_NAME = dbiclient; PACKAGE_DESCRIPTION = dbiclient; CONTROL_SOURCE_DIR = /home/mkrishan/conan_issue/issue@2/build_sim_frcug3x/src/external-repos/dbiclient
-- VERSION_INFO 6.1.0.1
-- PACKAGE_NAME = profiles; PACKAGE_DESCRIPTION = Profile pkg; CONTROL_SOURCE_DIR = /home/mkrishan/conan_issue/issue@2/src/application/profiles
-- VERSION_INFO 7.0.0.10
-- curl-cmake: Arch is=x86_64, TAR_FILE=
-- Conan: checking conan executable
-- Conan: Found program /home/mkrishan/.local/bin/conan
-- Conan: Version found Conan version 1.53.0
-- Conan executing: /home/mkrishan/.local/bin/conan install . --remote conan-infn --settings build_type=Debug OFF --settings compiler=gcc --settings compiler.version=8 --settings compiler.libcxx=libstdc++11 --settings compiler.cppstd=14
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug OFF
compiler=gcc
compiler.cppstd=14
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

ERROR: Invalid imports line: lib, * -> /home/mkrishan/conan_issue/issue@2/build_sim_frcug3x/src/external-repos/curl/
EX: OpenCV/lib, * -> ./lib
Wrong imports argument '2/build_sim_frcug3x/src/external-repos/curl/'. Need a 'arg=value' pair.
CMake Error at build_sim_frcug3x/conan_utils/conan.cmake:651 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  src/external-repos/curl/CMakeLists.txt:19 (conan_cmake_install)


-- Configuring incomplete, errors occurred!



### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: mkjkec2005
issue_14138: state: open
title: [question] grpc application link error caused by abseil on Debug mod
body: ### What is your question?

Hi,

I'm using conan package to build applications include grpc/1.50.1.

Here is profile (vpsdev_x86_64_linux)
```
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
[options]

[conf]
*:tools.cmake.cmaketoolchain:generator=Ninja
```
+ build script
```
conan install ./skvpslibCONAN_v2.py -r conancenter -pr ./vpsdev_x86_64_linux -pr:b ./vpsdev_x86_64_linux -s build_type=Debug -b missing -of ./Debug
```

After installing conan packages, I have tried to build my application. It built done and worked well on Release. But on Debug, abseil makes link error as below:
```
[build] /usr/bin/ld: /root/.conan2/p/b/absei310c3fd1f29d1/p/lib/libabsl_status.a(status.cc.o): in function `absl::lts_20220623::StatusCodeToString[abi:cxx11](absl::lts_20220623::StatusCode)':
[build] /root/.conan2/p/b/absei310c3fd1f29d1/b/src/absl/status/status.cc:36: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<std::allocator<char> >(char const*, std::allocator<char> const&)'
[build] /usr/bin/ld: /root/.conan2/p/b/absei310c3fd1f29d1/b/src/absl/status/status.cc:38: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<std::allocator<char> >(char const*, std::allocator<char> const&)'
[build] /usr/bin/ld: /root/.conan2/p/b/absei310c3fd1f29d1/b/src/absl/status/status.cc:40: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<std::allocator<char> >(char const*, std::allocator<char> const&)'
[build] /usr/bin/ld: /root/.conan2/p/b/absei310c3fd1f29d1/b/src/absl/status/status.cc:42: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<std::allocator<char> >(char const*, std::allocator<char> const&)'
[build] /usr/bin/ld: /root/.conan2/p/b/absei310c3fd1f29d1/b/src/absl/status/status.cc:44: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<std::allocator<char> >(char const*, std::allocator<char> const&)'
[build] /usr/bin/ld: /root/.conan2/p/b/absei310c3fd1f29d1/p/lib/libabsl_status.a(status.cc.o):/root/.conan2/p/b/absei310c3fd1f29d1/b/src/absl/status/status.cc:46: more undefined references to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>

~~~ more~~ 
```

In my opinion, it caused by abseil library related with "ABSL_OPTION_USE_INLINE_NAMESPACE" on Debug build. 

Is there any idea to fix link error?


### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: kismetro
issue_14134: state: open
title: [bug] Cross compilation detection when build/host arch/os matches but not other parameters
body: ### Environment details

* Operating System+version: Linux 5.x
* Compiler+version: Any
* Conan version: 2.0
* Python version: 3.x


### Steps to reproduce

Setup:
Build machine os/arch - Linux/ x86_64
Host machine os/arch - Linux/ x86_64
Let other config settings in conan profile like libc, compiler version be different.

Now, when the project conan receipe adds libs, say libev for example as dependency and exepects it to be built with host tool chains and also detect it as 'cross compilation', build for libev (in this example) fails.  Reason, '--host' is not passed to configure script (conanbuild.sh).

There are quite a few tickets raised here and have varying solutions.  Mostly requires, forking 'libev' source code and making changes to its recipe to manually update with options like '--host'.  But, problem here is not with libev alone, but many.

Further investigating, found that, AutotoolsToolChain() which generates the 'configure command with options', doesn't detect it to be 'cross-compiling' as it compares arch/os of build and hosts.  Ignores 'vendor' option.

Yes, 'vendor' option can be optional, but needs to be internally calculated as like config.guess does and compared.  Even, API to generate triplet misses the 'vendor' field.

However, setting tools.gnu:host_triplet under [conf] section in conan profile solves the problem, as it properly generates the triplet.

Instead of setting complete triplet at profile, can consider setting 'os.vendor' in conan profile and gen_triplet API of auto tool chain can use same and also in comparison to check whether being cross compiled (just generating triplet n comparing may suffice).

This should globally solve the problems that are being hit in multiple cases.

### Logs

_No response_
user: vithalsm
issue_14127: state: open
title: Add more integration tests about editables with a full flow
body: ### What is your suggestion?

We need a few more tests that exercise some good full flows for editable packages, see https://github.com/conan-io/conan/pull/14109 where we had a few problems:
 * package folder being None got caught by a semi-unreleated test, let's ensure there're some
 * Package info not running in the expected folder when the call_package_info base_folder was set to another folder was not caught whatsoever

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: RubenRBS
issue_14123: state: open
title: [question] VirtualBuildEnv in Conan 1.x
body: ### What is your question?

I have an internal tool used by other recipes via `tool_requires`. Its recipe contains
```python
    def package_info(self):
        self.cpp_info.libdirs = []
        self.cpp_info.includedirs = []
        # my_build_tool is in 'bin' subdirectory so the default 'bindirs' value is OK
```

When I use it with
```python
    generators = "VirtualBuildEnv"
    ...
    def build_requirements(self):
        self.tool_requires("my_build_tool/1.0")

    def build():
        self.run("my_build_tool ...")
```
my_build_tool's directory is correctly added to PATH and build() succeeds. But if I add the same requirement
```python
    generators = "VirtualBuildEnv"
    ...
    def requirements(self):
        self.requires("my_build_tool/1.0")

    def build_requirements(self):
        self.tool_requires("my_build_tool/1.0")

    def build():
        self.run("my_build_tool ...")
```
my_build_tool's directory will disappear from PATH and build() will fail. Is it expected behavior? Conan 2.0 doesn't suffer from that.

I see that CCI recipes always update PATH explicitly:
```python
        # TODO: to remove in conan v2
        bin_path = os.path.join(self.package_folder, "bin")
        self.output.info(f"Appending PATH environment variable: {bin_path}")
        self.env_info.PATH.append(bin_path)
```
but thought it should not be necessary as VirtualBuildEnv did it itself for cpp_info.bindirs.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: db4
issue_14121: state: open
title: Qt6 with conan
body: Hello,

While trying to install Qt6 I get this error:
```
[requires]
automake/1.16.5
qt/6.5.0

[generators]
CMakeDeps
CMakeToolchain
```
```
libffi/3.3: Building from source
libffi/3.3: Package libffi/3.3:fb75e7f920d3dbff49a775bdb60e92fb7338dc84
libffi/3.3: Copying sources to build folder
libffi/3.3: Building your package in C:\Users\.conan2\p\b\libffa262cd3d18ed0\b
libffi/3.3: Calling generate()
libffi/3.3: Generators folder: C:\Users\.conan2\p\b\libffa262cd3d18ed0\b\build-release\conan
ERROR: libffi/3.3: Error in generate() method, line 122
        ar_wrapper = unix_path(self, self.dependencies.build["automake"].conf_info.get("user.automake:lib-wrapper"))
        KeyError: "'automake' not found in the dependency set"
```

What can I do? I tried to install automake but it doesn't change anything.

Thanks
user: tickox
issue_14107: state: open
title: [question] dependency options conditional on whether dependency is being built
body: ### What is your question?

Hello,
I have a question whether something is possible (or intended to be possible) in conan v2. Consider the following situation: 
I have a project which has a big bunch of deeply nested dependencies. Quite often, I change some option or setting in my build and as a result have to rebuild a huge pile of dependencies pretty regularly. 

Suppose one particular dependency has a bunch of options, about whose values my own package **does not care** (for example, they might be for building extra plugins or functionalities I don't use). But, they take up a lot of time to build for all my various configurations. Therefore, one thing that would be nice, is to set the **options** for these dependencies, **depending on whether they are going to be built or not**.

I know this sounds rather weird but I think it's a valid use case. I understand the alternative is to have my own conan server and keep pre-built copies of everything I need there, but let's assume (because it happens in my own case to be true) that I can't really do that given my work environment. 

The options would need to be changed after the whole dep graph is computed, and then one would need some way within the recipe to trigger computation of the dep graph again after the options are changed. I think this may actually be possible within the `configure()` method, if I reach in and mess around with some conan internal stuff.

Thanks for your consideration of this question, and I appreciate this is a niche use case and likely something that will not be supported.



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: weatherhead99
issue_14100: state: open
title: [feature] Allow customizing CMAKE_GENERATOR_TOOLSET in CMakeToolchain
body: ### What is your suggestion?

Currently, it's not possible to customize `CMAKE_GENERATOR_TOOLSET`. It's only possible to influence toolset architecture via `tools.cmake.cmaketoolchain:toolset_arch`, but not the toolset itself.

Furthermore, if using `clang`, conan hardcodes `CMAKE_GENERATOR_TOOLSET` to `ClangCL`, which is correct only in case when using Clang provided by Visual Studio installation.

However, when dealing with custom LLVM toolchains, specifically those packaged into a conan package, we need the ability to define a custom toolset.

My current workaround is to have a custom command that patches the generated `conan_toolchain.cmake`.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: DoDoENT
issue_14099: state: open
title: package pylint or other python tools
body: ### What is your question?

Hi

I am looking for a way to package pylint or any other opensource or closed source python script so that they would be available through conan development environement + cmake for the developers.

For instance when developers has a small python script to execute, it would be good if it would have been directly available as a cmake target like they already does, except this is not integrated as a conan package (we have a bunch of tools user needs to manually install).

I would not want to install anything in the environment where conan is installed itself.

For exemple, let's say I want to distribute a pylint package with predefined configuration file + cmake scripts in conan. I though to create a "zipapp" of the pylint (an self-containing executable with all the depedendencies attached in a big zip file), for instance using shiv. And then work on the conan recipe to provide the config + the cmake target with the right call to launch the zipapp using the same interpreter than the one used by conan.

Does it makes sense, or does anyone already tried it ?

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: gsemet
issue_14088: state: open
title: [question] How to define variable to be set in generated cmake config?
body: ### What is your question?

Hi, I'm packaging a library, "Dep" I don't control to be used by another library, "B", I don't control. 

B's cmake scripts are expecting to have "DEP_VERSION" set in the cmake config, but the generated DepConfigVersion.cmake contains `set(PACKAGE_VERSION 3.1.8)` and so I need this to be `set(DEP_VERSION 3.1.8)` instead, or additionally, doesn't really matter.

I can't see any way of doing this from the docs, is there a way?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: anderslanglands
issue_14077: state: open
title: [feature] AutotoolsToolchain support [conf] tools.android:ndk_path
body: ### What is your suggestion?

AutotoolsToolchain support [conf] tools.android:ndk_path

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: zhizhi-dev
issue_14068: state: open
title: artifactory remote and conan center recipe date mismatch
body: ### Environment details

OS: WSL Ubuntu 20.04
Conan: 2.0.0

### Steps to reproduce

In conancenter I find the following recipes for pugixml/1.12.1:
```
conan list pugixml/1.12.1#* -r conancenter
conancenter
  pugixml
    pugixml/1.12.1
      revisions
        5a39f82651eba3e7d6197903a3202e21 (2022-02-23 20:10:41 UTC)
        642b2e2c10660f2e43579647e5f8ed67 (2022-09-20 11:12:28 UTC)
        e1bc6e24068d0fdd19f1ccc2ceddf8a8 (2023-02-01 12:08:39 UTC)

```

I have a virtual remote on my local artifactory (which points to conancenter) with the following content:

```
conan list pugixml/1.12.1#* -r conan-virtual
conan-virtual
  pugixml
    pugixml/1.12.1
      revisions
        5a39f82651eba3e7d6197903a3202e21 (2023-02-21 17:44:11 UTC)
        642b2e2c10660f2e43579647e5f8ed67 (2022-09-20 11:12:28 UTC)
        e1bc6e24068d0fdd19f1ccc2ceddf8a8 (2023-02-19 18:12:58 UTC)
```

My virtual remote says the latest pugixml recipe is 5a39..., but conancenter says this is the oldest recipe revision.
How is that possible? How can such a mismatch occur?

Regards
Klaus

### Logs

_No response_
user: klausholstjacobsen
issue_14066: state: open
title: [question] How to perform unit test with MSBuild
body: Version: 1.60.1
OS: Windows 11 x64

Hi,

Hope you all are well!

What is the recommended way using conan to build and run unit tests when using the Visual Studio's MSBuild helpers?

My company is looking to introduce more testing for our software and we want to use leverage Conan to build and run our testing programs.

I've seen support and docs for CMake. I was going to translate that approach to our projects, but I thought it was better to ask first. 

I was reading through the documentation pages but I couldn't find a clear and concise answer for my question.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: KingKiller100
issue_14056: state: open
title: [question] Replacement for scm attribute in Conan 2.x when exporting sources
body: ### What is your question?

Because the `scm` attribute has been removed, I tried to implement the solution with `conan.tools.scm.Git` as described [here](https://docs.conan.io/1/reference/conanfile/tools/scm/git.html#conan-tools-scm-git). 

However, I have a package that contains a patch and now I'm running into an old problem described in #1717: The destination directory for the Git checkout is already dirty because the exported source file has been copied there:

```
ERROR: goldfish/2.4.4@vsdk/stable: Error in source() method, line 28
        git.clone(url=self.scm["url"], target=self.source_folder)
        ConanException: Command 'git clone "http://10.30.21.21:7990/scm/oss/goldfish.git"  /home/fschoenm/.conan2/p/goldf9e9fa47f2b5bf/s' failed with errorcode '128'
b"fatal: destination path '/home/fschoenm/.conan2/p/goldf9e9fa47f2b5bf/s' already exists and is not an empty directory.\n"
```

The [previous solution](https://github.com/conan-io/conan/issues/1717#issuecomment-401316909) was

> With the scm feature it is fixed. First the scm is run, then the exports, exports_sources and finally the source method is called.

How do you workaround that issue in Conan 2.x?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fschoenm
issue_14055: state: open
title: [question] QMake generator and Conan 2
body: ### What is your question?

Hi! I have a question regarding the QMake generator in Conan.

I've got a fair number of large projects which all build with QMake, and they've accumulated some dependencies over time. I'm looking to see if Conan would be suitable for dependency management for my projects. Looking at the Conan documentation, I see that the [QMake generator](https://docs.conan.io/1/integrations/build_system/qmake.html) in Conan 1 is a deprecated feature, and so I was wondering what the status of QMake support in Conan 2 is. As far as I can tell, QMake support is absent in Conan 2 as of now.

Right now, would you recommend to start using Conan 1 instead of 2 if I really need QMake support? If not, is QMake going to be supported in Conan 2?

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: JohannesKauffmann
issue_14042: state: open
title: [question] MesonToolchain loses access to global (system) .pc files? No way to use PKG_CONFIG_PATH?
body: ### What is your question?

I'm trying to upgrade gst-plugin-X Conan recipes to make them work with cross-building. Though it seems changing recipes to use `MesonToolchain` makes local (Debian 11 in my case) `.pc` files, and so system libraries, "inaccessible". And I am not even talking about cross-build, just native build.

For example, `gst-plugins-bad` searches for `libva` for hardware-accelerated video decoding:
```
Run-time dependency libva found: NO (tried pkgconfig and cmake)
Not looking for a fallback subproject for the dependency libva because:
Use of fallback dependencies is disabled.
Run-time dependency libva-drm found: NO (tried pkgconfig and cmake)
Not looking for a fallback subproject for the dependency libva-drm because:
Use of fallback dependencies is disabled.
```

I can do some dirty hack in https://github.com/conan-io/conan/blob/a930709b420553593032fb86e747b05d4e025566/conan/tools/meson/toolchain.py#L70, by changing line into:
```
{% if pkg_config_path %}pkg_config_path = ['{{pkg_config_path}}', '/usr/lib/pkgconfig', '/usr/lib/x86_64-linux-gnu/pkgconfig/', '/usr/share/pkgconfig']{% endif %}
```
This was successful, `gst-plugins-bad` was built with `va` support:
```
...
Run-time dependency libva found: YES 1.17.0
Run-time dependency libva-drm found: YES 1.17.0
Run-time dependency libdrm found: YES 2.4.104
...
```
Culprit is that `pkg_config_path` is only a generator dir:

https://github.com/conan-io/conan/blob/a930709b420553593032fb86e747b05d4e025566/conan/tools/meson/toolchain.py#LL149C11-L149C11

Or are there other ways to fix it?

When I will need to make it cross-build, toolchain declares like:
```
export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
export PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig
```
...will be also "lost" with `MesonToolchain'?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: Talkless
issue_14041: state: open
title: [bug] msys2 fails to build cmake template
body: ### Environment details

On Windows 11, I've installed a fresh `msys2` environment, using the newer `ucrt64` and `conan-2.0.5`.

The right configuration, because I'm running conan from within  `ucrt64` shell.
~~~~
tools.microsoft.bash:active=True
tools.microsoft.bash:subsystem=msys2
~~~~

~~~~
conanfile.py (dummy/0.1.0): RUN: cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="C:/Users/joris/workspace/3rdparty/dummy/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/joris/workspace/3rdparty/dummy" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "C:/Users/joris/workspace/3rdparty/dummy/."
'.' is not recognized as an internal or external command,
operable program or batch file.
~~~~

As far as I can deduce, the issue is with the last cmake configuration argument which is the path of the `CMakeLists.txt` and doesn't like that final dot: "C:/Users/joris/workspace/3rdparty/dummy/**.**"

### Steps to reproduce

Create a minimal cmake library:
~~~~
> conan new cmake_lib -d name=dummy -d version=0.1.0
...
> conan build . -v trace
~~~~

### Logs

~~~~
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=13.1
os=Windows
[options]
boost/*:pch=False
boost/*:without_fiber=True
boost/*:without_iostreams=True
boost/*:without_stacktrace=True
[conf]
tools.microsoft.bash:active=True
tools.microsoft.bash:subsystem=msys2
tools.cmake.cmaketoolchain:generator=Ninja

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=13.1
os=Windows
[options]
boost/*:pch=False
boost/*:without_fiber=True
boost/*:without_iostreams=True
boost/*:without_stacktrace=True
[conf]
tools.microsoft.bash:active=True
tools.microsoft.bash:subsystem=msys2
tools.cmake.cmaketoolchain:generator=Ninja
...
======== Calling build() ========
conanfile.py (dummy/0.1.0): Calling build()
conanfile.py (dummy/0.1.0): Running CMake.configure()
conanfile.py (dummy/0.1.0): RUN: cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="C:/Users/joris/workspace/3rdparty/dummy/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/joris/workspace/3rdparty/dummy" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "C:/Users/joris/workspace/3rdparty/dummy/."
'.' is not recognized as an internal or external command,
operable program or batch file.

Traceback (most recent call last):
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/errors.py", line 51, in conanfile_exception_formatter
    yield
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/client/conanfile/build.py", line 13, in run_build_method
    conanfile.build()
  File "C:/Users/joris/workspace/3rdparty/dummy/conanfile.py", line 43, in build
    cmake.configure()
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conan/tools/cmake/cmake.py", line 112, in configure
    self._conanfile.run(command)
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/model/conan_file.py", line 334, in run
    raise ConanException("Error %d while executing" % retcode)
conans.errors.ConanException: Error 1 while executing

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conan/cli/cli.py", line 171, in run
    command.run(self._conan_api, self._commands[command_argument].parser, args[0][1:])
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conan/cli/command.py", line 134, in run
    info = self._method(conan_api, parser, *args)
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conan/cli/commands/build.py", line 63, in build
    conan_api.local.build(conanfile)
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conan/api/subapi/local.py", line 97, in build
    run_build_method(conanfile, app.hook_manager)
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/client/conanfile/build.py", line 11, in run_build_method
    with conanfile_exception_formatter(conanfile, "build"):
  File "C:/msys64/ucrt64/lib/python3.10/contextlib.py", line 153, in __exit__
    self.gen.throw(typ, value, traceback)
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/errors.py", line 66, in conanfile_exception_formatter
    _raise_conanfile_exc(exc)
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/errors.py", line 46, in _raise_conanfile_exc
    raise ConanExceptionInUserConanfileMethod(traceback.format_exc())
conans.errors.ConanExceptionInUserConanfileMethod: Traceback (most recent call last):
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/errors.py", line 51, in conanfile_exception_formatter
    yield
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/client/conanfile/build.py", line 13, in run_build_method
    conanfile.build()
  File "C:/Users/joris/workspace/3rdparty/dummy/conanfile.py", line 43, in build
    cmake.configure()
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conan/tools/cmake/cmake.py", line 112, in configure
    self._conanfile.run(command)
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/model/conan_file.py", line 334, in run
    raise ConanException("Error %d while executing" % retcode)
conans.errors.ConanException: Error 1 while executing


ERROR: Traceback (most recent call last):
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/errors.py", line 51, in conanfile_exception_formatter
    yield
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/client/conanfile/build.py", line 13, in run_build_method
    conanfile.build()
  File "C:/Users/joris/workspace/3rdparty/dummy/conanfile.py", line 43, in build
    cmake.configure()
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conan/tools/cmake/cmake.py", line 112, in configure
    self._conanfile.run(command)
  File "C:/msys64/ucrt64/lib/python3.10/site-packages/conans/model/conan_file.py", line 334, in run
    raise ConanException("Error %d while executing" % retcode)
conans.errors.ConanException: Error 1 while executing
user: jputcu
issue_14038: state: open
title: Using options in build context not working with build requires!
body: ### What is your question?

I have some dependencies with options but no settings that are specified as build_requires.
Now I want to choose the right variant of the build dependency during a conan install command.

I was trying to use the -o:b and also the -pr:b command line parameter to hand over the right options for resolving the right variant of the build require. But it did no work, the option values given were not used to resolve the correct variant.

Only when I handed over the options as part of the host context (either -o, -o:h or -pr:h) it resolved to the correct build dependency.

I thought that all options and settings of build dependencies must be handed over in the build context. Or am I missing sth here?

PS. I am using Conan 1.60.1.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: MTomBosch
issue_14030: state: open
title: [bug] CMakeUserPresets.json gets generated when ConanFile.generators is set
body: ### Environment details

* Operating System+version: Windows 10 Pro
* Compiler+version: MSVC 193, VS2022
* Conan version: 1.60.1
* Python version:  3.10.10


### Steps to reproduce

using this as `conanfile.py`:
```python
import os.path

from conan import ConanFile
from conan.tools.layout import cmake_layout
from conan.tools.cmake import CMake, CMakeToolchain, CMakeDeps
from conan.tools.files import collect_libs, rmdir

required_conan_version = ">=1.51.0"

class TestConan(ConanFile):
    name = "test"
    description = "Testing"
    requires = [
        "fmt/9.1.0",
        "spdlog/1.11.0",
        "nlohmann_json/3.11.2",
    ]

    settings = "os", "arch", "compiler", "build_type"

    generators = "CMakeToolchain"

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def generate(self):
        tc = CMakeToolchain(self)
        tc.user_presets_path = False
        tc.generate()

        deps = CMakeDeps(self)
        deps.generate()

    def package(self):
        cmake = CMake(self)
        cmake.install()
        rmdir(self, os.path.join(self.package_folder, "lib", "cmake")) # remove native CMake package files

    def package_info(self):
        self.cpp_info.names["generator_name"] = "test"
        self.cpp_info.includedirs = ['include']  # Ordered list of include paths
        self.cpp_info.libs = collect_libs(self)  # The libs to link against
        self.cpp_info.system_libs = []  # System libs to link against
        self.cpp_info.libdirs = ['lib']  # Directories where libraries can be found
        self.cpp_info.resdirs = ['res']  # Directories where resources, data, etc. can be found
        self.cpp_info.bindirs = ['bin']  # Directories where executables and shared libs can be found
        self.cpp_info.srcdirs = []  # Directories where sources can be found (debugging, reusing sources)
        self.cpp_info.build_modules = {}  # Build system utility module files
        self.cpp_info.defines = []  # preprocessor definitions
        self.cpp_info.cflags = []  # pure C flags
        self.cpp_info.cxxflags = []  # C++ compilation flags
        self.cpp_info.sharedlinkflags = []  # linker flags
        self.cpp_info.exelinkflags = []  # linker flags
```
with empty `CMakeLists.txt` and run as:
```cmd
conan install -if out/conan -s build_type=Debug -s compiler.cppstd=20 .
```
produces `CMakeUserPresets.json`, even though it is explicitly disabled in `generate` function.

`CMakeUserPresets.json` is not produced when, either:
* install folder is not specified (i.e. the files are generated into the same folder as `conanfile.py` and `CMakeLists.txt` are stored)
* I remove the line `generators = "CMakeToolchain` from `conanfile.py`.

I am not sure if it is a bug or not, but seems inconsistent at least, plus `CMakeUserPresets.json` is really annoying as it breaks Visual Studio IDE.

### Logs

_No response_
user: risa2000
issue_14024: state: open
title: [question] CMake Generator priority
body: ### What is your question?

Hi! I have a question regarding the CMake Generator selection priority. I am wondering why configuration setting `tools.cmake.cmaketoolchain:generator` is prioritized over the `generator` parameter to `CMakeToolchain`s constructor?

I stumbled upon this recently in a recipe that simply wouldn't work with a multi-config generator, but a profile "forced" it to use "Ninja Multi-Config", even though I tried setting the generator in the `CMakeToolchain` constructor to just "Ninja". I have wondered about this choice of prioritization since.

EDIT; I'm talking about this function specifically: https://github.com/conan-io/conan/blob/a8074a2be4f7e48b328ced4417846a1b318a925e/conan/tools/cmake/toolchain/toolchain.py#L212-L248

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: PengolodhGoedath
issue_14021: state: open
title: [question] Minimum Windows version for Windows SDK
body: ### What is your question?

Does conan allow specifying minimum supported version for Windows SDK through os.version or some other setting? It's not always enough to just inject WINVER/_WIN32_WINNT as compile options through profile.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Nekto89
issue_14017: state: open
title: [feature] bootstrapping support
body: ### What is your suggestion?

We would like to use toolchains for both the host and build context.

```
[tool_requires]
gcc/[^8]
```

```
conan create \
  --profile:host aarch64-linux-gnu \
  --profile:host gcc-8 \
  --profile:build local \  # detects `x86_64-linux-gnu` build machine
  --profile:build gcc-8
```

This would then resolve `aarch64-linux-gnu-gcc` for the host context and `x86_64-linux-gnu-gcc` for the build context.

This is currently blocked on [this `TODO`](https://github.com/conan-io/conan/blob/a8074a2be4f7e48b328ced4417846a1b318a925e/conans/client/graph/graph_builder.py#L68).

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: mattyclarkson
issue_14016: state: open
title: [question] Propagation of ENVIRONMENT VARIABLES from transitive dependencies
body: ### What is your question?

Hi Conan Team,

I am using conan 2.0 to manage some packages that contain .lua files. The lua files depend on the ones in the required packages down the graph. 

Therefore, I need to propagate the LUA_PATH environment variable from the transitive dependencies to consuming packages up the graph. 
I am using 
`
def generate(self):
        vbenv= VirtualBuildEnv(self)
        [...]
        vbenv.generate()
`
By using `buildenv_info`, the environment variable is only passed to the next consuming package.
` def package_info(self):
self.buildenv_info.prepend_path("LUA_PATH", os.path.join(self.package_folder, "idl", "?.lua"))
`
I am wondering if I use buildenv_info in the wrong way or I have to build kind of a bridge to bring the environment variables from generate() to package_info().
Thanks in advance.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: xxdanlxx
issue_14015: state: open
title: [bug] Artifactory Community Edition for C/C++ failed to start
body: ### Environment details

_No response_

### Steps to reproduce

I downloaded the application through the link below and completed the decompression on my local machine.
[jfrog-artifactory-cpp-ce-7.59.9-windows](https://conan.io/downloads.html)
Then I ran artifactory.bat as an administrator(I haven’t done anything else apart from this.), but the console frequently displays error messages. It seems that it cannot be started properly.Could you help me take a look at this problem?I can provide all the logs.Thanks.

### Logs

From the access-service.log file.
```shell
2023-06-02T02:43:05.434Z [jfac ] [ERROR] [45b195bff37fa387] [.s.b.w.s.s.ErrorPageFilter:184] [27.0.0.1-8040-exec-1] - Forwarding to error page from request [/api/v1/system/ping] due to exception [The request was rejected because the header value "ç��é��" is not allowed.]
org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the header value "ç��é��" is not allowed.
	at org.springframework.security.web.firewall.StrictHttpFirewall$StrictFirewalledRequest.validateAllowedHeaderValue(StrictHttpFirewall.java:833)
...
2023-06-02T02:43:06.836Z [jfac ] [ERROR] [1c05319b66a89254] [.s.b.w.s.s.ErrorPageFilter:184] [27.0.0.1-8040-exec-2] - Forwarding to error page from request [/api/v1/system/ping] due to exception [The request was rejected because the header value "ç��é��" is not allowed.]
org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the header value "ç��é��" is not allowed.
...
2023-06-02T02:43:11.881Z [jfac ] [WARN ] [f3570b6fec3d726c] [o.j.c.ExecutionUtils:177      ] [jf-common-pool-1    ] - Retry 20 Elapsed 9.4 secs failed: Registration with router on URL http://localhost:8046 failed with error: UNAVAILABLE: io exception. Trying again
2023-06-02T02:43:16.901Z [jfac ] [WARN ] [f3570b6fec3d726c] [o.j.c.ExecutionUtils:177      ] [jf-common-pool-1    ] - Retry 30 Elapsed 14.41 secs failed: Registration with router on URL http://localhost:8046 failed with error: UNAVAILABLE: io exception. Trying again
...
```
user: yijianshuangdiao
issue_14010: state: open
title: [question] Conan search only shows packages that are outdated from recipe
body: ### What is your question?

Hi @memsharded I could observe with conan 1.45 and also 1.60 that when I am searching for a reference on a remote artifactory I only see outdated packages even though on the artifactory there is a new recipe revision which contains one non outdated package.

Th search command that reveals only outdated packages is the following:

````
$ conan search mypackage/1.0.1@user/stable -r remote-dev
Existing packages for recipe mypackage/1.0.1@user/stable:

Existing recipe in remote 'remote-dev':

    Package_ID: 0c7ac9a529c76b3697dd6c8b08eaea9cbbd48e44
        [options]
            shared: False
        [settings]
            arch: armv7hf
            build_type: Debug
            compiler: gcc
            compiler.libcxx: libstdc++11
            compiler.version: 9.3
            os: Linux
        Outdated from recipe: True

    Package_ID: 1299b26cefc5e04411a3481abe1c8b63227e2896
        [options]
            shared: False
        [settings]
            arch: x86
            build_type: Release
            compiler: Visual Studio
            compiler.runtime: MD
            compiler.version: 14
            os: Windows
        Outdated from recipe: True

    Package_ID: 14572928e5faf7a330814917e884bbf87f1d8b5d
        [options]
            shared: False
        [settings]
            arch: armv7hf
            build_type: Release
            compiler: gcc
            compiler.libcxx: libstdc++11
            compiler.version: 9.3
            os: Linux
        Outdated from recipe: True

    Package_ID: 251974cfdccce6efd38e10feccec3c61142d3a33
        [options]
            shared: False
        [settings]
            arch: armv7hf
            build_type: Release
            compiler: gcc
            compiler.libcxx: libstdc++
            compiler.version: 4.9
            os: Linux
        Outdated from recipe: True
````

Using the `--revision` flag shows both old and new recipe revisions on artifactory:

```
$ conan searchmypackage/1.0.1@user/stable -r remote-dev --revision
Revisions for 'mypackage/1.0.1@user/stable' at remote 'remote-dev':
eb650b8e69461657d08a298e6f4f81f0 (2023-05-31 00:09:44 UTC)
52c9fc7da5009c0e11d4cddf9bff688e (2022-09-08 10:39:34 UTC)
```

I thought conan search would by default return the packages from the latest recipe revision (eb650b8e69461657d08a298e6f4f81f0), if no revision is specified explicitly, and not just show the ones from an older recipe revision (52c9fc7da5009c0e11d4cddf9bff688e)? The `--outdated` flag seems to make no difference. With or without this flag I get only all outdated recipes from the old revision.

Only when I specify the latest recipe revision I get the search result I would have expected in the first place:

```
$ conan search mypackage/1.0.1@user/stable#eb650b8e69461657d08a298e6f4f81f0 -r remote-dev
Existing packages for recipe mypackage/1.0.1@user/stable:

Existing recipe in remote 'remote-dev':

    Package_ID: 2148b953e915707b8702b3a3c8eac94b4a9f6f37
        [options]
            shared: False
        [settings]
            arch: armv8
            build_type: Release
            compiler: gcc
            compiler.libcxx: libstdc++11
            compiler.version: 9
            os: Linux
        Outdated from recipe: False
```

```
$ conan search mypackage/1.0.1@user/stable#eb650b8e69461657d08a298e6f4f81f0 -r remote-dev --outdated
Existing packages for recipe mypackage/1.0.1@user/stable:

Existing recipe in remote 'remote-dev':

There are no outdated packages for reference 'mypackage/1.0.1@user/stable', but package recipe found.
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fjp
issue_14007: state: open
title: Dependency resolver in Conan is not smart? Version conflict
body: ### What is your question?

I have a conantxt.file with the following content: 
```
...
opencl-icd-loader/[>=2022.09.30]
opencl-clhpp-headers/[>=2022.09.30]
opencl-headers/[>=2022.09.30]
...
```
And during `conan install` I have:
```
Requirements
    ...
    opencl-clhpp-headers/2023.04.17#7c62fcc7ac2559d4839150d2ebaac5c8 - Downloaded (conancenter)
    opencl-headers/2022.09.30#ee45fce3f75c8803089c3b2546362187 - Downloaded (conancenter)
    opencl-icd-loader/2022.09.30#a757c4732c2aba4ab729746ed129c611 - Downloaded (conancenter)
    ...
Resolved version ranges
    ...
    opencl-clhpp-headers/[>=2022.09.30]: opencl-clhpp-headers/2023.04.17
    opencl-icd-loader/[>=2022.09.30]: opencl-icd-loader/2022.09.30
    ...
ERROR: Version conflict: opencl-clhpp-headers/2023.04.17->opencl-headers/2023.04.17, None->opencl-headers/2022.09.30.
```
We can see in CCI that OpenCL C and C++ headers have versions up to 2023.04.17, while latest version for OpenCL ICD loader is 2022.09.30.
I expect that conan can understand that he should download all 3 packages of version 2022.09.30. But instead, it downloaded all the dependencies with latest versions and faced with version conflict because `opencl-icd-loader` requires old version of `opencl-headers` than `opencl-clhpp-headers` package.

Is it a bug?
If no, what is the goal of having ranges in dependencies if conan cannot resolve them?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ilya-lavrenov
issue_14001: state: open
title: [bug] conan1 transitive override fails in diamond dependency variation
body: ### Environment details

* Operating System+version: ubuntu 20.04
* Compiler+version: gcc7
* Conan version: 1.60
* Python version: 3.10.9


### Steps to reproduce

Everything needed to reproduce the issue are documented in this repository: https://github.com/nicosmd/conan1-transitive-override-bug .
The problem seems to be so basic that I can't believe that it hasn't been caught yet by someone else but I was not able to find an issue which is similar to this one. So I'm very sorry when this bug is duplicated or not a bug but intended behavior.

### Logs

_No response_
user: nicosmd
issue_13997: state: open
title: [question] How to use MINGW64 Environment with msys2 recipe?
body: ### What is your question?

I've spent some time trying to work out how to use the [MINGW64 environment](https://www.msys2.org/docs/environments/) that ships with msys2 in a conan recipe, and I haven't been able to figure it out. This is in the context of trying to produce a native windows executable rather than one that has a dependency on `msys-2.0.dll`, which happens when using a vanilla `tool_requires("msys2/cci.latest")` as observed in https://github.com/conan-io/conan-center-index/pull/16284.

This injects a host dependency on msys2 downstream which would be desirable to avoid.

msys2 provides [some guidance](https://www.msys2.org/wiki/Launchers/) on how to launch an environment to achieve this (i.e., setting `MSYSTEM=MINGW64` in the environment before launching a login shell), but it's not clear to me how this fits in with the conan model of using `tools.microsoft.bash:path`, `tools.microsoft.bash:subsystem` and `win_bash=True`, or how the `msys2` recipe can be appropriately configured/overridden.

Any guidance that can be provided is appreciated!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: samuel-emrys
issue_13995: state: open
title: [bug] Exception when passing string arguments to commands on PowerShell with UTF8-BOM encoding
body: ### Environment details

* Operating System+version: Windows Server 2019, PowerShell 5.1
* Compiler+version:
* Conan version: 2.0.5
* Python version:


### Steps to reproduce

Running any command that accepts a string as input produces an exception. For example, running `conan config show "core.*"` throws this exception: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte`.

Other commands that do not require string input work fine, for example `conan --version`.

Changing the encoding of the PowerShell session solved the issue. To do that I used this command: `$PSDefaultParameterValues['*:Encoding'] = 'ascii'`.

### Logs

_No response_
user: zillemarco
issue_13984: state: open
title: [bug] Arrow with Parquet in Windows: arrow:parquet=True compile error
body: ### Environment details

* Operating System+version: Windows
* Compiler+version: MSVC 2019
* Conan version: 1.60
* Python version:


### Steps to reproduce

[requires]
boost/1.80.0
thrift/0.17.0
openssl/3.1.0

#zlib/1.2.13

libxml2/2.11.4
antlr4-cppruntime/4.13.0
gettext/0.21
#fmt/10.0.0
spdlog/1.11.0
#uchardet/0.0.7
libiconv/1.17
protobuf/3.21.9
leveldb/1.23
cli11/2.3.2
arrow/12.0.0

[generators]
cmake

[layout]
cmake_layout

[options]
arrow:shared=True
arrow:encryption=True
arrow:with_csv=True
arrow:with_zstd=True
arrow:parquet=True
arrow:with_openssl=True
arrow:with_boost=True


### Logs

```
  parquet_shared.vcxproj -> C:\.conan\113fda\1\build\release\Release\parquet.dll
  Building Custom Rule C:/.conan/113fda/1/src/cpp/src/parquet/CMakeLists.txt
  parquet_constants.cpp
  parquet_types.cpp
C:\.conan\51809f\1\include\thrift/transport/TTransportException.h(23,10): fatal error C1083: Cannot open include file: 'boost/numeric/conversion/cast.hpp': No such file or directory (compiling sour
ce file C:\.conan\113fda\1\src\cpp\src\generated\parquet_constants.cpp) [C:\.conan\113fda\1\build\src\parquet\parquet_test_support.vcxproj]
C:\.conan\51809f\1\include\thrift/transport/TTransportException.h(23,10): fatal error C1083: Cannot open include file: 'boost/numeric/conversion/cast.hpp': No such file or directory (compiling sour
ce file C:\.conan\113fda\1\src\cpp\src\generated\parquet_types.cpp) [C:\.conan\113fda\1\build\src\parquet\parquet_test_support.vcxproj]
arrow/12.0.0:
arrow/12.0.0: ERROR: Package 'be03e248e7e510cef0bea57f54aed973f80641c2' build failed
arrow/12.0.0: WARN: Build folder C:\.conan\113fda\1\build
ERROR: arrow/12.0.0: Error in build() method, line 530
        cmake.build()
        ConanException: Error 1 while executing cmake --build "C:\.conan\113fda\1\build" --config Release
```
user: jaimesalvador
issue_13981: state: open
title: Defining custom settings.yml for sanitizers
body: I already configured our `settings.yml` with sanitizer options per the doc a while back.  (BTW, why not just include these sanitization options in the default conan.io settings.yml?)

```
compiler:
    gcc: &gcc
        address_sanitizer: [None, True]
        hwaddress_sanitizer: [None, True]
        kernel_address_sanitizer: [None, True]
        thread_sanitizer: [None, True]
        undefined_behavior_sanitizer: [None, True]
        pointer_compare_sanitizer: [None, True] # only valid with address or kernel_address
        pointer_subtract_sanitizer: [None, True] # only valid with address or kernel_address
        shadow_call_stack_sanitizer: [None, True]
        leak_sanitizer: [None, True]
        stack_protector: [None, True]
        stack_check: [None, True]
    clang:
        address_sanitizer: [None, True]
        hwaddress_sanitizer: [None, True]
        thread_sanitizer: [None, True]
        memory_sanitizer: [None, True]
        undefined_behavior_sanitizer: [None, True]
```

But, I still don't know how to manage my `.conan/data` output.  As it is now, `conan install` just overwrites the dependency binaries per sanitization setting.  How does a `settings_user.yml` fix this?  Are you saying to upload different binaries to artifactory on a per-`settings.yml`-basis?  What does that look like?  I could in-theory upload the binaries to artifactory, but nobody else needs them other than me.

Oh, and `CONAN_SETTINGS_COMPILER_SANITIZER` seems not to be propagated for the conan 1.60 generator.  Is there something else I have to do to make that work?

> Even if I could do something with settings.yml, uploading and then downloading 65-package binaries that I already compiled on my macbook just because I changed a compiler flag seems wrong too.

_Originally posted by @hoyhoy in https://github.com/conan-io/conan/issues/5295#issuecomment-1564821799_
            
user: memsharded
issue_13980: state: open
title: [feature] Expert Mode "Config Unlocked" CMakeDeps alternative for Multi Config Projects
body: ### What is your suggestion?

1. please enjoy my bad jokes
2. There have been a few users asking for this and I've finally understood what they are asking for (hopefully)

### Current Situtation

Currently to have a multi-config setup with Conan you need to run `conan install` twice once with `build_type=Release` the second with `built_type=Debug` however if I want my deps _only_ in release (by adding `&:` to my `build_type`) I am still forced to do two installs because within `build/generators/fmt-Target-debug.cmake` there are limitations  to only filling in the properties if the CMake build type matches that individual install such as

```cmake
set_property(TARGET fmt::fmt PROPERTY INTERFACE_INCLUDE_DIRECTORIES
                     $<$<CONFIG:Debug>:${fmt_fmt_fmt_INCLUDE_DIRS_DEBUG}> APPEND)
```

This forces me to specify `cmake --config Debug` in order for my dependencies to be usable where I do need to run `cmake -config Release` (again will a full release set of deps) to validate that is also working. This is not possible without a second `conan install`

Now for a general default that makes sense in most cases that seems totally reasonable (thought the `_DEBUG` when this was a release package looks bizarre -- i double checked that cache package's `conaninfo.txt` does say release despite what CMake deps outputs)

### Desired workflow

Caveat: I know my project super duper well and this absolutely going to work despite the numerous pitfalls (aka please let me shoot myself I am a C++ developer, I like to live dangerously)

When developing new application logic, easier to just have that project in Debug to have symbols and logs whereas the dependencies are only needed in Release as they are stable.

Given I have a clean project with 
- `conan new cmake_exe --define name=hello -d version=0.1 -d requires=fmt/9.1.0`

I could like to call install _only once_ such as `conan install . -c tools.cmake.cmaketoolchain:generator="Ninja Multi-Config" -s '&:build_type=Debug' -s compiler.cppstd=17` 

I should then be able to call `cmake --preset conan-default` and `cmake --build build --config Debug` both of which work.
When I need to I should **also** be able to call `cmake --build build --config Release`... This fails...

```sh
$ cmake --build build --config Debug
[2/2] Linking CXX static library Debug/libhello.a
$ cmake --build build --config
Release
[1/2] Building CXX object CMakeFiles/hello.dir/Release/src/hello.cpp.o
FAILED: CMakeFiles/hello.dir/Release/src/hello.cpp.o
/tmp/conan0test/src/hello.cpp:3:10: fatal error: 'fmt/format.h' file not found
#include "fmt/format.h"
         ^~~~~~~~~~~~~~
1 error generated.
ninja: build stopped: subcommand failed.
```

> **Note**: To follow this you need to fix the defaults include and method call `#include "fmt/format.h"` and `fmt::print("Hello World!\n");` respectively in the `src/main.cpp` that was generated by `conan new` above

### Very rough proof of concept

If I manually delete this restriction by just doing a search and replace.

![image](https://github.com/conan-io/conan/assets/16867443/bd97de36-1015-432f-92d8-2501b74967f3)

I can then get the effect that I want

```sh
cmake --build build --config Release
[2/2] Linking CXX static library Release/libhello.a
```


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: prince-chrismc
issue_13979: state: open
title: [bug] cflags, cxxflags, sharedlinkflags and exelinkflags ignored when tools.android:cmake_legacy_toolchain set to `True`
body: ### Environment details

* Operating System+version: macos 
* Compiler+version: xcode 14.3
* Conan version: 2.0.6
* Python version: 3.11.3


### Steps to reproduce

If I set `tools.android:cmake_legacy_toolchain` to `True` in `package_info` of my Android NDK toolchain package, and after that define some flags in `self.cpp_info.cxxflags` and/or `self.conf_info.append('tools.build:cxxflags', '...')`, those flags are completely ignored. Only `cpp_info.defines` are propagated.

However, if I set the legacy toolchain to `False`, everything works.

I need to use legacy toolchain because [this bug is still not resolved](https://github.com/android/ndk/issues/1698).

I can workaround the issue by manually setting required flags in package's cmake script.

The reason can be seen from the generated `conan_toolchain.cmake` file. Here is the relevant part:

```cmake
set(ANDROID_PLATFORM android-21)
set(ANDROID_STL c++_static)
set(ANDROID_ABI arm64-v8a)
set(ANDROID_USE_LEGACY_TOOLCHAIN_FILE ON)
include(/Users/dodo/.conan2/p/b/androf215ba3bae550/p/build/cmake/android.toolchain.cmake)



# Extra c, cxx, linkflags and defines
string(APPEND CONAN_CXX_FLAGS " -nostdinc++ -isystem /Users/dodo/.conan2/p/b/androf215ba3bae550/p/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1")
string(APPEND CONAN_SHARED_LINKER_FLAGS " -nostdlib++ /Users/dodo/.conan2/p/b/androf215ba3bae550/p/mb-stl/arm64-v8a/libc++.a /Users/dodo/.conan2/p/b/androf215ba3bae550/p/mb-stl/arm64-v8a/libc++abi.a -lc")
string(APPEND CONAN_EXE_LINKER_FLAGS " -nostdlib++ /Users/dodo/.conan2/p/b/androf215ba3bae550/p/mb-stl/arm64-v8a/libc++.a /Users/dodo/.conan2/p/b/androf215ba3bae550/p/mb-stl/arm64-v8a/libc++abi.a -lc")
add_compile_definitions( "_LIBCPP_ABI_VERSION=2" "_LIBCPP_ABI_UNSTABLE=1")
```

The problem is that legacy `android.toolchain.cmake` already initializes `CMAKE_CXX_FLAGS` and friends, so any later `CMAKE_CXX_FLAGS_INIT` have not effect. Non-legacy android toolchain doesn't seem to do that - it uses `CMAKE_CXX_FLAGS_INIT` as any modern toolchain should do.

I'm not entirely sure, but I think that the issue could be mitigated by generating `include( .../android.toolchain.cmake )` after defining `CMAKE_CXX_FLAGS_INIT` and friends.

### Logs

_No response_
user: DoDoENT
issue_13977: state: open
title: [bug] Conan should unset VSINSTALLDIR before calling vcvars
body: ### Environment details

Windows + Visual Studio

### Steps to reproduce

This occurs in many different places, but here's one example. I'm experiencing it when calling `conan install` (actually through `BinaryInstaller` using a conan profile that uses a different version of Visual Studio than the one you are currently in. 

When a package is installed that uses CMakeDeps and the Ninja generator, a `conanvcvars.bat` file is generated, which is invoked when actually building. That file calls the `vcvarsall.bat` file corresponding to the Visual Studio version defined in the profile. 

This only works if `VSINSTALLDIR` is not set. `vcvarsall.bat` internally calls `vsdevcmd_start.bat` which has the following block of code.
```bat
if "%VSINSTALLDIR%" NEQ "" goto :set_devenvdir
@REM Set VSINSTALLDIR to Visual Studio Installation Directory
@REM vsdevcmd_start.bat location: Microsoft Visual Studio 16.0\Common7\Tools\vsdevcmd\core
@REM VSINSTALLDIR location: Microsoft Visual Studio 16.0
pushd "%~dp0..\..\..\..\"
set "VSINSTALLDIR=%CD%\"
popd
```

So it uses `VSINSTALLDIR` if it's set, and otherwise automatically detects it from the location of the `bat` file. `VSINSTALLDIR` is then used for finding extensions like location of compilers, cmake and so on. Since the list of extensions is determined by which `vcvarsall.bat` file you call, the resulting effect is that you get a frankenstein combination of Visual Studio, and unless you have the exact same extensions installed in both versions there will be errors.

The solution is simple, just undef the `VSINSTALLDIR` environment variable before calling `vcvarsall.bat`. At least for the purpose of CMake this is enough to make it work. But I haven't read the bat files in detail, there could be some other environment variables worth undefining too.

### Logs

_No response_
user: fredizzimo
issue_13976: state: open
title: [bug] CMakeDeps: Malformed generator expression set in imported target property
body: ### Environment details

* Windows 11
* Visual Studio 2022
* Conan 2.0.5
* Python 3.8.10
* CMake 3.26.0-rc3

### Steps to reproduce

#### Description
I'm having a problem in my project, which I could reproduce in a simple C++ HelloWorld CMake project (attached).
The project uses CMakeDeps and CMakeToolchain generators.

When reading INTERFACE_COMPILE_OPTIONS property of an imported target in CMake, it contains malformed generator expression:
 `$<$<CONFIG:Debug>:$<$<COMPILE_LANGUAGE:CXX>:>`
 whereas it should be:
 `$<$<CONFIG:Debug>:$<$<COMPILE_LANGUAGE:CXX>:>>`

My CMakeLists.txt file:
```
cmake_minimum_required(VERSION 3.26)
project(HelloWorld)

find_package(fmt REQUIRED)

# Print interface compile options
get_target_property(x fmt::fmt-header-only INTERFACE_COMPILE_OPTIONS)
foreach(y ${x})
    message("${y}")
endforeach()

add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} PRIVATE fmt::fmt-header-only)
```
#### Steps to reproduce:
1. Download [helloworld.zip](https://github.com/conan-io/conan/files/11575217/helloworld.zip) and extract the source code.
2. Run build.bat in project root in cmd.exe.
3. Find the generator expression printed in output.
#### Output:
Output log contains the following line:
`$<$<CONFIG:Release>:$<$<COMPILE_LANGUAGE:CXX>:>`
#### Expected:
`$<$<CONFIG:Release>:$<$<COMPILE_LANGUAGE:CXX>:>>`




### Logs

```
D:\dev\helloworld>build.bat

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=17
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=17
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows


======== Computing dependency graph ========
Graph root
    conanfile.py: D:\dev\helloworld\conanfile.py
Requirements
    fmt/9.1.0#44302d39c5a4bf7de8a39adc50bb4568 - Cache

======== Computing necessary packages ========
Requirements
    fmt/9.1.0#44302d39c5a4bf7de8a39adc50bb4568:da39a3ee5e6b4b0d3255bfef95601890afd80709#23660355cc67a81c3b47d66bb487e3ef - Cache

======== Installing packages ========
fmt/9.1.0: Already installed! (1 of 1)
WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated:     'cpp_info.names' used in: fmt/9.1.0

======== Finalizing install (deploy, generators) ========
conanfile.py: Writing generators to D:\dev\helloworld\build
conanfile.py: Generator 'CMakeDeps' calling 'generate()'
conanfile.py: Generator 'CMakeToolchain' calling 'generate()'
conanfile.py: CMakeToolchain generated: conan_toolchain.cmake
conanfile.py: Preset 'conan-default' added to CMakePresets.json. Invoke it manually using 'cmake --preset conan-default' if using CMake>=3.23
conanfile.py: If your CMake version is not compatible with CMakePresets (<3.23) call cmake like: 'cmake <path> -G "Visual Studio 17 2022" -DCMAKE_TOOLCHAIN_FILE=D:\dev\helloworld\build\conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW'
conanfile.py: CMakeToolchain generated: CMakePresets.json
conanfile.py: CMakeToolchain generated: ..\CMakeUserPresets.json
conanfile.py: Generating aggregated env files
conanfile.py: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
Install finished successfully
-- Using Conan toolchain: D:/dev/helloworld/build/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 17 with extensions OFF
-- Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.22621.
-- The C compiler identification is MSVC 19.35.32217.1
-- The CXX compiler identification is MSVC 19.35.32217.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.35.32215/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.35.32215/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: Component target declared 'fmt::fmt-header-only'
$<$<CONFIG:Release>:$<$<COMPILE_LANGUAGE:CXX>:>
$<$<COMPILE_LANGUAGE:C>:>>
-- Configuring done (3.3s)
-- Generating done (0.0s)
-- Build files have been written to: D:/dev/helloworld/build
MSBuild version 17.5.1+f6fdcf537 for .NET Framework

  1>Checking Build System
  1>Building Custom Rule D:/dev/helloworld/CMakeLists.txt
  main.cpp
  HelloWorld.vcxproj -> D:\dev\helloworld\build\Release\HelloWorld.exe
  1>Building Custom Rule D:/dev/helloworld/CMakeLists.txt
```
user: hadi-rahimi
issue_13969: state: open
title: [feature] Rust dependencies
body: ### What is your suggestion?

It is possible to write libraries in Rust that are intended for consumption by C/C++. It would be nice if we could write a conanfile that calls cargo and then extracts the resulting files and hooks everything up to `find_package` nicely.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: obsgolem
issue_13962: state: open
title: [question] cross building packages that uses PkgConfig.fill_cpp_info
body: ### What is your question?

I've been trying to cross compile some packages from Windows to raspberry pi with conan 2.0.4
host profile:
```
[settings]
os=Linux
arch=armv7
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=8
[conf]
tools.build:compiler_executables={"c": "arm-linux-gnueabihf-gcc-8", "cpp": "arm-linux-gnueabihf-g++"}
tools.build:sysroot=C:\\SysGCC\\raspberry\\arm-linux-gnueabihf\\sysroot
tools.gnu:make_program=C:/SysGCC/raspberry/bin/make
[buildenv]
PKG_CONFIG_PATH=C:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\lib\arm-linux-gnueabihf\pkgconfig;C:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\usr\lib\arm-linux-gnueabihf\pkgconfig;C:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\usr\lib\pkgconfig;C:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\usr\share\pkgconfig
```
Build profile 
```
[settings]
os=Windows
arch=x86_64
build_type=Release
compiler=msvc
compiler.runtime=dynamic
compiler.cppstd=20
compiler.version=193
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
```
And I having an issue with any system package, for example opengl/system, that uses PkgConfig.fill_cpp_info in package_info method. 
```
ERROR: opengl/system: Error in package_info() method, line 61
        pkg_config.fill_cpp_info(self.cpp_info, is_system=self.settings.os != "FreeBSD")
        ConanException: Command 'pkg-config --print-provides gl --print-errors' failed with errorcode '1'
b"Package gl was not found in the pkg-config search path.\r\nPerhaps you should add the directory containing `gl.pc'\r\nto the PKG_CONFIG_PATH environment variable\r\nNo package 'gl' found\r\n"
```
I can set PKG_CONFIG_PATH before calling `conan install` and everything works quite well then, but it seems not right for me. Is there a way to set this environment variable by conan?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: LadyzRoman
issue_13960: state: open
title: [question] SHORT DESCRIPTION
body: ### What is your question?

When I compile and link my application with mbedtls using conan I get an error:

```error: ‘mbedtls_ssl_conf_tls13_key_exchange_modes’ was not declared in this scope```

my conan.py includes the latest version of mbedtls:

```    requires = [...,  "mbedtls/3.2.1", ...  ] ```

when I use mbedtls as a git submodule I can configure it:

```mbedtls/scripts/config.py set MBEDTLS_SSL_PROTO_TLS1_3```

and my code does compile smoothly. So my question is: how to configure it so that I can compile it using conan?





### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ronnieott
issue_13959: state: open
title: [question] Dependency graph computation for tool_requires in conan 2.0
body: ### What is your question?

Dear Conan Team,

 we are facing issues while migrating some of our recipes to `conan 2.x`. We have some base tooling which is used in all our packages inclusive in the base tooling one.

- Lets say we have 2 packages named `my-build-tool` and `my-doc-tool` which are `tool_requires` on each other. They are building fine in `conan 1.x`.

- I updated and released both packages after making the recipes compatible with `conan 1.x` and `conan 2.x` by changing for example the legacy `from conans` import to `from conan`.

- When I try to build `my-build-tool` and `my-doc-tool` using `conan 2.x`, it fails because conan tries to load the recipes all the way down the dependency graph and ultimately hits the `from conans` import from old packages.

I tried to show this in the picture:

![image](https://github.com/conan-io/conan/assets/5364255/18a7c1bd-7115-4e69-904d-6ece1eeeeded)


How do we deal with such a situation? Can you suggest if there is any way to support this use case?


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sandeshhardikar
issue_13956: state: open
title: [question] What is the difference between test_requires() or build_requires(, force_host_context=True) and requires with "private" flag?
body: ### What is your question?

What is the difference between test_requires() or build_requires(, force_host_context=True) and requires with "private" flag?

This refers to the documentation:
https://docs.conan.io/1/devtools/build_requires.html#build-and-host-contexts
https://docs.conan.io/1/reference/conanfile/attributes.html#requires

e.g. what is the difference between:

```
def build_requirements(self):
        self.test_requires("pkgA/0.1")
```

and 

```
def requirements(self):
        self.requires("pkgA/0.1", "private")
```

?

I assume in both cases it does not lead to transitive dependencies and they are in the host context, right?


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: SzBosch
issue_13938: state: open
title: [question] Revisions and requirements overriding
body: ### What is your question?

Hello everyone,

I have a question regarding the recipe revisions and support for requirement overriding.

I have two different recipe revisions hosted in local Artifactory and the only difference between the recipes is the requirements specification (they build the same version of the library - only the dependency is different):

- Recipe one:
```
def requirements(self):
       ...
       if self.options.with_openssl:
           self.requires("openssl/1.1.1p")
       ...
```
  

- Recipe two:
```
def requirements(self):
       ...
       if self.options.with_openssl:
           self.requires("openssl/1.1.1t")
       ...
```

I was expecting that depending on the explicit requirement override the proper revision of the binary package will be pulled into cache. Unfortunately this is not the case and even if openssl/1.1.1p is explicitly requested the binary created from the recipe two (the newer revision) is being used with the following warning:

```
cassandra-cpp-driver/2.16.0: Downloaded recipe revision 7442e6ce8e6a7431a8d2191fa83fc71d
WARN: cassandra-cpp-driver/2.16.0: requirement openssl/1.1.1t overridden by your conanfile to openssl/1.1.1p 
```

This creates a huge problem where older branches of the product I'm working on are actually using (or trying to use) the never version of the recipe which was build with the different binary dependencies. 

What is the proper way of handling cases like that? 
I wanted to avoid adding explicit suffix versioning to the 3rd party library.

To summarize - when I'm updating some dependency (like OpenSSL) I want to update all the packages that were using this dependency, but without breaking the old branches that were using those same packages just built with different versions of the package they depend on.

Also is there any way aside from rewriting Git history and adding explicit revision specification to the older branches to get out of the mess I have put myself into?

Thank you and kind regards,
Grzegorz 
 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: roszakg
issue_13930: state: open
title: New ``local-recipes-index`` feature
body: Changelog: Feature: Allow adding a folder with a clone of conan-center-index or same folder structure as a remote.
Docs: https://github.com/conan-io/docs/pull/XXXX

How to use it:

```bash
$ git clone git@github.com:conan-io/conan-center-index
$ conan remote add c3ifork file:///path/to/cloned/conan-center-index
// use it as normal
$ conan search opencv*
$ conan graph info --requires=opencv/4.5.5 -r=c3ifork --format=html > file.html
```


user: memsharded
issue_13927: state: open
title: [feature] Add additional architectures for MCUs to the default settings.yml
body: ### What is your suggestion?

Would it be possible to add additional architectures for embedded microcontrollers to the default `settings.yml` file? This would make it possible to support CI in Conan Center for recipe's targeting microcontrollers such as conan-io/conan-center-index#17528.

This particular recipe is focused on the Arm embedded architectures, which are almost always actually the thumb variations of the ISA instead of the `arm` forms.
Rust has some helpful naming conventions for these: `thumbv6m`, `thumbv7m`, and `thumbv7em`, `thumbv8m.base`, and `thumbv8m.main` documented [here](https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-2-with-host-tools).
It's also possible to use GCC's naming conventions described [here](https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/ARM-Options.html#ARM-Options-1): `armv6-m`, `armv7-m`, `armv7e-m`, `armv8.1-m.main`, and `armv8-m.main`.
Note that it is probably important to make the distinction between the `thumb` format and the `arm` format, though in practice the `thumb` format is used for microcontrollers.

Of course, the ISA's for microcontrollers have a lot more configurability, so properly defining everything would require a lot of subsettings to define the FPU, floating-point ABI, and extensions, though many of these could alternatively be defined by consumers directly via compiler and linker flags through the `conf` options for `tools.build.*flags`.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: jwillikers
issue_13921: state: open
title: [Question] DuplicateOptionError Conan 1.60.0
body: ### What is your question?

Dear Conan community,

I am working with Conan for the first time as part of a software development project. The software developer who provides the software I use recommends a Conan version released before v2.0.0. I installed v1.60.0 on Linux with the following command:

`sudo pip install -U "conan<2.0"`

After that I have made the configuration. 
In the next step I wanted to compile one of the samples which was also provided by the software developer. I received the following error message

`ERROR: while executing system_requirements(): System requirements: "libasound2, libasound2-dev" are missing but can´t install because tools.system.package_manager:mode is "check". Please update packages manually or set "tools.system.package_manager:mode" to "install" in the [conf] section of the profile, or in the command line using "-c tools.system.package_manager:mode=install"`

libasound2 and libasound2-dev are definitely installed and up to date.
The software manufacturer recommends adding the following lines to global.conf in case of this error

`tools.system.package_manager:mode=install`
`tools.system.package_manager:sudo=True`

Unfortunately, I cannot find a global.conf in version 1.60.0 and have not yet found any useful information on how to create one or in which path it should be stored. Therefore, I have tried to modify the global.conf accordingly

`[log]`
`run_to_output = True`
`run_to_file = False`
`level = critical`
`print_run_commands = False`

`[general]`
`default_profile = default`
`compression_level = 9`
`sysrequires_sudo = True`
`request_timeout = 60`
`default_package_id_mode = semver_direct_mode`
`revision_enabled = 1`

`[storage]`
`path = ./data`

`[proxies]`

`[hooks]`
`attribute_checker`

`[tools]`
`system.package_manager:mode = install`
`system.package_manager:sudo = True`

Unfortunately, when trying to compile the sample with this conan.conf, I get this error message

`raise DuplicateOptionError(sectname, optname, configparser.DuplicateOptionError: While reading from "/home/miti/.conan/conan.conf" [line 25]: option "system.package_manager" in section "tools" already exists`

I also tried to solve the problem with `unset`, but that didn't work either.
Unfortunately I don't know how to fix this problem, so I would be very grateful for tips on how to create the global.conf or how to adjust the conan.conf so that the compilation of the sample works. 

Thanks a lot!

n1n14

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: n1n14
issue_13908: state: open
title: Multi-Config CMake Presents do not work with VS Code using CMake extension
body: Conan version: 2.0.4
Platform, OS: MacOS
CMake version: 3.26.0
CMake VS Code extension and its version: https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools 1.15.8


***

Only the default "configure" preset is loaded and detected how ever it's not possible to build and test with the debug or release presets. Everything is done with "Default" which in my case was release that I ran first

You can see only one option is preset
![image](https://github.com/conan-io/conan/assets/16867443/d9375e1b-5cd1-481e-a6e7-bc96fead5ca2)

I was not able to find anything suggest that picking a build or test preset when opening the project

```
7932  conan new cmake_lib --define name=hello -d version=0.1
7941  conan install . -c tools.cmake.cmaketoolchain:generator="Ninja Multi-Config"
7942  conan install . -c tools.cmake.cmaketoolchain:generator="Ninja Multi-Config" -s build_type=Debug
7943  cmake --preset conan-default
7944  cmake --build --preset conan-release
7945  cmake --build --preset conan-debug
```
user: prince-chrismc
issue_13890: state: open
title: [bug] Transitive dependencies aren't reported to cmake properly by CMakeDeps
body: ### Environment details

* Compiler+version: gcc 11.2.0
* Conan version: 2.0.4
* Python version: 3.11.3

### Steps to reproduce

1. Clone https://github.com/sfackler/conan-rpathlink-issue
2. Run `conan create `.
3. With a "normal" compiler, the build succeeds.
4. Run `CC=<compiler with a sysroot> conan create .`
5. Note that the build fails, with the compiler failing to find libz.so.1 when linking the test program.

I used crosstool-ng to make a compiler with a sysroot in this case, but if you don't want to go through the trouble, you can just look at the generated `link.txt` and see that there is no `rpath-link` entry:

```
/home/sfackler/x-tools/x86_64-linux-gnu/bin/x86_64-linux-gnu-gcc -m64 -O3 -DNDEBUG -m64 CMakeFiles/example.dir/src/example.c.o -o example   -L/home/sfackler/conan/.conan2/p/rpath38d4c26dea5c2/p/lib  -L/home/sfackler/conan/.conan2/p/zlibdbf95c5056fc3/p/lib  -Wl,-rpath,/home/sfackler/conan/.conan2/p/rpath38d4c26dea5c2/p/lib:/home/sfackler/conan/.conan2/p/zlibdbf95c5056fc3/p/lib /home/sfackler/conan/.conan2/p/rpath38d4c26dea5c2/p/lib/librpathlink.so
```

### Logs

<details><summary>Successful build with the default system gcc</summary>
<p>

```
======== Exporting recipe to the cache ========
rpathlink/1.0.0: Exporting package recipe: /home/sfackler/conan/rpathlink/conanfile.py
rpathlink/1.0.0: Copied 1 '.py' file: conanfile.py
rpathlink/1.0.0: Copied 1 '.txt' file: CMakeLists.txt
rpathlink/1.0.0: Copied 1 '.c' file: rpathlink.c
rpathlink/1.0.0: Copied 1 '.h' file: rpathlink.h
rpathlink/1.0.0: Exported to cache folder: /home/sfackler/conan/.conan2/p/rpath119ffb15b4eaf/e
rpathlink/1.0.0: Exported: rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf (2023-05-14 01:29:30 UTC)

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=12
os=Linux

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++12
compiler.version=12
os=Linux


======== Computing dependency graph ========
Graph root
    cli
Requirements
    rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf - Cache
    zlib/1.2.13#e377bee636333ae348d51ca90874e353 - Cache

======== Computing necessary packages ========
rpathlink/1.0.0: Forced build from source
Requirements
    rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf:ec5adadcb11acf21b8f297bf2ccd5426fb4b0578 - Build
    zlib/1.2.13#e377bee636333ae348d51ca90874e353:9a7f5466b6926f6dc790c94d617e893533d5c141#820168803a1b6fa582975fc10c2a284c - Cache

======== Installing packages ========
zlib/1.2.13: Already installed! (1 of 2)

-------- Installing package rpathlink/1.0.0 (2 of 2) --------
rpathlink/1.0.0: Building from source
rpathlink/1.0.0: Package rpathlink/1.0.0:ec5adadcb11acf21b8f297bf2ccd5426fb4b0578
rpathlink/1.0.0: Copying sources to build folder
rpathlink/1.0.0: Building your package in /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b
rpathlink/1.0.0: Calling generate()
rpathlink/1.0.0: Generators folder: /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release/generators
rpathlink/1.0.0: CMakeToolchain generated: conan_toolchain.cmake
rpathlink/1.0.0: CMakeToolchain generated: CMakePresets.json
rpathlink/1.0.0: CMakeToolchain generated: ../../../CMakeUserPresets.json
rpathlink/1.0.0: Generating aggregated env files
rpathlink/1.0.0: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
rpathlink/1.0.0: Calling build()
rpathlink/1.0.0: Running CMake.configure()
rpathlink/1.0.0: RUN: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/."
-- Using Conan toolchain: /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 17 with extensions ON
-- Conan toolchain: Setting BUILD_SHARED_LIBS = ON
-- The C compiler identification is GNU 12.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Conan: Target declared 'ZLIB::ZLIB'
-- Configuring done (0.6s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_POLICY_DEFAULT_CMP0091


-- Build files have been written to: /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release

rpathlink/1.0.0: Running CMake.build()
rpathlink/1.0.0: RUN: cmake --build "/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release" -- -j24
[ 50%] Building C object CMakeFiles/rpathlink.dir/src/rpathlink.c.o
[100%] Linking C shared library librpathlink.so
[100%] Built target rpathlink

rpathlink/1.0.0: Package 'ec5adadcb11acf21b8f297bf2ccd5426fb4b0578' built
rpathlink/1.0.0: Build folder /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release
rpathlink/1.0.0: Generating the package
rpathlink/1.0.0: Temporary package folder /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p
rpathlink/1.0.0: Calling package()
rpathlink/1.0.0: Running CMake.install()
rpathlink/1.0.0: RUN: cmake --install "/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release" --prefix "/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p"
-- Install configuration: "Release"
-- Installing: /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p/lib/librpathlink.so
-- Set runtime path of "/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p/lib/librpathlink.so" to ""
-- Installing: /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p/include/rpathlink.h

rpathlink/1.0.0: package(): Packaged 1 '.h' file: rpathlink.h
rpathlink/1.0.0: package(): Packaged 1 '.so' file: librpathlink.so
rpathlink/1.0.0: Created package revision 0563b0f16e58f9df25d79e529beb6c0e
rpathlink/1.0.0: Package 'ec5adadcb11acf21b8f297bf2ccd5426fb4b0578' created
rpathlink/1.0.0: Full package reference: rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf:ec5adadcb11acf21b8f297bf2ccd5426fb4b0578#0563b0f16e58f9df25d79e529beb6c0e
rpathlink/1.0.0: Package folder /home/sfackler/conan/.conan2/p/rpathb43975b8a1012/p
WARN: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN:     'cpp_info.names' used in: zlib/1.2.13

======== Launching test_package ========

======== Computing dependency graph ========
Graph root
    rpathlink/1.0.0 (test package): /home/sfackler/conan/rpathlink/test_package/conanfile.py
Requirements
    rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf - Cache
    zlib/1.2.13#e377bee636333ae348d51ca90874e353 - Cache

======== Computing necessary packages ========
Requirements
    rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf:ec5adadcb11acf21b8f297bf2ccd5426fb4b0578#0563b0f16e58f9df25d79e529beb6c0e - Cache
    zlib/1.2.13#e377bee636333ae348d51ca90874e353:9a7f5466b6926f6dc790c94d617e893533d5c141#820168803a1b6fa582975fc10c2a284c - Cache

======== Installing packages ========
zlib/1.2.13: Already installed! (1 of 2)
rpathlink/1.0.0: Already installed! (2 of 2)
WARN: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN:     'cpp_info.names' used in: zlib/1.2.13

======== Testing the package ========
Removing previously existing 'test_package' build folder: /home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release
rpathlink/1.0.0 (test package): Test package build: build/gcc-12-x86_64-gnu17-release
rpathlink/1.0.0 (test package): Test package build folder: /home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release
rpathlink/1.0.0 (test package): Writing generators to /home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release/generators
rpathlink/1.0.0 (test package): Generator 'CMakeDeps' calling 'generate()'
rpathlink/1.0.0 (test package): Generator 'CMakeToolchain' calling 'generate()'
rpathlink/1.0.0 (test package): CMakeToolchain generated: conan_toolchain.cmake
rpathlink/1.0.0 (test package): CMakeToolchain generated: CMakePresets.json
rpathlink/1.0.0 (test package): CMakeToolchain generated: ../../../CMakeUserPresets.json
rpathlink/1.0.0 (test package): Generating aggregated env files
rpathlink/1.0.0 (test package): Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']

======== Testing the package: Building ========
rpathlink/1.0.0 (test package): Calling build()
rpathlink/1.0.0 (test package): Running CMake.configure()
rpathlink/1.0.0 (test package): RUN: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/sfackler/conan/rpathlink/test_package" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/sfackler/conan/rpathlink/test_package/."
-- Using Conan toolchain: /home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 17 with extensions ON
-- The C compiler identification is GNU 12.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Conan: Target declared 'rpathlink::rpathlink'
-- Conan: Target declared 'ZLIB::ZLIB'
-- Configuring done (0.6s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_POLICY_DEFAULT_CMP0091


-- Build files have been written to: /home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release

rpathlink/1.0.0 (test package): Running CMake.build()
rpathlink/1.0.0 (test package): RUN: cmake --build "/home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release" -- -j24
[ 50%] Building C object CMakeFiles/example.dir/src/example.c.o
[100%] Linking C executable example
[100%] Built target example


======== Testing the package: Executing test ========
rpathlink/1.0.0 (test package): Running test()
rpathlink/1.0.0 (test package): RUN: ./example
1.2.13
```
</p>
</details> 

<details><summary>Failing build with a custom gcc built with a sysroot</summary>
<p>

```

======== Exporting recipe to the cache ========
rpathlink/1.0.0: Exporting package recipe: /home/sfackler/conan/rpathlink/conanfile.py
rpathlink/1.0.0: Copied 1 '.py' file: conanfile.py
rpathlink/1.0.0: Copied 1 '.txt' file: CMakeLists.txt
rpathlink/1.0.0: Copied 1 '.c' file: rpathlink.c
rpathlink/1.0.0: Copied 1 '.h' file: rpathlink.h
rpathlink/1.0.0: Exported to cache folder: /home/sfackler/conan/.conan2/p/rpath119ffb15b4eaf/e
rpathlink/1.0.0: Exported: rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf (2023-05-14 01:29:40 UTC)

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=12
os=Linux

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=12
os=Linux


======== Computing dependency graph ========
Graph root
    cli
Requirements
    rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf - Cache
    zlib/1.2.13#e377bee636333ae348d51ca90874e353 - Cache

======== Computing necessary packages ========
rpathlink/1.0.0: Forced build from source
Requirements
    rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf:ec5adadcb11acf21b8f297bf2ccd5426fb4b0578 - Build
    zlib/1.2.13#e377bee636333ae348d51ca90874e353:9a7f5466b6926f6dc790c94d617e893533d5c141#820168803a1b6fa582975fc10c2a284c - Cache

======== Installing packages ========
zlib/1.2.13: Already installed! (1 of 2)

-------- Installing package rpathlink/1.0.0 (2 of 2) --------
rpathlink/1.0.0: Building from source
rpathlink/1.0.0: Package rpathlink/1.0.0:ec5adadcb11acf21b8f297bf2ccd5426fb4b0578
rpathlink/1.0.0: Copying sources to build folder
rpathlink/1.0.0: Building your package in /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b
rpathlink/1.0.0: Calling generate()
rpathlink/1.0.0: Generators folder: /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release/generators
rpathlink/1.0.0: CMakeToolchain generated: conan_toolchain.cmake
rpathlink/1.0.0: CMakeToolchain generated: CMakePresets.json
rpathlink/1.0.0: CMakeToolchain generated: ../../../CMakeUserPresets.json
rpathlink/1.0.0: Generating aggregated env files
rpathlink/1.0.0: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
rpathlink/1.0.0: Calling build()
rpathlink/1.0.0: Running CMake.configure()
rpathlink/1.0.0: RUN: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/."
-- Using Conan toolchain: /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 17 with extensions ON
-- Conan toolchain: Setting BUILD_SHARED_LIBS = ON
-- The C compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/sfackler/x-tools/x86_64-linux-gnu/bin/x86_64-linux-gnu-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Conan: Target declared 'ZLIB::ZLIB'
-- Configuring done (0.6s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_POLICY_DEFAULT_CMP0091


-- Build files have been written to: /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release

rpathlink/1.0.0: Running CMake.build()
rpathlink/1.0.0: RUN: cmake --build "/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release" -- -j24
[ 50%] Building C object CMakeFiles/rpathlink.dir/src/rpathlink.c.o
[100%] Linking C shared library librpathlink.so
[100%] Built target rpathlink

rpathlink/1.0.0: Package 'ec5adadcb11acf21b8f297bf2ccd5426fb4b0578' built
rpathlink/1.0.0: Build folder /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release
rpathlink/1.0.0: Generating the package
rpathlink/1.0.0: Temporary package folder /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p
rpathlink/1.0.0: Calling package()
rpathlink/1.0.0: Running CMake.install()
rpathlink/1.0.0: RUN: cmake --install "/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/b/build/Release" --prefix "/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p"
-- Install configuration: "Release"
-- Installing: /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p/lib/librpathlink.so
-- Set runtime path of "/home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p/lib/librpathlink.so" to ""
-- Installing: /home/sfackler/conan/.conan2/p/t/rpatha5f78c2d1da0b/p/include/rpathlink.h

rpathlink/1.0.0: package(): Packaged 1 '.h' file: rpathlink.h
rpathlink/1.0.0: package(): Packaged 1 '.so' file: librpathlink.so
rpathlink/1.0.0: Created package revision 26b2d33a91d9937faaee5b5cbaa49717
rpathlink/1.0.0: Package 'ec5adadcb11acf21b8f297bf2ccd5426fb4b0578' created
rpathlink/1.0.0: Full package reference: rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf:ec5adadcb11acf21b8f297bf2ccd5426fb4b0578#26b2d33a91d9937faaee5b5cbaa49717
rpathlink/1.0.0: Package folder /home/sfackler/conan/.conan2/p/rpath38d4c26dea5c2/p
WARN: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN:     'cpp_info.names' used in: zlib/1.2.13

======== Launching test_package ========

======== Computing dependency graph ========
Graph root
    rpathlink/1.0.0 (test package): /home/sfackler/conan/rpathlink/test_package/conanfile.py
Requirements
    rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf - Cache
    zlib/1.2.13#e377bee636333ae348d51ca90874e353 - Cache

======== Computing necessary packages ========
Requirements
    rpathlink/1.0.0#583d5548b13f4e75c0d690ffb53e21cf:ec5adadcb11acf21b8f297bf2ccd5426fb4b0578#26b2d33a91d9937faaee5b5cbaa49717 - Cache
    zlib/1.2.13#e377bee636333ae348d51ca90874e353:9a7f5466b6926f6dc790c94d617e893533d5c141#820168803a1b6fa582975fc10c2a284c - Cache

======== Installing packages ========
zlib/1.2.13: Already installed! (1 of 2)
rpathlink/1.0.0: Already installed! (2 of 2)
WARN: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN:     'cpp_info.names' used in: zlib/1.2.13

======== Testing the package ========
Removing previously existing 'test_package' build folder: /home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release
rpathlink/1.0.0 (test package): Test package build: build/gcc-12-x86_64-gnu17-release
rpathlink/1.0.0 (test package): Test package build folder: /home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release
rpathlink/1.0.0 (test package): Writing generators to /home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release/generators
rpathlink/1.0.0 (test package): Generator 'CMakeDeps' calling 'generate()'
rpathlink/1.0.0 (test package): Generator 'CMakeToolchain' calling 'generate()'
rpathlink/1.0.0 (test package): CMakeToolchain generated: conan_toolchain.cmake
rpathlink/1.0.0 (test package): CMakeToolchain generated: CMakePresets.json
rpathlink/1.0.0 (test package): CMakeToolchain generated: ../../../CMakeUserPresets.json
rpathlink/1.0.0 (test package): Generating aggregated env files
rpathlink/1.0.0 (test package): Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']

======== Testing the package: Building ========
rpathlink/1.0.0 (test package): Calling build()
rpathlink/1.0.0 (test package): Running CMake.configure()
rpathlink/1.0.0 (test package): RUN: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/sfackler/conan/rpathlink/test_package" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/sfackler/conan/rpathlink/test_package/."
-- Using Conan toolchain: /home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release/generators/conan_toolchain.cmake
-- Conan toolchain: C++ Standard 17 with extensions ON
-- The C compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/sfackler/x-tools/x86_64-linux-gnu/bin/x86_64-linux-gnu-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Conan: Target declared 'rpathlink::rpathlink'
-- Conan: Target declared 'ZLIB::ZLIB'
-- Configuring done (0.7s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_POLICY_DEFAULT_CMP0091


-- Build files have been written to: /home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release

rpathlink/1.0.0 (test package): Running CMake.build()
rpathlink/1.0.0 (test package): RUN: cmake --build "/home/sfackler/conan/rpathlink/test_package/build/gcc-12-x86_64-gnu17-release" -- -j24
[ 50%] Building C object CMakeFiles/example.dir/src/example.c.o
[100%] Linking C executable example
/home/sfackler/x-tools/x86_64-linux-gnu/lib/gcc/x86_64-linux-gnu/11.2.0/../../../../x86_64-linux-gnu/bin/ld: warning: libz.so.1, needed by /home/sfackler/conan/.conan2/p/rpath38d4c26dea5c2/p/lib/librpathlink.so, not found (try using -rpath or -rpath-link)
/home/sfackler/x-tools/x86_64-linux-gnu/lib/gcc/x86_64-linux-gnu/11.2.0/../../../../x86_64-linux-gnu/bin/ld: /home/sfackler/conan/.conan2/p/rpath38d4c26dea5c2/p/lib/librpathlink.so: undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status
gmake[2]: *** [CMakeFiles/example.dir/build.make:98: example] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/example.dir/all] Error 2
gmake: *** [Makefile:91: all] Error 2

*********************************************************
Recipe 'rpathlink/1.0.0 (test package)' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter check: https://conan.io/cci-v2.html
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: rpathlink/1.0.0 (test package): Error in build() method, line 18
	cmake.build()
	ConanException: Error 2 while executing

```
</p>
</details> 
user: sfackler
issue_13885: state: open
title: [question] during source() step, untracked working tree source files should be forced to be overwritten by checkout ?
body: ### What is your question?

Hi,

I'm wondering why the `Git.fetch_commit()` doesn't force the deletion of the previous existing temporary local files (or force the ckeckout) ?
see bellow my fix for linux in `source()` function to work around my problem.

```python
  def export(self):
    git = Git(self, self.recipe_folder)
    if (git.is_dirty()):
      self.output.warning("The repository is dirty, Doesn't make sense to capture coordinates of something dirty, as it will not be reproducible.")
      self.output.warning("If there are local changes, and the user wants to test a local conan create, should commit the changes first (at least on local git).")
      return
    scm_url, scm_commit = git.get_url_and_commit()
    # we store the current url and commit in conandata.yml
    update_conandata(self, {"sources": {"commit": scm_commit, "url": scm_url}})

  def source(self):
    git = Git(self)
    if (self.conan_data is not None):
      # we recover the saved url and commit from conandata.yml and use them to get sources
      sources = self.conan_data["sources"]
      # FIX: delete the local files to fix the exception raise "the following untracked working tree files would be overwritten by checkout" ()
      # Existing local files are likely from the last export_sources(), commited files should always win ?
      self.run("rm -rf *") 
      git.fetch_commit(url=sources["url"], commit=sources["commit"])
    else:
      # we use the local sources not commited yet.
      self.output.warning("The repository is likely dirty. Local sources will be used but will not be buildable in other computer!")
  
  def export_sources(self):
    copy(self, "libraries/*",     f"{self.recipe_folder}/..", self.export_sources_folder)
    copy(self, "cmake/*",         f"{self.recipe_folder}/..", self.export_sources_folder)
    copy(self, "applications/*",  f"{self.recipe_folder}/..", self.export_sources_folder)
    copy(self, "CMakeLists.txt",  f"{self.recipe_folder}/..", self.export_sources_folder)
```

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: selim-pousse
issue_13869: state: open
title: [question] Best practice for installing many package artifacts to a common runtime location
body: ### What is your question?

Say I have packages a, b, c, d, etc., and I want to take the libs and exe's from them and have them be installed in a specified directory where I can then run/test them. Assuming all packages were built using cmake (deps, toolchain, layout, etc.), would it then be best to just have cmake handle this during the install stage? I've been wondering if deployers would be more suited to handling this?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: dataless-patch
issue_13866: state: open
title: Generate multiple `conanbuild.X` scripts from `VirtualBuildEnv` generator
body: When we run `conan install` and use the `VirtualBuildEnv` generator for local development (i.e. the goal is to build locally, not to create a new package) on windows it creates `conanbuild.bat` that can be used to setup the environment to run `cmake` (or any other tool).

The `tools.env.virtualenv:powershell` configuration option can be used to generate `conanbuild.ps1`, but there does not seem to be a way of generating `conanbuild.sh` on windows.

In my case, I'm used to developing locally with _ancient_ tools, a terminal, `vim`, `cmake` directly on the command line... which I do mostly on macos, sometimes on linux.  We have a multi-platform product, and sometimes I have to build/debug on a remote windows machine.  It would be convenient to be able to use `git-bash` on the remote windows machine rather than having to use `cmd`/`powershell`.
user: dribeas
issue_13865: state: open
title: [bug] Conan graph info fails getting packages from remote without login
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: not relevant
* Conan version: 2.0.4
* Python version: 3.11.3


### Steps to reproduce

```
cd conan-center-index
conan export recipes\h5pp\all\ --name h5pp --version 1.8.4
conan remote disable * # Make sure all other remotes are disabled
conan remote add custom-repo-that-needs-login https://
conan graph info --requires h5pp/1.8.4@#2374f72c25d498b336dc59964001b029
```
Note that the remote requires authentication but it was not provided.

The recipe used is just an example I was working with, but I believe it has nothing to do with the issue.

The expected behavior is conan requesting for auth to check the remote or at least failing with a better error message.

After doing `conan remote login custom-repo-that-needs-login ......` it worked as expected.

### Logs

```
λ conan graph info --requires h5pp/1.8.4@#2374f72c25d498b336dc59964001b029 -pr:h linux -pr:b linux

======== Computing dependency graph ========
hdf5/1.14.0: Not found in local cache, looking in remotes...
hdf5/1.14.0: Checking remote: conancenter-internal
Graph root
    cli
Requirements
    h5pp/1.8.4#2374f72c25d498b336dc59964001b029 - Cache
Graph error
    Package 'hdf5/1.14.0' not resolved: Unable to find 'hdf5/1.14.0' in remotes.

======== Basic graph information ========
conanfile:
  ref: conanfile
  id: 0
  recipe: Cli
  package_id: None
  prev: None
  build_id: None
  binary: None
  invalid_build: False
  revision_mode: hash
  package_type: unknown
  settings:
    os: Linux
    arch: x86_64
    compiler: gcc
    compiler.cppstd: 17
    compiler.version: 11
    build_type: Release
  options:
  system_requires:
  recipe_folder: None
  source_folder: None
  build_folder: None
  generators_folder: None
  package_folder: None
  cpp_info:
    root:
      includedirs: ['include']
      srcdirs: None
      libdirs: ['lib']
      resdirs: None
      bindirs: ['bin']
      builddirs: None
      frameworkdirs: None
      system_libs: None
      frameworks: None
      libs: None
      defines: None
      cflags: None
      cxxflags: None
      sharedlinkflags: None
      exelinkflags: None
      objects: None
      sysroot: None
      requires: None
      properties: None
  label: cli
  context: host
  test: False
  requires:
    1: h5pp/1.8.4#2374f72c25d498b336dc59964001b029
h5pp/1.8.4#2374f72c25d498b336dc59964001b029:
  ref: h5pp/1.8.4#2374f72c25d498b336dc59964001b029
  id: 1
  recipe: Cache
  package_id: None
  prev: None
  build_id: None
  binary: None
  invalid_build: False
  url: https://github.com/conan-io/conan-center-index
  license: MIT
  description: A C++17 wrapper for HDF5 with focus on simplicity
  topics: ('hdf5', 'binary', 'storage', 'header-only', 'cpp17')
  homepage: https://github.com/DavidAce/h5pp
  revision_mode: hash
  package_type: header-library
  settings:
    os: Linux
    arch: x86_64
    compiler: gcc
    compiler.cppstd: 17
    compiler.version: 11
    build_type: Release
  options:
  system_requires:
  recipe_folder: C:\Users\danielm\.conan2\p\h5ppb1c4e5e501d67\e
  source_folder: None
  build_folder: None
  generators_folder: None
  package_folder: None
  cpp_info:
    root:
      includedirs: ['include']
      srcdirs: None
      libdirs: ['lib']
      resdirs: None
      bindirs: ['bin']
      builddirs: None
      frameworkdirs: None
      system_libs: None
      frameworks: None
      libs: None
      defines: None
      cflags: None
      cxxflags: None
      sharedlinkflags: None
      exelinkflags: None
      objects: None
      sysroot: None
      requires: None
      properties: None
  label: h5pp/1.8.4
  context: host
  test: False
  requires:
ERROR: Package 'hdf5/1.14.0' not resolved: Unable to find 'hdf5/1.14.0' in remotes.
```
user: danimtb
issue_13858: state: open
title: [feature] Improve error message when not authenticated with remote
body: ### What is your suggestion?

Currently when the user is not authenticated with a JFrog Conan repository, the Conan client won't say so. Neither during operations like conan create / install, nor while explicitly searching for a specific package.

Instead the Conan client reports something like this:

    $ conan search -r conanserver mypkg
    There are no packages matching the 'mypkg' pattern

This is technically correct in a way. But it also annoyingly insufficient, especially to new users. They expect to be notified when they need to log in, especially since the JFrog Artifactory Conan server seems to reset the authentication token quite often.

A simple warning would already be sufficient, something like:

    $ conan search -r conanserver mypkg
    Warning: skipping remote "conanserver" due to authentication failure
    There are no packages matching the 'mypkg' pattern

This would really improve usability and would prevent users from wondering what's going on. Especially since the output of commands like conan create can be very verbose and confusing, it is often not clear what's actually happening.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: stevn
issue_13852: state: open
title: [question] How to use `conan graph build-order` in CI?
body: ### What is your question?

What is the intended use case for `conan graph build-order` in conan 2.0? I have experimented with `conan graph build-order` in order to convert (and possibly expand) our CI workflow, but it seems that I'm missing several features from conan 1.X (either because I'm not looking at it the right way, or because they have been left out).

What I found works well:
* Generating and merging build orders for multiple roots recipes, using the same profiles.

What I have problems with:
* Actually converting the output into concrete calls to build individual packages. I cannot seem to find a way to build a package using a recipe reference, only via `conanfile.py` (unless using `--build missing` on a downstream package I currently have a `conanfile.py` for).
* Merging build orders using multiple sets of profiles (e.g. release and debug), when there are some packages only provided for either of them.
* Translating recipe references from lockfiles/build orders to their corresponding conanfiles (as there doesn't seem to be an inbuilt way to build packages by recipe reference anymore).

---

Let's take the example from the [lockfiles documentation page](https://docs.conan.io/2.0/tutorial/versioning/lockfiles.html#tutorial-versioning-lockfiles). To make the scenario easier, let's assume I have only exported all recipes, but no packages have been created (yet). I can create lockfiles for `engine/1.0` using profiles for x86 and x64 architectures and release and debug buildtypes. I can also merge those into one single lockfile, if needed.
But it gets hairy once I try to establish which packages have to be built in what order using which profile:
* Using the combined lockfile forces me to keep track of which recipe needs to be built with which profile separately. It also causes unnecessary rebuilds if some combinations of recipe and profile have already been built, if others are missing. (Or I have to check each possible combination using `conan search`...) Example: recipe `sound32/1.0` has already been built for profile x86-release, but a package for x86-debug is missing.
* Using separate lockfiles, gathering build-orders for each individually, then merge them using `conan graph build-order-merge`: results in similar problems as above
* Using separate lockfiles, calculating all build-orders up front, then schedule all package builds according to build order and profile. This results in potentially rebuilding packages that are covered by multiple lockfiles (e.g. header only libraries, tool_requires, ...).
* Using separate lockfile, processing the sequentially (calculate build-order, then build those packages before continuing to the next lockfile). This way dependencies can only be (re-)evaluated after every lockfile, loosing opportunities to parallelize builds.

---

And all this is under the assumptions, that
1. I already have all of the recipes present locally
2. those recipe revisions actually match those calculated by lockfile/build order
3. I can map recipe revision from lockfile/build order to a local conanfile

Things fall apart once any of those assumptions no longer holds, which I think is likely in most CI scenarios, at least those involving more than one build server.

---

I feel like `conan graph build-order` in its current form is mostly overshadowed by `conan create --build missing --lockfile mylock.lock`, as that handles most of the problems, at the cost that package builds can no longer be distributed.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: PengolodhGoedath
issue_13842: state: open
title: [bug] exceeds the OS max path limit on windows
body: ### Environment details

* Operating System+version: exceeds the OS max path limit
* Compiler+version: VS2019
* Conan version: 2.0.4
* Python version:  n/a


### Steps to reproduce

1. grpc 1.50.1 build on windows using vs2019
2. conanfile.py
```
def requirements(self):   
        self.requires("grpc/1.50.1")
```
3. profile
```
[settings]
arch=x86_64
build_type=Release
compiler=msvc 
compiler.version=192
compiler.runtime=dynamic
os=Windows
[options]
[conf]
*:tools.build:cxxflags=["/MP"]
```
4. conan install
```
conan install . -r conancenter -pr ./vpsdev_x86_64_windows -pr:b ./vpsdev_x86_64_windows -s build_type=Release -b missing -of ./Release -vvv
```

my root path name length seems not to be long. however, it seems that conan cache folder causes long file name and path.

### Logs

```
Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(382,5): error MSB3491: Could not write
 lines to file “cloud_kubernetes_security_containersecurity_logging_containersecurity_logging.dir\Release\cloud_ku.F6248728.tlog\cloud_kubernetes_security_c
ontainersecurity_logging_containersecurity_logging.lastbuildstate”. Path: cloud_kubernetes_security_containersecurity_logging_containersecurity_logging.dir\
Release\cloud_ku.F6248728.tlog\cloud_kubernetes_security_containersecurity_logging_containersecurity_logging.lastbuildstate exceeds the OS max path limit. T
he fully qualified file name must be less than 260 characters. [C:\Users\kismetro\.conan2\p\t\googlbaf5bd4a0314f\b\build\cloud_kubernetes_security_container
security_logging_containersecurity_logging.vcxproj]
```


user: kismetro
issue_13840: state: open
title: [feature] Populate download_cache on upload
body: ### What is your suggestion?

While `core.download:download_cache` is a great way to speed up the download step in CI workflows, it unfortunately only serves to speed up the download of common dependencies.

In more complex chains where you have several (dependent) jobs on a common CI infrastructure, it's likely that the package a previous job has just created and uploaded to a remote, will also be directly consumed by a dependent job. In this case, any freshly created artifact will always go the full round-trip of upload *and* download, even with a cache configured.

Ideally, the compressed package would be forked straight into the `download_cache` (when configured), so that a following download of the new package is reduced to a noop.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Ext3h
issue_13829: state: open
title: [feature] Expose cmake_layout:build_folder as a setting
body: ### What is your suggestion?

Currently, when using `cmake_layout`, the build folder is defined by using a combination of several variables. First, there is a `build_folder` variable, which just sets a path. There is also the `build_folder_vars` variable, which take into account several variables specified as a setting. Depending on the build generator (Ninjca, Makefile...), is also takes into account the build type or not in the final build folder.

By combining those two methods, you can set the build folder to be `<root>/<cmake_layout:build_folder>/<path sepcified by variables>/<build_type>`, obtaining `<root>/build/desktop/linux-x86_64-gcc-10/Release` for example.

However, this is not enough, as different builds my set the build_folder, for example, doing `-s *:build_type=Debug -s &:build_type=Debug` or `-s *:build_type=Release -s &:build_type=Debug` may define the same build_folder name. Also, if I have several options and I want different `conan install` commands with different options, if is very difficult to track the name of the folder.

I think adding the option to directly set the build folder would simplify this, as we could match a name which makes semantic sense, to a specific build folder, with specific options. For example, I might make sense to define a folder `build/benchmarking` instead of a folder `build/linux-x86_64-clang-16-use_timers_True_is_benchmarking_True/Release`

The issue is that the `cmake_layout:build_folder` is not exposed as a setting, so in order to modify it, you need to directly tweak the conanfile. To do so I added a hack into my conanfile:

```
    def layout(self):
        if "CONAN_CMAKE_LAYOUT_BUILDDIR" in os.environ:
            cmake_layout(
                self, build_folder="build/{}".format(os.environ["CONAN_CMAKE_LAYOUT_BUILDDIR"]))
        else:
            cmake_layout(self)
```

With this hack, by setting the appropiate envvar, I can set the build folder to be whatever I want.

Would it be possible to expose a setting `tools.cmake.cmake_layout:build_folder` to set the cmake.build_folder property directly, without hacks?

Finally, when combining CMakeToolchain with cmake_layout, the name of the cmake preset is defined in the same way as the name of the build folder, so even with my hack, the name of the cmake doesn't match the build folder and again, makes it difficult to track what the preset is, or may have collisions with other preset names. As an example:

```
"configurePresets": [
        {
            "name": "linux-x86_64-gcc-10-debug",
            "displayName": "'linux-x86_64-gcc-10-debug' config",
            "description": "'linux-x86_64-gcc-10-debug' configure using 'Ninja' generator",
            "generator": "Ninja",
            "cacheVariables": {
                "CMAKE_BUILD_TYPE": "Debug"
            },
            "toolchainFile": "/workspace/build/asdf/linux-x86_64-gcc-10/Debug/generators/conan_toolchain.cmake",
            "binaryDir": "/workspace/build/asdf/linux-x86_64-gcc-10/Debug"
        }
    ],
```

Note that the toolchainfFile and the binaryDir point to `build/asdf` thanks to my hack, but the name of the preset doesn't have the `asdf` string. 

I link a discussion in slack about this
https://cpplang.slack.com/archives/C41CWV9HA/p1683276562027779

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jjcasmar
issue_13828: state: open
title: [bug] Options for transitive dependencies of "compatible" packages are not locked correctly if package is already locked
body: ### Environment details

* Operating System+version: Linux / Windows
* Compiler+version: N/A
* Conan version: 1.59
* Python version: 3.17

### Steps to reproduce

I have created a small repository to describe the issue.
Repository : https://github.com/pbouamriou/conan-issue-transitive-dependencies-of-compatible-package-locked

__An extract__ :

_Use case_ :
base has an option (shared = [ True, False]). 
compatible has a package compatibility for os (windows == linux). 
compatible depends on base. consumer depends on compatible.

Create a lock for consumer is OK. 
Re-create a lock for consumer using the previous lock as lock is NOK (transitive options are lost).

git clone https://github.com/pbouamriou/conan-issue-transitive-dependencies-of-compatible-package-locked.git
cd conan-issue-transitive-dependencies-of-compatible-package-locked
./script.sh

Patch is available here : https://github.com/pbouamriou/conan-issue-transitive-dependencies-of-compatible-package-locked/blob/main/0001-Correct-transitive-dependencies-options-lost-on-comp.patch.

Patch is based on this [patch](https://github.com/conan-io/conan/pull/9890). 


### Logs

```console
$ ./script.sh 
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'url'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'license'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'description'. It is recommended to add it as attribute
Exporting package recipe
base/1.1: The stored package has not changed
base/1.1: Using the exported files summary hash as the recipe revision: bca0440605471cb6943d8ab3227ec68e 
base/1.1: Exported revision: bca0440605471cb6943d8ab3227ec68e
Configuration:
[settings]
[options]
[build_requires]
[env]

base/1.1: Forced build from source
Installing package: base/1.1
Requirements
    base/1.1 from local cache - Cache
Packages
    base/1.1:2a623e3082a38f90cd2c3d12081161412de331b0 - Build

Installing (downloading, building) binaries...
base/1.1: Copying sources to build folder
base/1.1: Building your package in C:\Users\PhilippeBouamriou\.conan\data\base\1.1\_\_\build\2a623e3082a38f90cd2c3d12081161412de331b0
base/1.1: Generator txt created conanbuildinfo.txt
base/1.1: Aggregating env generators
base/1.1: Calling build()
base/1.1: WARN: This conanfile has no build step
base/1.1: Package '2a623e3082a38f90cd2c3d12081161412de331b0' built
base/1.1: Build folder C:\Users\PhilippeBouamriou\.conan\data\base\1.1\_\_\build\2a623e3082a38f90cd2c3d12081161412de331b0
base/1.1: Generated conaninfo.txt
base/1.1: Generated conanbuildinfo.txt
base/1.1: Generating the package
base/1.1: Package folder C:\Users\PhilippeBouamriou\.conan\data\base\1.1\_\_\package\2a623e3082a38f90cd2c3d12081161412de331b0
base/1.1: Calling package()
base/1.1: WARN: This conanfile has no package step
base/1.1 package(): WARN: No files in this package!
base/1.1: Package '2a623e3082a38f90cd2c3d12081161412de331b0' created
base/1.1: Created package revision 183a243e928743312cf7183347ecf13b
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'url'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'license'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'description'. It is recommended to add it as attribute
Exporting package recipe
compatible/1.1: The stored package has not changed
compatible/1.1: Using the exported files summary hash as the recipe revision: b55ef524ea4f6387ce11c3e6427f72f6 
compatible/1.1: Exported revision: b55ef524ea4f6387ce11c3e6427f72f6
Configuration:
[settings]
os=Linux
[options]
[build_requires]
[env]

compatible/1.1: Forced build from source
Version ranges solved
    Version range '>= 1.0 < 2.0' required by 'compatible/1.1' resolved to 'base/1.1' in local cache

Installing package: compatible/1.1
Requirements
    base/1.1 from local cache - Cache
    compatible/1.1 from local cache - Cache
Packages
    base/1.1:2a623e3082a38f90cd2c3d12081161412de331b0 - Cache
    compatible/1.1:162960fede95da44f5fe4cae8ea55c7eb0a84cb8 - Build

Cross-build from 'Windows:x86_64' to 'Linux:None'
Installing (downloading, building) binaries...
base/1.1: Already installed!
compatible/1.1: Copying sources to build folder
compatible/1.1: Building your package in C:\Users\PhilippeBouamriou\.conan\data\compatible\1.1\_\_\build\162960fede95da44f5fe4cae8ea55c7eb0a84cb8
compatible/1.1: Generator txt created conanbuildinfo.txt
compatible/1.1: Aggregating env generators
compatible/1.1: Calling build()
compatible/1.1: WARN: This conanfile has no build step
compatible/1.1: Package '162960fede95da44f5fe4cae8ea55c7eb0a84cb8' built
compatible/1.1: Build folder C:\Users\PhilippeBouamriou\.conan\data\compatible\1.1\_\_\build\162960fede95da44f5fe4cae8ea55c7eb0a84cb8
compatible/1.1: Generated conaninfo.txt
compatible/1.1: Generated conanbuildinfo.txt
compatible/1.1: Generating the package
compatible/1.1: Package folder C:\Users\PhilippeBouamriou\.conan\data\compatible\1.1\_\_\package\162960fede95da44f5fe4cae8ea55c7eb0a84cb8
compatible/1.1: Calling package()
compatible/1.1: WARN: This conanfile has no package step
compatible/1.1 package(): WARN: No files in this package!
compatible/1.1: Package '162960fede95da44f5fe4cae8ea55c7eb0a84cb8' created
compatible/1.1: Created package revision 252e77a2ad2037b3900f9e085671f835
compatible/1.1: Main binary package '4f1f2b3e6f672ad9e30e1fb5ba3715e84948f3ba' missing. Using compatible package '162960fede95da44f5fe4cae8ea55c7eb0a84cb8'
Version ranges solved
    Version range '>= 1.0 < 2.0' required by 'conanfile.py' resolved to 'compatible/1.1' in local cache
    Version range '>= 1.0 < 2.0' required by 'compatible/1.1' resolved to 'base/1.1' in local cache

Requirements
    base/1.1 from local cache - Cache
    compatible/1.1 from local cache - Cache
Packages
    base/1.1:2a623e3082a38f90cd2c3d12081161412de331b0 - Cache
    compatible/1.1:162960fede95da44f5fe4cae8ea55c7eb0a84cb8 - Cache

Generated lockfile: C:\Users\PhilippeBouamriou\OPAL-RT\temp\test_compatibility\deps.lock
Requirements
    base/1.1 from local cache - Cache
    compatible/1.1 from local cache - Cache
Packages
    base/1.1:2a623e3082a38f90cd2c3d12081161412de331b0 - Cache
    compatible/1.1:162960fede95da44f5fe4cae8ea55c7eb0a84cb8 - Cache

Generated lockfile: C:\Users\PhilippeBouamriou\OPAL-RT\temp\test_compatibility\deps-out.lock
Using lockfile: 'C:\Users\PhilippeBouamriou\OPAL-RT\temp\test_compatibility\deps-out.lock'
Configuration:
[settings]
os=Windows
[options]
[build_requires]
[env]

ERROR: compatible/1.1: Locked options do not match computed options
Locked options:
shared=False
Computed options:
shared=False
base:shared=True
```
user: pbouamriou
issue_13823: state: open
title: Can anyone help me on tracking this Issue down?
body: ### What is your question?

I am trying to fix this [[package] qt/5.15.8: can't be build on debian buster with qtwebengine](https://github.com/conan-io/conan-center-index/issues/17273) . We really need this package, otherwise we have to go a different way with our qt version. 

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: schmidjo82
issue_13820: state: open
title: [feature] Improve processing time of compatible packages
body: ### What is your suggestion?

While testing out the new compatibility.py functionality in conan 2, I've found that the processing of compatible configurations is very slow. With my company's setting customization and notions of compatibility, we have something like ~1k compatible packages (cartesian products get large quickly), which ends up with minutes of processing time for a single package (should the binary be missing).

This seems to be mostly an issue of using many small queries to the server -- replacing a nearby conan repository with one across a major ocean has a dramatic impact. My guess is that the solution is to do a large batch request to the server, and then process the response locally.

Until this is resolved, we are resorting to hard-coding settings in profiles, like we did with conan v1.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: ohanar
issue_13804: state: open
title: [ Conan2 Library Types] Allow explicit library types in libs definition
body: ### What is your suggestion?

Hey,

some libraries have some way of defining libraries, that can not modeled by the current scripts generated by CMake Deps. Looking at the recipe of Qt, the names of the plugins do not even show up in the generated CMake files. 

Also some libraries contain static or shared libraries, independent of the recipe configuration. 

CMake allows the 4 library types: 
- Configuration (Static or Shared, depending on CMake BUILD_SHARED_LIBS), 
- Static (Always)
- Shared (Always), 
- Module (only runtime library, see Qt Plugin)

However in a recipe, we can not model this behaviour, currently only the first one (Configuration) can be specified. If a 
CMake file defines the library as always SHARED (by doing add_library(Lib SHARED)), the corresponding DLL files can not be found, if the conan package is not build as a shared module. On the same hand, if a conan package is build as shared and a library was defined as always static, it reports, that the DLL could not be found. Modules, that only have a DLL file on windows can not be found at all by the current generator.

Additionally, currently it is assumed, that the name of the DLL file always matches the .lib file in windows. However, for some projects this does not match. For example zlib generates the lib file zdll.lib, however the DLL is named zlib1.dll. In this case the recipe could be adjusted, but it might be that DLL and lib file have different names, which can not be modeled.

I would propose this to address this issue:
- Add the 4 library types to the cpp_info.libs

For example:

cpp_info.libs = [
  **"static_or_shared",**     <- As defined now. The generator will assume shared for shared and static for static libraries
  **SharedLib("zdll", "zlib1"),**  <- Explicitly define a shared library, optionally with a name of the DLL file on windows
  **StaticLib("libstatic"),**          <- Explicitly define a static library. The library is always static independent of configuration
  **PluginLib("qsqlpsql", "sqldrivers")** <- Define a module/plugin library. Only expect a DLL or .so file. Provide a sync path, that is relative to the plugin directory. The generator could search only the DLL and provide a target parameter to be able to provide a desired location for syncing
] 

So the libs could take in 4 types: str, SharedLib, StaticLib and PluginLib

This way the qt recipe could define the plugin locations better. Including a location where they should be put in an installer. The zlib recipe could define their shared library configuration on windows.

What do you think about this idea? Is there already a better way and the recipes are not up-to-date? Or is that something you would support?

If this proposal is accepted, I would be happy to implement that.



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Untzelmann
issue_13802: state: open
title: [question] MBBuilddep doesn`t create suitable property file mixed shared and static library
body: ### What is your question?

Hi,

I have tried to generate 3rd party libraries for my project shared with co-workers using conan v2 used gcc, msvs.
Here is short conan requirements:
```
def requirements(self):        
        self.requires("zlib/1.2.13")
        self.requires("eigen/3.3.9", force=True)   
        self.requires("boost/1.81.0", force=True)
        self.requires("openssl/1.1.1t", force=True)
        self.requires("protobuf/3.21.9", force=True)        
        self.requires("cpprestsdk/2.10.18")
        self.requires("grpc/1.50.1")
        self.requires("libcurl/7.87.0")
        self.requires("libpng/1.6.39", override=True)   
        self.requires("libjpeg-turbo/2.1.5", override=True)
        self.requires("opencv/4.5.5")
        self.requires("libwebp/1.3.0", override=True)
```

I checked gcc worked fine. But MSBuildDeps caused strange errors.
For example, OpenCV was built as dynamic library(.dll) with static library dependencies - libpng, libtiff, libwebp and others(shared=false).
In case of this, my understanding is that my .sln project needs just opencv.prop. It means opencv doesn't need libpng, libtiff and libwebp prop to build opencv based applications. 

However, after execute "conan install .", conandeps.prop indicates opencv.prop and opencv.prop indicates libpng, libtiff.. and other dependencies that is not generated. So, when I import conandeps.prop in my project, property files can not be found.

Also, I built all requires as static, then it works well.

Do you have any comments to resolve this?

Thank you!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: kismetro
issue_13800: state: open
title: [question] Build missing binary package and store it to own repository
body: ### What is your question?

We have a project using qt from conan center index, but with a specific qt configuration, whose binaries are not on conan center.

To avoid rebuilding qt all the time, I'd like to build the qt binaries once (e.g. via --build=missing) and upload the binaries to our gitlab conan repository, which I added before.

This is what I did:
 - Added gitlab as a new remote "gitlab"
 - `conan create mypkg --build=missing` which will build qt 5.15.2 under the hash  XYZ
 - Upload the qt binaries via `conan upload qt/5.15.2@:XYZ -r gitlab` (it uploads qt, so far so good)
 - Clear the local cache via `conan remove "*" -f`

Now to the problem/ question:
When I try to reuse the uploaded package `conan create mypkg`, it will not find the prebuilt qt package on the gitlab remove. 

Output from conan search:

```
> conan search qt -r gitlab
Existing package recipes:

qt/5.15.2
```

```
> conan search qt/5.15.2 -r gitlab
There are no packages matching the 'qt/5.15.2' pattern
```

```
> conan search qt/5.15.2@ -r gitlab
ERROR: {"error":"404 Not Found"}. [Remote: gitlab]
```

What am I doing wrong here? 

Screenshot from gitlab's conan package registry (proof that qt was uploaded)

![image](https://user-images.githubusercontent.com/3213107/235745560-a60686b3-a4e6-4eea-8e2b-90930a54ac2c.png)


### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: rainman110
issue_13789: state: open
title: [feature] Allow user and channel fields to override in lockfiles
body: ### What is your suggestion?

Hey Team,

I figured I'd turn some of the additional conversation in #13742 into a feature request given that's closed for tracking.

## The request

It would be good to be able to specify a package with a user and channel to override a package of the same name but of a different user and channel. For example, in the following lockfile:

```
{
    "version": "0.5",
    "requires": [
        "boost/1.81.0@sam/testing",
        "boost/1.81.0#8dcd9d9df9e0d320714b83cceddbe120%1676029990.142"
    ],
    "build_requires": [],
    "python_requires": []
}
```
`boost/1.81.0@sam/testing` would replace `boost/1.81.0` in the dependency graph.

Presently, `boost/1.81.0@sam/testing` would not be recognized as an identity for `boost/1.81.0` and `boost/1.81.0` would be populated on any command consuming this lockfile where the conanfile contains `self.requires("boost/1.81.0")`.

It's true that this could be replaced within the conanfile as follows:

```diff
- self.requires("boost/1.81.0")
+ self.requires("boost/1.81.0@sam/testing", override=True)
```
and this _would_ be effective at overriding the instances of `boost/1.81` in the dependency graph. However, I consider this a separate feature - this request is for this interface to be available in a lockfile such that the conanfile doesn't need to be modified.

## Motivation

There are a number of use cases that would be satisfied by this feature. I'll enumerate each.

### Representation of package maturity

For some projects, using the channel feature to represent package maturity is desirable. I contend that the versioning strategy a project adopts shouldn't be mandated by what conan supports. This means a package may wish to adopt a date based version (or any other scheme):

* `pkg/2023.01.01@org/stable`
* `pkg/2023.02.05@org/experimental`

In this case, it's convenient to have the maturity of the package reflected in the channel and reflective of the dates on which versions are stable and ready for use.

Pre-empting some criticism of this, I realise that package promotion for a scheme like this is likely unsupportable due to the guarantees the conan team have stated a desire to provide, namely package immutability, which would be voided if a no-build package promotion facility was provided (i.e. `conan copy`, which was deprecated and removed in conan 2.0).

I think it is acceptable to stipulate that if an author decided to adopt the above scheme, they would do so acknowledging that promotion of a package from the `experimental` channel to the `stable` channel would require a rebuild.

From #13742, the proposal to address the issues associated with representing package maturity in the channel is to include the package maturity in the version, i.e. `pkg/1.2.0-dev`. This works well with versioning schemes such as [semver](https://semver.org/) and [calver](https://calver.org/), however is not a one-size-fits all approach. My suggestion here is that forcing maturity to be represented in the version is an opinionated approach, and will not necessarily be robust to the complex requirements and differing needs of different projects.

### Modification of recipes within an existing ecosystem of packages

For some reason, the `hdf5` recipe on conan center does not satisfy my requirements, and the modification that I want to make to the conan center recipe is not suitable to be propagated back, either for suitability or commercial considerations. I develop `hdf/1.14.0@org` to identify the recipe as presenting the same package interface as `hdf/1.14.0` but has different origins.

Now, I want to replace `hdf5/1.14.0` with `hdf5/1.14.0@org` in the dependency tree. It would be useful to be able to just modify a lockfile:

```
{
    "version": "0.5",
    "requires": [
        "hdf5/1.14.0@org",
        "hdf5/1.14.0#8dcd9d9df9e0d320714b83cceddbe120%1676029990.142",
        "armadillo/11.4.3"
    ],
    "build_requires": [],
    "python_requires": []
}
```

In this case, it's not possible to apply the suggestion above to append `-dev` or something similar, i.e. `hdf5/1.14.0-dev`, to the profile, as the valid versions are explicitly defined within `conandata.yml` (in the case of cci).

So, I'm happy with `hdf/1.14.0@org`, and so i add it to most of the packages under my control where necessary, and set it to `override` to override the upstream instances in conan center variants. A new version is released and now I want to see if `hdf5/1.15.0` has addressed my need to fork. So now it would be really useful to override `hdf/1.14.0@org` with `hdf/1.15.0`, but at the moment I can't because these aren't identified as substitutable pacakges from a lockfile perspective, without modifying a large number of recipes in which I've stated my dependency on `hdf/1.14.0@org`.

### Experimentation and testing of packages locally

I often want to test packages independently of a formal development cycle because i'm experimenting with a change or I'm reproducing a bug from someone elses branch, or something along those lines. This might mean pulling down a pull request from cci and building it. In this case, i would normally export the recipe to, say, `hdf/1.14.0@sam/testing` for example. I do this for a few reasons:

1. It's not possible to override the version attribute for out of source recipes when made available similarly to the way conan center do because of the presence of a conandata.yml that explicitly enumerates the valid versions. In fact, because I'm mostly modifying the recipe itself here, it also wouldn't be appropriate to modify the version because this reflects the underlying library version not the recipe revision.
2. I don't want any changes I make to conflict with any "production" sourced recipes, i.e. from conan center or from my organisation. I want to be confident that those recipes are from the source of truth, so I don't want to override `hdf5/1.14.0` in this case. Equally for an organisation, I wouldn't want to override `pkg/2023.05.20@org/stable` or `pkg/2023.05.20@org/experimental` because these are likely to be automatically built artefacts, and I want to be sure that if I'm using those user/channels, then I'm getting what I expect.
3. For local recipes, lets say I modify the version to be `pkg/1.2.3-test`, where I also have `pkg/1.2.0` and `pkg/1.2.3-dev`. In this case, `pkg/1.2.3-test` takes precedence over `pkg/1.2.3-dev` and `pkg/1.2.0` because it is recognised as the _newest version in the cache_, as it should. This also means that it will be the first to be resolved. If I keep the `-test` packages in my cache without deleting them, this would lead to the case where running a `conan create` would resolve to all of the `-test` packages i have in my cache, rather than the stable variants. I can solve this of course, I just need to specify the version of everything that I want in the lock file. This reverses the burden of effort to what's desirable. This means enumerating every "stable" version in the lockfile manually, rather than just specifying one exception to override.

I can get around this again by renaming `-test` to `-alpha.1` or something that would evaluate as less than `-dev` lexicographically. This is no longer semantically meaningful and so probably not a real solution. This also kind of just shifts the problem to making all of the `-dev` packages get resolved. Of course, this can be turned off by setting `core.version_ranges:resolve_prereleases=False`, but often what I want to test here is _one_ or _two_ packages in the entire dependency tree in a different stage of maturity, not all of them, and unfortunately this conf variable can't currently be set on a per-package basis, or easily, because it can only be modified in `global.conf`.

## Summary

I think there's a lot of value in this to enable flexible workflows, especially from a testing and experimentation perspective. I think there's probably more work that could be done in addition to this to make lockfiles even more useful (such as cli command to override with a lower version, for example), but this would be the first step in enabling more flexible workflows.

I'm sure I haven't communicated something clearly here, so please ask any questions to help clarify if necessary.

Relates to #13742, #9097

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: samuel-emrys
issue_13786: state: open
title: def source(), instead of cloning use the local files
body: In source method what we usually do, 


```
def source(self):
        self.run(f"git clone {self.conan_data['git']['url']} .")
        self.run(f"git checkout {self.conan_data['git']['commitId']}")
```

But instead of cloning, I want to make changes to my source code and try conan build with that source code. When I am satisfied with my source code then I will upload it to git. But till then I want to use the local source code instead git clone in source method.
Is it possible to use local repo and copy to self.source_folder?
user: sid-gif
issue_13783: state: open
title: [question] [Conan 2.0.4]
body: ### What is your question?

**Context:**
I want to package my-helper.cmake scripts in a conan package, and make them available to other packages in the CMAKE_MODULE_PATH. 

**Solution:**
I did it by using `self.cpp_info.builddirs = ["cmake"]`, here is the link to documentation
[package my-helper.cmake scripts in a conan package, and make them available to other packages in the CMAKE_MODULE_PATH]

**Problem:**
In the documentation, https://docs.conan.io/1/migrating_to_2.0/recipes.html?highlight=builddirs#removed-self-cpp-info-builddirs they say this 
"The default value (pointing to the package root folder) from self.cpp_info.builddirs has been removed. Also assigning it will be discouraged because it affects how [CMakeToolchain] and [CMakeDeps] locate executables, libraries, headers… from the right context (host vs build)." However, in the following text they say this
"If you have cmake modules or cmake config files at the root of the package, it is strongly recommended to move them to a subfolder cmake and assign it: self.cpp_info.builddirs = ["cmake"]" which is what we did. 

**Question:
so we wanted to know whether, `self.cpp_info.builddirs = ["cmake"]` this is a valid solution or not? 
Or we should not use it? If we should not use this, then what is the alternative ?**


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Anokhi1994
labels: docs: Issues related with improvements in the documentation
issue_13777: state: open
title: [feature] Add cstd to compiler settings
body: **Background**
We encountered an issue with the GCC toolchain (at least GCC 9) pulling in BSD and SVr4 extensions if no C/C++ dialect via compiler flag _-std=_ has been explicitly defined. This is unwanted on many embedded targets.

We found out that in contrast to the legacy [Conan CMake build helper](https://docs.conan.io/en/1.59/reference/build_helpers/cmake.html) the new [generate()](https://docs.conan.io/en/1.59/migrating_to_2.0/recipes.html#the-generate-method) automatically translates the infomation in setting _compiler.cppstd_ to a toolchain specific flag and appends it to the compiler call. This works pretty well for C++ files, but as many of our packages contain C files or are written exclusively in C, there is no similar feature for C in Conan. Using the same flag as for C++ is no option as this will create warnings for C files.

**Proposal**
- Add _cstd_ to settings _compiler_ similar to _cppstd_.
- Translate the information in _compiler.cstd_ to a compiler specific flag (e.g. for GCC _compiler.cstd=11_ translates to _-std=c11_).
- If using the [generate()](https://docs.conan.io/en/1.59/migrating_to_2.0/recipes.html#the-generate-method) approach add this compile flag to the compiler call.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: PhilippFinke1988
issue_13774: state: open
title: [question] [Cmake] No include directories added when trying to compile project with clang with packages build using gcc
body: ### What is your question?

Hi. We have a CMake project which I am trying to migrate to clang (v16) from gcc (v12.2). The project depends on some other internal conan packages which are built using gcc. The way we plan to go about doing it is create a new profile as follows:

1. Create a new profile for clang
```
[settings]
compiler=clang
compiler.version=16
compiler.libcxx=libstdc++11

[env]
CXX=/usr/bin/clang++
CC=/usr/bin/clang
```

2. Run conan install on project using new profile but pulling gcc packages for dependencies
```
conan install --profile=clang -s '*:compiler=gcc' -s'*:compiler.version=12.2' -s'*:compiler.libcxx=libstdc++11'
```

This works but when trying to run CMake, the generate compile command does not have the include directives for the dependencies. Is there something we are missing here?


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: bhavinkamdargsr
issue_13769: state: open
title: [question] Is there a way to specify component-level dependencies with "conan install --requires"
body: ### What is your question?

We are using "conan install --requires" to deploy conan packages as part of a larger build system. In doing so, we have encountered a challenge with packages like openssl that define multiple components. More specifically, we want to install the ssl component but not the crypto component. Conceptually, it seems like the following should work, but it results in an error:

> conan-2.0 install --requires=openssl::ssl/1.1.1s@ --deployer=custom_deployer --generator=custom_generator

> ERROR: Package 'openssl::ssl/1.1.1s' not resolved: Unable to find 'openssl::ssl/1.1.1s' in remotes.

Is there a way to specify package components at the command line?  Thanks

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: System-Arch
issue_13767: state: open
title: [bug] Uploading package with user and channel generates an error
body: ### Environment details

I have a local package:
~~~~
> conan list "general/0.3.56@company/stable"
Local Cache
  general
    general/0.3.56@company/stable
~~~~

Trying to upload this to `conan_server-2.0.4` running on linux results in following error: 
~~~~
> conan upload "general/0.3.56@company/stable" -r server2
ERROR: invalid literal for int() with base 10: '2023-04-25T11:26:37Z'. [Remote: server2]`
~~~~
I see the following at the server side:
~~~~
192.168.5.98 - - [25/Apr/2023 15:32:37] "GET /v2/conans/general/0.3.56/company/stable/revisions HTTP/1.1" 500 62
~~~~
Uploading to a `conan_server-1.59.0` does work.
Creating the package without `user` and `channel`, the upload to both works.

### Steps to reproduce

_No response_

### Logs

_No response_
user: jputcu
issue_13760: state: open
title: [question] How to correctly resolve version conflicts?
body: ### What is your question?

Hi! For an open source project I am using, I am currently working on a PR to allow them to move forward from conan1.x to conan2, which they use to consume dependencies.

In the process, a massive amount of version conflicts (including boost, openssl, and other packages) occured. I guess the default behavior of conan has changed?

I am (partly) able to resolve most of them using `force` or `overwrite`. However, looking into [the tutorial](https://docs.conan.io/2/tutorial/versioning/conflicts.html), it says:

> Resolving version conflicts by overrides/forces should in general be the exception and avoided when possible, applied as a temporary workaround. The real solution is to move forward the dependencies requires so they naturally converge to the same versions of upstream dependencies.

Unfortunately, I am unable to find any additional documentation/examples/references on how I should do that. What does "move forward the dependency requires" mean? Could you point me to documentation/references for best-practices on how to proceed? 🙂  

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Jean1995
issue_13753: state: open
title: static method CMake.get_version() seams to be missing
body: ### Environment details

* Operating System+version: Fedora release 38
* Compiler+version: gcc (GCC) 13.0.1 20230401 (Red Hat 13.0.1-0)
* Conan version: 1.59.0
* Python version: 3.11.2


### Steps to reproduce

1. Adding CMake.get_version() to any stage of a conan python recipe fails with AttributeError: 'CMake' object has no attribute 'get_version'

This static method is documented here https://docs.conan.io/en/1.59/reference/build_helpers/cmake.html?highlight=get_version#get-version
It is also mentioned here #5292

### Logs

```
cmake.get_version()
	AttributeError: 'CMake' object has no attribute 'get_version'

```
user: ashley-b
issue_13751: state: open
title: [feature] Provide ability to disable generation of aggregated env files
body: ### What is your suggestion?

We are using the Conan 2 install command with the --generator and --deployer options to integrate Conan-created/managed packages into an existing build system. More specifically, we use multiple instance of the install command to install packages as they are needed during the execution of a large component-based build where each component has distinct Conan package dependencies.

We specify the --output-folder to be the top of our build tree and augment that path in the generator and deployer functions to avoid collisions / race conditions. The issue that we are encountering is that these multiple "conan install" invocations all try to write aggregated env files into this top-level directory.

It appears that the most common reason that aggregated env files are being written at all is that we use shared libraries and these env files are trying to set or unset LD_LIBRARY_PATH pointing to locations in the Conan cache. Since we are using our custom deployer to copy these shared libs into the appropriate locations within our build tree (where our build system knows how to find them),  the aggregated env files become completely unnecessary. Thus it would be nice if there was a way to suppress their generation, perhaps with something like:

> conan install --requires <some_package> --deployer my_deployer --generator my_generator --no_aggregate_envs

Alternatively, if there is already a way to do this, that would be great too. Thanks

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: System-Arch
issue_13730: state: open
title: [bug] conan info requirements user/channel substitution
body: ### Environment details

* Operating System+version: Windows 10
* Compiler+version: -
* Conan version: 1.59.0
* Python version: 3.8.10


### Steps to reproduce

1. recipe with: 
```
    def requirements(self):
        self.requires("pkg/0.1@%s/%s" % (self.user, self.channel))
```
2. `conan info .` --> will not work: `ERROR: Specify the 'user' and the 'channel' or neither of them`
3. there is no way to add `user/channel` to `conan info`
4. so we use the environment variables `-e CONAN_USERNAME=user` and `-e CONAN_CHANNEL=channel`
5. this variables will not resolved for `self.requires()` in `def requirements(self):`

### Logs

_No response_
user: mahaase
issue_13723: state: open
title: [question] Do traits of a recipe affect files generated by CMakeDeps for transitive recipes?
body: ### What is your question?

After some experimentations of tricky recipes in conan-center, I have the feeling that dowtream traits affect files generated by CMakeDeps for transitive dependencies, instead of affecting the downstream recipe. Is it correct?

Example:

- libA depends on libB, no traits (so libB is private)
- libA & libB shared

Now in test package of libA, we just require libA, and for some reason we want to call find_package(libB REQUIRED) & link libB::libB target. When I do this, headers are not found, even though libB::libB is explicitly linked in CMakeLists of test package. So my understanding is that files generated by CMakeDeps for libB depend on libA and requirements() content of root conanfile, and it's very weird. I would have expected that traits logic would live in config files of libA, not libB.

I know that for conan, it's a hack to link libB::libB if it's a transitive dependency, but for some recipes it's impossible to add an explicit require to libB in test package (when it depends on options of libA for example, which can't be evaluated in requirements() of test package, or when versioning compatibility is tricky).

Some concrete examples:
 - xmlsec: https://github.com/conan-io/conan-center-index/pull/17062 (at this commit for example: https://github.com/conan-io/conan-center-index/pull/17062/commits/35895ea5102598d5baebbf62beb123c2415be458)
 - aws-c-cal: https://github.com/conan-io/conan-center-index/pull/17100

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: SpaceIm
issue_13699: state: open
title: [bug] conan 1.x doesn't support jinja template profiles
body: ### Environment details

* Operating System+version:
```
LSB Version:    :core-4.1-amd64:core-4.1-ia32:core-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 7.9 (Maipo)
Release:        7.9
Codename:       Maipo
```
* Compiler+version: N/A
* Conan version: 1.59.0
* Python version: 3.8.16

Since conan 1.x requires `.jinja` extension for jinja templates, it doesn't work when `profile` is a jinja template. 

Steps to reproduce:

1.  Create two files (`test.jinja` and `test2` with the same content in `$CONAN_USER_HOME/.conan/profiles`:
    ```jinja
    {% set value = "some value" %}

    [options]
    name={{ value }}
    ```
2.  As expected, conan 1.x fails with `test2`:
    ```
    $ conan profile show test2
    ERROR: Error reading 'test2' profile: The names of the variables cannot contain spaces
    ```
3.  On the other side, `test` can't be used as profile name because there is no file with this name:
    ```
    $ conan profile show test      
    ERROR: Profile not found: test
    ```
4.  So to use `test` profile, one has to write `test.jinja` explicitly says that this is a jinja template:
    ```
    $ conan profile show test.jinja
    Configuration for profile test.jinja:

    [settings]
    [options]
    name=some value
    [conf]
    [build_requires]
    [env]
    ```

Suggested fix: if there is no file with exact name as profile (e.g. `test`), look for a file with `.jinja` extension (e.g. `test.jinja`).

This fix will simplify migrating of plain profile files into jinja templates because otherwise, one had to have a lot of profiles that simply include corresponding files with `.jinja` extension, like **test** profile file for the example above:
```
include(test.jinja)
```
user: andrey-zherikov
issue_13697: state: open
title: How to change location/order  of -ldl
body: ### What is your question?

Hi!
I am writing an application that of which a library requires the -ldl parameter to be passed.
I am currently using conan 1.59 and cmake 3.25 on linux.

Using CMAKE I have added the -ldl parameter using the following in the CMakeLists.txt file....
target_link_libraries(${CMAKE_PROJECT_NAME} ${CMAKE_DL_LIBS})

The issue I am having is that it appears that I need to move the location of this parameter for me to be able to successfully link my applicaiton.

`/usr/bin/c++ -m64 -O3 -DNDEBUG -m64 CMakeFiles/em.dir/src/main.cpp.o CMakeFiles/em.dir/src/common.cpp.o -o em  -Wl,-rpath,/home/ddodd/.conan/data/ddi_em/1.4.0/ddi/dev/package/be051a40a7a84a61196272705bf2ae739cda3dad/lib     -ldl 
       /home/ddodd/.conan/data/ddi_em/1.4.0/ddi/dev/package/be051a40a7a84a61196272705bf2ae739cda3dad/lib/libddi_em.so /home/ddodd/.conan/data/ddi_common/1.0.1/ddi/stable/package/b911f48570f9bb2902d9e83b2b9ebf9d376c8c56/lib/libddi_common.a /home/ddodd/.conan/data/ddi_ntime/1.0.1/ddi/stable/package/b911f48570f9bb2902d9e83b2b9ebf9d376c8c56/lib/libddi_ntime.a -lpthread /home/ddodd/.conan/data/fmt/9.1.0/_/_/package/db123017807f5c094e7ffe64463018510e127133/lib/libfmt.a -lm 
`
This command results in the following errors..
```
/usr/bin/ld: /home/ddodd/.conan/data/ddi_em/1.4.0/ddi/dev/package/be051a40a7a84a61196272705bf2ae739cda3dad/lib/libddi_em.so: undefined reference to `dlopen'
/usr/bin/ld: /home/ddodd/.conan/data/ddi_em/1.4.0/ddi/dev/package/be051a40a7a84a61196272705bf2ae739cda3dad/lib/libddi_em.so: undefined reference to `dlerror'
/usr/bin/ld: /home/ddodd/.conan/data/ddi_em/1.4.0/ddi/dev/package/be051a40a7a84a61196272705bf2ae739cda3dad/lib/libddi_em.so: undefined reference to `dlsym'
```

If I manually move the -ldl to the end of the command I am able to link and run the application successfully.

I also, was unable to find a way to include the -ldl from within the conan configuration.  I would prefer to do that!  So if it is possible please direct me to documentation on how to do it....

Here is my conanfile.py

I am not sure how to get this to treat the first part of the file as "code"
```python
import os

from conan import ConanFile, tools
from conan.tools.cmake import CMake, CMakeToolchain, CMakeDeps

class DDITestMasterConan(ConanFile):
    name = "em"
    version = os.environ.get("LIBRARY_VERSION")
 
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}
    generators = "cmake_paths"

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def requirements(self):
        self.requires("ddi_slotcard/1.0.3@ddi/stable")
        self.requires("nlohmann_json/3.11.2")
        self.requires("yarger/1.0.0@ddi/stable")
        self.requires("spdlog/1.11.0")
        if self.settings.os != "Windows":
          self.requires("ddi_em/1.4.0@ddi/dev") 
        
    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()
        deps = CMakeDeps(self)
        deps.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()

    def package(self):
        self.copy("src/*.h", dst="include")
        self.copy("*.lib", dst="lib", keep_path=False)
        self.copy("*.a", dst="lib", keep_path=False)
```

Appreciate conan and any help/suggestions you can give me!



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ddi-ddodd
issue_13695: state: open
title: [question] What is the recommended way of dealing with "try_run"
body: ### What is your question?

What is the best way to deal with "try_run" in conan during cross-compilation? Is there any way to somehow inject preconfigured variables for specific environment without changing recipe each time?
I've recently found out about CMAKE_CROSSCOMPILING_EMULATOR which can be probably used for Emscripten. But I don't see how to use it with conan.

And what about cases where emulator can't be used? For example, cross-compiling on Apple Silicon from arm64 to x86_64?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Nekto89
issue_13692: state: open
title: [question] conan 2, win_bash_run and self.run()
body: I have a recipe created for conan 1 that uses `self.run(cmd, win_bash=True)` in its `build()` method. I want to migrate this recipe to conan 2, in which the `win_bash` argument is not supported.

So far I've set the conanfile attribute `win_bash_run = True`, and replaced the `win_bash` argument with `scope='run'`, but now the build fails with the following error message:

    ERROR: win_bash_run=True but tools.microsoft.bash:subsystem configuration not defined

After that I tried running:

    conan config set tools.microsoft.bash:subsystem=msys2

before `conan build`, but while that works for conan 1, it fails for conan 2 because the `set` subcommand has been removed.

Where do I go from here?
user: skoolkid
issue_13691: state: open
title: [bug] Autotools.install documentation does not match its behavior
body: ### Environment details

* Conan version: 2.0.4


### Steps to reproduce

1. Pass args=None
2. Wonder why DESTDIR is still set by conan

The documentation for conan.tools.gnu.Autotools.install states: "By default an argument ``DESTDIR=unix_path(self.package_folder)`` is added to the call if the passed value is ``None``." Yet DESTDIR is always added unless DESTDIR= appears in the joined args.

### Logs

_No response_
user: ltjax
issue_13686: state: open
title: [question] Private dependencies for `application` package type
body: ### What is your question?

For our usecase, we have several `application` recipes that are used during the build.
They are built with profile "A":
```ini
[settings]
os=Windows
arch=x86_64
build_type=Release

compiler=clang
compiler.version=15
compiler.cppstd=17
compiler.libcxx=c++_static
compiler.runtime=static
compiler.runtime_type=Release
compiler.runtime_version=v143

[...]
```
using the static CRT lets us replace the system allocator with something more performant which drastically cuts on CPU time (~20%). These tools depend on zlib, and are configured as follows:
```python
    package_type = "application"

    def requirements(self):
        if self.options.with_zlib:
            self.requires("zlib/1.2.13", visible=False)
[...]
    def package_id(self):
        del self.info.settings.compiler
        del self.info.settings.build_type
```

Now, these tools need to be available while building our libraries using profile "B":
```ini
[settings]
os=Windows
arch=x86_64
build_type=Release

compiler=clang
compiler.version=15
compiler.cppstd=17
compiler.libcxx=c++_shared
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.runtime_version=v143
```
When trying to install them however, conan complains that it can't find a prebuilt package for the tools even if it's already in cache.
Upon inspection, this is why:
```diff
[requires]
- zlib/1.2.13#13c96f538b52e1600c40b88994de240f:715953cc7daf111b27d6656d5c887b5791f4dd10
+ zlib/1.2.13#13c96f538b52e1600c40b88994de240f:7bfde258ff4f62f75668d0896dbddedaa7480a0f
```
so conan is computing a different package ID because of zlib being triggered for building. Have I misinterpreted the usage of the `visible` trait? Is the following the right solution for this?
```python
    def package_id(self):
        if self.options.with_zlib:
            self.info.requires.remove("zlib")

        del self.info.settings.compiler
        del self.info.settings.build_type
```

---
I cannot use these tools as `[tool_requires]` because this is #13533 in disguise, one of these `application` packages is a actually clang. 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sykhro
issue_13682: state: open
title: Unable to use boost while creating library
body: ### What is your question?

Hi,

I am trying to build a library using boost 1.75.0 on centos8. I have both CMakeLists.txt and conanfile.py
Method to build library:  cd hello 
                                        conan create . 
conan version = 2.0.2

CMakeLists.txt has "find_package(boost COMPONENTS json REQUIRED)
conanfile.py has 
      self.requires("boost/1.75.0") in def requirements(self) section
     generators = "CMakeDeps"

Error is:
fatal error: boost.h: No such file or directory

This example was working with conan 1.X. I am trying to migrate to conan 2.0.
Please help. 



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: laxmij-cmd
issue_13676: state: open
title: [bug] When msys2 is not in path, and the profile `tools.build:compiler_executables`, compiler unknown in cmake
body: ### Environment details

This is reproducible within vscode, using the built-in re-configure. It doesn't appear to be reproducible with the command alone.

* Operating System+version:
Windows 11 Version 10.0.22621 Build 22621

* Compiler+version:

  - vscode 1.77.1
  - MSYS_NT-10.0-22621 version 3.4.6.x86_64
  - gcc version 12.2.0
  - conan 2.0.4
  - Python 3.10.9

### Steps to reproduce

1. Don't add any msys2's bin directory to path.
2. Create a profile, use the following:
```
[settings]
os=Windows
arch=x86_64
compiler=gcc
compiler.version=12
compiler.libcxx=libstdc++
compiler.exception=seh
compiler.threads=posix
[options]
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
tools.build:compiler_executables={"c": "C:/utils/msys64/mingw64/bin/gcc.exe", "cpp": "C:/utils/msys64/mingw64/bin/g++.exe", "asm": "C:/utils/msys64/mingw64/bin/as.exe" }
```
3. Open vscode, reconfigure, the error will be present.

### Logs

```
[cmake] -- The C compiler identification is unknown
[cmake] -- The CXX compiler identification is unknown
[cmake] -- Detecting C compiler ABI info
[cmake] -- Detecting C compiler ABI info - failed
[cmake] -- Check for working C compiler: C:/utils/msys64/mingw64/bin/gcc.exe
[cmake] -- Check for working C compiler: C:/utils/msys64/mingw64/bin/gcc.exe - broken
```

```
[cmake]     Run Build Command(s):C:/utils/bin/ninja.exe -v cmTC_7c519 && [1/2] C:\utils\msys64\mingw64\bin\gcc.exe -D_GLIBCXX_USE_CXX11_ABI=0  -m64 -o CMakeFiles\cmTC_7c519.dir\testCCompiler.c.obj -c build\CMakeFiles\CMakeScratch\TryCompile-0rc9z6\testCCompiler.c
[cmake]     FAILED: CMakeFiles/cmTC_7c519.dir/testCCompiler.c.obj 
[cmake]     C:\utils\msys64\mingw64\bin\gcc.exe -D_GLIBCXX_USE_CXX11_ABI=0  -m64 -o CMakeFiles\cmTC_7c519.dir\testCCompiler.c.obj -c build\CMakeFiles\CMakeScratch\TryCompile-0rc9z6\testCCompiler.c
[cmake]     ninja: build stopped: subcommand failed.
[cmake]     
[cmake]   CMake will not be able to correctly generate this project.
```
user: seppeon
issue_13665: state: open
title: How to copy Qt supporting dlls required to run an application
body: ### What is your question?

Hi,

This seemed to work in Conan 1.x but in Conan 2.x, what I would have expected to work doesn't.

In my recipe, I copy all the 3rd party dlls to my build/bin folder which is fine except Qt has several folders that contain specific dll's for the application to run properly and they are located in several folders grouped in a certain way.
For example, in my conan cache under Qt, C:\Users\UserName\.conan2\p\qtc3c34ab36b321\p\bin\archdatadir\plugins There are several folders:
bearer
generic
imageformats
platforms
etc

How can I copy those folders and contents directly from the cache to my bin folder?  I didn't do anything special in 1.x but for some reason in 2.x the individual dlls are copied and not the folders.  I would like to do this, this way I don't have to copy each individual dll into its corresponding Qt folder listed above.
Thanks!


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: leinadme
issue_13655: state: open
title: [question] armv8 cross compile build failed usins same cananfile.txt used in linux X86_64
body: ### What is your question?

We used conanfile.txt for intel based build system for several months based on conan v1.59.0.

One of additional requirements from out customer is cross build environment. So we just added host-build profile for armv8, but build failed.

Here is our conanfile.txt:
```
[requires]
zlib/1.2.13
eigen/3.3.7
boost/1.73.0
openssl/1.1.1t
cpprestsdk/2.10.18
protobuf/3.20.0
grpc/1.38.1
libcurl/7.87.0
libpng/1.6.38
opencv/4.5.5

[generators]
cmake_find_package
cmake_paths
CMakeDeps
```

Also below command worked well.
```
conan install -r conancenter -pr hostbuild  -s build_type=Debug --build=missing -if ./Debug conanfile.txt
```

But, when I set cross compile environment as below:
```
conan install -r conancenter -pr:b hostbuild -pr:h vpsdev_armv8 -s build_type=Debug --build=missing -if ./Debug conanfile.txt
```
Using below profile for cross-compile env :
```
[settings]
os=Linux
arch=armv8
compiler=gcc
compiler.version=9
compiler.cppstd=17
compiler.libcxx=libstdc++11
build_type=Release

[conf]
tools.cmake.cmaketoolchain:generator=Ninja

[buildenv]
CC=/l4t/toolchain/bin/aarch64-linux-gcc
CXX=/l4t/toolchain/bin/aarch64-linux-g++
LD=/l4t/toolchain/bin/aarch64-linux-ld
```

overriding some package of conanfile.txt was not worked.
```
WARN: cpprestsdk/2.10.18: requirement boost/1.80.0 overridden by your conanfile to boost/1.73.0
WARN: cpprestsdk/2.10.18: requirement openssl/1.1.1s overridden by your conanfile to openssl/1.1.1t
WARN: websocketpp/0.8.2: requirement boost/1.81.0 overridden by cpprestsdk/2.10.18 to boost/1.73.0
WARN: grpc/1.38.1: requirement openssl/1.1.1n overridden by your conanfile to openssl/1.1.1t
WARN: grpc/1.38.1: requirement zlib/1.2.12 overridden by your conanfile to zlib/1.2.13
WARN: opencv/4.5.5: requirement libpng/1.6.39 overridden by your conanfile to libpng/1.6.38
WARN: opencv/4.5.5: requirement eigen/3.3.9 overridden by your conanfile to eigen/3.3.7
WARN: libtiff/4.4.0: requirement libwebp/1.3.0 overridden by opencv/4.5.5 to libwebp/1.2.4
WARN: protobuf/3.20.0: requirement zlib/1.2.13 overridden by grpc/1.38.1 to zlib/1.2.12
ERROR: protobuf/3.20.0: Incompatible requirements obtained in different evaluations of 'requirements'
    Previous requirements: [zlib/1.2.13]
    New requirements: [zlib/1.2.12]
```

We also tried to use not only conanfile.py but also conan v2. In case of conanfile.py caused same error - cannot override package-. Many packages didnt support v2. So, I decided that we must use conan v1.

In summary, let me know how to handle "Incompatible requirements obtained in different evaluations of 'requirements' " in cross-compile environment using v1.

Thank you in advanced. 


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: kismetro
issue_13649: state: open
title: [question] Unit testing packages for embedded targets
body: ### What is your question?

**Overview**
I’ve searched through the existing issues/questions but couldn’t find one that addresses this particular use case.

In general, I have many internal packages built to run on an ARM target. However, I am at a crossroads on how to best unit test these packages on Windows. For context, I have not moved to Conan 2.0 yet, and am running v1.56.

**Background**
Imagine the scenario where you are using Conan to manage a series of embedded packages. The packages in question are all internal and hosted within an Artifactory instance.

These packages were all built with the `gcc-arm-none-eabi` toolchain, and were designed to run on a Cortex-M target. Up until now, this has worked as expected. Embedded developers create packages based on the component they are working on, which then get consumed by other packages.

Applications then become the sum of all packages required for the application. I know the term "Application" is somewhat overloaded, but in this example, let’s say the Application is the entity that owns main(). It is also the one that requires a subset of Conan packages to facilitate some functionality.

As a basic example, if you’re working on various ARM chipsets, you might define a Conan package for the HAL. That HAL package would then be required by other packages that require access to the hardware.

Similarly, you might create a Conan package for the OS, such as ThreadX, or FreeRTOS, or maybe an OS abstraction layer similar to the HAL mentioned above.

In either case, the point is that the Application, destined for an ARM target, would consume these packages, which have all been built and compiled with `gcc-arm-none-eabi`, so that the single Application executable can be flashed onto the device.

**Question**
As mentioned above, everything is built with `gcc-arm-none-eabi`. However, I would like to add unit tests with a standard [GTest package](https://conan.io/center/gtest?tab=recipe) provided by Conan Center. To do that, I would have to recompile everything with GCC on X86 or X86_64, using something like [MinGW](https://conan.io/center/mingw-builds), or [MSYS2](https://conan.io/center/msys2), which is also on Conan Center.

The issue is that there are many internal packages that were not designed to be compiled against a Windows target. Also, the packages tend to use specific compiler flags in their associated `CMakeLists.txt`, which would not necessarily map to MinGW gcc, for example `-mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16`.

I’ve spent some time thinking about how I could do this and have put a couple of options below.

I’m curious what you think or if maybe I am going about this the wrong way.

1. Since the Unit Tests on running on Windows, I really don’t want to rebuild each package (which was previously built with `gcc-arm-none-eabi`). Instead, I want to build my code under test, and then mock out all other dependencies. With that said, maybe there’s a way to tell Conan to require package (x), but only the headers, not the source? In that case, since I have the headers, I would just provide stubs for the functions that did not link. This would allow me to write my unit tests, without having to rebuild an ARM-centric package, such as the HAL mentioned above.

2. Another option, similar to the one above, is to add logic for each internal package(yikes) to take a Conan option called `header-only`. If the consumer sets the option, then it will be packaged as a header-only, excluding the source. This would make it so all unit tests can simply set the Conan option in the profile or CLI. i.e we would use one profile for standard ARM builds and a different one for unit tests. The Unit Test profile would set the option which would prevent rebuilding the source as its header only.

3. Not ideal, but go through each internal package, and make sure it compiles for both Windows, and ARM. For hardware-specific API's mock those out. This would be the most costly option, but it might not be a bad idea. New packages would then have a sort of "done criteria", that requires them to build on both targets.

I know Conan is used by many in the embedded space, so I certainly don't want to reinvent the wheel. I'm curious if any of those options make sense and what others generally do in this scenario.

Thanks!



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: RobbyChapman
issue_13648: state: open
title: [question]About version conflicts for dependencies
body: ### What is your question?

the conan version I’m using is 1.58.0
![image](https://user-images.githubusercontent.com/100983632/230600820-e4c118b6-0182-437d-9e76-761af8867bda.png)
cmake version is 3.26.2
![image](https://user-images.githubusercontent.com/100983632/230600858-6995e96e-1cc4-4b88-963a-cc67e4dd880e.png)
my [conanfile.txt] reads as flows：
```
[requires]
eigen/3.4.0
openssl/1.1.1n
zlib/1.2.12
sqlite3/3.36.0
qt/5.15.3
gdal/3.1.0
[generators]
cmake_find_package
[options]
qt:shared=True 
```
after I ran the command：conan install . --build=missing
it showed one error：
```
 WARN: qt/5.15.3: requirement openssl/1.1.1q overridden by your conanfile to openssl/1.1.1n 
WARN: qt/5.15.3: requirement sqlite3/3.39.2 overridden by your conanfile to sqlite3/3.36.0 
WARN: pcre2/10.40: requirement zlib/1.2.13 overridden by qt/5.15.3 to zlib/1.2.12 
WARN: freetype/2.12.1: requirement libpng/1.6.39 overridden by qt/5.15.3 to libpng/1.6.37 
WARN: freetype/2.12.1: requirement zlib/1.2.13 overridden by qt/5.15.3 to zlib/1.2.12 
WARN: libpng/1.6.37: requirement zlib/1.2.13 overridden by freetype/2.12.1 to zlib/1.2.12 
WARN: gdal/3.1.0: requirement zlib/1.2.11 overridden by your conanfile to zlib/1.2.12 
WARN: libgeotiff/1.7.0: requirement libtiff/4.4.0 overridden by gdal/3.1.0 to libtiff/4.3.0 
WARN: libgeotiff/1.7.0: requirement proj/9.1.1 overridden by gdal/3.1.0 to proj/8.1.1 
WARN: libtiff/4.3.0: requirement zlib/1.2.13 overridden by libgeotiff/1.7.0 to zlib/1.2.12 
WARN: libtiff/4.3.0: requirement libjpeg/9e overridden by libgeotiff/1.7.0 to libjpeg/9d 
ERROR: Conflict in libtiff/4.3.0:
    'libtiff/4.3.0' requires 'zstd/1.5.4' while 'qt/5.15.3' requires 'zstd/1.5.2'.
    To fix this conflict you need to override the package 'zstd' in your root package.
CMake Error at cmake-build-debug/conan.cmake:653 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  cmake/deps.cmake:52 (conan_cmake_install)
  CMakeLists.txt:23 (include)
```
---------------------------------------------------------------------------------------------------------
I tried modifying my file like this：
```
[requires]
eigen/3.4.0
openssl/1.1.1n
zlib/1.2.12
sqlite3/3.36.0
qt/5.15.3
ztsd/1.5.4
gdal/3.1.0
[generators]
cmake_find_package
[options]
qt:shared=True 
```
but it didn't worked.

Could someone help me？


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: alLiucb
issue_13615: state: open
title: conan v2: pretty printing DepsGraph object
body: Its very difficult to recreate the very useful output of the client  for example `conan graph info --requires spdlog/1.11.0 --format json` because many of the objects are not implicitly support serialization results in errors like `TypeError: Object of type DepsGraph is not JSON serializable`

```py
        deps_graph = conan_api.graph.load_graph_requires(requires=[reference], tool_requires=[],
            profile_host=profile_host, profile_build=profile_build, lockfile=None, remotes=[],
            update=False, check_updates=False)
        conan_api.graph.analyze_binaries(deps_graph, build_mode=["missing"], remotes=[], update=False,
                                lockfile=None)
        print_graph_packages(deps_graph)
        json.dumps(deps_graph)
```

I did manage to track down the special code ....

https://github.com/conan-io/conan/blob/0c1624d2dd3b0278c1cf6f66f8dcc7bd1aa9ec48/conan/cli/formatters/graph/graph.py#L136
user: prince-chrismc
issue_13614: state: open
title: consumer can not download packages which I packed.
body: ### What is your question?

Here is my recipe
from conan import ConanFile
from conan.tools.files import copy
import os

class HfvInspect(ConanFile):
    name = "hfvinspect"
    version = "2.0.1"

    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}

    default_options = {"shared": False, "fPIC": True}
    requires = ["hfvlibrary/2.0.1"]
    generators = "CMakeDeps"


    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def baseName(self):
        return "HfvInspect"
        
    def package(self):
        arch = self.settings.get_safe("arch", default="x86")
        if arch == "x86":
            arch = "Win32"

        build_type = self.settings.get_safe("build_type", default="Release")

        print("=======================")
        print("Build/%s_%s/%s.lib"%(arch, build_type, self.baseName()))
        copy(self, pattern="*.h", src='.', dst=os.path.join(self.package_folder, "include"), keep_path=False)
        copy(self, pattern="Build/%s_%s/%s.lib"%(arch, build_type, self.baseName()), src='.', dst=os.path.join(self.package_folder, "lib"), keep_path=False)
        copy(self, pattern="Build/%s_%s/%s.dll"%(arch, build_type, self.baseName()), src='.', dst=os.path.join(self.package_folder, "bin"), keep_path=False)

    def package_info(self):
        self.cpp_info.libs = [self.baseName()]

I packed the binary lib and include folders, then I uploaded them to the JFrog.

PS C:\Users\harry> conan list hfvlibrary:* -r txww
txww
  hfvlibrary
    hfvlibrary/2.0.1
      revisions
        818bd761d49adc9289527d690e91ef79 (2023-03-27 16:22:46 UTC)
          packages
            ae4d4001e234191236108e2b6891c7a3025ec5d2
              info
                settings
                  arch: x86
                  build_type: Debug
                  compiler: msvc
                  compiler.runtime: dynamic
                  compiler.runtime_type: Debug
                  compiler.version: 192
                  os: Windows
                options
                  shared: True
                requires
                  jbig/20160605#2d29fa02aacd76902e0d2cbbc24631ef:e4dca085a89e4ca00f3ca82c801662d36aceac70
                  libdeflate/1.17#71f492ef993b45d9b961b36fb85e801f:1feaaaa4dde6c13b4d5e0b75ae078ac9e4ab2b1a
                  libjpeg/9e#68269859e4325ddc3f995d1fd3fc9187:1feaaaa4dde6c13b4d5e0b75ae078ac9e4ab2b1a
                  libpng/1.6.39#deca555b0890e584fc895ba756e83c06:865a1b19ae9d207da564337b643cc893805258a0
                  libtiff/4.4.0#e6d8942022c89a22dfbe1a9b77289c7e:99678841da3608293a8492ef038829e422a111f7
                  libwebp/1.3.0#d92654dbce1f8cb8ae45d5388f86fcfe:632480428c56e7fc7fdf67a82ffa55e70d0034d3
                  xz_utils/5.4.0#186e94237b66f785e4ea095f2f621a56:1feaaaa4dde6c13b4d5e0b75ae078ac9e4ab2b1a
                  zlib/1.2.13#13c96f538b52e1600c40b88994de240f:1feaaaa4dde6c13b4d5e0b75ae078ac9e4ab2b1a
                  zstd/1.5.4#15ac0bc440f89247276d78ea4fdf8b14:f7eda18446204245ddca91e447f21659ee8b6afb
            6ada2b1b18527439763f90baeaf118496b7b8327
              info
                settings
                  arch: x86_64
                  build_type: Debug
                  compiler: msvc
                  compiler.runtime: dynamic
                  compiler.runtime_type: Debug
                  compiler.version: 192
                  os: Windows
                options
                  shared: True
                requires
                  jbig/20160605#2d29fa02aacd76902e0d2cbbc24631ef:4c98541369841e147ebbba95651a111a25ce24da
                  libdeflate/1.17#71f492ef993b45d9b961b36fb85e801f:25f93aaacbebaa913a6aaecd4fa01e3ef49c798a
                  libjpeg/9e#68269859e4325ddc3f995d1fd3fc9187:25f93aaacbebaa913a6aaecd4fa01e3ef49c798a
                  libpng/1.6.39#deca555b0890e584fc895ba756e83c06:779a65a699f8fbb8c725ae5b03b7a21f30a7d3b5
                  libtiff/4.4.0#e6d8942022c89a22dfbe1a9b77289c7e:1470b2f48a7f48badc53836536c41fa714a3d728
                  libwebp/1.3.0#d92654dbce1f8cb8ae45d5388f86fcfe:69e41dedfc7f97155bcfd2aeb65197708fd1aee7
                  xz_utils/5.4.0#186e94237b66f785e4ea095f2f621a56:25f93aaacbebaa913a6aaecd4fa01e3ef49c798a
                  zlib/1.2.13#13c96f538b52e1600c40b88994de240f:25f93aaacbebaa913a6aaecd4fa01e3ef49c798a
                  zstd/1.5.4#15ac0bc440f89247276d78ea4fdf8b14:bc2a8dd1fd7ca5bf802db9f67e874e986d8b8f1c
            3967b599fc5754a562617a7a5bfdaa4b52df193a
              info
                settings
                  arch: x86_64
                  build_type: Release
                  compiler: msvc
                  compiler.runtime: dynamic
                  compiler.runtime_type: Release
                  compiler.version: 192
                  os: Windows
                options
                  shared: True
                requires
                  jbig/20160605#2d29fa02aacd76902e0d2cbbc24631ef:cce0638b24486ce38229e298351f25f1373c8986
                  libdeflate/1.17#71f492ef993b45d9b961b36fb85e801f:41ad450120fdab2266b1185a967d298f7ae52595
                  libjpeg/9e#68269859e4325ddc3f995d1fd3fc9187:41ad450120fdab2266b1185a967d298f7ae52595
                  libpng/1.6.39#deca555b0890e584fc895ba756e83c06:e5fe0b6535d74eb6994abd4674a39f9ab96055f1
                  libtiff/4.4.0#e6d8942022c89a22dfbe1a9b77289c7e:a2b0a68d062c3daca42a7b277a10552de8c27ff6
                  libwebp/1.3.0#d92654dbce1f8cb8ae45d5388f86fcfe:108623af8e2ffcc15db6c3d7d44e673780f612c7
                  xz_utils/5.4.0#186e94237b66f785e4ea095f2f621a56:41ad450120fdab2266b1185a967d298f7ae52595
                  zlib/1.2.13#13c96f538b52e1600c40b88994de240f:41ad450120fdab2266b1185a967d298f7ae52595
                  zstd/1.5.4#15ac0bc440f89247276d78ea4fdf8b14:43819e6b96c119efbb6462ca6fe82f587b56d528
            4664824d02fd894072b9964f3868e46e5b973e0f
              info
                settings
                  arch: x86
                  build_type: Release
                  compiler: msvc
                  compiler.runtime: dynamic
                  compiler.runtime_type: Release
                  compiler.version: 192
                  os: Windows
                options
                  shared: True
                requires
                  jbig/20160605#2d29fa02aacd76902e0d2cbbc24631ef:bf99faa1d6cdd0228c4a2d9ca724c80ab2070cd8
                  libdeflate/1.17#71f492ef993b45d9b961b36fb85e801f:7ab1c199a1c5aa3d35bb43d7a45168d0ef29cf50
                  libjpeg/9e#68269859e4325ddc3f995d1fd3fc9187:7ab1c199a1c5aa3d35bb43d7a45168d0ef29cf50
                  libpng/1.6.39#deca555b0890e584fc895ba756e83c06:a638816844af5ce46ad834a94313845434e1c7e6
                  libtiff/4.4.0#e6d8942022c89a22dfbe1a9b77289c7e:014ad25bf34f4b05fe927e23c92844b70bacb52c
                  libwebp/1.3.0#d92654dbce1f8cb8ae45d5388f86fcfe:ad37ba069488c9a6236f93482e445d8d92760473
                  xz_utils/5.4.0#186e94237b66f785e4ea095f2f621a56:7ab1c199a1c5aa3d35bb43d7a45168d0ef29cf50
                  zlib/1.2.13#13c96f538b52e1600c40b88994de240f:7ab1c199a1c5aa3d35bb43d7a45168d0ef29cf50
                  zstd/1.5.4#15ac0bc440f89247276d78ea4fdf8b14:70b39e617b27576562366d24164e00fb19e96495

Test1: When I do the command "conan install --requires=hfvlibrary/2.01 -r txww",  everything is ok. [Win10]
Test2: But when others try to do the samething to install the recipy,  conan report that [Missing pre-build binary]. [Win11]


The profile is exactly the same:

[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.runtime=dynamic
compiler.version=192
os=Windows

I found that the difference between "Test1" and "Test2" is that the [package id] is different. Is there somethig wrong when I packed it?
I just wanna know how to pack my package, so others can use it well.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fancygit
issue_13604: state: open
title: [feature] Support for zig as a C and C++ compiler
body: ### What is your suggestion?

I would like to be able to use the zig compiler to build C and C++ so I can use its support for cross-compilation and selectable libc support

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: dheater
issue_13594: state: open
title: Feature/b2
body: Changelog: Feature: Adds a B2Deps and B2Toolchain generators for the B2 build system.
Docs: https://github.com/conan-io/docs/pull/XXXX

- [ ] Refer to the issue that supports this Pull Request.
- [ ] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [X] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [X] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 

user: grisumbras
issue_13592: state: open
title: Add B2Deps generator.
body: Changelog: Feature: Adds a B2Deps generator for the B2 build system.
Docs: https://github.com/conan-io/docs/pull/3142

- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [x] I've opened another PR in the Conan docs repo to the ``release/2.0`` branch, documenting this one. 

user: grafikrobot
issue_13591: state: open
title: [question] Clang command line arguments and custom libc++
body: ### What is your question?

TL;DR: Can Conan provide argument to invocations of clang? Specifically arguments for using a custom built libc++ in a non-standard location.
___
Conan Community,

I am working in an environment where `/usr` is locked down by IT. C++ standard library changes were pushed by IT breaking building products on Linux. I manage our on-site Conan repositories and build processes. The team has decided to mitigate risk from IT by standardizing our compiler installation to clang for Linux and Windows. Linux has taken priority given our broken product.

I was able to build clang on Linux with correct enough [flavors](https://blog.conan.io/2022/10/13/Different-flavors-Clang-compiler-Windows.html). I built runtimes and linked against them explicitly [using a custom built libc++](https://libcxx.llvm.org/UsingLibcxx.html#using-a-custom-built-libc). Using `ldd` I was able to verify that the program was linking against the custom libc++ and libc++abi.

I attempted to extend that idea to our on-site Conan repositories. I was unsuccessful at finding a way to provide arguments to clang via Conan. I did find [global.conf settings like tools.build:cxxflags](https://docs.conan.io/1/reference/config_files/global_conf.html#tools-configurations), but the arguments didn't seem to propagate to clang invocations from build systems. Ideally, I would like to provide the command line arguments to clang to use the custom libc++ and libc++abi, but I haven't figured it out yet.

I was able to resolve a number of issues with environment variables. I will enumerate the specifics.

1. Set up Conan profile to use settings for custom compiler
2. Setting `CC` and `CXX` to the desired compiler for ensuring CMake finds the custom compiler
3. Setting `CPATH` to the location of headers for the custom libc++ as a substitute for `-isystem <install>/include/c++/v1`
4. Setting `LIBRARY_PATH` to the location of the custom libc++ library as a substitute for `-L <install>/lib`
5. Add environment variables to the Conan profile
6. Alias clang and clang++ to the custom compiler helping build systems find the correct compiler

The steps above allowed many dependencies to build using Conan. The dependencies that did not build produced errors I could verify with my test program. I had a duplicate definition issue when I removed the [-nostdinc++](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang1-nostdinc) argument. I had unresolved external symbol issues when I removed the [-Wl,-rpath,<install>/lib](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-wl-arg-arg2) argument.

I would like to know if [Conan's tool configurations](https://docs.conan.io/1/reference/config_files/global_conf.html#tools-configurations) can provide arguments to the compiler. I would like to know about strategies to manage the compiler using Conan. I would like to know anything I am overlooking. The solution may be twisting IT's arm to get updated compilers in typical locations.

Thank you!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: skipfowler
issue_13582: state: open
title: [question] Define build destination 
body: ### What is your question?

Hello!

I am trying to cross-build opencv (From the Conan Center) from x86 to amrv8 using Conan 1.59

To build opencv I am running the command:
`conan install . --build=missing -pr:b=default -pr:h=./cross-profile.txt -c tools.system.package_manager:mode=install -if /opt/axis/acapsdk/sysroots/aarch64/usr/lib/pkgconfig/ -of /opt/axis/acapsdk/sysroots/aarch64/usr/`

My default profile is:
```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++
build_type=Release
[options]
[conf]
[build_requires]
[env]
```

I have a cross-profile.txt file that looks like this:
```
[settings]
os=Linux
arch=armv8
build_type=Release
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++11

[buildenv]
CC=aarch64-linux-gnu-gcc -mcpu=cortex-a53 -march=armv8-a+crc+crypto -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/opt/axis/acapsdk/sysroots/aarch64 -L/opt/axis/acapsdk/sysroots/aarch64/usr/lib
CXX=aarch64-linux-gnu-g++ -mcpu=cortex-a53 -march=armv8-a+crc+crypto -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/opt/axis/acapsdk/sysroots/aarch64 -L/opt/axis/acapsdk/sysroots/aarch64/usr/lib
LD=aarch64-linux-gnu-ld --sysroot=/opt/axis/acapsdk/sysroots/aarch64



[conf]
tools.build:sysroot=/opt/axis/acapsdk/sysroots/aarch64
```

and conanfile.txt:
```

[requires]
cmake/3.25.3
opencv/4.5.5

[generators]
PkgConfigDeps
MesonToolchain

[options]
opencv:with_openexr=False
opencv:with_webp=False
opencv:with_gtk=False
opencv:with_jpeg2000=False
opencv:with_v4l=False
opencv:with_ffmpeg=False
opencv:with_png=False
opencv:dnn=False

# make haders go to /opt/axis/acapsdk/sysroots/aarch64/usr/include/
# make libs go to /opt/axis/acapsdk/sysroots/aarch64/usr/lib/
[imports]
lib, *.h -> /opt/axis/acapsdk/sysroots/aarch64/usr/include/
lib, *.hpp -> /opt/axis/acapsdk/sysroots/aarch64/usr/include/
lib, *.so* -> /opt/axis/acapsdk/sysroots/aarch64/usr/lib/

```

The build succeed, looking in my installation directory (`/opt/axis/acapsdk/sysroots/aarch64/usr/lib/pkgconfig/`) specified in the install command I find all the opencv*.pc files.

Here's what I get when I cat one of them

```
cat /opt/axis/acapsdk/sysroots/aarch64/usr/lib/pkgconfig/opencv-opencv_core.pc
prefix=/root/.conan/data/opencv/4.5.5/_/_/package/9bab48b3e7c75afc311f7c109f44f30ba1b1cd80
libdir1=${prefix}/lib
includedir1=${prefix}/include
includedir2=${prefix}/include/opencv4

Name: opencv-opencv_core
Description: Conan component: opencv-opencv_core
Version: 4.5.5
Libs: -L"${libdir1}" -lopencv_core -ltegra_hal -ldl -lm -lpthread -lrt 
Cflags: -I"${includedir1}" -I"${includedir2}" 
Requires: zlib eigen3
```
Everything seems fine, except that the prefix is set to `/root/.conan/data/opencv/4.5.5/_/_/package/9bab48b3e7c75afc311f7c109f44f30ba1b1cd80`. I am trying to make it go instead in my sysroot so that I can easily build my application using opencv built by conan.

Now, when I try to build an application that uses opencv, I get the following error:
```
FAILED: opencv_app.p/example.cpp.o 
aarch64-linux-gnu-g++ -mcpu=cortex-a53 -march=armv8-a+crc+crypto -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/opt/axis/acapsdk/sysroots/aarch64 -L/opt/axis/acapsdk/sysroots/aarch64/usr/lib -Iopencv_app.p -I. -I.. -I/opt/axis/acapsdk/sysroots/aarch64/root/.conan/data/zlib/1.2.13/_/_/package/115c8fa606e08a868a5ec8073c26c1a096c7263b/include -I/opt/axis/acapsdk/sysroots/aarch64/usr/include/glib-2.0 -I/opt/axis/acapsdk/sysroots/aarch64/usr/lib/glib-2.0/include -I/opt/axis/acapsdk/sysroots/aarch64/usr/include/vdo -I/opt/axis/acapsdk/sysroots/aarch64/usr/include/gio-unix-2.0 -I/opt/axis/acapsdk/sysroots/aarch64/root/.conan/data/opencv/4.5.5/_/_/package/9bab48b3e7c75afc311f7c109f44f30ba1b1cd80/include -I/opt/axis/acapsdk/sysroots/aarch64/root/.conan/data/opencv/4.5.5/_/_/package/9bab48b3e7c75afc311f7c109f44f30ba1b1cd80/include/opencv4 -I/opt/axis/acapsdk/sysroots/aarch64/root/.conan/data/eigen/3.3.9/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include/eigen3 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -O2 -pipe -g -feliminate-unused-debug-types -pthread -MD -MQ opencv_app.p/example.cpp.o -MF opencv_app.p/example.cpp.o.d -o opencv_app.p/example.cpp.o -c ../example.cpp
../example.cpp:19:10: fatal error: opencv-opencv_imgproc.hpp: No such file or directory
   19 | #include <opencv-opencv_imgproc.hpp>
```

It looks like that the headers are not found, as it looks for them in the wrong directory:
`/opt/axis/acapsdk/sysroots/aarch64/root/.conan/data/opencv/4.5.5/_/_/package/9bab48b3e7c75afc311f7c109f44f30ba1b1cd80/include
`
But they are in:
`/root/.conan/data/opencv/4.5.5/_/_/package/9bab48b3e7c75afc311f7c109f44f30ba1b1cd80/include
`
Is there a way to make conan install the headers in the correct directory?
Possibly `/opt/axis/acapsdk/sysroots/aarch64/usr/ `

Or it has to be in that specific conan workspace?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: Corallo
issue_13580: state: open
title: [feature] Inheriting from a user's CMake preset
body: ### What is your suggestion?

Right now, it is possible to [generate Conan presets and inherit your own from them](https://docs.conan.io/2/examples/tools/cmake/cmake_toolchain/extend_own_cmake_presets.html#examples-tools-cmake-toolchain-build-project-extend-presets). However the opposite is not possible.

With the usage of CMakePresets some IDEs stopped adding development-specific flags provided in their configuration. For example, [VSCode does not generate compile_commands.json anymore](https://github.com/microsoft/vscode-cmake-tools/issues/1835). Adding this one setting manually to every Conan-generated preset is really inconvenient. It would be great if the users could provide their own preset file with the base configuration like that:

```json
{
    "name": "base",
    "cacheVariables": {
        "CMAKE_EXPORT_COMPILE_COMMANDS": "ON"
    },
    "hidden": true
}
```

specify it on a `[conf]` section as a base preset file which would make Conan include that file and inherit every preset from it. This would be a great improvement that would allow users to inject their own development-specific configuration settings into the pipeline.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: mpusz
issue_13578: state: open
title: [bug] Conan cross building to 32bit sticky
body: ### Environment details

* Operating System+version:
Distributor ID: Ubuntu [in Docker]
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy

* Compiler+version: gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 / g++ (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
* Conan version: 2.0.2
* Python version: 3.10.6


~/.conan2/profiles# cat default
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux

~/.conan2/profiles# cat linux-x86
[settings]
arch=x86
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux

### Steps to reproduce

When cross-building to 32bit using cmake, two issues seem to occur. 

1. "conan build ."  rewrites the conan_toolchain.cmake file, defaulting to a non-cross building configuration, overwriting the configuration set by "conan install . --profile linux-x86" 
2. target outputs produced by cmake are not overwritten when changing settings for cross building. 


**To reproduce Issue 1.**

1. Add a new profile for 32bit architecture called 'linux-x86' (see environment details)
2. Create new cmake project using "conan new cmake_lib -d name=hello -d version=1.0"
3. call "conan install . --profile linux_x86" and inspect build/Release/conan_toolchain.cmake
"
...
message(STATUS "Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)")
set(CMAKE_POSITION_INDEPENDENT_CODE ON CACHE BOOL "Position independent code")

 

string(APPEND CONAN_CXX_FLAGS " -m32")
string(APPEND CONAN_C_FLAGS " -m32")
string(APPEND CONAN_SHARED_LINKER_FLAGS " -m32")
string(APPEND CONAN_EXE_LINKER_FLAGS " -m32")
...
"
4. call "conan build ." and inspect build/Release/conan_toolchain.cmake
"
message(STATUS "Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)")
set(CMAKE_POSITION_INDEPENDENT_CODE ON CACHE BOOL "Position independent code")

 

string(APPEND CONAN_CXX_FLAGS " -m64")
string(APPEND CONAN_C_FLAGS " -m64")
string(APPEND CONAN_SHARED_LINKER_FLAGS " -m64")
string(APPEND CONAN_EXE_LINKER_FLAGS " -m64")
"
**Here I would conan build to not overwrite the cross building configuration. From my experience under conan 1.X, conan install sets the settings, and conan build builds against those settings, it doesn't overwrite them**


**To reproduce Issue 2.** 
1. Add a new profile for 32bit architecture called 'linux-x86' (see environment details)
2. Create new cmake project using "conan new cmake_lib -d name=hello -d version=1.0"
3. call "conan install . --profile linux_x86" 
4. call "conan build . --profile linux_x86"
5. inspect the produced library using "readelf -a ./build/Release/libhello.a | less"
"
File: ./build/Release/libhello.a(hello.cpp.o)
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file
"
6. call "conan install ."
7. call "conan build ."
8. inspect the produced library using "readelf -a ./build/Release/libhello.a | less"
File: ./build/Release/libhello.a(hello.cpp.o)
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file
**Here I would expect the library to be ELF64, not ELF32, it seems to have become stuck from the initial configuration called using conan, even though the conan_toolchain.cmake updates appropriately**
9. delete "build" directory
10. call "conan install ."
11. call "conan build ."
12. inspect the produced library using "readelf -a ./build/Release/libhello.a | less"
File: ./build/Release/libhello.a(hello.cpp.o)
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)



### Logs

_No response_
user: nojgosu
issue_13577: state: open
title: [bug] Autoconf failures in test_other_client_can_link_autotools, test_autotools_lib_template tests
body: ### Environment details

* Operating System+version: Guix System
* Compiler+version: GCC 10.3.0
* Conan version: 2.0.2
* Python version: 3.9.9.


### Steps to reproduce

1. Run the test suite on GNU Guix.


### Logs

```
=================================== FAILURES ===================================
_____________________ test_other_client_can_link_autotools _____________________
[gw3] linux -- Python 3.9.9 /gnu/store/slsh0qjv5j68xda2bb6h8gsxwyi1j25a-python-wrapper-3.9.9/bin/python

transitive_shared_client = <conans.test.utils.tools.TestClient object at 0x7fffee5bfd90>

    @pytest.mark.tool("autotools")
    @pytest.mark.skipif(platform.system() == "Windows", reason="Autotools needed")
    def test_other_client_can_link_autotools(transitive_shared_client):
        client = transitive_shared_client
        # https://github.com/conan-io/conan/issues/13000
        # This failed, because of rpath link in Linux
        client = TestClient(servers=client.servers, inputs=["admin", "password"], path_with_spaces=False)
        client.run("new autotools_exe -d name=app -d version=0.1 -d requires=chat/0.1")
>       client.run("create . -o chat/*:shared=True -o hello/*:shared=True")

conans/test/functional/toolchains/cmake/test_shared_cmake.py:84: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:522: in run
    return self._run_cli(command_line, assert_error=assert_error)
conans/test/utils/tools.py:497: in _run_cli
    self._handle_cli_result(command_line, assert_error=assert_error, error=error, trace=trace)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <conans.test.utils.tools.TestClient object at 0x7fffee38c640>
command = 'create . -o chat/*:shared=True -o hello/*:shared=True'
assert_error = False, error = 1
trace = 'Traceback (most recent call last):\n  File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/errors.py", line 51, in c...ethod: app/0.1: Error in build() method, line 44\n\tautotools.configure()\n\tConanException: Error 1 while executing\n'

    def _handle_cli_result(self, command, assert_error, error, trace=None):
        if (assert_error and not error) or (not assert_error and error):
            if assert_error:
                msg = " Command succeeded (failure expected): "
            else:
                msg = " Command failed (unexpectedly): "
            exc_message = "\n{header}\n{cmd}\n{output_header}\n{output}\n".format(
                header='{:=^80}'.format(msg),
                output_header='{:=^80}'.format(" Output: "),
                cmd=command,
                output=str(self.stderr) + str(self.stdout) + "\n" + str(self.out)
            )
            if trace:
                exc_message += '{:=^80}'.format(" Traceback: ") + f"\n{trace}"
>           raise Exception(exc_message)
E           Exception: 
E           ======================== Command failed (unexpectedly): ========================
E           create . -o chat/*:shared=True -o hello/*:shared=True
E           =================================== Output: ====================================
E           
E           ======== Exporting recipe to the cache ========
E           app/0.1: Exporting package recipe: /tmp/guix-build-conan-2.0.2.drv-0/tmpzyq9j7x7conans/pathwithoutspaces/conanfile.py
E           app/0.1: Copied 1 '.py' file: conanfile.py
E           app/0.1: Copied 1 '.ac' file: configure.ac
E           app/0.1: Copied 2 '.am' files: Makefile.am, Makefile.am
E           app/0.1: Copied 2 '.cpp' files: app.cpp, main.cpp
E           app/0.1: Copied 1 '.h' file: app.h
E           app/0.1: Exported to cache folder: /tmp/guix-build-conan-2.0.2.drv-0/tmpcpziw2ihconans/pathwithoutspaces/.conan2/p/app446024162abfa/e
E           app/0.1: Exported: app/0.1#2af079693e96408ea7495ed0d947374f (2023-03-30 17:55:07 UTC)
E           
E           ======== Input profiles ========
E           Profile host:
E           [settings]
E           arch=x86_64
E           build_type=Release
E           compiler=gcc
E           compiler.libcxx=libstdc++11
E           compiler.version=8
E           os=Linux
E           [options]
E           chat/*:shared=True
E           hello/*:shared=True
E           
E           Profile build:
E           [settings]
E           arch=x86_64
E           build_type=Release
E           compiler=gcc
E           compiler.libcxx=libstdc++11
E           compiler.version=8
E           os=Linux
E           
E           
E           ======== Computing dependency graph ========
E           chat/0.1: Not found in local cache, looking in remotes...
E           chat/0.1: Checking remote: default
E           chat/0.1: Downloaded recipe revision 5fb41ddcc6cd7381399f488f1dff7123
E           hello/0.1: Not found in local cache, looking in remotes...
E           hello/0.1: Checking remote: default
E           hello/0.1: Downloaded recipe revision 234bf56e60ac669e4bc4897583f19c83
E           Graph root
E               cli
E           Requirements
E               app/0.1#2af079693e96408ea7495ed0d947374f - Cache
E               chat/0.1#5fb41ddcc6cd7381399f488f1dff7123 - Downloaded (default)
E               hello/0.1#234bf56e60ac669e4bc4897583f19c83 - Downloaded (default)
E           
E           ======== Computing necessary packages ========
E           app/0.1: Forced build from source
E           Requirements
E               app/0.1#2af079693e96408ea7495ed0d947374f:9c08b63a45d6bbf93294ed2a469e3fc2e202d11a - Build
E               chat/0.1#5fb41ddcc6cd7381399f488f1dff7123:0eaf9738e59c9117fa4ff046132a23272c3f160a#4528e3b761a08147fd3a73c7c21a343a - Download (default)
E               hello/0.1#234bf56e60ac669e4bc4897583f19c83:0645178f9911c96e0f11d63b451090c571726042#da9d0f9f1d353f770ccf333829dd1564 - Download (default)
E           
E           ======== Installing packages ========
E           
E           -------- Downloading 2 packages --------
E           hello/0.1: Retrieving package 0645178f9911c96e0f11d63b451090c571726042 from remote 'default' 
E           Decompressing conan_package.tgz
E           hello/0.1: Package installed 0645178f9911c96e0f11d63b451090c571726042
E           hello/0.1: Downloaded package revision da9d0f9f1d353f770ccf333829dd1564
E           chat/0.1: Retrieving package 0eaf9738e59c9117fa4ff046132a23272c3f160a from remote 'default' 
E           Decompressing conan_package.tgz
E           chat/0.1: Package installed 0eaf9738e59c9117fa4ff046132a23272c3f160a
E           chat/0.1: Downloaded package revision 4528e3b761a08147fd3a73c7c21a343a
E           
E           -------- Installing package app/0.1 (3 of 3) --------
E           app/0.1: Building from source
E           app/0.1: Package app/0.1:9c08b63a45d6bbf93294ed2a469e3fc2e202d11a
E           app/0.1: Copying sources to build folder
E           app/0.1: Building your package in /tmp/guix-build-conan-2.0.2.drv-0/tmpcpziw2ihconans/pathwithoutspaces/.conan2/p/t/appa1014ece93539/b
E           app/0.1: Calling generate()
E           app/0.1: Generators folder: /tmp/guix-build-conan-2.0.2.drv-0/tmpcpziw2ihconans/pathwithoutspaces/.conan2/p/t/appa1014ece93539/b/build-release/conan
E           app/0.1: Generating aggregated env files
E           app/0.1: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
E           app/0.1: Calling build()
E           app/0.1: RUN: autoreconf --force --install
E           libtoolize: putting auxiliary files in '.'.
E           libtoolize: copying file './ltmain.sh'
E           libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
E           libtoolize: and rerunning libtoolize and aclocal.
E           libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
E           patch-shebang: configure: changing `/bin/sh' to `/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh'
E           configure.ac:5: installing './ar-lib'
E           configure.ac:5: installing './compile'
E           configure.ac:6: installing './config.guess'
E           configure.ac:6: installing './config.sub'
E           configure.ac:3: installing './install-sh'
E           configure.ac:3: installing './missing'
E           src/Makefile.am: installing './depcomp'
E           
E           app/0.1: Calling:
E            > "/tmp/guix-build-conan-2.0.2.drv-0/tmpcpziw2ihconans/pathwithoutspaces/.conan2/p/t/appa1014ece93539/b/./configure" --prefix=/ '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' 
E           app/0.1: RUN: "/tmp/guix-build-conan-2.0.2.drv-0/tmpcpziw2ihconans/pathwithoutspaces/.conan2/p/t/appa1014ece93539/b/./configure" --prefix=/ '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' 
E           checking for a BSD-compatible install... /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/install -c
E           checking whether build environment is sane... yes
E           checking for a thread-safe mkdir -p... /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/mkdir -p
E           checking for gawk... gawk
E           checking whether make sets $(MAKE)... no
E           checking whether make supports nested variables... yes
E           checking for g++... g++
E           checking whether the C++ compiler works... yes
E           checking for C++ compiler default output file name... a.out
E           checking for suffix of executables... 
E           checking whether we are cross compiling... configure: error: in `/tmp/guix-build-conan-2.0.2.drv-0/tmpcpziw2ihconans/pathwithoutspaces/.conan2/p/t/appa1014ece93539/b/build-release':
E           configure: error: cannot run C++ compiled programs.
E           If you meant to cross compile, use `--host'.
E           See `config.log' for more details
E           
E           app/0.1: ERROR: 
E           Package '9c08b63a45d6bbf93294ed2a469e3fc2e202d11a' build failed
E           app/0.1: WARN: Build folder /tmp/guix-build-conan-2.0.2.drv-0/tmpcpziw2ihconans/pathwithoutspaces/.conan2/p/t/appa1014ece93539/b/build-release
E           *********************************************************
E           Recipe 'app/0.1' cannot build its binary
E           It is possible that this recipe is not Conan 2.0 ready
E           If the recipe comes from ConanCenter check: https://conan.io/cci-v2.html
E           If it is your recipe, check if it is updated to 2.0
E           *********************************************************
E           
E           ERROR: app/0.1: Error in build() method, line 44
E               autotools.configure()
E               ConanException: Error 1 while executing
E           
E           
E           ================================== Traceback: ==================================
E           Traceback (most recent call last):
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/errors.py", line 51, in conanfile_exception_formatter
E               yield
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/conanfile/build.py", line 13, in run_build_method
E               conanfile.build()
E             File "/tmp/guix-build-conan-2.0.2.drv-0/tmpcpziw2ihconans/pathwithoutspaces/.conan2/p/app446024162abfa/e/conanfile.py", line 44, in build
E               autotools.configure()
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/tools/gnu/autotools.py", line 59, in configure
E               self._conanfile.run(cmd)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/model/conan_file.py", line 318, in run
E               raise ConanException("Error %d while executing" % retcode)
E           conans.errors.ConanException: Error 1 while executing
E           
E           During handling of the above exception, another exception occurred:
E           
E           Traceback (most recent call last):
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/test/utils/tools.py", line 486, in _run_cli
E               command.run(args)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/cli/cli.py", line 171, in run
E               command.run(self._conan_api, self._commands[command_argument].parser, args[0][1:])
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/cli/command.py", line 156, in run
E               info = self._method(conan_api, parser, *args)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/cli/commands/create.py", line 83, in create
E               conan_api.install.install_binaries(deps_graph=deps_graph, remotes=remotes)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/api/subapi/install.py", line 22, in install_binaries
E               installer.install(deps_graph, remotes)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/installer.py", line 252, in install
E               self._handle_package(package, install_reference, None, handled_count, package_count)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/installer.py", line 315, in _handle_package
E               self._handle_node_build(package, package_layout)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/installer.py", line 385, in _handle_node_build
E               pref = builder.build_package(node, pkg_layout)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/installer.py", line 159, in build_package
E               raise exc
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/installer.py", line 152, in build_package
E               self._build(conanfile, pref)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/installer.py", line 101, in _build
E               raise exc
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/installer.py", line 94, in _build
E               run_build_method(conanfile, self._hook_manager)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/conanfile/build.py", line 16, in run_build_method
E               raise
E             File "/gnu/store/65i3nhcwmz0p8rqbg48gaavyky4g4hwk-python-3.9.9/lib/python3.9/contextlib.py", line 137, in __exit__
E               self.gen.throw(typ, value, traceback)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/errors.py", line 66, in conanfile_exception_formatter
E               _raise_conanfile_exc(exc)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/errors.py", line 48, in _raise_conanfile_exc
E               raise ConanExceptionInUserConanfileMethod(m)
E           conans.errors.ConanExceptionInUserConanfileMethod: app/0.1: Error in build() method, line 44
E               autotools.configure()
E               ConanException: Error 1 while executing

conans/test/utils/tools.py:563: Exception
_________________________ test_autotools_lib_template __________________________
[gw18] linux -- Python 3.9.9 /gnu/store/slsh0qjv5j68xda2bb6h8gsxwyi1j25a-python-wrapper-3.9.9/bin/python

    @pytest.mark.skipif(platform.system() not in ["Linux", "Darwin"], reason="Requires Autotools")
    @pytest.mark.tool("autotools")
    def test_autotools_lib_template():
        client = TestClient(path_with_spaces=False)
        client.run("new autotools_lib -d name=hello -d version=0.1")
    
        # Local flow works
        client.run("install .")
        client.run("build .")
    
        client.run("export-pkg .")
        package_id = re.search(r"Packaging to (\S+)", str(client.out)).group(1)
        ref = RecipeReference.loads("hello/0.1")
        pref = client.get_latest_package_reference(ref, package_id)
        package_folder = client.get_latest_pkg_layout(pref).package()
        assert os.path.exists(os.path.join(package_folder, "include", "hello.h"))
        assert os.path.exists(os.path.join(package_folder, "lib", "libhello.a"))
    
        # Local flow for shared library works
        client.save({}, clean_first=True)
        client.run("new autotools_lib -d name=hello -d version=0.1")
        client.run("install . -o hello/*:shared=True")
        client.run("build . -o hello/*:shared=True")
>       client.run("export-pkg . -o hello/*:shared=True")

conans/test/functional/toolchains/gnu/test_v2_autotools_template.py:36: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:522: in run
    return self._run_cli(command_line, assert_error=assert_error)
conans/test/utils/tools.py:497: in _run_cli
    self._handle_cli_result(command_line, assert_error=assert_error, error=error, trace=trace)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <conans.test.utils.tools.TestClient object at 0x7fffee892970>
command = 'export-pkg . -o hello/*:shared=True', assert_error = False, error = 1
trace = 'Traceback (most recent call last):\n  File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/errors.py", line 51, in c...(test package): Error in build() method, line 20\n\tautotools.configure()\n\tConanException: Error 1 while executing\n'

    def _handle_cli_result(self, command, assert_error, error, trace=None):
        if (assert_error and not error) or (not assert_error and error):
            if assert_error:
                msg = " Command succeeded (failure expected): "
            else:
                msg = " Command failed (unexpectedly): "
            exc_message = "\n{header}\n{cmd}\n{output_header}\n{output}\n".format(
                header='{:=^80}'.format(msg),
                output_header='{:=^80}'.format(" Output: "),
                cmd=command,
                output=str(self.stderr) + str(self.stdout) + "\n" + str(self.out)
            )
            if trace:
                exc_message += '{:=^80}'.format(" Traceback: ") + f"\n{trace}"
>           raise Exception(exc_message)
E           Exception: 
E           ======================== Command failed (unexpectedly): ========================
E           export-pkg . -o hello/*:shared=True
E           =================================== Output: ====================================
E           
E           ======== Exporting recipe to the cache ========
E           hello/0.1: Exporting package recipe: /tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/conanfile.py
E           hello/0.1: Copied 1 '.py' file: conanfile.py
E           hello/0.1: Copied 1 '.ac' file: configure.ac
E           hello/0.1: Copied 2 '.am' files: Makefile.am, Makefile.am
E           hello/0.1: Copied 1 '.cpp' file: hello.cpp
E           hello/0.1: Copied 1 '.h' file: hello.h
E           hello/0.1: Copied 1 '.in' file: Makefile.in
E           hello/0.1: Exported to cache folder: /tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/hello199849b3e6c54/e
E           hello/0.1: Exported: hello/0.1#5cfde34132e33dadbbd2f335ec9b4d7d (2023-03-30 17:55:32 UTC)
E           
E           ======== Computing dependency graph ========
E           Graph root
E               conanfile.py (hello/0.1): /tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/conanfile.py
E           
E           ======== Computing necessary packages ========
E           
E           ======== Installing packages ========
E           conanfile.py (hello/0.1): Calling generate()
E           conanfile.py (hello/0.1): Generators folder: /tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/build-release/conan
E           conanfile.py (hello/0.1): Generating aggregated env files
E           conanfile.py (hello/0.1): Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
E           
E           ======== Exporting recipe and package to the cache ========
E           conanfile.py (hello/0.1): Exporting binary from user folder to Conan cache
E           conanfile.py (hello/0.1): Packaging to 0645178f9911c96e0f11d63b451090c571726042
E           conanfile.py (hello/0.1): Generating the package
E           conanfile.py (hello/0.1): Temporary package folder /tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/t/hellof713b93beebfa/p
E           conanfile.py (hello/0.1): Calling package()
E           conanfile.py (hello/0.1): RUN: make install DESTDIR=/tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/t/hellof713b93beebfa/p -j24
E           Making install in src
E           make[1]: Entering directory '/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/build-release/src'
E           make[2]: Entering directory '/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/build-release/src'
E            /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/mkdir -p '/tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/t/hellof713b93beebfa/p//lib'
E            /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/mkdir -p '/tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/t/hellof713b93beebfa/p//include'
E            /gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh ../libtool   --mode=install /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/install -c   libhello.la '/tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/t/hellof713b93beebfa/p//lib'
E            /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/install -c -m 644 /tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/./src/hello.h '/tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/t/hellof713b93beebfa/p//include'
E           libtool: install: /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/install -c .libs/libhello.so.0.0.0 /tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/t/hellof713b93beebfa/p//lib/libhello.so.0.0.0
E           libtool: install: (cd /tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/t/hellof713b93beebfa/p//lib && { ln -s -f libhello.so.0.0.0 libhello.so.0 || { rm -f libhello.so.0 && ln -s libhello.so.0.0.0 libhello.so.0; }; })
E           libtool: install: (cd /tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/t/hellof713b93beebfa/p//lib && { ln -s -f libhello.so.0.0.0 libhello.so || { rm -f libhello.so && ln -s libhello.so.0.0.0 libhello.so; }; })
E           libtool: install: /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/install -c .libs/libhello.lai /tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/t/hellof713b93beebfa/p//lib/libhello.la
E           make[2]: Leaving directory '/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/build-release/src'
E           make[1]: Leaving directory '/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/build-release/src'
E           make[1]: Entering directory '/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/build-release'
E           make[2]: Entering directory '/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/build-release'
E           make[2]: Nothing to be done for 'install-exec-am'.
E           make[2]: Nothing to be done for 'install-data-am'.
E           make[2]: Leaving directory '/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/build-release'
E           make[1]: Leaving directory '/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/build-release'
E           libtool: warning: remember to run 'libtool --finish //lib'
E           
E           conanfile.py (hello/0.1): package(): Packaged 2 '.0' files: libhello.so.0.0.0, libhello.so.0
E           conanfile.py (hello/0.1): package(): Packaged 1 '.so' file: libhello.so
E           conanfile.py (hello/0.1): package(): Packaged 1 '.la' file: libhello.la
E           conanfile.py (hello/0.1): package(): Packaged 1 '.h' file: hello.h
E           conanfile.py (hello/0.1): Created package revision a509699490ff2805ab2df0c9a331bea9
E           conanfile.py (hello/0.1): Package '0645178f9911c96e0f11d63b451090c571726042' created
E           conanfile.py (hello/0.1): Full package reference: hello/0.1#5cfde34132e33dadbbd2f335ec9b4d7d:0645178f9911c96e0f11d63b451090c571726042#a509699490ff2805ab2df0c9a331bea9
E           conanfile.py (hello/0.1): Package folder /tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/hello3cf69c3500cf8/p
E           conanfile.py (hello/0.1): Exported package binary
E           
E           ======== Launching test_package ========
E           
E           ======== Computing dependency graph ========
E           Graph root
E               hello/0.1 (test package): /tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/test_package/conanfile.py
E           Requirements
E               hello/0.1#5cfde34132e33dadbbd2f335ec9b4d7d - Cache
E           
E           ======== Computing necessary packages ========
E           Requirements
E               hello/0.1#5cfde34132e33dadbbd2f335ec9b4d7d:0645178f9911c96e0f11d63b451090c571726042#a509699490ff2805ab2df0c9a331bea9 - Cache
E           
E           ======== Installing packages ========
E           hello/0.1: Already installed! (1 of 1)
E           
E           ======== Testing the package ========
E           Removing previously existing 'test_package' build folder: /tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/test_package/build-release
E           hello/0.1 (test package): Test package build: build-release
E           hello/0.1 (test package): Test package build folder: /tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/test_package/build-release
E           hello/0.1 (test package): Writing generators to /tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/test_package/build-release/conan
E           hello/0.1 (test package): Generator 'AutotoolsToolchain' calling 'generate()'
E           hello/0.1 (test package): Generator 'AutotoolsDeps' calling 'generate()'
E           hello/0.1 (test package): Generating aggregated env files
E           hello/0.1 (test package): Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
E           
E           ======== Testing the package: Building ========
E           hello/0.1 (test package): Calling build()
E           hello/0.1 (test package): RUN: autoreconf --force --install
E           patch-shebang: configure: changing `/bin/sh' to `/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh'
E           
E           hello/0.1 (test package): Calling:
E            > "/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/test_package/./configure" --prefix=/ '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' 
E           hello/0.1 (test package): RUN: "/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/test_package/./configure" --prefix=/ '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' 
E           checking for a BSD-compatible install... /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/install -c
E           checking whether build environment is sane... yes
E           checking for a thread-safe mkdir -p... /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/mkdir -p
E           checking for gawk... gawk
E           checking whether make sets $(MAKE)... no
E           checking whether make supports nested variables... yes
E           checking for g++... g++
E           checking whether the C++ compiler works... yes
E           checking for C++ compiler default output file name... a.out
E           checking for suffix of executables... 
E           checking whether we are cross compiling... configure: error: in `/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/test_package/build-release':
E           configure: error: cannot run C++ compiled programs.
E           If you meant to cross compile, use `--host'.
E           See `config.log' for more details
E           
E           *********************************************************
E           Recipe 'hello/0.1 (test package)' cannot build its binary
E           It is possible that this recipe is not Conan 2.0 ready
E           If the recipe comes from ConanCenter check: https://conan.io/cci-v2.html
E           If it is your recipe, check if it is updated to 2.0
E           *********************************************************
E           
E           ERROR: hello/0.1 (test package): Error in build() method, line 20
E               autotools.configure()
E               ConanException: Error 1 while executing
E           
E           
E           ================================== Traceback: ==================================
E           Traceback (most recent call last):
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/errors.py", line 51, in conanfile_exception_formatter
E               yield
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/conanfile/build.py", line 13, in run_build_method
E               conanfile.build()
E             File "/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/test_package/conanfile.py", line 20, in build
E               autotools.configure()
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/tools/gnu/autotools.py", line 59, in configure
E               self._conanfile.run(cmd)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/model/conan_file.py", line 318, in run
E               raise ConanException("Error %d while executing" % retcode)
E           conans.errors.ConanException: Error 1 while executing
E           
E           During handling of the above exception, another exception occurred:
E           
E           Traceback (most recent call last):
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/test/utils/tools.py", line 486, in _run_cli
E               command.run(args)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/cli/cli.py", line 171, in run
E               command.run(self._conan_api, self._commands[command_argument].parser, args[0][1:])
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/cli/command.py", line 156, in run
E               info = self._method(conan_api, parser, *args)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/cli/commands/export_pkg.py", line 95, in export_pkg
E               deps_graph = run_test(conan_api, test_conanfile_path, ref, profile_host, profile_build,
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/cli/commands/test.py", line 70, in run_test
E               test_package(conan_api, deps_graph, path, tested_python_requires)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/cli/commands/create.py", line 140, in test_package
E               conan_api.local.build(conanfile)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conan/api/subapi/local.py", line 97, in build
E               run_build_method(conanfile, app.hook_manager)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/client/conanfile/build.py", line 16, in run_build_method
E               raise
E             File "/gnu/store/65i3nhcwmz0p8rqbg48gaavyky4g4hwk-python-3.9.9/lib/python3.9/contextlib.py", line 137, in __exit__
E               self.gen.throw(typ, value, traceback)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/errors.py", line 66, in conanfile_exception_formatter
E               _raise_conanfile_exc(exc)
E             File "/tmp/guix-build-conan-2.0.2.drv-0/source/conans/errors.py", line 48, in _raise_conanfile_exc
E               raise ConanExceptionInUserConanfileMethod(m)
E           conans.errors.ConanExceptionInUserConanfileMethod: hello/0.1 (test package): Error in build() method, line 20
E               autotools.configure()
E               ConanException: Error 1 while executing

conans/test/utils/tools.py:563: Exception
=============================== warnings summary ===============================
conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
  /tmp/guix-build-conan-2.0.2.drv-0/tmpdi5m85flconans/path with spaces/conanfile.py:12: DeprecationWarning: invalid escape sequence \i
    env = deps.environment

conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
  /tmp/guix-build-conan-2.0.2.drv-0/tmpdi5m85flconans/path with spaces/conanfile.py:15: DeprecationWarning: invalid escape sequence \l
    env.remove("LDFLAGS", "dep2_shared_link_flag")

conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
  /tmp/guix-build-conan-2.0.2.drv-0/tmp2dn4nkiyconans/path with spaces/.conan2/p/dep1c5db8abbaa6d4/e/conanfile.py:12: DeprecationWarning: invalid escape sequence \i
    self.cpp_info.includedirs.append("other\include\path\{}".format(self.name))

conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
  /tmp/guix-build-conan-2.0.2.drv-0/tmp2dn4nkiyconans/path with spaces/.conan2/p/dep1c5db8abbaa6d4/e/conanfile.py:15: DeprecationWarning: invalid escape sequence \l
    self.cpp_info.libdirs.append("one\lib\path\{}".format(self.name))

conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
  /tmp/guix-build-conan-2.0.2.drv-0/tmp2dn4nkiyconans/path with spaces/.conan2/p/dep24bfd446af2d8a/e/conanfile.py:12: DeprecationWarning: invalid escape sequence \i
    self.cpp_info.includedirs.append("other\include\path\{}".format(self.name))

conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
conans/test/integration/toolchains/gnu/test_autotoolsdeps.py::test_cpp_info_aggregation
  /tmp/guix-build-conan-2.0.2.drv-0/tmp2dn4nkiyconans/path with spaces/.conan2/p/dep24bfd446af2d8a/e/conanfile.py:15: DeprecationWarning: invalid escape sequence \l
    self.cpp_info.libdirs.append("one\lib\path\{}".format(self.name))

-- Docs: https://docs.pytest.org/en/stable/warnings.html
=========================== short test summary info ============================
FAILED conans/test/functional/toolchains/cmake/test_shared_cmake.py::test_other_client_can_link_autotools
FAILED conans/test/functional/toolchains/gnu/test_v2_autotools_template.py::test_autotools_lib_template
= 2 failed, 3019 passed, 321 skipped, 165 xfailed, 9 xpassed, 12 warnings in 121.14s (0:02:01) =
```

Attached is a config.log from one of the above failure.  The config error appears to be:
```
configure:2738: g++ -o conftest  -m64 -O3  -DNDEBUG -I/tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/hello3cf69c3500cf8/p/include  -m64 -L/tmp/guix-build-conan-2.0.2.drv-0/tmpv4txz0o6conans/pathwithoutspaces/.conan2/p/hello3cf69c3500cf8/p/lib conftest.cpp  -lhello >&5
configure:2742: $? = 0
configure:2749: ./conftest
[config.log](https://github.com/conan-io/conan/files/11114657/config.log)

./conftest: error while loading shared libraries: libhello.so.0: cannot open shared object file: No such file or directory
configure:2753: $? = 127
configure:2760: error: in `/tmp/guix-build-conan-2.0.2.drv-0/tmpguj34la7conans/pathwithoutspaces/test_package/build-release':
configure:2762: error: cannot run C++ compiled programs.
```

The environment contains:
```
autoconf-wrapper@2.69 automake@1.16.3 cmake@3.25.1 coreutils@8.32 git-minimal@2.39.2
+ libtool@2.4.6 meson@0.60.3 ninja@1.10.2 pkg-config@0.29.2 python-bottle@0.12.23 python-colorama@0.4.4
+ python-dateutil@2.8.2 python-distro@1.6.0 python-fasteners@0.15 python-future@0.18.2 python-jinja2@3.1.1
+ python-mock@3.0.5 python-node-semver@0.8.1 python-parameterized@0.7.4 python-patch-ng@1.17.4
+ python-pluginbase@1.0.1 python-pygments@2.12.0 python-pyjwt@2.6.0 python-pytest-xdist@2.1.0
+ python-pytest@6.2.5 python-pyyaml@5.4.1 python-requests@2.28.1 python-six@1.16.0 python-tqdm@4.64.1
+ python-urllib3@1.26.9 python-webtest@2.0.35 which@2.21
```
user: Apteryks
issue_13575: state: open
title: [bug] 'main __GNUC__9' hard-coded in _check_binary test
body: ### Environment details

* Operating System+version: Guix System
* Compiler+version: GCC 10.3.0
* Conan version: 2.0.2
* Python version: 3.9.9


### Steps to reproduce

1. Run the test suite an a system using GCC != 9, e.g. GCC 10.

### Logs

```
=================================== FAILURES ===================================
_____________ MesonToolchainTest.test_definition_of_global_options _____________
[gw3] linux -- Python 3.9.9 /gnu/store/slsh0qjv5j68xda2bb6h8gsxwyi1j25a-python-wrapper-3.9.9/bin/python

self = <conans.test.functional.toolchains.meson.test_meson.MesonToolchainTest testMethod=test_definition_o

    def test_definition_of_global_options(self):
        hello_h = gen_function_h(name="hello")
        hello_cpp = gen_function_cpp(name="hello", preprocessor=["STRING_DEFINITION"])
        app = gen_function_cpp(name="main", includes=["hello"], calls=["hello"])
    
        self.t.save({"conanfile.py": self._conanfile_py,
                     "meson.build": self._meson_build,
                     "meson_options.txt": self._meson_options_txt,
                     "hello.h": hello_h,
                     "hello.cpp": hello_cpp,
                     "main.cpp": app})
    
        self.t.run("install .")
    
        content = self.t.load(os.path.join("build", "gen_folder", "conan_meson_native.ini"))
    
        self.assertIn("[project options]", content)
        self.assertIn("STRING_DEFINITION = 'Text'", content)
        self.assertIn("TRUE_DEFINITION = true", content)
        self.assertIn("FALSE_DEFINITION = false", content)
        self.assertIn("INT_DEFINITION = 42", content)
        self.assertIn("ARRAY_DEFINITION = ['Text1', 'Text2']", content)
    
        self.assertIn("[built-in options]", content)
        self.assertIn("buildtype = 'release'", content)
    
        self.t.run("build .")
        self.t.run_command(os.path.join("build", "demo"))
    
        self.assertIn("hello: Release!", self.t.out)
        self.assertIn("STRING_DEFINITION: Text", self.t.out)
    
        self.assertIn("[properties]", content)
        self.assertNotIn("needs_exe_wrapper", content)
    
>       self._check_binary()

conans/test/functional/toolchains/meson/test_meson.py:107: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/functional/toolchains/meson/_base.py:36: in _check_binary
    self.assertIn("main __GNUC__9", self.t.out)
E   AssertionError: 'main __GNUC__9' not found in 'main: Release!\n  main __x86_64__ defined\n  main _GLIBn  hello __x86_64__ defined\n  hello _GLIBCXX_USE_CXX11_ABI 1\n  hello __cplusplus201402\n  hello __GNUC__
```

As the comment in the test says: # FIXME: Some values are hardcoded to match the CI setup
user: Apteryks
issue_13570: state: open
title: [bug] `self.*_path` in `CMakeToolchain` variables causes `CMakePresets` generation failure
body: ### Environment details

* Operating System+version: Windows 11 22621.1413
* Conan version: 2.0.2
* Python version: 3.11.1

In `ConanFile`, `self.package_path` and friends are not plain strings. Consequently, if used as `CMakeToolchain` variables, the presets generator will crash because it does not know how to turn a `WindowsPath`/`UnixPath` into JSON.
This can be worked around with a simple call to `str()`, but it doesn't seem to be documented anywhere (and feels like a bug).

### Steps to reproduce

1. Create a `foo/bar` recipe
2. Define `generate()` as follows:
```
    def generate(self):
        tc = CMakeToolchain(self)
        tc.cache_variables["CMAKE_INSTALL_PREFIX"] = self.package_path
        tc.generate()
 ```
 3.  `conan create [...]` witll fail when generating `CMakePresets.json`, because `self.package_path` is a `pathlib` path type (not JSON serializable).
 

### Logs

_No response_
user: sykhro
issue_13565: state: open
title: [question] What is Conan 2's story for deploying cross compiled binaries to a remote machine?
body: ### What is your question?

I'm using Conan 2.0.2 to cross compile a collection of 1st and 3rd party code. The target hardware is not hardware on which we can directly do development, hence the requirement to cross compile everything. Conan 2 has a clear story for how cross compilation works but I'm struggling to figure out the best way to get those compiled shared libraries and executables onto our target hardware. 

I had a talk with @prince-chrismc after which we determined that [Deployers](https://docs.conan.io/2.0/reference/extensions/deployers.html) are not the right solution. If not Deployers then how do you recommend I copy these binaries to the target hardware? Am I best off doing something like using rsync in a shell script to copy the required files over or do more sophisticated solutions exist?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ChrisThrasher
issue_13560: state: open
title: [bug] conan 2.x: linking against a shared lib with private shared dependencies fails on Linux (again)
body: ### Environment details

* Operating System+version: Ubuntu 22.04
* Compiler+version: gcc 12.1.0
* Conan version: 2.0.2
* Python version: 3.10.6


### Steps to reproduce

`conan install --requires="libzippp/6.0-1.9.2" -o "*:shared=True" -b missing`

### Logs

<details><summary>build log</summary>

```
libzippp/6.0-1.9.2: Building from source
libzippp/6.0-1.9.2: Package libzippp/6.0-1.9.2:ee3488ab65102991abf5b636e39de538d8d3e7ab
libzippp/6.0-1.9.2: Copying sources to build folder
libzippp/6.0-1.9.2: Building your package in /home/spaceim/.conan2/p/t/libzic30b1ebec828d/b
libzippp/6.0-1.9.2: Calling generate()
libzippp/6.0-1.9.2: Generators folder: /home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/build/Release/generators
libzippp/6.0-1.9.2: CMakeToolchain generated: conan_toolchain.cmake
libzippp/6.0-1.9.2: CMakeToolchain generated: CMakePresets.json
libzippp/6.0-1.9.2: CMakeToolchain generated: ../../../src/CMakeUserPresets.json
libzippp/6.0-1.9.2: Generating aggregated env files
libzippp/6.0-1.9.2: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
libzippp/6.0-1.9.2: Calling build()
libzippp/6.0-1.9.2: Running CMake.configure()
libzippp/6.0-1.9.2: RUN: cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/spaceim/.conan2/p/t/libzic30b1ebec828d/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src"
-- Using Conan toolchain: /home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/build/Release/generators/conan_toolchain.cmake
-- Conan toolchain: Setting BUILD_SHARED_LIBS = ON
-- The C compiler identification is GNU 12.1.0
-- The CXX compiler identification is GNU 12.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc-12 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++-12 - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: Component target declared 'libzip::zip'
-- Conan: Target declared 'ZLIB::ZLIB'
-- Conan: Target declared 'BZip2::BZip2'
-- Conan: Including build module from '/home/spaceim/.conan2/p/bzip2b4101dd1d9e37/p/lib/cmake/conan-official-bzip2-variables.cmake'
-- Conan: Target declared 'LibLZMA::LibLZMA'
-- Conan: Including build module from '/home/spaceim/.conan2/p/xz_utae9210766e49b/p/lib/cmake/conan-official-xz_utils-variables.cmake'
-- Conan: Component target declared 'zstd::libzstd_shared'
-- Conan: Component target declared 'OpenSSL::Crypto'
-- Conan: Component target declared 'OpenSSL::SSL'
-- Conan: Target declared 'openssl::openssl'
-- Conan: Including build module from '/home/spaceim/.conan2/p/opens3b56123e737a3/p/lib/cmake/conan-official-openssl-variables.cmake'
-- Configuring done (5.2s)
-- Generating done (0.0s)
-- Build files have been written to: /home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/build/Release

libzippp/6.0-1.9.2: Running CMake.build()
libzippp/6.0-1.9.2: RUN: cmake --build "/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/build/Release" -- -j8
[1/4] Building CXX object CMakeFiles/libzippp.dir/src/libzippp.cpp.o
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/src/libzippp.cpp: In function ‘void defaultErrorHandler(const std::string&, const std::string&, int, int)’:
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/src/libzippp.cpp:127:37: warning: unused parameter ‘zip_error_code’ [-Wunused-parameter]
  127 |                                 int zip_error_code,
      |                                 ~~~~^~~~~~~~~~~~~~
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/src/libzippp.cpp:128:37: warning: unused parameter ‘system_error_code’ [-Wunused-parameter]
  128 |                                 int system_error_code)
      |                                 ~~~~^~~~~~~~~~~~~~~~~
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/src/libzippp.cpp: In function ‘void progress_callback(zip*, double, void*)’:
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/src/libzippp.cpp:350:29: warning: unused parameter ‘archive’ [-Wunused-parameter]
  350 | void progress_callback(zip* archive, double progression, void* ud) {
      |                        ~~~~~^~~~~~~
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/src/libzippp.cpp: In function ‘int progress_cancel_callback(zip*, void*)’:
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/src/libzippp.cpp:359:35: warning: unused parameter ‘archive’ [-Wunused-parameter]
  359 | int progress_cancel_callback(zip *archive, void *ud) {
      |                              ~~~~~^~~~~~~
[3/4] Building CXX object CMakeFiles/libzippp_test.dir/tests/tests.cpp.o
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/tests/tests.cpp: In function ‘void test21()’:
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/tests/tests.cpp:678:45: warning: the address of ‘int fflush(FILE*)’ will never be NULL [-Waddress]
  678 |     cout << "Running test 21..." << endl << fflush;
      |                                             ^~~~~~
In file included from /usr/include/c++/12/cstdio:42,
                 from /usr/include/c++/12/ext/string_conversions.h:43,
                 from /usr/include/c++/12/bits/basic_string.h:3960,
                 from /usr/include/c++/12/string:53,
                 from /usr/include/c++/12/bits/locale_classes.h:40,
                 from /usr/include/c++/12/bits/ios_base.h:41,
                 from /usr/include/c++/12/ios:42,
                 from /usr/include/c++/12/ostream:38,
                 from /usr/include/c++/12/iostream:39,
                 from /home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/tests/tests.cpp:38:
/usr/include/stdio.h:230:12: note: ‘int fflush(FILE*)’ declared here
  230 | extern int fflush (FILE *__stream);
      |            ^~~~~~
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/tests/tests.cpp: In function ‘int main(int, char**)’:
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/tests/tests.cpp:895:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
  895 | int main(int argc, char** argv) {
      |          ~~~~^~~~
/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/src/tests/tests.cpp:895:27: warning: unused parameter ‘argv’ [-Wunused-parameter]
  895 | int main(int argc, char** argv) {
      |                    ~~~~~~~^~~~
[4/4] Linking CXX executable libzippp_shared_test
FAILED: libzippp_shared_test
: && /usr/bin/g++-12 -W -Wall -Wextra -ansi -pedantic -std=c++11 -O3 -m64 CMakeFiles/libzippp_test.dir/tests/tests.cpp.o -o libzippp_shared_test  -Wl,-rpath,/home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/build/Release  libzippp.so && :
/usr/bin/ld: warning: libcrypto.so.1.1, needed by /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `EVP_aes_128_ecb@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `PKCS5_PBKDF2_HMAC_SHA1@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `HMAC_CTX_new@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `EVP_sha1@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `HMAC_Final@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `EVP_aes_192_ecb@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `HMAC_Init_ex@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `EVP_EncryptUpdate@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `HMAC_CTX_free@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `EVP_CIPHER_CTX_new@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `EVP_EncryptInit_ex@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `EVP_aes_256_ecb@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `EVP_CIPHER_CTX_free@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `RAND_bytes@OPENSSL_1_1_0'
/usr/bin/ld: /home/spaceim/.conan2/p/libzi1690beeedfbba/p/lib/libzip.so.5: undefined reference to `HMAC_Update@OPENSSL_1_1_0'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

libzippp/6.0-1.9.2: ERROR:
Package 'ee3488ab65102991abf5b636e39de538d8d3e7ab' build failed
libzippp/6.0-1.9.2: WARN: Build folder /home/spaceim/.conan2/p/t/libzic30b1ebec828d/b/build/Release
*********************************************************
Recipe 'libzippp/6.0-1.9.2' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter check: https://conan.io/cci-v2.html
If it is your recipe, check if it is updated to 2.0
*********************************************************

ERROR: libzippp/6.0-1.9.2: Error in build() method, line 88
        cmake.build()
        ConanException: Error 1 while executing
```

</details>

related to https://github.com/conan-io/conan/issues/13000

If you dig into libzippp recipe, recipe of its dependency libzip, their upstream CMakeLists and how they are patched, you'll see that libzippp properly links to `libzip::zip` target defined in libzip recipe, and that `openssl::crypto` conan component of openssl recipe is properly appended to `requires` of this `libzip::_libzip` conan component in `package_info()` of libzip. Still, openssl crypto is missing in `-rpath-link` when linker tries to create libzippp shared lib.
user: SpaceIm
issue_13555: state: open
title: [bug] Problems when enable Swift language in CMake
body: ### Environment details

* Operating System+version: macos
* Compiler+version: 14
* Conan version: latest
* Python version: 3.9


### Steps to reproduce

Hi,

We are trying solve a problem that happen only with conan when we enable Swift language in CMakeLists.txt:
https://gitlab.kitware.com/cmake/cmake/-/issues/24650

Basically is a problem when compile for mac-catalyst when have this line in CMakeLists `enable_language(Swift)` and using conan toolchain. 

If we change to CPM and this toolchain "https://github.com/leetal/ios-cmake" it works without problems.

Can someone help me?

The cmake files generated from conan is here:
[mac-catalyst.zip](https://github.com/conan-io/conan/files/11092860/mac-catalyst.zip)


Thanks.

### Logs

_No response_
user: paulocoutinhox
issue_13551: state: open
title: [question] How to handle multiple versions of profiles and settings
body: ### What is your question?

I see that I can use [conan config install](https://docs.conan.io/2/reference/commands/config.html#conan-config-install) to distribute profiles and settings across a team, but I'm unsure how to version those profiles. 

The idea is I want each project to first call `conan config install <our stuff>`, so everyone is building with the same profiles. Beyond that we could even distribute cflags that any application aught to throw by modifying `tools.build:cflags` in the config. 

This all sounds great, but if we ever change anything in the profiles and settings and have to check an old version of our software the build would be different without a lot of manual work to determine the state of the profiles at the old version of the software.

I kind of have a workaround by keeping all our profiles etc on a git repo and in a project call:
`conan config install <git repo> --type git --args "--branch <tag>"`

Before I request that example to be added to the docs I wanted to see if there is a better way, or even if this whole idea is a bad practice I'll regret. 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: daltonv
issue_13545: state: open
title: [question] How to get environment variables from profile.
body: ### What is your question?

We use the Yocto SDK to cross-compile for embedded devices. The SDK ships Qemu, which allows us to run unittests and `test_package` executables on the build host. We set an environment variable `QEMU` in the `[runenv]` section of our profile, which contains the path to the qemu binary. In our Conan recipe we use the following test function:

```
def test(self):
        cmd = os.path.join(self.cpp.build.bindirs[0], "my-lib-a-test-package")

        # FIXME: Is there an easier way to get runenv variables?
        runenvs = dict(self.runenv.vars(self, scope="run").items())

        if not can_run(self) and "QEMU" in runenvs:
            cmd = "{QEMU} {cmd}".format(**runenvs, cmd=cmd)

        self.run(cmd, env="conanrun")
```

My question is how we can get access to runenv variables. It seems like `Environment` stores variables as an `OrderedDict` internally, the same is true for `EnvVars`. However, both classes to not implement `collections.Container`, i.e. do not implement `__contains__`. Is this intentional? Would you accept PRs to add this functionality?

(We would also just rely on the shell and use `self.run(f"${{QEMU}} {cmd}", env="conanrun")` to interpolate the variables in shel; however we prefer to have the full path also in the logs generated by Conan, hence interpolation in the Conan recipe is preferred)

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: skycaptain
issue_13534: state: open
title: [question] cmake_layout in test_package
body: ### What is your question?

The common pattern for test_package is nowadays

```python
    def layout(self):
        cmake_layout(self)

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
```

it works well until you create/test several package options/settings configurations in sequence (for example, during CI). As they share the same `build` folder, `CMakeCache.txt` persists between test runs. This creates undesired side effects. To work around them I have to change `build` method in my recipes to:

```python
    def build(self):
        cache = os.path.join(self.build_folder, "CMakeCache.txt")
        if os.path.exists(cache):
            self.output.info(f"Removing {cache}")
            os.remove(cache)
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
```

but I'm afraid this issue could exist for many CCI recipes that one cannot easily modify (before  `cmake_layout` introduction each build resided in its own hash-named directory). Can it be solved on Conan level?


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: db4
issue_13533: state: open
title: [feature] Ability to propagate a profile from a recipe for packaged toolchains and bootstrapping
body: ### What is your suggestion?

Hi Team,

There are a few things that I would like to achieve with conan:

* Compile packages with packaged compilers (i.e., gcc, gfortran (or other?) via gcc recipe, clang, flang via llvm recipe)
* Bootstrap the compiler I use such that I can:
    * build my required compiler version from source where it doesn't exist, or
    * build cross compilers where they don't exist, or
    * specify the glibc and linux header requirements to discretely control my build environment and library ABI.

I've experimented with this a little with the existing [gcc](https://github.com/conan-io/conan-center-index/blob/master/recipes/gcc/all/conanfile.py) recipe, a glibc recipe (that I'm yet to upstream), with the lapack recipe that's currently in draft format (https://github.com/conan-io/conan-center-index/pull/15556), and a PR that's up to model the libraries that gcc exposes (https://github.com/conan-io/conan-center-index/pull/15128).

From this experimentation, I've identified a few requirements that we would have in this situation:
1. **Compiler libraries need to be exposed as a runtime requirement when when the compiler is used in the build context.** There is a need to be able to link against the libraries distributed with compiler packages. This requirement needs to be propagated to consumers. An example of this is that using `gfortran` from the `gcc` recipe requires any consnumer of the library built with `gfortran` to link against `libgfortran.{a,so}`. This need can be mitigated where a shared lib is being created, then it can statically link `libgfortran.a` and consumers don't need to be aware of the `libgfortran` requirement, but this won't always be the case. This can be observed in the lapack PR above.
2. **Compiler packages need to be able to propagate a profile matching their own characteristics to libraries being built with them.** If I specify that I want to use `gcc/11.3.0` to build a package, but a pre-built variant of this doesn't exist, it should look to bootstrap itself by looking to previous versions of `gcc`. Lets say it finds a prebuilt package for `gcc/10.2.0` - this compiler and version should be reflected in the metadata of the `gcc/11.3.0` package now, rather than what would happen at the moment which is whatever the user defined profile is (which may even vary from `gcc/11.3.0`!). Likewise, the package I'm building with `gcc/11.3.0` should have `gcc 11.3.0` in its package metadata, not whatever the user defined profile is. Similarly, I would expect a package compiled with `gfortran` to have `settings.info.compiler=gfortran` rather than `settings.info.compiler=gcc` in its package metadata.
This is a simplistic representation of some of the things that might change. It's also useful to know the `libc` that the `gcc` package has been built against and the requirement that it will impart on libraries that it builds. This could be a step towards more meaningfully controlling library ABI.
This would also be useful for building cross-compilers.
3. **Profiles need a placeholder template in which a recipe can be specified as the compiler, rather than relying on what's installed on the system.** To facilitate (2) above, allowing the user to specify in their profile that they want metadata to be derived from a compiler package would be useful to avoid a multi-step environment set up. To illustrate, it would be good to be able to set a profile in a way similar to:

```
[settings]
arch=x86_64
os=Linux
compiler={{ package:gcc/11.3.0 }}
build_type=Release
# requirement on gcc/11.3.0 package to populate: 
# settings.compiler
# settings.compiler.version
# settings.compiler.libc
# settings.compiler.libcxx
# conf.tools.build:compiler_executables
```
In the above case, if the `conf.tools.build:compiler_executables=gfortran`, then `compiler={{ package:gcc/11.3.0 }}` would evaluate to `compiler=gfortran`, `compiler.version=11.3.0`. I can see that this might be difficult to infer which executable is used here, so another alternative might be to just ensure that each compiler has its own recipe/package.

I think what's being highlighted here is a need for a new package type - it would not be desirable to have _any_ package be able to override the user specified profile or act this way. Perhaps the definition of `package_type` could be extended to include a use case such as this rather than just traits propagation. I.e., `package_type=compiler` (noting that there is still a runtime requirement that compiler packages are likely to impart)

There's a lot of text here and I'm sure I've been unclear about some things. Please ask any questions that would help clarify the use case and proposed interface.

Relates to:
* https://github.com/conan-io/conan/issues/13469
* https://github.com/conan-io/conan/issues/3972
* https://github.com/conan-io/conan-center-index/issues/15099

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: samuel-emrys
issue_13520: state: open
title: v2 cmake presets: Generates files which are incompatible with installed CMake ` Unrecognized "version" field`
body: UX gripe, the output says CMakePresets are supported above version 3.19 however the `"include"` which as used were introduced in version 4 (cmake v3.23) https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html

The result is a confusing message that takes a while to sort out 😕 

The code comments clearly forces it to version 4 so conan should spit out a higher when working in v4 mode?

More instructions about how to lower the cmake requirement and use presets? 


```
C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>conan-script source . --version 9.1.0
conanfile.py (fmt/9.1.0): Calling source() in C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all\src
Downloading fmt-9.1.0.zip

conanfile.py (fmt/9.1.0): Unzipping 4.5MB, this can take a while
Unzipping 100 %

C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>conan-script install . --version 9.1.0

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows


======== Computing dependency graph ========
Graph root
    conanfile.py (fmt/9.1.0): C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all\conanfile.py

======== Computing necessary packages ========

======== Installing packages ========

======== Finalizing install (deploy, generators) ========
conanfile.py (fmt/9.1.0): Calling generate()
conanfile.py (fmt/9.1.0): Generators folder: C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all\build\generators
conanfile.py (fmt/9.1.0): CMakeToolchain generated: conan_toolchain.cmake
conanfile.py (fmt/9.1.0): Preset 'conan-default' added to CMakePresets.json. Invoke it manually using 'cmake --preset conan-default'
conanfile.py (fmt/9.1.0): If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Visual Studio 17 2022" -DCMAKE_TOOLCHAIN_FILE=C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all\build\generators\conan_toolchain.cmake -DFMT_DOC=OFF -DFMT_TEST=OFF -DFMT_INSTALL=ON -DFMT_LIB_DIR=lib -DFMT_OS=ON -DCMAKE_POLICY_DEFAULT_CMP0091=NEW'
conanfile.py (fmt/9.1.0): CMakeToolchain generated: CMakePresets.json
conanfile.py (fmt/9.1.0): CMakeToolchain generated: ..\..\src\CMakeUserPresets.json
conanfile.py (fmt/9.1.0): Generating aggregated env files
conanfile.py (fmt/9.1.0): Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
Install finished succesfully

C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>cmake src  --preset conan-default
CMake Error: Could not read presets from C:/Users/Chris McArthur/Documents/conan-center-index/recipes/fmt/all/src: Unrecognized "version" field

C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>cmake src --preset conan-default
CMake Error: Could not read presets from C:/Users/Chris McArthur/Documents/conan-center-index/recipes/fmt/all/src: Unrecognized "version" field

C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>cmake src --preset conan-default
CMake Error: Could not read presets from C:/Users/Chris McArthur/Documents/conan-center-index/recipes/fmt/all/src: No "version" field

C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>cmake src --preset conan-default
CMake Error: Could not read presets from C:/Users/Chris McArthur/Documents/conan-center-index/recipes/fmt/all/src: Unrecognized "version" field

C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>cmake src --preset conan-default
CMake Error: Could not read presets from C:/Users/Chris McArthur/Documents/conan-center-index/recipes/fmt/all/src: Unrecognized "version" field

C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>cmake src --preset conan-default
CMake Error: Could not read presets from C:/Users/Chris McArthur/Documents/conan-center-index/recipes/fmt/all/src: Invalid "version" field

C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>cmake src --preset conan-default
CMake Error: Could not read presets from C:/Users/Chris McArthur/Documents/conan-center-index/recipes/fmt/all/src: Unrecognized "version" field

C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>conan-script --version
Conan version 2.0.2

C:\Users\Chris McArthur\Documents\conan-center-index\recipes\fmt\all>cmake --version
cmake version 3.22.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).
```


https://github.com/conan-io/conan/blob/f0a67283508daa6e62eb123eee36d8e6f87d19b1/conan/tools/cmake/presets.py#L231-L238
user: prince-chrismc
issue_13515: state: open
title: [bug] settings_target is None when building tools for tools
body: ### Environment details

* Operating System+version: Macos 13.0 
* Conan version: 2.0.2
* Python version: 3.10.8


### Steps to reproduce

I have here three recipes, `gcc`, `binutils`, and `libmagic`. (here: https://github.com/smoofra/conan-none-bug)

`libmagic` tool_requires `gcc` .  It also tool_requires itself if cross compiling.

`gcc` requires `binutils`

`gcc` and `binutils` have options `arch_target` and `os_target` which specify the target platform for the toolchain.

It seems somewhere in the depths of conan `None` is turning into the string `'None'` and being assigned to `options.arch_target` on `binutils`.

```
git clone git@github.com:smoofra/conan-none-bug.git
cd conan-none-bug
conan export binutils
conan export gcc

conan graph info -pr:h ./Linux-x86_64 -pr:b ./Linux-x86_64 libmagic     # native compile, fine
conan graph info -pr:h ./Linux-x86_64 -pr:b ./Macos-x86_64 libmagic   # cross compile, still works

conan graph info -pr:h ./Linux-x86 -pr:b ./Linux-x86_64 libmagic  # cross compile fails!
```

### Logs

```
➜  ~/src/conan-none-bug git:(master) ./bug.sh 

======== Exporting recipe to the cache ========
binutils/2.38@bug: Exporting package recipe: /Users/larry/src/conan-none-bug/binutils/conanfile.py
binutils/2.38@bug: Copied 1 '.py' file: conanfile.py
binutils/2.38@bug: Exported to cache folder: /Volumes/build/conan2/binutd1f56ed6e9f1c/e
binutils/2.38@bug: Exported: binutils/2.38@bug#f7d6315c907aefb98d7c6b9dc144c5d8 (2023-03-23 14:57:38 UTC)

======== Exporting recipe to the cache ========
gcc/11.3.0@bug: Exporting package recipe: /Users/larry/src/conan-none-bug/gcc/conanfile.py
gcc/11.3.0@bug: Copied 1 '.py' file: conanfile.py
gcc/11.3.0@bug: Exported to cache folder: /Volumes/build/conan2/gcc9095fe2d964f9/e
gcc/11.3.0@bug: Exported: gcc/11.3.0@bug#d41af3f682f7a2f647881be73c375209 (2023-03-23 14:57:38 UTC)

======== Computing dependency graph ========
ERROR: 'None' is not a valid 'options.arch_target' value.
Possible values are ['x86', 'x86_64']
```
user: smoofra
issue_13503: state: open
title: make CMakeToolChain use customised initial cache file
body: ### What is your question?

Hi!
I am trying to migrate from conan1 to conan2 and am having trouble understanding how to pre-load a script to populate the cmake cache.

This is how it is currently done with conans.cmake class:
```
    cache_file = str(os.environ["CMAKE_CACHE_FILE"])
    cmake = CMake(self)
    cmake.configure(args=["-C", os.path.expandvars(cache_file)])
```


I am trying to get CMakeToolChain to use the initial cache file that is shipped to us. This is how the profile looks like now:
```
include(linux-gcc8-x86_64)
[settings]
os=Neutrino
os.version=7.1
arch=aarch64le
compiler=qcc
compiler.version=8.3
compiler.libcxx=cxx
[options]
[build_requires]
[env]
CC=qcc
CXX=QCC
CONAN_CMAKE_GENERATOR="Unix Makefiles"
CONAN_CMAKE_TOOLCHAIN_FILE=${CONAN_USER_HOME}/.conan/cmake/toolchain/qcc8_qnx710_aarch64.cmake
CMAKE_CACHE_FILE=${CONAN_USER_HOME}/.conan/cmake/config/qnx710_aarch64le_qcc8.cmake
[conf]
tools.build:compiler_executables={"c": "qcc", "cpp": "qcc"}
tools.cmake.cmaketoolchain:user_toolchain=["/home/.conan/cmake/toolchain/qcc8_qnx710_aarch64.cmake"]
```

Would appreciate some guidance, I got it to start using the toolchain that is shipped to us, but it is as important to use the correct cache file.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: hghzbc44
issue_13478: state: open
title: [question] Build the project with Debug while dependencies with Release (conan v2.x)
body: - conanfile.py

```
from conan import ConanFile
from conan.tools.cmake import CMake, CMakeDeps, cmake_layout

class ConanTest(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    generators = "CMakeToolchain", "CMakeDeps"
    build_policy = "missing"

    def requirements(self):
        self.requires("fmt/9.1.0")
        self.requires("spdlog/1.11.0")
        self.requires("boost/1.81.0")
        self.requires("yaml-cpp/0.7.0")

    def configure(self):
        self.options["fmt/*"].shared = False
        self.options["spdlog/*"].shared = False
        self.options["boost/*"].shared = False
        self.options["yamlc-pp/*"].shared = False

    def layout(self):
        cmake_layout(self)
```
### Goal
I want to build **my project with Debug mode** linking **dependencies with Release mode** 
(Because I can make sure that dependencies will work correctly).
The similar issue can be found in [#12656](https://github.com/conan-io/conan/issues/12656).

### What I have tried
To build **dependencies with Release mode**, I did:
`conan install . --settings=build_type=Release`

However, if I use the command:
`cmake -DCMAKE_TOOLCHAIN_FILE=./Release/generators/conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Debug`,
`make` fails to include the path to the dependencies. For example:
`fmt/os.h: No such file or directory`.

To handle the errors above, I have tried two things:

1. The compilation successes, but my project is built as **Release mode**, which means that `assertion` does not occur in the program:
`cmake -DCMAKE_TOOLCHAIN_FILE=./Release/generators/conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release`
2. set `CMAKE_MAP_IMPORTED_CONFIG_DEBUG RELEASE` in a `CMakeLists.txt` and use:
`cmake -DCMAKE_TOOLCHAIN_FILE=./Release/generators/conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Debug`,

(2) achieves my goal.

### Questions
1. Is (2) the only way to achieve what I want to do? If it is, how does `CMAKE_MAP_IMPORTED_CONFIG_DEBUG RELEASE` work in combination with `conan` (How was it possible to achieve my goal) ?
2. Are there other ways (e.g., w/o using `CMAKE_MAP_IMPORTED_CONFIG_DEBUG RELEASE`) to achieve what I want to do (e.g., scripting `conanfile.py`)?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: allencho1222
issue_13453: state: open
title: [question] How to ensure clang installed with the MSCV compiler is used?
body: ### What is your question?

Hi! I would like to ensure in the respective profile that the clang coming with the MSVC installation (2022 in this case) is used even if there is another clang/LLVM installation in the `PATH`.
Already went through https://blog.conan.io/2022/10/13/Different-flavors-Clang-compiler-Windows.html but i could only find how to use the `clang-cl` coming with the MSVC installation.

Currently the relevant part of the profile is:
```
[settings]
compiler=clang
compiler.version=15
compiler.cppstd=20
compiler.runtime_version=v143

[conf]
tools.build:compiler_executables={'c':'clang','c++':'clang'}
```

So the problem is that `clang` is taken from the `PATH` and the question is how to set `tools.build:compiler_executables` without knowing the exact path of the `clang` executables in the MSVC installation?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: petermbauer
issue_13447: state: open
title: [question] Support for RAD Studio (Delphi and C++Builder)?
body: ### What is your question?

Hello,
I apologize in advance if it isn't the right place to ask, but I figured it is worth a try.

I've used Conan for quite some time to manage a couple C++ projects for embedded development and become quite impressed with the capabilities of Conan.

As I spend most of my time in RAD Studio developing Delphi applications and sometimes cross-over with C++Builder (Due to the interop features). I was wondering if the Conan team would consider including support for RAD Studio?
I don't expect the Conan team have the capacity to add the support themselves, but would it be of interest if the integration is maintained as an external contribution and upstreamed to the Conan project?

Since Delphi uses DCUs (Delphi Compiled Units) to speed up the already fast compilation (Similar to the new C++ modules), and bpl packages (Essentially a dll/so/dylib with additional header magic for lookups) for components and optional runtime packages for modularity, Conan has all the features which would fit well into RAD Studio - especially when managing dependencies in a CI/CD pipeline, managing a large project in the IDE or managing multi platform projects which requires additional C++ dependencies to be compiled.
The same goes for C++Builder (It is clang/LLVM backed).
RAD Studio uses MSBuild project format format and MSBuild to build projects.

Thank you in advance.
Kind regards, Glenn.



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: code-kungfu
issue_13446: state: open
title: [bug] Fail on FreeBsd
body: ### Environment details

* Operating System+version: FreeBsd12, FreeBsd13
* Conan version: 1.53
* Python version: 3.9


### Steps to reproduce

1. Install conan from pkg - standart package manager for FreeBSD 
2. $conan user
3. ERROR: Couldn't read login
Try removing '/home/user/.conan/.conan.db' file
4. $rm /home/user/.conan/.conan.db && conan user
5. ERROR: Couldn't read login
Try removing '/home/user/.conan/.conan.db' file

### Logs

```
$conan user
ERROR: Couldn't read login
Try removing '/home/user/.conan/.conan.db' file
```
user: detrio333
issue_13443: state: open
title: [feature] AutotoolsToolchain: define environment when building for Android
body: ### What is your suggestion?

When targetting Android and building something that requires Autotools, we need to define `CC`, `CXX`, etc, as described here: https://developer.android.com/ndk/guides/other_build_systems

if `os=Android`, if `os.api_level`  and `tools.android:ndk_path` are defined in the profile, we have enough information to derive the correct environment variables as per the Android NDK documentation. 

Currently `tools.android:ndk_path` is sufficient for `CMakeToolchain`, but not for Autotools, resulting in having to define additional variables in the profile. We could consider doing this implicitly.


See: https://github.com/conan-io/conan/issues/13373#issuecomment-1468193058

user: jcar87
issue_13440: state: open
title: Consider possible alternative to ``--build-require`` in recipes as class attribute
body: ### What is your question?

https://github.com/conan-io/conan/pull/13433 => discuss further the ``--build-require`` possible parallel in recipes attribute

Most likely not using ``package_type``, but a different thing.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: memsharded
issue_13439: state: open
title: [question] How to disable search of dependency's test binary packages
body: ### What is your question?

I find out that conan search for test binary package of dependencies. It's may lead to long search of unnecessary packages, which will be skipped after search.

Furthermore, I have a problem if packages depends on each other. I have `rtengine` package, which uses `pkcs11ecp` package for tests. After some time I add `rtengine` to `pkcs11ecp` for test. And after that update `rtengine` to new version of `pkcs11ecp.` Install works fine, but export-pkg looks for unnecessary packages  and at the final can't find necessary binary for `pkcs11ecp`.

rtengine conanfile:
```python
from conan import ConanFile
from conan.tools.files import copy

from os import path

class RtengineConanfile(ConanFile):
    settings = "os", "compiler", "arch", "build_type", "libc"
    options = {"shared": [True, False], "restricted": [True, False], "country": ["ru", "kaz"]}
    default_options = {"shared": True, "restricted": False, "country": "ru"}

    python_requires = "rutokenconanfile/0.29@rutoken/testing"
    python_requires_extend = "rutokenconanfile.RutokenConanFile"

    def build_requirements(self):
        self.test_requires("boost-mt/1.76.0-e7488ca@rutoken/experimental")
        self.test_requires("pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing", options={"country": self.options.country})
        self.test_requires("openssl/3.0.7-cb192d2@rutoken/experimental")

    def requirements(self):
        self.requires("rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental", visible=not self.options.shared)

    def configure(self):
        self.settings.rm_safe("compiler.cppstd")

        if self.settings.os == "Windows":
            self.settings.compiler.runtime = "static"
            self.settings.compiler.runtime_type = self.settings.build_type

    def package(self):
        copy(self, "*", path.join(self.build_folder, "shared" if self.options.shared else "static"), self.package_folder)
```

updated pkcs11ecp conanfile (old version depends on nothing)
```python
from conan import ConanFile
from conan.tools.files import copy

from os import path

class RtPkcs11EcpConanfile(ConanFile):
    settings = "os", "compiler", "arch", "build_type", "libc"
    options = {"shared": [True, False], "sysformat": [True, False], "crypto": [True, False], "country": ["ru", "kaz"], "use_cprocsp": [True, False]}
    default_options = {"shared": True, "sysformat": False, "crypto": False, "country": "ru"}

    python_requires = "rutokenconanfile/0.29@rutoken/testing"
    python_requires_extend = "rutokenconanfile.RutokenConanFile"

    def configure(self):
        self.settings.rm_safe("compiler.cppstd")

        if self.settings.os == "Windows":
            self.settings.compiler.runtime = "static"
            self.settings.compiler.runtime_type = self.settings.build_type

        self.options.use_cprocsp = self.settings.os in ["Windows", "Linux", "FreeBSD", "Macos"] and self.settings.arch in  ["x86", "x86_64"]

    def build_requirements(self):
        self.test_requires("tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing", options={"country": self.options.country})

        if self.options.use_cprocsp:
            self.test_requires("cprocsp/5.0.11732@rutoken/experimental")

        if self.settings.os in ["FreeBSD", "Linux"]:
            self.test_requires("pcsclite/1.9.5@rutoken/testing#a50e78deffa149d380cc0a88381cf124")
        elif self.settings.os == "Android":
            self.test_requires("pcsc-android/v1.10.0-12-gf5d49a60@rutoken/testing")
            self.test_requires("rtservice/v1.10.0-12-gf5d49a60@rutoken/testing")
        elif self.settings.os == "iOS":
            self.test_requires("pcsc-ios/v4.0.0@rutoken/experimental")
        elif self.settings.os == "Macos":
            self.test_requires("osx-ccid/e560ac36b10e96df43af4ee22d0aa6299f89b327@rutoken/testing", options={"country": self.options.country})

    def requirements(self):
        visible = not self.options.shared
        self.requires("openssl/3.0.7-cb192d2@rutoken/experimental", visible=visible, options={"shared": False})
        self.requires("rtengine/v3.1.1-5-g5535964@rutoken/experimental", visible=visible,
                      options={"country": self.options.country, "restricted": self.options.country == "ru", "shared": False})

    def package(self):
        if self.options.shared:
            copy(self, "*", path.join(self.build_folder, "shared"), self.package_folder)
        else:
            copy(self, "*", path.join(self.build_folder, "static"), self.package_folder)

    def package_id(self):
        del self.info.options.use_cprocsp
```


conan install works fine, but search for unnecessary packages (conan search for test_dependencies for test_dependencies) and has bad output(boost-mt is skipped but actually downloaded):
```console
 conan install --name kek --version 0.0.1 -pr glibc-x86_64-gcc11 -of kek -s build_type=Debug .

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Debug
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=11
libc=glibc
libc.version=2.12
os=Linux

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=12
os=Linux

rutokenconanfile/0.29@rutoken/testing: Not found in local cache, looking in remotes...
rutokenconanfile/0.29@rutoken/testing: Checking remote: conancenter
rutokenconanfile/0.29@rutoken/testing: Checking remote: rutoken
rutokenconanfile/0.29@rutoken/testing: Downloaded recipe revision 25973501fa393aae9945419209b747fe

======== Computing dependency graph ========
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Not found in local cache, looking in remotes...
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Checking remote: conancenter
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Checking remote: rutoken
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Downloaded recipe revision 1f4153c5c04cedc619e3faa2c9e025e8
rutokenconanfile/0.26@rutoken/testing: Not found in local cache, looking in remotes...
rutokenconanfile/0.26@rutoken/testing: Checking remote: conancenter
rutokenconanfile/0.26@rutoken/testing: Checking remote: rutoken
rutokenconanfile/0.26@rutoken/testing: Downloaded recipe revision b1257b9a92f36b4c09fa008f25a292ca
cprocsp/5.0.11732@rutoken/experimental: Not found in local cache, looking in remotes...
cprocsp/5.0.11732@rutoken/experimental: Checking remote: conancenter
cprocsp/5.0.11732@rutoken/experimental: Checking remote: rutoken
cprocsp/5.0.11732@rutoken/experimental: Downloaded recipe revision 75066d2cfa02a28f12b562ed4dae876d
rutokenconanfile/0.25@rutoken/testing: Not found in local cache, looking in remotes...
rutokenconanfile/0.25@rutoken/testing: Checking remote: conancenter
rutokenconanfile/0.25@rutoken/testing: Checking remote: rutoken
rutokenconanfile/0.25@rutoken/testing: Downloaded recipe revision 2933131cd0b258b5e47c6fbee93c7bb0
boost-mt/1.76.0-e7488ca@rutoken/experimental: Not found in local cache, looking in remotes...
boost-mt/1.76.0-e7488ca@rutoken/experimental: Checking remote: conancenter
boost-mt/1.76.0-e7488ca@rutoken/experimental: Checking remote: rutoken
boost-mt/1.76.0-e7488ca@rutoken/experimental: Downloaded recipe revision 766f131873c73bc3cde079bff2bf1754
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: Not found in local cache, looking in remotes...
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: Checking remote: conancenter
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: Checking remote: rutoken
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: Downloaded recipe revision c0a84b2701d504989b1bbf53a4663f79
openssl/3.0.7-cb192d2@rutoken/experimental: Not found in local cache, looking in remotes...
openssl/3.0.7-cb192d2@rutoken/experimental: Checking remote: conancenter
openssl/3.0.7-cb192d2@rutoken/experimental: Checking remote: rutoken
openssl/3.0.7-cb192d2@rutoken/experimental: Downloaded recipe revision c691c52600664b10b7477f3ca576ee9c
rtengine/v3.1.1-5-g5535964@rutoken/experimental: Not found in local cache, looking in remotes...
rtengine/v3.1.1-5-g5535964@rutoken/experimental: Checking remote: conancenter
rtengine/v3.1.1-5-g5535964@rutoken/experimental: Checking remote: rutoken
rtengine/v3.1.1-5-g5535964@rutoken/experimental: Downloaded recipe revision 6ab88a1007911bbc294a0ca014658a40
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: Not found in local cache, looking in remotes...
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: Checking remote: conancenter
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: Checking remote: rutoken
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: Downloaded recipe revision 68d7e9dfbe6a53922a47ec4a242016c2
tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing: Not found in local cache, looking in remotes...
tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing: Checking remote: conancenter
tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing: Checking remote: rutoken
tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing: Downloaded recipe revision c1280aa905c0fe5ef843c05535fb05a1
pcsclite/1.9.5@rutoken/testing: Not found in local cache, looking in remotes...
pcsclite/1.9.5@rutoken/testing: Checking remote: conancenter
pcsclite/1.9.5@rutoken/testing: Checking remote: rutoken
pcsclite/1.9.5@rutoken/testing: Downloaded recipe revision a50e78deffa149d380cc0a88381cf124
Graph root
    conanfile.py (kek/0.0.1): /home/lo1ol/Documents/work/rtengine/conanfile.py
Requirements
    rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental#1f4153c5c04cedc619e3faa2c9e025e8 - Downloaded (rutoken)
Test requirements
    boost-mt/1.76.0-e7488ca@rutoken/experimental#766f131873c73bc3cde079bff2bf1754 - Cache
    cprocsp/5.0.11732@rutoken/experimental#75066d2cfa02a28f12b562ed4dae876d - Cache
    openssl/3.0.7-cb192d2@rutoken/experimental#c691c52600664b10b7477f3ca576ee9c - Cache
    pcsclite/1.9.5@rutoken/testing#a50e78deffa149d380cc0a88381cf124 - Cache
    pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing#68d7e9dfbe6a53922a47ec4a242016c2 - Cache
    pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing#c0a84b2701d504989b1bbf53a4663f79 - Downloaded (rutoken)
    rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental#1f4153c5c04cedc619e3faa2c9e025e8 - Cache
    rtengine/v3.1.1-5-g5535964@rutoken/experimental#6ab88a1007911bbc294a0ca014658a40 - Downloaded (rutoken)
    tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing#c1280aa905c0fe5ef843c05535fb05a1 - Downloaded (rutoken)
Python requires
    rutokenconanfile/0.25@rutoken/testing#2933131cd0b258b5e47c6fbee93c7bb0 - Downloaded (rutoken)
    rutokenconanfile/0.26@rutoken/testing#b1257b9a92f36b4c09fa008f25a292ca - Downloaded (rutoken)
    rutokenconanfile/0.29@rutoken/testing#25973501fa393aae9945419209b747fe - Cache

======== Computing necessary packages ========
boost-mt/1.76.0-e7488ca@rutoken/experimental: Checking 50 compatible configurations:
boost-mt/1.76.0-e7488ca@rutoken/experimental: '4115bd5b2ad61fe73c9251212dce1dca55df9b24': build_type=Release
boost-mt/1.76.0-e7488ca@rutoken/experimental: Main binary package '042da963fb7d3e363c64266822c0ed9890d8c44b' missing. Using compatible package '4115bd5b2ad61fe73c9251212dce1dca55df9b24'
openssl/3.0.7-cb192d2@rutoken/experimental: Checking 13 compatible configurations:
openssl/3.0.7-cb192d2@rutoken/experimental: '9604cbbe3ab4d7a9796f4862b97a22492749a0c2': build_type=Release
openssl/3.0.7-cb192d2@rutoken/experimental: Main binary package 'ce8dbdeab63ab1f0c7ace120ebfd3611aa5dd75f' missing. Using compatible package '9604cbbe3ab4d7a9796f4862b97a22492749a0c2'
openssl/3.0.7-cb192d2@rutoken/experimental: Checking 13 compatible configurations:
openssl/3.0.7-cb192d2@rutoken/experimental: 'd26d4ad84e7d0d9ccde5c37a6514288f50e44efd': build_type=Release
openssl/3.0.7-cb192d2@rutoken/experimental: Main binary package '3a59bc00c13965211a71d35a72250fa70a09ccfb' missing. Using compatible package 'd26d4ad84e7d0d9ccde5c37a6514288f50e44efd'
pcsclite/1.9.5@rutoken/testing: Checking 13 compatible configurations:
pcsclite/1.9.5@rutoken/testing: '98981384b21184d62f24f26a66dd865b2fd3197c': build_type=Release
pcsclite/1.9.5@rutoken/testing: Main binary package '222d94c573a4f4ae5eaee526bc5b3247046770f4' missing. Using compatible package '98981384b21184d62f24f26a66dd865b2fd3197c'
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Checking 13 compatible configurations:
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: '426334e6c2a31bb34a190b48c3114ef5d7cb9140': build_type=Release
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Main binary package '090e2a50985ed8afc712ddce15c945dbe963b810' missing. Using compatible package '426334e6c2a31bb34a190b48c3114ef5d7cb9140'
rtengine/v3.1.1-5-g5535964@rutoken/experimental: Checking 13 compatible configurations:
rtengine/v3.1.1-5-g5535964@rutoken/experimental: 'd1a1e4b7534bbfc447cde6cf7a56191051580ea1': build_type=Release
rtengine/v3.1.1-5-g5535964@rutoken/experimental: Main binary package '65abe93129f3465e8314430308210bd88e0dbd10' missing. Using compatible package 'd1a1e4b7534bbfc447cde6cf7a56191051580ea1'
Requirements
    rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental#1f4153c5c04cedc619e3faa2c9e025e8:426334e6c2a31bb34a190b48c3114ef5d7cb9140#af57376943cf3eedd16daa20d83faa5e - Download (rutoken)
Test requirements
    boost-mt/1.76.0-e7488ca@rutoken/experimental#766f131873c73bc3cde079bff2bf1754:4115bd5b2ad61fe73c9251212dce1dca55df9b24#27200b190241c7a40892d7b861ab44ae - Skip
    cprocsp/5.0.11732@rutoken/experimental#75066d2cfa02a28f12b562ed4dae876d:f2d37cd7199b4fc0a2b397e64f1ae8247612826e#3a1dad8b516b04057e884a80759d132e - Skip
    openssl/3.0.7-cb192d2@rutoken/experimental#c691c52600664b10b7477f3ca576ee9c:9604cbbe3ab4d7a9796f4862b97a22492749a0c2#1d846fcd9aa8288878247144a451edb5 - Skip
    openssl/3.0.7-cb192d2@rutoken/experimental#c691c52600664b10b7477f3ca576ee9c:d26d4ad84e7d0d9ccde5c37a6514288f50e44efd#0b6c0911ab9ee6851314c12bd89168d0 - Download (rutoken)
    pcsclite/1.9.5@rutoken/testing#a50e78deffa149d380cc0a88381cf124:98981384b21184d62f24f26a66dd865b2fd3197c#5e7a4d9580d524973726981151c69944 - Skip
    pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing#68d7e9dfbe6a53922a47ec4a242016c2:784e657aa1b7f1a719ee85805183271a87127175#f8ed13115b6767a8a848c678e1253c75 - Skip
    pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing#c0a84b2701d504989b1bbf53a4663f79:435e75f0dbc065a8a7a66009de0c7c625aaf16cc#81d31254a330ea2f51c7f6f091dff66b - Download (rutoken)
    rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental#1f4153c5c04cedc619e3faa2c9e025e8:426334e6c2a31bb34a190b48c3114ef5d7cb9140#af57376943cf3eedd16daa20d83faa5e - Skip
    rtengine/v3.1.1-5-g5535964@rutoken/experimental#6ab88a1007911bbc294a0ca014658a40:d1a1e4b7534bbfc447cde6cf7a56191051580ea1#e7c3d8500483b424a8ee4ec67f354475 - Skip
    tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing#c1280aa905c0fe5ef843c05535fb05a1:f33bea03e0bf2394aee7ddebe87f0cc1795187e1#013156f93803be3acb55544f840fa2b7 - Skip

======== Installing packages ========

-------- Downloading 4 packages --------
boost-mt/1.76.0-e7488ca@rutoken/experimental: Retrieving package 4115bd5b2ad61fe73c9251212dce1dca55df9b24 from remote 'rutoken' 
Downloading conanmanifest.txt
Downloading conan_package.tgz
Decompressing conan_package.tgz
boost-mt/1.76.0-e7488ca@rutoken/experimental: Package installed 4115bd5b2ad61fe73c9251212dce1dca55df9b24
boost-mt/1.76.0-e7488ca@rutoken/experimental: Downloaded package revision 27200b190241c7a40892d7b861ab44ae
openssl/3.0.7-cb192d2@rutoken/experimental: Retrieving package d26d4ad84e7d0d9ccde5c37a6514288f50e44efd from remote 'rutoken' 
Downloading conan_package.tgz
Decompressing conan_package.tgz
openssl/3.0.7-cb192d2@rutoken/experimental: Package installed d26d4ad84e7d0d9ccde5c37a6514288f50e44efd
openssl/3.0.7-cb192d2@rutoken/experimental: Downloaded package revision 0b6c0911ab9ee6851314c12bd89168d0
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Retrieving package 426334e6c2a31bb34a190b48c3114ef5d7cb9140 from remote 'rutoken' 
Downloading conan_package.tgz
Decompressing conan_package.tgz
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Package installed 426334e6c2a31bb34a190b48c3114ef5d7cb9140
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Downloaded package revision af57376943cf3eedd16daa20d83faa5e
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: Retrieving package 435e75f0dbc065a8a7a66009de0c7c625aaf16cc from remote 'rutoken' 
Downloading conan_package.tgz
Decompressing conan_package.tgz
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: Package installed 435e75f0dbc065a8a7a66009de0c7c625aaf16cc
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: Downloaded package revision 81d31254a330ea2f51c7f6f091dff66b

======== Finalizing install (deploy, generators) ========
conanfile.py (kek/0.0.1): Calling generate()
conanfile.py (kek/0.0.1): Generators folder: /home/lo1ol/Documents/work/rtengine/kek
Install finished succesfully
```


but export-pkg looks for all compatible packages and can't find `pkcs11ecp`:
```console
conan export-pkg --name kek --version 0.0.1 -pr glibc-x86_64-gcc11 -of kek -s build_type=Debug .

======== Exporting recipe to the cache ========
kek/0.0.1: Exporting package recipe: /home/lo1ol/Documents/work/rtengine/conanfile.py
kek/0.0.1: Copied 1 '.py' file: conanfile.py
kek/0.0.1: Exported to cache folder: /home/lo1ol/.conan2/p/kek84681448ad62c/e
kek/0.0.1: Exported: kek/0.0.1#e86f8ac25d946b5856e021b4237c46a4 (2023-03-14 07:57:28 UTC)

======== Computing dependency graph ========
Graph root
    conanfile.py (kek/0.0.1): /home/lo1ol/Documents/work/rtengine/conanfile.py
Requirements
    rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental#1f4153c5c04cedc619e3faa2c9e025e8 - Cache
Test requirements
    boost-mt/1.76.0-e7488ca@rutoken/experimental#766f131873c73bc3cde079bff2bf1754 - Cache
    cprocsp/5.0.11732@rutoken/experimental#75066d2cfa02a28f12b562ed4dae876d - Cache
    openssl/3.0.7-cb192d2@rutoken/experimental#c691c52600664b10b7477f3ca576ee9c - Cache
    pcsclite/1.9.5@rutoken/testing#a50e78deffa149d380cc0a88381cf124 - Cache
    pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing#68d7e9dfbe6a53922a47ec4a242016c2 - Cache
    pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing#c0a84b2701d504989b1bbf53a4663f79 - Cache
    rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental#1f4153c5c04cedc619e3faa2c9e025e8 - Cache
    rtengine/v3.1.1-5-g5535964@rutoken/experimental#6ab88a1007911bbc294a0ca014658a40 - Cache
    tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing#c1280aa905c0fe5ef843c05535fb05a1 - Cache
Python requires
    rutokenconanfile/0.25@rutoken/testing#2933131cd0b258b5e47c6fbee93c7bb0 - Cache
    rutokenconanfile/0.26@rutoken/testing#b1257b9a92f36b4c09fa008f25a292ca - Cache
    rutokenconanfile/0.29@rutoken/testing#25973501fa393aae9945419209b747fe - Cache

======== Computing necessary packages ========
boost-mt/1.76.0-e7488ca@rutoken/experimental: Checking 50 compatible configurations:
boost-mt/1.76.0-e7488ca@rutoken/experimental: '4115bd5b2ad61fe73c9251212dce1dca55df9b24': build_type=Release
boost-mt/1.76.0-e7488ca@rutoken/experimental: Main binary package '042da963fb7d3e363c64266822c0ed9890d8c44b' missing. Using compatible package '4115bd5b2ad61fe73c9251212dce1dca55df9b24'
openssl/3.0.7-cb192d2@rutoken/experimental: Checking 13 compatible configurations:
openssl/3.0.7-cb192d2@rutoken/experimental: '9604cbbe3ab4d7a9796f4862b97a22492749a0c2': build_type=Release
openssl/3.0.7-cb192d2@rutoken/experimental: 'eecfb0029a97f73fc8850870ea1b888876ac6498': compiler.version=11.3
openssl/3.0.7-cb192d2@rutoken/experimental: 'a0e226842049c89c3d79cb64395076ba92a8bba5': compiler.version=11.2
openssl/3.0.7-cb192d2@rutoken/experimental: '007b1f74046a2218c414c143fe6582309ec534e8': compiler.version=11.1
openssl/3.0.7-cb192d2@rutoken/experimental: 'f367484addf5e44fcc62fb7ec7c78b0f54320446': compiler.version=10
openssl/3.0.7-cb192d2@rutoken/experimental: '3eeddd4635c9f0ea0a06e2cd2436477b7a06eddd': compiler.version=9
openssl/3.0.7-cb192d2@rutoken/experimental: 'b958caa7bf3c5d12ce630ace1dca6050750460ac': compiler.version=8
openssl/3.0.7-cb192d2@rutoken/experimental: '8030ccfecedce9534ec6270c27ed0c8e509879b6': build_type=Release, compiler.version=11.3
openssl/3.0.7-cb192d2@rutoken/experimental: 'c1485e746a617968790343b676fda7325cd621ae': build_type=Release, compiler.version=11.2
openssl/3.0.7-cb192d2@rutoken/experimental: '67013a1def2af33542ad14095334103725a3aa2b': build_type=Release, compiler.version=11.1
openssl/3.0.7-cb192d2@rutoken/experimental: '856e0d30187aeb0086f950f26e8a25190a2346c0': build_type=Release, compiler.version=10
openssl/3.0.7-cb192d2@rutoken/experimental: 'cf75bc26b4368738a060b1ef43b343b3e23e6dac': build_type=Release, compiler.version=9
openssl/3.0.7-cb192d2@rutoken/experimental: 'e838076049a737dc5b3c8878b7496f15abe73d78': build_type=Release, compiler.version=8
openssl/3.0.7-cb192d2@rutoken/experimental: Checking 13 compatible configurations:
openssl/3.0.7-cb192d2@rutoken/experimental: 'd26d4ad84e7d0d9ccde5c37a6514288f50e44efd': build_type=Release
openssl/3.0.7-cb192d2@rutoken/experimental: Main binary package '3a59bc00c13965211a71d35a72250fa70a09ccfb' missing. Using compatible package 'd26d4ad84e7d0d9ccde5c37a6514288f50e44efd'
pcsclite/1.9.5@rutoken/testing: Checking 13 compatible configurations:
pcsclite/1.9.5@rutoken/testing: '98981384b21184d62f24f26a66dd865b2fd3197c': build_type=Release
pcsclite/1.9.5@rutoken/testing: 'bebbe508853d2bdd2810cfe864433c55106d4592': compiler.version=11.3
pcsclite/1.9.5@rutoken/testing: 'ce749999665cb1e9ad3a0fad532f617efb7963fb': compiler.version=11.2
pcsclite/1.9.5@rutoken/testing: '1d247ccb365e7250c028c92d4707a3dc60190d0d': compiler.version=11.1
pcsclite/1.9.5@rutoken/testing: '1190665e21535be5ad003d4d50200ecea95b605e': compiler.version=10
pcsclite/1.9.5@rutoken/testing: '224a756f128ffa8f1f66c3d738b109de54b04764': compiler.version=9
pcsclite/1.9.5@rutoken/testing: '9a213b35a8582b079b675aeccf160eb34432ee79': compiler.version=8
pcsclite/1.9.5@rutoken/testing: '994fa52562bab39b4cc12155099ed0153ff13612': build_type=Release, compiler.version=11.3
pcsclite/1.9.5@rutoken/testing: 'e8d6525c180cc1a225de47c3e16ce35f9db9c6dc': build_type=Release, compiler.version=11.2
pcsclite/1.9.5@rutoken/testing: '5629499f747670e2210e2d68b4cb1efbbf276985': build_type=Release, compiler.version=11.1
pcsclite/1.9.5@rutoken/testing: 'bc8076832d87a9781b768d4832d0687717b41417': build_type=Release, compiler.version=10
pcsclite/1.9.5@rutoken/testing: '1a6fe6bf13de27fd3e21c89127fbbe271baf2681': build_type=Release, compiler.version=9
pcsclite/1.9.5@rutoken/testing: '60bb1855ba818f27d866e804b493b84c13f69f2d': build_type=Release, compiler.version=8
pcsclite/1.9.5@rutoken/testing: Checking 13 compatible configurations:
pcsclite/1.9.5@rutoken/testing: '98981384b21184d62f24f26a66dd865b2fd3197c': build_type=Release
pcsclite/1.9.5@rutoken/testing: 'bebbe508853d2bdd2810cfe864433c55106d4592': compiler.version=11.3
pcsclite/1.9.5@rutoken/testing: 'ce749999665cb1e9ad3a0fad532f617efb7963fb': compiler.version=11.2
pcsclite/1.9.5@rutoken/testing: '1d247ccb365e7250c028c92d4707a3dc60190d0d': compiler.version=11.1
pcsclite/1.9.5@rutoken/testing: '1190665e21535be5ad003d4d50200ecea95b605e': compiler.version=10
pcsclite/1.9.5@rutoken/testing: '224a756f128ffa8f1f66c3d738b109de54b04764': compiler.version=9
pcsclite/1.9.5@rutoken/testing: '9a213b35a8582b079b675aeccf160eb34432ee79': compiler.version=8
pcsclite/1.9.5@rutoken/testing: '994fa52562bab39b4cc12155099ed0153ff13612': build_type=Release, compiler.version=11.3
pcsclite/1.9.5@rutoken/testing: 'e8d6525c180cc1a225de47c3e16ce35f9db9c6dc': build_type=Release, compiler.version=11.2
pcsclite/1.9.5@rutoken/testing: '5629499f747670e2210e2d68b4cb1efbbf276985': build_type=Release, compiler.version=11.1
pcsclite/1.9.5@rutoken/testing: 'bc8076832d87a9781b768d4832d0687717b41417': build_type=Release, compiler.version=10
pcsclite/1.9.5@rutoken/testing: '1a6fe6bf13de27fd3e21c89127fbbe271baf2681': build_type=Release, compiler.version=9
pcsclite/1.9.5@rutoken/testing: '60bb1855ba818f27d866e804b493b84c13f69f2d': build_type=Release, compiler.version=8
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: Checking 13 compatible configurations:
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '280af46ea68650b0df905d024c65f1b6ee455fe5': build_type=Release
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: 'bfc62b4d447120b9b4d441d539e36d2c4536ed6d': compiler.version=11.3
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '32620f2643a62f892e314aeb737d83b3124f5d5a': compiler.version=11.2
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: 'f0365d4feffde0ea7a85938009e457e5e94b61c1': compiler.version=11.1
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '18e202362cff25ab949b1b280185c53f1f3118a1': compiler.version=10
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: 'a9ae39abdee15e002579de03f881b6cbc75b1059': compiler.version=9
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '16816b0923d3abb21c0461363e21a1cbd1768847': compiler.version=8
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '3dd4b6a4c087c9c3686de50932f42a3ae6c2f1c5': build_type=Release, compiler.version=11.3
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: 'be42fa58baa687befcd429f1821409a8dcef0423': build_type=Release, compiler.version=11.2
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '085a46cd7ad31d1c5c9e65671e52f4d75db05d1b': build_type=Release, compiler.version=11.1
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: 'e2fa73dd3ebc38e37ffa0f22b835478f7b2b74f4': build_type=Release, compiler.version=10
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '7e5f49b00fa04da1b97e13dd68124ee51ae9ee64': build_type=Release, compiler.version=9
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '6938bb836441d28332649a9384984cd7dd8d2b1e': build_type=Release, compiler.version=8
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: Checking 13 compatible configurations:
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '280af46ea68650b0df905d024c65f1b6ee455fe5': build_type=Release
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: 'bfc62b4d447120b9b4d441d539e36d2c4536ed6d': compiler.version=11.3
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '32620f2643a62f892e314aeb737d83b3124f5d5a': compiler.version=11.2
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: 'f0365d4feffde0ea7a85938009e457e5e94b61c1': compiler.version=11.1
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '18e202362cff25ab949b1b280185c53f1f3118a1': compiler.version=10
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: 'a9ae39abdee15e002579de03f881b6cbc75b1059': compiler.version=9
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '16816b0923d3abb21c0461363e21a1cbd1768847': compiler.version=8
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '3dd4b6a4c087c9c3686de50932f42a3ae6c2f1c5': build_type=Release, compiler.version=11.3
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: 'be42fa58baa687befcd429f1821409a8dcef0423': build_type=Release, compiler.version=11.2
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '085a46cd7ad31d1c5c9e65671e52f4d75db05d1b': build_type=Release, compiler.version=11.1
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: 'e2fa73dd3ebc38e37ffa0f22b835478f7b2b74f4': build_type=Release, compiler.version=10
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '7e5f49b00fa04da1b97e13dd68124ee51ae9ee64': build_type=Release, compiler.version=9
pkcs11ecp/v2.7.1.0-2-g1b3b2602@rutoken/testing: '6938bb836441d28332649a9384984cd7dd8d2b1e': build_type=Release, compiler.version=8
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Checking 13 compatible configurations:
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: '426334e6c2a31bb34a190b48c3114ef5d7cb9140': build_type=Release
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental: Main binary package '090e2a50985ed8afc712ddce15c945dbe963b810' missing. Using compatible package '426334e6c2a31bb34a190b48c3114ef5d7cb9140'
tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing: Checking 1 compatible configurations:
tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing: '50f5bb15f23a6e97a11679e5a1a884111d1fe8c3': build_type=Release
rtengine/v3.1.1-5-g5535964@rutoken/experimental: Checking 13 compatible configurations:
rtengine/v3.1.1-5-g5535964@rutoken/experimental: 'd1a1e4b7534bbfc447cde6cf7a56191051580ea1': build_type=Release
rtengine/v3.1.1-5-g5535964@rutoken/experimental: '72cf280ae77105a4d385a492787320ef896ff4c6': compiler.version=11.3
rtengine/v3.1.1-5-g5535964@rutoken/experimental: 'c7d09cd7a47a84c615022523941606c9983b158a': compiler.version=11.2
rtengine/v3.1.1-5-g5535964@rutoken/experimental: '674523e2f44d932345207260278c84a08be2906c': compiler.version=11.1
rtengine/v3.1.1-5-g5535964@rutoken/experimental: '2584bc886a826de404259c0722f2428e98196b99': compiler.version=10
rtengine/v3.1.1-5-g5535964@rutoken/experimental: 'c6974c7b3c7f1c56547cef111d2f124f2cf325fc': compiler.version=9
rtengine/v3.1.1-5-g5535964@rutoken/experimental: 'f73abf5c01a21ae70868469db2dcaa25d44e3d0e': compiler.version=8
rtengine/v3.1.1-5-g5535964@rutoken/experimental: '648aa58e4cb999a249ae5f0ea62fcec7fbd1683b': build_type=Release, compiler.version=11.3
rtengine/v3.1.1-5-g5535964@rutoken/experimental: '9a5dd71a4fc1c5312e5160f1591043f07cdab177': build_type=Release, compiler.version=11.2
rtengine/v3.1.1-5-g5535964@rutoken/experimental: '0c83e7eb12fdf56a3493a1337431248bb6ceda35': build_type=Release, compiler.version=11.1
rtengine/v3.1.1-5-g5535964@rutoken/experimental: '70acc0dd4cadbed7bb6dd3e94dc390553b1bb2f6': build_type=Release, compiler.version=10
rtengine/v3.1.1-5-g5535964@rutoken/experimental: '00ac2520d7d9afbc53d6e4a5a5775d64497de2c2': build_type=Release, compiler.version=9
rtengine/v3.1.1-5-g5535964@rutoken/experimental: '931121e3af148a6635680d0e5afbbda3a1905d4c': build_type=Release, compiler.version=8
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: Checking 13 compatible configurations:
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: '64e987f38c32f37860afa13dbab2b0dcc0d0b6de': build_type=Release
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: 'a6fc06671067108ffc079ca856abd9e71b87e017': compiler.version=11.3
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: '52543618d77f8a4cca90798f8700e3e9de1e0c58': compiler.version=11.2
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: '56b943a16517ad6cb5ba73c348c29d43c2ed340e': compiler.version=11.1
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: '9b234a35257b4a72248fd153067638e59d18b9a4': compiler.version=10
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: '50fba9199f2b80de4f5ccf9ccb63ec1e24728cbe': compiler.version=9
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: '26a63e57ca32c1bf9c625a969756a83be57ca854': compiler.version=8
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: 'a45feefe4fc940a752ab56ca87386252d84ebf02': build_type=Release, compiler.version=11.3
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: 'a2eee4c00b8f93c44ab9eac6746377f269d3585f': build_type=Release, compiler.version=11.2
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: 'fd03c70cdaad8783432e578a48df1bd8084df864': build_type=Release, compiler.version=11.1
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: '4f423972e87e036c064f7180f341d8ef97a7d903': build_type=Release, compiler.version=10
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: 'd1e3822c9cfdb80fe9c668c813d35139ae32151f': build_type=Release, compiler.version=9
pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: '929912e34e25896683c0f067c67ba479c9697dd1': build_type=Release, compiler.version=8

======== Installing packages ========
ERROR: Missing binary: pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing:d9a2cef528d4b4d3a66e1724c68b253e57f11bb1

pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing: WARN: Can't find a 'pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing' package binary 'd9a2cef528d4b4d3a66e1724c68b253e57f11bb1' for the configuration:
[settings]
arch=x86_64
build_type=Debug
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=11
libc=glibc
libc.version=2.12
os=Linux
[options]
country=ru
crypto=False
shared=True
sysformat=False
[requires]
cprocsp/5.0.11732@rutoken/experimental#75066d2cfa02a28f12b562ed4dae876d:f2d37cd7199b4fc0a2b397e64f1ae8247612826e
openssl/3.0.7-cb192d2@rutoken/experimental#c691c52600664b10b7477f3ca576ee9c:ce8dbdeab63ab1f0c7ace120ebfd3611aa5dd75f
pcsclite/1.9.5@rutoken/testing#a50e78deffa149d380cc0a88381cf124:222d94c573a4f4ae5eaee526bc5b3247046770f4
rtcrypt/v0.4.0-19-g84b054d@rutoken/experimental#1f4153c5c04cedc619e3faa2c9e025e8:426334e6c2a31bb34a190b48c3114ef5d7cb9140
rtengine/v3.1.1-5-g5535964@rutoken/experimental#6ab88a1007911bbc294a0ca014658a40:65abe93129f3465e8314430308210bd88e0dbd10
tokenchooser/2234642335593619d04b42b0030559b812c44b55@rutoken/testing#c1280aa905c0fe5ef843c05535fb05a1:f33bea03e0bf2394aee7ddebe87f0cc1795187e1
[python_requires]
rutokenconanfile/0.29.Z@rutoken/testing

ERROR: Missing prebuilt package for 'pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing'
Check the available packages using 'conan list pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing:* -r=remote'
or try to build locally from sources using the '--build=pkcs11ecp/v2.7.1.0-4-gaa62c24b@rutoken/testing' argument

More Info at 'https://docs.conan.io/2/knowledge/faq.html#error-missing-prebuilt-package'
```


Sorry, I can't write a small example, which reproduce my problem

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: lo1ol
issue_13427: state: open
title: [feature] Configurable remotes.json via global.conf
body: Hi.

My company is an active user of conan for dependency management. First of all, thanks for all of your efforts! We're very satisfied with conan 2.0!

I'd like to have an option to specify `remotes.json` location via configuration file `global.conf`.
Currently, we use conan to automatically download dependencies which are stored on multiple repositories. To make this as easy as possible for the developer, whole process is automated (cmake settings are auto-detected, remotes are automatically added, etc.).

I'd like to package individual `remotes.json` for each individual project, so that I can easily install them and not worry about overriding user's default `remotes.json` file.
I know that I have an option to specify `CONAN_HOME` (conanv2) environment variable, but in that case, I do not share the cache between the projects, which is something that I'd like, since some dependencies are shared between projects.

My suggestion would be to add new entry in `global.conf`, such as `core.remotes_file_path`, which would enable simpler process of installing project specific files, without interfering with user's default settings.

Kind regards

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: mzukovec
issue_13407: state: open
title: [question] How to proparate transitive build dependencies (Conan v2)?
body: ### What is your question?

Suppose I have tools `tool_a` and `tool_b` where the latter depends on the former with some specific set of options.

So I have `tool_a` recipe with
```python
    options = {"an_option": [True, False], ...}
    default_options =  {"an_option": False, ...}

    def package_info(self):
        self.buildenv_info.define("TOOL_A_ENV", "value")
```
and `tool_b` recipe with
```python
    def requirements(self):
        self.requires("tool_a/1.0", run=True)

    def configure(self):
        self.options["tool_a"].an_option = True
```
Now `lib_c` requires `tool_b` for its build:
```python
    generators = "VirtualBuildEnv"

    def build_requirements(self):
        self.tool_requires("tool_b/1.0")
```
and I have two problems while building `lib_c`. 1) `self.options["tool_a"].an_option = True` is just ignored and `tool_a` gets the default set of options. 2) `TOOL_A_ENV` does not appear in the generated `conanbuildenv-release-x86_64.bat`. Can you explain what I'm doing wrong?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: db4
issue_13405: state: open
title: [question] shared library not found when running test package
body: ### What is your question?

Hi!

I'm migrating my packages to conan 2 and I have problem with linux build (macos build work OK for some reason). Here is the erro in the build log:
https://github.com/cppfw/nitki/actions/runs/4375079406/jobs/7671051614#step:10:220

The problem is that package `nitki` which I'm currently migrating to conan 2 depends on package `opros` and package `utki` which are already migrated. Package `opros`, in turn, also depends on `utki`.
Package `opros` did not have this problem with test_package test run, so I suppose the package`utki` is packaged properly. But `nitki` has this problem:

```console
======== Testing the package: Executing test ========
nitki/307a2bfc7d8ff4f684b63f77801a4da4c30340b5@cppfw/main (test package): Running test()
nitki/307a2bfc7d8ff4f684b63f77801a4da4c30340b5@cppfw/main (test package): RUN: ./example
./example: error while loading shared libraries: libutki.so.3: cannot open shared object file: No such file or directory

ERROR: nitki/307a2bfc7d8ff4f684b63f77801a4da4c30340b5@cppfw/main (test package): Error in test() method, line 22
	self.run(".%sexample" % os.sep, env="conanbuild") # env sets LD_LIBRARY_PATH etc. to find dependency libs
	ConanException: Error 127 while executing
Error: Process completed with exit code 1.
```

it cannot find the `libtuki.so.3` shared library.

in the `conanfile.py` of the test_package I'm using `conanbuild` environment, so I suppose it should have set `LD_LIBRARY_PATH` to point to the directory where to find the lib:
```python
self.run(".%sexample" % os.sep, env="conanbuild")
```

I would be greatful for help with figuring out why it happens.

Thanks!

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: igagis
issue_13393: state: open
title: [feature] --conf option for CMakeToolchain.user_presets_location
body: ### What is your suggestion?

Hi,
The request is to add a command line option to configure `CMakeToolchain.user_presets_location`. The functionality I'm looking for was present in the [first revision](https://github.com/conan-io/conan/pull/11917/commits/5a13c4e7947eae713b4ee5dae71e462e22910981) of #11917, but was removed during review.

This is my use case:
I have a subset of recipes from conan-center-index in a private repo. We don't plan on making any changes to the recipes. Currently, calling `conan create` leaves me with a dirty repo because it creates several files under `test_package`. For instance, with gtest I get

```
?? recipes/gtest/all/test_package/CMakeUserPresets.json
?? recipes/gtest/all/test_package/build/
```

I just want to build a binary package and upload it to artifactory, so I don't need CMakeUserPresets to be generated. Being able to set `user_presets_location = False` from the command line would allow me to avoid having to patch the recipe.


-------

I have a related question in this area too. I tried to disable CMakeUserPresets by modifying the recipe but the files are generated regardless (I'm using conan 2.0.0). This is the change I made to the gtest `conanfile.py` from conan-center-index, what am I doing wrong here?

```
diff --git a/recipes/gtest/all/conanfile.py b/recipes/gtest/all/conanfile.py
index 198ee6f..4c2da3c 100644
--- a/recipes/gtest/all/conanfile.py
+++ b/recipes/gtest/all/conanfile.py
@@ -118,6 +118,7 @@ class GTestConan(ConanFile):
         if Version(self.version) < "1.12.0":
             # Relocatable shared lib on Macos
             tc.cache_variables["CMAKE_POLICY_DEFAULT_CMP0042"] = "NEW"
+        tc.user_presets_path = False
         tc.generate()

     def _patch_sources(self):
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: praetorian20
issue_13372: state: open
title: [feature] conan2: Add asmflags configuration variable for CMakeToolchain
body: ### What is your suggestion?

I would like for conan to be able to use a `[conf]` variable like `tools.build:cxxflags` but for flags to the assembler, e.g. `tools.build:asmflags` when using [CMakeToolchain](https://docs.conan.io/2/reference/tools/cmake/cmaketoolchain.html). This would have the effect of appending to `CMAKE_ASM_FLAGS_INIT`.

There may be some slight similarity here to an old issue #3083, but this is different in that it would not try and automatically figure out any flags to pass. Only the flags explicitly set in `[conf]` via the chosen `tools.build` variable would apply.

This isn't a bug, but as a "workaround" I am presently using a user `[conf]` variable in conjunction with a `python-requires` module function to add this functionality for myself by defining an `asmflags` variable in the `extra_flags` block. It also appends to the template for the `extra_flags` and `cmake_flags_init` blocks in the same way as the other `cflags`, `cxxflags`, etc.

If the maintainers are amenable to this request, I am comfortable submitting a PR.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: stumt
issue_13363: state: open
title: copy conanfile.py before calling `export()` and `export_sources()`
body: Ref: #13362
Changelog: (Feature): copy conanfile.py before calling export() and export_sources()

Docs: https://github.com/conan-io/docs/pull/XXXX

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [x] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 

<sup>**Note:** By default this PR will skip the slower tests and will use a limited set of python versions. Check [here](https://github.com/conan-io/conan/blob/develop/.github/PR_INCREASE_TESTING.md) how to increase the testing level by writing some tags in the current PR body text.</sup>

user: thorsten-klein
issue_13362: state: open
title: [bug] conanfile.py is overwritten in cache after `export()` method
body: ### Environment details

* Operating System+version: Ubuntu 20
* Compiler+version: -
* Conan version: - 
* Python version: 3.8.10


### Steps to reproduce

Related to #13273 

Users might want to manipulate the conanfile.py during `export()`. 
Currently the conanfile.py is overwritten after the `export()` and `export_sources()`

a reproducing test you can find in the mentioned Pull Request


### Logs

_No response_
user: thorsten-klein
issue_13361: state: open
title: [question] How to specify visibility of system libs and frameworks so that they are propagated with transitive_headers?
body: ### What is your question?

It seems that system_libs of recipes in requirements of another recipe are not propagated when `transitive_headers=True`, even if this dependency is header-only.

What is the idiomatic way to specify that system libs are public dependencies of a recipe? I would have assumed that defines, system libs & frameworks would be considered INTERFACE (in the CMake sense) properties by default (after all, they can be skipped conditionally in package_info() when shared=True to achieve PRIVATE meaning).

Example in ceres-solver: https://github.com/conan-io/conan-center-index/pull/14855 (but before commit https://github.com/conan-io/conan-center-index/pull/14855/commits/fe0f57f2a39eef756ec5b9ca16ffcefab086d770)

eigen (header only) is a public dependency of ceres-solver, so there is `self.requires("eigen/3.4.0", transitive_headers=True)` in ceres-solver. eigen has `m` in its system libs. But test package of ceres-solver fails in v2 pipeline with undefined references to exp (from libm): https://c3i.jfrog.io/c3i/misc-v2/logs/pr/14855/12-linux-gcc/ceres-solver/1.14.0/488cfcde5dee2f2fbd264f05e972aa3db7a0a09e-test.txt

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: SpaceIm
issue_13302: state: open
title: private linking of transitive dependencies
body: I've setup a small [example](https://github.com/tbsuht/conan-private-linking). If this is not related to the topic of the discussion above, we can also move this into a new issue.

The relationship is as follows ("->" == "depends on"):
app -> libB
libB -> libA
libA -> libX & libY

Build via:
```
cd libX
conan create . -pr:h default -pr:b default -s build_type=Release

cd libY
conan create . -pr:h default -pr:b default -s build_type=Release

cd libA
conan create . -pr:h default -pr:b default -s build_type=Release

cd app
conan create . -pr:h default -pr:b default -s build_type=Release
```

This is failing with:
```
Scanning dependencies of target app
[ 80%] Building CXX object src/app/CMakeFiles/app.dir/app.cpp.o
[ 80%] Building CXX object src/app/CMakeFiles/app.dir/main.cpp.o
[100%] Linking CXX executable app
/usr/bin/ld: warning: liblibX.so, needed by /home/user/.conan/data/libA/1.0.0/_/_/package/b2bcf496ea6094c509a11d681ff126c83f01fc2f/lib/liblibA.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: liblibY.so, needed by /home/user/.conan/data/libA/1.0.0/_/_/package/b2bcf496ea6094c509a11d681ff126c83f01fc2f/lib/liblibA.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /home/user/.conan/data/libA/1.0.0/_/_/package/b2bcf496ea6094c509a11d681ff126c83f01fc2f/lib/liblibA.so: undefined reference to `libY()'
/usr/bin/ld: /home/user/.conan/data/libA/1.0.0/_/_/package/b2bcf496ea6094c509a11d681ff126c83f01fc2f/lib/liblibA.so: undefined reference to `libX()'
collect2: error: ld returned 1 exit status
make[2]: *** [src/app/CMakeFiles/app.dir/build.make:100: src/app/app] Error 1
make[1]: *** [CMakeFiles/Makefile2:160: src/app/CMakeFiles/app.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
```

The error is gone once you link libB PUBLIC against libA.
`target_link_libraries(libB PUBLIC libA::libA)`

I was wondering whether this is related to [this issue](https://github.com/conan-io/conan/issues/13000), but I might be wrong.

```
$ conan --version
Conan version 1.53.0
```

_Originally posted by @tbsuht in https://github.com/conan-io/conan/issues/7192#issuecomment-1451741971_
            
user: memsharded
issue_13290: state: open
title: [bug] package-specific tools.build:compiler_executables has no effect
body: ### Environment details

* Operating System+version: Windows 10
* Compiler+version: VS Build Tools 2022
* Conan version: 1.58.0
* Python version: 3.7.5


### Steps to reproduce

I would like to use the clang frontend of MSVC coming with the Build Tools installation by default but this does not work for the openssl package so i want to override the `conf` setting for this package only. This does not seem to work, meaning `clang` is also used for `openssl`.

1. Set the following in a profile:
```
[conf]
tools.build:compiler_executables={'c': 'clang', 'c++': 'clang'}
openssl:tools.build:compiler_executables=!
```
2. Run `conan install --profile <theprofile> --build=openssl openssl/1.1.1s@`
3. openssl build fails since `clang` is used with cl.exe-specific args

The order of the conf entries in the profile should be ok, its also correct in the output of `conan install` but still `clang` is actually used instead of the default `cl`

### Logs

```
conan install --profile debug --build=missing ..
Configuration (profile_host):
[settings]
arch=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=20
compiler.runtime=dynamic
compiler.runtime_type=Debug
compiler.runtime_version=v143
compiler.version=15
os=Windows
[options]
[build_requires]
[env]
[conf]
tools.build:compiler_executables={'c': 'clang', 'c++': 'clang'}
tools.cmake.cmaketoolchain:generator=Ninja
tools.env.virtualenv:auto_use=True
openssl:tools.build:compiler_executables=!

Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.cppstd=20
compiler.runtime=MD
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
[conf]

...

openssl/1.1.1s: Applying build-requirement: nasm/2.15.05
openssl/1.1.1s: Applying build-requirement: strawberryperl/5.32.1.1
openssl/1.1.1s: WARN: Build folder is dirty, removing it: C:\.conan\9308e6\1
openssl/1.1.1s: Copying sources to build folder
openssl/1.1.1s: Building your package in C:\.conan\9308e6\1
openssl/1.1.1s: Generator txt created conanbuildinfo.txt
openssl/1.1.1s: Calling generate()
openssl/1.1.1s: Aggregating env generators
openssl/1.1.1s: Calling build()
openssl/1.1.1s: Apply patch (portability): TVOS and WatchOS don't like fork()
openssl/1.1.1s: gen_info = {'CFLAGS': ['-MDd', '-Zi', '-Ob0', '-Od'], 'CXXFLAGS': ['-MDd', '-Zi', '-Ob0', '-Od'], 'DEFINES': [], 'LDFLAGS': ['-debug']}
openssl/1.1.1s: using target: VC-conan-Debug-Windows-x86_64-Visual Studio-17 -> VC-WIN64A
openssl/1.1.1s: my %targets = (
    "VC-conan-Debug-Windows-x86_64-Visual Studio-17" => {
        inherit_from => [ "VC-WIN64A" ],
        cflags => add("-MDd -Zi -Ob0 -Od"),
        cxxflags => add("-MDd -Zi -Ob0 -Od"),

        includes => add(),
        lflags => add("-debug"),








    },
);

openssl/1.1.1s: ['"VC-conan-Debug-Windows-x86_64-Visual Studio-17"', 'no-shared', '--prefix=/', '--openssldir="res"', 'no-unit-test', 'threads', 'PERL=C:/.conan/1d86f0b/1/bin/perl.exe', 'no-tests', '--debug', '--libdir=lib', 'no-md2']
openssl/1.1.1s: WARN: replace_in_file didn't find pattern '/MTd ' in 'Configurations\10-main.conf' file.
openssl/1.1.1s: WARN: replace_in_file didn't find pattern '/MTd"' in 'Configurations\10-main.conf' file.
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.4.4
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
Configuring OpenSSL version 1.1.1s (0x1010113fL) for VC-conan-Debug-Windows-x86_64-Visual Studio-17
Using os-specific seed configuration
Creating configdata.pm
Creating makefile

**********************************************************************
***                                                                ***
***   OpenSSL has been successfully configured                     ***
***                                                                ***
***   If you encounter a problem while building, please open an    ***
***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
***   and include the output from the following command:           ***
***                                                                ***
***       perl configdata.pm --dump                                ***
***                                                                ***
***   (If you are new to OpenSSL, you might want to consult the    ***
***   'Troubleshooting' section in the INSTALL file first)         ***
***                                                                ***
**********************************************************************
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.4.4
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

Microsoft (R) Program Maintenance Utility Version 14.34.31937.0
Copyright (C) Microsoft Corporation.  All rights reserved.

        "C:/.conan/1d86f0b/1/bin/perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "include\crypto\bn_conf.h.in" > include\crypto\bn_conf.h
        "C:/.conan/1d86f0b/1/bin/perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "include\crypto\dso_conf.h.in" > include\crypto\dso_conf.h
        "C:/.conan/1d86f0b/1/bin/perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "include\openssl\opensslconf.h.in" > include\openssl\opensslconf.h
        "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.34.31933\bin\HostX64\x64\nmake.exe" /                   depend && "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.34.31933\bin\HostX64\x64\nmake.exe" /                   _all

Microsoft (R) Program Maintenance Utility Version 14.34.31937.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Microsoft (R) Program Maintenance Utility Version 14.34.31937.0
Copyright (C) Microsoft Corporation.  All rights reserved.

        clang  /Zi /Fdossl_static.pdb /MDd /Zl /Gs0 /GF /Gy -MDd -Zi -Ob0 -Od -MDd -Zi -Ob0 -Od /I "." /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"\\res\"" -D"ENGINESDIR=\"\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"DEBUG" -D"_DEBUG"  -c /Foapps\app_rand.obj "apps\app_rand.c"
clang: error: unknown argument: '-MDd'
clang: error: unknown argument: '-MDd'
clang: error: no such file or directory: '/Zi'
clang: error: no such file or directory: '/Fdossl_static.pdb'
clang: error: no such file or directory: '/MDd'
clang: error: no such file or directory: '/Zl'
clang: error: no such file or directory: '/Gs0'
clang: error: no such file or directory: '/GF'
clang: error: no such file or directory: '/Gy'
clang: error: no such file or directory: '/I'
clang: error: no such file or directory: '/I'
clang: error: no such file or directory: '/Foapps\app_rand.obj'
clang: error: unsupported use of internal gcc -Z option '-Zi'
clang: warning: .: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: include: 'linker' input unused [-Wunused-command-line-argument]
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\Llvm\x64\bin\clang.EXE"' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.34.31933\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
openssl/1.1.1s:
openssl/1.1.1s: ERROR: Package '164640aad040835ac89882393a96d89200694f04' build failed
openssl/1.1.1s: WARN: Build folder C:\.conan\9308e6\1\build-debug
ERROR: openssl/1.1.1s: Error in build() method, line 727
        self.run('nmake /F Makefile')
        ConanException: Error 2 while executing nmake /F Makefile
```
user: petermbauer
issue_13280: state: open
title: [question] Parse buildenv variables in conanfile.py
body: ### What is your question?

#### Environment
- OS: Debian 11
- Python version: 3.9.2
- Conan version: 2.0.0

Hi there!
Scenario:
Let's say there is a library with the autotools build system, particularly FFmpeg. Now, FFmpeg has some interesting quirks regarding it's build system, as it ships with a rather odd configure file. Whenever the user cross-compiles, it always uses the system-wide compiler binaries, if not told otherwise explicitly.
Say we want to cross-compile from Linux to OSX using an [osxcross](https://github.com/tpoechtrager/osxcross) toolchain.
Having `CC=<toolchain>/bin/arm64-apple-darwin21.4-clang` is not enough, we have to supply it  with:
`--cc=<toolchain>/bin/arm64-apple-darwin21.4-clang`

This is particularly problematic, as conan altered the environment variable setting in 2.0 amongst many other things, so instead of defining a simple [env], we have to use [buildenv] and [runenv]. This is fine in itself, however, the access to these specific env variables are quite tricky. There is not documentation on this, so I had to come up with this solution:

`CC = self._conan_buildenv.get_profile_env("").vars(self).get('CC')`

However, this will result in the following value in our case (see toolchain profile below):
`$toolchain_path/bin/$target_host-$cc_compiler`
The variables are not expanded. I either have to do manual parsing by iterating over all variable references, or I'm missing something. I also cannot burn-in the full toolchain path variables, as these will be parsed from a property-like file from the client side.
Any help is appreciated.

Ps: The [official conanfile](https://conan.io/center/ffmpeg?os=Linux&tab=overview) for ffmpeg is outdated, many functions (including the env variable handling) are deprecated, I cannot use that unfortunately for conan 2.0.

Cross toolchain profile (`osxcross.jinja`):
```
[buildenv]
...
CHOST=$target_host
CC=$toolchain_path/bin/$target_host-$cc_compiler
CXX=$toolchain_path/bin/$target_host-$cxx_compiler
cc_compiler=clang
cxx_compiler=clang++
toolchain_path=<path>/macosx-12.3-cross-toolchain
target_host=aarch64-apple-darwin21.4
```
(The reversed ordering is intentional, as conan exports the last entries first)

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: donlk
issue_13265: state: open
title: [question] Best practice reusing dependencies via lock file for new package version creation
body: ### What is your question?

What is the best practice reusing dependencies via lock file for new package version creation?

Context: Conan 1.x

We are now introducing lockfiles to baseline a set of dependencies used for the creation of a package.
Let's say we created package A in version 1 by using a lockfile.
In the created lock file there is a node 0 entry representing the package with a ref "A/1"

Now we want to create A in version 2 reusing the same dependencies ( = reusing the same lockfile).
This all works fine until we come to the export-pkg step. Here Conan is complaining that the ref of the "0" node (the package to be created) is not matching the ref of the package that shall be created/exported.

How can we resolve this problem?

PS. We know that with Conan 2.x the lockfile mechanism will change a lot but we will stick to Conan 1.x for a longer time and rather in parallel setup Conan 2.x packaging for testing/poc purposes.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: MTomBosch
issue_13258: state: open
title: [feature] Include build/run environment variables in --format=json output
body: ### What is your suggestion?

The json generator in Conan 1 included the environment variables set by the installed packages in the deps_env_info section. This generator was replaced by the `--format=json` flag in Conan 2, but its output does not include environment variables. They are present in the conanbuildenv/conanrunenv scripts, but those are more painful to properly parse out programmatically than JSON.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: sfackler
issue_13257: state: open
title: [question] clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
body: ### What is your question?

Hi,

I'm trying to cross compile for iOS. I got the following error
```
clang: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
clangclang: : warningwarning: : no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]

clangclang: : errorerror: : invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'

clangclang: : errorerror: : invalid version number in '-mmacosx-version-min=14.0'invalid version number in '-mmacosx-version-min=14.0'

clang: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'clang
: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
clang: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:205: CMakeFiles/zlibstatic.dir/inftrees.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:192: CMakeFiles/zlibstatic.dir/infback.o] Error 1
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:140: CMakeFiles/zlibstatic.dir/gzlib.o] Error 1
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:179: CMakeFiles/zlibstatic.dir/inflate.o] Error 1
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:166: CMakeFiles/zlibstatic.dir/gzwrite.o] Error 1
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:88: CMakeFiles/zlibstatic.dir/compress.o] Error 1
clang: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
[ 41%] Building C object CMakeFiles/zlib.dir/gzclose.o
[ 41%] Building C object CMakeFiles/zlib.dir/compress.o
[ 41%] Building C object CMakeFiles/zlib.dir/crc32.o
[ 44%] Building C object CMakeFiles/zlib.dir/gzlib.o
[ 47%] Building C object CMakeFiles/zlib.dir/deflate.o
[ 50%] Building C object CMakeFiles/zlib.dir/gzread.o
make[2]: *** [CMakeFiles/zlib.dir/build.make:75: CMakeFiles/zlib.dir/adler32.o] Error 1
make[2]: *** Waiting for unfinished jobs....
clangclang: clangclangclang: : : warningwarning: : : warningwarningno such sysroot directory: 'iphoneos' [-Wmissing-sysroot]warningno such sysroot directory: 'iphoneos' [-Wmissing-sysroot]: : : 

no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]


clangclang: : errorerror: : clangclang: : invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'errorerror

: : clanginvalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'clang: : 

errorerrorclang: clang: : : invalid version number in '-mmacosx-version-min=14.0'errorinvalid version number in '-mmacosx-version-min=14.0'error: : 

invalid version number in '-mmacosx-version-min=14.0'invalid version number in '-mmacosx-version-min=14.0'

clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:114: CMakeFiles/zlibstatic.dir/deflate.o] Error 1
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:75: CMakeFiles/zlibstatic.dir/adler32.o] Error 1
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:101: CMakeFiles/zlibstatic.dir/crc32.o] Error 1
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:127: CMakeFiles/zlibstatic.dir/gzclose.o] Error 1
make[2]: *** [CMakeFiles/zlibstatic.dir/build.make:153: CMakeFiles/zlibstatic.dir/gzread.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:115: CMakeFiles/zlibstatic.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
clang: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
clang: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
clang: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
clang: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
make[2]: *** [CMakeFiles/zlib.dir/build.make:140: CMakeFiles/zlib.dir/gzlib.o] Error 1
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
clang: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
clang: warning: no such sysroot directory: 'iphoneos' [-Wmissing-sysroot]
clang: error: invalid argument '-mmacosx-version-min=14.0' not allowed with '-miphoneos-version-min=14.0'
clang: error: invalid version number in '-mmacosx-version-min=14.0'
make[2]: *** [CMakeFiles/zlib.dir/build.make:153: CMakeFiles/zlib.dir/gzread.o] Error 1
make[2]: *** [CMakeFiles/zlib.dir/build.make:101: CMakeFiles/zlib.dir/crc32.o] Error 1
make[2]: *** [CMakeFiles/zlib.dir/build.make:88: CMakeFiles/zlib.dir/compress.o] Error 1
make[2]: *** [CMakeFiles/zlib.dir/build.make:127: CMakeFiles/zlib.dir/gzclose.o] Error 1
make[2]: *** [CMakeFiles/zlib.dir/build.make:114: CMakeFiles/zlib.dir/deflate.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:89: CMakeFiles/zlib.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
zlib/1.2.13: 
zlib/1.2.13: ERROR: Package 'b05af63153a8ce37f60bad20fc8e8230576d28da' build failed
zlib/1.2.13: WARN: Build folder /root/.conan/data/zlib/1.2.13/_/_/build/b05af63153a8ce37f60bad20fc8e8230576d28da/build/Release
ERROR: zlib/1.2.13: Error in build() method, line 45
	cmake.build()
	ConanException: Error 2 while executing cmake --build "/root/.conan/data/zlib/1.2.13/_/_/build/b05af63153a8ce37f60bad20fc8e8230576d28da/build/Release" '--' '-j12'
```

The question is how can I remove `'-mmacosx-version-min=14.0'errorinvalid version number in '-mmacosx-version-min=14.0'` so clang doesn't complain.

See my config below
profile
```
[settings]
os=iOS
os.sdk=iphoneos
os.version=14.0
arch=armv8
compiler=apple-clang
compiler.libcxx=libstdc++
compiler.cppstd=14
compiler.version=10.0
build_type=Release

[options]

[tool_requires]
toolchain_iosxc-arm64/0.1.0

[env]
CC=/ios_deps_arm64/bin/arm-apple-darwin11-clang
CXX=/ios_deps_arm64/bin/arm-apple-darwin11-clang++
```

iOS toolchain
```
# Toolchain for iOS arm64 target

# Standard settings
set (CMAKE_SYSTEM_NAME Darwin)
set (CMAKE_SYSTEM_VERSION 1)
set (UNIX True)
set (APPLE True)
set (IOS True)

set(CMAKE_C_COMPILER /ios_deps_arm64/bin/arm-apple-darwin11-clang)
set(CMAKE_CXX_COMPILER /ios_deps_arm64/bin/arm-apple-darwin11-clang++)

set(_CMAKE_TOOLCHAIN_PREFIX arm-apple-darwin11-)

set(CMAKE_IOS_SDK_ROOT "/ios_deps_arm64/SDK/iPhoneOS14.0.sdk")

# Set the sysroot default to the most recent SDK
set(CMAKE_OSX_SYSROOT ${CMAKE_IOS_SDK_ROOT} CACHE PATH "Sysroot used for iOS support")

# set the architecture for iOS
set(IOS_ARCH arm64)

set(CMAKE_OSX_ARCHITECTURES ${IOS_ARCH} CACHE STRING "Build architecture for iOS")
set(CMAKE_SYSTEM_PROCESSOR ${IOS_ARCH})

if(NOT DEFINED ENABLE_BITCODE)
    # disable bitcode support by default
    set(ENABLE_BITCODE FALSE CACHE BOOL "enable bitcode")
endif()

set(CMAKE_C_COMPILER_FORCED TRUE) # forces CMake to skip compiler checks
set(CMAKE_CXX_COMPILER_FORCED TRUE)

set(APPLE_FLAGS "-isystem ${CMAKE_IOS_SDK_ROOT}/usr/include/c++ -framework AVFoundation -framework CoreGraphics -framework CoreMedia -framework CoreVideo -framework CoreFoundation -framework Foundation")
set(CMAKE_C_FLAGS "${APPLE_FLAGS} ${CMAKE_C_FLAGS}")
set(CMAKE_CXX_FLAGS "${APPLE_FLAGS} ${CMAKE_CXX_FLAGS}")

if(ENABLE_BITCODE)
    # enable bitcode
    set(CMAKE_C_FLAGS "-fembed-bitcode ${CMAKE_C_FLAGS}")
    set(CMAKE_CXX_FLAGS "-fembed-bitcode ${CMAKE_CXX_FLAGS}")
endif()

# Set the find root to the iOS developer roots and to user defined paths
set(CMAKE_FIND_ROOT_PATH ${CMAKE_IOS_DEVELOPER_ROOT} ${CMAKE_IOS_SDK_ROOT} ${CMAKE_PREFIX_PATH} CACHE STRING "iOS find search path root")

# searching for frameworks only
set(CMAKE_FIND_FRAMEWORK FIRST)

# set up the default search directories for frameworks
set(CMAKE_SYSTEM_FRAMEWORK_PATH
    ${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks
)

```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: cocoza4
issue_13255: state: open
title: [question] cmake not found when cross compiling for iOS
body: ### What is your question?

Hi,
I'm trying to cross compile for iOS using a user toolchain. I have cmake `3.22.1` installed locally. I could build with other profiles except with iOS.

When I run build
```
conan create . -pr:h /workspace/conan/profiles/iosxc-arm64 -pr:b default -tf=None
```
I got 
```root@peeranat:/workspace/3rdparty/zlib# conan create . -pr:h /workspace/conan/profiles/iosxc-arm64 -pr:b default -tf=None
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'url'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'license'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'description'. It is recommended to add it as attribute
Exporting package recipe
zlib/1.2.13: The stored package has not changed
zlib/1.2.13: Exported revision: 13561d4c3d463d06ad577c9b3d93d7ac
Configuration (profile_host):
[settings]
arch=armv8
build_type=Release
compiler=apple-clang
compiler.cppstd=14
compiler.libcxx=libstdc++
compiler.version=10.0
os=iOS
os.sdk=iphoneos
os.version=14.0
[options]
[build_requires]
*: toolchain_iosxc-arm64/0.1.0
[env]
LD_LIBRARY_PATH=/ios_deps_arm64/lib:$LD_LIBRARY_PATH
PATH=/ios_deps_arm64/bin:$PATH
Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

zlib/1.2.13: Forced build from source
Installing package: zlib/1.2.13
Requirements
    zlib/1.2.13 from 'artifactory' - Cache
Packages
    zlib/1.2.13:b05af63153a8ce37f60bad20fc8e8230576d28da - Build
Build requirements
    toolchain_iosxc-arm64/0.1.0 from local cache - Cache
Build requirements packages
    toolchain_iosxc-arm64/0.1.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache

Cross-build from 'Linux:x86_64' to 'iOS:armv8'
Installing (downloading, building) binaries...
toolchain_iosxc-arm64/0.1.0: Already installed!
zlib/1.2.13: Applying build-requirement: toolchain_iosxc-arm64/0.1.0
zlib/1.2.13: WARN: Build folder is dirty, removing it: /root/.conan/data/zlib/1.2.13/_/_/build/b05af63153a8ce37f60bad20fc8e8230576d28da
zlib/1.2.13: Copying sources to build folder
zlib/1.2.13: Building your package in /root/.conan/data/zlib/1.2.13/_/_/build/b05af63153a8ce37f60bad20fc8e8230576d28da
zlib/1.2.13: Generator 'CMakeDeps' calling 'generate()'
zlib/1.2.13: Calling generate()
zlib/1.2.13: Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
zlib/1.2.13: If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/root/.conan/data/zlib/1.2.13/_/_/build/b05af63153a8ce37f60bad20fc8e8230576d28da/build/Release/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
zlib/1.2.13: Aggregating env generators
zlib/1.2.13: Calling build()
zlib/1.2.13: CMake command: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/root/.conan/data/zlib/1.2.13/_/_/build/b05af63153a8ce37f60bad20fc8e8230576d28da/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/root/.conan/data/zlib/1.2.13/_/_/package/b05af63153a8ce37f60bad20fc8e8230576d28da" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/root/.conan/data/zlib/1.2.13/_/_/build/b05af63153a8ce37f60bad20fc8e8230576d28da/."
/bin/sh: 1: cmake: not found
zlib/1.2.13: 
zlib/1.2.13: ERROR: Package 'b05af63153a8ce37f60bad20fc8e8230576d28da' build failed
zlib/1.2.13: WARN: Build folder /root/.conan/data/zlib/1.2.13/_/_/build/b05af63153a8ce37f60bad20fc8e8230576d28da/build/Release
ERROR: zlib/1.2.13: Error in build() method, line 29
	cmake.configure()
	ConanException: Error 127 while executing cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/root/.conan/data/zlib/1.2.13/_/_/build/b05af63153a8ce37f60bad20fc8e8230576d28da/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/root/.conan/data/zlib/1.2.13/_/_/package/b05af63153a8ce37f60bad20fc8e8230576d28da" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/root/.conan/data/zlib/1.2.13/_/_/build/b05af63153a8ce37f60bad20fc8e8230576d28da/."
```

Code below


profile `iosxc-arm64`
```
[settings]
os=iOS
os.sdk=iphoneos
os.version=14.0
arch=armv8
compiler=apple-clang
compiler.libcxx=libstdc++
compiler.cppstd=14
compiler.version=10.0
build_type=Release

[options]

[tool_requires]
toolchain_iosxc-arm64/0.1.0

[env]
PATH=/ios_deps_arm64/bin:$PATH
LD_LIBRARY_PATH=/ios_deps_arm64/lib:$LD_LIBRARY_PATH
```

iOS toolchain
```
# Toolchain for iOS arm64 target

# Standard settings
set (CMAKE_SYSTEM_NAME Darwin)
set (CMAKE_SYSTEM_VERSION 1)
set (UNIX True)
set (APPLE True)
set (IOS True)

set(CMAKE_C_COMPILER arm-apple-darwin11-clang)
set(CMAKE_CXX_COMPILER arm-apple-darwin11-clang++)

set(_CMAKE_TOOLCHAIN_PREFIX arm-apple-darwin11-)

set(CMAKE_IOS_SDK_ROOT "/ios_deps_arm64/SDK/iPhoneOS14.0.sdk")

# Set the sysroot default to the most recent SDK
set(CMAKE_OSX_SYSROOT ${CMAKE_IOS_SDK_ROOT} CACHE PATH "Sysroot used for iOS support")

# set the architecture for iOS
set(IOS_ARCH arm64)

set(CMAKE_OSX_ARCHITECTURES ${IOS_ARCH} CACHE STRING "Build architecture for iOS")
set(CMAKE_SYSTEM_PROCESSOR ${IOS_ARCH})

if(NOT DEFINED ENABLE_BITCODE)
    # disable bitcode support by default
    set(ENABLE_BITCODE FALSE CACHE BOOL "enable bitcode")
endif()

set(APPLE_FLAGS "-isystem ${CMAKE_IOS_SDK_ROOT}/usr/include/c++ -framework AVFoundation -framework CoreGraphics -framework CoreMedia -framework CoreVideo -framework CoreFoundation -framework Foundation")
set(CMAKE_C_FLAGS "${APPLE_FLAGS} ${CMAKE_C_FLAGS}")
set(CMAKE_CXX_FLAGS "${APPLE_FLAGS} ${CMAKE_CXX_FLAGS}")

if(ENABLE_BITCODE)
    # enable bitcode
    set(CMAKE_C_FLAGS "-fembed-bitcode ${CMAKE_C_FLAGS}")
    set(CMAKE_CXX_FLAGS "-fembed-bitcode ${CMAKE_CXX_FLAGS}")
endif()

# Set the find root to the iOS developer roots and to user defined paths
set(CMAKE_FIND_ROOT_PATH ${CMAKE_IOS_DEVELOPER_ROOT} ${CMAKE_IOS_SDK_ROOT} ${CMAKE_PREFIX_PATH} CACHE STRING "iOS find search path root")

# searching for frameworks only
set(CMAKE_FIND_FRAMEWORK FIRST)

# set up the default search directories for frameworks
set(CMAKE_SYSTEM_FRAMEWORK_PATH
    ${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks
)
```

ZLIB Recipe
```
from conan import ConanFile
from conan.tools.files import get
from conan.tools.cmake import CMake, CMakeToolchain, cmake_layout

class ZLIBConan(ConanFile):
  name = "zlib"

  version = "1.2.13"

  settings = "os", "compiler", "build_type", "arch"

  generators = "CMakeDeps"

  def source(self):
    get(self, f"https://github.com/madler/zlib/archive/refs/tags/v{self.version}.tar.gz", strip_root=True)

  def generate(self):
    tc = CMakeToolchain(self)
    if self.settings.os != "Windows":
      tc.variables["CMAKE_C_FLAGS"] = "-fPIC"
      tc.variables["CMAKE_CXX_FLAGS"] = "-fPIC"
    tc.generate()

  def layout(self):
    cmake_layout(self)

  def build(self):
    cmake = CMake(self)
    cmake.configure()
    cmake.build()

  def package(self):
    cmake = CMake(self)
    cmake.install()

  def package_info(self):
    if self.settings.os == "Windows":
      if self.settings.compiler == "gcc": # mingw
        lib = "libzlibstatic.a"
      else: # msvc
        lib = "zlibstatic.lib"
    else:
      lib = "libz.a"
    self.cpp_info.libs = [lib]
    self.cpp_info.names["cmake_find_package"] = "ZLIB"
    self.cpp_info.set_property("cmake_file_name", "ZLIB")
    self.cpp_info.set_property("cmake_target_name", "ZLIB::ZLIB")
    self.cpp_info.set_property("pkg_config_name", "zlib")
```

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: cocoza4
issue_13246: state: open
title: [bug] Ctrl+Break does not work in conan
body: ### Environment details

* Operating System+version: Windows 10
* Compiler+version:
* Conan version: 2.0
* Python version: 3.11

When conan is stuck in downloading phase or in many other places Ctlr+Break is simply ignored by conan app. And there is no way to stop it, only terminate.

### Steps to reproduce

_No response_

### Logs

_No response_
user: yatagarasu25
issue_13223: state: open
title: [bug] environment variables not expanded before passing to cmake
body: ### Environment details

* Operating System+version: Ubuntu 20.04
* Compiler+version: clang-16
* Conan version: conan 1.59.0
* Python version: 3.10.9


### Steps to reproduce

Attempting to cross -compile from Linux to Android, and I am using environment variables in the ndk path definition.

The result of that is that in the generated cmake toolchain file it treats the paths as string literal and just puts it into the toolchain file to include the android.cmake file.
Because cmake has it's own variables and it is not prefixed with the env specification to tell cmake that's an environment variable, it will get reduced to an empty string, obviously failing to find the cmake include.

### Logs

```
Configuration (profile_host):
[settings]
arch=armv8
build_type=Release
compiler=clang
compiler.cppstd=17
compiler.runtime=static
compiler.version=12
os=Android
os.api_level=29
[options]
boost:bzip2=False
boost:error_code_header_only=True
boost:magic_autolink=False
boost:namespace_alias=False
boost:numa=False
boost:pch=False
boost:shared=False
boost:system_no_deprecated=True
boost:system_use_utf8=True
boost:without_atomic=False
boost:without_chrono=False
boost:without_container=False
boost:without_context=True
boost:without_contract=True
boost:without_coroutine=True
boost:without_date_time=False
boost:without_exception=False
boost:without_fiber=True
boost:without_filesystem=True
boost:without_graph=True
boost:without_graph_parallel=True
boost:without_iostreams=True
boost:without_json=True
boost:without_locale=True
boost:without_log=True
boost:without_math=True
boost:without_mpi=True
boost:without_nowide=True
boost:without_program_options=True
boost:without_python=True
boost:without_random=True
boost:without_regex=True
boost:without_serialization=True
boost:without_stacktrace=True
boost:without_system=False
boost:without_test=False
boost:without_thread=False
boost:without_timer=False
boost:without_type_erasure=True
boost:without_url=True
boost:without_wave=True
boost:zlib=False
boost:zstd=False
[build_requires]
[env]
AR=${NDK_BIN}/llvm-ar
ARFLAGS=crs
AS=${NDK_BIN}/aarch64-linux-android-as
CC=${NDK_BIN}/aarch64-linux-android${ANDROID_API}-clang
CXX=${NDK_BIN}/aarch64-linux-android${ANDROID_API}-clang++
LD=${NDK_BIN}/ld
NM=${NDK_BIN}/llvm-nm
OBJCOPY=${NDK_BIN}/llvm-objcopy
RANLIB=${NDK_BIN}/llvm-ranlib
READELF=${NDK_BIN}/llvm-readelf
STRIP=${NDK_BIN}/llvm-strip
ANDROID_API=29
NDK_BIN=${ANDROID_NDK_ROOT}/toolchains/llvm/prebuilt/linux-x86_64/bin
[conf]
tools.android:ndk_path=${ANDROID_NDK_ROOT}

Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=clang
compiler.cppstd=17
compiler.libcxx=libstdc++
compiler.version=16
os=Linux
os_build=Linux
[options]
boost:bzip2=False
boost:error_code_header_only=True
boost:magic_autolink=False
boost:namespace_alias=False
boost:numa=False
boost:pch=False
boost:shared=False
boost:system_no_deprecated=True
boost:system_use_utf8=True
boost:without_atomic=False
boost:without_chrono=False
boost:without_container=False
boost:without_context=True
boost:without_contract=True
boost:without_coroutine=True
boost:without_date_time=False
boost:without_exception=False
boost:without_fiber=True
boost:without_filesystem=True
boost:without_graph=True
boost:without_graph_parallel=True
boost:without_iostreams=True
boost:without_json=True
boost:without_locale=True
boost:without_log=True
boost:without_math=True
boost:without_mpi=True
boost:without_nowide=True
boost:without_program_options=True
boost:without_python=True
boost:without_random=True
boost:without_regex=True
boost:without_serialization=True
boost:without_stacktrace=True
boost:without_system=False
boost:without_test=False
boost:without_thread=False
boost:without_timer=False
boost:without_type_erasure=True
boost:without_url=True
boost:without_wave=True
boost:zlib=False
boost:zstd=False
[build_requires]
[env]
```
user: Sil3ntStorm
issue_13210: state: open
title: [question] How to cross compiling when using generator with AutotoolsToolchain()
body: ### What is your question?

Hello,

I'm cross building the openssl library which using generator with AutotoolsToolchain(). My current conanfile.py works for the CMakeToolchain() as below:
def generate(self):
    tc = CMakeToolchain(self)
    tc.blocks["user_toolchain"].values["paths"] = ["/opt/aarch64-linux-gnu.toolchain.cmake"]
I've no idea how to implement it to autotoolstoolchain. 
Could you please help me with this? Thx.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: lijie-jiang
issue_13201: state: open
title: [feature] conan v2: Provide a config so that all direct requires behave as `force=True` implicitly
body: ### What is your suggestion?

In conan v2, versions conflicts are not resolved automatically. Even a direct dependency of top conanfile does not override transitive dependency version if force=True is not explicitly set in conanfile.py (and it's impossible in conanfile.txt or command line). While this behavior might be desirable in companies with well written conanfile.py, lockfile etc, I don't think it's appropriate for new comers or simple projects with a conanfile.txt, or while testing a recipe with `conan create`, because versions conflicts will always happen in sufficiently complex dependency graphs.
conan-center has never been able to provide a global dependency graph without versions conflicts between transitive dependencies during the past 3 years (just a new version of zlib or openssl takes months to be propagated to all conan-center recipes), so how could it scale?

Therefore I think a config changing the behavior as if all direct dependencies had `force=True` (recursively) would be convenient.

I'm pretty sure that conan-center will be beaten by this graph model very quickly in recipes with many direct & transitive dependencies, like arrow, cairo, cpython, drogon, ffmpeg, folly, gdal, grpc, itk, opencv, qt etc.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: SpaceIm
issue_13174: state: open
title: [bug] could not remove local receipe because of "receipe not found"
body: ### Environment details

* Operating System+version: ubuntu linux
* Conan version: 1.58



### Steps to reproduce

I had a local version of some package `FooBar/1.2.3-beta3@FooBar/stable` installed from a repo `xyz-A`.
The package was removed from `xyz-A` and added to `xyz-B`

A `conan search FooBar` showed me the local package  `FooBar/1.2.3-beta3@FooBar/stable` and a `conan search -r all FooBar` showed me the package within the `xyz-B` but not the `xyz-A`  repo.

Some setup scripts failed because the receipe could not be found, so I tried to remove the local one with 
`conan remove FooBar/1.2.3-beta3@FooBar/stable` 

This failed with the error message `ERROR: Recipe not found: FooBar/1.2.3-beta3@FooBar/stable`

In my search I found this bug: https://github.com/conan-io/conan/issues/5297 and inspired from the description, I tried
`conan remove "FooBar/1.2.3-beta*"` which asked me for all matching packages including the troublesome and removed them without any errors.

I do not think that it is intended that way.

So maybe it is a regression of above Bugticket.




### Logs

_No response_
user: rst-ct
issue_13171: state: open
title: [feature] Consider the re-package concept
body: ### What is your suggestion?

When a package, that is built using artifacts from other packages, can be built, but completely isolating the transitive dependencies. For consumers of that package, the transitive dependencies will not exist.

This might be a useful mechanism for releasing, both internally, but also externally (to other users) without unveiling the internal packages.

I can see at least some custom commands that could implement this via user-side (collect binaries + re-package), but it could be interesting what a ``--build=missing`` means for this kind of package, how the information from dependencies is gathered, how the package_id can be computed while isolating the dependencies.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: memsharded
issue_13167: state: open
title: [question] How to authenticate in GitHub Action using `conan.tools.scm.Git`
body: ### What is your question?

I'm trying to refactor my recipes and make them ready for Conan 2.0. The [migration guide](https://docs.conan.io/en/latest/migrating_to_2.0/recipes.html#the-scm-attribute) has an example that shows the usage of `conan.tools.scm.Git`. However when executing `conan create` inside a GitHub action of a private repository with the new `Git` helper then I get the following error:

```
ERROR: 
	CalledProcessErrorWithStderr: Command 'git clone "https://github.com/xxx/xxx"  .' returned non-zero exit status 128.
Cloning into '.'...
fatal: could not read Username for 'https://github.com/': No such device or address
```

What is the recommended way of passing the `GITHUB_TOKEN` secret or authenticate in general?

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: daniel-eiband-snkeos
issue_13160: state: open
title: V2 version conflicts (overriding from conanfile) do not behave the same
body:               ### Conan v1 pipeline :heavy_check_mark:

All green in build 1 (`10dbee2680c55ef9dbf8135ca3ac8876ee2651c7`):

 * **freeimage/3.18.0@:**
   All packages built successfully! ([All logs](https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/c3i/misc/logs/pr/15941/1/freeimage/3.18.0//summary.json))

----------

### Conan v2 pipeline (informative, not required for merge) :x:

> **Note**: Conan v2 builds are informative and they are not required for the PR to be merged.

The v2 pipeline failed. Please, review the errors and note this will be required for pull requests to be merged in the near future.

<details>

<summary> See details: </summary>

Failure in build 1 (`10dbee2680c55ef9dbf8135ca3ac8876ee2651c7`):

 * **freeimage/3.18.0@:**
   Error running command `conan graph info --requires freeimage/3.18.0@#0158d7ee5d058168115b3fe56e9d3335 -f json  -pr:h /home/conan/w/prod-v2_cci_PR-15941/1/826ba7d4-51af-4186-8976-dd7fdba49b17/profile_linux_11_libstdcpp11_gcc_release_64.-shared-False.txt -pr:b /home/conan/w/prod-v2_cci_PR-15941/1/826ba7d4-51af-4186-8976-dd7fdba49b17/profile_linux_11_libstdcpp11_gcc_release_64.-shared-False.txt`:
   ```
   -------- Input profiles --------
   Profile host:
   [settings]
   arch=x86_64
   build_type=Release
   compiler=gcc
   compiler.libcxx=libstdc++11
   compiler.version=11
   os=Linux
   [options]
   */*:shared=False
   
   Profile build:
   [settings]
   arch=x86_64
   build_type=Release
   compiler=gcc
   compiler.libcxx=libstdc++11
   compiler.version=11
   os=Linux
   [options]
   */*:shared=False
   
   
   -------- Computing dependency graph --------
   freeimage/3.18.0: WARN: G3 plugin and JPEGTransform are disabled.
   zlib/1.2.13: Not found in local cache, looking in remotes...
   zlib/1.2.13: Checking remote: conan-center-v2
   zlib/1.2.13: Trying with 'conan-center-v2'...
   Downloading conan_export.tgz
   Downloading conanfile.py
   Downloading conanmanifest.txt
   Decompressing conan_export.tgz
   zlib/1.2.13: Downloaded recipe revision 13c96f538b52e1600c40b88994de240f
   libjpeg/9e: Not found in local cache, looking in remotes...
   libjpeg/9e: Checking remote: conan-center-v2
   libjpeg/9e: Trying with 'conan-center-v2'...
   Downloading conanfile.py
   Downloading conanmanifest.txt
   Downloading conan_export.tgz
   Decompressing conan_export.tgz
   libjpeg/9e: Downloaded recipe revision 68269859e4325ddc3f995d1fd3fc9187
   openjpeg/2.5.0: Not found in local cache, looking in remotes...
   openjpeg/2.5.0: Checking remote: conan-center-v2
   openjpeg/2.5.0: Trying with 'conan-center-v2'...
   Downloading conanfile.py
   Downloading conan_export.tgz
   Downloading conanmanifest.txt
   Decompressing conan_export.tgz
   openjpeg/2.5.0: Downloaded recipe revision cb3ca9c879e991ad313caa16d7e04169
   libpng/1.6.39: Not found in local cache, looking in remotes...
   libpng/1.6.39: Checking remote: conan-center-v2
   libpng/1.6.39: Trying with 'conan-center-v2'...
   Downloading conanmanifest.txt
   Downloading conanfile.py
   Downloading conan_export.tgz
   Decompressing conan_export.tgz
   libpng/1.6.39: Downloaded recipe revision deca555b0890e584fc895ba756e83c06
   libwebp/1.3.0: Not found in local cache, looking in remotes...
   libwebp/1.3.0: Checking remote: conan-center-v2
   libwebp/1.3.0: Trying with 'conan-center-v2'...
   Downloading conanfile.py
   Downloading conanmanifest.txt
   Downloading conan_export.tgz
   Decompressing conan_export.tgz
   libwebp/1.3.0: Downloaded recipe revision d92654dbce1f8cb8ae45d5388f86fcfe
   openexr/2.5.7: Not found in local cache, looking in remotes...
   openexr/2.5.7: Checking remote: conan-center-v2
   openexr/2.5.7: Trying with 'conan-center-v2'...
   Downloading conanfile.py
   Downloading conan_export.tgz
   Downloading conanmanifest.txt
   Decompressing conan_export.tgz
   openexr/2.5.7: Downloaded recipe revision 3669225befe8a54199139bcfd2226848
   libraw/0.20.2: Not found in local cache, looking in remotes...
   libraw/0.20.2: Checking remote: conan-center-v2
   libraw/0.20.2: Trying with 'conan-center-v2'...
   Downloading conanfile.py
   Downloading conanmanifest.txt
   Downloading conan_export.tgz
   Decompressing conan_export.tgz
   libraw/0.20.2: Downloaded recipe revision e5f863b9f46898d2af06ed4e888ef79a
   lcms/2.14: Not found in local cache, looking in remotes...
   lcms/2.14: Checking remote: conan-center-v2
   lcms/2.14: Trying with 'conan-center-v2'...
   Downloading conanfile.py
   Downloading conan_export.tgz
   Downloading conanmanifest.txt
   Decompressing conan_export.tgz
   lcms/2.14: Downloaded recipe revision 87e77c68ae48f32ff18e1aef1fc6c4b7
   meson/1.0.0: Not found in local cache, looking in remotes...
   meson/1.0.0: Checking remote: conan-center-v2
   meson/1.0.0: Trying with 'conan-center-v2'...
   Downloading conanfile.py
   Downloading conanmanifest.txt
   Downloading conan_export.tgz
   Decompressing conan_export.tgz
   meson/1.0.0: Downloaded recipe revision 15586c0ac6f682805875ef903dbe7ee2
   ninja/1.11.1: Not found in local cache, looking in remotes...
   ninja/1.11.1: Checking remote: conan-center-v2
   ninja/1.11.1: Trying with 'conan-center-v2'...
   Downloading conan_export.tgz
   Downloading conanmanifest.txt
   Downloading conanfile.py
   Decompressing conan_export.tgz
   ninja/1.11.1: Downloaded recipe revision a2f0b832705907016f336839f96963f8
   jasper/4.0.0: Not found in local cache, looking in remotes...
   jasper/4.0.0: Checking remote: conan-center-v2
   jasper/4.0.0: Trying with 'conan-center-v2'...
   Downloading conanfile.py
   Downloading conan_export.tgz
   Downloading conanmanifest.txt
   Decompressing conan_export.tgz
   jasper/4.0.0: Downloaded recipe revision 0f24c583a775111430a750e3c5defb7f
   jxrlib/cci.20170615: Not found in local cache, looking in remotes...
   jxrlib/cci.20170615: Checking remote: conan-center-v2
   jxrlib/cci.20170615: Trying with 'conan-center-v2'...
   Downloading conanfile.py
   Downloading conanmanifest.txt
   Downloading conan_export.tgz
   Decompressing conan_export.tgz
   jxrlib/cci.20170615: Downloaded recipe revision a23c9807b12818ff7a73fae89e58ce6a
   libtiff/4.4.0: Not found in local cache, looking in remotes...
   libtiff/4.4.0: Checking remote: conan-center-v2
   libtiff/4.4.0: Trying with 'conan-center-v2'...
   Downloading conanmanifest.txt
   Downloading conan_export.tgz
   Downloading conanfile.py
   Decompressing conan_export.tgz
   libtiff/4.4.0: Downloaded recipe revision f46dce61bbb69e0e13cafa43b93b2885
   libdeflate/1.15: Not found in local cache, looking in remotes...
   libdeflate/1.15: Checking remote: conan-center-v2
   libdeflate/1.15: Trying with 'conan-center-v2'...
   Downloading conan_export.tgz
   Downloading conanmanifest.txt
   Downloading conanfile.py
   Decompressing conan_export.tgz
   libdeflate/1.15: Downloaded recipe revision 867521b6450fdfcc6ec97c37a603912f
   xz_utils/5.2.5: Not found in local cache, looking in remotes...
   xz_utils/5.2.5: Checking remote: conan-center-v2
   xz_utils/5.2.5: Trying with 'conan-center-v2'...
   Downloading conanmanifest.txt
   Downloading conanfile.py
   Downloading conan_export.tgz
   Decompressing conan_export.tgz
   xz_utils/5.2.5: Downloaded recipe revision ea2f3e1571def8a8605c4c603c8ac007
   jbig/20160605: Not found in local cache, looking in remotes...
   jbig/20160605: Checking remote: conan-center-v2
   jbig/20160605: Trying with 'conan-center-v2'...
   Downloading conanmanifest.txt
   Downloading conan_export.tgz
   Downloading conanfile.py
   Decompressing conan_export.tgz
   jbig/20160605: Downloaded recipe revision 223f0b4bdf5b597534f9c06ba1c07a08
   zstd/1.5.2: Not found in local cache, looking in remotes...
   zstd/1.5.2: Checking remote: conan-center-v2
   zstd/1.5.2: Trying with 'conan-center-v2'...
   Downloading conanmanifest.txt
   Downloading conan_export.tgz
   Downloading conanfile.py
   Decompressing conan_export.tgz
   zstd/1.5.2: Downloaded recipe revision bc40550e2e34fad211de590f86a05ed6
   Graph root
       virtual
   Requirements
       freeimage/3.18.0#0158d7ee5d058168115b3fe56e9d3335 - Cache
       jasper/4.0.0#0f24c583a775111430a750e3c5defb7f - Downloaded (conan-center-v2)
       jbig/20160605#223f0b4bdf5b597534f9c06ba1c07a08 - Downloaded (conan-center-v2)
       jxrlib/cci.20170615#a23c9807b12818ff7a73fae89e58ce6a - Downloaded (conan-center-v2)
       lcms/2.14#87e77c68ae48f32ff18e1aef1fc6c4b7 - Downloaded (conan-center-v2)
       libdeflate/1.15#867521b6450fdfcc6ec97c37a603912f - Downloaded (conan-center-v2)
       libjpeg/9e#68269859e4325ddc3f995d1fd3fc9187 - Downloaded (conan-center-v2)
       libpng/1.6.39#deca555b0890e584fc895ba756e83c06 - Downloaded (conan-center-v2)
       libraw/0.20.2#e5f863b9f46898d2af06ed4e888ef79a - Downloaded (conan-center-v2)
       libtiff/4.4.0#f46dce61bbb69e0e13cafa43b93b2885 - Downloaded (conan-center-v2)
       libwebp/1.3.0#d92654dbce1f8cb8ae45d5388f86fcfe - Downloaded (conan-center-v2)
       openexr/2.5.7#3669225befe8a54199139bcfd2226848 - Downloaded (conan-center-v2)
       openjpeg/2.5.0#cb3ca9c879e991ad313caa16d7e04169 - Downloaded (conan-center-v2)
       xz_utils/5.2.5#ea2f3e1571def8a8605c4c603c8ac007 - Downloaded (conan-center-v2)
       zlib/1.2.13#13c96f538b52e1600c40b88994de240f - Downloaded (conan-center-v2)
       zstd/1.5.2#bc40550e2e34fad211de590f86a05ed6 - Downloaded (conan-center-v2)
   Build requirements
       meson/1.0.0#15586c0ac6f682805875ef903dbe7ee2 - Downloaded (conan-center-v2)
       ninja/1.11.1#a2f0b832705907016f336839f96963f8 - Downloaded (conan-center-v2)
   Graph error
       Version conflict: libtiff/4.4.0->libwebp/1.2.4, None->libwebp/1.3.0.
   ERROR: Version conflict: libtiff/4.4.0->libwebp/1.2.4, None->libwebp/1.3.0.
   ```

---

<sup>**Note:** To save resources, CI tries to finish as soon as an error is found. For this reason you might find that not all the references have been launched or not all the configurations for a given reference. Also, take into account that we cannot guarantee the order of execution as it depends on CI workload and workers availability.</sup>

</details>

_Originally posted by @conan-center-bot in https://github.com/conan-io/conan-center-index/issues/15941#issuecomment-1427073016_
            
user: prince-chrismc
issue_13149: state: open
title: Installing doxygen fails: no doxygen-config.cmake file created
body: ### Environment details

* Operating System+version: ubuntu-20.04 (on GitHub runners)
* Compiler+version: GNU 9.4.0
* Conan version: 1.57.0
* Python version: Python 3.8.10
* Doxygen version: 1.9.2

This error occurs on GitHub runners using Ubuntu 20, and also on my colleague's machine (Ubuntu 22) but not on my own machine (Ubuntu 20). I have also tried with doxygen 1.8.17 and with older Conan version (1.54, 1.55) and all work fine on my machine and break on the my colleague's Ubuntu 22.

### Steps to reproduce

In our `conanfile.py` we have 
```
if self.options.docs == 'on':
            self.requires("doxygen/1.8.17")
```
When building in GitHub Actions we have these steps:

```
- name: Configure
        run: conan install ${{github.workspace}} -if ${{github.workspace}}/build --build missing  -s compiler.libcxx=libstdc++11 -o mpi=off -o openmp=off -o docs=on -o cppflow=on

- name: Build
        run: conan build ${{github.workspace}} -bf ${{github.workspace}}/build
```

### Logs

Running the GitHub Action in the output from the Configure step it seems to correctly download and install doxygen. The output from this step is very long so I've only copied here the initial setup info and the bits mentioning doxygen (the ... indicates more output about other dependencies, no errors there) but if let me know if the full output would be helpful.

```
Auto detecting your dev setup to initialize the default profile (/home/runner/.conan/profiles/default)
Found gcc 9
Found clang 11.0
gcc>=5, using the major as version

************************* WARNING: GCC OLD ABI COMPATIBILITY ***********************
 
Conan detected a GCC version > 5 but has adjusted the 'compiler.libcxx' setting to
'libstdc++' for backwards compatibility.
Your compiler is likely using the new CXX11 ABI by default (libstdc++11).

If you want Conan to use the new ABI for the default profile, run:

    $ conan profile update settings.compiler.libcxx=libstdc++11 default

Or edit '/home/runner/.conan/profiles/default' and set compiler.libcxx=libstdc++11

************************************************************************************



Default settings
	os=Linux
	os_build=Linux
	arch=x86_64
	arch_build=x86_64
	compiler=gcc
	compiler.version=9
	compiler.libcxx=libstdc++
	build_type=Release
*** You can change them in /home/runner/.conan/profiles/default ***
*** Or override with -s compiler='other' -s ...s***


Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os_build=Linux
[options]
cppflow=on
docs=on
mpi=off
openmp=off
[build_requires]
[env]

...


doxygen/1.8.17: Not found in local cache, looking in remotes...
doxygen/1.8.17: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
doxygen/1.8.17: Downloaded recipe revision 0

...

Requirements
    doxygen/1.8.17 from 'conancenter' - Downloaded

...

Packages
    doxygen/1.8.17:e94378795f92fbf88bb8cef7f9c2f38c4ecf9126 - Download

...

Installing (downloading, building) binaries...
doxygen/1.8.17: Retrieving package e94378795f92fbf88bb8cef7f9c2f38c4ecf9126 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
doxygen/1.8.17: Package installed e94378795f92fbf88bb8cef7f9c2f38c4ecf9126
doxygen/1.8.17: Downloaded package revision 0
```

Then in the Build step I get the following error:

```
CMake Error at cmake_files/dependencies.cmake:24 (find_package):
  By not providing "Finddoxygen.cmake" in CMAKE_MODULE_PATH this project has
-- Configuring incomplete, errors occurred!
  asked CMake to find a package configuration file provided by "doxygen", but
  CMake did not find one.
  Could not find a package configuration file provided by "doxygen" with any
  of the following names:
    doxygenConfig.cmake
    doxygen-config.cmake
  Add the installation prefix of "doxygen" to CMAKE_PREFIX_PATH or set
  "doxygen_DIR" to a directory containing one of the above files.  If
  "doxygen" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  CMakeLists.txt:44 (include)
See also "/home/runner/work/sopt/sopt/build/CMakeFiles/CMakeOutput.log".
ERROR: conanfile.py (sopt/4.0.0): Error in build() method, line 72
	cmake.configure()
	ConanException: Error 1 while executing cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/runner/work/sopt/sopt/build/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/runner/work/sopt/sopt/build/package" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/runner/work/sopt/sopt"
Error: Process completed with exit code 1.
```

I have used tmate to ssh onto the gihub runners and confirm that after the Configure step doxygen is there and is the specified version, but it does not create the `doxygen-config.cmake` or `doxygenConfig.cmake` file in the build folder as it does for all the other dependencies.
user: SJaffa
issue_13143: state: open
title: Conan 1.x - build-order command is not giving correct output
body: ### What is your question?

Hi, 

We have 2 components Logger and Basesytem - Logger is dependent on BasySystem. Now we are trying to set up the product pipeline using the example provided in the link below. 

https://github.com/conan-ci-cd-training/products/blob/master/Jenkinsfile

Logger is missing in the build-order, so how can we build the product (Logger) for the change in dependency (BaseSystem/[6.1.0.1])?

+ cat x86_64.lock
{
"graph_lock": {
  "nodes": {
   "1": {
    "ref": "logger/[6.1.0.0#8bcc3a686d18376f5c7e49fb26b6e7b9](https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F6.1.0.0%2F%238bcc3a686d18376f5c7e49fb26b6e7b9&data=05%7C01%7Cmkrishan%40infinera.com%7C4a2dbe56402144a45e6208db0ffb2f5a%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C638121343752227450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pa49cBSIwH2MQzjGMi56CgZskydY4gm9yTv12Wc9dKE%3D&reserved=0)",
    "options": "shared=False\nBaseSystem:shared=False",
    "package_id": "991f626f47791da066b00357470672026006e218",
    "prev": "05fafaae1dc866cd9b5b42e7330803a4",
    "requires": [
     "2"
    ],
    "context": "host"
   },
   "2": {
    "ref": "BaseSystem/[6.1.0.1#e69835d7aa1e0df11b949f4e714d550f](https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F6.1.0.1%2F%23e69835d7aa1e0df11b949f4e714d550f&data=05%7C01%7Cmkrishan%40infinera.com%7C4a2dbe56402144a45e6208db0ffb2f5a%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C638121343752227450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OtMCJWjmNV%2BsGeN17mzpKCOI6Gt2SK7DezyoOh37XKs%3D&reserved=0)",
    "options": "shared=False",
    "package_id": "0e10188faca2665db460fb4fbc3832f12077f9b8",
    "context": "host"
   }
  },
  "revisions_enabled": true
},
"version": "0.4",
"profile_host": "[settings]\narch=x86_64\ncompiler=gcc\ncompiler.cppstd=14\ncompiler.libcxx=libstdc++11\ncompiler.version=8\nos=Linux\n[options]\n[build_requires]\n[env]\n"
}
[Pipeline] sh
+ conan lock build-order x86_64.lock --json=build_order.json
[[('[BaseSystem/6.1.0.1@#e69835d7aa1e0df11b949f4e714d550f](mailto:BaseSystem/6.1.0.1@#e69835d7aa1e0df11b949f4e714d550f)', '0e10188faca2665db460fb4fbc3832f12077f9b8', 'host', '2')]]
+ cat build_order.json
[
[
  [
   BaseSystem/6.1.0.1@#e69835d7aa1e0df11b949f4e714d550f,
   "0e10188faca2665db460fb4fbc3832f12077f9b8",
   "host",
   "2"
  ]
]
]
[basesytem_recipe.txt](https://github.com/conan-io/conan/files/10755921/basesytem_recipe.txt)
[Jenkinsfile.txt](https://github.com/conan-io/conan/files/10755922/Jenkinsfile.txt)
[logging_recipe.txt](https://github.com/conan-io/conan/files/10755923/logging_recipe.txt)




### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: mkjkec2005
issue_13138: state: open
title: [feature] Profiles should permit specification of [test_requires]
body: ### What is your suggestion?

Presently, it is possible to specify tool requirements in a Conan 2.0 profile using the [tool_requires] section of a profile. I therefore expected to be able to do something similar with a [test_requires] section but that results in the following error:

> profile: ConfigParser: Unrecognized field 'test_requires'

Is there some alternate syntax that provides this functionality. My motivation for requesting this feature is as follows. We use Conan to manage our tool chain including the version of CMake we use, which we can specify via a tool_requires entry:

> [tool_requires]
> cmake/3.25.1

With test_package recipes increasingly turning to the use of CMake's ctest functionality, the CMake bin path needs to be visible at test_package run time. It appears that specifying tool_requires does not meet this requirement and I don't think we want to run all tests in the build scope. With a global test_requires for cmake, recipes can safely use ctest the same way they can use cmake.


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: System-Arch
issue_13136: state: open
title: [feature] CMakePresets support for msvc toolset version
body: ### What is your suggestion?

## Suggestion

Would it be possible for the Conan generated CMakePresets.json to include `msvc.toolset` version details (i.e. `v143`, `v142`, etc.) when populating the `toolset.value` field?

This would allow IDEs to know which `vcvarsall.bat` environment to use when building the project.

## Expected Behavior

For example, when cross-compiling with VS2022 x64 to x86, I'd expect to see the conan generated CMakePresets.json look something like:
```diff
"generator": "Ninja",
"cacheVariables": {
    "CMAKE_POLICY_DEFAULT_CMP0091": "NEW",
    "CMAKE_BUILD_TYPE": "RelWithDebInfo"
},
"architecture": {
    "value": "x86",
    "strategy": "external"
},
+"toolset": {
+    "value": "v143,host=x64",
+    "strategy": "external"
+},
"toolchainFile": "C:\\projects\\build\\foo\\RelWithDebInfo\\generators\\conan_toolchain.cmake",
"binaryDir": "C:\\projects\\build\\foo\\RelWithDebInfo
```            

_I can use `tools.cmake.cmaketoolchain:toolset_arch=x64` to add the "host=x64" portion, but I don't have anyway to get `v143` added._

VSCode recognizes this `toolset` / `architecture` combination and correctly chooses VS2022 and calls `vcvarsall.bat amd64_x86` prior to calling CMake.

## Current Behavior

Conan *doesn't* include `toolset` details in the generated CMakePresets.json file, so in order to get IDEs like VSCode to find the right environment, we need to adjust CMakePresets.json (as described above) or worse adjust the CMakeUserPresets.json file as follows:

```diff
{
    "version": 4,
    "vendor": {
        "conan": {}
    },
    "include": [
        "C:\\path\\to\\conan\\CMakePresets.json"
-    ]
+    ],
+    "configurePresets": [
+      {
+        "name": "RelWithDebInfo",
+        "displayName": "RelWithDebInfo",
+        "inherits": "relwithdebinfo",
+        "toolset": {
+          "value": "v143,host=x64",
+          "strategy": "external"
+        }
+    ],
+    "buildPresets": [
+        {
+            "name": "RelWithDebInfo",
+            "displayName": "RelWithDebInfo",
+            "configurePreset": "RelWithDebInfo",
+            "configuration": "RelWithDebInfo"
+        }
+    ]
}
```

Conan already knows *which* vcvarsall to call, and and ensures the correct one gets called in the generated `conanvcvars.bat`.

Conan also appears to know about `msvc.toolset` version information:
https://github.com/conan-io/conan/blob/e33b55a486fd208223524dda49cce02dbe70c214/conans/client/conf/__init__.py#L117
_At least for the legacy toolsets_

And seems to know about the mapping:
https://github.com/conan-io/conan/blob/e0a8ee058bc8dc2d9811b8aeb6999f69aeb78d85/conan/tools/microsoft/visual.py#L53-L60

It seems like Conan could should be able to use the `msvc.toolset` information from the build profile and populate the version field correctly.

## Context
Follow up to https://github.com/conan-io/conan/issues/11623

Some IDEs are capable of targeting multiple toolsets (e.g. VS2015, VS2019, VS2022), and `toolset.value` is the way for the IDE to know which `vcvarsall.bat` to load and use internally while compiling.

> It's the same step that Visual Studio takes for you when the IDE invokes CMake. **Visual Studio parses the active Configure Preset for the host and target architecture specified by toolset and architecture. Visual Studio then sources the specified environment from vcvarsall.bat.** When you build from the Windows command line with Ninja, you'll need to take this step yourself.
_Excerpt from MSDN [Sourcing the environment when building with command-line generators on Windows](https://learn.microsoft.com/en-us/cpp/build/cmake-presets-vs?view=msvc-170#sourcing-the-environment-when-building-with-command-line-generators-on-windows)_

IDE | Support 
----|----------
VSCode | [Already Supported](https://github.com/microsoft/vscode-cmake-tools/search?q=varsForVSInstallation) <br> https://github.com/microsoft/vscode-cmake-tools/pull/2524
QtCreator | [In Progress](https://codereview.qt-project.org/c/qt-creator/qt-creator/+/457588/8/src/plugins/cmakeprojectmanager/cmakeprojectimporter.cpp)<br> [QTCREATOR-BUG 28693](https://bugreports.qt.io/browse/QTCREATORBUG-28693)
CLion | [Feature Request](https://youtrack.jetbrains.com/issue/CPP-31353/Support-external-strategy-of-toolset-and-architecture-fields-in-CMakePresets.json-for-MSVC-compilers.)

Thanks for your support!



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: thorntonryan
issue_13129: state: open
title: How to package/upload broken symlinks
body: I am trying to create binary packages that are similar to how many linux distributions distribute their shared libraries (using a binary package and a "devel" package for the library (e.g., libpcap and  libpcap-devel)). Linux distributions will have the actual shared library binary in the library package and headers and a broken shared library symlink will be in the devel package (e.g., `libpcap.so.1.9.1` will be in the 'libpcap' rpm and the libpcap-devel rpm will contain the header files and a broken symlink of `libpcap.so` pointing to `libpcap.so.1.9.1`).

So the devel package on its own is "broken"; you need to install both the devel package and the library package for the broken symlink to be resolved (no longer broken).

Anyway, I'm trying to follow a similar construct with conan packages I'm creating . I found that if I set `skip_broken_symlinks_check=True` in my conan.conf I'm able to create these packages in my local cache and the broken symlink is "packaged up" correctly. I can then import the package in other projects where they are needed and if both the "library" and "devel" packages are imported, the symlink resolves.

However, if I UPLOAD the "devel" package to artifactory, the broken symlink is not included. Thus, these packages cannot be distributed; which kind of defeats the purpose of using conan as our package manager.

Is there any way to get the artifactory view to reflect what's in my local cache view in `~/.conan/data/<my_package>/.../package/*/*` ? In other words, is there any way to get the conan package in artifactory to have that broken symlink? 


user: gabeblack
issue_13127: state: open
title: How to Read a environment variable
body: ### What is your question?

I used the AutotoolsDeps to define an environment variable in my recipe file generate method. In the build method I am trying to read the environment method using the following code and it does not return and the value for the environment variable

		try:
			srcopt = os.environ['CSTART_SRCOPTS']
		except KeyError:
			raise ConanInvalidConfiguration(f"{_envar} is not defined in the environment ")

The attached file shows the environment variable is being defined
[conanautotoolsdeps.txt](https://github.com/conan-io/conan/files/10733806/conanautotoolsdeps.txt)

What is the correct way to read an environment variable that was defined in AutotoolsDeps

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: Ed-CMI
issue_13116: state: open
title: [question] have find_package use an existing xxxConfig.cmake
body: ### What is your question?

Hi, I hope I can phrase my issue well enough. (tl;dr version at the bottom :D )

I'm currently developing an application that will cross compile from linux to qnx. I was previously using conan 1.54 and now upgraded to 1.58. While at it I also decided to move to host and build profiles. Previously I was only using 1 profile. So this brought the issue of some info no longer being available in `deps_cpp_info`

## My Setup / Workflow

This is an extract of how my conanfile.py currently looks like. I added some comments to explain a few things.
```
class AppConan(ConanFile):
# ...
   name = "MyApp"
   generators = "virtualenv", "CMakeDeps", "CMakeToolchain"
   requires = ["lz4/1.9.4"]
   tool_requires = ["qnx-compiler", "cmake-helpers"]

   def generate(self):
      deps = CMakeDeps(self)
      # I kinda want to use HelpersConfig.cmake provided
      # by the helpers package and not generate a new one
      # deps.build_context_activated = ["cmake-helpers"]
      deps.generate()

      tc = CMakeToolchain(self)
      # This was the proposal from the colleague that created the "cmake-helpers" 
      # package to allow finding the HelpersConfig.cmake shipped within his package
      # in conan 1.54
      for _, val in self.deps_cpp_info.dependencies:
         path = val.rootpath.replace("\\", "/")
         name = val.get_property("cmake_file_name")
         if name != None:
            tc.variables[f"{name}_ROOT"] = str(path)
     tc.generate()

# ...
```

In my CMakeLists.txt I have this part:
```
find_package(cmake-helpers 0.0.2 CONFIG REQUIRED)
include(folder-inside-cmake-helpers/cmake/custom_cmake_commands) # <-- this is a .cmake file
``` 

This is how it worked in conan 1.54 with only one profile:
1.  conanfile.py would set `Helpers_ROOT = path/to/helpers-package/in/conancache`
2. `find_package` in `CMakeLists.txt` would find the corresponding `HelpersConfig.cmake` thanks to `Helpers_ROOT` and source it
3. In `CMakeLists.txt` i could call `include` to (optionally) include some more .cmake files provided by the helpers package

The cmake helpers is basically a package that provides many wrappers to "easily" setup up stuff we need for development, code analysis, etc.

## The issue

So now with 2 profiles I'm running into the issue that the `deps_cpp_info` no longer contains info about the build requirements.
This means that I can no longer set `Helpers_ROOT` (using the for-loop in my conanfile) because my `self.deps_cpp_info.dependencies` no longer contains info about my helper package.

Using:
```
deps.build_context_activated = ["cmake-helpers"]
```

also doesn't help since I want to use the existing `HelpersConfig.cmake`, since that file sets a few CMake variables that allows calling `include` to include some other cmake files.

From the CMake error log I see that I somehow have to get conan to set the path to this build requirement in `CMAKE_PREFIX_PATH` or alternatively somehow set `Helpers_ROOT`. 

So the question is how to do this if I no longer have to info info in `deps_cpp_info` ?

## Tl;Dr

How can I make `find_package(XXX CONFIG)` use the `XXXConfig.cmake` provided by a package that is a build requirement when using host and build profiles. This only seems to work for `find_package(XXX MODULE)` if the package provides a `FindModule.cmake`.



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: myzb
issue_13108: state: open
title: Building libcurl with mingw on windows
body: ### What is your question?

conan 1.55
build os: Windows 10
host os: windows

I am trying to simply build libcurl for windows using mingw and msys2

host and build profile:
```
[settings]
os=Windows
arch=x86_64
compiler=gcc
compiler.version=12
compiler.threads=posix
compiler.exception=seh
compiler.libcxx=libstdc++11
build_type=Release

[tool_requires]
mingw-builds/12.2.0
msys2/20210105

[conf]
```

cosumer recipe:
```
from conan.tools.cmake import CMake, CMakeToolchain, CMakeDeps
from conans import ConanFile, tools
from conans.errors import ConanException

class MyRecipe(ConanFile):
   ...
    requires = [("libcurl/7.87.0")]    
```

Command:
```
conan.exe install [path_to_conanfile]/conanfile.py --update --build missing --profile:host [path_to_profiles]/windows-x86_64-w64-mingw32.profile --profile:build [path_to_profiles]/windows-x86_64-w64-mingw32.profile
```

Getting errors like:
```
Configuration (profile_host):
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.exception=seh
compiler.libcxx=libstdc++11
compiler.threads=posix
compiler.version=12
os=Windows
[options]
[build_requires]
*: mingw-builds/12.2.0, msys2/20210105
[env]

Configuration (profile_build):
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.exception=seh
compiler.libcxx=libstdc++11
compiler.threads=posix
compiler.version=12
os=Windows
[options]
[build_requires]
*: mingw-builds/12.2.0, msys2/20210105
[env]

libcurl/7.87.0: Not found in local cache, looking in remotes...
libcurl/7.87.0: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libcurl/7.87.0: Downloaded recipe revision 9b166c63d5b06b69358f8698cb8daa45
openssl/1.1.1s: Not found in local cache, looking in remotes...
openssl/1.1.1s: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
openssl/1.1.1s: Downloaded recipe revision 5449870f797dec26045f2765d6fc7b5a
zlib/1.2.13: Not found in local cache, looking in remotes...
zlib/1.2.13: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
zlib/1.2.13: Downloaded recipe revision 13c96f538b52e1600c40b88994de240f
nasm/2.15.05: Not found in local cache, looking in remotes...
nasm/2.15.05: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
nasm/2.15.05: Downloaded recipe revision 799d63b1672a337584b09635b0f22fc1
msys2/20210105: Not found in local cache, looking in remotes...
msys2/20210105: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
msys2/20210105: Downloaded recipe revision c8b630a0d2b875c34c380e164d12ec4a
mingw-builds/12.2.0: Not found in local cache, looking in remotes...
mingw-builds/12.2.0: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
mingw-builds/12.2.0: Downloaded recipe revision 40ab045ce629019b6f1056ce511079e9
libtool/2.4.7: Not found in local cache, looking in remotes...
libtool/2.4.7: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libtool/2.4.7: Downloaded recipe revision 0df56d1f5ae0b5c5c1bbb818c88247a8
automake/1.16.5: Not found in local cache, looking in remotes...
automake/1.16.5: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
automake/1.16.5: Downloaded recipe revision 891f585a736bce951cc0e7109aa5ffee
autoconf/2.71: Not found in local cache, looking in remotes...
autoconf/2.71: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
autoconf/2.71: Downloaded recipe revision 053e3879948e44d44a511554854ffbe9
m4/1.4.19: Not found in local cache, looking in remotes...
m4/1.4.19: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
m4/1.4.19: Downloaded recipe revision 7689d2cae05587d0efb12261ddc4124d
pkgconf/1.9.3: Not found in local cache, looking in remotes...
pkgconf/1.9.3: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
pkgconf/1.9.3: Downloaded recipe revision 02904517fb960fa340bee15bef847751
gnu-config/cci.20210814: Not found in local cache, looking in remotes...
gnu-config/cci.20210814: Trying with 'conan-virtual'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
gnu-config/cci.20210814: Downloaded recipe revision eb941b98dbf40f3eb1753f6b1f05861f
conanfile.py (my_package/1.0.0): Installing package
Requirements
    libcurl/7.87.0 from 'conan-virtual' - Downloaded
    openssl/1.1.1s from 'conan-virtual' - Downloaded
    zlib/1.2.13 from 'conan-virtual' - Downloaded
Packages
    libcurl/7.87.0:fe63e481b744a5ddb950976f601e39ed21a34637 - Build
    openssl/1.1.1s:b6e8139245c8b25a8d2440de4fd9d71781b83f65 - Build
    zlib/1.2.13:72ab1929946a1e7e9b69c00bc299eb0126492ede - Build
Build requirements
    autoconf/2.71 from 'conan-virtual' - Downloaded
    automake/1.16.5 from 'conan-virtual' - Downloaded
    gnu-config/cci.20210814 from 'conan-virtual' - Downloaded
    libtool/2.4.7 from 'conan-virtual' - Downloaded
    m4/1.4.19 from 'conan-virtual' - Downloaded
    mingw-builds/12.2.0 from 'conan-virtual' - Cache
    msys2/20210105 from 'conan-virtual' - Cache
    nasm/2.15.05 from 'conan-virtual' - Downloaded
    pkgconf/1.9.3 from 'conan-virtual' - Downloaded
Build requirements packages
    autoconf/2.71:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    automake/1.16.5:3e48e69237f7f2196164383ef9dedf0f93cbf249 - Download
    gnu-config/cci.20210814:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    libtool/2.4.7:41d69a1bf21ee61501b0948b9825fc48bc912010 - Build
    m4/1.4.19:0a420ff5c47119e668867cdb51baff0eca1fdb68 - Download
    mingw-builds/12.2.0:6903a9d1b48b06f7fbe0929db654512c77e6cc32 - Download
    msys2/20210105:eee3fba89db6d777329de604625af8c30d46f080 - Download
    nasm/2.15.05:0a420ff5c47119e668867cdb51baff0eca1fdb68 - Download
    pkgconf/1.9.3:0a420ff5c47119e668867cdb51baff0eca1fdb68 - Download

Installing (downloading, building) binaries...
gnu-config/cci.20210814: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conan-virtual' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
gnu-config/cci.20210814: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
gnu-config/cci.20210814: Downloaded package revision 84fe970dd17e1d5d5f34965d5e7a47ba
m4/1.4.19: Retrieving package 0a420ff5c47119e668867cdb51baff0eca1fdb68 from remote 'conan-virtual' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
m4/1.4.19: Package installed 0a420ff5c47119e668867cdb51baff0eca1fdb68
m4/1.4.19: Downloaded package revision 993400024ef56bcd05fb2780eeaa5d84
mingw-builds/12.2.0: Retrieving package 6903a9d1b48b06f7fbe0929db654512c77e6cc32 from remote 'conan-virtual' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
mingw-builds/12.2.0: Package installed 6903a9d1b48b06f7fbe0929db654512c77e6cc32
mingw-builds/12.2.0: Downloaded package revision c9c5440a67ee9649ce6d9b417f83a58d
msys2/20210105: Retrieving package eee3fba89db6d777329de604625af8c30d46f080 from remote 'conan-virtual' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
.msys2/20210105: Package installed eee3fba89db6d777329de604625af8c30d46f080
msys2/20210105: Downloaded package revision 557a6d65631ae995117b1b05a7634740
nasm/2.15.05: Retrieving package 0a420ff5c47119e668867cdb51baff0eca1fdb68 from remote 'conan-virtual' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
nasm/2.15.05: Package installed 0a420ff5c47119e668867cdb51baff0eca1fdb68
nasm/2.15.05: Downloaded package revision 46436e7a1259642e13668e66e996492f
pkgconf/1.9.3: Retrieving package 0a420ff5c47119e668867cdb51baff0eca1fdb68 from remote 'conan-virtual' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
pkgconf/1.9.3: Package installed 0a420ff5c47119e668867cdb51baff0eca1fdb68
pkgconf/1.9.3: Downloaded package revision c8ad03e4277801194bdfa05cff8aeb09
autoconf/2.71: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conan-virtual' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
autoconf/2.71: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
autoconf/2.71: Downloaded package revision 3eaf9daa785fcf85a9367addc5534fc7
automake/1.16.5: Retrieving package 3e48e69237f7f2196164383ef9dedf0f93cbf249 from remote 'conan-virtual' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
automake/1.16.5: Package installed 3e48e69237f7f2196164383ef9dedf0f93cbf249
automake/1.16.5: Downloaded package revision d0367a6c7bc48a392fcb55eb243aa190
m4/1.4.19: Appending PATH environment variable: C:\Users\[me]\.conan\data\m4\1.4.19\_\_\package\0a420ff5c47119e668867cdb51baff0eca1fdb68\bin
mingw-builds/12.2.0: Appending PATH env var with : C:\Users\[me]\.conan\data\mingw-builds\12.2.0\_\_\package\6903a9d1b48b06f7fbe0929db654512c77e6cc32\bin
mingw-builds/12.2.0: Appending PATH env var with : C:\Users\[me]\.conan\data\mingw-builds\12.2.0\_\_\package\6903a9d1b48b06f7fbe0929db654512c77e6cc32\bin
mingw-builds/12.2.0: Appending PATH env var with : C:\Users\[me]\.conan\data\mingw-builds\12.2.0\_\_\package\6903a9d1b48b06f7fbe0929db654512c77e6cc32\bin
mingw-builds/12.2.0: Appending PATH env var with : C:\Users\[me]\.conan\data\mingw-builds\12.2.0\_\_\package\6903a9d1b48b06f7fbe0929db654512c77e6cc32\bin
mingw-builds/12.2.0: Appending PATH env var with : C:\Users\[me]\.conan\data\mingw-builds\12.2.0\_\_\package\6903a9d1b48b06f7fbe0929db654512c77e6cc32\bin
msys2/20210105: Creating MSYS_ROOT env var : C:\.conan\253a75\1\bin\msys64
msys2/20210105: Creating MSYS_BIN env var : C:\.conan\253a75\1\bin\msys64\usr\bin
msys2/20210105: Appending PATH env var with : C:\.conan\253a75\1\bin\msys64\usr\bin
msys2/20210105: Creating MSYS_ROOT env var : C:\.conan\253a75\1\bin\msys64
msys2/20210105: Creating MSYS_BIN env var : C:\.conan\253a75\1\bin\msys64\usr\bin
msys2/20210105: Appending PATH env var with : C:\.conan\253a75\1\bin\msys64\usr\bin
msys2/20210105: Creating MSYS_ROOT env var : C:\.conan\253a75\1\bin\msys64
msys2/20210105: Creating MSYS_BIN env var : C:\.conan\253a75\1\bin\msys64\usr\bin
msys2/20210105: Appending PATH env var with : C:\.conan\253a75\1\bin\msys64\usr\bin
msys2/20210105: Creating MSYS_ROOT env var : C:\.conan\253a75\1\bin\msys64
msys2/20210105: Creating MSYS_BIN env var : C:\.conan\253a75\1\bin\msys64\usr\bin
msys2/20210105: Appending PATH env var with : C:\.conan\253a75\1\bin\msys64\usr\bin
msys2/20210105: Creating MSYS_ROOT env var : C:\.conan\253a75\1\bin\msys64
msys2/20210105: Creating MSYS_BIN env var : C:\.conan\253a75\1\bin\msys64\usr\bin
msys2/20210105: Appending PATH env var with : C:\.conan\253a75\1\bin\msys64\usr\bin
pkgconf/1.9.3: Appending PATH env var: C:\Users\[me]\.conan\data\pkgconf\1.9.3\_\_\package\0a420ff5c47119e668867cdb51baff0eca1fdb68\bin
pkgconf/1.9.3: Setting PKG_CONFIG env var: C:/Users/[me]/.conan/data/pkgconf/1.9.3/_/_/package/0a420ff5c47119e668867cdb51baff0eca1fdb68/bin/pkgconf.exe
pkgconf/1.9.3: Appending AUTOMAKE_CONAN_INCLUDES env var: /mnt/c/Users/[me]/.conan/data/pkgconf/1.9.3/_/_/package/0a420ff5c47119e668867cdb51baff0eca1fdb68/bin/aclocal
autoconf/2.71: Defining AC_MACRODIR environment variable: C:\Users\[me]\.conan\data\autoconf\2.71\_\_\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\res\autoconf
autoconf/2.71: Defining autom4te_perllibdir environment variable: C:\Users\[me]\.conan\data\autoconf\2.71\_\_\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\res\autoconf
autoconf/2.71: Defining AUTOCONF environment variable: C:\Users\[me]\.conan\data\autoconf\2.71\_\_\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\bin\autoconf
autoconf/2.71: Defining AUTORECONF environment variable: C:\Users\[me]\.conan\data\autoconf\2.71\_\_\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\bin\autoreconf
autoconf/2.71: Defining AUTOHEADER environment variable: C:\Users\[me]\.conan\data\autoconf\2.71\_\_\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\bin\autoheader
autoconf/2.71: Defining AUTOM4TE environment variable: C:\Users\[me]\.conan\data\autoconf\2.71\_\_\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\bin\autom4te
openssl/1.1.1s: Applying build-requirement: mingw-builds/12.2.0
openssl/1.1.1s: Applying build-requirement: nasm/2.15.05
openssl/1.1.1s: Applying build-requirement: msys2/20210105
Downloading conan_sources.tgz
openssl/1.1.1s: Configuring sources in C:\Users\[me]\.conan\data\openssl\1.1.1s\_\_\source\src
openssl/1.1.1s: 
openssl/1.1.1s: Copying sources to build folder
openssl/1.1.1s: Building your package in C:\Users\[me]\.conan\data\openssl\1.1.1s\_\_\build\b6e8139245c8b25a8d2440de4fd9d71781b83f65
openssl/1.1.1s: Generator txt created conanbuildinfo.txt
openssl/1.1.1s: Calling generate()
ERROR: openssl/1.1.1s: Error in generate() method, line 254
	VirtualBuildEnv(self).generate()
	ConanException: win_bash=True but tools.microsoft.bash:subsystem configuration not defined
CMake Error at BuildSystem/conan.cmake:655 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  BuildSystem/build-system.cmake:52 (conan_cmake_install)
  CMakeLists.txt:4 (include)
```

This should be a simple task, what am I doing wrong?
I can see that the msys2 package sets `tools.microsoft.bash:subsystem` and `tools.microsoft.bash:path` , but it seems like VirtualBuildEnv cannot find them?

I have tried setting `tools.microsoft.bash:subsystem` and `tools.microsoft.bash:path` manually without success?
Am I doing something wrong, is it a bug in VirtualBuildEnv? It puzzles med that these conf variables does not propagate from msys2 as a tool_requires to all other recipes being built.

It would be very much appreciated with working examples in the docs. I'll even supply them if I get this working.

Regards
Klaus

PS: Thank you for your hard work on this in general!


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: klausholstjacobsen
issue_13098: state: open
title: [bug] AutotoolsToolchain: pkgconfig files not found if build machine is Windows
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: Visual Studio 2022
* Conan version: 1.58.0
* Python version: 3.11.1


### Steps to reproduce

1. Build latest revision of `coin-osi` recipe in conan-center with Visual Studio: https://github.com/conan-io/conan-center-index/tree/33f83eba030e5db6023f9ccf0ea98b80df0b5499/recipes/coin-osi/all (based on legacy `AutotoolsBuildEnvironment`) => this recipe works fine.
2. Checkout https://github.com/conan-io/conan-center-index/pull/15834 doing a migration of this recipe to `AutotoolsToolchain` + `PkgConfigDeps`. This recipe has a `PKG_CONFIG_PATH` workaround at the end of `generate()`: https://github.com/conan-io/conan-center-index/blob/aa92d624b614488edf620d21ae69bef70c348d68/recipes/coin-osi/all/conanfile.py#L94-L98. Remove this workaround and build coin-utils with Visual Studio. It should fail without the workaround because it can't find `coinutils.pc` (`coin-utils` is a dependency of `coin-osi`).

I can't explain why it doesn't work without the workaround which overrides `PKG_CONFIG_PATH` of AutotoolsToolchain with regular windows path (instead of unix path). Maybe it's a bug in conan client, maybe in `pkgconf` recipe, a pernicious bug in the interaction between msys2, pkgconf, conan client, I have no idea.

I think a first step in conan client would be to add Autotools tests (`AutotoolsToolchain`, `AutotoolsDeps`, `PkgConfigDeps` etc, with & without an autoreconf) on Windows in a msys2 context, with at least Visual Studio and MinGW gcc. I see that all these tests are disabled on Windows, it's annoying.

### Logs

<details><summary>Click to expand log</summary>

```
********************************************************************************
conan install coin-osi/0.108.6@#d8ab6d63ef9c43eceb5f5b6ab85d7a0c --build=coin-osi -pr C:\J\w\prod\BuildSingleReference@3\175664\16db3f68-57f2-4d94-b89f-cce90964c26b/profile_windows_15_md_vs_release_64.coin-osi-shared-False.txt -c tools.system.package_manager:mode=install -c tools.system.package_manager:sudo=True
********************************************************************************
Auto detecting your dev setup to initialize the default profile (C:\J\w\prod\BuildSingleReference@3\.conan\profiles\default)
Found Visual Studio 17
Default settings
	os=Windows
	os_build=Windows
	arch=x86_64
	arch_build=x86_64
	compiler=Visual Studio
	compiler.version=17
	build_type=Release
*** You can change them in C:\J\w\prod\BuildSingleReference@3\.conan\profiles\default ***
*** Or override with -s compiler='other' -s ...s***


Configuration:
[settings]
arch=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=15
os=Windows
[options]
coin-osi:shared=False
[build_requires]
[env]
[conf]
tools.system.package_manager:mode=install
tools.system.package_manager:sudo=True

coin-utils/2.11.6: Not found in local cache, looking in remotes...
coin-utils/2.11.6: Trying with 'conan-center'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
coin-utils/2.11.6: Downloaded recipe revision 2937fc99817108d36c6bdd7e6049e5f4
bzip2/1.0.8: Not found in local cache, looking in remotes...
bzip2/1.0.8: Trying with 'conan-center'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
bzip2/1.0.8: Downloaded recipe revision 23cc41191fd58460207c5db046033507
zlib/1.2.13: Not found in local cache, looking in remotes...
zlib/1.2.13: Trying with 'conan-center'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
zlib/1.2.13: Downloaded recipe revision 13c96f538b52e1600c40b88994de240f
coin-osi/0.108.6: Forced build from source
gnu-config/cci.20210814: Not found in local cache, looking in remotes...
gnu-config/cci.20210814: Trying with 'conan-center'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
gnu-config/cci.20210814: Downloaded recipe revision eb941b98dbf40f3eb1753f6b1f05861f
pkgconf/1.9.3: Not found in local cache, looking in remotes...
pkgconf/1.9.3: Trying with 'conan-center'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
pkgconf/1.9.3: Downloaded recipe revision 02904517fb960fa340bee15bef847751
msys2/cci.latest: Not found in local cache, looking in remotes...
msys2/cci.latest: Trying with 'conan-center'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
msys2/cci.latest: Downloaded recipe revision 567331f1604f3c584f04feade960f06e
Installing package: coin-osi/0.108.6
Requirements
    bzip2/1.0.8 from 'conan-center' - Downloaded
    coin-osi/0.108.6 from local cache - Cache
    coin-utils/2.11.6 from 'conan-center' - Downloaded
    zlib/1.2.13 from 'conan-center' - Downloaded
Packages
    bzip2/1.0.8:5be2b7a2110ec8acdbf9a1cea9de5d60747edb34 - Download
    coin-osi/0.108.6:e363b996481dec7f9909b333d17ccaa8bb269381 - Build
    coin-utils/2.11.6:f560f2e53e2577b853efd625fc4f85c98181f641 - Download
    zlib/1.2.13:6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7 - Download
Build requirements
    gnu-config/cci.20210814 from 'conan-center' - Downloaded
    msys2/cci.latest from 'conan-center' - Downloaded
    pkgconf/1.9.3 from 'conan-center' - Downloaded
Build requirements packages
    gnu-config/cci.20210814:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    msys2/cci.latest:eee3fba89db6d777329de604625af8c30d46f080 - Download
    pkgconf/1.9.3:0a420ff5c47119e668867cdb51baff0eca1fdb68 - Download

Installing (downloading, building) binaries...
bzip2/1.0.8: Retrieving package 5be2b7a2110ec8acdbf9a1cea9de5d60747edb34 from remote 'conan-center' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
bzip2/1.0.8: Package installed 5be2b7a2110ec8acdbf9a1cea9de5d60747edb34
bzip2/1.0.8: Downloaded package revision d2e68565291f5c4646d3f5be6a3d080f
gnu-config/cci.20210814: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conan-center' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
gnu-config/cci.20210814: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
gnu-config/cci.20210814: Downloaded package revision 84fe970dd17e1d5d5f34965d5e7a47ba
msys2/cci.latest: Retrieving package eee3fba89db6d777329de604625af8c30d46f080 from remote 'conan-center' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
.msys2/cci.latest: Package installed eee3fba89db6d777329de604625af8c30d46f080
msys2/cci.latest: Downloaded package revision 46ddb31bf9506588aebc9c721b254646
pkgconf/1.9.3: Retrieving package 0a420ff5c47119e668867cdb51baff0eca1fdb68 from remote 'conan-center' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
pkgconf/1.9.3: Package installed 0a420ff5c47119e668867cdb51baff0eca1fdb68
pkgconf/1.9.3: Downloaded package revision c8ad03e4277801194bdfa05cff8aeb09
zlib/1.2.13: Retrieving package 6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7 from remote 'conan-center' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
zlib/1.2.13: Package installed 6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7
zlib/1.2.13: Downloaded package revision 481234a6c14e4b0bba04e4b86717c77e
coin-utils/2.11.6: Retrieving package f560f2e53e2577b853efd625fc4f85c98181f641 from remote 'conan-center' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
coin-utils/2.11.6: Package installed f560f2e53e2577b853efd625fc4f85c98181f641
coin-utils/2.11.6: Downloaded package revision a543cc55edcd9291e5a11b63788133a5
pkgconf/1.9.3: Appending PATH env var: C:\J\w\prod\BuildSingleReference@3\.conan\data\pkgconf\1.9.3\_\_\package\0a420ff5c47119e668867cdb51baff0eca1fdb68\bin
pkgconf/1.9.3: Setting PKG_CONFIG env var: C:/J/w/prod/BuildSingleReference@3/.conan/data/pkgconf/1.9.3/_/_/package/0a420ff5c47119e668867cdb51baff0eca1fdb68/bin/pkgconf.exe
pkgconf/1.9.3: Appending AUTOMAKE_CONAN_INCLUDES env var: /c/j/w/prod/buildsinglereference@3/.conan/data/pkgconf/1.9.3/_/_/package/0a420ff5c47119e668867cdb51baff0eca1fdb68/bin/aclocal
coin-osi/0.108.6: Applying build-requirement: gnu-config/cci.20210814
coin-osi/0.108.6: Applying build-requirement: pkgconf/1.9.3
coin-osi/0.108.6: Applying build-requirement: msys2/cci.latest
[HOOK - conan-center.py] pre_source(): [IMMUTABLE SOURCES (KB-H010)] OK
coin-osi/0.108.6: Configuring sources in C:\J\w\prod\BuildSingleReference@3\.conan\data\coin-osi\0.108.6\_\_\source\src
coin-osi/0.108.6: 
[HOOK - conan-center.py] post_source(): [LIBCXX MANAGEMENT (KB-H011)] OK
[HOOK - conan-center.py] post_source(): [CPPSTD MANAGEMENT (KB-H022)] OK
[HOOK - conan-center.py] post_source(): [SHORT_PATHS USAGE (KB-H066)] OK
coin-osi/0.108.6: Copying sources to build folder
coin-osi/0.108.6: Building your package in C:\J\w\prod\BuildSingleReference@3\.conan\data\coin-osi\0.108.6\_\_\build\e363b996481dec7f9909b333d17ccaa8bb269381
coin-osi/0.108.6: Generator txt created conanbuildinfo.txt
coin-osi/0.108.6: Calling generate()
coin-osi/0.108.6: Aggregating env generators
[HOOK - conan-center.py] pre_build(): [FPIC MANAGEMENT (KB-H007)] 'fPIC' option not found
[HOOK - conan-center.py] pre_build(): [FPIC MANAGEMENT (KB-H007)] OK
coin-osi/0.108.6: Calling build()
coin-osi/0.108.6: Copied 1 '.guess' file: config.guess
coin-osi/0.108.6: Copied 1 '.sub' file: config.sub
coin-osi/0.108.6: Calling:
 > "/c/j/w/prod/buildsinglereference@3/.conan/data/coin-osi/0.108.6/_/_/build/e363b996481dec7f9909b333d17ccaa8bb269381/src/configure" --disable-shared --enable-static --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include --without-blas --without-lapack --enable-msvc=MD 

----Running------
> "C:\J\w\prod\BuildSingleReference@3\.conan\data\coin-osi\0.108.6\_\_\build\e363b996481dec7f9909b333d17ccaa8bb269381\build-release\conan\conanbuild.bat" && "C:\J\w\prod\BuildSingleReference@3\.conan\data\coin-osi\0.108.6\_\_\build\e363b996481dec7f9909b333d17ccaa8bb269381\build-release\conan\msys2_mode.bat" && C:\J\w\prod\BuildSingleReference@3/s\9fc206\1\bin\msys64\usr\bin\bash.exe --login -c ^". \^"C:\J\w\prod\BuildSingleReference@3\.conan\data\coin-osi\0.108.6\_\_\build\e363b996481dec7f9909b333d17ccaa8bb269381\build-release\conan\conanbuild.sh\^" ^&^& \^"/c/j/w/prod/buildsinglereference@3/.conan/data/coin-osi/0.108.6/_/_/build/e363b996481dec7f9909b333d17ccaa8bb269381/src/configure\^" --disable-shared --enable-static --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include --without-blas --without-lapack --enable-msvc=MD ^"
-----------------
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.51
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
configure: loading site script /etc/config.site
checking build system type... x86_64-w64-mingw32
checking whether we want to compile in debug mode... no
checking for C compiler default output file name... conftest.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... obj
checking whether we are using the GNU C compiler... no
checking whether cl -nologo accepts -g... yes
checking for cl -nologo option to accept ANSI C... none needed
configure: Overruling autoconf; cl does not recognise -g.
configure: C compiler options are:  -MD -O2 -Ob2 -FS  
checking whether we are using the GNU C++ compiler... no
checking whether cl -nologo accepts -g... yes
checking whether C++ compiler cl -nologo works... yes
configure: Overruling autoconf; cl does not recognise -g.
configure: C++ compiler options are:  -MD -O2 -Ob2 -EHsc -FS  
configure: Trying to determine Fortran compiler name
checking for ifort... no
checking for fl32... no
checking for compile_f2c... no
configure: Fortran compiler options are:  
configure: Building of DLLs not supported in this configuration.
checking for egrep... grep -E
checking whether ln -s works... yes
checking for a BSD-compatible install... /c/j/w/prod/buildsinglereference@3/s/9fc206/1/bin/msys64/usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking dependency style of cl -nologo... none
checking dependency style of cl -nologo... none
checking whether to enable maintainer-specific portions of Makefiles... no
checking host system type... x86_64-w64-mingw32
checking for a sed that does not truncate output... /c/j/w/prod/buildsinglereference@3/s/9fc206/1/bin/msys64/usr/bin/sed
checking for non-GNU ld... link
checking if the linker (link) is GNU ld... no
checking for link option to reload object files... -r
checking for BSD-compatible nm... /c/j/w/prod/buildsinglereference@3/s/9fc206/1/bin/msys64/usr/bin/nm -B
checking how to recognise dependent libraries... file_magic file format pei*-i386(.*architecture: i386)?
checking how to run the C preprocessor... cl -nologo -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... no
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... no
checking dlfcn.h usability... no
checking dlfcn.h presence... no
checking for dlfcn.h... no
checking how to run the C++ preprocessor... cl -nologo -E
checking the maximum length of command line arguments... 8192
checking command to parse /c/j/w/prod/buildsinglereference@3/s/9fc206/1/bin/msys64/usr/bin/nm -B output from cl -nologo object... ok
checking for objdir... .libs
checking for ar... lib -nologo
checking for ranlib... ranlib
checking for strip... strip
checking for cl -nologo option to produce PIC... -DDLL_EXPORT
checking if cl -nologo PIC flag -DDLL_EXPORT works... yes
checking if cl -nologo static flag  works... yes
checking if cl -nologo supports -c -o file.obj... no
checking if we can lock with hard links... yes
checking whether the cl -nologo linker (link) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking whether the cl -nologo linker (link) supports shared libraries... no
checking for cl -nologo option to produce PIC... 
checking if cl -nologo static flag  works... yes
checking if cl -nologo supports -c -o file.obj... no
checking if we can lock with hard links... yes
checking whether the cl -nologo linker (link) supports shared libraries... no
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for unavailable option to produce PIC... -DDLL_EXPORT
checking if unavailable PIC flag -DDLL_EXPORT works... no
checking if unavailable static flag  works... no
checking if unavailable supports -c -o file.obj... no
checking if we can lock with hard links... yes
checking whether the unavailable linker (link) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
configure: Build is "x86_64-w64-mingw32".
checking for dos2unix... dos2unix
configure: Applying patches to libtool for cl compiler
checking if library version is set... no
checking whether source of project Glpk is available and should be compiled... no
checking whether source of project SoPlex is available and should be compiled... no
checking whether source of project Blas is available and should be compiled... no, --without-blas has been specified
checking whether source of project Lapack is available and should be compiled... no, --without-lapack has been specified
checking whether source of project Sample is available and should be compiled... no
checking whether source of project Netlib is available and should be compiled... no
checking whether source of project CoinUtils is available and should be compiled... no
checking whether source of project Osi is available and should be compiled... yes, source in Osi
configure: configuring doxygen documentation options
checking for doxygen... no
checking for latex... no
checking for dot... NO
checking for doxygen doc'n for CoinUtils ... //share/coin/doc/CoinUtils/doxydoc (tag)
checking for doxygen doc'n for Cgl ... //share/coin/doc/Cgl/doxydoc (tag)
checking for doxygen doc'n for Clp ... //share/coin/doc/Clp/doxydoc (tag)
checking for doxygen doc'n for DyLP ... //share/coin/doc/DyLP/doxydoc (tag)
checking for doxygen doc'n for Vol ... //share/coin/doc/Vol/doxydoc (tag)
checking for doxygen doc'n for SYMPHONY ... //share/coin/doc/SYMPHONY/doxydoc (tag)
checking which command should be used to link input files... cp
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doxydoc/doxygen.conf
config.status: executing depfiles commands
configure: configuring in Osi
configure: running /bin/sh '/c/j/w/prod/buildsinglereference@3/.conan/data/coin-osi/0.108.6/_/_/build/e363b996481dec7f9909b333d17ccaa8bb269381/src/Osi/configure' --prefix=/  '--disable-shared' '--enable-static' '--prefix=/' '--bindir=/bin' '--sbindir=/bin' '--libdir=/lib' '--includedir=/include' '--oldincludedir=/include' '--without-blas' '--without-lapack' '--enable-msvc=MD' 'CC=cl -nologo' 'CFLAGS= -MD -O2 -Ob2 -FS' 'CPPFLAGS= -DNDEBUG' 'CXXFLAGS= -MD -O2 -Ob2 -EHsc -FS' 'CXX=cl -nologo' 'LDFLAGS=' --cache-file=/dev/null --srcdir=/c/j/w/prod/buildsinglereference@3/.conan/data/coin-osi/0.108.6/_/_/build/e363b996481dec7f9909b333d17ccaa8bb269381/src/Osi
configure: loading site script /etc/config.site
checking build system type... x86_64-w64-mingw32
checking for svnversion... no
checking whether we want to compile in debug mode... no
checking for C compiler default output file name... conftest.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... obj
checking whether we are using the GNU C compiler... no
checking whether cl -nologo accepts -g... yes
checking for cl -nologo option to accept ANSI C... none needed
configure: Overruling autoconf; cl does not recognise -g.
configure: C compiler options are:  -MD -O2 -Ob2 -FS   -DOSI_BUILD
checking whether we are using the GNU C++ compiler... no
checking whether cl -nologo accepts -g... yes
checking whether C++ compiler cl -nologo works... yes
configure: Overruling autoconf; cl does not recognise -g.
configure: C++ compiler options are:  -MD -O2 -Ob2 -EHsc -FS   -DOSI_BUILD
configure: Building of DLLs not supported in this configuration.
checking for egrep... grep -E
checking whether ln -s works... yes
checking for a BSD-compatible install... /c/j/w/prod/buildsinglereference@3/s/9fc206/1/bin/msys64/usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking dependency style of cl -nologo... none
checking dependency style of cl -nologo... none
checking whether to enable maintainer-specific portions of Makefiles... no
configure: Using libtool script in directory ..
checking if library version is set... 14:6:13
checking for COIN-OR package CoinUtils... not given: Package coinutils was not found in the pkg-config search path.
Perhaps you should add the directory containing `coinutils.pc'
to the PKG_CONFIG_PATH environment variable
Package 'coinutils', required by 'virtual:world', not found
coin-osi/0.108.6: 
configure: WARNING: Failed to find a Fortran compiler!
configure: WARNING: Using pkg-config together with MS or Intel Compiler on Windows is not support by example Makefiles. Consider using --disable-pkg-config.
configure: error: Required package CoinUtils not available.
configure: error: /bin/sh '/c/j/w/prod/buildsinglereference@3/.conan/data/coin-osi/0.108.6/_/_/build/e363b996481dec7f9909b333d17ccaa8bb269381/src/Osi/configure' failed for Osi
coin-osi/0.108.6: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
coin-osi/0.108.6: ERROR: Package 'e363b996481dec7f9909b333d17ccaa8bb269381' build failed
coin-osi/0.108.6: WARN: Build folder C:\J\w\prod\BuildSingleReference@3\.conan\data\coin-osi\0.108.6\_\_\build\e363b996481dec7f9909b333d17ccaa8bb269381\build-release
ERROR: coin-osi/0.108.6: Error in build() method, line 108
	autotools.configure()
	ConanException: Error 1 while executing "/c/j/w/prod/buildsinglereference@3/.conan/data/coin-osi/0.108.6/_/_/build/e363b996481dec7f9909b333d17ccaa8bb269381/src/configure" --disable-shared --enable-static --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include --without-blas --without-lapack --enable-msvc=MD 
```

</details>
user: SpaceIm
issue_13086: state: open
title: [question] Best way to define and build a "code coverage instrumented" package variant
body: ### What is your question?

We need to build a package containing some binaries in two variants, once the normal binary and once the binaries must be instrumented so that the code coverage can be measured after tests have run.
For building we are using cmake that is invoked via the conan recipe build() function.

What I am thinking about is to introduce an option "coverage" to the conan package that allows to differentiate the variants of the package. Since this option is transported to the CMake call as a variable the cmakelist file can be implemented to either create instrumented or non-instrumented binary code depending on the option value.

Now the question would be how and when this option needs to be set. In case I first want to build the non-instrumented binary I of course run a conan install and then a conan build. If I now want to build the instrumented variant how can I hand over the "coverage" option to the build command assuming that the dependincies are the same for both variants? 
I guess I have to run a conan install with the option "coverage=true" so that this option is saved locally for the build function, right?

Last and most important question: What I described above, does that make sense or is there a better approach?

Thank you

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: MTomBosch
issue_13083: state: open
title: [bug] [maybe] env.append("CL", " /nologo") in a recipe creates	AttributeError: 'function' object has no attribute 'append' error
body: ### Environment details

* Operating System+version: Any
* Compiler+version: Any
* Conan version: 1.58
* Python version: 3.10


### Steps to reproduce

This change 
https://github.com/conan-io/conan-center-index/commit/c014471b56df814a81375b24f75e31d487f9db0c#diff-be29fd7111c51ef64d2c4fe8bbcf1243cd49c81cc33c97e76037c114654ea829L57

removed this code
```
            tc = NMakeToolchain(self)
            env = tc.environment
            env.append("CL", " /nologo")
```

This code producded the following Error
```
nasm/2.15.05: Calling generate()
ERROR: nasm/2.15.05: Error in generate() method, line 58
	env.append("CL", " /nologo")
	AttributeError: 'function' object has no attribute 'append'
```

If that code should never have been there and never worked, I can not say

Please decide if that breaks the compatibility promise Conan does, or not. 
If not, please just close that issue. Thank you!


### Logs

_No response_
user: a4z
issue_13080: state: open
title: [feature] Allow to use the profile name inside the cmake_layout build_folder_vars 
body: ### What is your suggestion?

Under this page https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmake_layout.html#:~:text=For%20example%2C%20this%20would%20implement%20the%20standard%20CMake,and%20cpp%20attributes%20described%20in%20the%20%28layout%20reference%29.

One can adjust the build folder to match settings or options being used.  Yet in my case, we have a set of settings/options that we refer to as a "platform".  We know that the platform "ABC" is an arm, gcc 9.3, Linux, etc...

Now I can ask conan cmake_layout to create a build folder such as build/gcc/9.3/Linux/etc./Release, but really this is "decomposing" what my ABC platform actually means.

So I am looking at using the name of the profile itself as a variable to the then compute the build folder.

So that I could shortcut the above with build_folder_vars=["profile_host[0].name"] for example and obtain build/ABC/Release as the build folder out of cmake_layout.

I understand that there may be more than one profile, so using an array would be require and the end-user would know to pass the first or last profile as being the one that named the build folder.

Another way to achieve this could be to add a new settings.vendor.name or settings.platform or settings.name variable that could hold the string ABC in question.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: hpe-ykoehler
issue_13076: state: open
title: [feature] PkgConfigDeps.set_property() for renaming .pc files
body: ### What is your suggestion?

CMakeDeps recently gained a handy set_property() method.

For the ffmpeg recipe, the x264.pc file is manually renamed to libx264.pc,
it would be pretty sweet if it could become
```
pc = PkgConfigDeps(self)
pc.set_property("libx264", "pkg_config_name", "libx264")
```
or something like that.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: paulharris
issue_13073: state: open
title: [bug] expose `conan.tools.files.sha256sum`
body: ### Environment details

* Operating System+version: `Linux debian 6.1.8-x64v3-custom-xanmod1 #1 SMP PREEMPT_DYNAMIC Tue Jan 31 19:37:53 +07 2023 x86_64 GNU/Linux`
* Compiler+version: `g++ (GCC) 12.2.0`
* Conan version: `Conan version 2.0.0-beta9`
* Python version: `Python 3.9.2`


### Steps to reproduce

1. `python -c "from conan.tools.files import sha256sum"`

### Logs

```
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name 'sha256sum' from 'conan.tools.files' (/home/sse4/.local/lib/python3.9/site-packages/conan/tools/files/__init__.py)
```
user: SSE4
issue_13069: state: open
title: [bug] Virtual{Run,Build}Env add current working directory to LD_LIBRARY_PATH
body: ### Environment details

* Operating System+version: Ubuntu 22.04.1 LTS
* Compiler+version: 11.3.0
* Conan version: 2.0.0-beta9
* Python version: CPython 3.10.6


### Steps to reproduce

Execute the following: `conan install --requires fmt/9.1.0 --tool-requires bison/3.8.2 -o "fmt/*:shared=True" -g VirtualBuildEnv -g VirtualRunEnv -b missing -u`
The resulting virtual environments ends with `...:$LD_LIBRARY_PATH`, `LD_LIBRARY_PATH` is usually undefined, so this expands to just `...:`, which may be interpreted as being the current working directory.

This behavior actually breaks building glibc with conan.

This could be fixed be replacing it by a `...${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH` which will only expand the `:` when `LD_LIBRARY_PATH` is defined.

### Logs

From trying to make a glibc recipe:
```
configure: error: 
*** LD_LIBRARY_PATH shouldn't contain the current directory when
*** building glibc. Please change the environment variable
*** and run configure again.
glibc/2.37: ERROR: 
Package '0c481dc58c17f75b32d8aa640b5e06e865d97c84' build failed
```
user: TheClonerx
issue_13062: state: open
title: Boost 1.81.0 and gtest 1.12.1 built with different visibilities on MacOS
body: # Versions
Conan version 1.58.0
MacOS 12.6.3
Apple Clang 14.0

# Conan File
```
[requires]
boost/1.81.0
gtest/1.12.1
[generators]
cmake_find_package
[options]
boost:without_atomic=True
boost:without_chrono=True
boost:without_container=True
boost:without_context=True
boost:without_contract=True
boost:without_coroutine=True
boost:without_date_time=True
boost:without_exception=True
boost:without_fiber=True
boost:without_filesystem=True
boost:without_graph=True
boost:without_graph_parallel=True
boost:without_iostreams=True
boost:without_json=True
boost:without_locale=True
boost:without_log=True
boost:without_math=True
boost:without_mpi=True
boost:without_nowide=True
boost:without_program_options=True
boost:without_python=True
boost:without_random=True
boost:without_regex=True
boost:without_serialization=True
boost:without_stacktrace=True
boost:without_system=False
boost:without_test=True
boost:without_thread=True
boost:without_timer=True
boost:without_type_erasure=True
boost:without_url=False
boost:without_wave=True
```

# Conan Info
```
[settings]
    arch=x86_64
    build_type=Debug
    compiler=apple-clang
    compiler.cppstd=20
    compiler.libcxx=libc++
    compiler.version=14.0
    os=Macos

[requires]
    boost/1.Y.Z
    gtest/1.Y.Z

[options]


[full_settings]
    arch=x86_64
    arch_build=x86_64
    build_type=Debug
    compiler=apple-clang
    compiler.cppstd=20
    compiler.libcxx=libc++
    compiler.version=14.0
    os=Macos
    os_build=Macos

[full_requires]
    boost/1.81.0:0efd09d0b0cfdd985370c44ffbbada262df82953
    gtest/1.12.1:bea8f6d16a8dc05432bcc6dc8e49989621426e7e

[full_options]
    boost:asio_no_deprecated=False
    boost:buildid=None
    boost:bzip2=True
    boost:debug_level=0
    boost:diagnostic_definitions=False
    boost:error_code_header_only=False
    boost:extra_b2_flags=None
    boost:fPIC=True
    boost:filesystem_no_deprecated=False
    boost:filesystem_use_std_fs=False
    boost:filesystem_version=None
    boost:header_only=False
    boost:i18n_backend=deprecated
    boost:layout=system
    boost:lzma=False
    boost:magic_autolink=False
    boost:multithreading=True
    boost:namespace=boost
    boost:namespace_alias=False
    boost:pch=True
    boost:python_executable=None
    boost:python_version=None
    boost:segmented_stacks=False
    boost:shared=False
    boost:system_no_deprecated=False
    boost:system_use_utf8=False
    boost:visibility=hidden
    boost:without_atomic=True
    boost:without_chrono=True
    boost:without_container=True
    boost:without_context=True
    boost:without_contract=True
    boost:without_coroutine=True
    boost:without_date_time=True
    boost:without_exception=True
    boost:without_fiber=True
    boost:without_filesystem=True
    boost:without_graph=True
    boost:without_graph_parallel=True
    boost:without_iostreams=True
    boost:without_json=True
    boost:without_locale=True
    boost:without_log=True
    boost:without_math=True
    boost:without_mpi=True
    boost:without_nowide=True
    boost:without_program_options=True
    boost:without_python=True
    boost:without_random=True
    boost:without_regex=True
    boost:without_serialization=True
    boost:without_stacktrace=True
    boost:without_system=False
    boost:without_test=True
    boost:without_thread=True
    boost:without_timer=True
    boost:without_type_erasure=True
    boost:without_url=False
    boost:without_wave=True
    boost:zlib=True
    boost:zstd=False
    gtest:build_gmock=True
    gtest:fPIC=True
    gtest:hide_symbols=False
    gtest:no_main=False
    gtest:shared=False

[recipe_hash]


[env]
```

When I build this using:

```
conan_cmake_install(
    PATH_OR_REFERENCE .
    BUILD missing
    REMOTE conancenter
    SETTINGS ${settings})
```

I get errors like:
```
[build] ld: warning: direct access in function '___cxx_global_var_init.178' from file '/Users/avance/.conan/data/boost/1.81.0/_/_/package/0efd09d0b0cfdd985370c44ffbbada262df82953/lib/libboost_url.a(src.o)' to global weak symbol 'guard variable for boost::system::detail::stdcat_mx_holder<void>::mx_' from file 'CMakeFiles/http_server_test.dir/main.cpp.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
```

I tried adding:
```
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fvisibility=hidden")
```

I then get similar errors for `gtest`:
```
[build] ld: warning: direct access in function 'testing::internal::ParameterizedTestSuiteInfo<http::(anonymous namespace)::StockResponsesTests>::RegisterTests()' from file 'CMakeFiles/http_server_tests.dir/stock_responses_tests.cpp.o' to global weak symbol 'std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::endl<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)' from file '/Users/avance/.conan/data/gtest/1.12.1/_/_/package/bea8f6d16a8dc05432bcc6dc8e49989621426e7e/lib/libgmock.a(gmock-all.cc.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
```

Looks like gtest and boost are built with different visibility settings/flags. Is there anything I can do to stop these warnings?

I didn't see this when using boost 1.80.0 with gtest 1.12.1.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: av4625
issue_13057: state: open
title: [question] How can I create a package without .cpp files but still allow user to build by specific options locally?
body: ## Background

I have a cpp project A and I can create and upload a conan package by using following commands:

```shell
conan create . 
conan upload "A/0.1.0"
```

when I checked the package detail in /home/xxx/.conan/data/A/[path-to-package], I found all my .cpp files have been exported too. I hoped I could protect my source code (which means I don't want user download any .cpp files when using A package). How can I acheive this goal?

## Sample conanfile.py

```python
from conans import ConanFile, CMake, tools


class AConan(ConanFile):
    name = "A"
    version = "0.1.0"
    settings = "os", "compiler", "build_type", "arch"
    options = {
        "shared": [True, False],
        "fPIC": [True, False],
    }
    default_options = {
        "shared": True,
        "fPIC": True,
    }
    generators = "cmake"
    exports_sources = "src/*"

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def requirements(self):
        self.requires("catch2/2.13.9")

    def build(self):
        cmake = CMake(self)
        cmake.configure(source_folder="src")
        cmake.build()

        # Explicit way:
        # self.run('cmake %s/hello %s'
        #          % (self.source_folder, cmake.command_line))
        # self.run("cmake --build . %s" % cmake.build_config)

    def package(self):
        self.copy("*.h", dst="include/modules", src="src", keep_path=False)
        self.copy("*.hpp", dst="include/modules", src="src", keep_path=False)
        libDir = "lib/" + self.name
        self.copy("*", dst=libDir, keep_path=True)

    def package_info(self):
        self.cpp_info.libs = [self.name]
```

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: timxian
issue_13053: state: open
title: How to create a build/host specific conan.lock file from a base lock file
body: ### What is your question?

I've been tasked to update our use of CMake/Conan to use conan lock files.

I have a base lock file that I created using the following command:

`conan lock create --base --lockfile-out conan.base.lock ../../../build/conanfile.txt`

The conanfile.txt was present from the last build I had done, and is correct.  The newly created conan.base.lock file contains all of the dependencies and their versions but none of the build/host information. **So far so good.**

Now, as part of our conan cmake environment, I'm trying to use this conan.base.lock file to generate the build/host specific lock file. To do that, I'm using the macros provided in conan.cmake as follows:

```cmake
conan_cmake_autodetect(conan_settings)
conan_cmake_lock_create(
   LOCKFILE ../Src/Cmake/Cloud/conan.base.lock
   LOCKFILE_OUT ./conan.lock
   SETTINGS ${conan_settings}
   )
```

The intention is once the buid/host specific lock file is created, I can pass that to `conan_cmake_install` command. However, I'm getting an error with `conan_cmake_lock_create`. The error I'm getting is shown below:

```bash
-- Conan: Version found Conan version 1.58.0
-- Conan executing: C:/Users/hoffmat/AppData/Local/Programs/Python/Python310/Scripts/conan.exe lock create --lockfile ../Src/Cmake/Cloud/conan.base.lock --lockfile-out ./conan.lock --settings arch=x86_64 --settings 
build_type=Debug --settings compiler=Visual Studio --settings compiler.version=17 --settings compiler.runtime=MDd --settings compiler.cppstd=17
ERROR: Specify the 'name' and the 'version'
CMake Error at Cmake/Cloud/conan.cmake:761 (message):
  Conan lock create failed='1'
Call Stack (most recent call first):
  Cmake/Cloud/PhxGrpcCloudConfig.cmake:44 (conan_cmake_lock_create)
  CMakeLists.txt:26 (include)
```

Upon inspecting the `conan_cmake_lock_create` macro, I see it's not valid to pass `name` and `version` to it.  So, as a test, I modified `conan.cmake` and hard-coded values for `name` and `version`  just to see if I could get past this problem, but I got the same error:

```bash
-- Conan executing: C:/Users/hoffmat/AppData/Local/Programs/Python/Python310/Scripts/conan.exe lock create --name fubar --version 1.0 --lockfile ../Src/Cmake/Cloud/conan.base.lock --lockfile-out ./conan.lock --settings arch=x86_64 --settings build_type=Debug --settings compiler=Visual Studio --settings compiler. Version=17 --settings compiler.runtime=MDd --settings compiler.cppstd=17
ERROR: Specify the 'name' and the 'version'
```

I saw on the conan site, in all it's discussions about base lock files, when calling `lock create`  that you pass it a conanfile.py file.  However, that doesn't make sense for my situation the conanfile.py files are for a specific package.  I don't have a specific conanfile.py file in this context. 

So, I'm stumped how to do this...  any help is appreciated. 





### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: BoilerTom90
issue_13051: state: open
title: [feature] build-time system_requirements
body: ### What is your suggestion?

There are times where a package needs to have a system package installed but only at build time.  This can be useful for bootstrapping (such as building a cmake conan package using a cmake system package) and for cases where a large dependency is needed to build, but not to run - exactly in the same vein as `tool_requires`.

A lot of the packages that I build use pybind11.  There are some large pip packages that may be needed for build/test that are not needed when the final package is installed.  In these cases, I put the pip install in the `build` function to ensure that we don't install the pip packages with the final package.  I realize that this is a terrible solution, but it's the only way that I am aware of to prevent the issue.

I think there are two reasonable ways that this could be implemented.
1. Add a "context" to the system package manager functions, much like what we have for `requires`.  Something like:
```
def system_requirements(self):
   Apt(self).install(pkg_list, build=True)
```
2. Create a `tool_system_requirements` function:
```
def tool_system_requirements(self):
  Apt(self).install(pkg_list)
``` 

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: jsallay
issue_13047: state: open
title: [feature] Add an compiler attribute to settings if clang so that conan client & recipes has a chance to disambiguate between windows clang flavors
body: ### What is your suggestion?

It's more or less related to https://github.com/conan-io/conan/issues/12336, and to many issues conan-center is facing from users building recipes with clang-cl, LLVM clang, MinGW clang etc.

Recipes have sometimes to make decision depending on the compiler:

- raise if not supported
- build with Autotools, CMake, NMake, MSBuild or Meson depending on the compiler (you can do a build with NMake or MSBuild if compiler is clang-cl, but not if it's clang MinGW).
- inject options, flags, env vars
- predict lib name of each component

Currently, it's impossible for a recipe to disambiguate which windows clang flavor a consumer is using, and clang-cl is fundamentally different to MinGW clang. There should be a compiler attribute, or anything else in settings which should be the canonical conan way to express a specific clang flavor on Windows to conan, so that recipes can rely on it for any custom logic (bonus: add helpers like is_clang_cl(), is_mingw() based on settings).

Many conan-center recipes are broken for at least one Windows clang flavor, without any way to fix it without breaking the other.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: SpaceIm
issue_13046: state: open
title: [bug] Extracting packages from Artifactory after download fails on Windows/SMB
body: ### Environment details

* Operating System+version: Windows Server 2016
* Compiler+version: Visual Studio 2019
* Conan version: 1.57
* Python version: 3.10


### Steps to reproduce

1. You need to have a package in Artifactory that is fetched during conan install as a dependency.
2. Do a conan install on a Windows SMB share and the extraction of the conan_package.tgz and conan_export.tgz fails.
3. With debug prints it could be determined that the following error codes are returned by Windows in Pythons ntpath.py:

ntpath.py:660: [WinError 3] The system cannot find the path specified

ntpath.py:679: [WinError 2] The system cannot find the file specified

When it works (e.g. because a time.sleep(5) is added in line 679) in both cases the error code 3 is returned.

Workaround:

Set the registry key HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\FileNotFoundCacheLifetime to 0 (no reboot needed) and it works. The default value is 5 seconds.

It looks like the FileNotFoundCache is either buggy or the caching breaks conan/Python path handling code.

### Logs

_No response_
user: aheck
issue_13043: state: open
title: Package visual studio compiler for use with tool_requires
body: ### What is your question?

OS: windows 10
conan 1.56

I have packaged the "Visual Studio 2017" toolchain in a package and use it on the consumer side in my build profile [tool_requires].
My consumer I would then like my consumer recipe to detect and use the toolchain provided by conan like this:

```
    def generate(self):
        tc = CMakeToolchain(self)
        tc.cache_variables["CMAKE_GENERATOR_INSTANCE"] = "[path to toolchain]"
        tc.generate()
        deps = CMakeDeps(self)
        deps.generate()
```

[path to toolchain] points to "...2017\BuildTools" within the package as indicated by cmake.
But CMakeToolchain refuses to detect anything but the installed Visual Studio in "c:\Program Files....."
Is there a way for me to be able to force the "system" to use the visual studio compiler from my package so that other developers in my team can build without manually installing visual studio.

Regards
Klaus


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: klausholstjacobsen
issue_13036: state: open
title: [feature] Make it easy for all consumers using CMakeDeps + CMakeToolchain to find tool requirements with find_package
body: `find_package` is *the* way to find package dependencies in CMake. It supports version checking. It lets a package author handle the search for installed components, which is a package-specific implementation detail that consumers do not want to be concerned with. Consumers do not want to be mucking with `find_program` or `find_library` if they don't have to. Even if they _do_ have to, they can always package that into a Find Module that is invoked by their call to `find_package`. `find_package` gives consumers options: lean on the package to find its components if it can; fall back to your own Find Module if it cannot. Consumers should always have the option to find dependencies with `find_package`.

If the above has convinced you, then there's a problem with the newest CMake integration (`CMakeDeps` + `CMakeToolchain`) in Conan: it is very  difficult (impossible in some cases) to use `find_package` to find a tool requirement.

`CMakeDeps` generates a CMake Package Configuration File in the output folder during `conan install` for tool requirements _only if_ the consumer [assigns](https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmakedeps.html#build-context-activated) `build_context_activated` in a `generate` method like below, and _only if_ the consumer is using separate build and host profiles (`conan install` will fail with an error otherwise!):

```python
    def generate(self):
        deps = CMakeDeps(self)
        deps.build_context_activated = ['mytool']
        deps.generate()
        tc = CMakeToolchain(self)
        tc.generate()
```

These are too many hoops. This method is not low-friction easy for consumers who are not cross-compiling (i.e., most users), and it does not support consumers at all who use `conanfile.txt`. One way to fix this method is to unconditionally generate package configuration files for a consumer's direct tool requirements. This is what the old CMake `find_package` generators did.

There is another possible fix, for packages that generate and install their own CMake Package Configuration File: let tool requirements modify the `CMAKE_PREFIX_PATH` in the `CMakeToolchain` generator. Presently, that power is [limited](https://github.com/conan-io/conan/blob/637ea443323526f3a89249238c0fa01888bc0afe/conan/tools/cmake/toolchain/blocks.py#L469-L471) to non-tool requirements. They can do it by setting `cpp_info.builddirs`. I don't care if tool requirements have to do it through a different `cpp_info` property, but there should be a way. This method _used_ to work just 6 months ago, when I was [using](https://github.com/thejohnfreeman/project-template-cpp/actions/runs/2784932607) it in my own project.

Right now, my only workaround is to depend on my tool as a non-tool requirement.

Tagging @SpaceIm who spoke with me in Slack about this.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: thejohnfreeman
issue_13035: state: open
title: [bug] CMakeDeps generate Release config packages for packages with Debug setting set
body: ### Environment details

* Operating System+version: archlinux, up to date
* Compiler+version: gcc 12
* Conan version: 1.58
* Python version:  3.10.9


### Steps to reproduce

With this conan file for example

```
from conan import ConanFile
from conan.tools.cmake import CMakeDeps, CMakeToolchain, cmake_layout
from conan.tools.env import VirtualRunEnv


class EmbreeIssue(ConanFile):
    settings = "os", "compiler", "build_type", "arch"

    requires = (
        "embree3/3.13.5",
        "cgal/5.5.1",
    )

    def config_options(self):
        self.options["embree3"].shared = True

    def generate(self):
        cmake = CMakeDeps(self)
        cmake.generate()

        toolchain = CMakeToolchain(self)
        toolchain.variables["CMAKE_MAP_IMPORTED_CONFIG_DEBUG"] = "Release"
        toolchain.generate()

        venv = VirtualRunEnv(self)
        venv.generate()

    def layout(self):
        cmake_layout(self)

```

and with a profile with build_type set to Release

```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=12
compiler.libcxx=libstdc++11
build_type=Release
```

execute conan install specifying embree to be built in debug
```
conan install . --pr <profile> -s embree3:build_type=Debug
```

In this case, CMakeDeps is still generating a config package for release, but its pointing to a package in the cache which is built in Debug mode. 

```
ls -l *embree*                                                                                        
-rw-r--r-- 1 jjcasmar jjcasmar 1323 Feb  1 18:40 embree-config.cmake
-rw-r--r-- 1 jjcasmar jjcasmar  577 Feb  2 17:44 embree-config-version.cmake
-rw-r--r-- 1 jjcasmar jjcasmar 1839 Feb  2 17:44 embree-release-x86_64-data.cmake
-rw-r--r-- 1 jjcasmar jjcasmar 3212 Feb  2 17:44 embree-Target-release.cmake
-rw-r--r-- 1 jjcasmar jjcasmar  841 Feb  2 17:44 embreeTargets.cmake
```



### Logs

_No response_
user: jjcasmar
issue_13033: state: open
title: [question] How to handle CMake interface libaries in Conan
body: ### What is your question?

Hey guys,
with your help I did manage to create a first version of my FreeRTOS recipe here. I created the CMake files to build FreeRTOS via Cmake.
https://github.com/conan-io/conan/issues/12681.

Now meanwhile freertos has an "official" CMake support.
https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/CMakeLists.txt

FreeRTOS now recommends to pass the FreeRTOSConfig.h an the used port as a separate interface library.
Is it possible to make my Conan Recipe respect interface libraries?
The challenge is that the interface libraries are not part of the conan recipe and the FreeRTOS Source Repository, instead this interface libraries are placed in the "actual" project which consumes the conan packages.


This is my current recipe. Thx for your help guys :)
```
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMake, cmake_layout
from conan.tools.scm import Git


class FreeRTOSConan(ConanFile):
    name = "FreeRTOS"
    version = "0.4.3"

    # Optional metadata
    license = "Apache 2.0"
    author = "Julian Heni"
    url = "https://github.com/FreeRTOS/FreeRTOS-Kernel.git"
    description = "FreeRTOS as a conan 3rd party"
    topics = ("FreeRTOS", "c", "c++")

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False], "BUILD_TARGET": [True, False]}
    default_options = {"shared": True, "fPIC": True, "BUILD_TARGET": False}
    generators = "CMakeDeps"
    # build_policy = "always"  # for better debugging always build freertos

    def source(self):
        git = Git(self)
        # check out tagged version
        clone_args = [f"-b main"]
        git.clone(url="https://github.com/FreeRTOS/FreeRTOS-Kernel.git", args=clone_args)

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        if self.options.BUILD_TARGET:
            print("Building target")
            tc.cache_variables["BUILD_TARGET"] = "ON"

        else:
            print("Building simulation")
            tc.cache_variables["BUILD_TARGET"] = "OFF"
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure(build_script_folder="freertos")
        cmake.build()
        cmake.test(build_type=self.settings.build_type, target="FreeRTOS")

    def package(self):
        cmake = CMake(self)
        cmake.install()

    def package_info(self):
        self.cpp_info.libs = ["FreeRTOS"]
        self.cpp_info.includedirs = ["include"]

```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Ju1He1
issue_13030: state: open
title: [bug] expose `conan.tools.files.dos2unix` and `conan.tools.files.unix2dos` (#12872)
body: ### Environment details

* Operating System+version: `Linux debian 6.1.8-x64v3-custom-xanmod1 #1 SMP PREEMPT_DYNAMIC Tue Jan 31 19:37:53 +07 2023 x86_64 GNU/Linux`
* Compiler+version: `g++ (GCC) 12.2.0`
* Conan version: `Conan version 2.0.0-beta9`
* Python version: `Python 3.9.2`

### Steps to reproduce

1. `python -c "from conan.tools.files import dos2unix"`

### Logs

```
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name 'dos2unix' from 'conan.tools.files' (/home/sse4/.local/lib/python3.9/site-packages/conan/tools/files/__init__.py)
```
user: SSE4
issue_13029: state: open
title: [bug] expose `conan.tools.apple.apple_deployment_target_flag` (#12872)
body: ### Environment details

* Operating System+version: `Linux debian 6.1.8-x64v3-custom-xanmod1 #1 SMP PREEMPT_DYNAMIC Tue Jan 31 19:37:53 +07 2023 x86_64 GNU/Linux`
* Compiler+version: `g++ (GCC) 12.2.0`
* Conan version: `Conan version 2.0.0-beta9`
* Python version: `Python 3.9.2`



### Steps to reproduce

1. `python -c "from conan.tools.apple import apple_deployment_target_flag"`

### Logs

```
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name 'apple_deployment_target_flag' from 'conan.tools.apple' (/home/sse4/.local/lib/python3.9/site-packages/conan/tools/apple/__init__.py)
```
user: SSE4
issue_13028: state: open
title: [bug] expose `conan.tools.gnu.get_gnu_triplet` (#12872)
body: ### Environment details

* Operating System+version: `Linux debian 6.1.8-x64v3-custom-xanmod1 #1 SMP PREEMPT_DYNAMIC Tue Jan 31 19:37:53 +07 2023 x86_64 GNU/Linux`
* Compiler+version: `g++ (GCC) 12.2.0`
* Conan version: `Conan version 2.0.0-beta9`
* Python version: `Python 3.9.2`


### Steps to reproduce

1. `python -c "from conan.tools.gnu import get_gnu_triplet; get_gnu_triplet()"`

### Logs

```
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: 'module' object is not callable
```
user: SSE4
issue_13027: state: open
title: [bug] `tools.build.compiler_executables` not used in `conan install`
body: ### Environment details

* Operating System+version: Ubuntu 22.10
* Compiler+version: gcc-11 but gcc-12 is also installed and set as a default compiler in Ubuntu
* Conan version: 1.58.0
* Python version: 3.10.7


### Steps to reproduce

I have the following profile file:

```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++11
build_type=Release
[conf]
tools.build.compiler_executables={"c": "gcc-11", "cpp": "g++-11"}
```

When I run `conan install` with it I get a CMake error as below. Shouldn't conan force a correct compiler to be used by CMake in this step?

### Logs

```
doxygen/1.9.4: Aggregating env generators
doxygen/1.9.4: Calling build()
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Adjusting output directories
-- Conan: Using cmake targets configuration
-- Library fl found /home/mpusz/.conan/data/flex/2.6.4/_/_/package/4cc81c2613a066531a3fa4ef00e16064aeb208d2/lib/libfl.a
-- Library y found /home/mpusz/.conan/data/bison/3.7.1/_/_/package/4cc81c2613a066531a3fa4ef00e16064aeb208d2/lib/liby.a
-- Library xapian found /home/mpusz/.conan/data/xapian-core/1.4.19/_/_/package/a0c40af3c32dbfe769a9ed5f794a76607ecbca08/lib/libxapian.a
-- Library z found /home/mpusz/.conan/data/zlib/1.2.12/_/_/package/dfbe50feef7f3c6223a476cd5aeadb687084a646/lib/libz.a
-- Library uuid found /home/mpusz/.conan/data/libuuid/1.0.3/_/_/package/dfbe50feef7f3c6223a476cd5aeadb687084a646/lib/libuuid.a
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan: Compiler GCC>=5, checking major version 11
-- Conan: Checking correct version: 12
CMake Error at conanbuildinfo.cmake:1067 (message):
  Detected a mismatch for the compiler version between your conan profile
  settings and CMake:

  Compiler version specified in your conan profile: 11

  Compiler version detected in CMake: 12.2

  Please check your conan profile settings (conan profile show
  [default|your_profile_name])

  P.S.  You may set CONAN_DISABLE_CHECK_COMPILER CMake variable in order to
  disable this check.
Call Stack (most recent call first):
  conanbuildinfo.cmake:1151 (conan_error_compiler_version)
  conanbuildinfo.cmake:1258 (check_compiler_version)
  conanbuildinfo.cmake:806 (conan_check_compiler)
  CMakeLists.txt:5 (conan_basic_setup)
```
user: mpusz
issue_13023: state: open
title: [bug] ConanOutput not working with CONAN_LOG_RUN_TO_OUTPUT set to "False"
body: ### Environment details

* Operating System+version: Windows
* Conan version: 1.57
* Python version: 3.10



### Steps to reproduce

Build a recipe like "qt" with CONAN_LOG_RUN_TO_OUTPUT set to False to reduce the output.
This will fail on the "python version guessing".

Reproduce as Code:
```
import os
import sys
from io import StringIO
from conans.client.output import ConanOutput
from conans.client.runner import ConanRunner

buffer = StringIO()
out = ConanOutput(sys.stdout)
r = ConanRunner(output=out, log_run_to_output=True)
assert r("python --version", output=buffer) == 0
print(buffer.getvalue())
assert buffer.getvalue() != ""

buffer = StringIO()
out = ConanOutput(sys.stdout)
r = ConanRunner(output=out, log_run_to_output=False)
assert r("python --version", output=buffer) == 0
print(buffer.getvalue())
assert buffer.getvalue()  != ""  ## <-- fails

```

It should be possible to still wrap the output of the pipe with "run"



### Logs

```
>>> import os
>>> import sys
>>> from io import StringIO
>>> from conans.client.output import ConanOutput
>>> from conans.client.runner import ConanRunner
>>>
>>> buffer = StringIO()
>>> out = ConanOutput(sys.stdout)
>>> r = ConanRunner(output=out, log_run_to_output=True)
>>> assert r("python --version", output=buffer) == 0
<_io.StringIO object at 0x0000017B4F888C10> <_io.StringIO object at 0x0000017B4F888C10>
>>> print(buffer.getvalue())
Python 3.10.0

>>> assert buffer.getvalue() != ""
>>>
>>> buffer = StringIO()
>>> out = ConanOutput(sys.stdout)
>>> r = ConanRunner(output=out, log_run_to_output=False)
>>> assert r("python --version", output=buffer) == 0
<_io.StringIO object at 0x0000017B4F383E20> <_io.StringIO object at 0x0000017B4F383E20>
>>> print(buffer.getvalue())

>>> assert buffer.getvalue()  != ""  ## <-- fails
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError
>>>
```
user: roalter
issue_13018: state: open
title: [feature][CMakeDeps] Refactor
body: ### What is your suggestion?

This issue aims to list all the things to be improved in a future version of CMakeDeps:

- [ ] Distinguish between STATIC/SHARED libraries (related to https://github.com/conan-io/conan/issues/3230#issuecomment-529229441 among others)
- [ ] Improve Apple Frameworks management (related to https://github.com/conan-io/conan/issues/10140)


Feel free to add more issues here...

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: franramirez688
issue_13017: state: open
title: [feature] Add new field `system_frameworks` to `cpp_info`
body: ### What is your suggestion?

We should add a new field `system_frameworks` to `self.cpp_info` (similar behavior as `system_libs`).

The idea would be to have the Apple System Frameworks listed there to differentiate between system ones and own user ones.

```python
def package_info(self):
        self.cpp_info.system_frameworks = ["Foundation"]
        self.cpp_info.components["Component"].frameworkdirs = [os.path.join(self.package_folder, "MyFrameworkFolder")]
        self.cpp_info.components["Component"].frameworks = ["MyFramework"]
```

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: franramirez688
issue_13012: state: open
title: [question] Managing rpaths
body: ### What is your question?

I have a CMake project which uses several in-house libraries which are managed by conan. Theses libraries have also some dependencies. 

The compilation and link phase are fine, but when I try to run my executables, the executable can't find some of the libraries. 

I have been debugging this and it appears to be an issue with the dependency of the dependencies. That make sense because the dependencies are packaged with conan using 
```
cmake = CMake(self)
cmake.install()
```
which removes the rpath, so my executable have the rpath set and can find the dependencies, but the dependencies doesn't have rpath and can't find their own dependencies. 

However, I have been doing some testing with spdlog, which uses fmt as a transitive dependency, and in that case things seems to work fine. 

Is this something expected? What are the best practices regarding this? 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jjcasmar
issue_13008: state: open
title: [question] Requirements - combine private and override
body: ### What is your question?

Hi!

I have a question about combining private and override. Here is a minimal example:

1. It is shown on top of the example from here: https://docs.conan.io/en/latest/versioning/introduction.html#dependencies-overriding
2. There are 4 combinations of requirement definitions to consume pkga:
 a. 'pkga/2.0'
 b. ('pkga/2.0','override'),
 c. ('pkga/2.0','private'),
 d. ('pkga/2.0','override', 'private'),


ad a. - This works perfectly fine and it is printing a warning
>     WARN: pkgb/1.0: requirement pkga/1.0 overridden by pkgd/1.0 to pkga/2.0
ad b. - works exactly same as a.
ad c. - Throws an error:

>     ERROR: Conflict in pkgd/1.0:
>         'pkgd/1.0' requires 'pkga/2.0' while 'pkgb/1.0' requires 'pkga/1.0'.
>         To fix this conflict you need to override the package 'pkga' in your root package.

ad d. - Finish without error, but uses pkga/1.0.

I have an issue with point d. If I correctly understand the implementation, when you define dependency as private, it is not considered during dependency resolution. But in my use case, I need to hide a particular dependency (Therefore defining this as private), but I want to use it to override dependency. In other words, I need to override to pkga/2.0.
Is there any way to achieve this?

Minimal example with logs. Please update PkgD\conanfile.py to check different variants.
[ConanPrivateOverride.zip](https://github.com/conan-io/conan/files/10538666/ConanPrivateOverride.zip)

Thanks,
Michal

* Operating System+version: Windows 10, 21H2
* Compiler+version: N/A
* Conan version: Conan 1.57.0
* Python version: 3.10.6

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: MichalCermakx
issue_12995: state: open
title: remove cache from CMakeToolchain.variables
body: Changelog: Fix: Remove ``CACHE`` from ``CMakeToolchain.variables``
Docs: https://github.com/conan-io/docs/pull/XXXX


This is exploratory, to see what could break while investigating https://github.com/conan-io/conan/issues/12994. I recall there were some reasons, but lets check.


user: memsharded
issue_12994: state: open
title: [bug] CMakeToolchian 'variables' attribute declares CACHE variables instead of normal ones.
body: ### Environment details

* Operating System+version: Ubuntu 20.04.1
* Compiler+version: GCC 9.4.0
* Conan version: 2.0.0-beta8
* Python version: 3.8.10


### Steps to reproduce

In essence this might not seems as a big problem but if you have the following setup its quite hard to figure out what's going on and it shouldn't be like that, correct me if I'm wrong. I've created a git [repo](https://github.com/hrco159753/conan-bugs.git) where I created a simple project that demonstrates the problem, its in the 'CMakeToolchainCacheVariables' directory. 

So to explain what I've created, I have a project that has an option called 'someOption' that passes the value of that option to cmake by using `CMakeToolchain`, i.e. `tc.variables["SOME_VALUE"] = self.option.someOption` and it has a default value of "<Unknown>". In "CMakeLists.txt" I'm just forwarding it to a compiler definition and then I'm printing it in the `main.cpp`. Most of this is not necessary but it shows the issue directly. Ok so, I've positioned myself into the 'CMakeToolchainCacheVariables' directory and invoked the following sequence of commands:
- `conan editable . bug/0.0.1 && conan build . && conan test test_package bug/0.0.1`
and it prints, as expected "Value: <Unknown>". After that I've invoked this:
- conan build . -o bug/*:someOption="Something" && conan test test_package bug/0.0.1`

and with this I was hoping to get "Value: Something" as the output, but sadly I've got the same as before.
The way how I succeeded to get what I wanted is to delete the "build" directory and then invoke the previous, so like this:
- rm -rf build && conan build . -o bug/*:someOption="Something" && conan test test_package bug/0.0.1`

I don't want to do that, everything would be ok if the generated toolchain declares `SOME_VALUE` variable as a normal, non-cached variable, so instead of `set(SOME_VARIABLE "<Unknown>" CACHE STRING "Variable SOME_VARIABLE conan-toolchain defined")` just `set(SOME_VARIABLE "<Unknown>" PARENT_SCOPE")`. `PARENT_SCOPE` is needed so that this variable gets to the "CMakeLists.txt".

No matter what is the fix for this, `CMakeToolchain.variables` should declare normal variables and not CACHE ones. If someone wants CACHE variable there is `cache_variables` attribute so it makes sense to use that then.

### Logs

_No response_
user: hrco159753
issue_12990: state: open
title: [question] Config files from two different profiles with CMakeDeps and CMakeToolchain
body: ### What is your question?

I have been doing some testing with CMakeDeps and CMakeToolchain generators. My conanfile.py is the following:

```
from conan import ConanFile
from conan.tools.cmake import CMakeDeps, CMakeToolchain, cmake_layout


class HDF5Test(ConanFile):
    settings = "os", "arch", "compiler", "build_type"

    def requirements(self):
        self.requires("highfive/2.6.2")

    def generate(self):
        cmake = CMakeDeps(self)
        cmake.generate()

        toolchain = CMakeToolchain(self)
        toolchain.variables["CMAKE_MAP_IMPORTED_CONFIG_DEBUG"] = "Release"
        toolchain.generate()

    def layout(self):
        cmake_layout(self)

```

When I run `conan install . --build=missing`, it writes several files (FooConfig.cmake files and conan_toolchain.cmake) under build/generators.

However, if I have another profile and I rerun `conan install . --build=missing -pr=myprofile`, with some non default options, such as another compiler for example, it just overwrites the files in build/generators. 

How could I generate my toolchain and Config files under another folder? 

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jjcasmar
issue_12983: state: open
title: [question] How to have deploy(self) be called during normal Conan build?
body: ### What is your question?

Hi,
I have trouble understanding when/how the deploy() method in my conanfile.py is called.
According to the source code (manager.py/deps_install), deploy is called if:

        if not create_reference and isinstance(ref_or_path, ConanFileReference):
            # The conanfile loaded is a virtual one. The one w deploy is the first level one
            neighbours = deps_graph.root.neighbors()
            deploy_conanfile = neighbours[0].conanfile
            if hasattr(deploy_conanfile, "deploy") and callable(deploy_conanfile.deploy):
                run_deploy(deploy_conanfile, install_folder)

which means - by my understanding - that I can't do a "conan install [...] .", but I need to provide a full package
reference to conan install instead, e.g. "conan install foo/1.2.3@user/channel" so that deploy() would be executed.
I thought that the whole idea of deploy() is that it is executed a.) after install (so that it includes the package artifacts
as well, not just the dependency artifacts) b.) can be used with a path reference and not a package reference.

What do I miss? Isn't there a way to execute deploy() in the conanfile.py during normal build (e.g. conan build, 
conan package step, or something like that)
Thanks,

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: harsszegi
issue_12982: state: open
title: [feature] tools.build:compiler_executables environment variables
body: ### What is your suggestion?

Hi, with the current implementation of `tools.build:compiler_executables` there seems to be no general way of using environment variables. For example the following won't work for CMake:

```
[conf]
tools.build:compiler_executables={"c": "$CLANGCC", "cpp": "$CLANGCXX"}
```

What seems to work for CMake is the following but I am not sure if this will be true for other build system generators.

```
[conf]
tools.build:compiler_executables={"c": "$ENV{CLANGCC}", "cpp": "$ENV{CLANGCXX}"}
```

Is there another recommended way to use environment variables with the `tools.build:compiler_executables`?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: fjp
issue_12979: state: open
title: [question] Using conan.tools.microsoft.MSBuild
body: Conan Version: 1.57.0


Hi,

I'm converting my conanfile.py scripts to use the recommended Microsoft generators and MSBuild tools. Migrating the generators has been okay but I have noticed something when migrating the MSBuild over. I noticed that by default, the build doesn't utilize the parallel compilations offered by MSBuild. Looking at your src, I noticed you need a value in your conan.conf or profile settings for the `tools.microsoft.msbuild:max_cpu_count` to allow for the `/m` switch to be appended and enable the parallel build.

I didn't need to do this before so I was wondering if there is a way for the conan environment to detect the number of cpus and automatically fill the value for this?

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: KingKiller100
issue_12978: state: open
title: [bug] Conan fails to install package when using apple-clang 13
body: ### Environment details

* Operating System+version:
<img width="351" alt="image" src="https://user-images.githubusercontent.com/430175/214677504-b001f116-0939-45e5-89db-dceb0c6db4cd.png">* 
* Compiler+version:
```
$ gcc --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
```
* Conan version:
```
$ conan --version
Conan version 1.57.0
```
* Python version:
```
$ python3 --version
Python 3.10.8
```

### Steps to reproduce

1. have a mypkg with a recipe with `def compatibility(): ` defined as follows:
```
    def compatibility(self):
        """
        Determine which packages are compatible.

        We assume all compilers with the same or older version as compatible,
        with more recent versions being prefered
        """
        ver_consumer = Version(str(self.settings.compiler.version))

        # Get the versions declared in the settings.yml for this compiler type
        # Note reversed order when sorting so that more recent versions are preferred

        default_settings = Settings.loads(get_default_settings_yml())
        default_settings.compiler = self.settings.compiler
        known_compiler_versions = sorted(
            default_settings.compiler.version.values_range,
            key=lambda x: Version(x),
            reverse=True)

        return [
            {"settings": [("compiler.version", v)]}
            for v in known_compiler_versions if v <= ver_consumer]
```

2. run `conan install mypkg -s compiler.version=13` produces error

Running with `conan install mypkg -s compiler.version=13.0` does not produce the error.
Running with  `-s compiler.version=14` also do not have issues

Seems to be related to https://github.com/conan-io/conan/issues/11227 ?


### Logs

`conan install mypkg -s compiler.version=13`
Error log:
```
Traceback (most recent call last):
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/command.py", line 2216, in run
    method(args[0][1:])
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/command.py", line 547, in install
    info = self._conan.install_reference(ref,
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/conan_api.py", line 93, in wrapper
    return f(api, *args, **kwargs)
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/conan_api.py", line 558, in install_reference
    deps_install(self.app, ref_or_path=reference, install_folder=install_folder,
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/manager.py", line 58, in deps_install
    deps_graph = graph_manager.load_graph(ref_or_path, create_reference, graph_info, build_modes,
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/graph/graph_manager.py", line 128, in load_graph
    deps_graph = self._resolve_graph(root_node, profile_host, profile_build, graph_lock,
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/graph/graph_manager.py", line 290, in _resolve_graph
    deps_graph = self._load_graph(root_node, check_updates, update,
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/graph/graph_manager.py", line 411, in _load_graph
    self._recurse_build_requires(graph, builder, check_updates, update, build_mode,
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/graph/graph_manager.py", line 337, in _recurse_build_requires
    self._binary_analyzer.evaluate_graph(graph, build_mode, update, remotes, nodes_subset, root)
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/graph/graph_binaries.py", line 459, in evaluate_graph
    self._evaluate_node(node, build_mode, update, remotes)
  File "/private/tmp/.test_env/lib/python3.10/site-packages/conans/client/graph/graph_binaries.py", line 227, in _evaluate_node
    assert node.binary is not None
AssertionError
```
user: zouhairm
issue_12971: state: open
title: [bug] Race condition - parallel writing on deactive_conanbuildenv.sh with 2 parallel commands
body: ### Environment details

* Operating System+version: Ubuntu 18.04
* Conan version: 1.56.0
* Python version: 3.6


### Steps to reproduce

Let's assume, we have a recipe `tool-x` containing a `system_requirements()` which indeed check if a package is installed (in our case `usbutils`).
```python
    name="tool-x"

    def system_requirements(self):
        apt = Apt(self, arch_names={"<conan_arch_setting>": "apt_arch_setting"})
        apt.install(["usbutils"], check=True)
```

In our CI pipeline, we run the `conan test` and a `conan install` of the created package in parallel as we want to test different things. In the first case, the package, in the second the usability of the tools by our consumers as we are using the `deploy()`.
We were surprised that the pipeline fails sometimes. In fact, both calls sources the same `conanbuildenv.sh`! See logs.
It leads that one may overwrite partially the other `deactivate_conanbuildenv.sh` which leads to single quote parsing issue in the shell interpreter, see logs.

I propose following patch to make this behavior explicitly failing (neither retrying nor waiting is in my opinion a good idea):
```diff
--- environment.py	2023-01-11 10:18:40.797067056 +0100
+++ environment.py	2023-01-11 10:19:32.869589199 +0100
@@ -378,6 +378,12 @@
         filepath, filename = os.path.split(file_location)
         deactivate_file = os.path.join(filepath, "deactivate_{}".format(filename))
         deactivate = textwrap.dedent("""\
+           if [ -f {deactivate_file}.lock ]; then
+               echo "ERROR: Trying to write to a file which is locked [{deactivate_file}]"
+               exit 1
+           fi
+           touch {deactivate_file}.lock
+           ls -al {deactivate_file}.lock
            echo "echo Restoring environment" > "{deactivate_file}"
            for v in {vars}
            do
@@ -390,6 +396,7 @@
                    echo unset $v >> "{deactivate_file}"
                fi
            done
+           rm {deactivate_file}.lock
            """.format(deactivate_file=deactivate_file, vars=" ".join(self._values.keys())))
         capture = textwrap.dedent("""\
               {deactivate}
```

What do you think?

### Logs

Debugging setup
```
export CONAN_LOG_RUN_TO_OUTPUT =1
export CONAN_LOGGING_LEVEL=10
export CONAN_PRINT_RUN_COMMANDS=1
export CONAN_VERBOSE_TRACEBACK=1
```

Path setup
```
BUILD_DIR="${SCRIPT_DIR}/build/${PROFILE}"
TEST_BASE_DIR="${BUILD_DIR}-test"
TEST_DIR="${TEST_BASE_DIR}/conan"
DEPLOY_TEST_DIR="${TEST_BASE_DIR}/robot"
```

Parallel execution of following 2 commands and their relevant debugging output

```bash
conan test "${SCRIPT_DIR}/test/conan" "${COMPONENT_NAME}/${VERSION}@${REFERENCE}" \
--profile:build "linux-settings" \
--profile:host "${PROFILE}" \
--test-build-folder "${TEST_DIR}"

[2023-01-11T13:58:01.132Z] > . "/data/jenkins/workspace/tool-x_PR-13/build/linux-settings/conanbuild.sh" && dpkg-query -W -f='${Status}' usbutils | grep -q "ok installed"
```

```bash
conan install "${COMPONENT_NAME}/${VERSION}@${REFERENCE}" \
--generator VirtualRunEnv \
--install-folder "${DEPLOY_TEST_DIR}" \
--profile:host "${PROFILE}"

[2023-01-11T13:58:01.211Z] > . "/data/jenkins/workspace/tool-x_PR-13/build/linux-settings/conanbuild.sh" && dpkg-query -W -f='${Status}' usbutils | grep -q "ok installed"
```

Content of the `deactivate_conanbuildenv.sh`
```bash
echo Restoring environment
9xx/.conan/data/tools/0.19.0/user/stable/package/2d343e1b326e747f0a9e5f73ffa67a3ed62f2b2c/tools:'
export AAAAAAAAAAAA='/tmp/xxx9xx/.conan/data/tools-config/0.32.0/user/stable/package/7e808ba62e711d669863b5c5b26db60b51b690ca/src'
.....
```

Issue while running `deactivate_conanbuildenv.sh`
```bash
Restoring environment
/data/jenkins/workspace/COIN_tools-x_PR-13/build/linux-settings/deactivate_conanbuildenv.sh: line 11: unexpected EOF while looking for matching `''
```
user: Bearwolves
issue_12970: state: open
title: Add "application-with-library" as package_type
body: Changelog: (Feature): Add "application-with-library" as additional package_type (Closes #12969)
Docs: https://github.com/conan-io/docs/pull/XXXX

- [X] Refer to the issue that supports this Pull Request.
- [X] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [X] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [X] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 

<sup>**Note:** By default this PR will skip the slower tests and will use a limited set of python versions. Check [here](https://github.com/conan-io/conan/blob/develop/.github/PR_INCREASE_TESTING.md) how to increase the testing level by writing some tags in the current PR body text.</sup>

user: System-Arch
issue_12969: state: open
title: [feature] Conan 2.0 needs a package_type for applications with libraries
body: ### What is your suggestion?

Various applications such as GCC and Flex include headers and runtime libraries that are used by compiled or generated code. If one specifies the package_type as "application" for these package recipes, clients will not see their headers or libraries due to the following code in conans/model/requires.py:

>         if pkg_type is PackageType.APP:
>             # Change the default requires headers&libs to False for APPS
>             set_if_none("_headers", False)
>             set_if_none("_libs", False)
>             set_if_none("_run", True)

Thus Conan 2.0 would benefit from having an additional package_type "application-with-library" to support this use case. It could be implemented with the following one-line addition:

>     class PackageType(Enum):
>         LIBRARY = "library"  # abstract type, should contain shared option to define
>         STATIC = "static-library"
>         SHARED = "shared-library"
>         HEADER = "header-library"
>         BUILD_SCRIPTS = "build-scripts"
>         APP = "application"
>         APP_LIB = "application-with-library"    # Support applications with libraries (e.g., GCC, Flex, etc.)
>         PYTHON = "python-require"
>         UNKNOWN = "unknown"

I realize this is equivalent to not specifying any package_type but it is inconsistent to not be able to specify the package_type explicitly for every recipe. Doing so permits things like programmatically querying for all applications in a given code base, which becomes impossible when some of the applications are not labelled thusly. Thanks,

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: System-Arch
issue_12964: state: open
title: [question] MSBuild Helper looking in wrong folder for buildtools
body: I am trying to create a conan package using Visual Studio Build Tools 2022. My conan file is using the MSBuild helper.

I get the following output:
```
2023-01-24T12:03:16.5246613Z The system cannot find the path specified.
2023-01-24T12:03:16.5293803Z lcms/2.14@nitro/docker: 
2023-01-24T12:03:16.5298991Z lcms/2.14@nitro/docker: ERROR: Package '5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b' build failed
2023-01-24T12:03:16.5300580Z lcms/2.14@nitro/docker: WARN: Build folder C:\conan\.conan\data\lcms\2.14\nitro\docker\build\5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b
2023-01-24T12:03:16.5311122Z ERROR: lcms/2.14@nitro/docker: Error in build() method, line 129
2023-01-24T12:03:16.5311423Z 	self._build_visual_studio()
2023-01-24T12:03:16.5311837Z while calling '_build_visual_studio', line 109
2023-01-24T12:03:16.5312213Z 	msbuild.build("lcms2.sln", targets=[target], platforms={"x86": "Win32"},
2023-01-24T12:03:16.5313283Z 	ConanException: Error 1 while executing set "VSCMD_START_DIR=%CD%" && call "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC/Auxiliary/Build/vcvarsall.bat" amd64 && msbuild "lcms2.sln" /p:Configuration="Release" /p:UseEnv=true /p:Platform="x64" /m:16 /target:lcms2_static /p:PlatformToolset="v143" /verbosity:minimal /p:ForceImportBeforeCppTargets="C:\conan\.conan\data\lcms\2.14\nitro\docker\build\5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b\source_subfolder\Projects\VC2022\conan_build.props" /p:WholeProgramOptimization="false"
```
I don't think there is any x86 build tools for 2022 anymore:
https://devblogs.microsoft.com/dotnet/msbuild-and-64-bit-visual-studio-2022/

So, it seems that the MSBuild helper is looking in the wrong folder for the build tools?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: ckearney-nitro
issue_12963: state: open
title: [feature] Allow setting of vendor specific information for generated CMake presets
body: ### What is your suggestion?

Hello, and thanks for your great work on Conan!

We really like the automatic generation of CMake presets feature and want to make it a fixed part of our (future) workflow.

Here is our use-case: Many in our teams use Clion for their C/C++ development. Clion has ever improving support for presets and they use the 'vendor' section of the configure presets for the user to specify which 'Clion toolchain' he wants to use, this might look something like:
```
    {
      "name": "my_preset",
      "vendor": {
        "jetbrains.com/clion": {
          "toolchain": "my-docker-toolchain"
        }
      }
    }
```
We currently use this feature to configure/build/test/debug builds in Docker containers or WSL. The only issue is, that we cannot set this information in any way when generating the presets with Conan. We would have to patch the generated presets or create some new ones which are derived from the generated ones.

Perhaps Conan could provide a way to set this section for the generated configure/build/test presets? 


### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: WernerWessely
issue_12953: state: open
title: [feature] Support for virtual environments
body: ### What is your suggestion?

I work on a open source project (https://github.com/gnuradio/gnuradio) that uses a plugin model and I am trying to convince them to use conan for their package management.  People have written hundreds on these plugins which end up compiling to dynamically linked libraries.

There is a workflow that I would like to enable where the user finds a package, "installs" it, and immediately is able to use it along with any other "installed" packages.  This is presently difficult in `conan` because each install is independent.  If I do a `conan install --requires package1` and later do `conan install --requires package2` it produces two sets of conan(run/build).sh scripts.  The scripts will have the same names, so I can accidentally overwrite the previous script if I call install from the same folder twice.

I could have the user do a single install command - `conan install --requires package1 --requires package2`, but as the number of plugins installed grows, this becomes more and more difficult.

There is also the difficulty of managing the environment.  The presently defined deployers, install packages to unique folders per package.  So even though the vast majority of these packages only need to set a few common variables like `LD_LIBRARY_PATH`, we need to source a new environment after every install.

It would be really nice to have something that works more like a python venv, where we essentially create an alternate root directory and install everything in there.  I could set `LD_LIBRARY_PATH=<alt_root>/usr/lib` and any package that was installed would be immediately available.  I wouldn't have to worry about sourcing a new set of environment variables (unless the package had some non-standard ones, but you could write a check for that).

Another bonus to this approach is that it would make final deployment of an application really easy.  In a multistage docker build, we could install the conan packages to this virtual environment in the first stage (also installing the `system_requirements` to the alt root.  A second stage could just copy `--from builder <alt_root> /`.  The final docker image would not need to have conan or anything else installed, it would just contain the final application and its dependencies.

Is there an interest in this feature?  I have written a v2.0 `conan venv` command and a custom deployer that might be useful as a start.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jsallay
issue_12945: state: open
title: [feature] specify all compiler executables in tools.build:compiler_executables
body: ### What is your suggestion?

To avoid creating conan profile like this:



```
toolchain=/usr/i686-w64-mingw32 # Adjust this path
target_host=i686-w64-mingw32

[settings]

# We are cross-building to Windows
os=Windows
arch=x86
compiler=gcc

# Adjust to the gcc version of your MinGW package
compiler.libcxx=libstdc++11
compiler.version=12
build_type=Release

# required for Boost.Locale in versions >= 1.81
compiler.cppstd=11

[conf]
tools.cmake.cmaketoolchain:generator = Ninja
tools.build:compiler_executables = {"c": "i686-w64-mingw32-gcc", "cpp": "i686-w64-mingw32-g++"}
tools.build:cflags = ["-msse2"]
tools.build:cxxflags = ["-msse2"]

[env]
CONAN_CMAKE_FIND_ROOT_PATH=$toolchain
CHOST=$target_host
AR=$target_host-ar
AS=$target_host-as
RANLIB=$target_host-ranlib
STRIP=$target_host-strip
RC=$target_host-windres
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: rilian-la-te
issue_12940: state: open
title: [bug] poco, libmysqlclient undefined reference to zlib functions
body: ### Environment details

* Operating System+version: windows  WSL Ubuntu 22 
* Compiler+version: g++ 11
* Conan version:  1.57.0
* Python version: 3.11


### Steps to reproduce

[requires]

angelscript/2.36.0
argparse/2.9
args-parser/6.3.2
boost/1.81.0
cryptopp/8.7.0
eigen/3.4.0
fmt/9.1.0
glm/cci.20220420
gtest/cci.20210126
imgui/cci.20220621+1.88.docking
implot/0.14
lz4/1.9.4
magic_enum/0.8.2
nlohmann_json/3.11.2
numcpp/2.8.0
opengl/system
poco/1.12.4
range-v3/0.12.0
re2/20221201
sdl/2.26.1
sfml/2.5.1
spdlog/1.11.0
sqlite3/3.40.1
sqlitecpp/3.2.1
tabulate/1.4
zlib/1.2.13
openssl/3.0.7
libmysqlclient/8.0.31


[generators]
cmake
cmake_paths
cmake_find_package

### Logs

[ 73%] Linking CXX executable ../runtime_output_directory/thr_lock
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_expand_block':
c_zlib.c:(.text+0x49): undefined reference to `inflate'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_compress_block':
c_zlib.c:(.text+0xb2): undefined reference to `deflate'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_finish':
c_zlib.c:(.text+0xd9): undefined reference to `inflateEnd'
/usr/bin/ld: c_zlib.c:(.text+0xe2): undefined reference to `deflateEnd'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_init':
c_zlib.c:(.text+0x1c1): undefined reference to `inflateInit_'
/usr/bin/ld: c_zlib.c:(.text+0x22c): undefined reference to `deflateInit_'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_ctrl':
c_zlib.c:(.text+0x390): undefined reference to `deflate'
/usr/bin/ld: c_zlib.c:(.text+0x496): undefined reference to `zError'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_write':
c_zlib.c:(.text+0x738): undefined reference to `deflate'
/usr/bin/ld: c_zlib.c:(.text+0x7d6): undefined reference to `zError'
/usr/bin/ld: c_zlib.c:(.text+0x851): undefined reference to `deflateInit_'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_read':
c_zlib.c:(.text+0x98c): undefined reference to `inflate'
/usr/bin/ld: c_zlib.c:(.text+0xa26): undefined reference to `zError'
/usr/bin/ld: c_zlib.c:(.text+0xa83): undefined reference to `inflateInit_'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_free':
c_zlib.c:(.text+0xb2b): undefined reference to `inflateEnd'
/usr/bin/ld: c_zlib.c:(.text+0xb54): undefined reference to `deflateEnd'
[ 73%] Linking CXX executable ../runtime_output_directory/mf_iocache_test
collect2: error: ld returned 1 exit status
gmake[2]: *** [utilities/CMakeFiles/comp_client_err.dir/build.make:122: runtime_output_directory/comp_client_err] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:1520: utilities/CMakeFiles/comp_client_err.dir/all] Error 2
/usr/bin/ld: gmake[1]: *** Waiting for unfinished jobs....
/home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_expand_block':
c_zlib.c:(.text+0x49): undefined reference to `inflate'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_compress_block':
c_zlib.c:(.text+0xb2): undefined reference to `deflate'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_finish':
c_zlib.c:(.text+0xd9): undefined reference to `inflateEnd'
/usr/bin/ld: c_zlib.c:(.text+0xe2): undefined reference to `deflateEnd'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_init':
c_zlib.c:(.text+0x1c1): undefined reference to `inflateInit_'
/usr/bin/ld: c_zlib.c:(.text+0x22c): undefined reference to `deflateInit_'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_ctrl':
c_zlib.c:(.text+0x390): undefined reference to `deflate'
/usr/bin/ld: c_zlib.c:(.text+0x496): undefined reference to `zError'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_write':
c_zlib.c:(.text+0x738): undefined reference to `deflate'
/usr/bin/ld: c_zlib.c:(.text+0x7d6): undefined reference to `zError'
/usr/bin/ld: c_zlib.c:(.text+0x851): undefined reference to `deflateInit_'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_read':
c_zlib.c:(.text+0x98c): undefined reference to `inflate'
/usr/bin/ld: c_zlib.c:(.text+0xa26): undefined reference to `zError'
/usr/bin/ld: c_zlib.c:(.text+0xa83): undefined reference to `inflateInit_'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_free':
c_zlib.c:(.text+0xb2b): undefined reference to `inflateEnd'
/usr/bin/ld: c_zlib.c:(.text+0xb54): undefined reference to `deflateEnd'
collect2: error: ld returned 1 exit status
gmake[2]: *** [utilities/CMakeFiles/my_print_defaults.dir/build.make:106: runtime_output_directory/my_print_defaults] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:1653: utilities/CMakeFiles/my_print_defaults.dir/all] Error 2
[ 73%] Built target thr_lock
[ 73%] Built target mf_iocache_test
[ 73%] Linking CXX executable ../runtime_output_directory/comp_err
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_expand_block':
c_zlib.c:(.text+0x49): undefined reference to `inflate'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_compress_block':
c_zlib.c:(.text+0xb2): undefined reference to `deflate'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_finish':
c_zlib.c:(.text+0xd9): undefined reference to `inflateEnd'
/usr/bin/ld: c_zlib.c:(.text+0xe2): undefined reference to `deflateEnd'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `zlib_stateful_init':
c_zlib.c:(.text+0x1c1): undefined reference to `inflateInit_'
/usr/bin/ld: c_zlib.c:(.text+0x22c): undefined reference to `deflateInit_'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_ctrl':
c_zlib.c:(.text+0x390): undefined reference to `deflate'
/usr/bin/ld: c_zlib.c:(.text+0x496): undefined reference to `zError'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_write':
c_zlib.c:(.text+0x738): undefined reference to `deflate'
/usr/bin/ld: c_zlib.c:(.text+0x7d6): undefined reference to `zError'
/usr/bin/ld: c_zlib.c:(.text+0x851): undefined reference to `deflateInit_'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_read':
c_zlib.c:(.text+0x98c): undefined reference to `inflate'
/usr/bin/ld: c_zlib.c:(.text+0xa26): undefined reference to `zError'
/usr/bin/ld: c_zlib.c:(.text+0xa83): undefined reference to `inflateInit_'
/usr/bin/ld: /home/andriy/.conan/data/openssl/3.0.7/_/_/package/304480252b01879c8641f79a653b593b8f26cf9f/lib/libcrypto.a(libcrypto-lib-c_zlib.o): in function `bio_zlib_free':
c_zlib.c:(.text+0xb2b): undefined reference to `inflateEnd'
/usr/bin/ld: c_zlib.c:(.text+0xb54): undefined reference to `deflateEnd'
collect2: error: ld returned 1 exit status
gmake[2]: *** [utilities/CMakeFiles/comp_err.dir/build.make:106: runtime_output_directory/comp_err] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:1493: utilities/CMakeFiles/comp_err.dir/all] Error 2
gmake: *** [Makefile:156: all] Error 2
libmysqlclient/8.0.31:
libmysqlclient/8.0.31: ERROR: Package 'ee07977676c85caceddd59d7015f4782d0f76242' build failed
libmysqlclient/8.0.31: WARN: Build folder /home/andriy/.conan/data/libmysqlclient/8.0.31/_/_/build/ee07977676c85caceddd59d7015f4782d0f76242
ERROR: libmysqlclient/8.0.31: Error in build() method, line 242
        cmake.build()
        ConanException: Error 2 while executing cmake --build '/home/andriy/.conan/data/libmysqlclient/8.0.31/_/_/build/ee07977676c85caceddd59d7015f4782d0f76242' '--' '-j12'
user: andriy-byte
issue_12936: state: open
title: [bug] override fails when using --build missing
body: ### Environment details

* Operating System+version: Mac 10.15
* Compiler+version: apple-clang 14
* Conan version: 1.57.0
* Python version: 3.10.9


### Steps to reproduce

I have a recipe which requires a bunch of packages, most importantly grpc/1.47.0
grpc/1.47.0 requires openssl 1.1.1o, however in the conanfile.py this requirement is overrules with 1.1.1q (since that is the version used by other dependencies).

When running `conan info --build missing -pr:h mac-x86_64 -pr:b default --json conan-info.json .` conan errors out and does not produce an out file at all (why?).
Running `conan install -pr:h mac-x86_64 -pr:b default --json conan-install.json .` will happily list all the dependencies and then fail on missing binaries (which is expected). It warns about the override and only lists openssl/1.1.1q as expected.
Running `conan install -pr:h mac-x86_64 -pr:b default --json conan-install.json --build missing .` will print a warning about the override, then fail on the missing openssl/1.1.1o dependency which should not be required by anything.

### Logs

```
WARN: grpc/1.47.0: requirement openssl/1.1.1o overridden by your conanfile to openssl/1.1.1q 
WARN: spdlog/1.10.0: requirement fmt/8.1.1 overridden by your conanfile to fmt/8.0.1 
openssl/1.1.1o: Not found in local cache, looking in remotes...
ERROR: Failed requirement 'openssl/1.1.1o' from 'grpc/1.47.0'
ERROR: Unable to find 'openssl/1.1.1o' in remotes
```
user: Sil3ntStorm
issue_12929: state: open
title: [question] how to force tool_requires libffi/3.4.3 to use a user/channel
body: ### What is your question?

Conan 1.57.0

I have a custom automake and libffi, with user/channels
The standard recipes don't build, but the custom ones do.

I'm using two profiles (host, build), but the same profile for both.

When I build my project, I can't make conan use my custom libffi.

This is the key bit in my profile:
```
[tool_requires]
# libffi requires automake
automake/1.16.5@cci-bugfix/sysarch-1-2023-01-19
!automake*: libffi/3.4.3@cci-fix/automake-2023-01-19
```

No matter what I try and do, conan still insists on using libffi/3.4.3@_/_ ie the standard libffi.

It is happy to use my custom automake...

```
Build requirements
    autoconf/2.71 from 'myrepo' - Cache
    automake/1.16.5@cci-bugfix/sysarch-1-2023-01-19 from local cache - Cache
    bzip2/1.0.8 from 'myrepo' - Cache
    cmake/3.25.0 from 'myrepo' - Cache
    glib/2.75.0 from 'myrepo' - Cache
    libffi/3.4.3 from 'myrepo' - Cache
    libgettext/0.21 from 'myrepo' - Cache
... and more
```

What is the magic sauce I'm missing please?


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: paulharris
issue_12926: state: open
title: [feature] Add Cmake config and installation generation support
body: ### What is your suggestion?

Add support for generating native Cmake-config files and installation scripts. 

### Background

We maintain many private libraries for internal consumption, and we use Conan extensively for all of our projects.
One very annoying part of the whole process has been maintaining the CMake-native installation support, this mainly includes the config files and a `installation.cmake` script which contains EXPORT and INSTALL commands, which we source from the project root.

While we use Conan extensively, we wanted to keep the native CMake installation support available for easier public consumption if we decide to make these public. Not everyone uses Conan and since we use CMake as our build system we wanted to try and keep things up to date with the best packaging practices.

We recently decided to completely remove all the native CMake support from our internal libraries.

This is due to the fact that the custom config files are at odds with the incredible CMakeDeps generator config files. The native vs generated config files differ in general feature-completeness, and we have to basically expend a lot of effort just to keep the hand-crafted native config files up to date.

### Details

I thought that it would be incredibly useful for library writers that already maintain feature-complete Conan recipes to use these recipes as an underlying model to generate their Cmake native config files and also installation support. I believe that the Conan underlying model is rich enough to express most use cases. 

Basically, the library provider leans on the Conan support to generate the Cmake installation and config files that end-users can use. This helps with adoption since it prevents the library authors from having to expend effort for both Conan and native Cmake consumption. It would probably also solve compatibility issues with adding conan-center-index support, which purges the custom config files.

I would imagine that the config-file part of the feature wouldn't be very hard to implement, since this is inherently very similar to what the CmakeDeps generator does. The main difference being that the config file cannot be aware of transitive dependencies.
 
For this feature to be complete it would also have to provide custom INSTALL/EXPORT commands which the library provider could then include from the project root, this part should be harder to generate since I am not aware of anything remotely similar so far, but it should be mostly straightforward.

Any thoughts are welcome!

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: liarokapisv
issue_12924: state: open
title: [feature] Add support for specifying the bash path on Windows
body: ### What is your suggestion?

As a conan user,
I would like to be able to specify the bash path in my conan recipe for Windows,
so that I can build auto tools project in a specific recipe.

---

https://github.com/conan-io/conan/issues/12920 seems to claim that it is a conf. However, I do not want to touch a global conf. I want to make this change specifically for the recipe because this change only makes sense for that particular recipe, so it should be done where it belongs, not in an entirely different place.

### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: lpapp
issue_12922: state: open
title: [bug] unzip gets stuck and never returns
body: ### Environment details

* Operating System+version:
* Compiler+version:
* Conan version:
* Python version:


### Steps to reproduce

I have this in my recipe (source method):

```
from conan.tools.files import unzip

            cygwin_git = Git(self)
            cygwin_git.clone(url='git@gitlab.foo:cygwin.git')
            tarball_file = os.path.join(self.source_folder, 'Cygwin', 'cygwin64.tgz')
            unzip(self, tarball_file)
```

It seems that the extraction has actually happened, but the unzip process never returns.

This is happening on Windows 10 using the Visual Studio 2022 prompt. I am using conan 1.57.0.

### Logs

_No response_
user: lpapp
issue_12920: state: open
title: [bug] generate method not called for conan create
body: ### Environment details

* Operating System+version:
* Compiler+version:
* Conan version:
* Python version:


### Steps to reproduce

conan create -pr my_profile . 1.0.0@

on my recipe with a generate method in it, it does not eventually get called even tough it sets up important things, for example:

```
    def generate(self):                                                                                                   
        tc = AutotoolsToolchain(self)                                           
        tc.configure_args.append(f"configure_dir={self.source_folder}")         
        tc.make_args.append("-j1")                                              
        tc.generate()                                                           
        deps = AutotoolsDeps(self)                                              
        deps.generate()                                                         
        if self.settings.os == 'Windows':                                       
            self.conf["tools.microsoft.bash:subsystem"] = "cygwin"              
            self.conf["tools.microsoft.bash:path"] = os.path.join(self.source_folder, 'cygwin64', 'bin', 'bash.exe')
```

This is using conan 1.57.0

### Logs

_No response_
user: lpapp
issue_12919: state: open
title: [feature] add XCode version to settings.yaml
body: ### What is your suggestion?

Hi! 

I suggest adding xcode_version to settings.yml to be able fit concrete version of XCode required for the profile.

Currently only version of apple clang can be selected in conan settings, but there are situations when different XCode version have the same compiler:

Xcode 14.2
Apple clang version 14.0.0 (clang-1400.0.29.202)

Xcode 14.1
Apple clang version 14.0.0 (clang-1400.0.29.202)

Xcode 14.0.1
Apple clang version 14.0.0 (clang-1400.0.29.102)

Xcode 14.0
Apple clang version 14.0.0 (clang-1400.0.29.102)

The problem arises on CI build agent to select correct version of XCode before build.
There is no chance to deduce XCode version from clang version set in a profile.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: andreya108
issue_12914: state: open
title: wip: Make deactivate_conanx a function instead of an extra file
body: As a draft so I can share the idea around, and unfinished as of now.
This is something I already talked with @memsharded (That having a deactivate could be cool), but this does not do half what Python's virtualenv does to ensure correctness.

After a `source conanrun.sh`, now you'll get a `deactivate_conanrun` etc for each env. Note that this function does not get propagated to spawned childs of the shell in cases of VirtualRunEnv, this is in line with Python's virtualenv behaviour
For #10979
user: RubenRBS
issue_12903: state: open
title: [question] How does one set toolchain-specific profile configurations
body: ### What is your question?

I'm trying to set up generic build policies for things like reproducibility and portability. To this end, I'd like to set -ffile-prefix-map for Linux builds. I've used Jinja to create a Linux-specific profile, but when I try to follow the recommendation in https://blog.conan.io/2019/09/02/Deterministic-builds-with-C-C++.html by adding:

> tools.build:cflags=['-ffile-prefix-map=${CMAKE_SOURCE_DIR}=.' ]

it works correctly for CMake recipes but blows up for others (e.g., OpenSSL) that don't use CMake. It feels like Conan may need to support finer-grained configuration settings, i.e., something like:

> tools.cmake.build:cflags=['-ffile-prefix-map=${CMAKE_SOURCE_DIR}=.' ]

I'm also looking for an analogous way to implement this setting for autotools builds. As above, the challenge is having an appropriate way to specify the source directory in an abstract manner that can be passed as part of a build flag. Perhaps  something like this could be made to work:

> tools.build:cflags=[f'-ffile-prefix-map={conanfile.source_folder}=.' ]

Next, I would like to specify -Wl,-rpath=\\$ORIGIN as a linker option. While the following should theoretically work:

> tools.build:sharedlinkflags=['-Wl,-rpath=\\$ORIGIN']
> tools.build:exelinkflags=['-Wl,-rpath=\\$ORIGIN']

I don't see these statements having the desired effect in a CMake context, however, unlike the documentation (see conans/model/conf.py) that says these only affect CMake variables, they do seem to be picked up by autotools and other tool chains as well, which seems should be documented.

For CMake, I am guessing these flags should really be set via CMAKE_INSTALL_RPATH as discussed here [[https://docs.conan.io/en/latest/howtos/manage_shared_libraries/rpaths.html](https://docs.conan.io/en/latest/howtos/manage_shared_libraries/rpaths.html)], but it is not obvious (to me) how to set the value of this CMake variable in a profile. Thus it might be helpful if there was a CMake variable dictionary analogous to tools.microsoft.msbuildtoolchain:compile_options that would permit something like:

> tools.cmake:variables={ "CMAKE_INSTALL_RPATH": "-Wl,-rpath=\\$ORIGIN" }

Thanks for any insights or suggestions

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: System-Arch
issue_12897: state: open
title: [bug] Breaking change introduced relating to deprecated MsBuild  in 1.57.0
body: ### Environment details

* Operating System+version: Windows 10
* Compiler+version: v141_xp
* Conan version: 1.57.0
* Python version: builtin


### Steps to reproduce

```
from conans import ConanFile, MSBuild, tools
from conan.tools.microsoft import MSBuildToolchain
```

A project with the above structure fails to under 1.57.0. Works on 1.56.0.

### Logs

```
$ conan install -g deploy raptor/12.2.11@inseinc/stable --build=missing --profile=debug_141
Configuration:
[settings]
arch=x86
arch_build=x86_64
build_type=Debug
compiler=Visual Studio
compiler.runtime=MTd
compiler.toolset=v141_xp
compiler.version=15
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

raptor/12.2.11@inseinc/stable: Not found in local cache, looking in remotes...
raptor/12.2.11@inseinc/stable: Trying with 'inseinc'...
Downloading conanmanifest.txt completed [0.15k]
Downloading conanfile.py completed [6.82k]
Downloading conan_export.tgz completed [2.97k]
Decompressing conan_export.tgz completed [0.00k]
raptor/12.2.11@inseinc/stable: Downloaded recipe revision 603ddac7099f35393983cf3c894a6fd0
Installing package: raptor/12.2.11@inseinc/stable
Requirements
    boost/1.71.0@conan/stable from 'inseinc' - Cache
    bzip2/1.0.8@conan/stable from 'inseinc' - Cache
    cryptopp/5.6.5@inseinc/stable from 'inseinc' - Cache
    directx/9.0.0-2@inseinc/stable from 'inseinc' - Cache
    icu/58.3@inseinc/stable from 'inseinc' - Cache
    libb64/1.2.1-1@inseinc/stable from 'inseinc' - Cache
    mpir/2.7.0-2@inseinc/stable from 'inseinc' - Cache
    novolineage/1.1.37@inseinc/stable from 'inseinc' - Cache
    ogapi/2.24.1@inseinc/stable from 'inseinc' - Cache
    raptor/12.2.11@inseinc/stable from 'inseinc' - Downloaded
    tinyxml/2.6.2@inseinc/stable from 'inseinc' - Cache
    xvid/1.3.7@inseinc/stable from 'inseinc' - Cache
    zlib/1.2.11@conan/stable from 'inseinc' - Cache
Python requires
    version-calculator/1.0.1@inseinc/stable
Packages
    boost/1.71.0@conan/stable:d7ffa9e297e83b28e60a025c92fe4920da0910bd - Cache
    bzip2/1.0.8@conan/stable:86b2aac9fd4b7bb0f6eb25f1a636b1876d9e5d28 - Cache
    cryptopp/5.6.5@inseinc/stable:bfbe0a039702cfd8f54032276416635413b39052 - Cache
    directx/9.0.0-2@inseinc/stable:45b43bcd991ec89baf1eb618b595ca3227a3cf0b - Cache
    icu/58.3@inseinc/stable:4bb79ee642e42e148fb304236d2d4b4e901b55a6 - Cache
    libb64/1.2.1-1@inseinc/stable:bfbe0a039702cfd8f54032276416635413b39052 - Cache
    mpir/2.7.0-2@inseinc/stable:bfbe0a039702cfd8f54032276416635413b39052 - Cache
    novolineage/1.1.37@inseinc/stable:c1bee5dbaade32063b1c8a277ff3975af4993d4c - Cache
    ogapi/2.24.1@inseinc/stable:a010013fac2b1bfaff6ac23bbc89b20a065c65d7 - Cache
    raptor/12.2.11@inseinc/stable:86d70a3c64071db8d6b1189af14b259ad10cc7ba - Build
    tinyxml/2.6.2@inseinc/stable:bfbe0a039702cfd8f54032276416635413b39052 - Cache
    xvid/1.3.7@inseinc/stable:bfbe0a039702cfd8f54032276416635413b39052 - Cache
    zlib/1.2.11@conan/stable:fb466dfd43375561fcec289ed252bcf8185c4253 - Cache
Build requirements
    crc-calculator/1.0.1@inseinc/stable from 'inseinc' - Cache
    doctest/1.2.6@bincrafters/stable from 'inseinc' - Cache
Build requirements packages
    crc-calculator/1.0.1@inseinc/stable:11e6a84a7894f41df553e7c92534c3bf26896802 - Cache
    doctest/1.2.6@bincrafters/stable:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache

Cross-build from 'Windows:x86_64' to 'Windows:x86'
Installing (downloading, building) binaries...
bzip2/1.0.8@conan/stable: Already installed!
crc-calculator/1.0.1@inseinc/stable: Already installed!
cryptopp/5.6.5@inseinc/stable: Already installed!
directx/9.0.0-2@inseinc/stable: Already installed!
doctest/1.2.6@bincrafters/stable: Already installed!
icu/58.3@inseinc/stable: Already installed!
libb64/1.2.1-1@inseinc/stable: Already installed!
mpir/2.7.0-2@inseinc/stable: Already installed!
novolineage/1.1.37@inseinc/stable: Already installed!
ogapi/2.24.1@inseinc/stable: Already installed!
tinyxml/2.6.2@inseinc/stable: Already installed!
xvid/1.3.7@inseinc/stable: Already installed!
zlib/1.2.11@conan/stable: Already installed!
boost/1.71.0@conan/stable: Already installed!
boost/1.71.0@conan/stable: LIBRARIES: ['libboost_wave', 'libboost_container', 'libboost_contract', 'libboost_exception', 'libboost_graph', 'libboost_iostreams', 'libboost_locale', 'libboost_log', 'libboost_program_options', 'libboost_random', 'libboost_regex', 'libboost_serialization', 'libboost_wserialization', 'libboost_coroutine', 'libboost_fiber', 'libboost_context', 'libboost_timer', 'libboost_thread', 'libboost_chrono', 'libboost_date_time', 'libboost_atomic', 'libboost_filesystem', 'libboost_system', 'libboost_type_erasure', 'libboost_log_setup', 'libboost_math_c99', 'libboost_math_c99f', 'libboost_math_c99l', 'libboost_math_tr1', 'libboost_math_tr1f', 'libboost_math_tr1l', 'libboost_stacktrace_noop', 'libboost_stacktrace_windbg', 'libboost_stacktrace_windbg_cached', 'libboost_unit_test_framework']
boost/1.71.0@conan/stable: Package folder: D:\.conan\6ff637b\1
boost/1.71.0@conan/stable: Disabled magic autolinking (smart and magic decisions)
raptor/12.2.11@inseinc/stable: Applying build-requirement: crc-calculator/1.0.1@inseinc/stable
raptor/12.2.11@inseinc/stable: Applying build-requirement: doctest/1.2.6@bincrafters/stable
raptor/12.2.11@inseinc/stable: Configuring sources in D:\.conan\ccf20c\1
raptor/12.2.11@inseinc/stable: SCM: Getting sources from url: 'snip'
raptor/12.2.11@inseinc/stable: Copying sources to build folder
raptor/12.2.11@inseinc/stable: Building your package in D:\.conan\b09911\1
raptor/12.2.11@inseinc/stable: Generator visual_studio_multi created conanbuildinfo_multi.props
raptor/12.2.11@inseinc/stable: Generator visual_studio_multi created conanbuildinfo_debug_v141_win32_v141_xp.props
raptor/12.2.11@inseinc/stable: Calling generate()
raptor/12.2.11@inseinc/stable: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
raptor/12.2.11@inseinc/stable: MSBuildToolchain created conantoolchain_debug_v141_win32.props
raptor/12.2.11@inseinc/stable: MSBuildToolchain writing conantoolchain.props
raptor/12.2.11@inseinc/stable: Aggregating env generators
raptor/12.2.11@inseinc/stable imports(): Copied 1 '.exe' file: CrcCalculator.exe
raptor/12.2.11@inseinc/stable: Calling build()
raptor/12.2.11@inseinc/stable:
raptor/12.2.11@inseinc/stable: ERROR: Package '86d70a3c64071db8d6b1189af14b259ad10cc7ba' build failed
raptor/12.2.11@inseinc/stable: WARN: Build folder D:\.conan\b09911\1
ERROR: raptor/12.2.11@inseinc/stable: Error in build() method, line 104
        msbuild = MSBuild(self)
        ConanException: Using the wrong 'MSBuild' helper. To use MSBuildDeps, MSBuildToolchain you should use 'from conan.tools.microsoft import MSBuild'
```

The existing recipe in question uses the following import structure:

```
from conans import ConanFile, MSBuild, tools
from conan.tools.microsoft import MSBuildToolchain
```

It's been some time now, but if I recall correctly, the legacy MsBuild import was used as the new one uses a slightly different method that resulted in the compiler running out of heap memory. Retroactively releasing new recipe revisions would be a no go for us, due to regulatory issues it creates, and the number of them that exist.

The breaking change was introduced in 79100038f289553bbe09c9543a7080936ded4e27
user: AshleighAdams
issue_12891: state: open
title: [bug] Conan is unusable on white terminal theme (default for Gnome terminal, etc)
body: ### Environment details

* Operating System+version:
* Compiler+version:
* Conan version: 1.45
* Python version: 3.11


### Steps to reproduce

1. Run conan search boost/1.76@ or something similar.

![Screenshot 2023-01-11 at 16 44 51](https://user-images.githubusercontent.com/141957/212025686-db7eff48-d411-419c-aa38-903e2fa86d37.png)

See the yellow and grey characters.

I have been using this setup for years, but I have never encountered any issues with any other commands, not even a wide variety of vim syntax highlighting for various languages. I think those two colours should be adjusted for conan.

It is pretty much a blocker for usability.

### Logs

_No response_
user: lpapp
issue_12877: state: open
title: [bug] Unable to run executable under msys2 
body: ### Environment details

* Operating System+version: Windows 11 with msys2/mingw64 shell
* Conan version:1.56.0
* Python version:3.10.9


### Steps to reproduce

In a msys2/mingw64 shell, create a basic library using a template:
~~~~
> conan new dummy/1.3 --template=cmake_lib
> conan create .
...
dummy/1.3 (test package): Running test()
'.' is not recognized as an internal or external command,
operable program or batch file.
ERROR: dummy/1.3 (test package): Error in test() method, line 30
        self.run(cmd, env="conanrun")
        ConanException: Error 1 while executing ./example
~~~~

In my own code I only got the following working:
~~~~
    def test(self):
        if not cross_building(self):
            if self.settings.os == "Windows":
                self.run("example")
            else:
                self.run("./example")
~~~~

Some relevant environment variables:
~~~~
> env
SHELL=/usr/bin/bash
MINGW_PREFIX=/mingw64
MSYSTEM=MINGW64
OS=Windows_NT
_MSYS2_BASH=C:\msys64\usr\bin\bash.exe
_MSYS2_PREFIX=x86_64
MSYSTEM_CHOST=x86_64-w64-mingw32
MSYSTEM_PREFIX=/mingw64
~~~~

### Logs

_No response_
user: jputcu
issue_12872: state: open
title: let's create an issue to migrate it then.
body:         let's create an issue to migrate it then.
every old v1 `tools.*` should have a drop-in replacement in v2, or at very least, some clear migration path how to replace it.
let's avoid adding workarounds that don't scale to recipes.

_Originally posted by @SSE4 in https://github.com/conan-io/conan-center-index/pull/15121#discussion_r1064241394_
      
user: SSE4
issue_12865: state: open
title: [bug] `conan build` interface regression: `--configure`, `--build`, and `--test` do nothing
body: ### Environment details

* Operating System+version: Arch linux
* Compiler+version: Clang 14.0.6
* Conan version: 1.56.0
* Python version: 3.11.0


### Steps to reproduce

1. `conan new foo/0.1.0 --template=cmake_lib`
2. `conan install .`
3. `conan build --configure .`

This will run the `configure`, `build` and `test` phases of the `conan build` command, not just the `configure` stage (see logs below). This seems like a regression, since
```
$ conan build --help
usage: conan build [-h] [-b] [-bf BUILD_FOLDER] [-c] [-i] [-t] [-if INSTALL_FOLDER] [-pf PACKAGE_FOLDER] [-sf SOURCE_FOLDER] path

Calls your local conanfile.py 'build()' method.

The recipe will be built in the local directory specified by
--build-folder, reading the sources from --source-folder. If you are
using a build helper, like CMake(), the --package-folder will be
configured as the destination folder for the install step.

positional arguments:
  path                  Path to a folder containing a conanfile.py or to a recipe file e.g., my_folder/conanfile.py

options:
  -h, --help            show this help message and exit
  -b, --build           Execute the build step (variable should_build=True). When specified, configure/install/test won't run unless --configure/--install/--test specified
  -bf BUILD_FOLDER, --build-folder BUILD_FOLDER
                        Directory for the build process. Defaulted to the current directory. A relative path to the current directory can also be specified
  -c, --configure       Execute the configuration step (variable should_configure=True). When specified, build/install/test won't run unless --build/--install/--test specified
  -i, --install         Execute the install step (variable should_install=True). When specified, configure/build/test won't run unless --configure/--build/--test specified
  -t, --test            Execute the test step (variable should_test=True). When specified, configure/build/install won't run unless --configure/--build/--install specified
  -if INSTALL_FOLDER, --install-folder INSTALL_FOLDER
                        Directory containing the conaninfo.txt and conanbuildinfo.txt files (from previous 'conan install'). Defaulted to --build-folder
  -pf PACKAGE_FOLDER, --package-folder PACKAGE_FOLDER
                        Directory to install the package (when the build system or build() method does it). Defaulted to the '{build_folder}/package' folder. A relative path can be specified, relative to the current folder. Also an absolute path is allowed.
  -sf SOURCE_FOLDER, --source-folder SOURCE_FOLDER
                        Directory containing the sources. Defaulted to the conanfile's directory. A relative path to the current directory can also be specified
```
is pretty explicit about being able to specify `--configure`, `--build`, `--test` or `--install`.

I've also realised that `conan build` is suspiciously absent from https://docs.conan.io/en/2.0/reference/commands.html - is this being removed in conan 2.0? I really hope not - this is our preferred workflow to invoke cmake, and these selectors are really quite useful in separating out the stages of a build for debugging purposes.

### Logs

```
$ conan new foo/0.1.0 --template=cmake_lib
File saved: CMakeLists.txt
File saved: conanfile.py
File saved: include/foo.h
File saved: src/foo.cpp
File saved: test_package/CMakeLists.txt
File saved: test_package/conanfile.py
File saved: test_package/src/example.cpp
$ conan install .
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=clang
compiler.libcxx=libstdc++11
compiler.version=14
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
CC=/usr/bin/clang
CXX=/usr/bin/clang++
[conf]
tools.build:skip_test=False

conanfile.py (foo/0.1.0): Installing package
Requirements
Packages

Installing (downloading, building) binaries...
conanfile.py (foo/0.1.0): Generator txt created conanbuildinfo.txt
conanfile.py (foo/0.1.0): Calling generate()
conanfile.py (foo/0.1.0): WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
conanfile.py (foo/0.1.0): Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
conanfile.py (foo/0.1.0): If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/home/user/projects/irc/conan-build-example/build/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
conanfile.py (foo/0.1.0): Aggregating env generators
conanfile.py (foo/0.1.0): Generated conaninfo.txt
conanfile.py (foo/0.1.0): Generated graphinfo
$ conan build --configure .
Using lockfile: '/home/user/projects/irc/conan-build-example/conan.lock'
Using cached profile from lockfile
[HOOK - conan-center.py] pre_build(): [FPIC MANAGEMENT (KB-H007)] OK. 'fPIC' option found and apparently well managed
[HOOK - conan-center.py] pre_build(): [FPIC MANAGEMENT (KB-H007)] OK
conanfile.py (foo/0.1.0): Calling build()
conanfile.py (foo/0.1.0): CMake command: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/user/projects/irc/conan-build-example/build/generators/conan_toolchain.cmake" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/user/projects/irc/conan-build-example/."
-- Using Conan toolchain: /home/user/projects/irc/conan-build-example/build/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The CXX compiler identification is Clang 14.0.6
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_POLICY_DEFAULT_CMP0091


-- Build files have been written to: /home/user/projects/irc/conan-build-example/build/Release
conanfile.py (foo/0.1.0): CMake command: cmake --build "/home/user/projects/irc/conan-build-example/build/Release" '--' '-j24'
[ 50%] Building CXX object CMakeFiles/foo.dir/src/foo.cpp.o
[100%] Linking CXX static library libfoo.a
[100%] Built target foo
```
user: samuel-emrys
issue_12860: state: open
title: [question] How to access conf variables for the build context in the generate method?
body: ### What is your question?

The [conf attribute](https://docs.conan.io/en/latest/reference/conanfile/attributes.html#conf) may contain settings for the build context which recipes need, such as `compiler_executables`. The `libcap` recipe uses `BUILD_CC` environment variable, see [here](https://github.com/conan-io/conan-center-index/blob/master/recipes/libcap/all/conanfile.py#L66-L69), to configure the C compiler to use in the build context. I don't see a way to access `compiler_executables` for the build context to properly set this environment variable in the `generate` method.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: jwillikers
issue_12859: state: open
title: [feature] Function to remove absolute paths in `RUNPATH`/`RPATH`/`LC_RPATH` of shared libs/executables
body: ### What is your suggestion?

On macOS, thanks to https://github.com/conan-io/conan/pull/11114 `AutotoolsDeps` injects to `LDFLAGS` `-Wl,-rpath -Wl,<libdir>` for each libdir of dependencies. It's required for configuration step of autotools on macOS because conftest executables are linked to all libs listed in `LIBS` populated by `AutotoolsDeps`, so without this trick on macOS it would fail due to SIP when there are shared libs in dependencies (even when `VirtualRunEnv` is injected in build scope, since SIP seems to be triggered somewhere during autotools configuration unfortunately).
But there is a side effect in resulting binaries: it pollutes `LC_RPATH` of shared libs and executables of the package with build machine absolute paths of these external dependencies. It doesn't break anything (maybe just slow down a little bit runtime loader), but it makes no sense for relocatable binaries.

A function similar to `fix_apple_shared_install_name()` would be very convenient to remove these absolute paths in `LC_RPATH` afterwards in `package()` method. It should not remove relative paths (or it could be opt-in), because it may be convenient for few packages to have relative paths of their own shared libs in `LC_RPATH`. Moreover this function doesn't have to be limited to macOS, it could be extended to all *nix patforms.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: SpaceIm
issue_12858: state: open
title: [bug] CMake generator specifies wrong CONAN_LINK_RUNTIME
body: ### Environment details

* Operating System+version: Windows
* Compiler+version: msvc 19.28
* Conan version: 1.56


### Steps to reproduce

What is the correct way of using the compiler.runtime option  with `msvc`  and the CMake helper?

I can see that the `compiler.runtime` option is used verbatim as a compiler switch,  and `/dynamic` is not a msvc option.

build profile:
```
[settings]
os=Windows
arch=x86_64
compiler=msvc
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=192
compiler.cppstd=14
build_type=Release

[build_requires]
cmake/3.24.2
ninja/1.11.1

[env]
CMAKE_GENERATOR=Ninja
CMAKE_BUILD_TYPE=Release
```

build recipe:
```
    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
        cmake.install()
```

in `conans/client/build/cmake_flags.py`, we can see that runtime is used verbatim.
```
def runtime_definition(runtime):
    return {runtime_definition_var_name: "/%s" % runtime} if runtime else {}
```

In the resulting generated build files:

CMakeCache.txt:
```
//No help, variable specified on the command line.
CONAN_LINK_RUNTIME:UNINITIALIZED=/dynamic
```

build.ninja
```
build foo.obj: CXX_COMPILER__foo_Release C$:\Users\nschultz\.conan\data\foo\2.21.1\_\_\build\aa0b2eec1220ffba6f90dea50c53c31cc623ec42\foo.cpp || cmake_object_order_depends_target_foolib
  DEFINES = ...
  FLAGS = /DWIN32 /D_WINDOWS /W3 /GR /EHsc   /dynamic /O2 /Ob2 /DNDEBUG  -D_NOEXCEPT=noexcept -std:c++14
```

During the build,  I get the warning:
```
cl : Command line warning D9002 : ignoring unknown option '/dynamic'
```

## Workarounds


If I add `MD` to my `settings.yml` under `compiler/msvc/runtime`, and update my profile to use it,  then it works.

Alternatively, in my recipe, I can override the cmake definition:
```
    def __fixup_cmake_runtime(self, cmake):
        from conans.client.build.cmake_flags import runtime_definition_var_name 
        msvc_runtimes = {
            "dynamic:Debug": "/MDd",
            "dynamic:Release": "/MD",
            "static:Debug": "/MTd",
            "static:Release": "/MT"        
        }

        if self.settings.compiler == "msvc":
            cmake.definitions[runtime_definition_var_name] = msvc_runtimes[f"{self.settings.compiler.runtime}:{self.settings.compiler.runtime_type}"]
        

    def build(self):
        cmake = CMake(self)
        self.__fixup_cmake_runtime(cmake)
        cmake.configure()
        cmake.build()
        cmake.install()
```

However, this won't fix my build profile with other recipes.



### Logs

_No response_
user: nick-schultz
issue_12856: state: open
title: [question] Extending MSBuildDeps?
body: ### What is your question?

I'm trying to migrate from the `visual_studio_multi` generator to `MSBuildDeps` in order to take advantage of per-dependency `.props` files. We are currently running a modified version of `visual_studio_multi` that gets distributed as a Conan package. (There are several modifications, but the biggest is that we have a ton of different "Debug" and "Release" variants, so I need to do a `Contains` on the `Configuration` instead of a straight comparison.)

I've tried to follow a similar pattern to modify `MSBuildDeps`, but I get the below error during `conan install`, presumably because `MSBuildDeps` does not inherit from `Generator`. According to https://docs.conan.io/en/latest/howtos/custom_generators.html, custom generators are a deprecated feature but it's not clear to me what the alternative is. Is there another way I can register my class with Conan?

```
Traceback (most recent call last):
  File "C:\devel\checkout\core-conan\.venv\lib\site-packages\conans\client\generators\__init__.py", line 195, in write_generators
    generator_class = self._generators[generator_name]
KeyError: 'MSBuildDeps_Modified'
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: illusionistpm
issue_12852: state: open
title: [question] Introduce newer versions of conan in a tested environemnt and deploy
body: ### What is your question?

Dear Conan folks,

I would like to know if there is any other way to introduce newer conan versions, recipe changes across component, projects.
At the moment, I am experimenting with cruft I can have a bootstrap repository where I have a requirements.txt containing the conan versions or any other python packages that I am using with my python scripts. Also the bootstarp repository contains a basic layout of a package repository with CMakeLists.txt, conanfile.py , Jenkinsfile and a build.py.
However,  I am looking if there are any other options to handle it. Because the combination of variants and platform in a component is ever growing.

Thanks for your reply.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: maitrey
issue_12850: state: open
title: [question] "ERROR: Loop detected in context build" for tool requirement
body: ### What is your question?

I'm adding a tool requirement for GCC 12 in my build profile, but I'm getting a loop error, and I haven't been able to find a solution.
```
> conan install --build=missing -pr:b=build_profile -pr:h=host_profile -s build_type=Debug .
Configuration (profile_host):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=23
compiler.libcxx=c++_static
compiler.version=15
os=Linux
os_build=Linux
[options]
[build_requires]
*: ninja/1.11.1
[env]
[conf]
tools.build:cxxflags=['-march=ivybridge -mtune=ivybridge']
tools.build:ldflags=['-march=ivybridge -mtune=ivybridge']

Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=12
os=Linux
os_build=Linux
[options]
[build_requires]
*: gcc/12.2.0
[env]

Setting up in a local environment
WARN: mpfr/4.1.0: requirement gmp/6.2.1 overridden by mpc/1.2.0 to gmp/6.2.0
ERROR: Loop detected in context build: 'gcc/12.2.0' requires 'zlib/1.2.11' which is an ancestor too
```
How can I fix this error? Adding zlib as an explicit tool requirement in the profile does not seem to make a difference.

My build profile
```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=12
compiler.libcxx=libstdc++11
build_type=Release

[options]

[tool_requires]
gcc/12.2.0
```
My host profile
```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=clang
compiler.version=15
compiler.libcxx=c++_static
compiler.cppstd=23

[options]

[tool_requires]
ninja/1.11.1

[buildenv]

[conf]
tools.build:cxxflags=["-march=ivybridge -mtune=ivybridge"]
tools.build:ldflags=["-march=ivybridge -mtune=ivybridge"]
```
Conan version: 1.55

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: buevl
issue_12842: state: open
title: [feature] Add option to clean the cache before update via `config_install_interval`
body: ### What is your suggestion?

Hi,

I really like the possibility to update the Conan configuration periodically via the `config_install_interval` variable. However, this doesn't fit our needs to 100%. It would be great if the automatic update functionality could be enhanced to clean the cache (not the package data, but the profiles and hooks) before the configurations are updated. E.g. via a `config_install_clean` variable in the `conan.conf` file. Unfortunately this isn't that easy:
- What shall happen if the configuration is not reachable (e.g. no internet access, folder has been removed, etc.)? Is the cache cleaned but the configuration not applied then?
- Which kind of data shall be cleaned (profiles, hooks, etc.) and which kind of information shall be kept (data folder, ...)?

Another solution would be to provide a hook for that purpose, so a project specific clean up is possible:

```
from conans import tools

def pre_update_config(cache_dir, configs, **kwargs):
    # Project specific clean up of the cache (config provides access to config_install.json structure)
    pass

def post_update_config(cache_dir, valid_configs, invalid_configs, **kwargs):
    # Project specific stuff (valid_configs points to all configs in config_install.json that have been updated properly)
    # Does this make sense if the file has been replaced during the update?
    pass
```

What do you think?

Best regards,
Markus

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: gpxricky
issue_12837: state: open
title: [question] Why is CMakDeps not generating INTERFACE_LINK_DIRECTORIES by default?
body: ### Use case:

We are creating an `SDK` package containing multiple libraries like Operating System based packages or even CUDA, but we don't want to specify all libraries present there in the `cpp_info.libs` to avoid exploding our linker command with a lot of useless information. We also would prefer to have the linker command as expressive as possible. Hence, we would like to specify all library manually on the consumer side CMakeLists.txt. The consumer packages would need to access "INTERFACE_LINK_DIRECTORIES" configuration which should be generated by the CMakeDeps generator.

### Question

Why is the CMake property "INTERFACE_LINK_DIRECTORIES" generation disabled by default? Especially, why not being able to enable it via property also for Linux or any other UNIX System? If I delete locally the if check related to windows, it works like a charm., at least how I would like that it works :D
I tried it on the example which I mentioned here which was not working => https://github.com/conan-io/conan/issues/12564 . I will closed it as the reasoning is understood based on the question in this ticket.

I had a look at the comment in the code but it isn't enough for me to understand the reasoning.
`# This is only used for '#pragma comment(lib, "foo")' (automatic link)`

Conan's code
https://github.com/conan-io/conan/blob/develop/conan/tools/cmake/cmakedeps/templates/target_configuration.py#L30
https://github.com/conan-io/conan/blob/develop/conan/tools/cmake/cmakedeps/templates/target_configuration.py#L38
https://github.com/conan-io/conan/blob/develop/conan/tools/cmake/cmakedeps/templates/target_configuration.py#L114-L120


### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: Bearwolves
issue_12835: state: open
title: [question] `conan install --update` doesn't seem to get the latest revision.
body: Is there some additional command line or setting so that when `conan install --update` is issued, the latest revision is downloaded to local cache?

This is for 1.55. 

Also, just in case it is relevant. The revision mode is set to scm (i.e. ` revision_mode = "scm"`)

For example: 
To check the local cache revision I do:
`conan search <package> -rev` 
returns
```
Revisions for '<package>':
769be40fc79547aa1b091c78e93119eec0989b86 (2022-12-28 08:23:46 UTC)
```

Now for the server:
`conan search --remote <remote> <package> -rev`
I get:
```
Revisions for '<package>' at remote '<remote>':
0f9c76286017bfb9b6aa501f9f2bcb200a642d65 (2022-12-30 08:23:49 UTC)
7e48aef42961db4bee17df89497d4d1fd21d1609 (2022-12-29 08:23:49 UTC)
769be40fc79547aa1b091c78e93119eec0989b86 (2022-12-28 08:23:46 UTC)
c8b21d643f787f7daa9122e6e5bd1bbe7dec6327 (2022-12-27 08:24:07 UTC)
32c51fe76be4ac5042214ebd4e6a4f9b9778b3bf (2022-12-21 08:24:10 UTC)
fd5c68be4b01e5665c9e027686bb63f5feec76b7 (2022-12-20 08:24:05 UTC)
548bc9859a932706432976d892aa42a58c6bff94 (2022-12-19 08:23:35 UTC)
aa1062dcb63b8f54eba930804f203a9faaaadbbf (2022-12-16 08:23:53 UTC)
0 (2022-12-15 17:09:36 UTC)
12cd3785c90cd3c01f9683a5ec89b5b6cf7346cd (2022-12-15 02:51:23 UTC)
bef7c45a252279b9aa1929bfe1e006eb8ad9efa8 (2022-12-12 08:24:06 UTC)
```

with `conan install --update` I was expecting the latest revision (i.e. `0f9c762...`) to be downloaded to local cache.


user: birsoyo
issue_12826: state: open
title: [bug] PATH inconsistent in test package method between one and two profiles
body: ### Environment details

* Conan version: 1.56.0

I am trying to migrate to two profiles, and facing problems with our test packages in the process. Paths set with `self.env_info.PATH` are not set in the `test()` method of the test package any more.

`conanfile.py`
```
from conans import ConanFile
import os

class TestConan(ConanFile):
    name = "testtest"
    version = "latest"

    def package_info(self):
        self.env_info.PATH.append(os.path.join(self.package_folder, "test", "bin"))
```

`test_package/conanfile.py` 
```
from conans import ConanFile
import os

class TestTestConan(ConanFile):
    def test(self):
        print(os.environ['PATH'])
```



### Steps to reproduce

Create a new Conan package with the given test package, and call `conan create` just with a single profile, then repeat the process with two profiles.

### Logs

```
conan create conanfile.py -pr=default
...
testtest/latest (test package): Running test()
D:\Conan\Cache2profiles\testtest\latest\_\_\package\4068d26db0f235082dbcdd6f303d1cbf4d149cf1\test\bin;C:\Program Files\Eclipse Foundation\jdk-8.0.302.8-hotspot\bin;...
```
While with two profiles, it is not part of the printed PATH.
```
conan create conanfile.py -pr:b=default -pr:h=default
...
testtest/latest (test package): Running test()
C:\Program Files\Eclipse Foundation\jdk-8.0.302.8-hotspot\bin;...
```
user: KerstinKeller
issue_12820: state: open
title: [bug] cmake_generator configuration is not respected
body: ### Environment details

* Operating System+version: Microsoft Windows 10 Pro 10.0.19045 Build 19045
* Compiler+version: clang 15
* Conan version: 1.56.0
* Python version: 3.8.6


### Steps to reproduce

1. Set `cmake_generator`
```
conan config set general.cmake_generator=Ninja
```
2. Run
```
conan workspace install /path/to/conan-workspace.yml --build=missing --profile "/path/to/conan-clang-profile"
```
For the bzip2/1.0.8 package, which is a dependency, I get the error
```
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
```

I was expecting that everything will be build with `Ninja` as a CMake generator instead of `MinGW Makefiles`.

In `C:\Users\sogartary\.conan\data\bzip2\1.0.8\_\_\build\664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b\build\generators\CMakePresets.json` the wrong generator is specified.


### Logs

```
conan workspace install ../conan-workspace.yml --build=missing --profile ../conan-clang-debug-profile
```

```
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=clang
compiler.cppstd=20
compiler.version=15
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
CONAN_CMAKE_GENERATOR=Ninja
boost/1.81.0: Not found in local cache, looking in remotes...
boost/1.81.0: Trying with 'conancenter'...
Downloading conanmanifest.txt completed [0.35k]
Downloading conanfile.py completed [79.68k]
Downloading conan_export.tgz completed [1.37k]
Decompressing conan_export.tgz completed [0.00k]
boost/1.81.0: Downloaded recipe revision 0
zlib/1.2.13: Not found in local cache, looking in remotes...
zlib/1.2.13: Trying with 'conancenter'...
Downloading conanmanifest.txt completed [0.28k]
Downloading conanfile.py completed [4.04k]
Downloading conan_export.tgz completed [0.29k]
Decompressing conan_export.tgz completed [0.00k]
zlib/1.2.13: Downloaded recipe revision 0
bzip2/1.0.8: Not found in local cache, looking in remotes...
bzip2/1.0.8: Trying with 'conancenter'...
Downloading conanmanifest.txt completed [0.17k]
Downloading conanfile.py completed [4.26k]
Downloading conan_export.tgz completed [0.24k]
Decompressing conan_export.tgz completed [0.00k]
bzip2/1.0.8: Downloaded recipe revision 0
eigen/3.4.0: Not found in local cache, looking in remotes...
eigen/3.4.0: Trying with 'conancenter'...
Downloading conanmanifest.txt completed [0.10k]
Downloading conanfile.py completed [3.20k]
Downloading conan_export.tgz completed [0.25k]
Decompressing conan_export.tgz completed [0.00k]
eigen/3.4.0: Downloaded recipe revision 0
nlohmann_json/3.11.2: Not found in local cache, looking in remotes...
nlohmann_json/3.11.2: Trying with 'conancenter'...
Downloading conanmanifest.txt completed [0.10k]
Downloading conanfile.py completed [1.64k]
Downloading conan_export.tgz completed [0.24k]
Decompressing conan_export.tgz completed [0.00k]
nlohmann_json/3.11.2: Downloaded recipe revision 0
polymorphic_value/1.3.0: Not found in local cache, looking in remotes...
polymorphic_value/1.3.0: Trying with 'conancenter'...
Downloading conanmanifest.txt completed [0.10k]
Downloading conanfile.py completed [2.73k]
Downloading conan_export.tgz completed [0.26k]
Decompressing conan_export.tgz completed [0.00k]
polymorphic_value/1.3.0: Downloaded recipe revision 0
b2/4.9.2: Not found in local cache, looking in remotes...
b2/4.9.2: Trying with 'conancenter'...
Downloading conanmanifest.txt completed [0.10k]
Downloading conanfile.py completed [6.99k]
Downloading conan_export.tgz completed [0.24k]
Decompressing conan_export.tgz completed [0.00k]
b2/4.9.2: Downloaded recipe revision 0
Requirements
    boost/1.81.0 from 'conancenter' - Downloaded
    bzip2/1.0.8 from 'conancenter' - Downloaded
    eigen/3.4.0 from 'conancenter' - Downloaded
    nlohmann_json/3.11.2 from 'conancenter' - Downloaded
    polymorphic_value/1.3.0 from 'conancenter' - Downloaded
    zlib/1.2.13 from 'conancenter' - Downloaded
    modscheme_lib/0.1 from user folder - Editable
    modscheme_server/0.1 from user folder - Editable
Packages
    boost/1.81.0:62c93f29b9f76c328a46007549cc459447eeb77b - Build
    bzip2/1.0.8:664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b - Build
    eigen/3.4.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    nlohmann_json/3.11.2:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    polymorphic_value/1.3.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    zlib/1.2.13:01822c8126f3805e61534fa72215516497c36eb2 - Build
    modscheme_lib/0.1:27e502d47a8725d19299a32b559b4f6dd00ec394 - Editable
    modscheme_server/0.1:1a022cf2f8fb5768319a46ddef85fc367f8c90bd - Editable
Build requirements
    b2/4.9.2 from 'conancenter' - Downloaded
Build requirements packages
    b2/4.9.2:ca33edce272a279b24f87dc0d4cf5bbdcffbc187 - Download

Installing (downloading, building) binaries...
b2/4.9.2: Retrieving package ca33edce272a279b24f87dc0d4cf5bbdcffbc187 from remote 'conancenter'
Downloading conanmanifest.txt completed [14.27k]
Downloading conaninfo.txt completed [0.24k]
Downloading conan_package.tgz completed [505.57k]
Decompressing conan_package.tgz completed [0.00k]
b2/4.9.2: Package installed ca33edce272a279b24f87dc0d4cf5bbdcffbc187
b2/4.9.2: Downloaded package revision 0
eigen/3.4.0: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter'
Downloading conanmanifest.txt completed [47.09k]
Downloading conaninfo.txt completed [0.29k]
Downloading conan_package.tgz completed [1433.41k]
Decompressing conan_package.tgz completed [0.00k]
eigen/3.4.0: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
eigen/3.4.0: Downloaded package revision 0
nlohmann_json/3.11.2: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter'
Downloading conanmanifest.txt completed [3.73k]
Downloading conaninfo.txt completed [0.27k]
Downloading conan_package.tgz completed [148.87k]
Decompressing conan_package.tgz completed [0.00k]
nlohmann_json/3.11.2: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
nlohmann_json/3.11.2: Downloaded package revision 0
polymorphic_value/1.3.0: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter'
Downloading conanmanifest.txt completed [0.24k]
Downloading conaninfo.txt completed [0.27k]
Downloading conan_package.tgz completed [2.76k]
Decompressing conan_package.tgz completed [0.00k]
polymorphic_value/1.3.0: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
polymorphic_value/1.3.0: Downloaded package revision 0
Downloading conan_sources.tgz completed [0.59k]
Decompressing conan_sources.tgz completed [0.00k]
bzip2/1.0.8: Configuring sources in C:\Users\sogartary\.conan\data\bzip2\1.0.8\_\_\source\src
Downloading bzip2-1.0.8.tar.gz completed [791.04k]                                       bzip2/1.0.8: 0.8:
bzip2/1.0.8:
bzip2/1.0.8: Copying sources to build folder
bzip2/1.0.8: Building your package in C:\Users\sogartary\.conan\data\bzip2\1.0.8\_\_\build\664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b
bzip2/1.0.8: Generator txt created conanbuildinfo.txt
bzip2/1.0.8: Calling generate()
bzip2/1.0.8: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
bzip2/1.0.8: Preset 'debug' added to CMakePresets.json. Invoke it manually using 'cmake --preset debug'
bzip2/1.0.8: If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE=C:\Users\sogartary\.conan\data\bzip2\1.0.8\_\_\build\664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b\build\generators\conan_toolchain.cmake -DCMAKE_SH=CMAKE_SH-NOTFOUND -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Debug'
bzip2/1.0.8: Aggregating env generators
bzip2/1.0.8: Calling build()
bzip2/1.0.8: apply_conandata_patches(): No patches defined in conandata
bzip2/1.0.8: CMake command: cmake -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE="C:/Users/sogartary/.conan/data/bzip2/1.0.8/_/_/build/664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/sogartary/.conan/data/bzip2/1.0.8/_/_/package/664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b" -DCMAKE_SH="CMAKE_SH-NOTFOUND" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Debug" "C:\Users\sogartary\.conan\data\bzip2\1.0.8\_\_\build\664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b\src\.."
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
bzip2/1.0.8:
bzip2/1.0.8: ERROR: Package '664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b' build failed
bzip2/1.0.8: WARN: Build folder C:\Users\sogartary\.conan\data\bzip2\1.0.8\_\_\build\664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b\build\Debug
ERROR: bzip2/1.0.8: Error in build() method, line 72
        cmake.configure(build_script_folder=os.path.join(self.source_folder, os.pardir))
        ConanException: Error 1 while executing cmake -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE="C:/Users/sogartary/.conan/data/bzip2/1.0.8/_/_/build/664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/sogartary/.conan/data/bzip2/1.0.8/_/_/package/664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b" -DCMAKE_SH="CMAKE_SH-NOTFOUND" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Debug" "C:\Users\sogartary\.conan\data\bzip2\1.0.8\_\_\build\664a290ff8a4232d40ea8d66ae4e20ff2cb6ef7b\src\.."
```
user: sogartar
issue_12818: state: open
title: [bug] Error	LNK1104	cannot open file 'CONAN_LIB::libpng_libpng16d_DEBUG.lib'
body: ### Environment details

* Operating System+version: Windows11
* Compiler+version: VC++2022
* Conan version: 1.50.0 & 1.56.0
* Python version: 3.9.13

Profile:

```
[settings]
arch=x86_64
build_type=Debug
compiler=Visual Studio
compiler.runtime=MDd
compiler.version=17
os=Windows
os_build=Windows
arch_build=x86_64
[options]
[conf]
[build_requires]
[env]
```

conanfile.py:

```
from conans import ConanFile
import os

class MyConan(ConanFile):
	settings = "os", "compiler", "build_type", "arch"

	requires = (
		"openssl/1.1.1d",
		"boost/1.76.0",
		"di/1.2.0",
		"cpprestsdk/2.10.18",
		"soci/4.0.2",
		"sqlcipher/4.3.0",
		"libzip/1.7.3",
		"libzippp/4.0",
		"bzip2/1.0.8",
		"zlib/1.2.11",
		"zstd/1.4.3",
		"ms-gsl/3.0.1",
		"tesseract/4.1.1",
		"xz_utils/5.2.4",
		"cryptopp/8.5.0",
		"opencv/4.5.2",
		"libwebp/1.1.0",
		"qt/5.15.2",
		"libjpeg/9e",
		"libpng/1.6.38",
		"libtiff/4.4.0",
		"sqlite3/3.39.2",
	)

	generators = "MSBuildDeps"

	default_options = (
		"boost:without_python=False",
		"boost:python_executable=" + os.path.join(os.path.dirname(__file__), "../../packages/Python/Python38/python.exe"),
		"boost:python_version=3.8",
		"soci:with_sqlite3=True",
		"libzip:shared=True",
		"libzippp:with_encryption=True",
	)

	def imports(self):
		dst = os.path.join("..", "..")
		if self.settings.arch == "x86_64":
			dst = os.path.join(dst, "x64")
		dst = os.path.join(dst, str(self.settings.build_type))
		self.copy("*.dll", dst, "bin", excludes=("libEGL*.dll", "libGLESv2*.dll"))

```

### Steps to reproduce

1. Add `qt/6.4.1` as requires in conanfile.py
2. QT Versions set `6.4.1-Debug => D:\.conan\3d5de2\1`
3. C:\Users\myname\AppData\Local\QtMsBuild\Qt.props in Property Manager
4. Add conanbuildinfo.props in Property Manager
5. Build project in VS
6. 

### Logs

qtvars_x64_Debug.props:

```
<Qt_LIBS_>D:\.conan\3d5de2\1\res\archdatadir\plugins\styles\qwindowsvistastyled.lib;D:\.conan\3d5de2\1\lib\objects-Debug\QWindowsIntegrationPlugin_resources_1\.rcc\qrc_openglblacklists.cpp.obj;D:\.conan\3d5de2\1\lib\objects-Debug\QWindowsIntegrationPlugin_resources_2\.rcc\qrc_cursors.cpp.obj;D:\.conan\3d5de2\1\res\archdatadir\plugins\platforms\qwindowsd.lib;imm32.lib;oleaut32.lib;shlwapi.lib;winspool.lib;wtsapi32.lib;shcore.lib;comdlg32.lib;d3d9.lib;D:\.conan\3d5de2\1\lib\Qt6OpenGLd.lib;D:\.conan\3d5de2\1\res\archdatadir\plugins\imageformats\qgifd.lib;D:\.conan\3d5de2\1\res\archdatadir\plugins\imageformats\qicod.lib;D:\.conan\3d5de2\1\lib\objects-Debug\Widgets_resources_1\.rcc\qrc_qstyle.cpp.obj;D:\.conan\3d5de2\1\lib\objects-Debug\Widgets_resources_2\.rcc\qrc_qstyle1.cpp.obj;D:\.conan\3d5de2\1\lib\objects-Debug\Widgets_resources_3\.rcc\qrc_qmessagebox.cpp.obj;D:\.conan\3d5de2\1\lib\Qt6Widgetsd.lib;dwmapi.lib;uxtheme.lib;D:\.conan\3d5de2\1\lib\objects-Debug\Gui_resources_1\.rcc\qrc_qpdf.cpp.obj;D:\.conan\3d5de2\1\lib\objects-Debug\Gui_resources_2\.rcc\qrc_gui_shaders.cpp.obj;D:\.conan\3d5de2\1\lib\Qt6Guid.lib;d3d11.lib;dxgi.lib;dxguid.lib;gdi32.lib;CONAN_LIB::libpng_libpng16d_DEBUG.lib;harfbuzz.lib;Gdi32.lib;RpcRT4.lib;USP10.lib;freetyped.lib;libpng16d.lib;zlib.lib;bz2.lib;brotlicommon-static.lib;brotlidec-static.lib;brotlienc-static.lib;glib-2.0.lib;WS2_32.lib;Ole32.lib;User32.lib;AdvAPI32.lib;pcre2-8-staticd.lib;pcre2-posix-staticd.lib;pcre2-16-staticd.lib;pcre2-32-staticd.lib;gnuintl.lib;iconv.lib;charset.lib;gmodule-2.0.lib;gobject-2.0.lib;libffi.lib;gthread-2.0.lib;gio-2.0.lib;iphlpapi.lib;DnsAPI.lib;ShLwApi.lib;CONAN_LIB::md4c_md4c_md4c_md4c_DEBUG.lib;CONAN_LIB::freetype_freetyped_DEBUG.lib;d2d1.lib;dwrite.lib;D:\.conan\3d5de2\1\lib\Qt6Cored.lib;CONAN_LIB::zlib_zlib_DEBUG.lib;synchronization.lib;mpr.lib;userenv.lib;advapi32.lib;authz.lib;kernel32.lib;netapi32.lib;ole32.lib;shell32.lib;user32.lib;uuid.lib;version.lib;winmm.lib;ws2_32.lib;CONAN_LIB::double-conversion_double-conversion_DEBUG.lib;runtimeobject.lib;CONAN_LIB::pcre2_PCRE2_16BIT_pcre2-16-staticd_DEBUG.lib;D:\.conan\3d5de2\1\lib\Qt6EntryPointd.lib;shell32.lib</Qt_LIBS_>
```
user: sinall
issue_12817: state: open
title: MSBuild: add argument to build() to opt-in autoconsumption of props files generated by MSBuildToolchain & MSBuildDeps
body: related to https://github.com/conan-io/conan/issues/12155#issuecomment-1252832378

Changelog: (Fix): In `MSBuild`, add an argument to `build()` method to opt-in automatic consumption of props files generated by `MSBuildToolchain` & `MSBuildDeps`, without requiring intrusive modification of vcxproj files.
Docs: https://github.com/conan-io/docs/pull/2885

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [x] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 

<sup>**Note:** By default this PR will skip the slower tests and will use a limited set of python versions. Check [here](https://github.com/conan-io/conan/blob/develop/.github/PR_INCREASE_TESTING.md) how to increase the testing level by writing some tags in the current PR body text.</sup>

user: SpaceIm
issue_12815: state: open
title: [question] Granularity of new requires traits vs components
body: ### What is your question?

How conan v2 will handle fine-grained components type regarding transitive_libs/transitive_headers/run etc?

For example:

recipeA has 1 library libA, either shared or static depending on shared option

recipeB has 2 component libB1 & libB2:
- libB1: either shared or static depending on shared option
- libB2: always static, and libA is a private dependency of libB2

So we would write something like this in recipeB:

```python
def requirements(self):
    self.requires("recipeA/x.y.y")

def package_info(self):
    self.cpp_info.components["libB1"].libs = ["B1"]
    self.cpp_info.components["libB2"].libs = ["B2"]
    self.cpp_info.components["libB2"].requires = ["recipeA::recipeA"]
```

How conan knows that for recipeB, deps like generators must take into account that libA must always be propagated to link flags of libB imported target (in case of CMakeDeps, but it's the same problem for other deps like generators) even when shared option of recipeB is True (since libB2 component is always static)? I have the feeling that it's not as powerful as CMake PRIVATE/PUBLIC/INTERFACE mechanism per target, but maybe I'm missing something.

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: SpaceIm
issue_12789: state: open
title: [bug] _get_gnu_triplet returns incorrect triplet for x86_64 linux
body: ### Environment details

* Operating System+version: Ubuntu 16.04
* Compiler+version: gcc 5.5
* Conan version: 1.56.0
* Python version: 3.7.13


### Steps to reproduce

1. `conan new foo/0.1.0 --template=cmake_lib`
2. Add the following patch:
```diff
diff --git a/conanfile.py b/conanfile.py
index e12e580..89aa9bc 100644
--- a/conanfile.py
+++ b/conanfile.py
@@ -1,5 +1,7 @@
 from conan import ConanFile
 from conan.tools.cmake import CMakeToolchain, CMake, cmake_layout
+from conan.tools.gnu.get_gnu_triplet import _get_gnu_triplet
+from conan.tools.build.cross_building import get_cross_building_settings


 class FooConan(ConanFile):
@@ -37,6 +39,12 @@ class FooConan(ConanFile):
         cmake.configure()
         cmake.build()

+        os_build, arch_build, os_host, arch_host = get_cross_building_settings(self)
+        compiler = self.settings.get_safe("compiler")
+        triplet = _get_gnu_triplet(os_host, arch_host, compiler=compiler)
+
+        self.output.info(f"Generated triplet: {triplet}")
+
     def package(self):
         cmake = CMake(self)
         cmake.install()
```
3. `conan install .`
4. `conan build .`
5. Observe that the output is `conanfile.py (foo/0.1.0): Generated triplet: x86_64-linux-gnu`

`gcc` expects this to be `x86_64-pc-linux-gnu`, **not** `x86_64-linux-gnu`. Is this expected behaviour?

Relates to #12546 , #10267


### Logs

```
conan@341c228b02d7:~/triplet_test$ conan install .
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=5
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
[conf]
tools.env.virtualenv:auto_use=True
conanfile.py (foo/0.1.0): Installing package
Requirements
Packages

Installing (downloading, building) binaries...
conanfile.py (foo/0.1.0): Generator txt created conanbuildinfo.txt
conanfile.py (foo/0.1.0): Calling generate()
conanfile.py (foo/0.1.0): WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
conanfile.py (foo/0.1.0): Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
conanfile.py (foo/0.1.0): If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/home/conan/triplet_test/build/generators/co
nan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
conanfile.py (foo/0.1.0): Aggregating env generators
conanfile.py (foo/0.1.0): Generated conaninfo.txt
conanfile.py (foo/0.1.0): Generated graphinfo
conan@341c228b02d7:~/triplet_test$ conan build .
Using lockfile: '/home/conan/triplet_test/conan.lock'
Using cached profile from lockfile
conanfile.py (foo/0.1.0): Calling build()
conanfile.py (foo/0.1.0): CMake command: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/conan/triplet_test/build/generators/conan_toolchain.cmake" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYP
E="Release" "/home/conan/triplet_test/."
-- Using Conan toolchain: /home/conan/triplet_test/build/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The CXX compiler identification is GNU 5.5.0
-- Check for working CXX compiler: /usr/local/bin/c++
-- Check for working CXX compiler: /usr/local/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_POLICY_DEFAULT_CMP0091


-- Build files have been written to: /home/conan/triplet_test/build/Release
conanfile.py (foo/0.1.0): CMake command: cmake --build "/home/conan/triplet_test/build/Release" '--' '-j4'
Scanning dependencies of target foo
[ 50%] Building CXX object CMakeFiles/foo.dir/src/foo.cpp.o
[100%] Linking CXX static library libfoo.a
[100%] Built target foo
conanfile.py (foo/0.1.0): Generated triplet: x86_64-linux-gnu
```
user: samuel-emrys
issue_12787: state: open
title: [feature] provide msbuild property sheets to consumers
body: ### What is your suggestion?

I'm trying to convert a Nuget dependency to conan. Nuget packages can provide custom build targets or properties to consumers in the form of `<package_id>.targets` or `<package_id>.props` files (see https://learn.microsoft.com/en-us/nuget/concepts/msbuild-props-and-targets). 
I think conan should be able to provide such ability, e.g. by adding an `msbuild_build_modules`  property, similar to `cmake_build_modules`, and including those modules in `MSBuildDeps` generator outputs.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: dvirtz
issue_12784: state: open
title: [bug] `AutotoolsDeps` is not suitable to Visual Studio
body: ### Environment details

* Operating System+version: Windows 11
* Compiler+version: Visual Studio 2022
* Conan version: 1.56.0
* Python version: 3.10.2


### Steps to reproduce

- checkout https://github.com/SpaceIm/conan-center-index/tree/76a44f95038c2addd04b377deeb80627ce3c6180 (from https://github.com/conan-io/conan-center-index/pull/14792, it's the first attempt of a conan v2 migration of a CCI recipe which uses Autotools AND AutotoolsDeps for msvc build).
- try to build with Visual Studio

config test fails because usual autotools wrapper scripts for cl don't understand `/I` & `/LIBPATH`, so they are passed as is. They expect to receive GNU like flags (`-I` & `-L`) and translate them to cl like flags, not the opposite. These wrappers can't be avoided in the case of https://github.com/conan-io/conan-center-index/pull/14792.

It comes from `GNUDepsFlags` in conan, but it can't be fixed naively because it seems that `MesonDeps` & `PkgConfigDeps` also rely on it.

I think that `AutotoolsDeps` should provide an argument to ask whether it should generate regular cl like options or gnu like options if compiler is msvc.

Or maybe these msvc flags can be passed but they are not properly quoted or something like that, I'm not sure.

### Logs

```
configure:4077: /c/users/spaceim/.conan/data/xapian-core/1.4.19/_/_/build/cdb6fd543ab5677fd09e2c988f468d700c5445bc/src/compile cl -nologo  -MD -O2 -Ob2 -FS  -DNDEBUG /I/c/users/spaceim/.conan/data/zlib/1.2.13/_/_/package/5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b/include  /LIBPATH:/c/users/spaceim/.conan/data/zlib/1.2.13/_/_/package/5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b/lib conftest.c  zlib.lib >&5
cl : Command line warning D9024 : unrecognized source file type 'I:/c/users/spaceim/.conan/data/zlib/1.2.13/_/_/package/5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b/include', object file assumed
cl : Command line warning D9024 : unrecognized source file type 'C:\Users\spaceim\.conan_short\e44064\1\bin\msys64\LIBPATH;C:\users\spaceim\.conan\data\zlib\1.2.13\_\_\package\5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b\lib', object file assumed
conftest.c
LINK : fatal error LNK1181: cannot open input file 'I:\c\users\spaceim\.conan\data\zlib\1.2.13\_\_\package\5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b\include.obj'
configure:4081: $? = 2
configure:4119: result: no
```
user: SpaceIm
issue_12782: state: open
title: Using gtest_discover_tests from cmake.test() in conan2
body: ### What is your question?

I'm trying to figure out the best way to run build-time unit tests for a package using CMake integration in conan2 on Windows. My package is pretty simple, but it does create a shared library and has shared library upstream dependencies.

Here's my folder layout:

CMakeLists.txt
conanfile.py
test/
>CMakeLists.txt
>unittest/
>>CMakeLists.txt
>>src/
>>>tests.cpp

The top-level CMakeLists.txt has the following part relevant to testing:

```
if (NOT BUILD_TESTING STREQUAL OFF)
    enable_testing()
    add_subdirectory(test)
endif()
```
The CMakeLists.txt in the test folder just does

```
project(tests)
add_subdirectory(unittest)
```

Finally, the CMakeLists.txt in the unittest folder has

```find_package(GTest CONFIG REQUIRED)
include_directories(${GTest_INCLUDE_DIRS})
include(GoogleTest)
```
...
```
gtest_discover_tests(${PROJECT_NAME})
```

My conanfile in the top level has

```
def requirements(self):
self.test_requires("gtest/1.12.1")

def build(self):
    cmake = CMake(self)
    cmake.configure()
    cmake.build()
    if not self.conf.get("tools.build:skip_test", default=False):
        cmake.test()
```

The package build works - all the upstream dependencies are found and correctly linked, but it fails when cmake gets to the `gtest_discover_tests` part as the folders for the upstream dependencies are not on the path and the test discovery phase needs to run the test executable.

Is there any way to set up the path correctly at this point in the build to allow this to work? I guess something akin to the test_package workflow would do it, but that happens after the build is complete rather than as part of the build itself.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: snargit
issue_12767: state: open
title: [bug] Conan install doesnt work with pinned revision
body: ### Environment details

* Operating System+version: Ubuntu 20 VM
* Compiler+version:
* Conan version: 1.54
* Python version: 3.6.9


### Steps to reproduce

Iam trying to install a package from my private Artifactory conan repo. 



1- revisions_enabled = True in my ~/.conan/conan.conf
2- Package is already on Conan private repo on Artifactory, structure is : Pkg/version/channel/user/RREV/Package_id/PREV.

Ofcourse RREV,Package_id and PREV are hashes.

i followed instructions from here
https://docs.conan.io/en/latest/versioning/revisions.html#

There is a table that specifies how you can use revisions with conan install for example, the only one that worked for me is


lib/1.0@conan/stable#RREV | Specific RREV for lib/1.0@conan/stable

if i try lib/1.0@conan/stable#RREV:package_id or lib/1.0@conan/stable#RREV:package_id#PREV as in the following command:

$conan install lib/1.0@conan/stable#RREV:package_id#PREV

ERROR: Conanfile not found at /home/$USER/lib/1.0@conan/stable#RREV:package_id#PREV

but this one works no problem:
$conan install lib/1.0@conan/stable#RREV

I thought maybe i need to escape some characters but no luck so far
user: Hash17
issue_12760: state: open
title: [bug] Anomalous behavior running Conan 2.0 in a Git Bash window on Windows 
body: ### Environment details

* Operating System+version: Windows 10
* Compiler+version: Visual Studio 2019
* Conan version: 2.0.0-beta6
* Python version: 3.7.9


### Steps to reproduce

1. Install Git for Windows including the Bash shell
2. Launch a Bash Shell
3. Run a Conan command that uses a recipe that relies on VCVars and commands wrapped in Bash. The m4 recipe fits this bill

### Logs

Here's the output with some debug instrumentation and slightly edited output:

conan-2.0 build -pr:b tools.jinja -pr:h tools.jinja --name m4 --version 1.4.19 .  # --build=never
final_command is ["C:\Users\marc\AppData\Local\Temp\tmp.IwEMme6231\m4\build-release\conan\conanbuild.bat" && "C:\Users\marc\AppData\Local\Temp\tmp.IwEMme6231\m4\build-release\conan\msys2_mode.bat" && C:\Users\marc\.conan2\p\c2bbc405b72a9345\p\bin\msys64\usr\bin\bash.exe --login -c ^". \^"C:\Users\marc\AppData\Local\Temp\tmp.IwEMme6231\m4\build-release\conan\conanbuild.sh\^" ^&^& printenv ^&^& \^"/c/users/marc/appdata/local/temp/tmp.iwemme6231/m4/src/configure\^" --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include gl_cv_func_printf_directive_n=no gl_cv_func_snprintf_directive_n=no gl_cv_func_snprintf_directive_n=no ac_cv_func__set_invalid_parameter_handler=yes ^"]

-------- Input profiles --------
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=192
os=Windows
[tool_requires]
!openssl*: cmake/3.24.2

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=192
os=Windows
[tool_requires]
!openssl*: cmake/3.24.2


-------- Computing dependency graph --------
Graph root
    conanfile.py (m4/1.4.19): C:\Users\marc\AppData\Local\Temp\tmp.IwEMme6231\m4\conanfile.py
Build requirements
    cmake/3.24.2#de544be3bdac5a39bf43ef20ca86c9d8 - Cache
    msys2/cci.latest#c2c59de30b6dd4090dcc00c22859265e - Cache

-------- Computing necessary packages --------
Build requirements
    cmake/3.24.2#de544be3bdac5a39bf43ef20ca86c9d8:581183ca2ec1945c2d8e6bd2fb4795f24f993e62#83abd46d5d9b48cc99aff33793a56e72 - Cache
    msys2/cci.latest#c2c59de30b6dd4090dcc00c22859265e:ea3606590bcd730f9c5363293046107800d8da53#c5d09ac848e472f1f3aff5e4330cd3d0 - Cache

-------- Installing packages --------

-------- Installing (downloading, building) binaries... --------
cmake/3.24.2: Already installed!
cmake/3.24.2: Appending PATH environment variable: C:\Users\marc\.conan2\p\3183c3e6020bdf99\p\bin
WARN: The use of 'env_info' is deprecated in Conan 2.0 and will be removed in Conan 2.X. Please, update your recipes unless you are maintaining compatibility with Conan 1.X
msys2/cci.latest: Already installed!
msys2/cci.latest: Creating MSYS_ROOT env var : C:\Users\marc\.conan2\p\c2bbc405b72a9345\p\bin\msys64
msys2/cci.latest: Creating MSYS_BIN env var : C:\Users\marc\.conan2\p\c2bbc405b72a9345\p\bin\msys64\usr\bin
WARN: The use of 'env_info' is deprecated in Conan 2.0 and will be removed in Conan 2.X. Please, update your recipes unless you are maintaining compatibility with Conan 1.X
WARN: The use of 'env_info' is deprecated in Conan 2.0 and will be removed in Conan 2.X. Please, update your recipes unless you are maintaining compatibility with Conan 1.X
msys2/cci.latest: Appending PATH env var with : C:\Users\marc\.conan2\p\c2bbc405b72a9345\p\bin\msys64\usr\bin
WARN: The use of 'env_info' is deprecated in Conan 2.0 and will be removed in Conan 2.X. Please, update your recipes unless you are maintaining compatibility with Conan 1.X

-------- Finalizing install (deploy, generators) --------
conanfile.py (m4/1.4.19): Calling generate()
conanfile.py (m4/1.4.19): Aggregating env generators
conanfile.py (m4/1.4.19): Calling build()
conanfile.py (m4/1.4.19): Calling:
 > "/c/users/marc/appdata/local/temp/tmp.iwemme6231/m4/src/configure" --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include gl_cv_func_printf_directive_n=no gl_cv_func_snprintf_directive_n=no gl_cv_func_snprintf_directive_n=no ac_cv_func__set_invalid_parameter_handler=yes
conanfile.py (m4/1.4.19): RUN: "/c/users/marc/appdata/local/temp/tmp.iwemme6231/m4/src/configure" --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include gl_cv_func_printf_directive_n=no gl_cv_func_snprintf_directive_n=no gl_cv_func_snprintf_directive_n=no ac_cv_func__set_invalid_parameter_handler=yes
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.7.7
** Copyright (c) 2020 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

ORIGINAL_PATH=/c/Program Files/Git/mingw64/bin:/c/Program Files/Git/usr/bin:...

configure: loading site script /etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /c/users/marc/.conan2/p/c2bbc405b72a9345/p/bin/msys64/usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for gcc... cl -nologo
checking whether the C compiler works... no
configure: error: in `/c/Users/marc/AppData/Local/Temp/tmp.IwEMme6231/m4/build-release':
configure: error: C compiler cannot create executables
See `config.log' for more details
ERROR: conanfile.py (m4/1.4.19): Error in build() method, line 107
        autotools.configure()
        ConanException: Error 77 while executing
ERROR: Conan-2.0 build failed for 'm4'
(conan-2.0)

user: System-Arch
issue_12750: state: open
title: [feature] Ability for Conan remotes to serve "announcements" to clients
body: ### What is your suggestion?

As a Conan remote maintainer, I would like to be able to serve announcement messages that clients see when they perform operations that connect to the remote. 


### Have you read the CONTRIBUTING guide?

- [ ] I've read the CONTRIBUTING guide
user: jcar87
issue_12748: state: open
title: [bug] tools.files.patch not usable with development worfklow
body: ### Environment details

* Operating System+version: Ubuntu 18.04
* Compiler+version: N.A
* Conan version: 1.55.0
* Python version: 3.6


### Steps to reproduce

Calling `tools.files.patch` with an absolute path 
```python
def source(self):
     patch(self, base_path=self.source_folder, patch_file=os.path.join(self.recipe_folder, "patches", "0001-dummy.patch"))
```
It fails
```
export CONAN_VERBOSE_TRACEBACK=1
...
conan install --profile:build "linux-settings" --profile:host "${PROFILE}" --install-folder "${BUILD_DIR}" "${SCRIPT_DIR}"
conan source --source-folder "${SOURCE_DIR}" --install-folder "${BUILD_DIR}" "${SCRIPT_DIR}"
...
conanfile.py (xxxx/3.2.3): Checkout: xxxxx-3.2.3
export_sources_folder [None]
patch_file [/home/XXX6XXX/wp/dummy/patches/0001-dummy.patch]
recipe_folder [/home/XXX6XXX/wp/dummy]
ERROR: Traceback (most recent call last):
  File "/home/XXX6XXX/.local/lib/python3.6/site-packages/conans/errors.py", line 34, in conanfile_exception_formatter
    yield
  File "/home/XXX6XXX/.local/lib/python3.6/site-packages/conans/client/source.py", line 157, in _run_source
    conanfile.source()
  File "/home/XXX6XXX/wp/dummy/conanfile.py", line 63, in source
    patch(self, base_path=self.source_folder, patch_file=os.path.join(self.recipe_folder, "patches", p))
  File "/home/XXX6XXX/.local/lib/python3.6/site-packages/conan/tools/files/patches.py", line 55, in patch
    patch_path = os.path.join(conanfile.export_sources_folder, patch_file)
  File "/usr/lib/python3.6/posixpath.py", line 80, in join
    a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not NoneType
```

Issue seems to be that `self.export_sources_folder` is not set, just try to print `self.export_sources_folder` in the source method() demonstrate the issue
```
print(f"self.export_sources_folder [{self.export_sources_folder}]")
...
self.export_sources_folder [None]
```
Line in the code => https://github.com/conan-io/conan/blob/develop/conan/tools/files/patches.py#L52

I didn't debug further as I don't know the conan path generation mechanic yet. Did I miss to configure something?

### Logs

_No response_
user: Bearwolves
issue_12745: state: open
title: cmake.configure arguments
body: Conan Version: 1.53.0

I am having issues passing arguments into the cmake.configure() method defined at: https://docs.conan.io/en/1.53/reference/build_helpers/cmake.html#configure

I am appending a list of arguments and then passing it into cmake.Configure.

Example:

```
configure_args = []
configure_args.append("-debug" if self.settings.build_type == "Debug" else "-release")
```
**I have tried** 
```
cmake.configure(configure_args)
cmake.configure(self, configure_args)
```
**Result**: TypeError: join() argument must be str, bytes, or os.PathLike object, not 'list'
```
cmake.configure(args=configure_args)
cmake.configure(self, args=configure_args)
```
**Result**: TypeError: CMake.configure() got an unexpected keyword argument 'args'

I am at a loss of what the configure method wants.

user: MikeRavenelle
issue_12739: state: open
title: [bug] AutotoolsToolchain does not call vcvars when compiler is Visual Studio 2012
body: ### Environment details

* Operating System+version: Windows
* Compiler+version: Visual C++ from Visual Studio 2012
* Conan version: 1.55



### Steps to reproduce

May need further investigation, but it appears recipes that use the new `AutotoolsToolchain` integration do not end up loading vcvars at all when the compiler is from Visual Studio 2012.

Note that this may be expected - as per https://github.com/conan-io/tribe/blob/main/design/032-msvc_support.md, for VS 2012 only CMake integrations are covered. However we may be able to improve the experience (e.g. point the user to invoke the conan commands from within a VS shell).


### Logs

`autotools.configure()` inside a `build()` method will fail with an error pointing to look at `config.log`, which shows that `cl` cannot be located in the current environment.


user: jcar87
issue_12734: state: open
title: [feature] Allow toolchain packages to disable CMakeToolchain Blocks as they may interfere with the toolchains intention
body: ### What is your suggestion?

I just wrote a toolchain for X32 (x86_64, but with 32 bit pointers) as a conan package to be used with CMakeToolchain, and it kind of works, but I need to disable the `arch_flags` block with `tc.blocks.remove("arch_flags")` because the `-m32` or `-m64` flag is confusing the compilers and causing it generate the wrong output.

It would be nice if I could either disable a toolchain block via config from the profile, or from the user_toolchain(preferred), or override it from a user_toolchain that is included at the end (least preferred).

Otherwise I would need to modify the conan recipes that will be used, and I only need to do that for certain toolchains, which makes this even more annoying. 

On a much higher level, I would prefer to be able to set the target triple (x86_64-linux-gnux32 for X32, armv8.5-a+crypto-linux-gnu_ilp32 for my Macbook, or a plain x86_64-linux-gnu for anybody else) instead of having os and arch as this would give a much cleaner command line for clang, and would potentially allow to find a proper GCC to be used.

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: KarstenB
issue_12733: state: open
title: [question] Canonical way to get all aggregated cpp_info of a dependency with `conanfile.dependency`?
body: ### What is your question?

attributes like `system_libs` of `self.dependencies[deps].cpp_info` are empty when deps has components. It seems that the robust way to get aggregated attributes is `self.dependencies[deps].cpp_info.aggregated_components()`, but in terms of API it's a little bit confusing since consumers have to know whether a dependency has components or not, or they have to always call `aggregated_components()` to prevent any breakage in case of modification in downstream recipe (which could suddenly decide to add components in a new RREV).
Moreover `aggregated_components()` is not documented in https://docs.conan.io/en/latest/reference/conanfile/dependencies.html
And finally, it can be confusing if consumer wants to also call `get_property`. Properties are not aggregated, so consumers must be aware of this internal detail, and refer to `self.dependencies[deps].cpp_info` when they want to use get_property, and `self.dependencies[deps].cpp_info.aggregated_components()` when they want to get attribures like bindirs, system_libs, frameworks, libs etc

Is it intended?

related to https://github.com/conan-io/conan-center-index/issues/14817

### Have you read the CONTRIBUTING guide?

- [x] I've read the CONTRIBUTING guide
user: SpaceIm
issue_12729: state: open
title: [question] Recommended practice for managing dependencies
body: ### What is your question?

Hi!

I have questions regarding mixing my recipes and recipes from conan center and also managing versions. I have several use cases which I want to know how to solve in a better way.

### Scenario 1
First scenario which I face. I have the following graph of dependencies:
conancenter packages <- pkg@mycompany <- app@mycompany

Sometimes I get the following error from the subgraph of conancenter packages: "something requires zlib/1.1.12 while other requires zlib/1.1.13, to fix this conflict you need to override it in your root package". None of pkg@mycompany and app@mycompany have direct dependency on zlib, so it seems a bit non-logical to put zlib as their requires. And I also would like to make sure that during developing of pkg@mycompany I will use the same version of zlib which will be later used in app@mycompany. (zlib and openssl often cause such conan conflicts errors, though I think their api is quite stable).

### Scenario 2
Secondly, sometimes I would like to make a fork of a recipe from conancenter (let's say for a library named `lib`). Then I have the following dependency graph:
conancenter packages <- lib@mycompany <- conancenter packages <- other packages@mycompany

Here I again need to understand where is a better place to override "lib" with "lib@mycompany".

### Final thoughts
Our own packages are often no so api stable as zlib and openssl, where I would prefer to have version ranges. Thus I think that override warnings about those versions should be somehow more visible and more important.

Maybe, it is suggested to make a fork of conancenter recipes to our company git repo and manage it there? Or don't put "mycompany" suffix for forked recipes, but just keep them in a different more prioritized remote?



### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: technic
issue_12726: state: open
title: [question] Is it possible to customize lib version in CMake config file generated by `CMakeDeps`?
body: ### What is your question?

In `vulkan-headers` recipe of conan-center, version in CMake config file generated by CMakeDeps must be "sanitized" to really follow upsteam CMake config file content (always `x.y.z` while we may have "sdk version" like `1.3.236.0` in conan-center). It's important because build system of a downstream recipe (`vulkan-validationlayers`) relies on this version in CMake config file to inject this value into a manifest file. If this value doesn't exactly follow this `x.y.z` convention, it leads to an illformed manifest file which will break logic of another library at runtime (`Vulkan-Loader`) when it tries to find validation layers.
see https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/4973

So is it possible to change this version in `package_info()`? Something like this in `vulkan-headers` recipe for example:

```python
def package_info():
    vk_version = Version(self.version)
    self.cpp_info.set_property("cmakedeps_version", f"{vk_version.major}.{vk_version.minor}.{vk_version.patch}")
```

### Have you read the CONTRIBUTING guide?

- [X] I've read the CONTRIBUTING guide
user: SpaceIm
issue_12706: state: open
title: [question] Locally built package not found
body: <!-- What is your question? Please be as specific as possible! -->

Conan can't find a locally build package. I had no errors when running `conan create`. Not sure if I am using the correct hash for the requires parameter. 

So I have built the package locally and can see the contents in this folder.
`C:\Users\ckearney\.conan\data\cef\106.1.0+g30ad805\nitro\docker\package\d23a10e4a9236fc851c01354c5bb71c139236b0e`

In my app, I have a conanfile that requires the package:
`self.requires("cef/106.1.0+g30ad805@nitro/docker#d23a10e4a9236fc851c01354c5bb71c139236b0e")`

When trying to build my app. Not being able to find it in the remote is expected. However it should of found it in the local cache.
```
cef/106.1.0+g30ad805@nitro/docker: Not found in local cache, looking in remotes...
cef/106.1.0+g30ad805@nitro/docker: Trying with 'conancenter'...
ERROR: Failed requirement 'cef/106.1.0+g30ad805@nitro/docker' from 'conanfile.py'
ERROR: Unable to find 'cef/106.1.0+g30ad805@nitro/docker#d23a10e4a9236fc851c01354c5bb71c139236b0e' in remotes
```

Here are some commands trying to look for the package, I wasn't sure when to use the `@` so I did it for both:

- search
```
PS C:\repos\nitroapp> conan search cef/106.1.0+g30ad805 
Existing package recipes:

cef/106.1.0+g30ad805@nitro/docker

PS C:\repos\nitroapp> conan search cef/106.1.0+g30ad805@
ERROR: Recipe not found: 'cef/106.1.0+g30ad805'
```

- info
```
PS C:\repos\nitroapp> conan info cef/106.1.0+g30ad805   
ERROR: Conanfile not found at C:\repos\nitroapp\cef\106.1.0+g30ad805

PS C:\repos\nitroapp> conan info cef/106.1.0+g30ad805@
cef/106.1.0+g30ad805: Not found in local cache, looking in remotes...
cef/106.1.0+g30ad805: Trying with 'nitro'...
cef/106.1.0+g30ad805: Trying with 'conancenter'...
ERROR: Unable to find 'cef/106.1.0+g30ad805' in remotes
```

- inspect
```
PS C:\repos\nitroapp> conan inspect cef/106.1.0+g30ad805@
cef/106.1.0+g30ad805: Not found in local cache, looking in remotes...
cef/106.1.0+g30ad805: Trying with 'nitro'...
cef/106.1.0+g30ad805: Trying with 'conancenter'...
ERROR: Unable to find 'cef/106.1.0+g30ad805' in remotes

PS C:\repos\nitroapp> conan inspect cef/106.1.0+g30ad805 
cef/106.1.0+g30ad805: Not found in local cache, looking in remotes...
cef/106.1.0+g30ad805: Trying with 'nitro'...
cef/106.1.0+g30ad805: Trying with 'conancenter'...
ERROR: Unable to find 'cef/106.1.0+g30ad805' in remotes
```


Conan version: 1.54 - Configuration:
```
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.toolset=v143
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
```

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: ckearney-nitro
issue_12694: state: open
title: [question] Look into usage of resdirs in downstream consumers
body: The default value of `resdirs` (`res`) has caused confusion in Conan Center, where a package install scripts may place certain files in the `share` subfolder. This has lead to a de-facto rule where we advise to place this files either in `res` or, as a workaround, in the `bin` subfolder.

`self.cpp_info.resdirs = ['res'] `

The FHS (https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf) describes the contents of `share` in section 4.11.

The default value of `cpp_info.resdirs` and the location inside Conan Center packages are probably orthogonal and should require no enforcement. For example, the cmake executable assumes that it can find the modules folder in a specific location _relative_ to the executable, so we cannot alter the location (it must be in `share` inside the package folder, or cmake ceases to be relocatable).

The files typically inside these folders tend to be either specific to the executable, or contain files that are currently excluded from conan center packages (for example, generated CMake configuration files). 

Consider:
* Evaluate whether there are any implicit uses of `cpp_info.resdirs` that affect downstream consumers 
* Evaluate whether in Conan 2.0 this could be `share`, to align ourselves with FHS, or if this has any impact at ll
* Re-consider the current rules in Conan Center - chances are we are overburdening contributors by making them move things inside the package for no technical reason.




user: jcar87
issue_12691: state: open
title: [feature] Provide a wrapper for `rc.exe` to ease Autotools builds with msvc
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Most autotools projects which have to compile a resource file expect a resource compiler following `windres` command line interface (GNU resource compiler for windows in binutils).

While windres works fine for native build on Windows x86_64, there are several flaws:
- windres is not provided by Visual Studio installation, usually it's exposed indirectly in conan-center recipes by msys2 in tool_requires
- cross-build doesn't work out of the box
- ARM64 is not supported

Therefore a neater way to compile these resource files if compiler is Visual Studio, is to use `rc.exe` (resource compiler of Visual Studio, which is provided by Windows SDK actually). But it doesn't understand options of windres, therefore we need a wrapper translating these options to rc.exe options, so that we can inject this script with `rc.exe` as an argument into `WINDRES` & `RC` env vars for autotools.
vcpkg handles this magic out of the box in its autotools helper:
https://github.com/microsoft/vcpkg/blob/cf1fda5443f2acfa976d5bda70c50fa22c26fe80/scripts/cmake/vcpkg_configure_make.cmake#L307-L308
https://github.com/microsoft/vcpkg/blob/master/scripts/buildsystems/make_wrapper/windres-rc

Here is an issue in conan-center which cannot be solved easily without such wrapper: https://github.com/conan-io/conan-center-index/issues/14279
There is also at least libgettext recipe which is likely broken for Windows cross-build to ARM64 with Visual Studio.
user: SpaceIm
issue_12687: state: open
title: [bug] Virtual repository breaks when remote repository becomes unreachable (and conan center is down)
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: all
  * Compiler+version: n/a
  * Conan version: 1.55
  * Python version: 3.11

### Steps to reproduce (Include if Applicable)
Conan center appears to be down at the moment. I have a virtual repository on Artifactory that uses conan center as a remote repository. I thought some of the point here was to have a cache that was under our control, so if conan center goes down or goes away, we can continue to operate. Shouldn't this work?

user: rconde01
issue_12680: state: open
title: [question] 2.0 Migration how to check MSVC version without raising an error
body: To have a recipe that works for 1.x and 2.0 we need to check both `"Visual Studio"` and `"msvc"` however each uses a different version scheme so both need to be check individually.

For example 

https://github.com/conan-io/conan-center-index/blob/e72e91ee19975973e7ca1a4d8e2b714be60b0175/recipes/jsoncpp/all/conanfile.py#L73-L74

would become

```py
        if (self.settings.compiler == "Visual Studio" and self.settings.compiler.version == "11") or \
           (self.settings.compiler == "msvc" and self.settings.compiler.version == "100"): # might be wrong versions its too old
```

But in 2.0 this would still produce the error for using an unknown compiler.

```log
jsoncpp/1.9.5: Error in build() method, line 79
	self._patch_sources()
while calling '_patch_sources', line 73
	if self.settings.compiler == "Visual Studio" and self.settings.compiler.version == "11":
	ConanException: Invalid setting 'Visual Studio' is not a valid 'settings.compiler' value.
Possible values are ['sun-cc', 'gcc', 'msvc', 'clang', 'apple-clang', 'intel-cc', 'qcc', 'mcst-lcc']
Read "http://docs.conan.io/en/latest/faq/troubleshooting.html#error-invalid-setting"
```

Typically we would use https://docs.conan.io/en/1.53/reference/conanfile/tools/microsoft.html#check-min-vs but that raises an except which is not the required effect here
user: prince-chrismc
issue_12679: state: open
title: [question] how to override transitive build_requires?
body: # The problem

I am trying to override a transitive requirement from a build requires.
Take the following example:

```
import json
import os

from conans.model.graph_lock import GraphLockFile
from conans.test.utils.tools import TestClient, GenConanfile

profile = """
[tool_requires]
""" 

def test_regular_package():
    client = TestClient()
    # TODO: This is hardcoded
    client.run("config set general.revisions_enabled=1")
    client.save({"pkga/conanfile.py":     GenConanfile(),
                 "tool/conanfile.py":    GenConanfile().with_requires("pkga/[>=1.0.0]"),
                 "app/conanfile.py":      GenConanfile().with_require("pkga/1.0.0").with_build_requires("tool/1.0.0"),
                 "myprofile": profile})    # version range in app
   
   
    # export different version from the libs to the cache         
    client.run("export pkga pkga/1.0.0@")
    client.run("export pkga pkga/1.1.0@") #This starts the misery
    client.run("export tool tool/1.0.0@") 
    client.run("export app  app/1.0.0@")

    client.run("lock create --reference app/1.0.0@  --lockfile-out app.lock --build outdated --profile=myprofile --profile:build=myprofile")
    client.run("lock build-order app.lock --json=build_order.json")
```

Running this, I get a lockfile that contains `pcka/1.0.0@` in the build context, but `pcka/1.1.0@` in the host context. 


I would like to somehow lock `pkga/1.0.0` also for the build context.
How can I achieve it? Any arguments, `require-overrides` (seems not available for `lock create` command), any suggestion is highly appreciated 😄 

## What I have tried:

### adding another build_requires of pkga to the conanfile of app
```
.with_build_requires("pkga/1.0.0@")
```
This results in the followint error
```
E           Exception:
E           ------------------------ Command failed (unexpectedly): ------------------------
E           lock create --reference app/1.0.0@  --lockfile-out D:/Temp/conan-2-profiles/app.lock --build outdated --profile=myprofile --profile:build=myprofile
E           ----------------------------------- Output: ------------------------------------
E           ERROR: Conflict in tool/1.0.0:
E               'tool/1.0.0' requires 'pkga/1.1.0' while 'app/1.0.0' requires 'pkga/1.0.0'.
E               To fix this conflict you need to override the package 'pkga' in your root package.
E
E           --------------------------------------------------------------------------------
```
(But I don't know how, `build_requires` or `tool_requires` don't take override arguments)

### Putting a tool_requires in the profile
profile = """
[tool_requires]
tool:pkga/1.0.0@
""" 
doesn't seem to have any effect whatsoever

### 
There doesn't seem to be anything like an override for tool_requires.
In general I suspect / hope that things get easier for 2.0, but I would need this for the preparation of the Conan 2.0 migration.
## app.lock for reference
```
{
 "graph_lock": {
  "nodes": {
   "1": {
    "ref": "app/1.0.0#1060c73d1197f6b245cef3cd7c87ac71",
    "options": "",
    "package_id": "7a295e38f67ab11f20e4d00c956ccbf105042b5d",
    "requires": [
     "2"
    ],
    "build_requires": [
     "3"
    ],
    "context": "host"
   },
   "2": {
    "ref": "pkga/1.0.0#f3367e0e7d170aa12abccb175fee5f97",
    "options": "",
    "package_id": "5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9",
    "context": "host"
   },
   "3": {
    "ref": "tool/1.0.0#a04bd171e1fdb2dfdd736aad73aedf92",
    "options": "",
    "package_id": "7a295e38f67ab11f20e4d00c956ccbf105042b5d",
    "requires": [
     "4"
    ],
    "context": "build"
   },
   "4": {
    "ref": "pkga/1.1.0#f3367e0e7d170aa12abccb175fee5f97",
    "options": "",
    "package_id": "5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9",
    "context": "build"
   }
  },
  "revisions_enabled": true
 },
 "version": "0.4",
 "profile_host": "[settings]\n[options]\n[build_requires]\n[env]\n",
 "profile_build": "[settings]\n[options]\n[build_requires]\n[env]\n"
}
```
user: KerstinKeller
issue_12676: state: open
title: [question] ERROR: not a valid git repo or git not found (But it's a git repo and git is in the path)
body: When I run (from a CMD window):

conan export-pkg . <name> -if .conan -f 

I'm getting an error:
ERROR: <current directory> is not a valid 'git' repository or 'git not found

However, if I run 'git status' in the same directory it shows that my repo is clean and up to date. (All other git commands, commit, push, etc work fine also.)

Is there anything else that would give that error?

git --version is 2.25.1.windows.1
conan --version is 1.43.4

- [x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: a101010
issue_12667: state: open
title: [question] How to build MacOS Universal2 with a mix on Universal2 and non-Universal2 Conan packages
body: Does anybody have any experience creating Conan pkgs for Apple Universal2/fat binaries i.e. those that contain both `x86_64` & `arm64` code?  The recommended approach seems to be to remove the arch setting to indicate a pkg is "any architecture": https://github.com/conan-io/conan-extensions/issues/59  That isn't quite true for Universal2 as it only supports `x86_64` and `arm64` architectures.  However, you can't specify multiple architectures for the Conan arch setting and as of 1.54, `universal2` is not a recognized arch setting.

CMake supports building Universal2 (fat) binaries and static libs quite nicely with this one setting:
```cmake
set(CMAKE_OSX_ARCHITECTURES "arm64;x86_64" CACHE STRING "" FORCE)
```

This will compile each source file with `-arch arm64 -arch x86_64` producing fat o files that can be linked into either fat binaries or fat static libs.  Pretty neat but once you introduce other Conan pkgs into the picture, particularly source-only packages that don't build universals libs directly, things fall apart.  Since Conan drives the CMake build process and there is no Conan arch to specify you want a fat lib, the best you can do AFAICT is run `conan install` twice: once for the `x86_64` and again for `arm64`.  But when you go to build your source, you have to specify either arch=x86_64 or arch=x64 when referencing those pkgs (think gtest or poco).  You can't remove the arch setting for those pkgs, arch is a required setting. If you do, Conan won't find a matching recipe.  So if you pick arch=x86_64 you wind up with a conanbuildinfo.cmake that references the gtest x86_64 architecture and then fails to build a fat o file because it can't find the arm64 version e.g.:

```
ld: warning: ignoring file /Users/hillr/.conan/data/gtest/1.8.1-1/conan/stable/package/05e7d98d1302d7e4c4029b91efa8810e5bf7de58/lib/libgmockd.a, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
```

So, unless the Conan src pkg you need to build knows how to build for Universal2, I'm not sure how you get Conan to tell CMake, "Hey, for this here gtest pkg, when you link to it, refer to the libs in BOTH the x86_64 **and** arm64 recipes".  I don't know of a way to do that.  It's looking like the best way to build is to build separately for `x86_64` and `arm64` and then at the end create a fat lib (or binary) from each build.  What's frustrating is that you can do this from the command line easily.  It is very simple to build an x86_64 binary against a fat static lib or an arm64 binary against that same fat lib or a fat binary against that same fat lib.  Put Conan into the mix and that simplicity seems to evaporate. 😢 

Is there something I'm missing that would make Conan get on board with Universal2 builds?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: rkeithhill-keysight
issue_12663: state: open
title: [question] using self-written (not conan-center) conan recipes during a build?
body: We have a group internally who is trying to build open source C++ code using conan. 

We rely on some C++ code which doesn’t yet exist in the conan ecosystem (example: https://github.com/spdk/spdk ). The team tells me that there’s a pretty stringent process to get things listed (needing it to succesfully compile for multiple architectures, etc), such that it’s unlikely they’ll be able to submit a 3rd party recipe to conan for these dependencies. Additionally, it’s not likely that the upstreams will take the conanfile contributions. 

Is there a way to have 3rd party recipes within conan such that we can build this out in the open?

Our alternative it to use an internally hosted conan instance and do all builds internally.. but doing that behind closed doors has several questions and concerns associated that we’d love to avoid.


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: justinabrahms
issue_12661: state: open
title: [question] How to specify compiler cflags (such as -B, --sysroot and -static-libgcc) for cross-compilation
body: <!-- What is your question? Please be as specific as possible! -->

One of my toolchain required the usage of -B, --sysroot and -static-libgcc in order to be usable.  I have attempted to use CONAN_C_FLAGS, CFLAGS in my profile.  So far, I only got it working when I defined CC as "arm-linux-gcc -B<path> --sysroot=<path> -static-gcc"

I was expecting that CONAN_C_FLAGS would get mapped to the gcc CFLAGS, or just CFLAGS would, but none does.

I am also surprised to see CONAN_CMAKE_SYSROOT not being converted into a --sysroot option to gcc, and something else I found which is surprising, is that if I set CONAN_CMAKE_SYSROOT=mysysroot, the actual value I see being used in CMAKE is mysysroot/usr

where is that /usr coming from?

```
build/generators/conanbuildenv-release-armv7hf.sh:export CONAN_CMAKE_SYSROOT="/usr/arm-5.3-uclibc-1.0.12/usr/arm-buildroot-linux-uclibcgnueabihf/sysroot"
build/CMakeFiles/3.25.1/CMakeCCompiler.cmake:set(CMAKE_C_COMPILER_SYSROOT "/usr/arm-5.3-uclibc-1.0.12/usr/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr")
build/CMakeFiles/3.25.1/CMakeCCompiler.cmake:set(CMAKE_COMPILER_SYSROOT "/usr/arm-5.3-uclibc-1.0.12/usr/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr")
```

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: hpe-ykoehler
issue_12660: state: open
title: [bug] Incorrect usage of "build" profiles instead of target.
body: https://wiki.osdev.org/GCC_Cross-Compiler

In Conan, the definition of host & build seems to be different than what the cross-compiling terms are in other tools.

In GCC/autotools, etc.  The host is the platform you initiate the command from, the target is the machine the binaries you are building will be run on, while the build is a specific Canadian Cross-Compile terminology for when you create a tool-chain on the host that is targetting to be run on the build, as to produce a binary that runs on a target.

As such, the host/build profile notion in Conan would be better expressed as host/target instead, so as to not cause confusion with the same terms in other cross-compiling aspects.


user: hpe-ykoehler
issue_12657: state: open
title: [question] How to debug private dependency issues
body: <!-- What is your question? Please be as specific as possible! -->
Hello,

I am using conan version 1.52

I have a library package, say Lib1 having option SocketType which can take values S1,S2,S3, etc.
I have components which use this Lib1 package as a dependency.
So, I have Comp1 which requires self.options['Lib1'].SocketType=S1
Also, I have another component Comp2, which requires a different value of SocketType.

Below are excerpts from my configuration in short:

conanfile of Comp1 looks like:
```
self.requires("Lib1", private=True)

self.options["Lib1"].SocketType = "S1"
```

conanfile of Comp2 looks like:
```
self.requires("Lib1", private=True)

self.options["Lib1"].SocketType = "S2"
```


conanfile of my main consumer package looks like:
```
self.requires("Comp1")
self.requires("Comp2")
self.requires("Lib1")

self.options["Lib1"].SocketType = "S2"
```

Now, when I try to run conan info command, I get error saying:  
`ERROR: Comp1 tried to change option SocketType to S1 but it was already assigned to S2 by MainConsumerPkg`

How do I proceed to debug the actual cause of the ERROR. I tried setting CONAN_LOGGING_LEVEL=1 but still I do not get information which will help me find the error in dependencies.

Could you please let me know some way by which I can see more verbose steps to figure out the issue?


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: sunj1
issue_12654: state: open
title: [question][1.55.0] "CMakeDeps" doesn't provide `IMPORTED_LOCATION[_<CONFIG>]` target properties for its generated Imported Targets?
body: ### Problem Description

This issue is related to the one I posted before, which was closed with the new release version **1.55.0**:

* https://github.com/conan-io/conan/issues/12077

In short, the problem mentioned in the above issue is that "CMakeDeps" generator doesn't provide the following target properties for its generated Imported Targets:

* [`IMPORTED_LOCATION`](https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_LOCATION.html)
* [`IMPORTED_LOCATION_<CONFIG>`](https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_LOCATION_CONFIG.html)

However, it seems that this problem is still not solved after conducting some experiments, https://github.com/conan-io/conan/issues/12077#issuecomment-1324031251.

@memsharded @lasote 

What do I miss? If I do miss somehting in the [demo](https://github.com/conan-io/conan/issues/12077#issuecomment-1324031251), can you provide a correct demonstration?

Thanks.

user: hwhsu1231
issue_12641: state: open
title: [question] Best practice to generate compile_commands.json across deps
body: <!-- What is your question? Please be as specific as possible! -->

Newbie here...
What are some suggested workflows for generating compile_commands.json (a la `clangd`) for conan projects?  For make-based projects I typically build thus `bear make ...`., whereas for cmake-based projects thus `cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1 ...`.  I'd really like to do this for any deps I'm pulling in, while avoiding mucking-up recipes files. 
user: GrqPnegre
issue_12625: state: open
title: Artifactory bloat issues with multiple Conan packages (versions/revision). 
body: We have 80+ repos (components) that change frequently and are interdependent (changing one component will result in multiple versions of other dependent components). Artifactory is our binary storage repository. Now that we plan to migrate to Conan, we are concerned about the storage requirements in Artifactory as we will be generating N Conan package versions daily due to direct or transitive dependencies. Do we have a recommendation on how this can be optimized?
user: mkjkec2005
issue_12624: state: open
title: [question] VirtualRunEnv doesn't generate PowerShell ps1 script
body: <!-- What is your question? Please be as specific as possible! -->

Using the `VirtualRunEnv` generator in a conan recipe with conan 1.53 in a Windows Developer PowerShell doesn't generate ps1 scripts. Only the conanrun.bat and conanrunenv-release-x86_64.bat are generated. Is there a configuration to generate also the powershell scripts?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).


user: fjp
issue_12618: state: open
title: [question] Compile with `_GLIBCXX_DEBUG`
body: Hello, I'm trying to debug a project and attempt to use preprocessor macro `_GLIBCXX_DEBUG` to assist the debug. This requires all packages to be compiled with this macro, or a link error will occur. 

However, I don't know how I can get the required packages compiled with this macro. Is it possible to get the packages in conanfile compiled with custom macros?

canonfile.txt
```
[requires]
boost/1.80.0
antlr4-cppruntime/4.9.3
fmt/9.1.0
gtest/1.10.0
magic_enum/0.8.1
tabulate/1.4

[generators]
cmake
```
with profile
```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++11
build_type=Debug
[options]
[build_requires]
[env]
CXXFLAGS=-D_GLIBCXX_DEBUG
```

This profile is not working, and cannot get the required packages compiled with `_GLIBCXX_DEBUG`, and when I enabled this macro in CMake, the link error occurs

```
/usr/bin/ld: CMakeFiles/main.dir/parser/SQLParser.cpp.o: in function `SQLParser::SQLParser(antlr4::TokenStream*)':
.../parser/SQLParser.cpp:14: undefined reference to `antlr4::atn::ParserATNSimulator::ParserATNSimulator(antlr4::Parser*, antlr4::atn::ATN const&, std::__debug::vector<antlr4::dfa::DFA, std::allocator<antlr4::dfa::DFA> >&, std::__debug::unordered_set<std::shared_ptr<antlr4::atn::PredictionContext>, antlr4::atn::PredictionContextHasher, antlr4::atn::PredictionContextComparer, std::allocator<std::shared_ptr<antlr4::atn::PredictionContext> > >&)'
```



- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Btlmd
issue_12610: state: open
title: Cross-compiling ninja from Macos armv8 to Android armv8
body: I'm trying to cross-compile `ninja v1.11.1` from my `Macos M1 (armv8), Monterey 12.6` to `Android armv8`, using the `NDK 22.1.7171670`. I'm using [conan-package-tools](https://github.com/conan-io/conan-package-tools) with the following settings:

```
builder.add(settings={
        "compiler.cppstd": "17",
        "os": "Android",
        "arch": "armv8",
        "build_type": "Release",
        "os.api_level": "24",
        "compiler": "clang",
        "compiler.version": "11",
        "compiler.libcxx": "libc++",
        "os_build": "Macos",
        "arch_build": "armv8"
    }, options={}, env_vars={
        "CONAN_CMAKE_ANDROID_NDK": "<path>/25.1.8937393"
    }, build_requires={})
```
```
% python --version
Python 3.10.8
```

Log snipet:
```
ninja/1.11.1@local/workbench:
ninja/1.11.1@local/workbench: Copying sources to build folder
ninja/1.11.1@local/workbench: Building your package in /Users/ernesto.messina/.conan/data/ninja/1.11.1/local/workbench/build/4cd8a0226669e0be90b7c9a8fcdc9ee41453a7d3
ninja/1.11.1@local/workbench: Generator txt created conanbuildinfo.txt
ninja/1.11.1@local/workbench: Calling generate()
ninja/1.11.1@local/workbench: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
ninja/1.11.1@local/workbench: Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
ninja/1.11.1@local/workbench: If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/Users/ernesto.messina/.conan/data/ninja/1.11.1/local/workbench/build/4cd8a0226669e0be90b7c9a8fcdc9ee41453a7d3/build/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
ninja/1.11.1@local/workbench: Aggregating env generators
ninja/1.11.1@local/workbench: Calling build()
ninja/1.11.1@local/workbench: CMake command: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/Users/ernesto.messina/.conan/data/ninja/1.11.1/local/workbench/build/4cd8a0226669e0be90b7c9a8fcdc9ee41453a7d3/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/Users/ernesto.messina/.conan/data/ninja/1.11.1/local/workbench/package/4cd8a0226669e0be90b7c9a8fcdc9ee41453a7d3" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/Users/ernesto.messina/.conan/data/ninja/1.11.1/local/workbench/build/4cd8a0226669e0be90b7c9a8fcdc9ee41453a7d3/src"
-- Using Conan toolchain: /Users/ernesto.messina/.conan/data/ninja/1.11.1/local/workbench/build/4cd8a0226669e0be90b7c9a8fcdc9ee41453a7d3/build/generators/conan_toolchain.cmake
CMake Error at /Users/ernesto.messina/Library/Android/sdk/ndk/22.1.7171670/build/cmake/android.toolchain.cmake:381 (message):
  Invalid Android STL: libc++.
Call Stack (most recent call first):
  /Users/ernesto.messina/.conan/data/ninja/1.11.1/local/workbench/build/4cd8a0226669e0be90b7c9a8fcdc9ee41453a7d3/build/generators/conan_toolchain.cmake:27 (include)
  /opt/homebrew/Cellar/cmake/3.24.2/share/cmake/Modules/CMakeDetermineSystem.cmake:124 (include)
  CMakeLists.txt:6 (project)


CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
```

I've tried changing the SDK version, but got the same error.
Also tried `compiler.libcxx` to `c++_static` and `c++_shared`, but got code errors, like not detecting the compiler correctly.
user: TheSlackOne
issue_12607: state: open
title: [feature] Add QML Plugins support to qmake generator
body: Now when using the [qml plugin](https://doc.qt.io/qt-6/qtqml-modules-cppplugins.html) in the project using it, you need to specify the path to the qml files using the variable [QML_IMPORT_PATH](https://doc.qt.io/qtcreator/creator-qml-modules-with-plugins.html#importing-qml-modules) 
At the moment, the [qmake generator](https://github.com/conan-io/conan/blob/develop/conans/client/generators/qmake.py) does not support the creation of a  variable QML_IMPORT_PATH in conanbuildinfo.pri.

I propose to add the functionality of creating  a  variable QML_IMPORT_PATH in conanbuildinfo.pri.

PS:
I understand that I can create my [own generator](https://docs.conan.io/en/1.43/howtos/custom_generators.html) to enable qml plugins, but it seems to me that this functionality should be available out of the box when using the generator for qmake, since qml pligins is an integral part of Qt applications

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: explorer85
labels: component: Build: Build helpers, build systems..
issue_12606: state: open
title: [question] toolchains: generate in a list of scopes?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Sorry if I already asked, but in high level toolchains helpers, is it possible to call `generate()` method of these helpers with a list of scopes?

In boost recipe I would need to create a custom scope which has everything from `build` scope except one toolchain, so that onespecific `self.run` afterwards during build() is called with this custom scope, but all other self.run of build() should be executed with build scope. See https://github.com/conan-io/conan-center-index/pull/14415#discussion_r1031921124

In conan v1, it was quite easy to have fine-grained env vars for each self.run. But with conan v2 paradigm where all vars are supposed to be written in one or several scripts in generate() and associated to scope names, so that they can be called afterwards, it's less obvious.

Current `generate()` of boost recipe in https://github.com/conan-io/conan-center-index/pull/14415 is quite simple:

```python
    def generate(self):
        if not self.options.header_only:
            env = VirtualBuildEnv(self)
            env.generate()
            if is_msvc(self):
                vc = VCVars(self)
                vc.generate()
```

But would it be possible to have something like this (pretty sure it doesn't work currently since `scope` argument expects a string):

```python
    def generate(self):
        if not self.options.header_only:
            env = VirtualBuildEnv(self)
            env.generate(scope=["build", "build_but_without_vc_vars_when_b2_is_called"])
            if is_msvc(self):
                vc = VCVars(self)
                vc.generate()
```


user: SpaceIm
issue_12605: state: open
title: [feature] conan v2 tools: expose a public function like `tools.msvs_toolset`
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

boost recipe needs to inject toolset version. In conan v1 there is `tools.msvs_toolset`. In conan v2 there is no public function. The closest function suitable for cross conan v1/v2 support is a private static method of `MSBuildToolchain`: `_msvs_toolset`. Current workaround in boost recipe is get this value from `MSBuildToolchain(self).toolset` since it's populated with value returned by `_msvs_toolset(conanfile)`.
user: SpaceIm
issue_12604: state: open
title: [feature] conan v2 tools: Expose `apple_min_version_flag` function
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Same rational than https://github.com/conan-io/conan/issues/12603. It's used in boost recipe, and current workaround is to indirectly get this value from `AutootolsToolchain.apple_min_version_flag`.
user: SpaceIm
issue_12602: state: open
title: failing test for check_cxx_source_compile()
body: Changelog: Omit
Docs: Omit

Follow up from https://github.com/conan-io/conan/pull/12600

Check the comments, it can be solved by using the full path, not targets (at least with CMake 3.15), so https://github.com/conan-io/conan/pull/12600 does not solve it either.
user: memsharded
issue_12600: state: open
title: change CMakeDeps xxx_LIBRARIES to be a list of libraries not targets
body: Changelog: Fix: change CMakeDeps xxx_LIBRARIES to be a list of libraries not targets
Docs: https://github.com/conan-io/docs/pull/XXXX

Attempt at:
https://github.com/conan-io/conan/issues/12012
https://github.com/conan-io/conan/issues/12180

Just a draft attempt to see if something breaks...
user: memsharded
issue_12597: state: open
title: [question] How to make rootfs libraries from toolchain package transparent
body: We are developing an application which is compiled for x86 and cross compiled for arm. The app has a lot of dependencies like for example `OpenCV`, which we now want to manage using conan. For the arm build we've already created a toolchain package containing the cross compiler toolchain and some libraries in a rootfs directory, which are produced during the build of our linux image of the embedded device. These libraries are coming from our SoC's vendor and are also depending for example on `OpenCV`, why its libraries are part of the rootfs as well. For the x86 build we want to completely rely on the `OpenCV` package which are available at conan center. For the application we are already using `CMakeToolchain` and `CMakeDeps` generator.

The problem we currently have is that in the applications `conanfile.py` we basically want to have 

```
    def requirements(self):
         self.requires("opencv/4.5.5")
```

which is absolutely fine for the x86 build because there we don't rely on these vendor libraries. But in context of arm I think it is a bad idea to link both the conan center `OpenCV` and the toolchains `OpenCV` (coming transitively from the vendors libraries) to our application. The only solution, which I can see here, is to only rely on the `OpenCV` library from the toolchain package.

The idea I have so far was to utilize somehow the `CMakeDeps` generator to normally produce for x86 build the *Config.cmake files inside the CMAKE_BINARY_DIR, which points to the `OpenCV` libraries in the conan cache and for the arm build I create custom *Config.cmake files inside the toolchain package, which points to the `OpenCV` libraries in the toolchain package. As far as I understand, I could use `cmake_build_modules` and `build_context_build_modules` properties to achieve this, so the `find_package` should work in both cases and I do not need to change anything in the CMakeLists.txt.

**My Question now is**: how can I tell conan to **not** generate the \*Config.cmake, which are provided by the toolchain package and how do I make the dependencies provided by the toolchain package transparent to conan?

I think the second part of the question is quite important because libraries like OpenCV have also dependencies to some very common libraries like zlib, which then must be part of the rootfs as well. Imagine there is a package libA, which depends on zlib too, then I want that the build for libA also uses the toolchains zlib and I want to be informed if there is a version conflict somewhere in my dependency graph. I think this can only be achieved when conan knows which libraries with which version are provided by the toolchain package, otherwise all the dependencies of the firmware libraries would become marshy and I'm again in the dependency hell. 

Maybe I'm over-complicating things, but I have the feeling that this must be a common use case to have some libraries be part of the rootfs in embedded systems and that there is already an obvious solution I'm missing.

Thank you very much in advance!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: nicosmd
issue_12596: state: open
title: [feature] Toolchain type of the package
body: From the following presentation I saw a new feature `package-type`: https://youtu.be/v5BMoW9wVg8?t=497

My suggestion is to add a new `package_type="toolchain"`. The reason is that although `package_type="application"` could be considered as `toolchain`, `toolchain` usually has additional standard utility like: `linker`, `objdump`, `debbuger` and etc., and it would be useful to distinguish between type of applications

Also in future `conan` could install toolchain and generate profile for installed toolchain, for example if toolchain was installed by `conan` the `conanfile.txt` could looks like:
```txt
[requires]
glfw/3.3.7
glew/2.2.0
glm/0.9.9.8

[generators]
cmake

[toolchain]
clang-17
```
And `conan` will figured out profile from toolchain name

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: redradist
issue_12589: state: open
title: [bug] conan info fails if a package was built with --require-override
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->
When building with the `--require-override` flag, `conan info` fails to get any information about the successfully-created package. I'd like to use this for our internal builds of libraries that are using outdated (and possibly CVE-impacted) versions of `openssl` or `zlib`. Ultimately, the solution is to update all of the recipes on conan-center to use the new versions of their dependencies, but as a stop-gap, I was hoping to use the override mechanism. Not having access to `conan info` on these packages is a hinderance.

### Environment Details (include every applicable attribute)
  * Ubuntu 18.04
  * gcc 7.5.0
  * Conan version: 1.54.0
  * Python version: 3.10.7

### Steps to reproduce (Include if Applicable)
1. Setup a local conan server as your only remote.
2. Use the conan-center-index recipes to build `openssl/1.1.1s`, and publish it to your remote.
3. Build `ldns/1.8.1` (which at the moment requires `openssl/1.1.1o`) with the command: `conan create ./conan-center-index/recipes/ldns/all ldns/1.8.1@ --require-override=openssl/1.1.1s`. The Build should succeed.
4. Now type `conan info ldns/1.8.1@`

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
openssl/1.1.1o: Retrieving from server 'myremote' 
openssl/1.1.1o: Trying with 'myremote'...
ERROR: Failed requirement 'openssl/1.1.1o' from 'ldns/1.8.1'
ERROR: openssl/1.1.1o was not found in remote 'myremote'
```
<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: jave27
issue_12587: state: open
title: [bug] Conan 2.0 editable packages with CMakeDeps
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version: gcc9 
  * Conan version: 2.0.0-beta5
  * Python version: 3.8.10

### Steps to reproduce (Include if Applicable)
I'm experimenting with using editable packages in conan 2.0beta5 and I'm having a few problems.  It's possible that I'm not using them correctly.  It feels to me like there is an odd mixing of an install directory with the conanfile directory.  I start with the following conanfiles.  

```
from conan import ConanFile
from conan.tools.cmake import cmake_layout

class T0Conan(ConanFile):
    name = "t0"
    version = "1.0.0"
    settings = "os", "compiler", "build_type", "arch"
    
    def layout(self):
        cmake_layout(self)

```
```
from conan import ConanFile
from conan.tools.cmake import cmake_layout

class T1Conan(ConanFile):
    name = "t1"
    version = "1.0.0"
    settings = "os", "compiler", "build_type", "arch"
    generators = "CMakeDeps"

    def requirements(self):
        self.requires("t0/1.0.0")

    def layout(self):
        cmake_layout(self)
```
I also have the following folder layout:
```
~/
  t0/
    conanfile.py
  t1/
    conanfile.py
```

I run the following commands:
```
conan editable add t0 t0/1.0.0
conan install t0
conan editable add t1 t1/1.0.0
coann install t1
```
On a real package I get an error that it can't find libraries from t0.
If I open, t1/build/generators/t0-release-x86_64-data.cmake  I can see:
```
set(t0_INCLUDE_DIRS_RELEASE "${t0_PACKAGE_FOLDER_RELEASE}/./include")
...
set(t0_LIB_DIRS_RELEASE "${t0_PACKAGE_FOLDER_RELEASE}/build/Release/.")
```
I think that the LIB_DIRS is being set incorrectly, but I'm new to editable packages and so I'm not sure the right way to do it.  I was assuming that using `cmake_layout` would set it properly.

Note that for a real package, I would also run a cmake command:`cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=generators/conan_toolchain.cmake -DCMAKE_INSTALL_PREFIX=<unknown_path_here>`

From reading the documentation for `conan editable add`, I would think that I would think that the CMAKE_INSTALL_PREFIX should match the path passed into the `conan editable add` command.

I am open to the idea that I am missing something, but I'm not sure what it would be.


### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: jsallay
issue_12579: state: open
title: I am trying to convert 1 particular component to conan 2.0, but I am facing some kind of issues.
body: These 3 are the errors I am getting

*ERROR: Error reading 'conan_profiles/x86_64' profile: ConfigParser: Unrecognized field 'build_requires'

*ERROR: Error loading conanfile at '/home/dibm/bird_routing/conanfile.py': Unable to load conanfile in /home/dibm/bird_routing/conanfile.py
  File "<frozen importlib._bootstrap_external>", line 728, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/dibm/bird_routing/conanfile.py", line 1, in <module>
    from conan import ConanFile, tools, AutoToolsBuildEnvironment, load
ImportError: cannot import name 'AutoToolsBuildEnvironment' from 'conan' (/home/dibm/.local/lib/python3.7/site-packages/conan/__init__.py)

*ERROR: Error reading 'conan_profiles/x86_64' profile: ConfigParser: Unrecognized field 'env'

user: disha123-bm
issue_12576: state: open
title: [bug] conan does full git submodule checkout to conan cache with "shallow" scm setting
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Linux
  * Compiler+version: n/a
  * Conan version: 1.53
  * Python version: 3.9

### Steps to reproduce (Include if Applicable)
* have a repo with a large submodule
* configure scm in a conanfile.py to have "shallow" flag on submodule
* run conan to check out this repo to conan cache (e.g. via conan install)
* check checked out repo: it has a full submodule checkout, not a shallow one

### Logs (Executed commands with output) (Include/Attach if Applicable)
n/a

### Fix
add "--depth=1" to the "submodule update --init" git call at https://github.com/conan-io/conan/blob/develop/conans/client/tools/scm.py#L221
user: insi-eb
issue_12501: state: open
title: [question] Documentation suggests settings_target is set to None with no build profile but the attribute does not exist
body: From: https://docs.conan.io/en/latest/systems_cross_building/cross_building.html#conan-v1-24-and-newer

> * self.settings_target: for recipes in the host context this attribute will be equal to None, for those in the build context, if will depend on the level of validation:
> 
>    * for recipes that are tool requirements of packages in the host context, this attribute will contain the settings from the profile profile_host, while
>    * for recipes that are tool requirements of other tool requirements the self.settings_target will contain the values of the profile_build.
> 

Writing a recipe which accesses `self.settings_target` in `configure()` causes an AttributeError if a build profile is not specified. I expected it to equal `None` instead of being unset. Although the text says it should be `None`, the example code below it uses `getattr()` to retrieve `self.settings_target` in case it is unset, and returns `None` in that case.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: joshvazquez-amzn
issue_12500: state: open
title: [bug] cmake generator ignores private requirements if build profile is set
body: ### Environment Details (include every applicable attribute)
  * Conan version: 1.54.0

Consider the following test recipe:
```
from conans import ConanFile

class TestConan(ConanFile):
    generators = "cmake"

    def requirements(self):
        self.requires("zlib/1.2.13", private=True)
```
Let's try to generate `conanbuildinfo.cmake` from it:
```
conan install .
```
The resulting `conanbuildinfo.cmake` contains something like
```
#################
###  ZLIB
#################
set(CONAN_ZLIB_ROOT "D:/.conan/data/zlib/1.2.13/_/_/package/6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7")
set(CONAN_INCLUDE_DIRS_ZLIB "D:/.conan/data/zlib/1.2.13/_/_/package/6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7/include")
set(CONAN_LIB_DIRS_ZLIB "D:/.conan/data/zlib/1.2.13/_/_/package/6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7/lib")
...
```
OK, good. Now explicitly set build profile:
```
conan install -pr:b=default .
```
and look into `conanbuildinfo.cmake`. No ZLIB settings! Why?

user: db4
issue_12497: state: open
title: [bug] can't pass a list to `self.run` when using `VCVars` generator
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->
Conan converts the list to a string and appends that to the vcvars script, which keeps the square brackets and commas in the command causing it to fail.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Conan version: 1.53.0
  * Python version: 3.10.5

### Steps to reproduce (Include if Applicable)
call `conan create` with the following recipe:

```python
class TestConan(ConanFile):
    name = "test"
    settings = "os", "arch", "compiler", "build_type"
    generators = "VCVars"

    def build(self):
        self.run([sys.executable, "--version"])
```

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
----Running------
> "C:\Users\dyitzchaki\.conan\data\test\2.0.221101.3\_\_\build\5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b\conanbuild.bat" && ['C:\\Users\\dyitzchaki\\github\\conan-center-index\\.venv\\Scripts\\python.exe', '--version']
-----------------
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.3.0
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
The filename, directory name, or volume label syntax is incorrect.
test/2.0.221101.3:
test/2.0.221101.3: ERROR: Package '5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b' build failed
<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->
```
user: dvirtz
issue_12489: state: open
title: [question] Export dependencies into a sysroot
body: I have a project which I compile and run in docker and uses several dependencies, which I managed by conan. Some of this dependencies are external libraries, but other are libraries developed internally, in my company. This dependencies are installed into the $HOME/.conan inside the container (which actually is a volume mapped to somewhere in my host). So far so great

However, I have tried to run `perf` to get a trace and here comes the problem. Since all the paths are related to the container, when I try to get a report in the host it basically can't find the libraries because they are not on the same path as they were recorded. I guess this will happen exactly the same if doing crosscompiling. 

I would like to know if there is anyway to ask conan to export the libraries into a sysroot, so I can tell perf where to find the libraries all at once, instead of having the specify the path of each dependency. 
user: jjcasmar
issue_12488: state: open
title: [question] How to prevent cmake from checking /usr/lib/x86_64-linux-gnu/cmake ?
body: I can't build the OpenAL package on my system because it finds 
`/usr/lib/x86_64-linux-gnu/cmake/PulseAudio/PulseAudioConfigVersion.cmake`
and then things fall apart due to cmake variables etc.

It shouldn't find that cmake file in the first place ... it was not asked to build with Pulse...

user: paulharris
issue_12487: state: open
title: [bug] conan 1.54.0 incorrectly reports wrong requires
body: I'll try and explain, and then we can narrow down the test case if required.

I have a (draft) recipe in the works for VTK, it requires `proj/9.0.1` and `sqlite3/3.38.5`
Note that VTK's recipe requires an older sqlite3

I have a recipe up for review for proj, it requires `sqlite3/3.39.4`
Note that proj requires the most recent sqlite3.

I am using the latest CCI recipe for QT it requires `sqlite3/3.39.2`
Note that this is a different sqlite3 version to the others, so we'll get a conflict.

My simple test recipe requires vtk, proj, and QT.
`requires = [ "qt/6.3.1", "vtk/9.1.0" ]`

I run this install command in my test recipe folder, with a few overrides to work around some irrelevant version issues:
`conan install . -if build --require-override openal/1.22.2 --require-override libffi/3.4.3`

The key part of the message I get is:
`'proj/9.0.1' requires 'sqlite3/3.38.5' while 'qt/6.3.1' requires 'sqlite3/3.39.2'.`
Full message below.

Note that `test <-- vtk <-- proj`
Technically, proj requires sqlite3/3.39.4.
It is VTK's recipe that is overriding proj's requirement to an older sqlite/3.38.5 (and requires it for itself).
But the error message reports that it is proj's fault.
This was very confusing to debug!

```
WARN: qt/6.3.1: requirement openal/1.22.1 overridden by test/1.0.0 to openal/1.22.2 
WARN: glib/2.73.3: requirement zlib/1.2.13 overridden by harfbuzz/4.4.1 to zlib/1.2.12 
WARN: glib/2.73.3: requirement pcre2/10.40 overridden by harfbuzz/4.4.1 to pcre2/10.37 
WARN: libxml2/2.9.14: requirement zlib/1.2.13 overridden by xkbcommon/1.4.1 to zlib/1.2.12 
WARN: wayland/1.20.0: requirement libffi/3.4.2 overridden by xkbcommon/1.4.1 to libffi/3.4.3 
WARN: vtk/9.1.0: requirement qt/6.2.4 overridden by test/1.0.0 to qt/6.3.1 
ERROR: Conflict in proj/9.0.1:
    'proj/9.0.1' requires 'sqlite3/3.38.5' while 'qt/6.3.1' requires 'sqlite3/3.39.2'.
    To fix this conflict you need to override the package 'sqlite3' in your root package.
```

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu Una / Mint 20.3
  * Conan version: 1.54.0
  * Python version: 3.8.10

user: paulharris
labels: component: ux: No changes to core business logic
issue_12481: state: open
title: Does a modification in the Conf section value result in a different profile?
body: We have 2 profile with similar settings but different compiler flags value inside conf section.

Our objective is to construct libraries using various combinations of compiler flags.

Issue faced :Changes to the value of the conf section are not recognized as changes to the profile.

could you please guild us how can we proceed?
user: himansu2906
issue_12478: state: open
title: [feature] CMake integration: proof of concept of sysroot + CMakeDeps priority
body: It is not fully clear, maybe not enough tested:

- A vendor tool, like Android or similar, that could come in a Conan package, and that provides its toolchain.cmake file with the details how to use it.
- That toolchain might contain some libraries
- There are also Conan packages, that via CMakeDeps can be found
- But also some other packages should be found in the sysroot of the vendor toolchain

What would be the best way to integrate? The ``conan_toolchain.cmake`` can include the vendor toolchain.cmake, or an intermediate one from the user, but does this guarantee behavior if the vendor toolchain changes priorities of CMake for finding package only in itself?


cc / @maikelvdh 
user: memsharded
issue_12476: state: open
title: [bug] conan 1.x vs 2.x differences in new compatibility() method vs package_id() method
body: https://docs.conan.io/en/latest/migrating_to_2.0/recipes.html#migrate-conanfile-compatible-packages-to-the-new-compatibility-method recommends migrating recipes from package_id: ... self.compatible_packages.append to the new compatibility() method even in 1.x

However, the behavior of 1.53 and 2.0.0-beta4 do not match, and the 1.x implementation does not seem to be viable if the package has anything non-default going on in its package_id method, e.g. the sort of things shown at https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html?highlight=defining%20abi#defining-a-custom-package-id like deleting options/subsettings, or assigning broader category strings before hashing.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 20H2
  * Conan version: 1.53.0 / 2.0.0-beta4
  * Python version: 3.10.7

### Steps to reproduce (Include if Applicable)

<details>
<summary>conanfile.py</summary>

```python
from conan import ConanFile

class TestConanFile(ConanFile):
    name = "test"
    version = "0.1"

    options = {
        "compat": ["A", "B", "AB"],
        "info_only": [1,2],
    }

    default_options = {
            "compat": "A",
            "info_only": 1,
    }

    def compatibility(self):
        if self.options.compat == "A" or self.options.compat == "B":
            return [
                    {"options":[
                        ("compat","AB"),
#                      ("info_only",None),
                    ]},
            ]

    def package_id(self):
#        self.output.info("package_id: %s" % self.info.dumps())
        del self.info.options.info_only # option that only affects package_info and doesn't produce a separate package_id
```
</details>

`options.info_only` represents something that would affect package_info but can be disregarded by package_id. E.g. something like [`no_main` in conancenter's gtest package](https://github.com/conan-io/conan-center-index/blob/53701c8d799efbea53aac76528b9cf0cc660d569/recipes/gtest/all/conanfile.py#L85).

### Logs (Executed commands with output) (Include/Attach if Applicable)

`conan export-pkg conanfile.py -o compat=AB`
> test/0.1: Package '2a1d269613fc54bcec85cbcd305de9a83c570bc2' created

`conan info test/0.1@ -o compat=A`
> ID: d11f361b89caf2b5d6f08e4f72c5d2d1b0b4783e

d11f361b89caf2b5d6f08e4f72c5d2d1b0b4783e doesn't exist, and it failed to find the compatible package 2a1d269613fc54bcec85cbcd305de9a83c570bc2 with `options.compat=AB` (despite the compatibility() method). Sticking a `print(compat_info.package_id())` into [_compatible_infos](https://github.com/conan-io/conan/blob/3e08841b55bd7bb83af31d212774b998add503f1/conans/client/graph/compatibility.py#L33) shows that it looked for 51c2ac4602637ed8f01dad0cb6dce1e97f511eea, which would be the hash of a package with compat=AB and info_only=1. But such an id will never exist, because of `package:id(self): del self.info.options.info_only`.

2.0.0-beta4 works:

`conan2 export-pkg conanfile.py -o compat=AB`
`conan2 graph info --require test/0.1 -o compat=A`
> test/0.1: Main binary package 'c9e7469bb04284f8b9e4bb45ea02dd49ddeb848b' missing. Using compatible package '6cbd7cce3e41ee00df89053dfb6e615f18749c3c'

Uncommenting the self.output call in package_id shows that conan 1.53.0 calls package_id(self) for the main binary package, but not for the alternatives it constructed from the tuples returned by compatibility(). Thus, if the package_id deletes or modifies values in `self.info`, no return value from `compatiblility()` would match binary packages that could actually exist.

conan 2.0.0-beta4 calls package_id multiple times (for each info object being considered), computes the correct hashes, and finds the expected match.

Doing things the old way (with self.compatible_packges.append in the package_id method) can work as long as the correct modifications are performed (in this case, simply a matter of doing the `info.clone()` after the `del self.info.options.info_only`)

It does not seem to be possible to make this work even extra with manual care to account for package_id; e.g. uncommenting the `("info_only",None),` tuple errors out showing the values from compatibility are being validated as if they were the initially-bound option values, rather than contents for the `self.info` object.
> ERROR: 'None' is not a valid 'options.info_only' value.
> Possible values are ['1', '2']

2.0 does not seem to perform this validation, and will quietly allow compatibility() to return invalid option values that are passed through to self.info as-is (which package_id can then change further before hashing).

So it seems like neither 1.53.0 nor 2.0.0-beta4 are being consistent here about whether [the return tuple values `compatibility()`](https://docs.conan.io/1/reference/conanfile/methods.html#method-compatibility) are meant to be self.options or self.info.options. 1.53.0 is validating it like --options input from the profile. but then not calling package_id to translate it before hashing. 2.0.0-beta4 is *not* validating the options, but *is* passing through the (possibly-invalid) values when it invokes self.package_id. And the documentation doesn't really say either way which interpretation is intended.

user: puetzk
issue_12471: state: open
title: Parallel build failures due to Conan config install
body: Hello, We are running multiple builds in parallel using Jenkins. Each of the child jobs (running builds) leverage Conan to consume package from the Artifactory Conan repo. These builds are failing randomly with the below error. 

ERROR: Failed conan config install: [Errno 17] File exists: '/home/bangbuild/.conan/tmp_config_install'

Do we have a way to fix this?
user: mkjkec2005
issue_12469: state: open
title: [bug] conan lock does not include default user & channel
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

Creating a lockfile using `conan lock create` ignores the user and channel if the `default_user` and `default_channel` attributes are set. All the other information (name, version) is taken from the conanfile.

My current workaround is reading the values using `conan inspect` from the recipe before and supplying it with the parameters `--user` and `--channel`. This works but seems to be a little bit inconvenient and increases the execution time because of the two additional commands.

### Environment Details (include every applicable attribute)
  * Conan version: 1.53.0
  * Python version: 3.8.8

### Steps to reproduce (Include if Applicable)
- conanfile.py with `default_channel` & `default_user` attributes
- call `conan lock create`

user: codetent
issue_12467: state: open
title: [question] Unable to cross-compile a package using Clang
body: Hello, I'm developing a cross-platform C++ library using CMake, Ninja, Clang, and Conan. I've been able to cross-compile the library for Linux (from Windows) with a [prebuilt Ubuntu toolchain](https://gnutoolchains.com/ubuntu/). However, I've encountered problems while trying to add a Conan package. For a test, I've included [fmt](https://conan.io/center/fmt) and [zlib](https://conan.io/center/zlib) packages:

*conanfile.txt*
```
[requires]
zlib/1.2.13
fmt/9.0.0

[generators]
cmake

[options]
zlib:shared=True
fmt:shared=True
```

I've also created two Conan profiles:

*clangwindows*
```
[settings]
os=Windows
arch=x86_64
compiler=clang
compiler.version=14
build_type=Release

[env]
CC=clang
CXX=clang++
CONAN_CMAKE_GENERATOR=Ninja

[conf]
tools.cmake.cmaketoolchain:generator=Ninja
```

*clanglinux*
```
[settings]
os=Linux
arch=x86_64
compiler=clang
compiler.version=14
build_type=Release

[env]
CC=clang
CXX=clang++
CONAN_CMAKE_GENERATOR=Ninja
CONAN_CMAKE_SYSROOT="C:/path/to/ubuntu/toolchain/x86_64-linux-gnu/sysroot"

[conf]
tools.cmake.cmaketoolchain:generator=Ninja
```

When I try to build the fmt package with command: `conan install . --build=fmt -pr:h=clanglinux -pr:b=clangwindows` it fails with the following error:
```
CMake Error at CMakeLists.txt:231 (add_library):
  The install of the fmt target requires changing an RPATH from the build
  tree, but this is not supported with the Ninja generator unless on an
  ELF-based or XCOFF-based platform.  The CMAKE_BUILD_WITH_INSTALL_RPATH
  variable may be set to avoid this relinking step.
```

And if I try to build the zlib package with `conan install . --build=zlib -pr:h=clanglinux -pr:b=clangwindows`, it fails with:
```
[16/17] Linking C shared library libz.so.1.2.13
FAILED: libz.so.1.2.13 
cmd.exe /C "cd . && C:\PROGRA~1\LLVM\bin\clang.exe -m64  -m64  -Wl,--version-script,"C:/Users/mirko.braic/.conan/data/zlib/1.2.13/_/_/build/07325ef95da875475b9effafa9aab72ba975b954/src/zlib.map" -shared -Wl,-soname,libz.so.1 -o libz.so.1.2.13 CMakeFiles/zlib.dir/adler32.c.o CMakeFiles/zlib.dir/compress.c.o CMakeFiles/zlib.dir/crc32.c.o CMakeFiles/zlib.dir/deflate.c.o CMakeFiles/zlib.dir/gzclose.c.o CMakeFiles/zlib.dir/gzlib.c.o CMakeFiles/zlib.dir/gzread.c.o CMakeFiles/zlib.dir/gzwrite.c.o CMakeFiles/zlib.dir/inflate.c.o CMakeFiles/zlib.dir/infback.c.o CMakeFiles/zlib.dir/inftrees.c.o CMakeFiles/zlib.dir/inffast.c.o CMakeFiles/zlib.dir/trees.c.o CMakeFiles/zlib.dir/uncompr.c.o CMakeFiles/zlib.dir/zutil.c.o   && cd ."
LINK : warning LNK4044: unrecognized option '/-version-script'; ignored
LINK : warning LNK4044: unrecognized option '/soname'; ignored
C:\Users\mirko.braic\.conan\data\zlib\1.2.13\_\_\build\07325ef95da875475b9effafa9aab72ba975b954\src\zlib.map : fatal error LNK1107: invalid or corrupt file: cannot read at 0x611
clang: error: linker command failed with exit code 1107 (use -v to see invocation)
ninja: build stopped: subcommand failed.
zlib/1.2.13: 
zlib/1.2.13: ERROR: Package '07325ef95da875475b9effafa9aab72ba975b954' build failed
zlib/1.2.13: WARN: Build folder C:\Users\mirko.braic\.conan\data\zlib\1.2.13\_\_\build\07325ef95da875475b9effafa9aab72ba975b954\build\Debug
ERROR: zlib/1.2.13: Error in build() method, line 90
        cmake.build()
        ConanException: Error 1 while executing cmake --build "C:\Users\mirko.braic\.conan\data\zlib\1.2.13\_\_\build\07325ef95da875475b9effafa9aab72ba975b954\build\Debug" -- -j8
```

Is there something I'm doing wrong or is there some incompatibility with Conan/Clang and the packages I'm trying to cross-compile? I'm having difficulties understanding the root cause of the issue.

### Environment Details
  * Windows 10, 20H2
  * Clang 14.0.5
  * Conan 1.53.0
  * CMake 3.24.0
  * Ninja 1.10.2
  * Python 3.10.5
user: mirkobraic
issue_12466: state: open
title: Is workspace feature supported in Conan 2.0?
body: Hi,

Is workspace feature supported in Conan 2.0? Kindly clarify. 
As per the stack overflow, The workspace feature is deprecated, the recommended approach is to use editables directly. 
It is also mentioed that workspace is not a good option. 

https://stackoverflow.com/questions/73607834/conan-add-local-project-as-dependency
user: mkjkec2005
issue_12465: state: open
title: [bug] Setting `conan_home` in `.conanrc` to just `.` for current directory fails
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

I want to have a github repo with all of my config files in the root so it's each so show the layout.
My frame of of reference for my expectations https://github.com/conan-io/conan/pull/11675

> Set the conan home to a relative folder inside the current folder
> ```
> # accepts comments
> conan_home=./relative folder/inside current folder
> ```

I was expect to set just `.` for the current directory

### Environment Details (include every applicable attribute)
  * Operating System+version: Macos 
  * Compiler+version:
  * Conan version: 2.0.0-beta4
  * Python version: 3.10

### Steps to reproduce (Include if Applicable)


1. With new line
```sh
echo "conan_home=.\n" > .conanrc
conan config home
```


2. no line ending
```sh
echo "conan_home=." > .conanrc
conan config home
```


```


### Logs (Executed commands with output) (Include/Attach if Applicable)

1. with new line
```sh
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.10/bin/conan", line 33, in <module>
    sys.exit(load_entry_point('conan==2.0.0b4', 'console_scripts', 'conan')())
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/conans/conan.py", line 7, in run
    main(sys.argv[1:])
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/conan/cli/cli.py", line 211, in main
    conan_api = ConanAPIV2()
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/conan/api/conan_api.py", line 33, in __init__
    self.cache_folder = cache_folder or get_conan_user_home()
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/conans/paths/__init__.py", line 42, in get_conan_user_home
    user_home = _user_home_from_conanrc_file() or os.getenv("CONAN_HOME")
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/conans/paths/__init__.py", line 30, in _user_home_from_conanrc_file
    values = {k: str(v) for k, v in
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/conans/paths/__init__.py", line 30, in <dictcomp>
    values = {k: str(v) for k, v in
ValueError: not enough values to unpack (expected 2, got 1)
```

2. no line ending
```sh
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.10/bin/conan", line 33, in <module>
    sys.exit(load_entry_point('conan==2.0.0b4', 'console_scripts', 'conan')())
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/conans/conan.py", line 7, in run
    main(sys.argv[1:])
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/conan/cli/cli.py", line 211, in main
    conan_api = ConanAPIV2()
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/conan/api/conan_api.py", line 33, in __init__
    self.cache_folder = cache_folder or get_conan_user_home()
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/conans/paths/__init__.py", line 49, in get_conan_user_home
    raise Exception("Invalid CONAN_HOME value '%s', "
Exception: Invalid CONAN_HOME value '.', please specify an absolute or path starting with ~/ (relative to user home)
```
user: prince-chrismc
labels: component: ux: No changes to core business logic
issue_12461: state: open
title: [feature] Make cmake_layout available from only one place
body: For now, we can import `cmake_layout` from both points:

- from conan.tools.layout import cmake_layout
- from conan.tools.cmake import cmake_layout

The documentation is inclined to use `cmake` only: https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmake_layout.html

However, importing from `conan.tools.layout` does not result in errors, nor warnings, but is not documented.

It would be great if was possible to import only from `cmake` module, to avoid prone errors.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: uilianries
issue_12456: state: open
title: [feature] Add support for TASKING compilers
body: > The settings.yml file is not perfect nor definitive and surely incomplete. Please share any suggestion in the Conan issue tracker with any missing settings and values that could make sense for other users.

Now that CMake 3.25 has [added built-in support for TASKING compilers](https://cmake.org/cmake/help/latest/release/3.25.html#id6), I think it also makes sense for Conan to support them.  I realise it is possible to extend `settings.yml` on my own, but cross-compilers for embedded systems are a bit trickier and users may implement it differently (which becomes a big problem when it comes to delivery between supplier and customer).  Therefore, I would propose that Conan offer an official solution.

As an example of the difficulties, I am currently facing issues because Conan sets CMAKE_SYSTEM_PROCESSOR based on `arch`, but CMake uses CMAKE_SYSTEM_PROCESSOR to select a CPU device (see [here](https://gitlab.kitware.com/cmake/cmake/-/issues/24115)).  I expect some collaboration is needed between both parties to get it right.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: GordonJess
issue_12452: state: open
title: [question] msvc_compatible() is not enough sometimes?
body: I'm trying to use boost package from CCI with `msvc` compiler (actually I have this problem with my own packages, but boost is good for demonstrating it) . Conan fails to find the (compatible) binary:
```
conan install boost/1.75.0@ -s compiler=msvc -s compiler.version=191 -s compiler.cppstd=14 -s compiler.runtime=dynamic

Configuration:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=191
os=Windows
[options]
[build_requires]
[env]

bzip2/1.0.8: Main binary package '040d0e3492940cd304bdcec8aa9d664c2054639c' missing. Using compatible package '5be2b7a2110ec8acdbf9a1cea9de5d60747edb34'
zlib/1.2.13: Main binary package '007a990a617b175b37992961a850c5c3b07260b3' missing. Using compatible package '6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7'
Installing package: boost/1.75.0
Requirements
    boost/1.75.0 from 'conancenter' - Cache
    bzip2/1.0.8 from 'conancenter' - Cache
    zlib/1.2.13 from 'conancenter' - Cache
Packages
    boost/1.75.0:660f4ef44f652d2ba7f74a79487832fd00a5a488 - Missing
    bzip2/1.0.8:5be2b7a2110ec8acdbf9a1cea9de5d60747edb34 - Cache
    zlib/1.2.13:6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7 - Cache

Installing (downloading, building) binaries...
ERROR: Missing binary: boost/1.75.0:660f4ef44f652d2ba7f74a79487832fd00a5a488
boost/1.75.0: WARN: Can't find a 'boost/1.75.0' package for the specified settings, options and dependencies:
- Settings: arch=x86_64, build_type=Release, compiler=msvc, compiler.cppstd=14, compiler.runtime=dynamic, compiler.runtime_type=Release, compiler.version=191, os=Windows
- Options: asio_no_deprecated=False, buildid=None, bzip2=True, debug_level=0, diagnostic_definitions=False, error_code_header_only=False, extra_b2_flags=None, filesystem_no_deprecated=False, filesystem_version=None, header_only=False, i18n_backend=deprecated, i18n_backend_iconv=off, i18n_backend_icu=False, layout=system, lzma=False, magic_autolink=False, multithreading=True, namespace=boost, namespace_alias=False, numa=True, pch=True, python_executable=None, python_version=None, segmented_stacks=False, shared=False, system_no_deprecated=False, system_use_utf8=False, visibility=hidden, without_atomic=False, without_chrono=False, without_container=False, without_context=False, without_contract=False, without_coroutine=False, without_date_time=False, without_exception=False, without_fiber=False, without_filesystem=False, without_graph=False, without_graph_parallel=True, without_iostreams=False, without_json=False, without_locale=False, without_log=False, without_math=False, without_mpi=True, without_nowide=False, without_program_options=False, without_python=True, without_random=False, without_regex=False, without_serialization=False, without_stacktrace=False, without_system=False, without_test=False, without_thread=False, without_timer=False, without_type_erasure=False, without_wave=False, zlib=True, zstd=False, bzip2:build_executable=True, bzip2:shared=False, zlib:shared=False
- Dependencies: zlib/1.2.13, bzip2/1.0.8
- Requirements: bzip2/1.Y.Z, zlib/1.Y.Z
- Package ID: 660f4ef44f652d2ba7f74a79487832fd00a5a488

ERROR: Missing prebuilt package for 'boost/1.75.0'
Use 'conan search boost/1.75.0@ --table=table.html -r=remote' and open the table.html file to see available packages
Or try to build locally from sources with '--build=boost'

More Info at 'https://docs.conan.io/en/latest/faq/troubleshooting.html#error-missing-prebuilt-package'
```
Why so? And how to debug such errors? `conan install boost/1.75.0@ -s compiler="Visual Studio" -s compiler.version=15` succeeds:
```
Configuration:
[settings]
arch=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=15
os=Windows
[options]
[build_requires]
[env]

Installing package: boost/1.75.0
Requirements
    boost/1.75.0 from 'conancenter' - Cache
    bzip2/1.0.8 from 'conancenter' - Cache
    zlib/1.2.13 from 'conancenter' - Cache
Packages
    boost/1.75.0:8d47612c404bfb3cc5b267708e639b6b2cda0c3a - Cache
    bzip2/1.0.8:5be2b7a2110ec8acdbf9a1cea9de5d60747edb34 - Cache
    zlib/1.2.13:6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7 - Cache

Installing (downloading, building) binaries...
bzip2/1.0.8: Already installed!
bzip2/1.0.8: Appending PATH environment variable: D:\.conan\data\bzip2\1.0.8\_\_\package\5be2b7a2110ec8acdbf9a1cea9de5d60747edb34\bin
zlib/1.2.13: Already installed!
boost/1.75.0: Already installed!
boost/1.75.0: Disabled magic autolinking (smart and magic decisions)
Aggregating env generators
```
user: db4
issue_12451: state: open
title: [question] How do i debug a library locally which is published as a conan library.
body: First of all, thank you for reading this issue.

【Background】
We have publish some libraries by use Conan and integrate them in out project. The following description is the way we used.

1. Publish Step:
         * We use google GN to build our codes to the binary library and then upload to cloud and write the library url in conanfile.py, so that when we execute `conan install xxxx`, we could download them to finish the conan "build" step. 
         * publish it use conan command. (Now here we call this library as "LibA"
2. Usage Step:
         * when install this LibA, in conanfile.py, we unzip the download file and use "package" method to finish "package" step，finally use conan "package_info" method to describe LibA

So far, everything is fine. But sometimes, we may have some problems, and finally locate the issue is in LibA, **we hope we can easy to debug at this time, it is really needed to debug with source codes(source code is in a folder on local computer) and even more we hope we can modify local codes, then recompile&regenerate the library in local source path, and easy to rebuild our application to use the modified code logic.**

【Question】
As i am ever a iOS developer, i try to find a way to debug like CocoaPods, just change the podspec location(in Podfile) to a local path(which contain the same podspec file), then we could begin the debug workings.
I find there exist some solutions like conan editable package, which is very like the CocoaPods debug solution. But i have some issues to use it.

1. I think when conan install, we finally use package_info() to describe the library in the package folder, so no matter how i build the library, i finally to put them in a folder like the "package folder", and hope when i run conan install command, conan will collect these informations to use conan generators to generate(like xxx.cmake file for cmake, like xxx.xcconfig for xcode, or like BUILD.gn for custom GN generator). So that we could link the new local libraries to debug. **How can i easy to do this? layout method seem need to set lots attribute for build, but i only want build by my self. **

2. If the library is a static library, it is easy to linked by the generated information which is integrated in application project(even use a conan path, i known we use imports section in conanfile.txt, but it is only working when execute conan install). **But if it is a dynamic library, how can i copy them to a specific path automatically by conanfile.py when in debug mode?** I don't want to copy manually every time i modify&rebuild the local codes.


user: initlifeinc
issue_12447: state: open
title: [question] Handling multiple package setting/option variations in single CMake build
body: Hi,
We would like to use Conan to install dependencies for a large CMake project using the CMakeDeps / CMakeToolchain. Currently a single build invocation of the project produces many individual binaries which are packaged into an installer.

Some of these binaries have dependencies on different setting/option variations of a Conan package. For example: On Windows several built executables use shared Boost libraries and the dynamic VS runtime while some libraries (installer custom actions) need to be statically linked against Boost and the VS runtime.

In the past for other projects built with VS solutions we invoked `conan install` multiple times to install the package variations into different directories (VS property sheet generator) and included the correct property sheets as required in individual VS projects. This way we could build the VS solution once to produce all the binaries without having to switch configurations, etc.

Is there a way to gracefully implement something similar in Conan/CMake without having to invoke CMake build multiple times?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: kielby
issue_12436: state: open
title: [bug] Error when trying to fix corrupted package
body: ### Issue
When building a project, I happened to get a warning about a corrupted package.
Then conan throws an error while trying to remove the package.

### Environment Details
  * OS: Windows 10 10.0.19044 Build 19044
  * Compiler+version: Run from visual studio, CPPSTD=17, runtime=MDd, toolset = v142, version=16
  * Conan version: 1.53.0, (first tried with 1.50.2)
  * Python version: 3.7.8

### Logs
```
1>  boost/1.73.0: WARN: Package binary is corrupted, removing: 524ea35a8120baabdde02483add58d81bf541327
1>  boost/1.73.0: WARN: Build folder is dirty, removing it: C:\.conan\4ef6cc\1
1>  boost/1.73.0: WARN: Trying to remove corrupted source folder
1>  boost/1.73.0: WARN: This can take a while for big packages
1>EXEC : error : boost/1.73.0: Error in source() method, line 565
1>  	apply_conandata_patches(self)
1>  	FileNotFoundError: [Errno 2] No such file or directory: 'C:\\.conan\\707a25\\1\\patches/boost_locale_fail_on_missing_backend.patch'
```

I updated to latest conan version, same issue.

### Workaround
Afterwards, I ran:
`conan remove boost` to delete the corrupted package manually.

The build then succeeded.




user: DLPalindrome
issue_12432: state: open
title: [question] When to specify which `compiler.runtime_version` settings of Clang compilers?
body: ### Problem Description

According to this [article](https://dev.to/yumetodo/list-of-mscver-and-mscfullver-8nd), there are 4 types of version with MSVC compilers. And the corresponding table is like the following. It seems that `compiler.runtime_version` is related to **MSVC toolset version**. I was wondering what value of `compiler.runtime_version` should I specify for Clang compilers?

| VC version | `_MSC_VER` macro | Visual Studio | MSVC toolset version |
| ---------- | ---------------- | ------------- | -------------------- |
| 8.0  | 1400 | 2005 | 80  |
| 10.0 | 1500 | 2008 | 90  |
| 11.0 | 1600 | 2010 | 100 |
| 12.0 | 1700 | 2012 | 110 |
| 13.0 | 1800 | 2013 | 120 |
| 14.0 | 1900 | 2015 | 140 |
| 15.0 | 1910~1919 | 2017 | 141 |
| 16.0 | 1920~1929 | 2019 | 142 |
| 17.0 | 1930~1939 | 2022 | 143 |

![image](https://user-images.githubusercontent.com/71438617/199062022-63fa0e33-cd11-4200-9eac-df61c3693729.png)


user: hwhsu1231
issue_12429: state: open
title: [bug] compiling automake fails on macOS if "--profile:build" is specified
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details
  * Operating System+version: macOS 12.6 (Apple silicon)
  * Compiler+version: Apple clang version 13.1.6 (clang-1316.0.21.2.5)
  * Conan version: 1.53.0
  * Python version: 3.8.9

### Steps to reproduce (Include if Applicable)
* Create and use the new empty `CONAN_USER_HOME`: `export CONAN_USER_HOME=$PWD/local-conan-home`
* From conan-center-index root, invoke `conan create recipes/automake/all/ 1.16.5@ --profile:host default --profile:build default`
-> This command fails with
```
configure: error: Autoconf 2.65 or better is required.
    Please make sure it is installed and in your PATH.
```

Interestingly, the command succeeds if I remove `--profile:build default` from the invocation.

### Logs (Executed commands with output) (Include/Attach if Applicable)

Full output of the command can be found here: https://gist.githubusercontent.com/mkoviazin/f9392089e71492922c020dc4a4194055/raw/72d333f39c2da394397aa2bf260639c0e86c9db5/gistfile1.txt

### Additional notes
* While testing it to report, I noticed thatthe issue is somewhat random. Sometimes this check does succeed, sometimes it doesn't. For me it takes a couple of attempts to trigger this failure. And the sequence of commands is always the same: remove the folder `CONAN_USER_HOME` points to and then call `conan create`
* I can't reproduce the issue when `--profile:build` is not specified
* On custom Conan remote, the issue seems to be reproduced more consistently. Omitting `--profile:build` from the invocation seems to fix the issue there as well

I could not check that with Conan2 since the recipe uses `conans` module.
user: ghost
issue_12424: state: open
title: [question] How to specify settings of Clang (GNU-like) and ClangCL (MSVC-like), respectively?
body: ### Problem Description

As we already know, there are basically two types of Clang compilers on Windows platform:

- `clang.exe/clang++.exe`: **GNU-like** CLI Clang.
- `clang-cl.exe`: **MSVC-like** CLI Clang.

According to the [article](https://blog.conan.io/2022/10/13/Different-flavors-Clang-compiler-Windows.html) of Conan Blog, there are two example Conan Profiles, **llvm_clang.profile** and **vs_clang.profile**:

- **llvm_clang.profile**

  <details><summary>Click to expand</summary>

  ```ini
  [settings]
  os=Windows
  arch=x86_64
  build_type=Release
  compiler=clang
  compiler.version=13
  compiler.cppstd=gnu14
  compiler.runtime=dynamic
  compiler.runtime_type=Release
  compiler.runtime_version=v143
  
  [buildenv]
  PATH=+(path)C:/ws/**LLVM/Clang**13/bin
  PATH+=(path)C:/ws/msys64/mingw64/bin
  
  [conf]
  tools.env.virtualenv:auto_use=True
  ```

  </details>

- **vs_clang.profile**

  <details><summary>Click to expand</summary>

  ```ini
  [settings]
  os=Windows
  arch=x86_64
  build_type=Release
  compiler=clang
  compiler.version=14
  compiler.cppstd=gnu14
  compiler.runtime=dynamic
  compiler.runtime_type=Release
  compiler.runtime_version=v143
  
  [conf]
  tools.env.virtualenv:auto_use=True
  tools.cmake.cmaketoolchain:generator=Visual Studio 17
  ```

  </details>

However, it seems that they are the **SAME** in terms of **[settings]** section. Does that mean these two types of Clang should use the **SAME** settigns? If not, then what settings should they specify, respectively?

### Screenshots

![image](https://user-images.githubusercontent.com/71438617/198861070-9b9cd835-8d8c-4e95-8b77-e0d74407ff9c.png)
![image](https://user-images.githubusercontent.com/71438617/198861099-2ff83b54-e8b7-4da5-a91f-29749250f704.png)


user: hwhsu1231
issue_12423: state: open
title: [bug] Periodic issues building packages with exported sources
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: multiple
  * Compiler+version: multiple
  * Conan version: 1.53.0 and others
  * Python version: 3.7+

### Steps to reproduce (Include if Applicable)
Somewhat vague, sorry, but I'm not sure how to dig more (it doesn't help that when this occurs, we have a work around and the machine is broken until we apply the work around).

- do a conan install of a package that has to build some dependency (in this case called assure) that has exported source but for which a binary package was previously downloaded.
- we get failures around not finding CMakeLists.txt
- deleting the local copy of the package (with `conan rm packagename\*`) causes the problem to go away next time we bound

We have seen this intermittently with various package, mostly ones from conancenter. I'm not 100% sure they all have exported sources, but I think they do. And I have a theory that exported sources don't always travel with packages when binary packages are fetched, which means one can end up with a broken local, or artifactory state.

It could be something with packages moving to the new CMake helpers too (there is a line in the log below about cmake presets). 

### Logs (Executed commands with output) (Include/Attach if Applicable)

`conan install path repo@velo3d/stable -g cmake -if path/to/build --build missing -pr path/to/conanprofile.txt`

Output
```
[2022-10-28T22:37:02.510Z] grpc/1.48.0: Already installed!
[2022-10-28T22:37:02.510Z] grpc/1.48.0: Appending PATH environment variable: /root/.conan/data/grpc/1.48.0/_/_/package/c42bd9ca8f14bb0dd1d1d204c655ddd445ac95c6/bin
[2022-10-28T22:37:02.510Z] assure/1.0.87@velo3d/stable: Copying sources to build folder
[2022-10-28T22:37:02.510Z] assure/1.0.87@velo3d/stable: Building your package in /root/.conan/data/assure/1.0.87/velo3d/stable/build/56ceefe04457be084f7b309814be85efbce59709
[2022-10-28T22:37:02.510Z] assure/1.0.87@velo3d/stable: Generator cmake_find_package created FindBoost.cmake
...
[2022-10-28T22:37:02.510Z] assure/1.0.87@velo3d/stable: Generator cmake_find_package created FindOpenSSL.cmake
[2022-10-28T22:37:02.510Z] assure/1.0.87@velo3d/stable: Generator cmake created conanbuildinfo.cmake
[2022-10-28T22:37:02.510Z] assure/1.0.87@velo3d/stable: Calling generate()
[2022-10-28T22:37:02.510Z] assure/1.0.87@velo3d/stable: Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
[2022-10-28T22:37:02.510Z] assure/1.0.87@velo3d/stable: If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/root/.conan/data/assure/1.0.87/velo3d/stable/build/56ceefe04457be084f7b309814be85efbce59709/build/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
[2022-10-28T22:37:02.510Z] assure/1.0.87@velo3d/stable: Aggregating env generators
[2022-10-28T22:37:02.510Z] assure/1.0.87@velo3d/stable: Calling build()
[2022-10-28T22:37:02.510Z] CMake Error: The source directory "/root/.conan/data/assure/1.0.87/velo3d/stable/build/56ceefe04457be084f7b309814be85efbce59709" does not appear to contain CMakeLists.txt.
```

conanfile bits
```
    exports_sources = ("CMakeLists.txt", "cmake/*", "src/*", "include/*",
                       "../../protos*", "../../tools*", "../../constants*", "3rdparty/ftpclient-src/*")

    generators = ["cmake", "cmake_find_package"]

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()

    def build(self):
        cmake = CMake(self)
       ...
        cmake.configure()
        cmake.build()
```
user: drussel
issue_12420: state: open
title: [question] About cmake.configure()
body: I am currently using conan 2.0, and it seems like in previous versions the `CMake.configure()` function allowed you to specify the build folder via the `build_folder` parameter. This parameter has been deprecated in version 2.0 and I wanted to know if there is still any way to specify which directory CMake will produce the build.

I know that the N configurations -> 1 package approach is discouraged, but my motivation behind this question is so that I can set up a single conan package that has subfolders for every different type of configuration. It would make my life easier if I could achieve this because the project I am working on expects this kind of structure.

Thanks

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: hamham240
issue_12419: state: open
title: [question] [2.0] Cmake.ctest missing libraries
body: For some background, I'm building a package that depends on gnuradio which complicates things in itself.

When trying to run cmake(self).ctest after a successful build, none of the dependency libraries are available. This is all being done in the build method of the recipe. I can make things work by adding the cmake path to the run environment and running ctest in the conanrunenv.

From looking at conan.tools.cmake.cmake it doesn't look like the test call is made aware of the toolchain or other build settings. What is the intended use of ctest? Should I be running ctest in a different area of the recipe? 

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: beenjohn
issue_12416: state: open
title: [bug] KeyError: 'cmake' when having both CMake and cmake packages in the cache
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: open suse leap 15.3
  * Compiler+version: gcc7
  * Conan version: 1.40.4
  * Python version: 3.6

### Steps to reproduce (Include if Applicable)

We use an internal cmake package in our organisation and, unfortunatelly, called it `CMake`. For the transition to conan 2.0 we need to start using a lower-case package `cmake` and update all dependencies. I've started this process and discovered an interesting behaviour of conan.

I have `PkgA -> PkgB -> CMake`. PkgA also depends on other packages not requiring cmake. When I run `conan info PkgA` having  lower-case cmake already in the cache I get a key error. If I remove the lower-case cmake from the cache it works. Noteable, the package still depends on the upper-case variant. So even not being part of the dep-tree, lower-case cmake has an influance on the conan info command. Another observation is, that conan is not fetching `CMake` from our remote in this case.

Having `PkgD->CMake` conan info will fetch it and the command works altough lower-case cmake is in the cache.

For the transistion to conan 2.0 I think it is quite likely to have both version in the cache. So at least conan should give some meaningful error such as https://docs.conan.io/en/latest/faq/troubleshooting.html?#error-requested-a-package-but-found-case-incompatible

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
> conan search cmake
Existing package recipes:

cmake/3.24.1@3rdparty/stable

> conan info PkgA
[no fetch of CMake, because cmake is present]
...
Traceback (most recent call last):
  File ".../python3.6/site-packages/conans/client/command.py", line 2232, in run
    method(args[0][1:])
  File ".../python3.6/site-packages/conans/client/command.py", line 790, in info
    lockfile=args.lockfile)
  File ".../python3.6/site-packages/conans/client/conan_api.py", line 93, in wrapper
    return f(api, *args, **kwargs)
  File ".../python3.6/site-packages/conans/client/conan_api.py", line 753, in info
    update, False, remotes, recorder)
  File ".../python3.6/site-packages/conans/client/graph/graph_manager.py", line 122, in load_graph
    apply_build_requires=apply_build_requires)
  File .../python3.6/site-packages/conans/client/graph/graph_manager.py", line 282, in _resolve_graph
    graph_lock=graph_lock)
  File ".../python3.6/site-packages/conans/client/graph/graph_manager.py", line 390, in _load_graph
    apply_build_requires=apply_build_requires)
  File ".../python3.6/site-packages/conans/client/graph/graph_manager.py", line 313, in _recurse_build_requires
    self._binary_analyzer.evaluate_graph(graph, build_mode, update, remotes, nodes_subset, root)
  File ".../python3.6/site-packages/conans/client/graph/graph_binaries.py", line 395, in evaluate_graph
    self._propagate_options(node)
  File ".../python3.6/site-packages/conans/client/graph/graph_binaries.py", line 308, in _propagate_options
    conanfile.requires[ref.name].ref = ref
KeyError: 'cmake'

> conan info PkgD
CMake/3.24.1@3rdparty/stable: Downloaded recipe revision 5bd0ad5ab85b682046a519c25293c69e
[no key error]

> conan search cmake
Existing package recipes:

CMake/3.24.1@3rdparty/stable
cmake/3.24.1@3rdparty/stable
```

user: Da-LiFe
issue_12415: state: open
title: [bug] PATH for build dependencies is not appended
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->
Conan failing on installation with error NASM not found


It seems that in some cases conan doesn't add build tools folder to the PATH variable. I submitted one case how to reproduce it. For some reason we faced that in azure cloud running on azure agent we have the same issue calling following command as a script, but everything works fine when you run it with bash shell inside azure job...
Hopefully it is the same case with described below.

### Environment Details (include every applicable attribute)
  * OS Name: Microsoft Windows 10 Pro 10.0.19044 N/A Build 19044
  * Compiler+version: MSVC 19.29.30146 for x64
  * Conan version: 1.53.0
  * Python version: v3.10.8:aaaf517,

### Steps to reproduce (Include if Applicable)
Conan file contents:

[requires]
zlib/1.2.12
openssl/1.1.1q
jwt-cpp/0.6.0
picojson/cci.20210117
gtest/1.12.1
libcurl/7.77.0
minizip-ng/3.0.2

[build_requires]

[generators]
cmake_find_package_multi

[options]


- place conanfile.txt to the current folder
- pip install conan
- mkdir tmp
- cd tmp
- conan install ../ --build missing -s os=Windows -s os_build=Windows -s arch=x86_64 -s arch_build=x86_64 -s compiler="Visual Studio" -s compiler.version=16 -s compiler.runtime=MD -s build_type=RelWithDebInfo --generator cmake_find_package_multi

### Logs (Executed commands with output) (Include/Attach if Applicable)
$ conan install ../ --build missing -s os=Windows -s os_build=Windows -s arch=x86_64 -s arch_build=x86_64 -s compiler="Visual Studio" -s compiler.version=16 -s compiler.runtime=MD -s build_type=RelWithDebInfo --generator cmake_find_package_multi

...

nasm/2.15.05: Created package revision b694b9c2a16133545e18358971a7a245
openssl/1.1.1q: Applying build-requirement: strawberryperl/5.30.0.1
openssl/1.1.1q: Applying build-requirement: nasm/2.15.05
Downloading conan_sources.tgz
openssl/1.1.1q: Configuring sources in C:\Users\user_user\.conan\data\openssl\1.1.1q\_\_\source
openssl/1.1.1q:
openssl/1.1.1q: Copying sources to build folder
openssl/1.1.1q: Building your package in C:\Users\user_user\.conan\data\openssl\1.1.1q\_\_\build\75ed07303f056424be45ffb582032fe7ad980a95
openssl/1.1.1q: Generator txt created conanbuildinfo.txt
openssl/1.1.1q: Aggregating env generators
openssl/1.1.1q: Calling build()
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.11.20
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
openssl/1.1.1q: using target: VC-conan-RelWithDebInfo-Windows-x86_64-Visual Studio-16 -> VC-WIN64A
openssl/1.1.1q: my %targets = (
    "VC-conan-RelWithDebInfo-Windows-x86_64-Visual Studio-16" => {
        inherit_from => [ "VC-WIN64A" ],
        cflags => add("-Zi -O2 -Ob1 -MD"),
        cxxflags => add("-Zi -O2 -Ob1 -MD"),
        defines => add("NDEBUG"),
        includes => add(),
        lflags => add(""),








    },
);

openssl/1.1.1q: ['"VC-conan-RelWithDebInfo-Windows-x86_64-Visual Studio-16"', 'no-shared', '--prefix="C:\\Users\\user_user\\.conan\\data\\openssl\\1.1.1q\\_\\_\\package\\75ed07303f056424be45ffb582032fe7ad980a95"', '--openssldir="C:\\Users\\user_user\\.conan\\data\\openssl\\1.1.1q\\_\\_\\package\\75ed07303f056424be45ffb582032fe7ad980a95\\res"', 'no-unit-test', 'threads', 'PERL=C:\\Users\\user_user\\.conan\\data\\strawberryperl\\5.30.0.1\\_\\_\\package\\ca33edce272a279b24f87dc0d4cf5bbdcffbc187\\bin\\perl.exe', 'no-tests', '--release', 'no-md2']
WARN: replace_in_file didn't find pattern '/MTd ' in 'Configurations\10-main.conf' file.
WARN: replace_in_file didn't find pattern '/MTd"' in 'Configurations\10-main.conf' file.
Configuring OpenSSL version 1.1.1q (0x1010111fL) for VC-conan-RelWithDebInfo-Windows-x86_64-Visual Studio-16
Using os-specific seed configuration

Failure!  build file wasn't produced.
Please read INSTALL and associated NOTES files.  You may also have to look over
your available compiler tool chain or change your configuration.

NASM not found - make sure it's installed and available on %PATH%
openssl/1.1.1q:
openssl/1.1.1q: ERROR: Package '75ed07303f056424be45ffb582032fe7ad980a95' build failed
openssl/1.1.1q: WARN: Build folder C:\Users\user_user\.conan\data\openssl\1.1.1q\_\_\build\75ed07303f056424be45ffb582032fe7ad980a95
ERROR: openssl/1.1.1q: Error in build() method, line 767
        self._make()
while calling '_make', line 689
        self.run('{perl} ./Configure {args}'.format(perl=self._perl, args=args), win_bash=self._win_bash)
        ConanException: Error 1 while executing C:\Users\user_user\.conan\data\strawberryperl\5.30.0.1\_\_\package\ca33edce272a279b24f87dc0d4cf5bbdcffbc187\bin\perl.exe ./Configure "VC-conan-RelWithDebInfo-Windows-x86_64-Visual Studio-16" no-shared --prefix="C:\Users\user_user\.conan\data\openssl\1.1.1q\_\_\package\75ed07303f056424be45ffb582032fe7ad980a95" --openssldir="C:\Users\user_user\.conan\data\openssl\1.1.1q\_\_\package\75ed07303f056424be45ffb582032fe7ad980a95\res" no-unit-test threads PERL=C:\Users\user_user\.conan\data\strawberryperl\5.30.0.1\_\_\package\ca33edce272a279b24f87dc0d4cf5bbdcffbc187\bin\perl.exe no-tests --release no-md2


user: jasuramme
issue_12410: state: open
title: conan package manager project help
body: Hello, I am currently learning to use conan as a C/C++ package manager, and I have completed the study of the official tutorial. Currently, I want to use a complex project using conan as a package management to facilitate my learning. Can the community help provide some open source The project of the Conan package manager, I searched for a long time in github, but did not find a suitable project. thanks
user: niuzhi
issue_12409: state: open
title: [bug] Deprecation warning when installing Conan with pip
body: On the latest pip 22.3, when doing `pip install conan`:

```
  DEPRECATION: conan is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559
```

Consider whether the easiest for us is to provide a wheel, or to migrate to `pyproject.toml` and continue doing source distributions. 

(first reported in https://github.com/conan-io/conan/issues/12400) 
user: jcar87
issue_12406: state: open
title: [question] Binary modes considering options (binary compatibility issue)
body: I have a library `Foo` which has an option `XXX=True | False` this option affects a definition of some structs (technically we define a macro and then alternate content with `#ifdef-#else`) thus `Foo:XXX=True` and `Foo:XXX=False` version of a library are binary incompatible (and that is not something I can change any time soon). 

CI creates/uploads the package with default value for the option: `Foo:XXX=True`.

So the issue with it comes when something depends on `Foo`. Because binaries stored in the registry are considered according to semver (let's consider `settings = "os", "compiler", "build_type", "arch"` are fixed). So a potential library/application `Bar` that depends on `Foo/1.2.3` will get into troubles when running `conan install <params> -o Foo:XXX=False`  because Conan will find ready to go binaries for `Foo/1.2.3` and bring them to client. 

And here we have binaries from registry for `Foo/1.2.3` which were compiled with default option `Foo:XXX=True`, and a `Bar`  that is going to be compiled with `Foo:XXX=False` and will act like it has a binary different version of `Foo` .

My real usecase is a bit more complicated but I believe it maps to the model I've described.

The above can be avoided with (must be present for libs that depends on `Foo`):
```py
    def package_id(self):
        self.info.requires["Foo"].full_package_mode()
```

And what is even worse here is that when a lib depends on smth that depends on `Foo` then it should reintroduce `full_package_mode`:

```py
    def package_id(self):
        self.info.requires["SmthThatDependsOnFoo"].full_package_mode()
```

All this also implies that I can't have the benefits of semver in cases this dirty options is the same. 

For example, consider we have have the following libs: `Baz1` depending on `Foo/1.2.3`, `Baz2` depending on `Foo/1.2.5`, and `Baz3` depending on `Foo/1.3.0` (and pre-compiled binaries are in registry). Then we have an app which uses `Baz1,2,3`. And just take the latest version of `Foo`. If all `Baz` libs apply `full_package_mode` for Foo it means that when getting requirements for our app Conan will run rebuild for `Baz1` and `Baz2` which is unnecessary if `Foo:XXX=True` - default option.

Is there something like the following (or some approach that achieves the same affect):

```py
    def package_id(self):
        self.info.options["XXX"].adjusts_abi_mode()
```

which I can do in `Foo`'s conanfile and it would add an additional "dimension" when considering binaries, thus perfectly doing semver if option value is the same.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: ngrodzitski
issue_12402: state: open
title: [question] How to prevent CONAN_LIB_DIRS in .mak file get libraries recursively?
body: Hi,
I wonder how to prevent the recursive contents in the `CONAN_LIBS` in my `.mak` file.
I want the `CONAN_LIBS` in my `.mak` file is only assigned as the library names from the `[requires]` in the conanfile.txt. (Exclude the requires of requires.)

For example, I have three libraries, the dependency relation is as the graph below:
<img src="https://i.imgur.com/O8YxJPN.jpg" />   
The content of the conanfile.txt is 
```
[requires]
top_lib/1.0.0
```

After I execute ` conan install ./conanfile.txt -g make `, I get a .mak file.
The `CONAN_LIBS` in the .mak file concatenate the three libraries, which is 
```
CONAN_LIBS +=  \
$(CONAN_LIBS_TOP_LIB) \
$(CONAN_LIBS_MIDDLE_LIB) \
$(CONAN_LIBS_ZLIB)
```

But I want `CONAN_LIBS` only be like 
```
CONAN_LIBS +=  \
$(CONAN_LIBS_TOP_LIB)
```
Thus my makefile can set `CONAN_LIBS` to the linker directly instead of specifying `CONAN_LIBS_TOP_LIB`, and my library doesn't have to depend on middle_lib and zlib directly. 
How can I achieve this?

Thank you.
user: JokaHD
issue_12404: state: open
title: [question] Possible Bug using conan lock create
body: Hello,
I have a question about an error I encountered while using/generating lock files.
We build packages with multiple compilers and followed a recommendation to first create a base lock file and use this as a basis to generate the actual build lock files.
Building a dependency resulted in an error, which I was able to temporarily avoid by not using a base lock file.
I do not know if I missed something, or if this could be a bug.

#### Our setup:

OS=Linux (Ubuntu 18.04)
Conan version: 1.51.3
Compiler: clang6, gcc8

#### Host profile:
[settings]
os=Linux
arch=x86_64
compiler=clang
compiler.version=6.0
compiler.libcxx=libstdc++11
build_type=Debug
[options]
[conf]
[build_requires]
[env]
CC=clang-6.0
CXX=clang++-6.0

#### Build profile:
[settings]
os=Linux
arch=x86_64
compiler=gcc
compiler.version=8
compiler.libcxx=libstdc++11
build_type=Release
[options]
[conf]
[build_requires]
[env]
CC=gcc-8
CXX=g++-8

#### Commands executed:

```
conan remove '*' -f
conan remote enable conancenter
conan download googleapis/cci.20220711@#7f3241ea8e0d5852cd4547d0b7b936f9 -re -r conancenter
conan remote disable conancenter    #only in our artifactory internalized packages should be used
conan remote remove_ref googleapis/cci.20220711@#7f3241ea8e0d5852cd4547d0b7b936f9

conan lock create --base --ref=googleapis/cci.20220711@#7f3241ea8e0d5852cd4547d0b7b936f9 --lockfile-out=base.lock -pr:h linux-x86_64-clang-6_0-libstdc++11-debug -pr:b linux-x86_64-gcc-8-libstdc++11-release

conan lock create --ref=googleapis/cci.20220711@#7f3241ea8e0d5852cd4547d0b7b936f9 -pr:h linux-x86_64-clang-6_0-libstdc++11-debug -pr:b linux-x86_64-gcc-8-libstdc++11-release --lockfile=base.lock --lockfile-out=testbuild.lock --build=missing
```

#### Error message:
`ERROR: 'zlib/1.2.12#82202701ea360c0863f1db5008067122' package-id '1d877a3df840030e6a8abb74c5ffb9088d08b47a' doesn't match the locked one 'd18c7969d006e56f2a0d590b65bc788eb0d0b075'`

#### Base lockfile content: 
```
{
 "graph_lock": {
  "nodes": {
   "1": {
    "ref": "googleapis/cci.20220711#7f3241ea8e0d5852cd4547d0b7b936f9",
    "requires": [
     "2"
    ],
    "context": "host"
   },
   "2": {
    "ref": "protobuf/3.21.4#399ed4d6e84ba4a768660c1a3fd1213c",
    "requires": [
     "3"
    ],
    "context": "host"
   },
   "3": {
    "ref": "zlib/1.2.12#82202701ea360c0863f1db5008067122",
    "context": "host"
   }
  },
  "revisions_enabled": true
 },
 "version": "0.4"
}
```

#### Testbuild lock file content (generated without base lock file):
```
{
 "graph_lock": {
  "nodes": {
   "1": {
    "ref": "googleapis/cci.20220711#7f3241ea8e0d5852cd4547d0b7b936f9",
    "options": "fPIC=True\nshared=False\nprotobuf:debug_suffix=True\nprotobuf:fPIC=True\nprotobuf:lite=False\nprotobuf:shared=False\nprotobuf:with_rtti=True\nprotobuf:with_zlib=True\nzlib:fPIC=True\nzlib:shared=False",
    "package_id": "6cd005926fe1ae21fed94b1c27496db1f482c6e5",
    "requires": [
     "2"
    ],
    "build_requires": [
     "4"
    ],
    "context": "host"
   },
   "2": {
    "ref": "protobuf/3.21.4#399ed4d6e84ba4a768660c1a3fd1213c",
    "options": "debug_suffix=True\nfPIC=True\nlite=False\nshared=False\nwith_rtti=True\nwith_zlib=True\nzlib:fPIC=True\nzlib:shared=False",
    "package_id": "286e5a51e7c8226dd96d07e62ee8499c7e467c4d",
    "prev": "a110018520ffdab9c17bb3a89dcf362d",
    "requires": [
     "3"
    ],
    "context": "host"
   },
   "3": {
    "ref": "zlib/1.2.12#82202701ea360c0863f1db5008067122",
    "options": "fPIC=True\nshared=False",
    "package_id": "d18c7969d006e56f2a0d590b65bc788eb0d0b075",
    "prev": "8c420b0823238b9ce05603a7f8cfa252",
    "context": "host"
   },
   "4": {
    "ref": "protobuf/3.21.4#399ed4d6e84ba4a768660c1a3fd1213c",
    "options": "debug_suffix=True\nfPIC=True\nlite=False\nshared=False\nwith_rtti=True\nwith_zlib=True\nzlib:fPIC=True\nzlib:shared=False",
    "package_id": "c48dd120eb397783f2600c0083d3ffc0c35d3f13",
    "prev": "418659637b2475647bef64f7b7e9e5a1",
    "requires": [
     "5"
    ],
    "context": "build"
   },
   "5": {
    "ref": "zlib/1.2.12#82202701ea360c0863f1db5008067122",
    "options": "fPIC=True\nshared=False",
    "package_id": "1d877a3df840030e6a8abb74c5ffb9088d08b47a",
    "prev": "03d1c688e9c9e0eeba8f05ec39404e65",
    "context": "build"
   }
  },
  "revisions_enabled": true
 },
 "version": "0.4",
 "profile_host": "[settings]\narch=x86_64\nbuild_type=Debug\ncompiler=clang\ncompiler.libcxx=libstdc++11\ncompiler.version=6.0\nos=Linux\n[options]\n[build_requires]\n[env]\nCC=clang-6.0\nCXX=clang++-6.0\n[buildenv]\nCC=clang-6.0\nCXX=clang++-6.0\n",
 "profile_build": "[settings]\narch=x86_64\nbuild_type=Release\ncompiler=gcc\ncompiler.libcxx=libstdc++11\ncompiler.version=8\nos=Linux\n[options]\n[build_requires]\n[env]\nCC=gcc-8\nCXX=g++-8\n[buildenv]\nCC=gcc-8\nCXX=g++-8\n"
}
```


user: RudolfNetzel
issue_12399: state: open
title: [question] How to select which `compiler.exception` settings for MinGW compiler?
body: ### Problem Descriptions

As we can see, there are 3 different `compiler.exception` settings for MinGW compiler to choose. 

- `dwarf2`
- `sjlj`
- `seh`

I was wondering that how to detect which exception model the current GCC/MinGW is using? If possible, design a detection mechanism for integration of [cmake-conan](https://github.com/conan-io/cmake-conan).

![image](https://user-images.githubusercontent.com/71438617/197929136-0009e801-d181-43f6-87dd-40413660a991.png)

user: hwhsu1231
issue_12396: state: open
title: [bug] 301 Moved Permanently in response to conan upload's PUT requests results in a 409 Conflict for URL
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->
**Update:** The below happens when a 301 redirect is returned in response to the PUT requests for the files being uploaded. Changing the conan remote's URL to match the one in the 301 allows the upload to proceed normally.


When uploading a package from Ubuntu a 409 Conflict for URL is received when the conanmanifest.txt file is uploaded. Copying the package to a MacOS environment with the same version of conan and an identical conan.conf allows the package to be uploaded just fine after deleting whatever managed to make it before the previous failure off of artifactory.

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 22.04 / MacOS Monterey 12.5.1
  * Compiler+version: GCC 11.3.0
  * Conan version: 1.51.0 (Ubuntu & Mac). I've also separately checked that the issue happens when 1.53.0 is installed on the Ubuntu machine
  * Python version: 3.8.15 & 3.10.6 (Ubuntu) / 3.8.13 (MacOS)

This is a relatively fresh Ubuntu install (installed last night), that I've since installed Qt 6, build-essentials, git, and cmake on. There are already zstd/1.5.0 packages for Windows and MacOS in the artifactory I'm using.

I've attached a copy of my profile.
[profile_ubuntu22.04.txt](https://github.com/conan-io/conan/files/9862276/profile_ubuntu22.04.txt)


### Steps to reproduce (Include if Applicable)
- Run Python Black on zstd/1.5.0's conanfile.py
- Create a package for `zstd/1.5.0` 
- Run `conan upload zstd/1.5.0@ -r ... --all`
- Recieve a 409 error
- Delete whatever half uploaded mess made it to Artifactory
- Copy ~/.conan/data/zstd to a MacOS system
- Run `conan upload zstd/1.5.0@ -r ... --all`
- Package is uploaded successfully

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

(References to my employer have been replaced with `...`) Ubuntu: 
```
conan create /home/gregory/.../src_build/zstd/1.5.0/conanfile.py zstd/1.5.0@_/_ --profile /home/gregory/.../_util/conan/profile_ubuntu22.04 --build missing 
Exporting package recipe
zstd/1.5.0 exports: File 'conandata.yml' found. Exporting it...
zstd/1.5.0 exports: Copied 1 '.yml' file: conandata.yml
zstd/1.5.0 exports_sources: Copied 1 '.txt' file: CMakeLists.txt
zstd/1.5.0 exports_sources: Copied 1 '.patch' file: 0001-cmake-install-dll.patch
zstd/1.5.0: The stored package has not changed
zstd/1.5.0: Using the exported files summary hash as the recipe revision: 798e1a11cf63a9f4ce1a389b64d72de4 
zstd/1.5.0: Exported revision: 798e1a11cf63a9f4ce1a389b64d72de4
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

Installing package: zstd/1.5.0
Requirements
    zstd/1.5.0 from '...' - Cache
Packages
    zstd/1.5.0:dfbe50feef7f3c6223a476cd5aeadb687084a646 - Cache

Installing (downloading, building) binaries...
zstd/1.5.0: Already installed!
conan upload zstd/1.5.0@ -r ... --all
Uploading to remote '...':
Uploading zstd/1.5.0 to remote '...'                                         
Compressing conan_export.tgz completed [1 files]                                         
Compressing conan_sources.tgz completed [2 files]                                        
Recipe is up to date, upload skipped
Uploading package 1/1: dfbe50feef7f3c6223a476cd5aeadb687084a646 to '...'     
Uploaded conanmanifest.txt -> zstd/1.5.0:dfbe [0.31k]                                    
ERROR: 409 Client Error: Conflict for url: https://....jfrog.io/artifactory/api/conan/.../v2/conans/zstd/1.5.0/_/_/revisions/798e1a11cf63a9f4ce1a389b64d72de4/packages/dfbe50feef7f3c6223a476cd5aeadb687084a646/revisions/71464c91c8fbe9533d27297fc7b82ef1/files/conanmanifest.txt
Waiting 5 seconds to retry...
Uploaded conanmanifest.txt -> zstd/1.5.0:dfbe [0.31k]                                    
ERROR: 
Error uploading file: conanmanifest.txt, '409 Client Error: Conflict for url: https://....jfrog.io/artifactory/api/conan/.../v2/conans/zstd/1.5.0/_/_/revisions/798e1a11cf63a9f4ce1a389b64d72de4/packages/dfbe50feef7f3c6223a476cd5aeadb687084a646/revisions/71464c91c8fbe9533d27297fc7b82ef1/files/conanmanifest.txt'
ERROR: zstd/1.5.0:dfbe50feef7f3c6223a476cd5aeadb687084a646: Upload package to '...' failed: Execute upload again to retry upload the failed files: conanmanifest.txt. [Remote: ...]

ERROR: Errors uploading some packages

```
user: bloxgate
issue_12394: state: open
title: [feature] Add a 'tool_options' section to conanfile
body: As a follow on from [this discussion](https://github.com/conan-io/conan-center-index/issues/13708), I think it'd be helpful to be able to specify separate options for the build/host profile from a conanfile without resorting to separate profiles.

If you have a conanfile like this:
```
[requires]
flatbuffers/2.0.8
[tool_requires]
flatbuffers/2.0.8
[options]
flatbuffers:shared=True
```
It's unclear which package is affected by that option. ~~Currently, the only way to add separate options (unless I'm mistaken?) is to add them to profiles.~~

I think since dual profiles are the new normal in Conan, either a `tool_options` (or similar) feature should be supported in conanfile.txt/py, or the `options` section should be removed entirely, and options should only be specified in profiles.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: AlexRamallo
issue_12391: state: open
title: [bug] It seems, that it is not possible to specify build and install folders with new generators 
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->
It seems, that it is not possible to specify build and install folders with new generators, when compiling for a local workflow.
If I am wrong, please write a script, that will build a new cmake template to a certain folder.

My build script was always:
```conan install . --install-folder=build --build missing  && \
conan build   . --build-folder=build --source-folder=. && \
conan package . --build-folder=build --package-folder=bin```

### Environment Details (include every applicable attribute)
  * Operating System+version: Linux Ubuntu 22.04
  * Compiler+version: any
  * Conan version: 1.53.0

### Steps to reproduce (Include if Applicable)
conan new test/0.0.0 --template cmake_exe
conan install . --install-folder=build --build missing

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
conanfile.py (test/0.0.0): Installing package
Requirements
Packages

Installing (downloading, building) binaries...
conanfile.py (test/0.0.0): Generator txt created conanbuildinfo.txt
conanfile.py (test/0.0.0): Calling generate()
conanfile.py (test/0.0.0): WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
conanfile.py (test/0.0.0): Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
conanfile.py (test/0.0.0): If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/home/andrei/sources/tmp/build/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
conanfile.py (test/0.0.0): Aggregating env generators
conanfile.py (test/0.0.0): Generated conaninfo.txt
conanfile.py (test/0.0.0): Generated graphinfo
Using lockfile: '/home/andrei/sources/tmp/build/conan.lock'
Using cached profile from lockfile
conanfile.py (test/0.0.0): Calling build()
ERROR: conanfile.py (test/0.0.0): Error in build() method, line 30
	cmake = CMake(self)
	FileNotFoundError: [Errno 2] No such file or directory: '/home/andrei/sources/tmp/build/build/generators/CMakePresets.json'-->

user: AndreyMlashkin
issue_12389: state: open
title: [question] How can I provide a CMAKE FLAG in recipe (not option), for providing diffrent sdk
body: <!-- What is your question? Please be as specific as possible! -->

I need to provide two kinds of API implementation in library A.so and library B.so, so I need to provide a flag so that I can use this flag to decide which library to link when I link those libraries.
user: Tumb1eweed
issue_12374: state: open
title: [question] How to create a virtual like  package of `libjpeg` & `libjpeg-turbo`?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

In conan-center, there is a very old wish to provide a virtual package of `libjpeg`. There are 3 well-known implementations of libjpeg: `libjpeg`, `libjpeg-turbo`, `mozjpeg`.

Currently each recipe is responsible of the implementation selection, it's tedious and leads to lot of discrepancy and illformed dependency graph (2 or 3 implementations in the same dependency graph => broken).
We would like to delegate this selection to only one virtual recipe, so that it could ensure coherency of the dependency graph (only one implementation).

Basically something like this:

```python
from conan import ConanFile, conan_version
from conan.tools.scm import Version

required_conan_version = ">=1.52.0"


class VirtualLibjpegConan(ConanFile):
    name = "virtual-libjpeg"
    description = "Proxy recipe to select either libjpeg, libjpeg-turbo or mozjpeg"
    license = "MIT"
    topics = ("proxy", "virtual", "libjpeg", "libjpeg-turbo", "mozjepg")
    homepage = "https://github.com/conan-io/conan-center-index"
    url = "https://github.com/conan-io/conan-center-index"

    settings = "os", "arch", "compiler", "build_type"
    options = {
        "impl": ["libjpeg", "libjpeg-turbo", "mozjpeg"],
    }
    default_options = {
        "impl": "libjpeg-turbo",
    }

    @property
    def _impl_version(self):
        return {
            "libjpeg": "9e",
            "libjpeg-turbo": "2.1.4",
            "mozjpeg": "4.1.1",
        }[str(self.options.impl)]

    def layout(self):
        pass

    def requirements(self):
        self.requires(f"{self.options.impl}/{self._impl_version}", transitive_headers=True, transitive_libs=True)

    def package_id(self):
        self.info.clear()

    def source(self):
        pass

    def build(self):
        pass

    def package(self):
        pass

    def package_info(self):
        if self.options.impl != "libjpeg": # libjpeg recipe already owns these names
            self.cpp_info.set_property("cmake_find_mode", "both")
            self.cpp_info.set_property("cmake_file_name", "JPEG")
            self.cpp_info.set_property("cmake_target_name", "JPEG::JPEG")
            if Version(conan_version).major < 2:
                self.cpp_info.names["cmake_find_package"] = "JPEG"
                self.cpp_info.names["cmake_find_package_multi"] = "JPEG"
        self.cpp_info.bindirs = []
        self.cpp_info.includedirs = []
        self.cpp_info.libdirs = []
        if self.options.impl == "libjpeg":
            self.cpp_info.requires = ["libjpeg::libjpeg"]
        elif self.options.impl == "libjpeg-turbo":
            self.cpp_info.requires = ["libjpeg-turbo::jpeg"]
        elif self.options.impl == "mozjpeg":
            self.cpp_info.requires = ["mozjpeg::libjpeg"]
```

I see one main issue with such virtual recipe and current conan behavior: if a recipeA depends on this virtual recipe, the underlying recipe implementation is not anymore a direct dependency of recipeA, so I suspect package id issues.
How to design this virtual recipe so that any recipe having it as a direct dependency would behave as if either libjpeg, libjpeg-turbo or mozjpeg would be considered a direct dependency?
user: SpaceIm
issue_12369: state: open
title: Using Conan with Neovim CoC (Conquest of Completion)
body: I want to use Neovim for my C++ development, and CoC is a great alternative to YouCompleteMe. However the Conan documentation only specifies YouCompleteMe as one of it's vim-like generators. Is there any support for CoC?
user: darius-grauslys
issue_12368: state: open
title: Using Conan with Xbps on Void Linux
body: ### Question:
How can I configure Conan to use my system's package manager correctly? (xbps-install from void linux https://voidlinux.org )
Specifically, how can I tell Conan to use a specific package naming convention such as yum, but invoke xbps-install?

### Problem description:
I am looking to set up Conan on my system and everything seems to work except when Conan tries to download dependencies of packages.

`
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gtk+-2.0' found
`
I can do something like:
`sudo xbps-install gtk+`
and it will resolve that singular issue, only for the next dependency requiring manual intervention as well.

Looking into it I would navigate to my .conan directory, to the specific caching of the package, and into the conanfile.py. Here I notice various package managers with explicit strings as install targets. (Like for, apt.install([ "libXYZ" ]) )

It looks like the install targets being used is here:
`pkg = package_manager.Pkg(self)`

Which makes sense since I don't have any of the other package managers Conan is looking for.
However, if Conan used the install targets for yum on xbps-install, I think everything would be fine.
user: darius-grauslys
issue_12362: state: open
title: [question] can we automatically delete test_package/build ?
body: When I call `conan create xyz`, it will automatically build and run test_package.

If I do it again, the previous build files remain in the test_package, and can interfere with the next conan-create execution.

So now I typically do `rm -r test_*/build; conan create something`

user: paulharris
issue_12360: state: open
title: [question] cmake_layout with subproject vs conan.tools.scm.Git
body: I'm trying to make [layout with multiple subprojects](https://docs.conan.io/en/latest/developing_packages/package_layout.html#example-multiple-subprojects) work. My sources are stored in a git repo organized as follows:

```
(git root)
└─── pkg1
│   │   CMakeLists.txt
│   └─── src
│       │   source_file.cpp
│       │   ...
└─── pkg2
|   │   CMakeLists.txt
|   └─── src
|       |   ...
...
```
Trying to build them in Conan cache I wrote
```python
    def layout(self):
        self.folders.root = ".."
        self.folders.subproject = "pkg1"
        cmake_layout(self)

    def source(self):
        git = Git(self)
        git.clone(URL, target='.')
        git.checkout(REVISION)
        self.output.info("Syncing git submodules")
        git.run("submodule sync --recursive")
        git.run("submodule update --init --recursive")

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
```
This doesn't work: git.clone() clones the whole git repo inside `pkg1` subfolder and cmake.configure() fails. What's the recommended way to use scm.Git with package layout feature?
user: db4
issue_12354: state: open
title: [feature] Ensure that `tools.gnu:pkg_config` is discoverable in all conan v2 build helpers
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Currently `tools.gnu:pkg_config` is only used in `PkgConfig` class (and it's explicitly described like this in `conan config list`). It would be a good idea to extend capabilities of this conf so that when it's set, it ensures that this specific executable is found by standard usage of CMake, Autotools, Meson etc...

For example in CMake, standard usage is to call `find_package(PkgConfig)`. There is a documented CMake variable `PKG_CONFIG_EXECUTABLE` which can be overridden to force this module file to use executable pointed by this variable: https://cmake.org/cmake/help/latest/module/FindPkgConfig.html#variables-affecting-behavior
user: SpaceIm
issue_12352: state: open
title: [question] Build-time only ConanInvalidConfiguration for a tool requirement
body: - [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

The `mold` linker can only be built with GCC 10 or newer, and that's being enforced with the `validate()` method:
https://github.com/conan-io/conan-center-index/blob/86de5edf37c74befdcd1a318bee352d15a01e675/recipes/mold/all/conanfile.py#L32-L33

This makes sense when you're actually building the mold package, but it also prevents it from being consumed by a project being built with an older GCC.
In my case, I build my project with GCC 8 and I'm including `mold` as a `build_requirement`, but conan complains about it:
```
Installing (downloading, building) binaries...
ERROR: There are invalid packages (packages that cannot exist for this configuration):
mold/1.5.1: Invalid ID: GCC version 10 or higher required
```

I'm wondering if there is a way of enforcing this only at compile-time and not at consumption time.
The package already removes the compiler from the build ID  with
```py
    def package_id(self):
        del self.info.settings.compiler
```

Thanks!
user: ericriff
issue_12343: state: open
title: [bug] cross compiling v2 compatible recipes fails on mac
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->
Moving the issue here @uilianries @SpaceIm. Related to https://github.com/conan-io/conan-center-index/issues/13251


### Environment Details (include every applicable attribute)
  * Operating System+version: MacOS Monterey 12.5
  * Compiler+version: gcc-11 (Homebrew GCC 11.3.0) 11.3.0
  * Conan version:  1.52.0
  * Python version: 3.9.1

### Steps to reproduce (Include if Applicable)
Have got this issue for many recipes that have updated to the v2 support:
`conan install libjpeg/9d@ --profile:build=default --profile:host=armhf  --build`
`conan install c-ares/1.18.1@ -pr:b=default --build -pr:h=armhf`

If i revert back to the commit before the v2 changes, it works in both cases.

### Logs (Executed commands with output) (Include/Attach if Applicable)

For `libjpeg/9d@`:
```
Configuration (profile_host):
[settings]
arch=armv7
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=10
os=Linux
[options]
[build_requires]
[env]
AR=armv7-unknown-linux-gnueabihf-ar
AS=armv7-unknown-linux-gnueabihf-as
CC=armv7-unknown-linux-gnueabihf-gcc
CMAKE_CXX_COMPILER=armv7-unknown-linux-gnueabihf-g++
CMAKE_C_COMPILER=armv7-unknown-linux-gnueabihf-gcc
CMAKE_SYSTEM_PROCESSOR=arm
CONAN_CMAKE_SYSTEM_PROCESSOR=arm
CXX=armv7-unknown-linux-gnueabihf-g++
FC=armv7-unknown-linux-gnueabihf-gfortran-6
LD=armv7-unknown-linux-gnueabihf-ld
RANLIB=armv7-unknown-linux-gnueabihf-ranlib
STRIP=armv7-unknown-linux-gnueabihf-strip
Configuration (profile_build):
[settings]
arch=armv8
arch_build=armv8
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11.3
os=Macos
os_build=Macos
[options]
[build_requires]
[env]
CC=/opt/homebrew/bin/gcc-11
CONAN_CMAKE_CXX_COMPILER=/opt/homebrew/bin/g++-11
CONAN_CMAKE_C_COMPILER=/opt/homebrew/bin/gcc-11
CXX=/opt/homebrew/bin/g++-11
libjpeg/9d: Not found in local cache, looking in remotes...
libjpeg/9d: Trying with 'conancenter'...
Downloading conanmanifest.txt completed [0.25k]
Downloading conanfile.py completed [8.05k]
Downloading conan_export.tgz completed [0.27k]
Decompressing conan_export.tgz completed [0.00k]
libjpeg/9d: Downloaded recipe revision 0
libjpeg/9d: Forced build from source
Installing package: libjpeg/9d
Requirements
    libjpeg/9d from 'conancenter' - Downloaded
Packages
    libjpeg/9d:dd9cddcdb46bc8e49ab41989adbb51fd7364d404 - Build

Cross-build from 'Macos:armv8' to 'Linux:armv7'
Installing (downloading, building) binaries...
Downloading conan_sources.tgz completed [6.16k]
Decompressing conan_sources.tgz completed [0.00k]
[HOOK - conan-center.py] pre_source(): [IMMUTABLE SOURCES (KB-H010)] OK
libjpeg/9d: Configuring sources in /Users/vinayvarma/.conan/data/libjpeg/9d/_/_/source/src
Downloading jpegsrc.v9d.tar.gz completed [1006.75k]                                      libjpeg/9d: g/9d:
libjpeg/9d:
[HOOK - conan-center.py] post_source(): [LIBCXX MANAGEMENT (KB-H011)] OK
[HOOK - conan-center.py] post_source(): [CPPSTD MANAGEMENT (KB-H022)] OK
libjpeg/9d: Copying sources to build folder
libjpeg/9d: Building your package in /Users/vinayvarma/.conan/data/libjpeg/9d/_/_/build/dd9cddcdb46bc8e49ab41989adbb51fd7364d404
libjpeg/9d: Generator txt created conanbuildinfo.txt
libjpeg/9d: Calling generate()
libjpeg/9d: Aggregating env generators
[HOOK - conan-center.py] pre_build(): [FPIC MANAGEMENT (KB-H007)] OK. 'fPIC' option found and apparently well managed
[HOOK - conan-center.py] pre_build(): [FPIC MANAGEMENT (KB-H007)] OK
libjpeg/9d: Calling build()
libjpeg/9d: Calling:
 > "/Users/vinayvarma/.conan/data/libjpeg/9d/_/_/build/dd9cddcdb46bc8e49ab41989adbb51fd7364d404/src/configure" '--disable-shared' '--enable-static' '--prefix=/' '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' '--host=arm-linux-gnueabi' '--build=aarch64-apple-darwin'
Capturing current environment in /Users/vinayvarma/.conan/data/libjpeg/9d/_/_/build/dd9cddcdb46bc8e49ab41989adbb51fd7364d404/build-release/conan/deactivate_conanautotoolstoolchain.sh
Configuring environment variables
Capturing current environment in /Users/vinayvarma/.conan/data/libjpeg/9d/_/_/build/dd9cddcdb46bc8e49ab41989adbb51fd7364d404/build-release/conan/deactivate_conanbuildenv-release-armv7.sh
Configuring environment variables
checking build system type... aarch64-apple-darwin
checking host system type... arm-unknown-linux-gnueabi
checking target system type... arm-unknown-linux-gnueabi
checking for a BSD-compatible install... /opt/homebrew/bin/ginstall -c
checking whether build environment is sane... yes
checking for arm-linux-gnueabi-strip... armv7-unknown-linux-gnueabihf-strip
checking for a thread-safe mkdir -p... /opt/homebrew/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for arm-linux-gnueabi-gcc... armv7-unknown-linux-gnueabihf-gcc
checking whether the C compiler works... no
configure: error: in `/Users/vinayvarma/.conan/data/libjpeg/9d/_/_/build/dd9cddcdb46bc8e49ab41989adbb51fd7364d404/build-release':
configure: error: C compiler cannot create executables
See `config.log' for more details
libjpeg/9d:
libjpeg/9d: ERROR: Package 'dd9cddcdb46bc8e49ab41989adbb51fd7364d404' build failed
libjpeg/9d: WARN: Build folder /Users/vinayvarma/.conan/data/libjpeg/9d/_/_/build/dd9cddcdb46bc8e49ab41989adbb51fd7364d404/build-release
ERROR: libjpeg/9d: Error in build() method, line 136
        autotools.configure()
        ConanException: Error 77 while executing "/Users/vinayvarma/.conan/data/libjpeg/9d/_/_/build/dd9cddcdb46bc8e49ab41989adbb51fd7364d404/src/configure" '--disable-shared' '--enable-static' '--prefix=/' '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' '--host=arm-linux-gnueabi' '--build=aarch64-apple-darwin'
```
For c-ares:
```
Configuration (profile_host):
[settings]
arch=armv7
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=10
os=Linux
[options]
[build_requires]
[env]
AR=armv7-unknown-linux-gnueabihf-ar
AS=armv7-unknown-linux-gnueabihf-as
CC=armv7-unknown-linux-gnueabihf-gcc
CMAKE_CXX_COMPILER=armv7-unknown-linux-gnueabihf-g++
CMAKE_C_COMPILER=armv7-unknown-linux-gnueabihf-gcc
CMAKE_SYSTEM_PROCESSOR=arm
CONAN_CMAKE_SYSTEM_PROCESSOR=arm
CXX=armv7-unknown-linux-gnueabihf-g++
FC=armv7-unknown-linux-gnueabihf-gfortran-6
LD=armv7-unknown-linux-gnueabihf-ld
RANLIB=armv7-unknown-linux-gnueabihf-ranlib
STRIP=armv7-unknown-linux-gnueabihf-strip
Configuration (profile_build):
[settings]
arch=armv8
arch_build=armv8
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11.3
os=Macos
os_build=Macos
[options]
[build_requires]
[env]
CC=/opt/homebrew/bin/gcc-11
CONAN_CMAKE_CXX_COMPILER=/opt/homebrew/bin/g++-11
CONAN_CMAKE_C_COMPILER=/opt/homebrew/bin/gcc-11
CXX=/opt/homebrew/bin/g++-11
c-ares/1.18.1: Not found in local cache, looking in remotes...
c-ares/1.18.1: Trying with 'conancenter'...
Downloading conanmanifest.txt completed [0.10k]
Downloading conanfile.py completed [4.31k]
Downloading conan_export.tgz completed [0.25k]
Decompressing conan_export.tgz completed [0.00k]
c-ares/1.18.1: Downloaded recipe revision 0
c-ares/1.18.1: Forced build from source
Installing package: c-ares/1.18.1
Requirements
    c-ares/1.18.1 from 'conancenter' - Downloaded
Packages
    c-ares/1.18.1:2091615c0a3aac96a800d7728cd62ef397c449d3 - Build

Cross-build from 'Macos:armv8' to 'Linux:armv7'
Installing (downloading, building) binaries...
[HOOK - conan-center.py] pre_source(): [IMMUTABLE SOURCES (KB-H010)] OK
c-ares/1.18.1: Configuring sources in /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/source/src
Downloading c-ares-1.18.1.tar.gz completed [1523.60k]                                    c-ares/1.18.1: res/1.18.1:
c-ares/1.18.1:
[HOOK - conan-center.py] post_source(): [LIBCXX MANAGEMENT (KB-H011)] OK
[HOOK - conan-center.py] post_source(): [CPPSTD MANAGEMENT (KB-H022)] OK
c-ares/1.18.1: Copying sources to build folder
c-ares/1.18.1: Building your package in /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/build/2091615c0a3aac96a800d7728cd62ef397c449d3
c-ares/1.18.1: Generator txt created conanbuildinfo.txt
c-ares/1.18.1: Calling generate()
c-ares/1.18.1: Aggregating env generators
[HOOK - conan-center.py] pre_build(): [FPIC MANAGEMENT (KB-H007)] OK. 'fPIC' option found and apparently well managed
[HOOK - conan-center.py] pre_build(): [FPIC MANAGEMENT (KB-H007)] OK
c-ares/1.18.1: Calling build()
c-ares/1.18.1: apply_conandata_patches(): No patches defined in conandata
c-ares/1.18.1: CMake command: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/build/2091615c0a3aac96a800d7728cd62ef397c449d3/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/build/2091615c0a3aac96a800d7728cd62ef397c449d3/src"
-- Using Conan toolchain: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/build/2091615c0a3aac96a800d7728cd62ef397c449d3/build/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- The C compiler identification is GNU 10.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /opt/homebrew/bin/armv7-unknown-linux-gnueabihf-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Looking for res_servicename
-- Looking for res_servicename - not found
-- Looking for res_servicename in resolv
-- Looking for res_servicename in resolv - not found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for socket
-- Looking for socket - found
-- Looking for clock_gettime
-- Looking for clock_gettime - found
-- Looking for include file sys/types.h
-- Looking for include file sys/types.h - found
-- Looking for include file sys/socket.h
-- Looking for include file sys/socket.h - found
-- Looking for include file sys/sockio.h
-- Looking for include file sys/sockio.h - not found
-- Looking for include file arpa/inet.h
-- Looking for include file arpa/inet.h - found
-- Looking for include file arpa/nameser_compat.h
-- Looking for include file arpa/nameser_compat.h - found
-- Looking for include file arpa/nameser.h
-- Looking for include file arpa/nameser.h - found
-- Looking for include file assert.h
-- Looking for include file assert.h - found
-- Looking for include file errno.h
-- Looking for include file errno.h - found
-- Looking for include file fcntl.h
-- Looking for include file fcntl.h - found
-- Looking for include file inttypes.h
-- Looking for include file inttypes.h - found
-- Looking for include file limits.h
-- Looking for include file limits.h - found
-- Looking for include file malloc.h
-- Looking for include file malloc.h - found
-- Looking for include file memory.h
-- Looking for include file memory.h - found
-- Looking for include file netdb.h
-- Looking for include file netdb.h - found
-- Looking for include file netinet/in.h
-- Looking for include file netinet/in.h - found
-- Looking for include file net/if.h
-- Looking for include file net/if.h - found
-- Looking for include file signal.h
-- Looking for include file signal.h - found
-- Looking for include file socket.h
-- Looking for include file socket.h - not found
-- Looking for include file stdbool.h
-- Looking for include file stdbool.h - found
-- Looking for include file stdint.h
-- Looking for include file stdint.h - found
-- Looking for include file stdlib.h
-- Looking for include file stdlib.h - found
-- Looking for include file strings.h
-- Looking for include file strings.h - found
-- Looking for include file string.h
-- Looking for include file string.h - found
-- Looking for include file stropts.h
-- Looking for include file stropts.h - found
-- Looking for include file sys/ioctl.h
-- Looking for include file sys/ioctl.h - found
-- Looking for include file sys/param.h
-- Looking for include file sys/param.h - found
-- Looking for include file sys/select.h
-- Looking for include file sys/select.h - found
-- Looking for include file sys/stat.h
-- Looking for include file sys/stat.h - found
-- Looking for include file sys/time.h
-- Looking for include file sys/time.h - found
-- Looking for include file sys/uio.h
-- Looking for include file sys/uio.h - found
-- Looking for include file time.h
-- Looking for include file time.h - found
-- Looking for include file dlfcn.h
-- Looking for include file dlfcn.h - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - found
-- Looking for include files sys/types.h, netinet/tcp.h
-- Looking for include files sys/types.h, netinet/tcp.h - found
-- Performing Test HAVE_SOCKLEN_T
-- Performing Test HAVE_SOCKLEN_T - Success
-- Performing Test HAVE_TYPE_SOCKET
-- Performing Test HAVE_TYPE_SOCKET - Failed
-- Performing Test HAVE_BOOL_T
-- Performing Test HAVE_BOOL_T - Success
-- Performing Test HAVE_SSIZE_T
-- Performing Test HAVE_SSIZE_T - Success
-- Performing Test HAVE_LONGLONG
-- Performing Test HAVE_LONGLONG - Success
-- Performing Test HAVE_SIG_ATOMIC_T
-- Performing Test HAVE_SIG_ATOMIC_T - Success
-- Performing Test HAVE_STRUCT_ADDRINFO
-- Performing Test HAVE_STRUCT_ADDRINFO - Success
-- Performing Test HAVE_STRUCT_IN6_ADDR
-- Performing Test HAVE_STRUCT_IN6_ADDR - Success
-- Performing Test HAVE_STRUCT_SOCKADDR_IN6
-- Performing Test HAVE_STRUCT_SOCKADDR_IN6 - Success
-- Performing Test HAVE_STRUCT_SOCKADDR_STORAGE
-- Performing Test HAVE_STRUCT_SOCKADDR_STORAGE - Success
-- Performing Test HAVE_STRUCT_TIMEVAL
-- Performing Test HAVE_STRUCT_TIMEVAL - Success
-- Looking for AF_INET6
-- Looking for AF_INET6 - found
-- Looking for O_NONBLOCK
-- Looking for O_NONBLOCK - found
-- Looking for FIONBIO
-- Looking for FIONBIO - found
-- Looking for SIOCGIFADDR
-- Looking for SIOCGIFADDR - found
-- Looking for MSG_NOSIGNAL
-- Looking for MSG_NOSIGNAL - found
-- Looking for PF_INET6
-- Looking for PF_INET6 - found
-- Looking for SO_NONBLOCK
-- Looking for SO_NONBLOCK - not found
-- Looking for CLOCK_MONOTONIC
-- Looking for CLOCK_MONOTONIC - found
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID - Success
-- Performing Test HAVE_LL
-- Performing Test HAVE_LL - Success
-- Looking for bitncmp
-- Looking for bitncmp - not found
-- Looking for closesocket
-- Looking for closesocket - not found
-- Looking for CloseSocket
-- Looking for CloseSocket - not found
-- Looking for connect
-- Looking for connect - found
-- Looking for fcntl
-- Looking for fcntl - found
-- Looking for freeaddrinfo
-- Looking for freeaddrinfo - found
-- Looking for getaddrinfo
-- Looking for getaddrinfo - found
-- Looking for getenv
-- Looking for getenv - found
-- Looking for gethostbyaddr
-- Looking for gethostbyaddr - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for gethostname
-- Looking for gethostname - found
-- Looking for getnameinfo
-- Looking for getnameinfo - found
-- Looking for getservbyport_r
-- Looking for getservbyport_r - found
-- Looking for getservbyname_r
-- Looking for getservbyname_r - found
-- Looking for gettimeofday
-- Looking for gettimeofday - found
-- Looking for if_indextoname
-- Looking for if_indextoname - found
-- Looking for inet_net_pton
-- Looking for inet_net_pton - not found
-- Looking for inet_ntop
-- Looking for inet_ntop - found
-- Looking for inet_pton
-- Looking for inet_pton - found
-- Looking for ioctl
-- Looking for ioctl - found
-- Looking for ioctlsocket
-- Looking for ioctlsocket - not found
-- Looking for IoctlSocket
-- Looking for IoctlSocket - not found
-- Looking for recv
-- Looking for recv - found
-- Looking for recvfrom
-- Looking for recvfrom - found
-- Looking for send
-- Looking for send - found
-- Looking for setsockopt
-- Looking for setsockopt - found
-- Looking for socket
-- Looking for socket - found
-- Looking for strcasecmp
-- Looking for strcasecmp - found
-- Looking for strcmpi
-- Looking for strcmpi - not found
-- Looking for strdup
-- Looking for strdup - found
-- Looking for stricmp
-- Looking for stricmp - not found
-- Looking for strncasecmp
-- Looking for strncasecmp - found
-- Looking for strncmpi
-- Looking for strncmpi - not found
-- Looking for strnicmp
-- Looking for strnicmp - not found
-- Looking for writev
-- Looking for writev - found
-- Looking for __system_property_get
-- Looking for __system_property_get - not found
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/build/2091615c0a3aac96a800d7728cd62ef397c449d3/build/Release
c-ares/1.18.1: CMake command: cmake --build "/Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/build/2091615c0a3aac96a800d7728cd62ef397c449d3/build/Release" '--' '-j8'
[  2%] Building C object src/lib/CMakeFiles/c-ares.dir/ares__addrinfo2hostent.c.o
[  2%] Building C object src/lib/CMakeFiles/c-ares.dir/ares__parse_into_addrinfo.c.o
[  3%] Building C object src/lib/CMakeFiles/c-ares.dir/ares__read_line.c.o
[  6%] Building C object src/lib/CMakeFiles/c-ares.dir/ares__close_sockets.c.o
[  6%] Building C object src/lib/CMakeFiles/c-ares.dir/ares__sortaddrinfo.c.o
[  7%] Building C object src/lib/CMakeFiles/c-ares.dir/ares__get_hostent.c.o
[  8%] Building C object src/lib/CMakeFiles/c-ares.dir/ares__addrinfo_localhost.c.o
[ 10%] Building C object src/lib/CMakeFiles/c-ares.dir/ares__readaddrinfo.c.o
[ 11%] Building C object src/lib/CMakeFiles/c-ares.dir/ares__timeval.c.o
[ 12%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_android.c.o
[ 14%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_cancel.c.o
[ 15%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_data.c.o
[ 16%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_destroy.c.o
[ 17%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_expand_name.c.o
[ 19%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_expand_string.c.o
[ 21%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_fds.c.o
[ 21%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_free_hostent.c.o
[ 23%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_free_string.c.o
[ 24%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_freeaddrinfo.c.o
[ 25%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_getenv.c.o
[ 26%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_getaddrinfo.c.o
[ 28%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_gethostbyaddr.c.o
[ 29%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_gethostbyname.c.o
[ 30%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_getnameinfo.c.o
[ 32%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_getsock.c.o
[ 33%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_init.c.o
[ 34%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_library_init.c.o
[ 35%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_llist.c.o
[ 37%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_mkquery.c.o
[ 38%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_create_query.c.o
[ 39%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_options.c.o
[ 41%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_nowarn.c.o
[ 42%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_a_reply.c.o
[ 43%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_aaaa_reply.c.o
[ 44%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_caa_reply.c.o
[ 46%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_mx_reply.c.o
[ 47%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_naptr_reply.c.o
[ 48%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_ns_reply.c.o
[ 50%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_ptr_reply.c.o
[ 51%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_soa_reply.c.o
[ 52%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_srv_reply.c.o
[ 53%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_txt_reply.c.o
[ 55%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_parse_uri_reply.c.o
[ 56%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_platform.c.o
[ 57%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_process.c.o
[ 58%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_search.c.o
[ 60%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_query.c.o
[ 61%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_send.c.o
[ 62%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_strcasecmp.c.o
[ 64%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_strdup.c.o
[ 65%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_strerror.c.o
[ 66%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_strsplit.c.o
[ 67%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_timeout.c.o
[ 69%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_version.c.o
[ 70%] Building C object src/lib/CMakeFiles/c-ares.dir/ares_writev.c.o
[ 71%] Building C object src/lib/CMakeFiles/c-ares.dir/bitncmp.c.o
[ 73%] Building C object src/lib/CMakeFiles/c-ares.dir/inet_net_pton.c.o
[ 74%] Building C object src/lib/CMakeFiles/c-ares.dir/inet_ntop.c.o
[ 75%] Building C object src/lib/CMakeFiles/c-ares.dir/windows_port.c.o
[ 76%] Linking C static library ../../lib/libcares.a
[ 76%] Built target c-ares
[ 78%] Building C object src/tools/CMakeFiles/ahost.dir/ahost.c.o
[ 79%] Building C object src/tools/CMakeFiles/ahost.dir/__/lib/ares_nowarn.c.o
[ 80%] Building C object src/tools/CMakeFiles/adig.dir/ares_getopt.c.o
[ 82%] Building C object src/tools/CMakeFiles/acountry.dir/acountry.c.o
[ 83%] Building C object src/tools/CMakeFiles/adig.dir/__/lib/ares_nowarn.c.o
[ 84%] Building C object src/tools/CMakeFiles/adig.dir/adig.c.o
[ 85%] Building C object src/tools/CMakeFiles/ahost.dir/ares_getopt.c.o
[ 87%] Building C object src/tools/CMakeFiles/acountry.dir/ares_getopt.c.o
[ 88%] Building C object src/tools/CMakeFiles/adig.dir/__/lib/ares_strcasecmp.c.o
[ 89%] Building C object src/tools/CMakeFiles/ahost.dir/__/lib/ares_strcasecmp.c.o
[ 91%] Building C object src/tools/CMakeFiles/acountry.dir/__/lib/ares_nowarn.c.o
[ 92%] Building C object src/tools/CMakeFiles/acountry.dir/__/lib/ares_strcasecmp.c.o
[ 93%] Linking C executable ../../bin/ahost
[ 94%] Linking C executable ../../bin/acountry
[ 96%] Built target ahost
[ 97%] Built target acountry
[ 98%] Linking C executable ../../bin/adig
[100%] Built target adig
c-ares/1.18.1: Package '2091615c0a3aac96a800d7728cd62ef397c449d3' built
c-ares/1.18.1: Build folder /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/build/2091615c0a3aac96a800d7728cd62ef397c449d3/build/Release
c-ares/1.18.1: Generated conaninfo.txt
c-ares/1.18.1: Generated conanbuildinfo.txt
c-ares/1.18.1: Generating the package
c-ares/1.18.1: Package folder /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3
c-ares/1.18.1: Calling package()
c-ares/1.18.1: Copied 1 '.md' file: LICENSE.md
c-ares/1.18.1: CMake command: cmake --install "/Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/build/2091615c0a3aac96a800d7728cd62ef397c449d3/build/Release" --prefix "/Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3"
-- Install configuration: "Release"
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/lib/cmake/c-ares/c-ares-targets.cmake
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/lib/cmake/c-ares/c-ares-targets-release.cmake
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/lib/cmake/c-ares/c-ares-config.cmake
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/lib/cmake/c-ares/c-ares-config-version.cmake
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/lib/pkgconfig/libcares.pc
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/include/ares.h
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/include/ares_version.h
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/include/ares_build.h
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/include/ares_rules.h
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/include/ares_dns.h
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/include/ares_nameser.h
-- Installing: /Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3/lib/libcares.a
CMake Error at src/tools/cmake_install.cmake:46 (file):
  file INSTALL cannot find
  "/Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/build/2091615c0a3aac96a800d7728cd62ef397c449d3/build/Release/src/tools/CMakeFiles/CMakeRelink.dir/ahost":
  No such file or directory.
Call Stack (most recent call first):
  src/cmake_install.cmake:48 (include)
  cmake_install.cmake:78 (include)


ERROR: c-ares/1.18.1: Error in package() method, line 76
        cmake.install()
        ConanException: Error 1 while executing cmake --install "/Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/build/2091615c0a3aac96a800d7728cd62ef397c449d3/build/Release" --prefix "/Users/vinayvarma/.conan/data/c-ares/1.18.1/_/_/package/2091615c0a3aac96a800d7728cd62ef397c449d3"
```
user: vvarma
issue_12342: state: open
title: [question] How to separate generator files by requirements and tool requirements
body: In https://github.com/conan-io/conan-center-index/pull/13612

We need to do some hackery in the build script to avoid both the dependencies and build requirements (which overlap) `PkgConfigDeps` being in the same folder.

@jwillikers implemented two different solutions
- one with `PkgConfigDeps.build_context_suffix` and patching the Meson build script to use the new name.
- one with manually copying the files to a seperate folder

Ideally there would be a generator folder for each for the advance case where we need to seperate them.

***

I'll get an error if I don't set the `build_context_suffix` for the `wayland` package because this library requires the `wayland-client` library from the `wayland` package as a regular requires while simultaneously requiring the `wayland-scanner` tool from the `wayland` package as a `tool_requires`.

If we were able to place the build-context pkg-config files in a separate directory from the others, this would avoid naming conflicts and the necessary patching to find the `tool_requires` dependencies. Meson would be able to handle this gracefully just by setting the standard project option `build.pkg_config_path` to a value including the directory for the build-context pkg-config files.

_Originally posted by @jwillikers in https://github.com/conan-io/conan-center-index/pull/13612#discussion_r999896514_
      
user: prince-chrismc
issue_12341: state: open
title: [feature] Run Conan from generic CMakeToolchain file and chainload the generated
body: Dear conan team,

I would like to propose the following feature in order to make Conan easier to use and adopt. The idea is based on a workflow implemented by vcpkg.

### The idea:
* The user provides a toolchain file that is shipped with conan to CMake.
* The user may define additional CMake variables. For example, the path to a conanfile and a profile.
* The generic toolchain file runs Conan which produces a project related toolchain and chainloads it.

I have implemented a prototype for this here: https://github.com/heilkn/conan-toolchain/blob/main/src/conan-toolchain.cmake
You can find an example project using this toolchain file in the test directory of the repository https://github.com/heilkn/conan-toolchain/tree/main/test Please see the CMakePresets.json how the toolchain file and additional variables are passed to CMake and to the toolchain file.

### Problems with the prototype
* For some reason, I have to use the cmake_find_package generator in the conanfile, because the CMakeDeps generator is making the dependency available, but the imported target does not define the include directories.


### My Motivation

I am working with conan for some time already privately and in a bigger corporation with several development teams. My experience has been that I could only introduce Conan because I could make it as transparent as possible for the developers working with me on the projects. Part of the solution was cmake-conan. Unfortunately, that has its own problems and will be deprecated with Conan 2.0. Furthermore, vcpkg is getting more traction in the moment, because it seems to be even easier to use.

I have the impression that the reason for vcpkg's popularity is the ability to point CMake at a generic toolchain file that is installed together with it and rely on the toolchain to manage the everything else.
Developers have the option to pass the toolchain either on the command line when invoking CMake directly, or simply put into the CMakePresets.json. In the latter case, all a developer needs to do is open the CMake project in his IDE of choice and select a CMake configure that is pre-configured to invoke vcpkg.
In this scenario, on-boarding new developers is then simply a matter of installing the required tools, checking out a repository and opening the project. That's it.

However, I am convinced that Conan has for the moment the better solution to handle ABI. Furthermore, some of our teams do already have a collection of recipies and binaries deployed to an Artifactory instance. For that reason, I would like to explore the idea of introducing the ease of use of vcpkg via a generic toolchain file that could be shipped with a future conan installation.

Kind regards

Konstantin

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: heilkn
issue_12340: state: open
title: [question] Using layout() to link pre-built binaries from an editable package
body: Hello, I have a question about using `layout()` and its capabilities. Is it possible to use `layout()` in a conanfile.py to link pre-built binaries from an editable package using the `cmake_multi` generator?

For example, let's say I have a dependency somewhere locally with a basic `include`/`lib` folder structure, and a conanfile.py that copies pre-built binaries from a directory:

```
from conans import ConanFile

class TestConan(ConanFile):
name = "testpackage"
version = "1.0"
settings = "os", "compiler", "build_type", "arch"
exports_sources = "*"
no_copy_source = True

def layout(self):
	self.cpp.package.libs = ['lib']
	self.cpp.package.includedirs = ['include']
	
	self.cpp.source.libdirs = ['lib'] 
	self.cpp.source.includedirs = ['include']

	self.cpp.build.libdirs = ['lib']

def package(self):
	self.copy("*.h")
	self.copy("*.lib")

def package_info(self):
	self.cpp_info.libs = self.collect_libs()
```

With this layout, requiring `testpackage` in another package adds the include directory to the project as expected, but it does not work for linking libraries. I can examine one of the `conanbuildinfo.cmake` files and see that CONAN_LIB_DIRS_TESTPACKAGE is the expected folder path, but it is not collecting the libs from the folder to actually link. I notice when comparing testpackage's section to other working package sections that a few variables are empty when they probably shouldn't be, such as `CONAN_BUILD_DIRS_TESTPACKAGE_DEBUG`, and more importantly, `CONAN_LIBS_TESTPACKAGE_DEBUG` and `CONAN_PKG_LIBS_TESTPACKAGE_DEBUG` do not contain the libs that should be linked. 

conanbuildinfo_debug.cmake:
```
#################
###  TESTPACKAGE
#################
set(CONAN_TESTPACKAGE_ROOT_DEBUG "C:/path/testpackage")
set(CONAN_INCLUDE_DIRS_TESTPACKAGE_DEBUG "C:/path/testpackage/include")
set(CONAN_LIB_DIRS_TESTPACKAGE_DEBUG "C:/path/testpackage/lib")
set(CONAN_BIN_DIRS_TESTPACKAGE_DEBUG )
set(CONAN_RES_DIRS_TESTPACKAGE_DEBUG )
set(CONAN_SRC_DIRS_TESTPACKAGE_DEBUG )
set(CONAN_BUILD_DIRS_TESTPACKAGE_DEBUG )
set(CONAN_FRAMEWORK_DIRS_TESTPACKAGE_DEBUG )
set(CONAN_LIBS_TESTPACKAGE_DEBUG )
set(CONAN_PKG_LIBS_TESTPACKAGE_DEBUG )
```

Is there a step missing that is needed to grab the lib files from the lib directory? I am using `conan_basic_setup()` in the driver project to link the libs. Could this be the source of the issue? Or is it a compatibility issue with `cmake_multi`? I am unable to make the jump to `CMakeDeps` or `CmakeToolchain` generator at this time.

Thanks very much for your time, and I appreciate any feedback!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: daywhirls
issue_12339: state: open
title: [question] Example profiles for `--profile:host` and `--profile:build` when using MSVC compilers?
body: Typically, there are about 4 types of MSVC compilers:

```
%VCToolsInstallDir%\bin\Hostx64\x64\cl.exe
%VCToolsInstallDir%\bin\Hostx64\x86\cl.exe
%VCToolsInstallDir%\bin\Hostx86\x64\cl.exe
%VCToolsInstallDir%\bin\Hostx86\x86\cl.exe
```

According to the [documentation](https://docs.conan.io/en/latest/systems_cross_building/cross_building.html#host-settings-os-build-arch-build-os-target-and-arch-target), using `arch` and `arch_build` for cross-compiling is not recommended. Instead, it is encouraged to use `--profile:host` and `--profile:build` to specify two profiles, respectively.

Can Conan Official or someone provide the basic examples of **Host Profile** and **Build Profile** when using these 4 types of MSVC compilers?

1.  Using `-T host=x64 -A x64` argument with Visual Studio generator.
2.  Using `-T host=x64 -A Win32` argument with Visual Studio generator.
3.  Using `-T host=x86 -A x64` argument with Visual Studio generator.
4.  Using `-T host=x86 -A Win32` argument with Visual Studio generator.


user: hwhsu1231
issue_12337: state: open
title: what method and at what stage is responsible for compression
body: Hi there,
I have created the simple recipe, exported hierarchy into local cache export folder, created a package (copied all files into local cache package folder). Now i need to upload the package into artifactory and was thinking to compress files hierarchy prior to that. I searched in the reference and couldn't find any zip/archive/compress related functionality (btw found the unzip method). What do i miss?
user: whitefluffypenguin
issue_12336: state: open
title: [feature] Add `is_cl_like()` or improve `is_msvc()` method to perfectly mimic behavior of `MSVC` variable in CMake
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Currently conan provides `is_msvc()` method which returns True if `compiler=Visual Studio` or `compiler=msvc` in settings. In conan-center recipes, this method is widely used for different logics, and one of them is for some branching in package() and package_info() depending on `MSVC` variable in upstream CMakeLists (conditional lib name, renaming of files, injection of definitions etc).
But `MSVC` variable in CMake is not only True for Visual Studio, but also for any cl like compiler like clang-cl: https://cmake.org/cmake/help/latest/variable/MSVC.html
The problem is that depending on clang flavor on Windows, it may or may not be a cl like compiler for CMake. It leads to wrong assumption in several recipes, for example zlib where `cpp_info.libs` may be wrong depending on clang flavor: https://github.com/conan-io/conan-center-index/issues/13474

For example a CMakeLists may have this:

```cmake
add_library(mylib ...)
if(MSVC AND NOT BUILD_SHARED_LIBS)
    set_target_properties(mylib PROPERTIES OUTPUT_NAME "mylib-static")
endif()
```

so that in conan recipe we usually write:

```python
    package_info(self):
        suffix = "-static" if is_msvc(self) and not self.options.shared else ""
        self.cpp_info.libs = [f"mylib{suffix}"]
```

It's very common, and it's broken for clang-cl.

So some folks using clang-cl were disappointed and began to put this kind of snippet in CCI recipes (and this time it's broken for non cl-like clang flavors on windows, so other folks complain that their clang flavor on windows doesn't work anymore):

```python
    @property
    def _is_clang_cl(self):
        return self.settings.os == "Windows" and self.settings.compiler == "clang"

    package_info(self):
        suffix = "-static" if (is_msvc(self) or self._is_clang_cl) and not self.options.shared else ""
        self.cpp_info.libs = [f"mylib{suffix}"]
```

So it would be nice if conan could provide a method to perfectly mimic https://cmake.org/cmake/help/latest/variable/MSVC.html logic. It may be another method than `is_msvc`, or an additional argument to `is_msvc` in order to switch to CMake `MSVC` behavior.
user: SpaceIm
issue_12331: state: open
title: [question] cmake doesn't find the package folder even though it exists.
body: CMake Error in CMakeLists.txt:
  Imported target "magic_enum::magic_enum" includes non-existent path

    "/home/mrv/.conan/data/magic_enum/0.8.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.

My conanfile.txt:
```
[requires]
magic_enum/0.8.0
[generators]
CMakeDeps
CMakeToolchain
```
My Cmakelists.txt:
```
cmake_minimum_required(VERSION 3.12)
set(CMAKE_CXX_STANDARD 20)
project(code_architecture CXX)

include(third_party/userver/cmake/SetupEnvironment.cmake)
include(GNUInstallDirs)

add_subdirectory(third_party/userver)

include(conan_libraries/conan_toolchain.cmake)
find_package(magic_enum REQUIRED)

include_directories(src)

# Common sources
add_library(${PROJECT_NAME}_objs OBJECT
		src/handlers/get_check/view.hpp
		src/handlers/get_check/view.cpp
		src/schemes/categories/Category.hpp
		src/schemes/ErrorGoods.hpp
		src/schemes/categories/Common.hpp
		src/schemes/categories/impl/Common.cpp
		src/schemes/consumers/Consumer.hpp
		src/schemes/categories/impl/Special.cpp
		src/schemes/categories/Special.hpp
		src/schemes/categories/impl/Receipt.cpp
		src/schemes/categories/Receipt.hpp
		src/schemes/consumers/impl/User.cpp
		src/schemes/consumers/User.hpp
		src/schemes/bases/impl/UserReceipts.cpp
		src/schemes/bases/UserReceipts.hpp
		src/schemes/consumers/impl/Doctor.cpp
		src/schemes/consumers/Doctor.hpp
		src/schemes/consumers/impl/UnknownConsumer.cpp
		src/schemes/consumers/UnknownConsumer.hpp
		src/schemes/fabrics/impl/UserFabric.cpp
		src/schemes/fabrics/UserFabric.hpp
		src/schemes/fabrics/AbstractConsumerFabric.hpp
		src/schemes/fabrics/impl/DoctorFabric.cpp
		src/schemes/fabrics/DoctorFabric.hpp
		src/schemes/fabrics/impl/ConsumersFabric.cpp
		src/schemes/fabrics/ConsumersFabric.hpp
)


target_link_libraries(${PROJECT_NAME}_objs PUBLIC userver-core userver-postgresql)
target_link_libraries(${PROJECT_NAME}_objs PUBLIC magic_enum::magic_enum)

# The Service
add_executable(${PROJECT_NAME} src/main.cpp)
target_link_libraries(${PROJECT_NAME} PRIVATE ${PROJECT_NAME}_objs)


# Unit Tests
add_executable(${PROJECT_NAME}_unittest)
target_link_libraries(${PROJECT_NAME}_unittest PRIVATE ${PROJECT_NAME}_objs userver-utest)
add_google_tests(${PROJECT_NAME}_unittest)


# Benchmarks
add_executable(${PROJECT_NAME}_benchmark
		)
target_link_libraries(${PROJECT_NAME}_benchmark PRIVATE ${PROJECT_NAME}_objs userver-ubench)
add_google_benchmark_tests(${PROJECT_NAME}_benchmark)

# Functional Tests
add_subdirectory(tests)

if(DEFINED ENV{PREFIX})
	message(STATUS "Set install prefix: $ENV{PREFIX}")
	file(TO_CMAKE_PATH "$ENV{PREFIX}" PREFIX_PATH)
	set(CMAKE_INSTALL_PREFIX ${PREFIX_PATH})
endif()

set(CONFIG_VAR_PATH ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_SYSCONFDIR}/${PROJECT_NAME}/config_vars.yaml)
set(CONFIG_FALLBACK_PATH ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_SYSCONFDIR}/${PROJECT_NAME}/dynamic_config_fallback.json)

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/configs/static_config.yaml.in ${CMAKE_CURRENT_SOURCE_DIR}/configs/static_config.yaml)

FILE(GLOB CONFIGS_FILES ${CMAKE_CURRENT_SOURCE_DIR}/configs/*.yaml ${CMAKE_CURRENT_SOURCE_DIR}/configs/*.json)

install(TARGETS ${PROJECT_NAME} DESTINATION ${CMAKE_INSTALL_BINDIR} COMPONENT ${PROJECT_NAME})
install(FILES ${CONFIGS_FILES} DESTINATION ${CMAKE_INSTALL_SYSCONFDIR}/${PROJECT_NAME} COMPONENT ${PROJECT_NAME})
```
My script to expand conan files:
```
conan install . --build=missing --install-folder conan_libraries --profile debug
```
Can anyoune help me?

user: sabudilovskiy
issue_12330: state: open
title: profile detail in artifactory and include function in conanfile.txt
body: Basically I have 2 different question.
1. Does Artifactory store detail of the profile? scenario (We want to be able to find with which profile, a project was built in ten years from now.)
2. we have following structure of the project, where we have **common** and **variation_point 1** and **variation_point 2** and each folder contains different source header and conanfile.txt file for dependencies.

> while building variation_point 1 we want to add conanfile.txt dependencies of variation_point 1 and common and same while building variation_point 2, adding conanfile.txt of variation_point 2 and common.
> but when we install dependencies from conanfile.txt while building in sequential manner, conanbuildinfo.cmake gets updated with last conan install call.
> we want to merger common and variation_point 1's conanfile.txt while building variation_point 1 and Variation_point 2 and common's conanfile.txt while building variation_point 2. 
is there any possibility to add these conanfile.txt while installing dependencies?
user: himansu2906
issue_12329: state: open
title: [bug] virtualenv + build with two profiles does not work
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: ubuntu:latest
  * Compiler+version: gcc 11 and 10.02
  * Conan version: latest

### Steps to reproduce (Include if Applicable)
git clone git@github.com:AndreyMlashkin/minimalistic_conan_docker.git
cd minimalistic_conan_docker
docker build.

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
docker build .
Sending build context to Docker daemon  186.9kB
Step 1/11 : FROM ubuntu:latest
 ---> 216c552ea5ba
Step 2/11 : RUN   apt-get update &&   apt-get install -y python3 python3-pip
 ---> Using cache
 ---> 7e182ff23d42
Step 3/11 : RUN pip3 install conan
 ---> Using cache
 ---> c9034751fa78
Step 4/11 : RUN apt-get update && apt-get install -y make gcc g++ cmake
 ---> Using cache
 ---> bf24faea9af3
Step 5/11 : COPY build_profile /root/.conan/profiles/build_profile
 ---> Using cache
 ---> f5807b54a01f
Step 6/11 : COPY requirements.txt requirements.txt
 ---> Using cache
 ---> 8a91ae72e657
Step 7/11 : RUN conan install requirements.txt --build missing -g virtualenv -pr build_profile
 ---> Using cache
 ---> ac272df030c2
Step 8/11 : RUN apt-get remove -y make gcc g++
 ---> Using cache
 ---> 592c3278d6f7
Step 9/11 : COPY host_profile /root/.conan/profiles/host_profile
 ---> Using cache
 ---> 4d8e7e33b5fe
Step 10/11 : RUN ls -l -a && chmod +x activate.sh && . ./activate.sh && cmake --help && echo $CC && echo $CXX && conan install zlib/1.2.12@ --build zlib -pr:b=host_profile -pr:h=host_profile --build missing
 ---> Running in 373f9b3f97d5
/root/.conan/data/gcc/10.2.0/_/_/package/62dc4bccd4f53b2b80985003a91278369abf3a4b/bin/gcc-10.2.0
/root/.conan/data/gcc/10.2.0/_/_/package/62dc4bccd4f53b2b80985003a91278369abf3a4b/bin/g++-10.2.0
Configuration (profile_host):
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=10.2
os=Linux
os_build=Linux
[options]
*:shared=False
cmake:with_openssl=False
[build_requires]
*: gcc/10.2.0, make/4.3, cmake/3.24.1
[env]
CMAKE_MAKE_PROGRAM=make
Configuration (profile_build):
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=10.2
os=Linux
os_build=Linux
[options]
*:shared=False
cmake:with_openssl=False
[build_requires]
*: gcc/10.2.0, make/4.3, cmake/3.24.1
[env]
CMAKE_MAKE_PROGRAM=make
zlib/1.2.12: Not found in local cache, looking in remotes...
zlib/1.2.12: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
zlib/1.2.12: Downloaded recipe revision 0
zlib/1.2.12: Forced build from source
WARN: mpfr/4.1.0: requirement gmp/6.2.1 overridden by mpc/1.2.0 to gmp/6.2.0 
zlib/1.2.11: Forced build from source
Installing package: zlib/1.2.12
Requirements
    zlib/1.2.12 from 'conancenter' - Downloaded
Packages
    zlib/1.2.12:30b88e95da2480aa597d26d85ba6f64038dcf40f - Build
Build requirements
    cmake/3.24.1 from 'conancenter' - Cache
    gcc/10.2.0 from 'conancenter' - Cache
    gmp/6.2.0 from 'conancenter' - Cache
    m4/1.4.19 from 'conancenter' - Cache
    make/4.3 from 'conancenter' - Cache
    mpc/1.2.0 from 'conancenter' - Cache
    mpfr/4.1.0 from 'conancenter' - Cache
    zlib/1.2.11 from 'conancenter' - Cache
Build requirements packages
    cmake/3.24.1:24647d9fe8ec489125dfbae4b3ebefaf7581674c - Cache
    gcc/10.2.0:62dc4bccd4f53b2b80985003a91278369abf3a4b - Cache
    gmp/6.2.0:449e527ce175490ba11c311028c9de6c454c619d - Build
    m4/1.4.19:24647d9fe8ec489125dfbae4b3ebefaf7581674c - Cache
    make/4.3:24647d9fe8ec489125dfbae4b3ebefaf7581674c - Cache
    mpc/1.2.0:c85de02642e2f4278d35ceee0e20ee832ddf4d22 - Build
    mpfr/4.1.0:391fe236ce3998076d9584f892788bce90ab14e0 - Build
    zlib/1.2.11:30b88e95da2480aa597d26d85ba6f64038dcf40f - Build

Installing (downloading, building) binaries...
cmake/3.24.1: Already installed!
cmake/3.24.1: Appending PATH environment variable: /root/.conan/data/cmake/3.24.1/_/_/package/24647d9fe8ec489125dfbae4b3ebefaf7581674c/bin
m4/1.4.19: Already installed!
m4/1.4.19: Appending PATH environment variable: /root/.conan/data/m4/1.4.19/_/_/package/24647d9fe8ec489125dfbae4b3ebefaf7581674c/bin
make/4.3: Already installed!
make/4.3: Creating CONAN_MAKE_PROGRAM environment variable: /root/.conan/data/make/4.3/_/_/package/24647d9fe8ec489125dfbae4b3ebefaf7581674c/bin/make
Downloading conan_sources.tgz
zlib/1.2.11: Configuring sources in /root/.conan/data/zlib/1.2.11/_/_/source/src
zlib/1.2.11: 
zlib/1.2.11: Copying sources to build folder
zlib/1.2.11: Building your package in /root/.conan/data/zlib/1.2.11/_/_/build/30b88e95da2480aa597d26d85ba6f64038dcf40f
zlib/1.2.11: Generator txt created conanbuildinfo.txt
zlib/1.2.11: Calling generate()
zlib/1.2.11: Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
zlib/1.2.11: If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/root/.conan/data/zlib/1.2.11/_/_/build/30b88e95da2480aa597d26d85ba6f64038dcf40f/build/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
zlib/1.2.11: Aggregating env generators
zlib/1.2.11: Calling build()
zlib/1.2.11: CMake command: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/root/.conan/data/zlib/1.2.11/_/_/build/30b88e95da2480aa597d26d85ba6f64038dcf40f/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/root/.conan/data/zlib/1.2.11/_/_/package/30b88e95da2480aa597d26d85ba6f64038dcf40f" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/root/.conan/data/zlib/1.2.11/_/_/build/30b88e95da2480aa597d26d85ba6f64038dcf40f/src"
-- Using Conan toolchain: /root/.conan/data/zlib/1.2.11/_/_/build/30b88e95da2480aa597d26d85ba6f64038dcf40f/build/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also "/root/.conan/data/zlib/1.2.11/_/_/build/30b88e95da2480aa597d26d85ba6f64038dcf40f/build/Release/CMakeFiles/CMakeOutput.log".
zlib/1.2.11: 
zlib/1.2.11: ERROR: Package '30b88e95da2480aa597d26d85ba6f64038dcf40f' build failed
zlib/1.2.11: WARN: Build folder /root/.conan/data/zlib/1.2.11/_/_/build/30b88e95da2480aa597d26d85ba6f64038dcf40f/build/Release
ERROR: zlib/1.2.11: Error in build() method, line 88
	cmake.configure()
	ConanException: Error 1 while executing cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/root/.conan/data/zlib/1.2.11/_/_/build/30b88e95da2480aa597d26d85ba6f64038dcf40f/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/root/.conan/data/zlib/1.2.11/_/_/package/30b88e95da2480aa597d26d85ba6f64038dcf40f" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/root/.conan/data/zlib/1.2.11/_/_/build/30b88e95da2480aa597d26d85ba6f64038dcf40f/src"
The command '/bin/sh -c ls -l -a && chmod +x activate.sh && . ./activate.sh && cmake --help && echo $CC && echo $CXX && conan install zlib/1.2.12@ --build zlib -pr:b=host_profile -pr:h=host_profile --build missing' returned a non-zero code: 1

-->

user: AndreyMlashkin
issue_12326: state: open
title: [feature] Allow self.name in tools.cmake.cmake_layout:build_folder_vars
body: In our org we have multiple recipes with a shared code basis. The directory structure is as following:
```sh
.
├── CMakeLists.txt
├── simple_example.cc
├── sub1
│   └── conanfile.py
└── sub2
    └── conanfile.py
```
The conan files look something like this:
```python
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMake, cmake_layout

class sub2Recipe(ConanFile):
    name = "sub2"
    version = "1.0"
    def layout(self):
        cmake_layout(self, generator="Ninja", src_folder="..")

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
```
When I now run:
```sh
 conan install sub1/conanfile.py
 conan install sub2/conanfile.py
``` 

I get a CMakeUserPresets.json that refers to both CMakePresets.json in their respective `subX/build/generators/CMakePresets.json` folder. The problem now is that for both CMakePresets the names are identical:
```json
    "configurePresets": [
        {
            "name": "release",
            "displayName": "'release' config",
            "description": "'release' configure using 'Unix Makefiles' generator",
            ...
        }
    ],
    "buildPresets": [
        {
            "name": "release",
            "configurePreset": "release"
        }
    ],
```

VSCode will show both displayNames and it is impossible to tell which one is going to build what.

So my idea of how to fix that would be the following, allow to run install like this:
```sh
conan install -ctools.cmake.cmake_layout:build_folder_vars="['self.name']" sub1/conanfile.py
```

Which results in:
```json
    "configurePresets": [
        {
            "name": "sub1-release",
            "displayName": "'sub1-release' config",
            "description": "'sub1-release' configure using 'Unix Makefiles' generator",
            ...
        }
    ],
    "buildPresets": [
        {
            "name": "sub1-release",
            "configurePreset": "sub1-release"
        }
    ],
```

Another nice side-effect is that I can also have a common build folder at the "root":
```
cmake_layout(self, generator="Ninja", src_folder="..", build_folder="../build")
```

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: KarstenB
issue_12325: state: open
title: [bug] CMake configure presets only work once
body: ### Environment Details
  * Conan version: 1.51.3

### Steps to reproduce (Include if Applicable)

```
conan install . -s compiler=Visual Studio -s compiler.version=16 -s arch=x86_64 ...
cmake --preset windows-x86_64
cmake --preset windows-x86_64
```

### Logs (Executed commands with output)

```log
> cmake --preset windows-x86_64
Preset CMake variables:

  CMAKE_POLICY_DEFAULT_CMP0091="NEW"
  CMAKE_TOOLCHAIN_FILE:FILEPATH="...\build\windows-x86_64\generators\conan_toolchain.cmake"

CMake Error: Error: generator platform:
Does not match the platform used previously: x64
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
```

### Expected behavior:

After manuall adding `architecture=x64` to the generated preset, cmake works as expected.
```json
            "generator": "Visual Studio 16 2019",
            "architecture": "x64",
```

When using `-c "tools.cmake.cmaketoolchain:generator=Ninja"` the problem is not reproduceable but this is not a solution since this doesn't generate a VS solution.
user: stefansli
issue_12324: state: open
title: [feature] Consider porting conans.tools.cppstd_flag to Conan 2.0
body: #### Suggestion

Port `conans.tools.cppstd_flag` to `conan.tools.build.cppstd_flag`


#### Why?

Some projects use a limited build script which require our manual intervention, passing all needed compiler flags, including `libcxx`, `cppstd`, `build_type`, `fPIC`, ... For those cases, we need to honor the `cppstd` version from the profile with what will be used by the compiler.

As a real example from CCI: https://github.com/conan-io/conan-center-index/pull/13552/files#diff-a3929dbede89f0e2d22b994ee16d101290e2d32f05767c52cc580a4edf1d950eR198

As we need to translate `cppstd` to the compiler flag, `cppstd_flag` would help us.


- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: uilianries
issue_12323: state: open
title: [question/bug] correct way to use custom Make program on Windows
body: I'm trying to build some CCI recipes that require Autotools, using Windows 8.1 x86 with msvc 2019. Building recipes with CMake works fine.

I can't install MSYS2 from ConanCenter because it requires x64, so I have the following configuration:

```
# conan.conf
[general]
bash_path = c:\Program Files\Git\bin\bash.exe
```

```
# global.conf
tools.microsoft.bash:path = c:\Program Files\Git\bin\bash.exe
tools.microsoft.bash:subsystem = msys2
```

Initially Autotools recipes failed because they couldn't find `make`. First, I tried to set `nmake` (and path to `jom`) to `conan_make_program` and `tools.gnu:make_program`, but those can't parse generated Makefiles. Then I found `gmake` in my Strawberry Perl distribution and now using it:

```
# conan.conf
[general]
conan_make_program = /c/Strawberry/c/bin/gmake.exe
```

```
# global.conf
tools.gnu:make_program = /c/Strawberry/c/bin/gmake.exe
```

It got me initial `make` command running, but then it fails with strange errors anyway. I'm not sure if I'm simply missing something or it's a bug in Conan or a bug in recipes?

<details><summary>libiconv</summary>

```
> conan install libiconv/1.17@ --build=missing --profile:build=default --profile:host=default
DEBUG :conan_api.py   [176]: INIT: Using config 'C:\Users\kamba_000\.conan\conan.conf' [2022-10-17 20:17:55,790]
DEBUG :tracer.py      [156]: CONAN_API: install_reference(settings=None,options=None,env=None,conf=None,profile_names=['default'],profile_build=ProfileData(profiles=['default'], settings=None, options=None, env=None, conf=None),remote_name=None,verify=None,manifests=None,manifests_interactive=None,build=['missing'],update=False,generators=None,install_folder=None,lockfile=None,lockfile_out=None,lockfile_node_id=None,is_build_require=False,require_overrides=None) [2022-10-17 20:17:55,795]
DEBUG :profile_loader.py[120]: PROFILE LOAD: C:\Users\kamba_000\.conan\profiles\default [2022-10-17 20:17:55,804]
DEBUG :profile_loader.py[120]: PROFILE LOAD: C:\Users\kamba_000\.conan\profiles\default [2022-10-17 20:17:55,807]
INFO  :settings_preprocessor.py[56]: Setting 'compiler.runtime' not declared, automatically adjusted to 'MD' [2022-10-17 20:17:55,978]
DEBUG :profile_loader.py[120]: PROFILE LOAD: C:\Users\kamba_000\.conan\profiles\default [2022-10-17 20:17:55,980]
DEBUG :profile_loader.py[120]: PROFILE LOAD: C:\Users\kamba_000\.conan\profiles\default [2022-10-17 20:17:55,983]
INFO  :settings_preprocessor.py[56]: Setting 'compiler.runtime' not declared, automatically adjusted to 'MD' [2022-10-17 20:17:56,165]
Configuration (profile_host):
[settings]
arch=x86
arch_build=x86
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
tools.gnu:make_program=/c/Strawberry/c/bin/gmake.exe
tools.microsoft.bash:path=c:\Program Files\Git\bin\bash.exe
tools.microsoft.bash:subsystem=msys2

Configuration (profile_build):
[settings]
arch=x86
arch_build=x86
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
tools.gnu:make_program=/c/Strawberry/c/bin/gmake.exe
tools.microsoft.bash:path=c:\Program Files\Git\bin\bash.exe
tools.microsoft.bash:subsystem=msys2

DEBUG :graph_builder.py[462]: GRAPH: new_node: libiconv/1.17 [2022-10-17 20:17:56,209]
DEBUG :graph_builder.py[69]: GRAPH: Time to load deps 0.02300095558166504 [2022-10-17 20:17:56,210]
libiconv/1.17: WARN: Package binary is corrupted, removing: 29d1f4003b3f7143826ef1988625574513d526ce
DEBUG :rest_client_common.py[160]: REST: ping: https://center.conan.io/v1/ping [2022-10-17 20:17:56,219]
DEBUG :rest_client.py [58]: REST: Cached capabilities for the remote: ['complex_search', 'checksum_deploy', 'revisions', 'matrix_params'] [2022-10-17 20:18:05,531]
DEBUG :rest_client_common.py[188]: REST: get: https://center.conan.io/v2/conans/libiconv/1.17/_/_/revisions/3832bf4490d1a4ed8eae6722927ce589/packages/29d1f4003b3f7143826ef1988625574513d526ce/latest [2022-10-17 20:18:05,533]
DEBUG :rest_client_common.py[30]: REST ERROR: <class 'conans.errors.NotFoundException'> [2022-10-17 20:18:05,691]
Installing package: libiconv/1.17
Requirements
    libiconv/1.17 from 'conancenter' - Cache
Packages
    libiconv/1.17:29d1f4003b3f7143826ef1988625574513d526ce - Build

Installing (downloading, building) binaries...
libiconv/1.17: WARN: Build folder is dirty, removing it: D:\conan-data\libiconv\1.17\_\_\build\29d1f4003b3f7143826ef1988625574513d526ce
libiconv/1.17: Copying sources to build folder
DEBUG :installer.py   [128]: BUILD: Copied to D:\conan-data\libiconv\1.17\_\_\build\29d1f4003b3f7143826ef1988625574513d526ce [2022-10-17 20:18:07,302]
DEBUG :installer.py   [129]: BUILD: Files copied src [2022-10-17 20:18:07,303]
libiconv/1.17: Building your package in D:\conan-data\libiconv\1.17\_\_\build\29d1f4003b3f7143826ef1988625574513d526ce
INFO  :installer.py   [133]: GENERATORS: Writing generators [2022-10-17 20:18:07,308]
libiconv/1.17: Generator txt created conanbuildinfo.txt
INFO  :installer.py   [137]: TOOLCHAIN: Writing toolchain [2022-10-17 20:18:07,311]
libiconv/1.17: Calling generate()
INFO  :runners.py     [87]: Calling command: "C:\Program Files\Microsoft Visual Studio\Installer\vswhere.exe" -format json -legacy -nologo > "C:\Users\KAMBA_~1\AppData\Local\Temp\tmppt1rsgzd\output" [2022-10-17 20:18:07,331]
INFO  :runners.py     [90]: Return code: 0 [2022-10-17 20:18:07,412]
INFO  :runners.py     [98]: Output: in file:[
                              {
                                "instanceId": "fee8c4cb",
                                "installDate": "2021-10-20T11:04:09Z",
                                "installationName": "VisualStudio/16.11.17+32630.194",
                                "installationPath": "C:\\Program Files\\Microsoft Visual Studio\\2019\\Community",
                                "installationVersion": "16.11.32630.194",
                                "productId": "Microsoft.VisualStudio.Product.Community",
                                "productPath": "C:\\Program Files\\Microsoft Visual Studio\\2019\\Community\\Common7\\IDE\\devenv.exe",
                                "state": 4294967295,
                                "isComplete": true,
                                "isLaunchable": true,
                                "isPrerelease": false,
                                "isRebootRequired": false,
                                "displayName": "Visual Studio Communityÿ2019",
                                "description": "Œ®é­ ï ¨­â¥£à¨à®¢ ­­ ï áà¥¤  à §à ¡®âª¨, ¡¥á¯« â­ ï ¤«ï áâã¤¥­â®¢, ãç áâ­¨ª®¢ ¯à®¥ªâ®¢ á ®âªàëâë¬ ª®¤®¬ ¨ ®â¤¥«ì­ëå ¯®«ì§®¢ â¥«¥©.",
                                "channelId": "VisualStudio.16.Release",
                                "channelUri": "https://aka.ms/vs/16/release/channel",
                                "enginePath": "C:\\Program Files\\Microsoft Visual Studio\\Installer\\resources\\app\\ServiceHub\\Services\\Microsoft.VisualStudio.Setup.Service",
                                "releaseNotes": "https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes-v16.11#16.11.17",
                                "thirdPartyNotices": "https://go.microsoft.com/fwlink/?LinkId=660909",
                                "updateDate": "2022-07-13T13:32:31.8287797Z",
                                "catalog": {
                                  "buildBranch": "d16.11",
                                  "buildVersion": "16.11.32630.194",
                                  "id": "VisualStudio/16.11.17+32630.194",
                                  "localBuild": "build-lab",
                                  "manifestName": "VisualStudio",
                                  "manifestType": "installer",
                                  "productDisplayVersion": "16.11.17",
                                  "productLine": "Dev16",
                                  "productLineVersion": "2019",
                                  "productMilestone": "RTW",
                                  "productMilestoneIsPreRelease": "False",
                                  "productName": "Visual Studio",
                                  "productPatchVersion": "17",
                                  "productPreReleaseMilestoneSuffix": "1.0",
                                  "productSemanticVersion": "16.11.17+32630.194",
                                  "requiredEngineVersion": "2.11.69.53063"
                                },
                                "properties": {
                                  "campaignId": "2011",
                                  "channelManifestId": "VisualStudio.16.Release/16.11.17+32630.194",
                                  "nickname": "",
                                  "setupEngineFilePath": "C:\\Program Files\\Microsoft Visual Studio\\Installer\\setup.exe"
                                }
                              }
                            ]

                            stdout: None
                            stderr:b'' [2022-10-17 20:18:07,415]
INFO  :runners.py     [87]: Calling command: "C:\Program Files\Microsoft Visual Studio\Installer\vswhere.exe" -format json -products * -nologo > "C:\Users\KAMBA_~1\AppData\Local\Temp\tmpdyak04js\output" [2022-10-17 20:18:07,428]
INFO  :runners.py     [90]: Return code: 0 [2022-10-17 20:18:07,486]
INFO  :runners.py     [98]: Output: in file:[
                              {
                                "instanceId": "fee8c4cb",
                                "installDate": "2021-10-20T11:04:09Z",
                                "installationName": "VisualStudio/16.11.17+32630.194",
                                "installationPath": "C:\\Program Files\\Microsoft Visual Studio\\2019\\Community",
                                "installationVersion": "16.11.32630.194",
                                "productId": "Microsoft.VisualStudio.Product.Community",
                                "productPath": "C:\\Program Files\\Microsoft Visual Studio\\2019\\Community\\Common7\\IDE\\devenv.exe",
                                "state": 4294967295,
                                "isComplete": true,
                                "isLaunchable": true,
                                "isPrerelease": false,
                                "isRebootRequired": false,
                                "displayName": "Visual Studio Communityÿ2019",
                                "description": "Œ®é­ ï ¨­â¥£à¨à®¢ ­­ ï áà¥¤  à §à ¡®âª¨, ¡¥á¯« â­ ï ¤«ï áâã¤¥­â®¢, ãç áâ­¨ª®¢ ¯à®¥ªâ®¢ á ®âªàëâë¬ ª®¤®¬ ¨ ®â¤¥«ì­ëå ¯®«ì§®¢ â¥«¥©.",
                                "channelId": "VisualStudio.16.Release",
                                "channelUri": "https://aka.ms/vs/16/release/channel",
                                "enginePath": "C:\\Program Files\\Microsoft Visual Studio\\Installer\\resources\\app\\ServiceHub\\Services\\Microsoft.VisualStudio.Setup.Service",
                                "releaseNotes": "https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes-v16.11#16.11.17",
                                "thirdPartyNotices": "https://go.microsoft.com/fwlink/?LinkId=660909",
                                "updateDate": "2022-07-13T13:32:31.8287797Z",
                                "catalog": {
                                  "buildBranch": "d16.11",
                                  "buildVersion": "16.11.32630.194",
                                  "id": "VisualStudio/16.11.17+32630.194",
                                  "localBuild": "build-lab",
                                  "manifestName": "VisualStudio",
                                  "manifestType": "installer",
                                  "productDisplayVersion": "16.11.17",
                                  "productLine": "Dev16",
                                  "productLineVersion": "2019",
                                  "productMilestone": "RTW",
                                  "productMilestoneIsPreRelease": "False",
                                  "productName": "Visual Studio",
                                  "productPatchVersion": "17",
                                  "productPreReleaseMilestoneSuffix": "1.0",
                                  "productSemanticVersion": "16.11.17+32630.194",
                                  "requiredEngineVersion": "2.11.69.53063"
                                },
                                "properties": {
                                  "campaignId": "2011",
                                  "channelManifestId": "VisualStudio.16.Release/16.11.17+32630.194",
                                  "nickname": "",
                                  "setupEngineFilePath": "C:\\Program Files\\Microsoft Visual Studio\\Installer\\setup.exe"
                                }
                              }
                            ]

                            stdout: None
                            stderr:b'' [2022-10-17 20:18:07,487]
libiconv/1.17: Aggregating env generators
DEBUG :build.py       [11]: Call conanfile.build() with files in build folder: ['conan', 'conanbuildinfo.txt'] [2022-10-17 20:18:07,517]
libiconv/1.17: Calling build()
libiconv/1.17: apply_conandata_patches(): No patches defined in conandata
libiconv/1.17: Calling:
 > "/d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/configure" --disable-shared --enable-static --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include

----Running------
> "D:\conan-data\libiconv\1.17\_\_\build\29d1f4003b3f7143826ef1988625574513d526ce\build-release\conan\conanbuild.bat" && "D:\conan-data\libiconv\1.17\_\_\build\29d1f4003b3f7143826ef1988625574513d526ce\build-release\conan\msys2_mode.bat" && "c:\Program Files\Git\bin\bash.exe" -c ^". \^"D:\conan-data\libiconv\1.17\_\_\build\29d1f4003b3f7143826ef1988625574513d526ce\build-release\conan\conanbuild.sh\^" ^&^& \^"/d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/configure\^" --disable-shared --enable-static --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include ^"
-----------------
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.0
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x86'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... no
checking whether make supports nested variables... no
checking whether make sets $(MAKE)... (cached) no
checking for gcc... /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo
checking whether the C compiler works... yes
checking for C compiler default output file name... conftest.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... obj
checking whether the compiler supports GNU C... no
checking whether /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo accepts -g... no
checking for /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo option to enable C11 features... unsupported
checking for /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo option to enable C99 features... unsupported
checking for /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo option to enable C89 features... unsupported
checking whether /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo understands -c and -o together... yes
checking whether the compiler is clang... no
checking for compiler option needed when checking for declarations... none
checking whether make supports the include directive... no
checking dependency style of /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo... none
checking how to run the C preprocessor... /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo -E
checking for strip... /c/ProgramData/chocolatey/bin/strip
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... no
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... no
checking for wchar.h... yes
checking for minix/config.h... no
checking for sys/param.h... no
checking for sys/socket.h... no
checking for limits.h... yes
checking for sys/time.h... no
checking for features.h... no
checking for crtdefs.h... yes
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for Minix Amsterdam compiler... no
checking for ar... /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/ar-lib lib
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... unknown
checking for _LARGE_FILES value needed for large files... unknown
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for non-GNU ld... link
checking if the linker (link) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... dumpbin -symbols
checking the name lister (dumpbin -symbols) interface... MS dumpbin
checking whether ln -s works... no, using cp -pR
checking the maximum length of command line arguments... 8192
checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... func_convert_file_msys_to_w32
checking how to convert i686-pc-mingw32 file names to toolchain format... func_convert_file_msys_to_w32
checking for link option to reload object files... -r
checking for file... file
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for dlltool... dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for archiver @FILE support... @
checking for strip... /c/ProgramData/chocolatey/bin/strip
checking for ranlib... :
checking command to parse dumpbin -symbols output from /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... yes
checking for dlfcn.h... no
checking for as... as
checking for dlltool... (cached) dlltool
checking for objdump... (cached) objdump
checking for objdir... .libs
checking for /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo option to produce PIC... -DDLL_EXPORT -DPIC
checking if /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo PIC flag -DDLL_EXPORT -DPIC works... yes
checking if /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo static flag  works... yes
checking if /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo supports -c -o file.obj... yes
checking if /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo supports -c -o file.obj... (cached) yes
checking whether the /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo linker (link) supports shared libraries... yes
checking dynamic linker characteristics... Win32 link.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for ld... link
checking if the linker (link) is GNU ld... no
checking for shared library path variable... PATH
checking whether to activate relocatable installation... no
checking how to copy files... cp -p
checking how to make hard links... ln
checking whether ln -s works... no, using cp -pR
checking for windres... windres
checking for windres... windres
checking for shared library run path origin... done
checking 32-bit host C ABI... yes
checking for ELF binary format... no
checking for the common suffixes of directories in the library search path... lib,lib,lib
checking for iconv... no, consider installing GNU libiconv
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyPreferredLanguages... no
checking for GNU gettext in libc... no
checking for iconv... (cached) no, consider installing GNU libiconv
checking for GNU gettext in libintl... no
checking whether to use NLS... no
checking for mbstate_t... yes
checking for wchar_t... yes
checking for getc_unlocked... no
checking for mbrtowc... yes
checking for wcrtomb... yes
checking for mbsinit... no
checking for setlocale... yes
checking whether <wchar.h> is standalone... yes
checking for memmove... no
checking for nl_langinfo and CODESET... no
checking for symlink... no
checking for canonicalize_file_name... no
checking for faccessat... no
checking for realpath... no
checking for lstat... no
checking for readlinkat... no
checking for _set_invalid_parameter_handler... yes
checking for fcntl... no
checking for getdtablesize... no
checking for getprogname... no
checking for getexecname... no
checking for readlink... no
checking for setenv... no
checking for working fcntl.h... no
checking for wchar.h... (cached) yes
checking for EILSEQ... yes
checking whether byte ordering is bigendian... no
checking for size_t... yes
checking for working alloca.h... no
checking for alloca... yes
checking whether lstat correctly handles trailing slash... no
checking whether // is distinct from /... yes
checking whether realpath works... no
checking for C/C++ restrict keyword... no
checking if environ is properly declared... yes
checking whether the preprocessor supports include_next... no
checking whether source code line length is unlimited... yes
checking for complete errno.h... no
checking absolute name of <errno.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\errno.h"
checking for EMULTIHOP value... no
checking for ENOLINK value... yes
checking for EOVERFLOW value... yes
checking for /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo options needed to detect all undeclared functions... none needed
checking whether strerror_r is declared... no
checking whether strerror_r returns char *... no
checking whether ctype.h defines __header_inline... no
checking for pid_t... no
checking for mode_t... no
checking absolute name of <fcntl.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\fcntl.h"
checking whether stat file-mode macros are broken... no
checking for 64-bit off_t... no
checking for 64-bit st_size... no
checking absolute name of <sys/stat.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\sys/stat.h"
checking for nlink_t... no
checking for sdkddkver.h... yes
checking whether getdtablesize is declared... no
checking absolute name of <limits.h>... "C:\\Program Files\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.29.30133\\include\\limits.h"
checking whether limits.h has WORD_BIT, BOOL_WIDTH etc.... no
checking for wint_t... yes
checking whether wint_t is large enough... no
checking whether the compiler produces multi-arch binaries... no
checking absolute name of <stdint.h>... "C:\\Program Files\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.29.30133\\include\\stdint.h"
checking whether stdint.h conforms to C99... yes
checking whether stdint.h works without ISO C predefines... yes
checking whether stdint.h has UINTMAX_WIDTH etc.... no
checking absolute name of <inttypes.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\inttypes.h"
checking whether malloc is ptrdiff_t safe... no
checking whether malloc, realloc, calloc set errno on failure... no
checking whether malloc (0) returns nonnull... yes
checking whether <limits.h> defines MIN and MAX... no
checking whether <sys/param.h> defines MIN and MAX... no
checking for O_CLOEXEC... no
checking for promoted mode_t type... mode_t
checking for sigset_t... no
checking for SIGPIPE... no
checking whether setenv is declared... no
checking for ssize_t... no
checking for uid_t in sys/types.h... no
checking absolute name of <signal.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\signal.h"
checking for volatile sig_atomic_t... yes
checking for sighandler_t... no
checking whether C symbols are prefixed with underscore at the linker level... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for good max_align_t... no
checking whether NULL can be used in arbitrary expressions... yes
checking absolute name of <stddef.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\stddef.h"
checking whether fcloseall is declared... yes
checking absolute name of <stdio.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\stdio.h"
checking which flavor of printf attribute matches inttypes macros... system
checking whether ecvt is declared... yes
checking whether fcvt is declared... yes
checking whether gcvt is declared... yes
checking absolute name of <stdlib.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\stdlib.h"
checking whether strerror(0) succeeds... yes
checking absolute name of <string.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\string.h"
checking absolute name of <sys/types.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\sys/types.h"
checking for struct timespec in <time.h>... yes
checking absolute name of <time.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\time.h"
checking for TIME_UTC in <time.h>... yes
checking whether execvpe is declared... no
checking absolute name of <unistd.h>... <unistd.h>
checking whether clearerr_unlocked is declared... no
checking whether feof_unlocked is declared... no
checking whether ferror_unlocked is declared... no
checking whether fflush_unlocked is declared... no
checking whether fgets_unlocked is declared... no
checking whether fputc_unlocked is declared... no
checking whether fputs_unlocked is declared... no
checking whether fread_unlocked is declared... no
checking whether fwrite_unlocked is declared... no
checking whether getc_unlocked is declared... no
checking whether getchar_unlocked is declared... no
checking whether putc_unlocked is declared... no
checking whether putchar_unlocked is declared... no
checking whether <wchar.h> uses 'inline' correctly... yes
checking absolute name of <wchar.h>... "C:\\Program Files\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt\\wchar.h"
checking whether wcsdup is declared... yes
checking for C compiler option to allow warnings... none
checking for __builtin_expect... no
checking for winsock2.h... yes
checking whether // is distinct from /... (cached) yes
checking whether dup2 works... no
checking for setdtablesize... no
checking for error_at_line... no
checking whether free is known to preserve errno... no
checking whether program_invocation_name is declared... no
checking whether program_invocation_short_name is declared... no
checking whether __argv is declared... yes
checking whether the compiler supports the __inline keyword... yes
checking for mbstate_t... (cached) yes
checking for mempcpy... no
checking whether program_invocation_name is declared... (cached) no
checking whether program_invocation_short_name is declared... (cached) no
checking for raise... yes
checking for rawmemchr... no
checking whether free is known to preserve errno... (cached) no
checking for mempcpy... (cached) no
checking for rawmemchr... (cached) no
checking for search.h... yes
checking for tsearch... no
checking for ssize_t... (cached) no
checking for struct stat.st_atim.tv_nsec... no
checking for struct stat.st_atimespec.tv_nsec... no
checking for struct stat.st_atimensec... no
checking for struct stat.st_atim.st__tim.tv_nsec... no
checking for struct stat.st_birthtimespec.tv_nsec... no
checking for struct stat.st_birthtimensec... no
checking for struct stat.st_birthtim.tv_nsec... no
checking for working stdalign.h... no
checking for winsock2.h... (cached) yes
checking for variable-length arrays... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating lib/Makefile
config.status: creating srclib/Makefile
config.status: creating src/Makefile
config.status: creating po/Makefile.in
config.status: creating man/Makefile
config.status: creating tests/Makefile
config.status: creating include/iconv.h
config.status: creating include/iconv.h.inst
config.status: creating config.h
config.status: creating lib/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
=== configuring in libcharset (/d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/build-release/libcharset)
configure: running /bin/sh /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/libcharset/configure --disable-option-checking '--prefix=/'  '--disable-shared' '--enable-static' '--bindir=/bin' '--sbindir=/bin' '--libdir=/lib' '--includedir=/include' '--oldincludedir=/include' 'CC=/d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo' 'CFLAGS= -MD -O2 -Ob2 -FS' 'LDFLAGS=' 'CPPFLAGS= -DNDEBUG' --cache-file=/dev/null --srcdir=/d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/libcharset
checking whether make sets $(MAKE)... no
checking for gcc... /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo
checking whether the C compiler works... yes
checking for C compiler default output file name... conftest.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... obj
checking whether the compiler supports GNU C... no
checking whether /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo accepts -g... no
checking for /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo option to enable C11 features... unsupported
checking for /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo option to enable C99 features... unsupported
checking for /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo option to enable C89 features... unsupported
checking how to run the C preprocessor... /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo -E
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... no
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... no
checking for wchar.h... yes
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for non-GNU ld... link
checking if the linker (link) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... dumpbin -symbols
checking the name lister (dumpbin -symbols) interface... MS dumpbin
checking whether ln -s works... no, using cp -pR
checking the maximum length of command line arguments... 8192
checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... func_convert_file_msys_to_w32
checking how to convert i686-pc-mingw32 file names to toolchain format... func_convert_file_msys_to_w32
checking for link option to reload object files... -r
checking for file... file
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for dlltool... dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for archiver @FILE support... @
checking for strip... /c/ProgramData/chocolatey/bin/strip
checking for ranlib... :
checking for gawk... gawk
checking command to parse dumpbin -symbols output from /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... yes
checking for dlfcn.h... no
checking for as... as
checking for dlltool... (cached) dlltool
checking for objdump... (cached) objdump
checking for objdir... .libs
checking for /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo option to produce PIC... -DDLL_EXPORT -DPIC
checking if /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo PIC flag -DDLL_EXPORT -DPIC works... yes
checking if /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo static flag  works... yes
checking if /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo supports -c -o file.obj... yes
checking if /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo supports -c -o file.obj... (cached) yes
checking whether the /d/conan-data/libiconv/1.17/_/_/build/29d1f4003b3f7143826ef1988625574513d526ce/src/build-aux/compile cl -nologo linker (link) supports shared libraries... yes
checking dynamic linker characteristics... Win32 link.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for ld... link
checking if the linker (link) is GNU ld... no
checking for shared library path variable... PATH
checking whether to activate relocatable installation... no
checking for nl_langinfo and CODESET... no
checking for symlink... no
checking for working fcntl.h... no
checking for setlocale... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating lib/Makefile
config.status: creating include/libcharset.h
config.status: creating include/libcharset.h.inst
config.status: creating include/localcharset.h
config.status: creating include/localcharset.h.inst
config.status: creating config.h
config.status: executing libtool commands

----Running------
> "D:\conan-data\libiconv\1.17\_\_\build\29d1f4003b3f7143826ef1988625574513d526ce\build-release\conan\conanbuild.bat" && "D:\conan-data\libiconv\1.17\_\_\build\29d1f4003b3f7143826ef1988625574513d526ce\build-release\conan\msys2_mode.bat" && "c:\Program Files\Git\bin\bash.exe" -c ^". \^"D:\conan-data\libiconv\1.17\_\_\build\29d1f4003b3f7143826ef1988625574513d526ce\build-release\conan\conanbuild.sh\^" ^&^& /c/Strawberry/c/bin/gmake.exe -j2^"
-----------------
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.0
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x86'
builddir="`pwd`"; cd libcharset && make all && make install-lib libdir="$builddir/lib" includedir="$builddir/lib"
/usr/bin/sh: line 1: make: command not found
gmake: *** [Makefile:41: lib/localcharset.h] Error 127
libiconv/1.17:
libiconv/1.17: ERROR: Package '29d1f4003b3f7143826ef1988625574513d526ce' build failed
libiconv/1.17: WARN: Build folder D:\conan-data\libiconv\1.17\_\_\build\29d1f4003b3f7143826ef1988625574513d526ce\build-release
ERROR: libiconv/1.17: Error in build() method, line 123
        autotools.make()
        ConanException: Error 2 while executing /c/Strawberry/c/bin/gmake.exe -j2
```

</details>

not sure why it still tries to use `make`

<details><summary>libvpx</summary>

```
> conan install libvpx/1.11.0@ --build=missing --profile:build=default --profile:host=default
Configuration (profile_host):
[settings]
arch=x86
arch_build=x86
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
tools.gnu:make_program=/c/Strawberry/c/bin/gmake.exe
tools.microsoft.bash:path=c:\Program Files\Git\bin\bash.exe
tools.microsoft.bash:subsystem=msys2

Configuration (profile_build):
[settings]
arch=x86
arch_build=x86
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
tools.gnu:make_program=/c/Strawberry/c/bin/gmake.exe
tools.microsoft.bash:path=c:\Program Files\Git\bin\bash.exe
tools.microsoft.bash:subsystem=msys2

libvpx/1.11.0: WARN: Package binary is corrupted, removing: bdefbd64b64c27caba7299c90306273d43bfd3f1
Installing package: libvpx/1.11.0
Requirements
    libvpx/1.11.0 from 'conancenter' - Cache
Packages
    libvpx/1.11.0:bdefbd64b64c27caba7299c90306273d43bfd3f1 - Build
Build requirements
    yasm/1.3.0 from 'conancenter' - Cache
Build requirements packages
    yasm/1.3.0:63c5d5dc6eb958dab897e143053e17f583d55879 - Cache

Installing (downloading, building) binaries...
yasm/1.3.0: Already installed!
yasm/1.3.0: Appending PATH environment variable: D:\conan-data\yasm\1.3.0\_\_\package\63c5d5dc6eb958dab897e143053e17f583d55879\bin
libvpx/1.11.0: Applying build-requirement: yasm/1.3.0
libvpx/1.11.0: WARN: Build folder is dirty, removing it: D:\conan-data\libvpx\1.11.0\_\_\build\bdefbd64b64c27caba7299c90306273d43bfd3f1
libvpx/1.11.0: Copying sources to build folder
libvpx/1.11.0: Building your package in D:\conan-data\libvpx\1.11.0\_\_\build\bdefbd64b64c27caba7299c90306273d43bfd3f1
libvpx/1.11.0: Generator txt created conanbuildinfo.txt
libvpx/1.11.0: Aggregating env generators
libvpx/1.11.0: Calling build()
Conan:vcvars already set
libvpx/1.11.0: run_in_windows_bash: "c:\Program Files\Git\bin\bash.exe" --login -c ^"cd \^"/d/conan-data/libvpx/1.11.0/_/_/build/bdefbd64b64c27caba7299c90306273d43bfd3f1\^" ^&^& PATH=\^"/d/conan-data/yasm/1.3.0/_/_/package/63c5d5dc6eb958dab897e143053e17f583d55879/bin:/d/conan-data/yasm/1.3.0/_/_/package/63c5d5dc6eb958dab897e143053e17f583d55879/bin:$PATH\^" ^&^& /d/conan-data/libvpx/1.11.0/_/_/build/bdefbd64b64c27caba7299c90306273d43bfd3f1/source_subfolder/configure --help ^"
Usage: configure [options]
Options:

Build options:
  --help                      print this message
  --log=yes|no|FILE           file configure log is written to [config.log]
  --target=TARGET             target platform tuple [generic-gnu]
  --cpu=CPU                   optimize for a specific cpu rather than a family
  --extra-cflags=ECFLAGS      add ECFLAGS to CFLAGS []
  --extra-cxxflags=ECXXFLAGS  add ECXXFLAGS to CXXFLAGS []
  --enable-extra-warnings     emit harmless warnings (always non-fatal)
  --enable-werror             treat warnings as errors, if possible
                              (not available with all compilers)
  --disable-optimizations     turn on/off compiler optimization flags
  --enable-pic                turn on/off Position Independent Code
  --enable-ccache             turn on/off compiler cache
  --enable-debug              enable/disable debug mode
  --enable-gprof              enable/disable gprof profiling instrumentation
  --enable-gcov               enable/disable gcov coverage instrumentation
  --enable-thumb              enable/disable building arm assembly in thumb mode
  --disable-dependency-tracking
                              disable to speed up one-time build

Install options:
  --disable-install-docs      control whether docs are installed
  --disable-install-bins      control whether binaries are installed
  --disable-install-libs      control whether libraries are installed
  --enable-install-srcs       control whether sources are installed


Advanced options:
  --disable-libs                  libraries
  --disable-examples              examples
  --disable-tools                 tools
  --disable-docs                  documentation
  --enable-unit-tests             unit tests
  --enable-decode-perf-tests      build decoder perf tests with unit tests
  --enable-encode-perf-tests      build encoder perf tests with unit tests
  --cpu=CPU                       tune for the specified CPU (ARM: cortex-a8, X86: sse3)
  --libc=PATH                     path to alternate libc
  --size-limit=WxH                max size to allow in the decoder
  --as={yasm|nasm|auto}           use specified assembler [auto, yasm preferred]
  --enable-codec-srcs             in/exclude codec library source code
  --enable-debug-libs             in/exclude debug version of libraries
  --enable-static-msvcrt          use static MSVCRT (VS builds only)
  --enable-vp9-highbitdepth       use VP9 high bit depth (10/12) profiles
  --enable-better-hw-compatibility
                                  enable encoder to produce streams with better
                                  hardware decoder compatibility
  --enable-vp8                    VP8 codec support
  --enable-vp9                    VP9 codec support
  --enable-internal-stats         output of encoder internal stats for debug, if supported (encoders)
  --enable-postproc               postprocessing
  --enable-vp9-postproc           vp9 specific postprocessing
  --disable-multithread           multithreaded encoding and decoding
  --disable-spatial-resampling    spatial sampling (scaling) support
  --enable-realtime-only          enable this option while building for real-time encoding
  --enable-onthefly-bitpacking    enable on-the-fly bitpacking in real-time encoding
  --enable-error-concealment      enable this option to get a decoder which is able to conceal losses
  --enable-coefficient-range-checking
                                  enable decoder to check if intermediate
                                  transform coefficients are in valid range
  --enable-runtime-cpu-detect     runtime cpu detection
  --enable-shared                 shared library support
  --disable-static                static library support
  --enable-small                  favor smaller size over speed
  --enable-postproc-visualizer    macro block / block level visualizers
  --enable-multi-res-encoding     enable multiple-resolution encoding
  --disable-temporal-denoising    enable temporal denoising and disable the spatial denoiser
  --enable-vp9-temporal-denoising
                                  enable vp9 temporal denoising
  --enable-webm-io                enable input from and output to WebM container
  --enable-libyuv                 enable libyuv

Codecs:
  Codecs can be selectively enabled or disabled individually, or by family:
      --disable-<codec>
  is equivalent to:
      --disable-<codec>-encoder
      --disable-<codec>-decoder

  Codecs available in this distribution:
           vp8:    encoder    decoder
           vp9:    encoder    decoder


NOTES:
    Object files are built at the place where configure is launched.

    All boolean options can be negated. The default value is the opposite
    of that shown above. If the option --disable-foo is listed, then
    the default value for foo is enabled.

Supported targets:
    arm64-android-gcc        arm64-darwin-gcc         arm64-darwin20-gcc
    arm64-darwin21-gcc       arm64-linux-gcc          arm64-win64-gcc
    arm64-win64-vs15
    armv7-android-gcc        armv7-darwin-gcc         armv7-linux-rvct
    armv7-linux-gcc          armv7-none-rvct          armv7-win32-gcc
    armv7-win32-vs14         armv7-win32-vs15
    armv7s-darwin-gcc
    armv8-linux-gcc
    mips32-linux-gcc
    mips64-linux-gcc
    ppc64le-linux-gcc
    sparc-solaris-gcc
    x86-android-gcc          x86-darwin8-gcc          x86-darwin8-icc
    x86-darwin9-gcc          x86-darwin9-icc          x86-darwin10-gcc
    x86-darwin11-gcc         x86-darwin12-gcc         x86-darwin13-gcc
    x86-darwin14-gcc         x86-darwin15-gcc         x86-darwin16-gcc
    x86-darwin17-gcc         x86-iphonesimulator-gcc  x86-linux-gcc
    x86-linux-icc            x86-os2-gcc              x86-solaris-gcc
    x86-win32-gcc            x86-win32-vs14           x86-win32-vs15
    x86-win32-vs16           x86-win32-vs17
    x86_64-android-gcc       x86_64-darwin9-gcc       x86_64-darwin10-gcc
    x86_64-darwin11-gcc      x86_64-darwin12-gcc      x86_64-darwin13-gcc
    x86_64-darwin14-gcc      x86_64-darwin15-gcc      x86_64-darwin16-gcc
    x86_64-darwin17-gcc      x86_64-darwin18-gcc      x86_64-darwin19-gcc
    x86_64-darwin20-gcc      x86_64-darwin21-gcc      x86_64-iphonesimulator-gcc
    x86_64-linux-gcc         x86_64-linux-icc         x86_64-solaris-gcc
    x86_64-win64-gcc         x86_64-win64-vs14        x86_64-win64-vs15
    x86_64-win64-vs16        x86_64-win64-vs17
    generic-gnu

libvpx/1.11.0: WARN: Error running `configure --help`: Error 1 while executing /d/conan-data/libvpx/1.11.0/_/_/build/bdefbd64b64c27caba7299c90306273d43bfd3f1/source_subfolder/configure --help
libvpx/1.11.0: Calling:
 > /d/conan-data/libvpx/1.11.0/_/_/build/bdefbd64b64c27caba7299c90306273d43bfd3f1/source_subfolder/configure --prefix=/d/conan-data/libvpx/1.11.0/_/_/package/bdefbd64b64c27caba7299c90306273d43bfd3f1 --disable-examples --disable-unit-tests --disable-tools --disable-docs --enable-vp9-highbitdepth --as=yasm --disable-shared --enable-static --target=x86-win32-vs16 --disable-avx --disable-avx2 --disable-avx512
libvpx/1.11.0: run_in_windows_bash: "c:\Program Files\Git\bin\bash.exe" --login -c ^"cd \^"/d/conan-data/libvpx/1.11.0/_/_/build/bdefbd64b64c27caba7299c90306273d43bfd3f1\^" ^&^& PATH=\^"/d/conan-data/yasm/1.3.0/_/_/package/63c5d5dc6eb958dab897e143053e17f583d55879/bin:/d/conan-data/yasm/1.3.0/_/_/package/63c5d5dc6eb958dab897e143053e17f583d55879/bin:$PATH\^" ^&^& /d/conan-data/libvpx/1.11.0/_/_/build/bdefbd64b64c27caba7299c90306273d43bfd3f1/source_subfolder/configure --prefix=/d/conan-data/libvpx/1.11.0/_/_/package/bdefbd64b64c27caba7299c90306273d43bfd3f1 --disable-examples --disable-unit-tests --disable-tools --disable-docs --enable-vp9-highbitdepth --as=yasm --disable-shared --enable-static --target=x86-win32-vs16 --disable-avx --disable-avx2 --disable-avx512  ^"
  disabling examples
  disabling unit_tests
  disabling tools
  disabling docs
  enabling vp9_highbitdepth
  disabling shared
  enabling vp8_encoder
  enabling vp8_decoder
  enabling vp9_encoder
  enabling vp9_decoder
Configuring for target 'x86-win32-vs16'
  enabling x86
  enabling runtime_cpu_detect
  enabling mmx
  enabling sse
  enabling sse2
  enabling sse3
  enabling ssse3
  enabling sse4_1
  using yasm
  disabling ccache
  enabling postproc
  enabling webm_io
  enabling libyuv
Bypassing toolchain for environment detection.
Creating makefiles for x86-win32-vs16 libs
Creating makefiles for x86-win32-vs16 solution
libvpx/1.11.0: run_in_windows_bash: "c:\Program Files\Git\bin\bash.exe" --login -c ^"cd \^"/d/conan-data/libvpx/1.11.0/_/_/build/bdefbd64b64c27caba7299c90306273d43bfd3f1\^" ^&^& PATH=\^"/d/conan-data/yasm/1.3.0/_/_/package/63c5d5dc6eb958dab897e143053e17f583d55879/bin:/d/conan-data/yasm/1.3.0/_/_/package/63c5d5dc6eb958dab897e143053e17f583d55879/bin:$PATH\^" ^&^& /c/Strawberry/c/bin/gmake.exe -j2 ^"
Makefile:344: /d/conan-data/libvpx/1.11.0/_/_/build/bdefbd64b64c27caba7299c90306273d43bfd3f1/source_subfolder/libs.mk: No such file or directory
gmake[1]: *** No rule to make target '/d/conan-data/libvpx/1.11.0/_/_/build/bdefbd64b64c27caba7299c90306273d43bfd3f1/source_subfolder/libs.mk'.  Stop.
gmake: *** [Makefile:17: .DEFAULT] Error 2
gmake: *** Waiting for unfinished jobs....
libvpx/1.11.0:
libvpx/1.11.0: ERROR: Package 'bdefbd64b64c27caba7299c90306273d43bfd3f1' build failed
libvpx/1.11.0: WARN: Build folder D:\conan-data\libvpx\1.11.0\_\_\build\bdefbd64b64c27caba7299c90306273d43bfd3f1
ERROR: libvpx/1.11.0: Error in build() method, line 172
        autotools.make()
        ConanException: Error 2 while executing /c/Strawberry/c/bin/gmake.exe -j2
```

</details>

but file `/d/conan-data/libvpx/1.11.0/_/_/build/bdefbd64b64c27caba7299c90306273d43bfd3f1/source_subfolder/libs.mk` does exist and I can view it in my bash shell.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: kambala-decapitator
issue_12322: state: open
title: [question] should we be using `msvc_version_to_vs_ide_version` in recipes
body: <!-- What is your question? Please be as specific as possible! -->

>  Not converted to new tools, can't be used as it's part of a private import.

_Originally posted by @uilianries in https://github.com/conan-io/conan-center-index/pull/13365#discussion_r996955447_

This has some useful benefits during the 2.0 migration period
      

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: prince-chrismc
issue_12321: state: open
title: [question] Conan 2.0: Using `is_msvc` fails in validate trying access settings
body: https://github.com/conan-io/conan-center-index/pull/13525#issuecomment-1281430889

```py
    def validate(self):
        if is_msvc(self) and self.info.options.shared:
            raise ConanInvalidConfiguration(f"{self.ref} shared not supported by Visual Studio")
```

gives a `ConanException: 'self.settings' access in 'validate()' method is forbidden`

https://github.com/conan-io/conan/blob/a1abe135c6ecb646e0eaad6ab99aa22600b1858e/conan/tools/microsoft/visual.py#L288

- is this expected (it's the default 1.x convention)?
- should this type of check be done in `valdiate_build`?
user: prince-chrismc
issue_12317: state: open
title: [bug] conan export-pkg suggests to use invalid option
body: "conan export-pkg" suggests to use "--update" but "--update" isn't a valid option for "export-pkg"

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version:
  * Conan version: 1.53.0
  * Python version:

### Steps to reproduce (Include if Applicable)
conan export-pkg -pf /mnt/c/conan/linux_debug -f -s os=Linux -s build_type=Debug -s compiler.cppstd=17 -pr /mnt/c/conan/profiles/host_unix /mnt/c/conan/test_conan/recipes/library/all/conanfile.py library/2020.0.1@user/channel

Recipe has requirements with recipe revision
```
self.requires("libxml2/2.9.14@user/channel#00b261c680d69a8bf53425b15b38c58a")
self.requires("zlib/1.2.12@user/channel#15ff7db1ab5b19debc62bfb6c2c77299")
```

### Logs (Executed commands with output) (Include/Attach if Applicable)
ERROR: Failed requirement 'zlib/1.2.12@user/channel' from 'libxml2/2.9.14@user/channel'
ERROR: The 'c0563e53bec60677ce8447f7d440e5e5' revision recipe in the local cache doesn't match the requested 'zlib/1.2.12@user/channel#15ff7db1ab5b19debc62bfb6c2c77299'. Use '--update' to check in the remote.

If I add --update, I'm getting
"conan export-pkg: error: unrecognized arguments: --update"

user: Nekto89
issue_12314: state: open
title: [question] MSBuildToolchain does not apply compiler toolset when it's missing from vcxproj files
body: Reviewing and playing with https://github.com/conan-io/conan-center-index/pull/13185 I discovered the new toolchain and build helper are able to pass in the compiler toolset from the settings model (or the recipe)... but not how I was expecting.

❓ Is this a limitation given the tribe decided on higher support (where this value should always be present) or is it possibly a bug?
❓ Is this expected when migrating old projects to Conan 2.0?

The recipe is currently building with https://github.com/yasm/yasm/tree/v1.3.0/Mkfiles/vc10 which does not have the `PlatformToolset` defined in any of the configurations. 

Calling `conan create all 1.3.0@ -pr msvc2019` results in 

```
Done Building Project "C:\J\w\prod\BuildSingleReference@2\.conan\data\yasm\1.3.0\_\_\build\0a420ff5c47119e668867cdb51baff0eca1fdb68\Mkfiles\vc10\yasm.sln" (default targets) -- FAILED.

Build FAILED.

"C:\J\w\prod\BuildSingleReference@2\.conan\data\yasm\1.3.0\_\_\build\0a420ff5c47119e668867cdb51baff0eca1fdb68\Mkfiles\vc10\genversion\genversion.vcxproj" (default target) (3) ->
(PlatformPrepareForBuild target) -> 
  C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Platform.targets(65,5): error MSB8020: The build tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found. To build using the v100 build tools, please install Visual Studio 2010 build tools.  Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [C:\J\w\prod\BuildSingleReference@2\.conan\data\yasm\1.3.0\_\_\build\0a420ff5c47119e668867cdb51baff0eca1fdb68\Mkfiles\vc10\genversion\genversion.vcxproj]
```

Modifying the recipe with

```pr
        tc = MSBuildToolchain(self)
        if not self.settings.get_safe("compiler.toolset"):
            tc.toolset = "v140"
        tc.generate()
```

Leads to the same problem as well as `conan create all 1.3.0@ -pr msvc2019 -s compiler.toolset=v142`

```
Configuration for profile msvc2019:

[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=Visual Studio
compiler.version=16
build_type=Release
[options]
[conf]
[build_requires]
[env]
```

https://github.com/conan-io/conan/blob/8aeea2230fd6375ce1da15f2380097bed9098377/conan/tools/microsof

***

Good news, when the patch is applied https://github.com/conan-io/conan-center-index/blob/404cd727b1387a69dca62a5588596effd1a69f48/recipes/yasm/all/patches/0001-platformtoolset.patch the toolset can be correctly applied

in a 2019 prompt it will fail with any toolset other then v142 (which is expected) and in a 2022 prompt it will only work in with `toolset=v143`... both work with the default provided toolset given `toolset=None`

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).t/toolchain.py#L56
user: prince-chrismc
issue_12309: state: open
title: [question] Handling of dependencies on python modules and access to dependency package_folder
body: Goal: Ability to install all python modules required by our dependencies

We have an internal convention for packages to provide a requirements.txt file in the root of the package when they require python modules. On the consumer side, after the `conan install` step, we parse the `conanbuildinfo.json` to get access to the rootpath of each package and check if there is any `requirements.txt` with a python script `consolidated_requirements.py`. If any exist, we gather the information in a `consolidated_requirements.txt` before installing it either on the user system or under a virtualenv (prefered).
During the transition to build/host profile, I detected that only dependencies marked as `requires` will be part of the list `dependencies` from `conanbuildinfo.json`.
Looking into closed bugs/questions I found that [`memsharded` mentioned that](https://github.com/conan-io/conan/issues/11351#issuecomment-1139740923) this file (`conanbuildinfo.json`) will not exist anymore in conan 2.0.

How to proceed further? I thought about following possibilities:

- Try to recreate the dependency tree information part of the install process by our own
  - How to handle the creation of "conan_dependency_rootpath.json"?
    - python_requires (create_buildinfo()) - 4 liners for the consumer! "python_requires, python_requires_extend, generate(self): self.create_buildinfo()"
    - each recipe (no way :D)
    - own generator (where is it stored? [Seems actually a python_requires](https://docs.conan.io/en/1.53/extending/custom_build_helper.html))
- Use another conan command like `conan info` to access the dependency tree information
  - `conan info` do not provide the `rootpath` information and the CONAN_USER_HOME structure is different between conan 1.x and 2.X due to multiple revisions support
- [Use custom commands of conan 2.X](https://docs.conan.io/en/2.0/examples/extensions/commands/clean/custom_command_clean_revisions.html#locate-the-command) (not backported to conan 1.x)
- [Use Python Virtual Env of Conan](https://github.com/conan-io/conan/pull/11601) (not backported to conan 1.x)
  - [requires python >= 3.8](https://github.com/conan-io/conan/pull/11601/files#diff-977ebace008712e4861389d940b2f3f2a0fbce81358c5d9f6e1348062154d01fR130)

With conan 1.X, I can only foresee using the first approach to access `build_requires` and `tool_requires` rootpath.

On top of that, the `self.dependencies` object does not contain the python_requires. Is that wanted? How can I get access to the `export_folder` of thus packages?

Actually, that wouldn't be much code if `self.dependencies` has access to `python_require`, right?

```python
    def create_buildinfo(self, file_name="conan_dependency_rootpath.json"):
        build_dep = []
        for _, dependency in self.dependencies.items():
            # I could add other information but as of now
            build_dep.append({"rootpath": dependency.package_folder})
        # for _, dependency in self.dependencies_python.items():
        #     build_dep.append({"rootpath": dependency.export_folder})
        with open(os.path.join(self.install_folder, file_name), 'w') as f:
            json.dump(build_dep, f)
```

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: Bearwolves
issue_12303: state: open
title: [question] Library not added to the CMAKE_MODULE_PATH
body: I used the default recipe for Benchmark from here:

<https://github.com/conan-io/conan-center-index/tree/master/recipes/benchmark>

and modified it to my needs but it is not added to the module path: CMAKE_MODULE_PATH.
I basically added `Findbenchmark.cmake` support.
I used an older version of this recipe before and I did had this problem.

> CMake Error at CMakeLists.txt:195 (find_package):
  By not providing "Findbenchmark.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "benchmark", but CMake did not find one.
>
>  Could not find a package configuration file provided by "benchmark" with
  any of the following names:
>
>    benchmarkConfig.cmake
    benchmark-config.cmake
>
>  Add the installation prefix of "benchmark" to CMAKE_PREFIX_PATH or set
  "benchmark_DIR" to a directory containing one of the above files.  If
  "benchmark" provides a separate development package or SDK, be sure it has
  been installed.

According to https://docs.conan.io/en/latest/integrations/build_system/cmake/find_packages.html there isn't anything special to do get the package added to the CMake module path.

```Python
from conan import ConanFile
from conan.errors import ConanInvalidConfiguration
from conan.tools.build import cross_building
from conan.tools.cmake import CMake, CMakeToolchain, cmake_layout
from conan.tools.files import copy, get, rmdir
from conan.tools.microsoft import is_msvc
from conan.tools.scm import Version
import os

required_conan_version = ">=1.47.0"


class BenchmarkConan(ConanFile):
    name = "benchmark"

    version = "1.7.0"

    description = "A microbenchmark support library."
    topics = ("benchmark", "google", "microbenchmark")
    url = "https://github.com/conan-io/conan-center-index/"
    homepage = "https://github.com/google/benchmark"
    license = "Apache-2.0"

    exports_sources = ["Findbenchmark.cmake"]

    settings = "os", "arch", "compiler", "build_type"
    options = {
        "shared": [True, False],
        "fPIC": [True, False],
        "enable_lto": [True, False],
        "enable_exceptions": [True, False],
        "universal_arm64_mac": [True, False],
    }
    default_options = {
        "shared": False,
        "fPIC": True,
        "enable_lto": False,
        "enable_exceptions": True,
        "universal_arm64_mac": False
    }

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def configure(self):
        if self.options.shared:
            try:
                del self.options.fPIC
            except Exception:
                pass

    def layout(self):
        cmake_layout(self, src_folder="src")

    def validate(self):
        if self.info.settings.compiler == "Visual Studio" and Version(self.info.settings.compiler.version) <= "12":
            raise ConanInvalidConfiguration(f"{self.ref} doesn't support Visual Studio <= 12")
        if Version(self.version) < "1.7.0" and is_msvc(self) and self.info.options.shared:
            raise ConanInvalidConfiguration(f"{self.ref} doesn't support msvc shared builds")

    def source(self):
        get(self, **self.conan_data["sources"][self.version],
            destination=self.source_folder, strip_root=True)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.variables["BENCHMARK_ENABLE_TESTING"] = "OFF"
        tc.variables["BENCHMARK_ENABLE_GTEST_TESTS"] = "OFF"
        tc.variables["BENCHMARK_ENABLE_LTO"] = self.options.enable_lto
        tc.variables["BENCHMARK_ENABLE_EXCEPTIONS"] = self.options.enable_exceptions
        if Version(self.version) >= "1.6.1":
            tc.variables["BENCHMARK_ENABLE_WERROR"] = False
            tc.variables["BENCHMARK_FORCE_WERROR"] = False
        if self.settings.os != "Windows":
            if cross_building(self):
                tc.variables["HAVE_STD_REGEX"] = False
                tc.variables["HAVE_POSIX_REGEX"] = False
                tc.variables["HAVE_STEADY_CLOCK"] = False
            tc.variables["BENCHMARK_USE_LIBCXX"] = self.settings.compiler.get_safe("libcxx") == "libc++"
        else:
            tc.variables["BENCHMARK_USE_LIBCXX"] = False
        if self.settings.os == "Macos":
            tc.variables["CMAKE_OSX_DEPLOYMENT_TARGET"] = str(self.settings.os.version)
            if self.options.universal_arm64_mac:
                tc.variables['CMAKE_OSX_ARCHITECTURES'] = 'arm64;x86_64'
            else:
                tc.variables['CMAKE_OSX_ARCHITECTURES'] = self.settings.arch
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        copy(self, "LICENSE", src=self.source_folder, dst=os.path.join(self.package_folder, "licenses"))
        copy(self, "Findbenchmark.cmake", src=self.export_sources_folder, dst=self.package_folder)

        cmake = CMake(self)
        cmake.install()

        rmdir(self, os.path.join(self.package_folder, "lib", "pkgconfig"))
        rmdir(self, os.path.join(self.package_folder, "lib", "cmake"))
        rmdir(self, os.path.join(self.package_folder, "share"))

    def package_info(self):
        self.cpp_info.set_property("cmake_file_name", "benchmark")
        self.cpp_info.set_property("pkg_config_name", "benchmark")

        self.cpp_info.components["_benchmark"].set_property("cmake_target_name", "benchmark::benchmark")
        self.cpp_info.components["_benchmark"].libs = ["benchmark"]

        if Version(self.version) >= "1.7.0" and not self.options.shared:
            self.cpp_info.components["_benchmark"].defines.append("BENCHMARK_STATIC_DEFINE")
        if self.settings.os in ("FreeBSD", "Linux"):
            self.cpp_info.components["_benchmark"].system_libs.extend(["pthread", "rt"])
        elif self.settings.os == "Windows":
            self.cpp_info.components["_benchmark"].system_libs.append("shlwapi")
        elif self.settings.os == "SunOS":
            self.cpp_info.components["_benchmark"].system_libs.append("kstat")

        self.cpp_info.components["benchmark_main"].set_property("cmake_target_name", "benchmark::benchmark_main")
        self.cpp_info.components["benchmark_main"].libs = ["benchmark_main"]
        self.cpp_info.components["benchmark_main"].requires = ["_benchmark"]

        # workaround to have all components in CMakeDeps of downstream recipes
        self.cpp_info.set_property("cmake_target_name", "benchmark::benchmark_main")

```
user: H-G-Hristov
issue_12300: state: open
title: [question] How to get LOCATION of a cmake target
body: Hi conan community,

I have an existing project using conan and cmake that I try to migrate to CMakeToolChain+CMakeDeps.
The existing CMakeLists.txt reads LOCATION target property, which was working before but no more works with CMakeToolChain+CMakeDeps.

I reproduce with https://github.com/EstebanDugueperoux2/qt5Example project.
When invoking "conan create . " I get "_target_location: _target_location-NOTFOUND",
while when invoking "cmake ." I get "_target_location: /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8"

Do you have an idea of the issue?

Regards.
user: EstebanDugueperoux2
issue_12287: state: open
title: [question] CMakeDeps appends invalid target in cmake_find_mode="none"
body: How to avoid CMakeDeps appending the default target to the generated `<library>-Target-<configuration>.cmake` file?

I have a setup with multiple libraries, some of them will use conan-generated `<lib>Config.cmake`, others will use default cmake config file that the library generates during the installation. I followed the instructions [here](https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmakedeps.html#disable-cmakedeps-for-installed-cmake-configuration-files). 
If one of my libraries that uses conan-generated cmake config depends on the package that does NOT use conan-generated cmake config, the default `lib1::lib1` target is appended to the `lib2_DEPS_TARGET` even though such target may not exist in a cmake config file that the package produced and I get linker errors. 
How to solve such an issue?

See the attached sources to replicate the setup:
1. `conan create lib1` -> library with disabled CMakeDeps
2. `conan create lib2` -> depends on lib1 and has CMakeDeps enabled
3. `conan install lib2/1.0.0@ -g CMakeDeps`
4. Inspect the `lib2-Target-release.cmake`. It contains the target `lib1::lib1` eventhough it may not exist.

[sources.zip](https://github.com/conan-io/conan/files/9756351/sources.zip)

user: mzukovec
issue_12284: state: open
title: Using CMakeToolChain / CMakeDeps 
body: I am having some struggle using the new CMake generators. I'll list some points I am having trouble with:

- If I want to compile in Debug, I need to tell conan that it has to generate the FooConfig-Debug.cmake. This means I have to call `conan install` in different build directories, depending on how I want to compile my project. Furthermore, if I understand correctly, this will use debug versions of my dependencies, which is something I really dont want. Is it possible to generate config files that can be used on Debug and Release builds?
- Similar to previous point, since I have to run `conan install` in the builddir, I will probably have to go into my project CMakePresets and find the build directories. At least is not the best workflow. 
- If I have several configurations in my CMakePresets, possibly using different compiler versions, I need to have different conan profiles matching those presets. Not even sure (because I havent tested yet) if conan allows to actually use different sysroots, but it is possible that my CMakePresets define a CMAKE_SYSROOT for crosscompiling. How should I proceed in this case?
- conan overrides my CMakePresets.json. Although I understand that the conan generated CMakePresets provides information about the preset that has been used, it makes no sense at all that it overrides project presets. In my opinion, all the information should go into the toolchain file, and ask the user to include the toolchain file in the build. 

I am not sure how I should integrate conan new generators with CMake presets workflow. Some guidelines would be really helpful


user: jjcasmar
issue_12283: state: open
title: [question] Validate and Validate build does not work well with compatible Package ID
body: There is a suspicious case on ConanCenterIndex where we need to use `validate()` + `validate_build()` + compatible packages, where a package (Moltenvk) needs Apple Clang 12, but it can consume older versions when built as shared:

https://github.com/conan-io/conan-center-index/pull/13142#discussion_r979387664

The package requires itself, but it's not listed on requirements nor as build requirement. It could not be a ConanCenterIndex error, because there is no dependency injection, so it seems be a Conan client behavior.

/cc @SpaceIm 

### Environment Details (include every applicable attribute)
  * Operating System+version: Mac OSX
  * Compiler+version: apple-clang 11
  * Conan version: 1.52.0 and 1.53.0
  * Python version: 3.7

### Steps to reproduce (Include if Applicable)

- Checkout the commit https://github.com/conan-io/conan-center-index/pull/13142/commits/8d8cb6878a249cad5b243fbcb22b5827e906633d
- Build moltenvk/1.11.1 with Apple Clang 12 + option shared=True:

```
[settings]
arch=x86_64
build_type=Debug
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=11.0
os=Macos
[options]
moltenvk:shared=True
```


### Logs (Executed commands with output) (Include/Attach if Applicable)

https://c3i.jfrog.io/c3i/misc/logs/pr/13142/1-configs/macos-clang/moltenvk/1.1.11//7f4dd75d0211800b386de5a9e4206d7ef71f08e7-build.txt

user: uilianries
issue_12272: state: open
title: [bug] Reusing CMake macros through tool_requires fails with specified host and build profile
body: Hello Conan Team

<!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 22.04
  * Compiler+version: gcc 11
  * Conan version: 1.53
  * Python version: 3.10.6

### Steps to reproduce (Include if Applicable)

- Use a host and build profiles such as

  ```
  [settings]
  os=Linux
  os.platform=Project.Debian
  os_build=Linux
  arch=x86_64
  arch_build=x86_64
  compiler=gcc
  compiler.version=11
  compiler.libcxx=libstdc++11
  build_type=Release
  [options]
  [build_requires]
  [env]
  
  [tool_requires]
  CustomCMakeUtils/0.1@fjp/stable
  ```

- CustomCMakeUtils conan package that provides CMake module which includes commonly used cmake macros and functions.

  ```
  from conan import ConanFile
  
  class CustomCMakeUtils Conan(ConanFile):
      name = "CustomCMakeUtils "
      description = "CMake utils for components."
      version = "0.1"
  
      cmake_modules = ['CustomUtils.cmake']
      exports_sources = cmake_modules
  
      def package_id(self):
          del self.info.settings.os
          del self.info.settings.arch
          del self.info.settings.compiler
          del self.info.settings.build_type
  
      def package(self):
          for module in self.cmake_modules:
              self.copy(module)
  
      def package_info(self):
          # old cmake_find_package generators
          self.cpp_info.build_modules = self.cmake_modules
          # cmake 2.0, CMakeDeps generator
          self.cpp_info.set_property("cmake_build_modules", self.cmake_modules)
  ```

- Conan Package that relies on CustomCMakeUtils, using `find_package(CustomCMakeUtils REQUIRED)` in its top level CMakeLists.txt.
  
  ```
  cmake_minimum_required(VERSION 3.15)
  project(app CXX)
  
  find_package(CustomCMakeUtils REQUIRED)
  add_library(app src/app.cpp)
  target_include_directories(app PUBLIC include)
  
  set_target_properties(app PROPERTIES PUBLIC_HEADER "include/app.h")
  install(TARGETS app)
  ```

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

Runningn with both, host and build profile, doesn't generate the CustomCMakeUtils cmake module, which will result in a CMake error during `conan build .`

```
app$ conan install . -pr:h default -pr:b default -b missing
Configuration (profile_host):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
os.platform=Project.Debian
os_build=Linux
[options]
[build_requires]
*: CustomCMakeUtils/0.1@fjp/stable
[env]

Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
os.platform=Project.Debian
os_build=Linux
[options]
[build_requires]
*: CustomCMakeUtils/0.1@fjp/stable
[env]

conanfile.py (app/None): Installing package
Requirements
Packages
Build requirements
    CustomCMakeUtils/0.1@fjp/stable from 'my-remote' - Cache
Build requirements packages
    CustomCMakeUtils/0.1@fjp/stable:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache

Installing (downloading, building) binaries...
CustomCMakeUtils/0.1@fjp/stable: Already installed!
conanfile.py (app/None): Applying build-requirement: CustomCMakeUtils/0.1@fjp/stable
conanfile.py (app/None): Generator txt created conanbuildinfo.txt
conanfile.py (app/None): Generator 'CMakeDeps' calling 'generate()'
conanfile.py (app/None): Calling generate()
conanfile.py (app/None): Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
conanfile.py (app/None): If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/home/fjp/dev/app/build/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
conanfile.py (app/None): Aggregating env generators
conanfile.py (app/None): Generated conaninfo.txt
conanfile.py (app/None): Generated graphinfo

app$ ls build/generators/
cmakedeps_macros.cmake  CMakePresets.json  conan_toolchain.cmake
```

When only specifying the host profile the CustomCMakeModule is available and the build succeeds:

```
app$ conan install . -pr:h default -b missing
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
os.platform=Project.Debian
os_build=Linux
[options]
[build_requires]
*: CustomCMakeUtils/0.1@fjp/stable
[env]

conanfile.py (app/None): Installing package
Requirements
Packages
Build requirements
    CustomCMakeUtils/0.1@fjp/stable from 'my-remote' - Cache
Build requirements packages
    CustomCMakeUtils/0.1@fjp/stable:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache

Installing (downloading, building) binaries...
CustomCMakeUtils/0.1@fjp/stable: Already installed!
conanfile.py (app/None): Applying build-requirement: CustomCMakeUtils/0.1@fjp/stable
conanfile.py (app/None): WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
conanfile.py (app/None): Generator 'CMakeDeps' calling 'generate()'
conanfile.py (app/None): Generator txt created conanbuildinfo.txt
conanfile.py (app/None): Calling generate()
conanfile.py (app/None): WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
conanfile.py (app/None): Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
conanfile.py (app/None): If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/home/fjp/dev/app/build/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
conanfile.py (app/None): Aggregating env generators
conanfile.py (app/None): Generated conaninfo.txt
conanfile.py (app/None): Generated graphinfo

app$ ls build/generators/
cmakedeps_macros.cmake  conan_toolchain.cmake  CustomCMakeUtilsConfigVersion.cmake         CustomCMakeUtils-Target-release.cmake
CMakePresets.json       CustomCMakeUtilsConfig.cmake   CustomCMakeUtils-release-x86_64-data.cmake  CustomCMakeUtilsTargets.cmake
```


A workaround for this is to use `self.requires("CustomCMakeUtilsTargets/0.1@fjp/stable")` in the app recipe. Is there a reason why this is not working in the `[tool_requires]` section of the profiles and having both host and build profiles set?

Another question is about the name of `test_requires()`: CustomCMakeUtilsTargets isn't really suitable for the `self.requires` method as it is only used during build time for CMake. However, setting it as a requirement through `self.test_requires` doesn't make any sense either as it is not test related. `self.build_requires` would convey perfect meaning but that is going to be removed[^rem]:

[^rem]: https://docs.conan.io/en/latest/devtools/build_requires.html#build-and-host-contexts

> Note: The test_requires(), available from Conan 1.43, is equivalent to the previous self.build_requires(, force_host_context=True) syntax. As the later is going to dissapear in Conan 2.0, the former test_requires() form is recommended.

What is the recommended way of reusing CMake macros, functions etc? And is there a chance that `self.build_requires` stays?
user: fjp
issue_12266: state: open
title: [bug] Major deviations from standard CMake Find Behaviour
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version: gcc9
  * Conan version: 1.53
  * Python version: 3.8

### Steps to reproduce (Include if Applicable)
- Build Qt5 with conan
- Use e.g. `IF (NOT Qt5Core_FOUND) message(FATAL_ERROR "not found")`  in your CMake code
- Fail

### Logs (Executed commands with output) (Include/Attach if Applicable)
`not found`

user: jpfeuffer
issue_12264: state: open
title: [bug] libGL System dependencies
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version: Gcc 9.4
  * Conan version: 1.53
  * Python version: 3.8.10

<details>
  <summary>Conanfile:</summary>

```
[requires]
eigen/[>3.0]
boost/[>1.60]
coin-cbc/[>1.0]
coin-cgl/[>0.0]
coin-clp/[>1.0]
coin-osi/[>0.0]
coin-utils/[>1.0]
libsvm/[>300]
hdf5/[>1.0]
sqlite3/[>3.0]
zlib/[>=1.2]
bzip2/[>=1.0]
qt/5.15.5

[generators]
cmake

[options]
qt:commercial=False
qt:config=None
qt:device=None
qt:gui=True
qt:multiconfiguration=False
qt:opengl=desktop
qt:openssl=False
qt:qt3d=False
qt:qtandroidextras=False
qt:qtcharts=False
qt:qtconnectivity=False
qt:qtdatavis3d=False
qt:qtdeclarative=False # for WebengineWidgets 
qt:qtdoc=False
qt:qtgamepad=False
qt:qtgraphicaleffects=False
qt:qtimageformats=False
qt:qtlocation=False # for WebengineWidgets 
qt:qtlottie=False
qt:qtmultimedia=False
qt:qtnetworkauth=False
qt:qtpurchasing=False
qt:qtquick3d=False
qt:qtquickcontrols=False
qt:qtquickcontrols2=False
qt:qtquicktimeline=False
qt:qtremoteobjects=False
qt:qtscript=False
qt:qtscxml=False
qt:qtsensors=False
qt:qtserialbus=False
qt:qtserialport=False
qt:qtspeech=False
qt:qtsvg=True
qt:qttools=False
qt:qttranslations=False
qt:qtvirtualkeyboard=False
qt:qtwayland=False
qt:qtwebchannel=False # for WebengineWidgets 
qt:qtwebengine=False
qt:qtwebglplugin=False
qt:qtwebsockets=False
qt:qtwebview=False
qt:qtx11extras=False
qt:qtxmlpatterns=False
qt:shared=True
qt:widgets=True
qt:with_dbus=False
qt:with_doubleconversion=True
qt:with_fontconfig=True
qt:with_freetype=True
qt:with_glib=False
qt:with_gssapi=False
qt:with_harfbuzz=False
qt:with_icu=False
qt:with_libjpeg=libjpeg
qt:with_libpng=True
qt:with_md4c=False
qt:with_mysql=False
qt:with_odbc=False
qt:with_pcre2=False
qt:with_pq=False
qt:with_sqlite3=True
qt:with_vulkan=False
qt:with_zstd=False
```
</details>

### Steps to reproduce (Include if Applicable)
`conan install .. --build missing -c tools.system.package_manager:mode=install`

### Logs (Executed commands with output) (Include/Attach if Applicable)

First I got:

```
ERROR: The following packages need to be installed:
 libgl-dev
opengl/system: ERROR: while executing system_requirements(): Aborted due to CONAN_SYSREQUIRES_MODE=verify. Some system packages need to be installed
ERROR: Error in system requirements
```

After installing manually (WHY? I specified install mode) with a simple `apt-get install libgl-dev` it went further, then:

```
...
Package already installed: libgl-dev
opengl/system: Already installed!
ERROR: opengl/system: Error in package_info() method, line 83
	self._fill_cppinfo_from_pkgconfig('gl')
while calling '_fill_cppinfo_from_pkgconfig', line 21
	if not pkg_config.provides:
	ConanException: pkg-config command ['pkg-config', '--print-provides', 'gl', '--print-errors'] failed with error: Command 'pkg-config --print-provides gl --print-errors' returned non-zero exit status 127.
/bin/sh: 1: pkg-config: not found
```

user: jpfeuffer
issue_12258: state: open
title: [feature] Additional arguments for hooks that deal with packages and recipes
body: I'm implementing a conan hook that deals with handling debug symbols for conan packages. For the implementation I'm often forced to dig deep into conan internals to get the information I need. The hook does some bookkeeping so it can upload debug symbols to a symbol server during the ´pre_upload_package´ hook. To do this properly I need access to the recipe revision and the package revision.
From what I can see, the package revision is missing entirely from all hooks while the recipe revision is mostly present as ´kwarg´.

Assuming revisions are supported, I'd like to have access to the package revision in the pre_upload_package and post_download_package hooks.

My current idea is to use the reference to get the metadata using the `ClientCache` helper and extract the package revision from there.

Speaking of the metadata. Can I use the metadata.json to store custom data?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: stefansli
issue_12254: state: open
title: Installing Conan packages (to be build from sources and pre-built) from conanfile.txt
body: We have package dependencies(internal libraries and pre-build external libraries) in the project.

How can we mention both kind of libraries in one conanfile.txt so that pre-built externals (where we don't have sources) are only getting installed and internal can be build from the sources if needed?

means how can we differentiate to build from sources or simply download in conanfile.txt(which is containing all the library dependencies )?
user: himansu2906
issue_12231: state: open
title: [feature] Provide logging command outputs for Azure Devops CI
body: We are running Conan in our CI on Azure Devops and right now we are parsing the generated console output to identify Conan output, warnings and errors. This is done using a regex, which is very prone to mismatching as Conan does not give very strong identifiable console output. 

Some of these messages we transform into [logging commands](https://learn.microsoft.com/en-us/azure/devops/pipelines/scripts/logging-commands?view=azure-devops&tabs=bash) which are easier to identify in a log and also get warnings and error to the the summary part of a build job.

I can see 3 different ways of making it easier to identify/parse issues:

1. Add an environment variable that prepends a token (i.e. CONAN:) to every output. This is how we deal with ninja progress output. This is really simple to implement and would work sufficiently well for my use-case
2. Enable hooks to replace self.output by providing a factory for the output. Simply setting conanfile.output in each hook method currently does not work because some commands rewrite their output with scoped outputs.
3. Integrate output in the logging command format for azure (I am sure we are no the only ones using Conan in a CI).

Did I miss another way of achieving my goal?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: KarstenB
issue_12228: state: open
title: [bug] AutotoolsToolchain does not respect `extra_cflags` or `extra_cxxflags` when used with environment vars.
body: AutotoolsToolchain does not respect the `extra_cflags` attribute when used with the environment.

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 22.04
  * Compiler+version: clang 14
  * Conan version: 1.52
  * Python version: 3.10

### Steps to reproduce
```
conan new at/1.0.0 -t -m autotools_lib
```

Edit the conanfile `generate` method to add
```py
def generate(self):
  ...  
  env = at_toolchain.environment()
  at_toolchain.extra_cxxflags.append("-march=native")
  at_toolchain.generate(env)
  ...
```

Run 
```
$ conan create . > log.txt
$ grep march log.txt
```

### Expected result

The `-march=native` flag should be present in the compiler command line:

```
/bin/bash ../libtool  --tag=CXX   --mode=link clang++  -stdlib=libc++ -m64 -fPIC -O3 -march=native  -m64 -o libat.la -rpath //lib at.lo
```

### Actual result

The additional flag is not preset

```
/bin/bash ../libtool  --tag=CXX   --mode=link clang++  -stdlib=libc++ -m64 -fPIC -O3  -m64 -o libat.la -rpath //lib at.lo
```

### Workaround

Use
```py
def generate(self):
  at_toolchain = AutotoolsToolchain(self)
  env = at_toolchain.environment()
  env.define("CXXFLAGS", at_toolchain.cxxflags + ["-march=native"])
  at_toolchain.generate(env)
```

The flag is present in the output as expected.


user: planetmarshall
issue_12222: state: open
title: [question] How to generate no configuration suffix when using CMakeDeps?
body: When consuming targets and CMake variables generated by [CMakeDeps](https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmakedeps.html), it generates all variables with a suffix based on its configuration:

https://github.com/conan-io/conan/blob/47353ab2e38b7cf5638dfce26d1fd2640eb2775e/conan/tools/cmake/cmakedeps/templates/__init__.py#L78

```python
@property
def suffix(self):
    if not self.conanfile.is_build_context:
        return ""
    return self.cmakedeps.build_context_suffix.get(self.conanfile.ref.name, "")
```

As result, it regenerates variables like `FOO_LIBS_RELEASE` and `foo_COMPILE_DEFINITIONS_RELEASE`. 

The question is, how to generate only `FOO_LIBS` (without build type suffix)? 

We could try a workaround, forcing the `CMakeDeps` configuration, but fails:

```python
def generate(self):
    deps = CMakeDeps(self)
    deps.configuration = ""
    deps.generate()
```

    conan create . foo/0.1@

```
ERROR: Traceback (most recent call last):
  File "/Users/uilian/.pyenv/versions/3.10.4/lib/python3.10/site-packages/conans/errors.py", line 34, in conanfile_exception_formatter
    yield
  File "/Users/uilian/.pyenv/versions/3.10.4/lib/python3.10/site-packages/conans/client/generators/__init__.py", line 253, in write_toolchain
    conanfile.generate()
  File "/Users/uilian/.conan/data/foo/0.1/_/_/export/conanfile.py", line 16, in generate
    tc.generate()
  File "/Users/uilian/.pyenv/versions/3.10.4/lib/python3.10/site-packages/conan/tools/cmake/cmakedeps/cmakedeps.py", line 46, in generate
    generator_files = self.content
  File "/Users/uilian/.pyenv/versions/3.10.4/lib/python3.10/site-packages/conan/tools/cmake/cmakedeps/cmakedeps.py", line 88, in content
    self._generate_files(require, dep, ret, find_module_mode=False)
  File "/Users/uilian/.pyenv/versions/3.10.4/lib/python3.10/site-packages/conan/tools/cmake/cmakedeps/cmakedeps.py", line 101, in _generate_files
    ret[data_target.filename] = data_target.render()
  File "/Users/uilian/.pyenv/versions/3.10.4/lib/python3.10/site-packages/conan/tools/cmake/cmakedeps/templates/target_data.py", line 20, in filename
    data_fname += "{}-{}".format(self.file_name, self.configuration.lower())
AttributeError: 'NoneType' object has no attribute 'lower'

```

Some projects use `LIBS` instead of `LIBRARIES` and have been working so far, and forcing to patch only because Conan uses target multi feature sounds a bit aggressive.


/cc @ericLemanissier 

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: uilianries
issue_12221: state: open
title: [bug] (Linux) Package with two shared components fails to link both at same time
body: First off, I'm not 100% certain if this is a bug, it very well could be a misunderstanding of how shared libraries work, please correct me if any of my assumptions are incorrect, however, this seems like a bug to me.

I have a single package with two components, pkg1 and pkg2, both shared, and pkg2 depends on pkg1. In my test package, I test two executables, one linking against pkg1, and one linking against pkg2 (and pkg1, implicitly). In the second executable, it fails to find the shared library for the first package.

### Environment Details (include every applicable attribute)
Ubuntu 22.04
Python 3.10
Conan 1.52 (seems to have the same behavior since 1.46)
GCC 11 (10 has the same behavior)

### Steps to reproduce (Include if Applicable)

I have a repo [here](https://github.com/Ahajha/double-shared-library-conan) showing a minimum reproducible example.

From there, run `conan create . 0.0.1@test/test`

Thanks in advance!
user: Ahajha
issue_12216: state: open
title: [bug] Error with CMakePresets on build missing package
body: When I try to build a missing package on Windows there is an error related with CMake presets.

I reproduced the issue in a minimum example here:

[example repository](https://github.com/joaquinherrero-facephi/issue-cmake-presets)

It seems that fails only on windows, so I suppose that is something related with CMakeDeps/Visual studio environment setup.

NOTES: 
There is a first call to vcvars (maybe done before build() method?) from conan side and then another from the tools.vcvars_dict call.

If I remove the environment append section on build method it works correctly. But I do not understand the error related with the CMake preset version field. 

### Environment:
  * Operating System+version: Windows 10 Home
  * Compiler+version: Visual Studio 16
  * Conan version: 1.52.0
  * Python version: 3.10.0

### Steps to reproduce

```
conan export lib
conan install -pr:h profile_win -pr:b profile_win -b "hello" app
```

### Logs

```Exporting package recipe
hello/1.0.0: Calling export_sources()
hello/1.0.0 export_sources() method: Copied 1 '.h' file: hello.h
hello/1.0.0 export_sources() method: Copied 1 '.cpp' file: hello.cpp
hello/1.0.0 export_sources() method: Copied 1 '.txt' file: CMakeLists.txt
hello/1.0.0: A new conanfile.py version was exported
hello/1.0.0: Folder: C:\Users\joaquinherrero\.conan\data\hello\1.0.0\_\_\export
hello/1.0.0: Using the exported files summary hash as the recipe revision: 6e66b54a72edf10b2610f9ebff57a5c0
hello/1.0.0: Package recipe modified in export, forcing source folder removal
hello/1.0.0: Use the --keep-source, -k option to skip it
hello/1.0.0: Exported revision: 6e66b54a72edf10b2610f9ebff57a5c0
Configuration (profile_host):
[settings]
arch=x86_64
arch_target=x86_64
build_type=Release
compiler=Visual Studio
compiler.cppstd=17
compiler.runtime=MD
compiler.toolset=v142
compiler.version=16
os=Windows
os_target=Windows
[options]
*:shared=False
[build_requires]
[env]
[conf]
tools.cmake.cmaketoolchain:generator=Ninja Multi-Config

Configuration (profile_build):
[settings]
arch=x86_64
arch_target=x86_64
build_type=Release
compiler=Visual Studio
compiler.cppstd=17
compiler.runtime=MD
compiler.toolset=v142
compiler.version=16
os=Windows
os_target=Windows
[options]
*:shared=False
[build_requires]
[env]
[conf]
tools.cmake.cmaketoolchain:generator=Ninja Multi-Config

hello/1.0.0: Forced build from source
conanfile.py (app/1.0.0): Installing package
Requirements
    hello/1.0.0 from local cache - Cache
Packages
    hello/1.0.0:f26537b056c9ff213dcc2874372b233408a3e04e - Build

Installing (downloading, building) binaries...
hello/1.0.0: WARN: Build folder is dirty, removing it: C:\Users\joaquinherrero\.conan\data\hello\1.0.0\_\_\build\f26537b056c9ff213dcc2874372b233408a3e04e
hello/1.0.0: Configuring sources in C:\Users\joaquinherrero\.conan\data\hello\1.0.0\_\_\source\.
hello/1.0.0: Copying sources to build folder
hello/1.0.0: Building your package in C:\Users\joaquinherrero\.conan\data\hello\1.0.0\_\_\build\f26537b056c9ff213dcc2874372b233408a3e04e
hello/1.0.0: Generator 'CMakeDeps' calling 'generate()'
hello/1.0.0: Calling generate()
hello/1.0.0: Aggregating env generators
hello/1.0.0: Calling build()
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.11.5
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.11.5
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
CMake Error: Could not read presets from C:/Users/joaquinherrero/.conan/data/hello/1.0.0/_/_/build/f26537b056c9ff213dcc2874372b233408a3e04e: Unrecognized "version" field
hello/1.0.0:
hello/1.0.0: ERROR: Package 'f26537b056c9ff213dcc2874372b233408a3e04e' build failed
hello/1.0.0: WARN: Build folder C:\Users\joaquinherrero\.conan\data\hello\1.0.0\_\_\build\f26537b056c9ff213dcc2874372b233408a3e04e\build
ERROR: hello/1.0.0: Error in build() method, line 68
        self.run(cmd_cmake_config)
        ConanException: Error 1 while executing cmake --preset default```
user: joaquinherrero-facephi
issue_12211: state: open
title: [feature] Add options based on the version of a recipe
body: <!-- What is your question? Please be as specific as possible! -->

This is from https://github.com/conan-io/conan-center-index/pull/13184#issuecomment-1260176736.

Currently the work flow we have resembles:

- `init`
- `config_options`
- "apply profiles"
- `configure`

The problem is conancenter uses `conan info` to learn about the available options but these do not take into account the version **AND** give users meaningful error messages

👉 Currently CCI allows users to pass options that are completely ignored so "I want this lib shared" does not actually mean you'll get a shared lib 😱 

### Adding it in `init`

we  do not have `self.version` at this point

```py
class PackageConan(ConanFile):
    name = "package"

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"fPIC": [True, False]}
    default_options = {"fPIC": True}

    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "CMakeLists.txt", "src/*", "include/*"

    def init(self):
        print(self.version)
        if Version(self.version) >= "0.2.0":
            self.options["shared"] = [True, False]
            self.default_options["shared"] = False
```

Sadly the version here being passed at the CLI is not known to the recipe

```sh
$ conan export . 0.1.0@
None
$ conan export . 0.2.0@
None
```

### Removing it from `config_options`

```py
class PackageConan(ConanFile):
    name = "package"

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False],"fPIC": [True, False]}
    default_options = {"shared":  False,"fPIC": True}

    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "CMakeLists.txt", "src/*", "include/*"

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC
        if Version(self.version) < "0.2.0":
            del self.options.shared
```

Makes the option completely unavailable in 0.2.0 (which is currently how CCI determines which are available)


```sh
$ conan inspect package/0.1.0@
name: package
version: 0.1.0
url: None
homepage: None
license: None
author: None
description: None
topics: None
generators: ['txt']
exports: None
exports_sources: ('CMakeLists.txt', 'src/*', 'include/*')
short_paths: False
apply_env: True
build_policy: None
revision_mode: hash
settings: ('os', 'compiler', 'build_type', 'arch')
options:
    fPIC: [True, False]
    shared: [True, False]
default_options:
    fPIC: True
    shared: False
deprecated: None
$ conan inspect package/0.2.0@
name: package
version: 0.2.0
url: None
homepage: None
license: None
author: None
description: None
topics: None
generators: ['txt']
exports: None
exports_sources: ('CMakeLists.txt', 'src/*', 'include/*')
short_paths: False
apply_env: True
build_policy: None
revision_mode: hash
settings: ('os', 'compiler', 'build_type', 'arch')
options:
    fPIC: [True, False]
    shared: [True, False]
default_options:
    fPIC: True
    shared: False
deprecated: None
```

`conan info` correctly fails

```sh
$ conan info package/0.1.0@ -o package:shared=True
ERROR: package/0.1.0: option 'shared' doesn't exist
Possible options are ['fPIC']
```

### using `configure`

```py
class PackageConan(ConanFile):
    name = "package"

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False],"fPIC": [True, False]}
    default_options = {"shared":  False,"fPIC": True}

    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "CMakeLists.txt", "src/*", "include/*"

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def configure(self):
        if Version(self.version) < "0.2.0":
            del self.options.shared
```

The option is incorrectly available for 0.1.0

```sh
$ conan inspect package/0.1.0@
name: package
version: 0.1.0
url: None
homepage: None
license: None
author: None
description: None
topics: None
generators: ['txt']
exports: None
exports_sources: ('CMakeLists.txt', 'src/*', 'include/*')
short_paths: False
apply_env: True
build_policy: None
revision_mode: hash
settings: ('os', 'compiler', 'build_type', 'arch')
options:
    fPIC: [True, False]
    shared: [True, False]
default_options:
    fPIC: True
    shared: False
deprecated: None
$ conan inspect package/0.2.0@
name: package
version: 0.2.0
url: None
homepage: None
license: None
author: None
description: None
topics: None
generators: ['txt']
exports: None
exports_sources: ('CMakeLists.txt', 'src/*', 'include/*')
short_paths: False
apply_env: True
build_policy: None
revision_mode: hash
settings: ('os', 'compiler', 'build_type', 'arch')
options:
    fPIC: [True, False]
    shared: [True, False]
default_options:
    fPIC: True
    shared: False
deprecated: None
```

however this allows passing the option in (incorrectly to 0.1.0 where this does not exist)

```sh
$ conan info package/0.1.0@ -o package:shared=True
package/0.1.0
    ID: 0094e5ca692951fde1f9889e7498de22717262dd
    BuildID: None
    Context: host
    Remote: None
    Provides: package
    Recipe: Cache
    Revision: 4c221dc4b5c1214bcb9a4b99c3635aca
    Package revision: None
    Binary: Missing
    Binary remote: None
    Creation date: 2022-09-28 15:45:57 UTC
$ conan info package/0.2.0@ -o package:shared=True
package/0.2.0
    ID: 98e27508f54bda7aede57f76ae1de7dab93fe8c1
    BuildID: None
    Context: host
    Remote: None
    Provides: package
    Recipe: Cache
    Revision: 4c221dc4b5c1214bcb9a4b99c3635aca
    Package revision: None
    Binary: Missing
    Binary remote: None
    Creation date: 2022-09-28 15:46:02 UTC
```

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: prince-chrismc
issue_12204: state: open
title: [bug] tools.untargz() / tools.get() errors out if strip_root=True on some tarballs if the file being extracted is a symlink that begins with the same substring as the common folder name
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version: -
  * Conan version: 1.49 
  * Python version: 3.8.10

### Steps to reproduce (Include if Applicable)

When executing `tools.untargz()` or `tools.get()` on this file: https://github.com/espressif/crosstool-NG/releases/download/esp-2022r1/riscv32-esp-elf-gcc11_2_0-esp-2022r1-linux-amd64.tar.xz

both functions fail with an unhandled `IndexError`. This can be traced to: https://github.com/conan-io/conan/blob/0fe6058771c7d9585f9fed1935a4e0ec078d3314/conans/client/tools/files.py#L180

In this case, the error is occurring because member `riscv32-esp-elf/bin/riscv32-esp-elf-cc` is a symlink to `riscv32-esp-elf-gcc` in the same directory. Since the member linkpath starts with `riscv32-esp-elf` and the `common_folder` name is `riscv32-esp-elf` and the symlink can't be split, this line results in an unhandled `IndexError`.

Currently I'm fixing this by untarring the file in my own `conanfile.py`  with an extra check to make sure the linkpath can actually be split.

Here's my little minimal test script:
```python
import os
from fnmatch import fnmatch

def untargz(filename, destination=".", pattern=None, strip_root=False):
    import tarfile
    with tarfile.TarFile.open(filename, 'r:*') as tarredgzippedFile:
        if not pattern and not strip_root:
            tarredgzippedFile.extractall(destination)
        else:
            members = tarredgzippedFile.getmembers()

            if strip_root:
                names = [n.replace("\\", "/") for n in tarredgzippedFile.getnames()]
                common_folder = os.path.commonprefix(names).split("/", 1)[0]
                #if not common_folder and len(names) > 1:
                #    raise ConanException("The tgz file contains more than 1 folder in the root")
                #if len(names) == 1 and len(names[0].split("/", 1)) == 1:
                #    raise ConanException("The tgz file contains a file in the root")
                # Remove the directory entry if present
                members = [m for m in members if m.name != common_folder]
                for member in members:
                    name = member.name.replace("\\", "/")
                    member.name = name.split("/", 1)[1]
                    member.path = member.name
                    if member.linkpath.startswith(common_folder):
                        # https://github.com/conan-io/conan/issues/11065
                        linkpath = member.linkpath.replace("\\", "/")
                        member.linkpath = linkpath.split("/", 1)[1]
                        member.linkname = member.linkpath
            if pattern:
                members = list(filter(lambda m: fnmatch(m.name, pattern),
                                      tarredgzippedFile.getmembers()))
            tarredgzippedFile.extractall(destination, members=members)

if __name__ == "__main__":
    untargz("gcc.tar.xz", strip_root=True)
```
user: tldrEllie
issue_12203: state: open
title: [bug] conan lock/install/build bypass validate failure
body: Using validate does not prevent conan lock/install/build from succeeding even though the validate method is throwing a ConanInvalidConfiguration. This is bypassing validate failures in our CI/CD pipelines.

[Docs state that](https://docs.conan.io/en/latest/reference/conanfile/methods.html?highlight=validate#validate) `If you try to use, consume or build such a package, it will raise an error, returning exit code` but this seems to only be true for the `conan create` command.

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 22.04.1 LTS
  * Compiler+version: gcc 11.2
  * Conan version: 1.52
  * Python version: 3.10.4

### Steps to reproduce (Include if Applicable)

1. Create a new conan project ex: `conan new LockFailValid/1.0.0`
2. Add a validate method that raises a `ConanInvalidConfiguration` and optionally prints to terminal. 
```python
    def validate(self):
        print("ran validate")
        raise ConanInvalidConfiguration("fail validate")
```
3. Add a `hello` folder and blank `CMakeLists.txt` (`hello/CMakeLists.txt`)
4. Run `conan lock create conanfile.py`
5. Run `conan install --lockfile conan.lock .`
6. Run `conan build .`

### Logs (Executed commands with output) (Include/Attach if Applicable)

`conan lock create conanfile.py`
```
ran validate
Requirements
Packages

Generated lockfile: /home/****/test/bad_lock/conan.lock
```

`conan install --lockfile conan.lock .`
```
Using lockfile: '/home/****/test/bad_lock/conan.lock'
Configuration (profile_host):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
ran validate
conanfile.py (LockFailValid/1.0.0): Installing package
Requirements
Packages

Installing (downloading, building) binaries...
conanfile.py (LockFailValid/1.0.0): ERROR: Invalid ID: fail validate. Trying to install dependencies, but this configuration will fail to build a package
conanfile.py (LockFailValid/1.0.0): Generator txt created conanbuildinfo.txt
conanfile.py (LockFailValid/1.0.0): Generator cmake created conanbuildinfo.cmake
conanfile.py (LockFailValid/1.0.0): Aggregating env generators
conanfile.py (LockFailValid/1.0.0): Generated conaninfo.txt
conanfile.py (LockFailValid/1.0.0): Generated graphinfo
```

`conan build .`
```
Using lockfile: '/home/****/test/bad_lock/conan.lock'
Using cached profile from lockfile
conanfile.py (LockFailValid/1.0.0): Calling build()
-- Configuring done
-- Generating done
-- Build files have been written to: /home/****/test/bad_lock
```
user: Reg-Arvidson-Bose
issue_12198: state: open
title: Execute GTest/Unit Test as a part of a build (not a test_package test question)
body: 
I am just trying my hand at Conan-IO+CMake, I am trying to execute UnitTests at build time and Conan/CMake is just not able to find the test executable. I have included my conanfile.py and CMakeLists.txt in the question itself.

Conanfile.py

from conans import ConanFile, CMake, tools
from conan.tools.cmake import CMakeToolchain,CMakeDeps
from conan.tools.layout import cmake_layout


class MylibConan(ConanFile):
    name = "mylib"
    version = "1.0.0"
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of Mylib here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False],}
    default_options = {"boost:shared":False,"shared": False, "fPIC": True} # if shared is true, we would have this as a shared library
    
    generators="cmake","cmake_find_package","json","virtualenv"
    exports_sources = (
        "CMakeLists.txt"
    )
    no_copy_source = True
    #The below method would be triggered iff you unset the no_copy_source variable
    #def export_source(self):
    #    self.copy("*")
    @property
    def _cmake(self):
        cmake = CMake(self)
        return cmake
    def requirements(self):
        self.requires("gtest/1.12.1")
    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC
    def generator(self): #Preprocessor
        tc = CMakeToolchain(self,generator='Ninja')
        tc.generate()
        CMakeDeps(self).generate() #creates findBoost.cmake
    def test(self):
        self.run("bin/runUnitTests")
    def build(self):
        cmake = CMake(self,generator='Ninja')
        cmake.configure(source_folder=self.source_folder)
        cmake.build()
        cmake.test(output_on_failure=True)
        # Explicit way:
        # self.run('cmake %s/hello %s'
        #          % (self.source_folder, cmake.command_line))
        # self.run("cmake --build . %s" % cmake.build_config)

    def package(self):
        self._cmake.install()

    def package_info(self):
        self.cpp_info.libs = ["hello"]


The following is my CMakeLists.txt file located in the same folder. This is the only CMakeFile in the entire project. I have included only the relevant portions

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup(TARGETS)
enable_testing()

find_package(GTest REQUIRED)


add_executable(runUnitTests UniteTest.cpp)
target_link_libraries(runUnitTests GTest::gtest)
add_test(runUnitTests runUnitTests)


I get the following error Message. Any ideas on how can I remedy this?

**Test project <project_location>/build
    Start 1: runUnitTests
Could not find executable runUnitTests
Looked in the following places:
runUnitTests
runUnitTests.exe
Release/runUnitTests
Release/runUnitTests.exe
Debug/runUnitTests
Debug/runUnitTests.exe
MinSizeRel/runUnitTests
MinSizeRel/runUnitTests.exe
RelWithDebInfo/runUnitTests
RelWithDebInfo/runUnitTests.exe
Deployment/runUnitTests
Deployment/runUnitTests.exe
Development/runUnitTests
**Development/runUnitTests.exe**
Unable to find executable: runUnitTests
1/1 Test #1: runUnitTests .....................Not Run   0.00 sec**
user: ujjwal1002
issue_12197: state: open
title: [bug] Apple flags are not sent to other build systems (bitcode, arc, visibility)
body: Hi,

With the new feature of enabling bitcode, arc and visibility, we can see that only dependencies built with Xcode will receive the flags:

https://github.com/conan-io/conan/commit/d383bb2de05f9d3132e624e9fab67784eb9373ea

But recipes like openssl and others that don't will be built with this, will be compiled without the bitcode, for example.

The result is an error when link:

```
ld: '/Users/paulo/.conan/data/openssl/1.1.1q/_/_/package/801ae4682e3f478afa7107aea3a8a4cf47aa78a5/lib/libcrypto.a(digest.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

### Environment Details (include every applicable attribute)
  * Operating System+version: macos latest
  * Compiler+version: clang 13
  * Conan version: 1.52
  * Python version: 3.9

### Steps to reproduce (Include if Applicable)


### Logs (Executed commands with output) (Include/Attach if Applicable)

```
Configuration (profile_host):
[settings]
arch=armv8
arch_build=armv8
build_type=Debug
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=14
os=iOS
os.sdk=iphoneos
os.version=11.0
os_build=Macos
[options]
nativium_arch=arm64
nativium_build_type=debug
nativium_group=ios
nativium_product_name=Nativium
nativium_project_name=nativium
nativium_target=ios
nativium_version=1.0.0
nativium_version_code=1
[build_requires]
[env]
[conf]
tools.apple:enable_bitcode=True
tools.apple:enable_arc=True

Configuration (profile_build):
[settings]
arch=armv8
arch_build=armv8
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=14
os=Macos
os_build=Macos
[options]
[build_requires]
[env]
```

user: paulocoutinhox
issue_12191: state: open
title: [feature] Add ability to specify separate "tools" and "library" repos in Conan 2
body: One of my favorite aspects of Conan is the ability to manage and deploy toolchains (compilers, build tools etc.) in an automated manner as part of using Conan for application/product libraries. This feature has gotten even better in Conan 2.0 with the cleaner distinction between "build" and "host" profile settings and the "tool_requires" profile feature. (As an aside the nomenclature is still somewhat confusing, i.e., tool_requires vs. the older build_requires, which actually aligns better with the "build" profile, but I digress).

I realize that I can upload tools to a separate Conan Artifactory repo by specifying the -r options to "conan upload", but the feature I am looking for is the ability to add a qualifier to each entry in my remotes.json file indicating whether a repo is suitable for resolving "tool" (build profile) vs. "library" (host profile) dependencies. My motivation for this request is to be able to establish a clear demarcation between libraries that may ultimately ship to customers/end users vs. those used only for internal purposes. I may have missed something, but I am not currently aware of any way to provide this separation today.

In summary,, I'm looking for something like:
  conan remote add conan-tools http://artifactory;8082/artifactory/api/conan/conan-local-tools" --tools [could be the default]
  conan remote add conan-prod http://artifactory;8082/artifactory/api/conan/conan-local-prod" --notools

Thank you for your consideration and for building such a useful and powerful tool.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: System-Arch
issue_12189: state: open
title: [question] CMakeToolchain and custom block: how to control position of the block & avoid boilerplate?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

In conan-center, there are several conan v1 recipes with arbitrary logic in the CMakeLists wrapper (usually to avoid big patches, or improve robustness). Sometimes this custom code strongly relies on stuff previously defined (options, system processor etc).

So two questions for migration of these recipes to `CMakeToolchain`:

- Since `CMakeToolchain` set options, system processor etc, how to ensure that our custom logic is appended after all built-in blocks? Indeed, I've tested and my custom block was added right before Variables blocks.

- How to avoid this boilerplate:

   ```python
   def generate(self):
       tc = CMakeToolchain(self)
       class MyGenericBlock:
           template = textwrap.dedent("""\
               if(NOT TARGET glslang)
                   add_library(glslang INTERFACE) # fake target for upstream CMakeLists (glslang required by tests only)
               endif()
           """)

           def context(self):
               return {}

       tc.blocks["custom_block"] = MyGenericBlock
       tc.generate()
   ```

   why can't we simply do:

   ```python
   def generate(self):
       tc = CMakeToolchain(self)
       tc.blocks["custom_block"] = textwrap.dedent("""\
           if(NOT TARGET glslang)
               add_library(glslang INTERFACE) # fake target for upstream CMakeLists (glslang required by tests only)
           endif()
       """)
       tc.generate()
   ```
user: SpaceIm
issue_12187: state: open
title: [question] Is get_property("cmake_file_name") of dependencies always defined?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

In `self.dependencies[lib].cpp_info` or `self.dependencies[lib].cpp_info.components[comp]`, is `get_property()` of either `cmake_find_mode`/`cmake_file_name`/`cmake_module_file_name`/`cmake_target_name`/`cmake_module_target_name`/`pkg_config_name` always defined (not None) regardless of wheter `package_info()` of this dependency/component has explicitly defined these properties?

In source code of conan I see sometimes tests to check whether these values are None.
user: SpaceIm
issue_12181: state: open
title: [bug] Conan install commad get error "CMake Error: Unknown argument --prefix"
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: MacOS Momentary 12.6 

But I build inside container dockcross/linux-armv7-lts
```
$ uname -a
> Linux ed92e4a451d3 5.10.124-linuxkit #1 SMP Thu Jun 30 08:19:10 UTC 2022 x86_64 GNU/Linux
```
  * Compiler+version: 
```
$ gcc --version
> gcc (Debian 10.2.1-6) 10.2.1 20210110
```
But `conan profile new name --detect` create next profile
```
compiler=gcc
compiler.version=8
compiler.libcxx=libstdc++11
```
  * Conan version: 1.52.0
  * Python version:3.9.2

### Steps to reproduce (Include if Applicable)
**Sources:**
https://github.com/Ryslan342/dockross-armv7-and-connon

**Main attention on**
- It how I create image 
https://github.com/Ryslan342/dockross-armv7-and-connon/blob/try_to_use_conan_docker_image/arm7/Dockerfile
- Build script 
https://github.com/Ryslan342/dockross-armv7-and-connon/blob/try_to_use_conan_docker_image/arm7/build-image.sh

### Logs (Executed commands with output) (Include/Attach if Applicable)
<details>
  <summary>Logs</summary>

```
Deploying '<unknown> Dockerfile: arm7/Dockerfile'…
Building image…
Preparing build context archive…
[==================================================>]94/94 files
Done

Sending build context to Docker daemon…
[==================================================>] 79,32kB
Done

Step 1/4 : FROM dockcross/linux-armv7-lts
 ---> 95f79f51f015
Step 2/4 : WORKDIR /work
 ---> Using cache
 ---> 0163f8c137d2
Step 3/4 : COPY ./ ./
 ---> 95c4eea3b7f4
Step 4/4 : RUN /bin/bash -c "source ./arm7/build-image.sh"
 ---> Running in cc883fa2517f
Requirement already satisfied: conan in /usr/local/lib/python3.9/dist-packages (1.52.0)
Requirement already satisfied: Jinja2<4.0.0,>=3.0 in /usr/local/lib/python3.9/dist-packages (from conan) (3.1.2)
Requirement already satisfied: node-semver==0.6.1 in /usr/local/lib/python3.9/dist-packages (from conan) (0.6.1)
Requirement already satisfied: requests<3.0.0,>=2.25 in /usr/local/lib/python3.9/dist-packages (from conan) (2.28.1)
Requirement already satisfied: urllib3<1.27,>=1.26.6 in /usr/local/lib/python3.9/dist-packages (from conan) (1.26.12)
Requirement already satisfied: colorama<0.5.0,>=0.3.3 in /usr/local/lib/python3.9/dist-packages (from conan) (0.4.5)
Requirement already satisfied: PyYAML<=6.0,>=3.11 in /usr/local/lib/python3.9/dist-packages (from conan) (6.0)
Requirement already satisfied: python-dateutil<3,>=2.7.0 in /usr/local/lib/python3.9/dist-packages (from conan) (2.8.2)
Requirement already satisfied: bottle<0.13,>=0.12.8 in /usr/local/lib/python3.9/dist-packages (from conan) (0.12.23)
Requirement already satisfied: PyJWT<3.0.0,>=2.4.0 in /usr/local/lib/python3.9/dist-packages (from conan) (2.5.0)
Requirement already satisfied: six<=1.16.0,>=1.10.0 in /usr/local/lib/python3.9/dist-packages (from conan) (1.16.0)
Requirement already satisfied: pygments<3.0,>=2.0 in /usr/local/lib/python3.9/dist-packages (from conan) (2.13.0)
Requirement already satisfied: tqdm<5,>=4.28.1 in /usr/local/lib/python3.9/dist-packages (from conan) (4.64.1)
Requirement already satisfied: patch-ng<1.18,>=1.17.4 in /usr/local/lib/python3.9/dist-packages (from conan) (1.17.4)
Requirement already satisfied: fasteners>=0.14.1 in /usr/local/lib/python3.9/dist-packages (from conan) (0.18)
Requirement already satisfied: distro<=1.6.0,>=1.0.2 in /usr/local/lib/python3.9/dist-packages (from conan) (1.6.0)
Requirement already satisfied: pluginbase>=0.5 in /usr/local/lib/python3.9/dist-packages (from conan) (1.0.1)
Requirement already satisfied: MarkupSafe>=2.0 in /usr/local/lib/python3.9/dist-packages (from Jinja2<4.0.0,>=3.0->conan) (2.1.1)
Requirement already satisfied: charset-normalizer<3,>=2 in /usr/local/lib/python3.9/dist-packages (from requests<3.0.0,>=2.25->conan) (2.1.1)
Requirement already satisfied: certifi>=2017.4.17 in /usr/local/lib/python3.9/dist-packages (from requests<3.0.0,>=2.25->conan) (2022.9.14)
Requirement already satisfied: idna<4,>=2.5 in /usr/local/lib/python3.9/dist-packages (from requests<3.0.0,>=2.25->conan) (3.4)
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
CC and CXX: /usr/xcc/armv7-unknown-linux-gnueabi/bin/armv7-unknown-linux-gnueabi-gcc, /usr/xcc/armv7-unknown-linux-gnueabi/bin/armv7-unknown-linux-gnueabi-g++ 
Found gcc 8.5
gcc>=5, using the major as version

************************* WARNING: GCC OLD ABI COMPATIBILITY ***********************
 
Conan detected a GCC version > 5 but has adjusted the 'compiler.libcxx' setting to
'libstdc++' for backwards compatibility.
Your compiler is likely using the new CXX11 ABI by default (libstdc++11).

If you want Conan to use the new ABI for the default profile, run:

    $ conan profile update settings.compiler.libcxx=libstdc++11 default

Or edit '/root/.conan/profiles/default' and set compiler.libcxx=libstdc++11

************************************************************************************



Profile created with detected settings: /root/.conan/profiles/default
[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]
WARN: Remotes registry file missing, creating default one in /root/.conan/remotes.json
Configuration:
[settings]
arch=armv7
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=8
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
[conf]
tools.system.package_manager:sudo=True
tools.system.package_manager:mode=install

opencv/4.5.5: Not found in local cache, looking in remotes...
opencv/4.5.5: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
opencv/4.5.5: Downloaded recipe revision 0
zlib/1.2.12: Not found in local cache, looking in remotes...
zlib/1.2.12: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
zlib/1.2.12: Downloaded recipe revision 0
libjpeg/9d: Not found in local cache, looking in remotes...
libjpeg/9d: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libjpeg/9d: Downloaded recipe revision 0
jasper/2.0.33: Not found in local cache, looking in remotes...
jasper/2.0.33: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
jasper/2.0.33: Downloaded recipe revision 0
libpng/1.6.37: Not found in local cache, looking in remotes...
libpng/1.6.37: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libpng/1.6.37: Downloaded recipe revision 0
openexr/2.5.7: Not found in local cache, looking in remotes...
openexr/2.5.7: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
openexr/2.5.7: Downloaded recipe revision 0
libtiff/4.3.0: Not found in local cache, looking in remotes...
libtiff/4.3.0: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libtiff/4.3.0: Downloaded recipe revision 0
WARN: libtiff/4.3.0: requirement libwebp/1.2.3 overridden by opencv/4.5.5 to libwebp/1.2.2 
libdeflate/1.12: Not found in local cache, looking in remotes...
libdeflate/1.12: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libdeflate/1.12: Downloaded recipe revision 0
xz_utils/5.2.5: Not found in local cache, looking in remotes...
xz_utils/5.2.5: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
xz_utils/5.2.5: Downloaded recipe revision 0
jbig/20160605: Not found in local cache, looking in remotes...
jbig/20160605: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
jbig/20160605: Downloaded recipe revision 0
zstd/1.5.2: Not found in local cache, looking in remotes...
zstd/1.5.2: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
zstd/1.5.2: Downloaded recipe revision 0
libwebp/1.2.2: Not found in local cache, looking in remotes...
libwebp/1.2.2: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libwebp/1.2.2: Downloaded recipe revision 0
eigen/3.3.9: Not found in local cache, looking in remotes...
eigen/3.3.9: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
eigen/3.3.9: Downloaded recipe revision 0
ffmpeg/4.4: Not found in local cache, looking in remotes...
ffmpeg/4.4: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
ffmpeg/4.4: Downloaded recipe revision 0
WARN: ffmpeg/4.4: requirement libwebp/1.2.3 overridden by opencv/4.5.5 to libwebp/1.2.2 
bzip2/1.0.8: Not found in local cache, looking in remotes...
bzip2/1.0.8: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
bzip2/1.0.8: Downloaded recipe revision 0
libiconv/1.17: Not found in local cache, looking in remotes...
libiconv/1.17: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libiconv/1.17: Downloaded recipe revision 0
freetype/2.12.1: Not found in local cache, looking in remotes...
freetype/2.12.1: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
freetype/2.12.1: Downloaded recipe revision 0
brotli/1.0.9: Not found in local cache, looking in remotes...
brotli/1.0.9: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
brotli/1.0.9: Downloaded recipe revision 0
openjpeg/2.5.0: Not found in local cache, looking in remotes...
openjpeg/2.5.0: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
openjpeg/2.5.0: Downloaded recipe revision 0
openh264/2.1.1: Not found in local cache, looking in remotes...
openh264/2.1.1: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
openh264/2.1.1: Downloaded recipe revision 0
vorbis/1.3.7: Not found in local cache, looking in remotes...
vorbis/1.3.7: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
vorbis/1.3.7: Downloaded recipe revision 0
ogg/1.3.5: Not found in local cache, looking in remotes...
ogg/1.3.5: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
ogg/1.3.5: Downloaded recipe revision 0
opus/1.3.1: Not found in local cache, looking in remotes...
opus/1.3.1: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
opus/1.3.1: Downloaded recipe revision 0
libx264/20191217: Not found in local cache, looking in remotes...
libx264/20191217: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libx264/20191217: Downloaded recipe revision 0
libx265/3.4: Not found in local cache, looking in remotes...
libx265/3.4: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libx265/3.4: Downloaded recipe revision 0
libvpx/1.11.0: Not found in local cache, looking in remotes...
libvpx/1.11.0: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libvpx/1.11.0: Downloaded recipe revision 0
libmp3lame/3.100: Not found in local cache, looking in remotes...
libmp3lame/3.100: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libmp3lame/3.100: Downloaded recipe revision 0
libfdk_aac/2.0.2: Not found in local cache, looking in remotes...
libfdk_aac/2.0.2: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libfdk_aac/2.0.2: Downloaded recipe revision 0
openssl/1.1.1q: Not found in local cache, looking in remotes...
openssl/1.1.1q: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
openssl/1.1.1q: Downloaded recipe revision 0
libalsa/1.2.7.2: Not found in local cache, looking in remotes...
libalsa/1.2.7.2: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libalsa/1.2.7.2: Downloaded recipe revision 0
xorg/system: Not found in local cache, looking in remotes...
xorg/system: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
xorg/system: Downloaded recipe revision 0
pulseaudio/14.2: Not found in local cache, looking in remotes...
pulseaudio/14.2: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
pulseaudio/14.2: Downloaded recipe revision 0
libsndfile/1.0.31: Not found in local cache, looking in remotes...
libsndfile/1.0.31: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libsndfile/1.0.31: Downloaded recipe revision 0
flac/1.3.3: Not found in local cache, looking in remotes...
flac/1.3.3: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
flac/1.3.3: Downloaded recipe revision 0
libcap/2.65: Not found in local cache, looking in remotes...
libcap/2.65: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libcap/2.65: Downloaded recipe revision 0
libtool/2.4.7: Not found in local cache, looking in remotes...
libtool/2.4.7: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libtool/2.4.7: Downloaded recipe revision 0
automake/1.16.5: Not found in local cache, looking in remotes...
automake/1.16.5: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
automake/1.16.5: Downloaded recipe revision 0
autoconf/2.71: Not found in local cache, looking in remotes...
autoconf/2.71: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
autoconf/2.71: Downloaded recipe revision 0
m4/1.4.19: Not found in local cache, looking in remotes...
m4/1.4.19: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
m4/1.4.19: Downloaded recipe revision 0
vaapi/system: Not found in local cache, looking in remotes...
vaapi/system: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
vaapi/system: Downloaded recipe revision 0
vdpau/system: Not found in local cache, looking in remotes...
vdpau/system: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
vdpau/system: Downloaded recipe revision 0
vulkan-loader/1.3.221: Not found in local cache, looking in remotes...
vulkan-loader/1.3.221: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
vulkan-loader/1.3.221: Downloaded recipe revision 0
vulkan-headers/1.3.221: Not found in local cache, looking in remotes...
vulkan-headers/1.3.221: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
vulkan-headers/1.3.221: Downloaded recipe revision 0
wayland/1.20.0: Not found in local cache, looking in remotes...
wayland/1.20.0: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
wayland/1.20.0: Downloaded recipe revision 0
libffi/3.4.2: Not found in local cache, looking in remotes...
libffi/3.4.2: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libffi/3.4.2: Downloaded recipe revision 0
libxml2/2.9.14: Not found in local cache, looking in remotes...
libxml2/2.9.14: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
libxml2/2.9.14: Downloaded recipe revision 0
expat/2.4.8: Not found in local cache, looking in remotes...
expat/2.4.8: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
expat/2.4.8: Downloaded recipe revision 0
quirc/1.1: Not found in local cache, looking in remotes...
quirc/1.1: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
quirc/1.1: Downloaded recipe revision 0
gtk/system: Not found in local cache, looking in remotes...
gtk/system: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
gtk/system: Downloaded recipe revision 0
protobuf/3.17.1: Not found in local cache, looking in remotes...
protobuf/3.17.1: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
protobuf/3.17.1: Downloaded recipe revision 0
ade/0.1.1f: Not found in local cache, looking in remotes...
ade/0.1.1f: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
ade/0.1.1f: Downloaded recipe revision 0
gnu-config/cci.20210814: Not found in local cache, looking in remotes...
gnu-config/cci.20210814: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
gnu-config/cci.20210814: Downloaded recipe revision 0
gnu-config/cci.20201022: Not found in local cache, looking in remotes...
gnu-config/cci.20201022: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
gnu-config/cci.20201022: Downloaded recipe revision 0
yasm/1.3.0: Not found in local cache, looking in remotes...
yasm/1.3.0: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
yasm/1.3.0: Downloaded recipe revision 0
pkgconf/1.7.4: Not found in local cache, looking in remotes...
pkgconf/1.7.4: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
pkgconf/1.7.4: Downloaded recipe revision 0
meson/0.62.1: Not found in local cache, looking in remotes...
meson/0.62.1: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
meson/0.62.1: Downloaded recipe revision 0
ninja/1.11.0: Not found in local cache, looking in remotes...
ninja/1.11.0: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
ninja/1.11.0: Downloaded recipe revision 0
meson/0.63.2: Not found in local cache, looking in remotes...
meson/0.63.2: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
meson/0.63.2: Downloaded recipe revision 0
gettext/0.21: Not found in local cache, looking in remotes...
gettext/0.21: Trying with 'conancenter'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
gettext/0.21: Downloaded recipe revision 0
conanfile.txt: Installing package
Requirements
    ade/0.1.1f from 'conancenter' - Downloaded
    autoconf/2.71 from 'conancenter' - Downloaded
    automake/1.16.5 from 'conancenter' - Downloaded
    brotli/1.0.9 from 'conancenter' - Downloaded
    bzip2/1.0.8 from 'conancenter' - Downloaded
    eigen/3.3.9 from 'conancenter' - Downloaded
    expat/2.4.8 from 'conancenter' - Downloaded
    ffmpeg/4.4 from 'conancenter' - Downloaded
    flac/1.3.3 from 'conancenter' - Downloaded
    freetype/2.12.1 from 'conancenter' - Downloaded
    gtk/system from 'conancenter' - Downloaded
    jasper/2.0.33 from 'conancenter' - Downloaded
    jbig/20160605 from 'conancenter' - Downloaded
    libalsa/1.2.7.2 from 'conancenter' - Downloaded
    libcap/2.65 from 'conancenter' - Downloaded
    libdeflate/1.12 from 'conancenter' - Downloaded
    libfdk_aac/2.0.2 from 'conancenter' - Downloaded
    libffi/3.4.2 from 'conancenter' - Downloaded
    libiconv/1.17 from 'conancenter' - Downloaded
    libjpeg/9d from 'conancenter' - Downloaded
    libmp3lame/3.100 from 'conancenter' - Downloaded
    libpng/1.6.37 from 'conancenter' - Downloaded
    libsndfile/1.0.31 from 'conancenter' - Downloaded
    libtiff/4.3.0 from 'conancenter' - Downloaded
    libtool/2.4.7 from 'conancenter' - Downloaded
    libvpx/1.11.0 from 'conancenter' - Downloaded
    libwebp/1.2.2 from 'conancenter' - Downloaded
    libx264/20191217 from 'conancenter' - Downloaded
    libx265/3.4 from 'conancenter' - Downloaded
    libxml2/2.9.14 from 'conancenter' - Downloaded
    m4/1.4.19 from 'conancenter' - Downloaded
    ogg/1.3.5 from 'conancenter' - Downloaded
    opencv/4.5.5 from 'conancenter' - Downloaded
    openexr/2.5.7 from 'conancenter' - Downloaded
    openh264/2.1.1 from 'conancenter' - Downloaded
    openjpeg/2.5.0 from 'conancenter' - Downloaded
    openssl/1.1.1q from 'conancenter' - Downloaded
    opus/1.3.1 from 'conancenter' - Downloaded
    protobuf/3.17.1 from 'conancenter' - Downloaded
    pulseaudio/14.2 from 'conancenter' - Downloaded
    quirc/1.1 from 'conancenter' - Downloaded
    vaapi/system from 'conancenter' - Downloaded
    vdpau/system from 'conancenter' - Downloaded
    vorbis/1.3.7 from 'conancenter' - Downloaded
    vulkan-headers/1.3.221 from 'conancenter' - Downloaded
    vulkan-loader/1.3.221 from 'conancenter' - Downloaded
    wayland/1.20.0 from 'conancenter' - Downloaded
    xorg/system from 'conancenter' - Downloaded
    xz_utils/5.2.5 from 'conancenter' - Downloaded
    zlib/1.2.12 from 'conancenter' - Downloaded
    zstd/1.5.2 from 'conancenter' - Downloaded
Packages
    ade/0.1.1f:80853771cbd70078c00b0565eb87ca70bd209819 - Build
    autoconf/2.71:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    automake/1.16.5:258f6f05ca54813b3d7180161753df7f9ccf7e1d - Download
    brotli/1.0.9:9302099770d51de61a6d205d01df264f64273127 - Build
    bzip2/1.0.8:9389a4c2c70b5b37c341b3cae252e60bdd643714 - Build
    eigen/3.3.9:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    expat/2.4.8:c16fb3f117604b73aff908091046466b79625454 - Build
    ffmpeg/4.4:03dd33d0b3e346272ca8ca4faab79cc3025df374 - Build
    flac/1.3.3:bf6d88572cd41b57c635a46031d739f8b33cb242 - Build
    freetype/2.12.1:e82b8547b9ff4addec8332bb75a7ccb6630d94f8 - Build
    gtk/system:cc5e5ca8b619d2dffaaeae1e4924ae3ce085a8f1 - Download
    jasper/2.0.33:dae9cafa0f46f611458a2aa6219efcdb7bb3a292 - Build
    jbig/20160605:a1ae33866acf0a0c69048b397cd79358b1eae7a9 - Build
    libalsa/1.2.7.2:72e5bb76647ad766395c534018248eaf92982941 - Build
    libcap/2.65:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    libdeflate/1.12:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    libfdk_aac/2.0.2:80853771cbd70078c00b0565eb87ca70bd209819 - Build
    libffi/3.4.2:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    libiconv/1.17:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    libjpeg/9d:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    libmp3lame/3.100:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    libpng/1.6.37:5c5d6852650564c3cfcfe18ac100c9512beb186f - Build
    libsndfile/1.0.31:20258edd06a6944d4a1509b2baf58d7639555c3f - Build
    libtiff/4.3.0:37f137255c6731d9cc8fe7bca6e3c4c702771f57 - Build
    libtool/2.4.7:401539cdacc057ba19f9b23ff2b9248ad753eea8 - Build
    libvpx/1.11.0:80853771cbd70078c00b0565eb87ca70bd209819 - Build
    libwebp/1.2.2:80969d4ee97223e83334123a5be8eaa2f269ba6b - Build
    libx264/20191217:b1d3baeb65f17c921d0553077fe2d29bc84b4052 - Build
    libx265/3.4:bbcca98f652410248cd8108169aa77ca16559c28 - Build
    libxml2/2.9.14:0da3e8420b5f6a4bb43b965855158b2b617b4e6f - Build
    m4/1.4.19:ef8d7bb63b73bcc98204f8763adba33115db9de2 - Build
    ogg/1.3.5:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    opencv/4.5.5:191ef37bfb22e599ef2caaa1acc49e9af713dfdf - Build
    openexr/2.5.7:b39f27629f7d261962470aaf97a609fe52ba32f9 - Build
    openh264/2.1.1:80853771cbd70078c00b0565eb87ca70bd209819 - Build
    openjpeg/2.5.0:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    openssl/1.1.1q:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    opus/1.3.1:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    protobuf/3.17.1:c878c2ce7cefe4df973abe5e555d74eb9aa298bb - Build
    pulseaudio/14.2:ea0595e15ef49d8d88d7e7cd8db4a1b789cb1239 - Build
    quirc/1.1:b0467552525336c7f0f8d1313b1448c7b6c461f1 - Build
    vaapi/system:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    vdpau/system:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    vorbis/1.3.7:9aae92fd70d6a2b0e3c21794b82bb894d5eb6621 - Build
    vulkan-headers/1.3.221:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    vulkan-loader/1.3.221:869ac164fb0ff66fe2375249d2b4ac37151eef56 - Build
    wayland/1.20.0:8ac2a86a0dcb937bdff0e327d21570939f13e327 - Build
    xorg/system:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    xz_utils/5.2.5:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    zlib/1.2.12:d458f0ad17daab8c37a59b910c7b82677fd9d3c0 - Build
    zstd/1.5.2:46574eda610307ec2289e9f6de8ca5204b6665e0 - Build
Build requirements
    autoconf/2.71 from 'conancenter' - Cache
    automake/1.16.5 from 'conancenter' - Cache
    gettext/0.21 from 'conancenter' - Downloaded
    gnu-config/cci.20201022 from 'conancenter' - Cache
    gnu-config/cci.20210814 from 'conancenter' - Downloaded
    libtool/2.4.7 from 'conancenter' - Cache
    m4/1.4.19 from 'conancenter' - Cache
    meson/0.62.1 from 'conancenter' - Cache
    meson/0.63.2 from 'conancenter' - Downloaded
    ninja/1.11.0 from 'conancenter' - Cache
    pkgconf/1.7.4 from 'conancenter' - Cache
    yasm/1.3.0 from 'conancenter' - Downloaded
Build requirements packages
    autoconf/2.71:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    automake/1.16.5:258f6f05ca54813b3d7180161753df7f9ccf7e1d - Download
    gettext/0.21:9e218ebddc8d83198fb500a52db606b1af9b7afd - Build
    gnu-config/cci.20201022:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    gnu-config/cci.20210814:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    libtool/2.4.7:401539cdacc057ba19f9b23ff2b9248ad753eea8 - Build
    m4/1.4.19:ef8d7bb63b73bcc98204f8763adba33115db9de2 - Build
    meson/0.62.1:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    meson/0.63.2:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
    ninja/1.11.0:ef8d7bb63b73bcc98204f8763adba33115db9de2 - Build
    pkgconf/1.7.4:ef8d7bb63b73bcc98204f8763adba33115db9de2 - Build
    yasm/1.3.0:ef8d7bb63b73bcc98204f8763adba33115db9de2 - Build

Cross-build from 'Linux:x86_64' to 'Linux:armv7'
Installing (downloading, building) binaries...
eigen/3.3.9: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
eigen/3.3.9: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
eigen/3.3.9: Downloaded package revision 0
gnu-config/cci.20201022: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
gnu-config/cci.20201022: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
gnu-config/cci.20201022: Downloaded package revision 0
gnu-config/cci.20210814: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
gnu-config/cci.20210814: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
gnu-config/cci.20210814: Downloaded package revision 0
gtk/system: Retrieving package cc5e5ca8b619d2dffaaeae1e4924ae3ce085a8f1 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
gtk/system: Package installed cc5e5ca8b619d2dffaaeae1e4924ae3ce085a8f1
gtk/system: Downloaded package revision 0
vaapi/system: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
vaapi/system: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
vaapi/system: Downloaded package revision 0
vdpau/system: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
vdpau/system: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
vdpau/system: Downloaded package revision 0
vulkan-headers/1.3.221: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
vulkan-headers/1.3.221: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
vulkan-headers/1.3.221: Downloaded package revision 0
xorg/system: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
xorg/system: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
xorg/system: Downloaded package revision 0
autoconf/2.71: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
autoconf/2.71: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
autoconf/2.71: Downloaded package revision 0
meson/0.62.1: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
meson/0.62.1: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
meson/0.62.1: Downloaded package revision 0
meson/0.63.2: Retrieving package 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
meson/0.63.2: Package installed 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
meson/0.63.2: Downloaded package revision 0
automake/1.16.5: Retrieving package 258f6f05ca54813b3d7180161753df7f9ccf7e1d from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conaninfo.txt
Downloading conan_package.tgz
automake/1.16.5: Package installed 258f6f05ca54813b3d7180161753df7f9ccf7e1d
automake/1.16.5: Downloaded package revision 0
ade/0.1.1f: Configuring sources in /root/.conan/data/ade/0.1.1f/_/_/source/src
ade/0.1.1f: 
ade/0.1.1f: Copying sources to build folder
ade/0.1.1f: Building your package in /root/.conan/data/ade/0.1.1f/_/_/build/80853771cbd70078c00b0565eb87ca70bd209819
ade/0.1.1f: Generator txt created conanbuildinfo.txt
ade/0.1.1f: Calling generate()
ade/0.1.1f: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
ade/0.1.1f: Aggregating env generators
ade/0.1.1f: Calling build()
ade/0.1.1f: CMake command: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/root/.conan/data/ade/0.1.1f/_/_/build/80853771cbd70078c00b0565eb87ca70bd209819/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/root/.conan/data/ade/0.1.1f/_/_/package/80853771cbd70078c00b0565eb87ca70bd209819" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/root/.conan/data/ade/0.1.1f/_/_/build/80853771cbd70078c00b0565eb87ca70bd209819/src"
-- Using Conan toolchain: /root/.conan/data/ade/0.1.1f/_/_/build/80853771cbd70078c00b0565eb87ca70bd209819/build/generators/conan_toolchain.cmake
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
-- The C compiler identification is GNU 8.5.0
-- The CXX compiler identification is GNU 8.5.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/xcc/armv7-unknown-linux-gnueabi/bin/armv7-unknown-linux-gnueabi-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/xcc/armv7-unknown-linux-gnueabi/bin/armv7-unknown-linux-gnueabi-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /root/.conan/data/ade/0.1.1f/_/_/build/80853771cbd70078c00b0565eb87ca70bd209819/build/Release
ade/0.1.1f: CMake command: cmake --build "/root/.conan/data/ade/0.1.1f/_/_/build/80853771cbd70078c00b0565eb87ca70bd209819/build/Release" '--' '-j8'
[  5%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/alloc.cpp.o
[ 11%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/assert.cpp.o
[ 16%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/check_cycles.cpp.o
[ 27%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/edge.cpp.o
[ 27%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/graph.cpp.o
[ 33%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/execution_engine.cpp.o
[ 38%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/memory_descriptor.cpp.o
[ 44%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/memory_accessor.cpp.o
[ 50%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/memory_descriptor_ref.cpp.o
[ 55%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/memory_descriptor_view.cpp.o
[ 61%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/metadata.cpp.o
[ 66%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/metatypes.cpp.o
[ 72%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/node.cpp.o
[ 77%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/passes/communications.cpp.o
[ 83%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/search.cpp.o
[ 88%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/subgraphs.cpp.o
[ 94%] Building CXX object sources/ade/CMakeFiles/ade.dir/source/topological_sort.cpp.o
[100%] Linking CXX static library ../../lib/libade.a
[100%] Built target ade
ade/0.1.1f: Package '80853771cbd70078c00b0565eb87ca70bd209819' built
ade/0.1.1f: Build folder /root/.conan/data/ade/0.1.1f/_/_/build/80853771cbd70078c00b0565eb87ca70bd209819/build/Release
ade/0.1.1f: Generated conaninfo.txt
ade/0.1.1f: Generated conanbuildinfo.txt
ade/0.1.1f: Generating the package
ade/0.1.1f: Package folder /root/.conan/data/ade/0.1.1f/_/_/package/80853771cbd70078c00b0565eb87ca70bd209819
ade/0.1.1f: Calling package()
ade/0.1.1f: Copied 1 file: LICENSE
ade/0.1.1f: CMake command: cmake --install "/root/.conan/data/ade/0.1.1f/_/_/build/80853771cbd70078c00b0565eb87ca70bd209819/build/Release" --prefix "/root/.conan/data/ade/0.1.1f/_/_/package/80853771cbd70078c00b0565eb87ca70bd209819"
CMake Warning:
  Ignoring extra path from command line:

   "/root/.conan/data/ade/0.1.1f/_/_/package/80853771cbd70078c00b0565eb87ca70bd209819"


CMake Error: Unknown argument --prefix
CMake Error: Run 'cmake --help' for all supported options.
ERROR: ade/0.1.1f: Error in package() method, line 55
        cmake.install()
        ConanException: Error 1 while executing cmake --install "/root/.conan/data/ade/0.1.1f/_/_/build/80853771cbd70078c00b0565eb87ca70bd209819/build/Release" --prefix "/root/.conan/data/ade/0.1.1f/_/_/package/80853771cbd70078c00b0565eb87ca70bd209819"
Error response from daemon: The command '/bin/sh -c /bin/bash -c "source ./arm7/build-image.sh"' returned a non-zero code: 1
Failed to deploy '<unknown> Dockerfile: arm7/Dockerfile': Can't retrieve image ID from build stream
```
</details>
user: Ryslan342
issue_12180: state: open
title: [bug] CMakeDeps: `<name>_LIBRARIES` variable is not suitable for macros like `check_symbol_exists`
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: macOS Monterey
  * Compiler+version: AppleClang 14
  * Conan version: 1.52.0
  * Python version: 3.10.6
  * cmake version: 3.24.2

### Steps to reproduce (Include if Applicable)

CMakeLists.txt

```cmake
cmake_minimum_required(VERSION 3.15)
project(test_check_symbol_exists LANGUAGES C)

find_package(zstd REQUIRED)

include(CheckSymbolExists)
set(CMAKE_REQUIRED_INCLUDES_SAVE ${CMAKE_REQUIRED_INCLUDES})
set(CMAKE_REQUIRED_LIBRARIES_SAVE ${CMAKE_REQUIRED_LIBRARIES})
list(PREPEND CMAKE_REQUIRED_INCLUDES ${zstd_INCLUDE_DIRS})
list(PREPEND CMAKE_REQUIRED_LIBRARIES ${zstd_LIBRARIES})
check_symbol_exists(ZSTD_decompressStream "zstd.h" ZSTD_RECENT_ENOUGH)
set(CMAKE_REQUIRED_INCLUDES ${CMAKE_REQUIRED_INCLUDES_SAVE})
set(CMAKE_REQUIRED_LIBRARIES ${CMAKE_REQUIRED_LIBRARIES_SAVE})

if(ZSTD_RECENT_ENOUGH)
    message(STATUS "Test succeeded")
else()
    message(FATAL_ERROR "Test failed")
endif()
```

test succeeds with `cmake_find_package`:

```shell
mkdir build1 && cd build1
conan install zstd/1.5.2@ -g CMakeToolchain -g cmake_find_package -c tools.cmake.cmaketoolchain:find_package_prefer_config="OFF"
cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release
```

test fails with `CMakeDeps`:

```shell
mkdir build2 && cd build2
conan install zstd/1.5.2@ -g CMakeToolchain -g CMakeDeps
cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release
```

`CMAKE_REQUIRED_INCLUDES` works fine here, but not `CMAKE_REQUIRED_LIBRARIES`, because `zstd_LIBRARIES` is  set to zstd imported target instead of full paths of all libraries.
According to CMake documentation, `check_c_source_compiles` allows imported targets in `CMAKE_REQUIRED_LIBRARIES`, but they don't say anything for `check_symbol_exists`.

It's quite annoying for conan v2 migration of several CCI recipes.

### Logs (Executed commands with output) (Include/Attach if Applicable)

`CMakeError.log` of `CMakeDeps` test:

```
Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
Build flags: ;;;;-m64
Id flags:

The output was:
1
ld: library not found for -lSystem
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Determining if the ZSTD_decompressStream exist failed with the following output:
Change Dir: /Users/spaceim/Documents/Personnel/test_check_symbol/build2/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/make -f Makefile cmTC_ed876/fast && /Applications/Xcode.app/Contents/Developer/usr/bin/make  -f CMakeFiles/cmTC_ed876.dir/build.make CMakeFiles/cmTC_ed876.dir/build
Building C object CMakeFiles/cmTC_ed876.dir/CheckSymbolExists.c.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc  -I/Users/spaceim/.conan/data/zstd/1.5.2/_/_/package/258f9d253d0e975fcb3ab38da19bbea0bc9bf506/include -m64  -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -MD -MT CMakeFiles/cmTC_ed876.dir/CheckSymbolExists.c.o -MF CMakeFiles/cmTC_ed876.dir/CheckSymbolExists.c.o.d -o CMakeFiles/cmTC_ed876.dir/CheckSymbolExists.c.o -c /Users/spaceim/Documents/Personnel/test_check_symbol/build2/CMakeFiles/CMakeTmp/CheckSymbolExists.c
Linking C executable cmTC_ed876
/Applications/CMake.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/cmTC_ed876.dir/link.txt --verbose=1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -m64  -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -m64  CMakeFiles/cmTC_ed876.dir/CheckSymbolExists.c.o -o cmTC_ed876
Undefined symbols for architecture x86_64:
  "_ZSTD_decompressStream", referenced from:
      _main in CheckSymbolExists.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [cmTC_ed876] Error 1
make: *** [cmTC_ed876/fast] Error 2


File /Users/spaceim/Documents/Personnel/test_check_symbol/build2/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <zstd.h>

int main(int argc, char** argv)
{
  (void)argv;
#ifndef ZSTD_decompressStream
  return ((int*)(&ZSTD_decompressStream))[argc];
#else
  (void)argc;
  return 0;
#endif
}
```
user: SpaceIm
issue_12173: state: open
title: [question] Is it safe to use self.package_path? ? 
body: Related to https://github.com/conan-io/docs/issues/2753

The `self.package_path` is not documented but looks stable and it uses `Path` library, which is easier than `os.path` usage. 

/cc @jellespijker 

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: uilianries
issue_12170: state: open
title: [question] Why is progressing the conan version required in order to maintain gtest 1.10.0 dependency?
body: We have gtest 1.10.0 configured in a number of projects that use Conan to manage artifacts during compilation. We have found over the past few weeks that successive upgrades to the conan version breaks this dependency on gtest 1.10.0. We find this to be strange, seeing that the gtest 1.10.0 tag hasn't changed since October 2019.

The problem manifests with this error:

```
ERROR: gtest/1.10.0: Error in validate() method, line 95
	if [self.info.settings.get_safe("compiler.cppstd"):
	TypeError: 'NoneType' object is not callable
```

Previously, the solution has been to simply update the conan version, and the problem seems to go away. However, we are unclear as to why this should be the solution. 

We suspected that there may be an issue calculating the conan hash, and to experiment, we have recently (with the update to conan v1.51.0) inserted the specific settings.info "compiler.cppstd=11" to no avail. We have not been using this settings.info setting in the past, and have had no specific issues. Just to note that we saw an update in the repo for Conan 2.0 just yesterday that looks to handle this issue for that release... is this related? [Pull request 12885](https://github.com/conan-io/conan-center-index/pull/12885)

We are under the impression that if we froze the conan version, that the dependency on gtest 1.10.0 should not change. 

If someone could help advise us what we should be looking for to help prevent us from continually having to update our gtest version or conan version just to maintain this dependency. Or are we mistaken in thinking that successive versions of conan should not require constant update of older versions of gtest? 

Any insight would be helpful, thanks!

@KyleJosling @delrizzo 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: delrizzo
issue_12164: state: open
title: [bug] Settting CONAN_MAKE_PROGRAM breaks CMake build helper
body: ### Environment Details
  * Operating System+version: Windows 10
  * Compiler+version: Visual Studio 15
  * Conan version: 1.52.0
  * Python version: 3.8.10

### Steps to reproduce

Take any recipe that imports CMake from conans (say, base64/0.4.0 from conancenter) and do the following:

```
C:\>set CONAN_MAKE_PROGRAM=make.exe
C:\>conan install base64/0.4.0@ --build base64
...
base64/0.4.0: Calling build()
base64/0.4.0: Using 'make.exe' as CMAKE_MAKE_PROGRAM
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is MSVC 19.16.27045.0
-- The CXX compiler identification is MSVC 19.16.27045.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.23/Modules/CMakeTestCCompiler.cmake:69 (message):
  The C compiler

    "C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: D:/.conan/data/base64/0.4.0/_/_/build/6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7/build_subfolder/CMakeFiles/CMakeTmp

    Run Build Command(s):make.exe cmTC_b217f.vcxproj /p:Configuration=Debug /p:Platform=x64 /p:VisualStudioVersion=15.0 /v:m && make: Nothing to be done for 'cmTC_b217f.vcxproj'.
    make: *** No rule to make target '/p:Configuration=Debug'.  Stop.
```
Note that make.exe is used instead of msbuild. Why?

user: db4
issue_12162: state: open
title: [bug] conan user --password "-..." can't begin with "-"
body: Temporary passwords generated in the CI beginning with "-" cannot be used directly.

Workaround from #2502 :
```
CONAN_PASSWORD="-my_ci_pw" conan user -r conancenter "user" -p
```

I would expect that:
- This is fixed, or:
- Documentation would note about this, e.g. `conan user --help` would note this behavior and points to an alternative way

### Environment Details
  * Operating System+version: Linux version 5.4.0-1075-kvm (buildd@lcy02-amd64-082) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1))
  * Compiler+version: clang 14.0.6
  * Conan version: 1.52.0
  * Python version: 3.8.10

### Steps to reproduce
`conan user --remote conancenter --password "-my_ci_pw" user`

### Logs
```
ubuntu@gitlabrunner:~$ conan user --remote conancenter --password "-my_ci_pw" user
usage: conan user [-h] [-c] [-p [PASSWORD]] [-r REMOTE] [-j JSON] [-s] [name]
conan user: error: unrecognized arguments: -my_ci_pw
ERROR: Exiting with code: 2
```

user: jusito
issue_12161: state: open
title: [question] [buildinfo] How to get CI Server url in buildinfo.json
body: Hi conan community,

I'm in context of Gitlab CI Docker using conan official images to build and upload my conan packages to a corporate Artifactory.
I have read https://docs.conan.io/en/latest/howtos/generic_ci_artifactory.html#generating-build-info-from-lockfiles-information and this is my CI:

```

conan_build_info --v2 start $CI_JOB_NAME $CI_JOB_ID
conan lock create conanfile.py --user=unite --channel=testing --lockfile-out=conan.lock
conan create . myPackage/0.0.1@unite/testing --lockfile=conan.lock --lockfile-out=conan.lock
conan upload myPackage/0.0.1@unite/testing --confirm --parallel --all -r $ARTIFACTORY_REPOSITORY
conan_build_info --v2 create buildinfo.json --lockfile conan.lock --user $CONAN_LOGIN_USERNAME --password $CONAN_PASSWORD
conan_build_info --v2 publish buildinfo.json --url http://artifactory.mycorporate.com/artifactory --user $CONAN_LOGIN_USERNAME --password $CONAN_PASSWORD
conan_build_info --v2 stop
```

But the generated buildinfo.json doesn't contain CI Server url as documented in https://github.com/jfrog/build-info-go/blob/main/buildinfo-schema.json#L73 and consequently no CI Server url is set in Artifactory build page UI.

Does conan_build_info supports all fields of buildinfo.json schema?
Does conan_build_info yet maintained?
Do you have a better use to have metadata uploaded to Artifactory/XRay for SCA analysis?

Regards.
user: EstebanDugueperoux2
issue_12159: state: open
title: [bug]`AutotoolsBuildEnvironment`: libs of `build_requires` injected into `LIBS` if 1 profile
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Any
  * Compiler+version: Any
  * Conan version: 1.52.0
  * Python version: 3.10.6

### Steps to reproduce (Include if Applicable)

- On Linux or macOS, build an autotools based recipe (relying on `AutotoolsBuildEnvironment`) with `libtool` in `build_requires`, all shared, and 1 profile. For example `conan install libcurl/7.85.0@#63e97620160ac0273d500d743786e4dd -o *:shared=True -b libcurl`
- You should see that `libltdl` (lib packaged in `libtool`) is added to required loadable shared lib into `libcurl` shared lib (and also that it may fail during configure step of libcurl on macOS), even though `libltdl` is not a dependency of `libcurl`.

### Logs (Executed commands with output) (Include/Attach if Applicable)

Here a log on Linux (from https://github.com/conan-io/conan-center-index/issues/13050)

```
$HOME/.conan/data/libcurl/7.85.0/_/_/package/8e30aef01317ee7bcd761ed54212d56c98ca820b/lib/libcurl.so:
	linux-vdso.so.1 (0x00007ffc699aa000)
	libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f1e9166c000)
	libssl.so.1.1 => /home/rasmus/Projects/ds4-util/build/bin/libssl.so.1.1 (0x00007f1e915b0000)
	libcrypto.so.1.1 => /home/rasmus/Projects/ds4-util/build/bin/libcrypto.so.1.1 (0x00007f1e91251000)
	libz.so.1 => /home/rasmus/Projects/ds4-util/build/bin/libz.so.1 (0x00007f1e9122b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e91003000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1e90ffc000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1e90ff7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1e91753000)
```

I don't expect any fix in `AutotoolsBuildEnvironment` since it's fixed by 2 profiles or in new `AutotoolsToolchain`/`AutotoolsDeps`/`Autotools` helpers, it's just for reference since I've not found any issue here while it's a very common problem when you build an autotools based recipe with all shared.
Indeed, many conan-center recipes are still relying on `AutotoolsBuildEnvironment`, and many users still use 1 profile. Though, several conan-center recipes have workaround against this bug (like forcing autotools.libs = [], and hope for the best when configure tries to discover dependencies).
user: SpaceIm
issue_12155: state: open
title: [question] What is the equivalent of `conans.tools.MSBuild.build()` `upgrade_project` in `conan.tools.microsoft.MSBuid`?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

To build `xz_utils/5.2.5` with Visual Studio 2022 in https://github.com/conan-io/conan-center-index/pull/13038, vcxproj file must be updated with a different Platform Toolset, how to achieve that in conan v2?

(otherwise it fails with this kind of error since we try to build against a vs2017 solution:

```
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(460,5): error MSB8020: The build tools for Visual Studio 2017 (Platform Toolset = 'v141') cannot be found.
To build using the v141 build tools, please install Visual Studio 2017 build tools.
Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [C:\Users\spaceim\.conan\data\xz_utils\5.2.5\_\_\build\5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b\src\windows\vs2017\liblzma.vcxproj]
```
)
user: SpaceIm
issue_12154: state: open
title: [bug] `conan create -kb` doesn't inject `tools.microsoft.bash:subsystem` config from `tool_requires`
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: MinGW 9 / gcc 11.2
  * Conan version: 1.52.0
  * Python version: 3.10.2

### Steps to reproduce (Include if Applicable)

- checkout https://github.com/conan-io/conan-center-index/pull/13038/commits/4e40e8ad67eb2d53bbe43949d7201d08b9d8651e (from https://github.com/conan-io/conan-center-index/pull/13038).
- on a windows machine call: `conan create . xz_utils/5.2.5@ -pr mingw_profile` (it should fail due to https://github.com/conan-io/conan/issues/12153)
- edit conanfile to add this workaround for https://github.com/conan-io/conan/issues/12153: `autotools.install(args=[f"DESTDIR={unix_path(self, self.package_folder)}"])`
- now call `conan create . xz_utils/5.2.5@ -pr mingw_profile -kb`

Be sure to not have `tools.microsoft.bash:subsystem` or `tools.microsoft.bash:path` set globally or in profile (they should come from `msys2` recipe which is in `tool_requires` of `xz_utils` recipe).

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
ERROR: xz_utils/5.2.5: Error in package() method, line 149
        autotools.install(args=[f"DESTDIR={unix_path(self, self.package_folder)}"])
        ConanException: The config 'tools.microsoft.bash:subsystem' is needed to run commands in a Windows subsystem
```
user: SpaceIm
issue_12151: state: open
title: [feature] Conan v2: Fix import modules for checking recipe via mypy
body: Currently I cannot check my `conanfile.py` using `mypy` "out-of-the-box" due to the following errors:
```sh
$ mypy conanfile.py
conanfile.py:1: error: Skipping analyzing "conan": module is installed, but missing library stubs or py.typed marker
conanfile.py:1: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
conanfile.py:2: error: Skipping analyzing "conan.errors": module is installed, but missing library stubs or py.typed marker
Found 2 errors in 1 file (checked 1 source file)
```
Please add support for mypy in conan imported modules. Thanks for your attention.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: leha-bot
issue_12150: state: open
title: [bug] Conan incorrectly assumes os_name in runenv_from_cpp_info for transitive dependencies
body: ### Environment Details (include every applicable attribute)
  * Conan version: 1.52.0
  * Python version: 3.8 / 3.10

### Steps to reproduce (Include if Applicable)
The problem is that `LD_LIBRARY_PATH` is not populated for transitive dependencies if recipe doesn't have `os` setting when using *single profile*.

1. Tool recipe (NOTE: declares settings):
```python
from pathlib import Path

from conan import ConanFile


class ToolConanFile(ConanFile):
    name = "tool"
    version = "1.0"

    settings = "os", "arch"

    def package_info(self):
        self.cpp_info.bindirs = ["bin"]
        self.cpp_info.libdirs = ["lib"]

    def package(self):
        p = Path(self.package_folder)
        (p / "bin").mkdir() # Conan skips non-existing directories
        (p / "lib").mkdir()
```

2. Consumer recipe (NOTE: does not have any settings)
```python
from conan import ConanFile


class ConsumerConanFile(ConanFile):
    name = "pkgA"
    version = "1.0"

    tool_requires = "tool/1.0"

    generators = "VirtualBuildEnv"
```

3. Create tool package `conan create create ./pkg_tool/conanfile.py -pr default`
4. Try to consume without build profile: `conan install ./pkg_consumer/ -pr default`
5. Generated `conanbuildenv.sh` contains only `PATH` variable set.
6. Try to consume with build profile: `conan install ./pkg_consumer/ -pr:b default`
7. Generated `conanbuildenv.sh` contains both `PATH` and `LD_LIBRARY_PATH` / `DYLD_LIBRARY_PATH` variables.

I think this is happening becase Conan strips recipe's settings down to what it declares, and then `os_name = self._conanfile.settings.get_safe("os")` returns `None`.

Changing to `requires` and `VirtualRunEnv` leads to the same problem.
user: ytimenkov
issue_12143: state: open
title: [feature] add function "getHostCmakeVersion"
body: In many conan-center recipes, there is such line;
```
    def build_requirements(self):
        self.tool_requires("cmake/3.24.1")
```
The only reason for adding it is that CI has an older cmake version than a recipe requirement.
Many recipies consumers don't need this unnesessery dependency. It would be much better to have a conditional add here, i.e.:

```
    def build_requirements(self):
        if getHostCmakeVersion() < "x.x.x" # where x.x.x is a recipe min requirement
              self.tool_requires("cmake/3.24.1")
```

Alternative solution:
we can add a new field 'min_cmake_requirement' to conandata.yml and add corresponding cmake requirement in a background.


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: AndreyMlashkin
issue_12135: state: open
title: [bug] some conan tools (e.g. conan.tools.apple.is_apple_os) don't work correctly from `validate`/`validate_build`
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
Operating System+version: macOS 12.3
Compiler+version: Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Conan version: Conan version 1.51.3
Python version: Python 3.7.1


### Steps to reproduce (Include if Applicable)

run simple recipe doing:
```
def validate_build(self):
    from conan.errors import ConanInvalidConfiguration
    from conan.tools.apple import is_apple_os
    if is_apple_os(self):
        raise ConanInvalidConfiguration("xxx")
```

as a result, sometimes it may raise `ConanException` instead of returning True/False as [documented](https://docs.conan.io/en/1.51/reference/conanfile/tools/apple.html#is-apple-os) - it's not documented it can raise in any circumstances

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
	if is_apple_os(self):
	ConanException: 'self.settings' access in 'validate()' method is forbidden
```

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SSE4
issue_12132: state: open
title: [bug] Conanfile.py generated in an alias is not compatible with conan 2.0
body: When creating an alias, I noticed that the generated conanfile.py looks like this

```
from conans import ConanFile

class AliasConanfile(ConanFile):
    alias = "hello_world/1.0.0@star/cpp#8320d88c7d475c3bb7be9ba562313b36"
    revision_mode = "hash"
```

However, according to the [conan 2.0 migration guide](https://docs.conan.io/en/latest/migrating_to_2.0/recipes.html), it states that conanfiles should be using the new import `from conan import ConanFile` instead (conans => conan).  I believe this means that aliases generated in conan 1.x will not be compatible with conan2.x.

### Environment Details (include every applicable attribute)
  * Conan version: 1.51.3

user: stackfun
labels: component: ux: No changes to core business logic
issue_12130: state: open
title: [feature] Expose `conans.ConanFile.run()` args to user
body: - [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

`ConanFile.run()` contains several arguments that alter behavior (most notably `ignore_errors` for my use case). All of these are detailed on [conan.io](https://docs.conan.io/en/1.6/reference/conanfile/other.html)

AFAIK there is no way to leverage these values with a `CMake.build()` invocation. Unless there is some other usage that I am not considering, utilizing these values requires modifying Conan source code.

I request that these be exposed to the user somehow.
user: dstfvrt
issue_12125: state: open
title: [question] How to use export-pkg with --ignore-dirty and the new scm mode in Conan v2.0
body: With the new scm attribute (https://docs.conan.io/en/latest/migrating_to_2.0/recipes.html#the-scm-attribute), how do we export a package in our CONAN_USER_HOME which is created from a dirty git repository?
```bash
~/wp/conan-example-component$ conan export-pkg --force --ignore-dirty /home/xxx6xxx/wp/conan-example-component yyy/stable
Exporting package recipe
conan-example-component/0.5.0@yyy/stable: Calling export()
ERROR: conan-example-component/0.5.0@yyy/stable: Error in export() method, line 35
        scm_url, scm_commit = git.get_url_and_commit()
        ConanException: Repo is dirty, cannot capture url and commit: /home/xxx6xxx/wp/conan-example-component
```

While looking about the conan 1.52.0 code especially following lines https://github.com/conan-io/conan/blob/1.52.0/conan/tools/scm/git.py#L49-L57 we didn't see any way to replicate the old behavior. Is that wanted?
If yes, can you point us to some documentation (PR in conan or conan tribe - I saw nothing in the tribe documentation) about it ?

Conan version used 1.52.0

Thanks a lot! :)

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Bearwolves
issue_12116: state: open
title: [bug] build order is redundant if build and host profile are identical
body: I have the following issue: Assume the following dependency graph

A.requires(B)
A.requires(C)

C.build_requires(B)

that I want to build with dual profile (to prepare for conan 2,0) but with build and host profile being identical.

If I create a lockfile for that with the following command:
```
conan lock create -pr:b ./host_profile -pr:h ./host_profile ./A/conanfile.py --user=test --channel=test --build=B --build=C --lockfile-out=./lockfile.lock
```

And afterwards create the build_order:
```
conan lock build-order lockfile.lock --json=build_order.json
```
The build order will contain an entry for package ``B`` twice, once in the host context and once in the build context. This doesn't make sense, as the packages are actually the same, so I don't want to have them in the build order twice (because that means I'll have to build them twice). In combination with updating the lockfile after building an entry of the lockfile this even leads to errors.
E.g. when iterating over the build order and building every package considering the build/host context, while also updating the lockfile after every build like the following:

```
for level in build_order:
    for entry in level:
        ref = entry[0]
        name = ref.split("/")[0]
        context = entry[2]
        lock_id = entry[3]
        cmd = f"conan install {ref} --build={name} --lockfile={lockfile} --lockfile-node-id={lock_id} --lockfile-out={lockfile_out}"
        if context == "build":
            cmd += " --build-require"
        print(f"Executing cmd:\n{cmd}")
        if os.system(cmd) != 0:
            print("Failed")
            exit(-1)
        
        os.system(f"conan lock update {lockfile} {lockfile_out}")
```

This will fail because once package ``B``  was built the first time (either in host or in build context), the update of the lockfile will mark it as ``locked`` and then, when reaching the second entry of ``B`` it gives the error:

```
ERROR: Cannot build 'B/1.0.0@test/test' because it is already locked in the input lockfile
```

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version: gcc 8.4
  * Conan version: Conan version 1.51.0
  * Python version: 3.8

### Steps to reproduce (Include if Applicable)

See [minimal example](https://github.com/frank-schmidtner/conan_minimal_example2/tree/package_in_built_context_already_locked_in_lockfile)

### Logs (Executed commands with output) (Include/Attach if Applicable)

user: frank-schmidtner
issue_12114: state: open
title: [feature] Publish buildinfo in a project specific artifactory repo
body: Provide an option to the conan_build_info --v2 publish subcommand to be able to specify an artifactory project with a dedicated buildinfo repository where the buildinfo should be stored.

Currently one can only perform this with the jfrog CLI build upload command (see https://www.jfrog.com/confluence/display/JFROG/Artifactory+REST+API#ArtifactoryRESTAPI-BuildUpload) but this requires an additional tool in the CI pipeline (including setup and authentication) though the principal functionality is already contained in the conan_build_info tool (see also https://github.com/czoido/conan-build-info-example/issues/1).

- [*] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: fg68
issue_12106: state: open
title: [bug] conan.tools.AutotoolsDeps: linker error due to `-F -Wl,-rpath -Wl,<libdirs>` on macOS when there are dependencies
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: macOS Monterey
  * Compiler+version: AppleClang 13.1.6
  * Conan version: 1.52.0
  * Python version: 3.10.6

### Steps to reproduce (Include if Applicable)

- create an autotools recipe with dependencies, relying on AutotoolsToolchain, AutotoolsDeps & Autotools
- run conan create

(I have a CCI branch for capnproto reproducing this issue, it's the first autotools recipe migrating to conan v2 and allowing a build on macOS, I'll submit a PR in CCI and provide the link)


### Logs (Executed commands with output) (Include/Attach if Applicable)

```
libtool: link: g++ -std=gnu++14 -dynamiclib  -o .libs/libkj-0.10.1.dylib  src/kj/.libs/common.o src/kj/.libs/units.o src/kj/.libs/memory.o src/kj/.libs/refcount.o src/kj/.libs/array.o src/kj/.libs/list.o src/kj/.libs/string.o src/kj/.libs/string-tree.o src/kj/.libs/source-location.o src/kj/.libs/hash.o src/kj/.libs/table.o src/kj/.libs/encoding.o src/kj/.libs/exception.o src/kj/.libs/debug.o src/kj/.libs/arena.o src/kj/.libs/io.o src/kj/.libs/mutex.o src/kj/.libs/thread.o src/kj/.libs/time.o src/kj/.libs/filesystem.o src/kj/.libs/filesystem-disk-unix.o src/kj/.libs/filesystem-disk-win32.o src/kj/.libs/test-helpers.o src/kj/.libs/main.o src/kj/parse/.libs/char.o   -L/Users/spaceim/.conan/data/zlib/1.2.12/_/_/package/bda713dd3b257827c8d11a06ac9d824038871572/lib -L/Users/spaceim/.conan/data/openssl/1.1.1q/_/_/package/bda713dd3b257827c8d11a06ac9d824038871572/lib -lz -lssl -lcrypto  -stdlib=libc++ -m64 -O3 -m64 -Wl,-rpath -Wl,@loader_path/../lib -F -Wl,-rpath -Wl,/Users/spaceim/.conan/data/zlib/1.2.12/_/_/package/bda713dd3b257827c8d11a06ac9d824038871572/lib -Wl,-rpath -Wl,/Users/spaceim/.conan/data/openssl/1.1.1q/_/_/package/bda713dd3b257827c8d11a06ac9d824038871572/lib   -install_name  //lib/libkj-0.10.1.dylib  -Wl,-single_module
ld: warning: directory not found for option '-F-Wl,-rpath'
ld: warning: double slash removed from -install_name (//lib/libkj-0.10.1.dylib)
ld: can't map file, errno=22 file '/Users/spaceim/.conan/data/zlib/1.2.12/_/_/package/bda713dd3b257827c8d11a06ac9d824038871572/lib' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libkj.la] Error 1
```

In this example with capnproto, dependencies are openssl & zlib:

It's worth noting that `zlib` recipe defines a layout, so it shouldn't propagate frameworkdirs (according to discussions in https://github.com/conan-io/conan/issues/11867?). But maybe it comes indirectly from the fact that openssl recipe doesn't define yet a layout and zlib is also one of its dependencies?
user: SpaceIm
issue_12105: state: open
title: [feature] fastbuild support
body: Support fastbuild .bff generation for integration with fastbuild build system. https://www.fastbuild.org/docs/home.html

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: eclazi
issue_12102: state: open
title: [bug] When using MSBuild the build-process outputs an error after starting the powershell! 
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 2019 (Visula Studio 17 2022)
  * Compiler+version: MSBuild version 17.3.1+2badb37d1 for .NET Framework
  * Conan version: 1.52.0
  * Python version: 3.10.6

### Steps to reproduce (Include if Applicable)
define a build() method as:

```
def build(self): 
  msbuild = MSBuild(self) 
  msbuild.build("./MySolution.sln")
```

### Logs (Executed commands with output) (Include/Attach if Applicable)

![image](https://user-images.githubusercontent.com/98085987/189964219-84f1a39c-8d98-4907-9afb-61603047e770.png)

### conan-profile

```
[settings]
    os=Windows
    os_build=Windows
    arch=x86_64
    arch_build=x86_64
    compiler=Visual Studio
    compiler.version=17
    build_type=Release
[options]
[conf]
[build_requires]
[env]
```

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: luistorrescisneros
issue_12100: state: open
title: [question] Overriding requirements for packaging pre-built binaries
body: I want to package library that was built with specific set of options/requirements. I'm trying to use `conan export-pkg` for this. I can pass options easily through profile. But I don't see API for overriding requirements in export-pkg. So I'm getting error if I specify transitive dependencies in recipe: `ConanException: mylibrary/1.0.0.0@user/channel package_info(): Package require 'bzip2' not used in components requires`. If I don't specify dependencies - wrong version of dependency is being used. Is there a way to somehow inject these dependencies? The only current workaround that I can think of is creating some fake component that will depend on transitive requirements just so that I don't get this error.
user: Nekto89
issue_12096: state: open
title: [question] Run only unit tests while developing
body: My question is related to #11898, but mine focuses on developer usage rather than CI.  As a developer, I would like to run only the unit tests during my code/test/debug/refactor development cycle.  But when I'm ready to create a package for testing with other packages, I would like to run all of the tests.  

One way to accomplish this would be to add a `develop` boolean option to my recipe that appropriately filters the tests to run, and do `conan install` with `-o develop=True` to set up my development environment.  When I want to create a package for testing, I would run `conan create`, and it would run all the tests because the `develop` option would be `False` in that case.  Any suggestions on how to make such a usage model work without me having to remember to add `-o develop=True` when I run `conan install`?  In other words, how can I have `develop` default to `True` for `conan install` and `False` for `conan create`?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: blackk-foxx
issue_12093: state: open
title: [question] Best way to validate checksums 
body: Hi everyone! 
I'm opening a new issue about this argument because I need to understand which is the best way to validate checksums through Conan.
I have to follow this pipeline:
1. I receive pre built ".a" and ".h" files which I have to package in order to be uploaded, subsequently, on Artifactory.
2. I need to calculate checksums on each ".a" and ".h" file, in a pre-upload phase, and keep their value since they will be further rechecked in the download phase.
3. Once in Artifactory, the checksums are automatically calculated on the ".tgz", not on each file, so I can't use that value because it won't match directly with the checksum I calculated before.
4. When I decide to download the package I need to check if checksums are still the same of the above point 2.

If everything goes right, then OK, if (at any time) checksum get corrupted ---> abort the operation and report the error.

Which is the best way to do this? I don't know if it's better to use hooks, the `conan install [stuff] --verify` command or something else which I'm totally missing.

I'm currently using Conan version 1.52.0. 
Thank everyone in advance!  

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: valeriomoroni95
issue_12092: state: open
title: Failed requirement 'icu/65.1@qtproject/stable' from 'conanfile.py (qtwebkit/5.212.0-alpha4)'
body: Issue :
1.We have tried to install the conan with the command "pip install conan".
2.Now we are blocked at issue 
conanfile.py (qtwebkit/5.212.0-alpha4): WARN: Cannot use matching dependencies for 6.2.0. Runtime errors caused by libraries bundled with Qt may happen. Use Qt >= 5.12.6 to be on a safe side
icu/65.1@qtproject/stable: Not found in local cache, looking in remotes...
icu/65.1@qtproject/stable: Trying with 'qtproject'...
**ERROR: Failed requirement 'icu/65.1@qtproject/stable' from 'conanfile.py (qtwebkit/5.212.0-alpha4)'
ERROR: Permission denied for user: 'None'. [Remote: qtproject]**
Exit code: 1

3.We have explored but couldnt get any clue to proceed further.
ENVIRONMENT used : 
WINDOWS 10, python 3.10.7, and our actual task is as mentioned in the link : https://github.com/qtwebkit/qtwebkit/wiki/Building-QtWebKit-on-Windows

Please consider our query as priority and your support will be more helpful.
Thankyou.
user: PavaniSivangula
issue_12091: state: open
title: [question] Compatible packages for options of dependencies
body: I'm currently trying to use full_package_mode. Is it possible to somehow state that I don't care about some options of consumed library?
For example, my library depends on Boost, but it doesn't use Boost::python at all. So values of "without_python", "python_executable", "python_version", "python_buildid" shouldn't affect binary compatibility.

I've tried using "del" in package_id but it doesn't work because RequirementInfo already contains just hash. Is there a way to achieve this properly?
"del self.info.requires["boost"].options.without_python
del self.info.requires["boost"].options.python_version"

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Nekto89
issue_12090: state: open
title: Setting values in settings.yml and in default profile related to compiler version.
body: Hello Team,

I am using old version of compiler (gcc, ver: 3.4) for my project, so to use conan, we had to update default profile and settings.yaml file with version number of old compiler.

default profile:
[settings]
os=Windows
os_build=Windows
arch=x86
arch_build=x86
compiler=gcc
compiler.version=3.4
compiler.libcxx=libstdc++
build_type=Release
[options]
[build_requires]
[env]


settings.yaml value in compiler section: added 3.4 as version number in compiler version

**issue:** we want to update these file automatically with desired value with the help of CLI commands or by any other method so that it can be easily integrated in DevOps pipeline without manual intervention.

Thanks & Regards,
Himanshu 
user: himansu2906
issue_12088: state: open
title: Fix incorrect path for CMake components with identical framework names
body: Changelog: Bugfix: Incorrect path found for different components with the same framework names.
Docs: omit
Closes: https://github.com/conan-io/conan/issues/10140

This PR is for issue [#10140](https://github.com/conan-io/conan/issues/10140) – a detailed description of the problem (and the solution) can be found there.

Short summary: If multiple components in a recipe have `self.cpp_info.components[component].frameworks` defined as an identical value, Conan's `cmake_find_package` generator will incorrectly return the path to the **first** found component for **all** of them because the value is cached, even if each component points to a different path.

**NOTE**: This change is in line with many other Conan *macros* which properly clear a value before using it.

- [x] Refer to the issue that supports this Pull Request: [#10140](https://github.com/conan-io/conan/issues/10140)
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 
user: T1T4N
issue_12076: state: open
title: [bug] Cannot install boost in Windows 10. ImportError: cannot import name 'is_apple_os' from 'conan.tools.apple'
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Windows 10+21H2:
  * MSVC+16.0:
  * Conan: 1.51.3
  * Python version: 3.10.7

### Steps to reproduce (Include if Applicable)

Try to install boost

### Logs (Executed commands with output) (Include/Attach if Applicable)

ERROR: boost/1.71.0: Cannot load recipe.
Error loading conanfile at 'C:\Users\MRV\.conan\data\boost\1.71.0\_\_\export\conanfile.py': Unable to load conanfile in C:\Users\MRV\.conan\data\boost\1.71.0\_\_\export\conanfile.py
  File "C:\Users\MRV\AppData\Local\Programs\Python\Python310\lib\imp.py", line 172, in load_source
    module = _load(spec)
  File "<frozen importlib._bootstrap>", line 719, in _load
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "C:\Users\MRV\.conan\data\boost\1.71.0\_\_\export\conanfile.py", line 1, in <module>
    from conan.tools.apple import is_apple_os
ImportError: cannot import name 'is_apple_os' from 'conan.tools.apple' (C:\Users\MRV\AppData\Local\Programs\Python\Python310\lib\site-packages\conan\tools\apple\__init__.py)

user: sabudilovskiy
issue_12057: state: open
title: [question] Is it possible to configure export-pkg command to do nothing if the package already exists in the conan cache?
body: Is it possible to configure export-pkg command to do nothing if the package already exists in the conan cache?

I use conan as a package manager.
I encounter an issue when I run the following commands.
1. conan install comp_x/1.0.0@demo/testing (work fine, brings existing package from Artifactory)

2. conan export-pkg comp_x/1.0.0@demo/testing gives folloving message
Exporting package recipe
comp_x/1.0.0@demo/testing: A new conanfile.py version was exported
comp_x/1.0.0@demo/testing: Folder: D:\.conan\data\comp_x\1.0.0\demo\testing\export
comp_x/1.0.0@demo/testing: Exported revision: f82ffb837f686230945dcbea874676c0
comp_x/1.0.0@demo/testing: Forced build from source
Packaging to 456f15897172eef340fcbac8a70811f2beb26a93
ERROR: Package already exists. Please use --force, -f to overwrite it

Here, I would like the tool to not export and not force build anything. If the package already exists then leave it untouched.

3.  conan install comp_x/1.0.0@demo/testing (same as 1) is now generating an error:
comp_x/1.0.0@demo/testing: WARN: The package comp_x/1.0.0@demo/testing:456f15897172eef340fcbac8a70811f2beb26a93 doesn't belong to the installed recipe revision, removing folder
.......
ERROR: Missing binary: comp_x/1.0.0@demo/testing:456f15897172eef340fcbac8a70811f2beb26a93
......
ERROR: Missing prebuilt package for 'comp_x/1.0.0@demo/testing'

Any suggestions?
Thank you!

user: cristyrye
issue_12040: state: open
title: [question] What's the difference between using generators cmake and CMakeDeps, CMakeToolchain?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Tumb1eweed
issue_12036: state: open
title: [question] export-pkg fails with "TypeError: expected str, bytes or os.PathLike object, not NoneType" when calling CMake(self) in package() 
body: I am trying to figure out how to use `CMakeDeps` for a package that uses package config files created by CMake, and to update some recipes for Conan 2.0. I am able to run the `install`, `source`, `build`, `package` commands on a simple example project (attached) and they seem to produce a reasonable package. 
But when I run `export-pkg` I get an error:
> cmakeinstall/1.0.0: Calling package()
> ERROR: cmakeinstall/1.0.0: Error in package() method, line 36
>         cmake = CMake(self)
>         TypeError: expected str, bytes or os.PathLike object, not NoneType

The  relevant pieces of code look like this:
```python
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMake

class CmakeinstallConan(ConanFile):
    def package(self):
        cmake = CMake(self)
        cmake.install()
```

When using `conans.ConanFile` and `conans.CMake` the identically looking `package()` does not have this problem

Conan version 1.52.0
Python 3.9.1
cmake version 3.21.1

[PackageWithCMakeInstall.zip](https://github.com/conan-io/conan/files/9492269/PackageWithCMakeInstall.zip)
user: a-kryuk
issue_12024: state: open
title: [feature] conditional config remote installation
body: Our Artifactory server has basically two conan repo's, which are mirrored from each other. The only difference is that one repository contains pre-build binaries as well. This setup ensures that we can still service our community developers, with setting up a development environment while allowing our own in-house developers and CI/CT to utilize the power of pre-build binaries.

In order to not host multiple configurations both remotes are added to the `remotes.txt` https://github.com/Ultimaker/conan-config/blob/master/remotes.txt

And our instructions explicitly state that community developers should remove the `in-house` repo from their list, because that requires authentication: https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source#1-configure-conan

Conan will fail if that authentication fails, during a install or search command.

Possible solutions are:

- to use conditional (jinja2) logic to (not) add one of these remotes
- allow conan to continue even if one of the remote authentications fails, maybe use an optional configuration setting or environmental variable, to not break old behaviour?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: jellespijker
issue_12022: state: open
title: [feature] Force check credentials before search
body: #3906

I noticed that there are some conan package registry that return empty array with code 200 rather than return code 401 while searching packages without a valid credential. (at least including Artifactory and GitLab)

So I request to add an argument for `conan search` command to explicitly check credentials before search.
user: PMExtra
issue_12020: state: open
title: [question] Is it intended to not set `libexecdir` in `AutotoolsToolchain`?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

`libexecdir` is not automatically set by `AutotoolsToolchain`.

AutoToolsBuildEnvironment:
`bindir`, `sbindir`, `libexecdir`, `libdir`, `includedir`, `oldincludedir`, `datarootdir`

AutotoolsToolchain:
`bindir`, `sbindir`, `libdir`, `includedir`, `oldincludedir`, `datarootdir`

I had to manually inject `libexecdir` in https://github.com/conan-io/conan-center-index/pull/12806 (conan v2 migration of `pulseaudio` recipe) to satisfy CCI hook.
user: SpaceIm
issue_12014: state: open
title: [bug] clang-cl requires only_diff=False in vcvars
body: I'm trying to build package that depends on hiredis/1.0.2 with clang-cl conan profile. 
Build fails and only known to me way to fix it is to manyally modify all recipes from conan-center-index (that i use as dependencies) with `tools.vcvars(self.settings, only_diff=False):` . Bug related to https://github.com/conan-io/conan/issues/6577

My conan profile:

```
toolchain_arch=x86_64

[settings]
# Tested in Windows 10
os=Windows
os_target=Windows
os_build=Windows
arch_build=$toolchain_arch
arch=$toolchain_arch
compiler=clang
compiler.version=14
build_type=Debug
[options]
[tool_requires]
cmake/[>=3.23]
ninja/[>=1.11]
ccache/[>=4.6]
[buildenv]
CC=clang-cl.exe
CXX=clang-cl.exe
[build_requires]
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
tools.env.virtualenv:auto_use=True
tools.files.download:retry=3
tools.files.download:retry_wait=5
tools.system.package_manager:tool="choco"
[env]
CONAN_CMAKE_GENERATOR=Ninja
CONAN_REVISIONS_ENABLED=1
CONAN_VERBOSE_TRACEBACK=1
CONAN_PRINT_RUN_COMMANDS=1
CONAN_LOGGING_LEVEL=10
CONAN_USE_ALWAYS_SHORT_PATHS=1
CC=clang-cl.exe
CXX=clang-cl.exe
```

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: clang-cl.exe
clang version 14.0.6
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
  * Conan version: Conan version 1.51.3
  * Python version: Python 3.10.5

### Steps to reproduce (Include if Applicable)

Build anything with clang-cl profile

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
----Running------
> "C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\build\0974a5b97849875d7301803ccabc46a5c139aab2\conanbuild.bat" && cd C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\build\0974a5b97849875d7301803ccabc46a5c139aab2\build_subfolder && cmake -G "Ninja" -DCONAN_LINK_RUNTIME="/MTd" -DCMAKE_BUILD_TYPE="Debug" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="clang" -DCONAN_COMPILER_VERSION="14" -DCONAN_CXX_FLAGS="-m64" -DCONAN_SHARED_LINKER_FLAGS="-m64" -DCONAN_C_FLAGS="-m64" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\package\0974a5b97849875d7301803ccabc46a5c139aab2" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCMAKE_MODULE_PATH="C:/Users/den00/.conan/data/hiredis/1.0.2/_/_/build/0974a5b97849875d7301803ccabc46a5c139aab2" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -DENABLE_SSL="False" -DDISABLE_TESTS="True" -DENABLE_EXAMPLES="False" -Wno-dev C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\build\0974a5b97849875d7301803ccabc46a5c139aab2
-----------------
Capturing current environment in C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\build\0974a5b97849875d7301803ccabc46a5c139aab2\deactivate_conanbuildenv-debug-x86_64.bat
Configuring environment variables
-- The C compiler identification is Clang 12.0.0 with MSVC-like command-line
-- The CXX compiler identification is Clang 12.0.0 with MSVC-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan: Compiler Clang>=8, checking major version 14
-- Conan: Checking correct version: 12
  Detected a mismatch for the compiler version between your conan profile
  settings and CMake:

  Compiler version specified in your conan profile: 14

  Compiler version detected in CMake: 12.0

  Please check your conan profile settings (conan profile show
  [default|your_profile_name])

  P.S.  You may set CONAN_DISABLE_CHECK_COMPILER CMake variable in order to
  disable this check.
Call Stack (most recent call first):
  conanbuildinfo.cmake:501 (conan_error_compiler_version)
  conanbuildinfo.cmake:593 (check_compiler_version)
  conanbuildinfo.cmake:141 (conan_check_compiler)
  CMakeLists.txt:5 (conan_basic_setup)


-- Configuring incomplete, errors occurred!
See also "C:/Users/den00/.conan/data/hiredis/1.0.2/_/_/build/0974a5b97849875d7301803ccabc46a5c139aab2/build_subfolder/CMakeFiles/CMakeOutput.log".
hiredis/1.0.2:
hiredis/1.0.2: ERROR: Package '0974a5b97849875d7301803ccabc46a5c139aab2' build failed
hiredis/1.0.2: WARN: Build folder C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\build\0974a5b97849875d7301803ccabc46a5c139aab2
Level 5:process_lock.py[145]: Acquired file lock `b'C:\\Users\\den00\\.conan\\data\\hiredis\\1.0.2\\_\\_.count.lock'` after waiting 0.000s [1 attempts were required] [2022-09-02 14:38:12,588]
Level 5:process_lock.py[183]: Unlocked and closed file lock open on `b'C:\\Users\\den00\\.conan\\data\\hiredis\\1.0.2\\_\\_.count.lock'` [2022-09-02 14:38:12,589]
Level 5:process_lock.py[183]: Unlocked and closed file lock open on `b'C:\\Users\\den00\\.conan\\data\\hiredis\\1.0.2\\_\\_\\locks\\0974a5b97849875d7301803ccabc46a5c139aab2'` [2022-09-02 14:38:12,589]
ERROR: Traceback (most recent call last):
  File "C:\Python310\lib\site-packages\conans\errors.py", line 34, in conanfile_exception_formatter
    yield
  File "C:\Python310\lib\site-packages\conans\client\conanfile\build.py", line 16, in run_build_method
    conanfile.build()
  File "C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\export\conanfile.py", line 64, in build
    cmake = self._configure_cmake()
  File "C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\export\conanfile.py", line 74, in _configure_cmake
    self._cmake.configure(build_folder=self._build_subfolder)
  File "C:\Python310\lib\site-packages\conans\client\build\cmake.py", line 287, in configure
    self._run(command)
  File "C:\Python310\lib\site-packages\conans\client\build\cmake.py", line 247, in _run
    self._conanfile.run(command)
  File "C:\Python310\lib\site-packages\conans\model\conan_file.py", line 443, in run
    raise ConanException("Error %d while executing %s" % (retcode, command))
conans.errors.ConanException: Error 1 while executing cd C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\build\0974a5b97849875d7301803ccabc46a5c139aab2\build_subfolder && cmake -G "Ninja" -DCONAN_LINK_RUNTIME="/MTd" -DCMAKE_BUILD_TYPE="Debug" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="clang" -DCONAN_COMPILER_VERSION="14" -DCONAN_CXX_FLAGS="-m64" -DCONAN_SHARED_LINKER_FLAGS="-m64" -DCONAN_C_FLAGS="-m64" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\package\0974a5b97849875d7301803ccabc46a5c139aab2" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCMAKE_MODULE_PATH="C:/Users/den00/.conan/data/hiredis/1.0.2/_/_/build/0974a5b97849875d7301803ccabc46a5c139aab2" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -DENABLE_SSL="False" -DDISABLE_TESTS="True" -DENABLE_EXAMPLES="False" -Wno-dev C:\Users\den00\.conan\data\hiredis\1.0.2\_\_\build\0974a5b97849875d7301803ccabc46a5c139aab2

Elapsed time: 25 s. (time), 25.483 s. (clock)
CMake Error at C:/Users/den00/conan_github_downloader/conan_github_downloader.cmake:339 (message):
  (conan_install_target)

        Bad exit status 1
Call Stack (most recent call first):
  C:/Users/den00/conan_github_downloader/conan_github_downloader.cmake:385 (conan_install_target)
  get_conan_dependencies.cmake:14 (conan_build_target_if)
  C:/Users/den00/conan_github_downloader/conan_github_downloader.cmake:488 (include)
```
user: blockspacer
issue_12013: state: open
title: [bug] ( clang-cl ) stop updating conan-center-index recipes to conan v2 before landing clang-cl support
body: ```
I suppose that conan v2 does not support clang-cl properly, so it is not safe to migrate to conan v2. (Maybe it is good idea to revert all recipes to conan v1 commits?)

I compiled without errors version before commit https://github.com/conan-io/conan-center-index/pull/12311/files

If i need to modify conan profile to add conan v2 support - please tell me. I attempted to set toolchain etc. inside conan profile, but got errors.
```

from https://github.com/conan-io/conan-center-index/issues/12760
user: blockspacer
issue_12012: state: open
title: [bug] check_c_source_compiles for openssl is not working with CMakeToolChain and Visual Studio generator
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 11
  * Compiler+version: Visual Studio 2019
  * Conan version: 1.51.3
  * Python version: 3.10.3

### Steps to reproduce (Include if Applicable)
- in the conanfile:
  - use CMakeToolChain to build the package
  - require openssl `self.requires("openssl/1.1.1q")`
- in the cmakefile of the project:
  -  link with openssl like `LINK_LIBRARIES(OpenSSL::SSL OpenSSL::Crypto)`
  - use check_c_source_compiles like
```
CHECK_C_SOURCE_COMPILES("#include <openssl/opensslv.h>
			#ifndef OPENSSL_VERSION_NUMBER
			#error No OPENSSL_VERSION_NUMBER defined
			#endif
			#if OPENSSL_VERSION_NUMBER < 0x10100000L
			#error This is not OpenSSL 1.1 or higher
			#endif
			int main(void) { return 0; }" PODOFO_HAVE_OPENSSL_1_1)
```

=> you get the following error:
```
C:/J/w/prod/BuildSingleReference/.conan/data/podofo/0.9.7/_/_/build/f8220457d46bfa1f3246ae8e28788767027bcd82/build/CMakeFiles/CMakeTmp/CMakeLists.txt:20 (add_executable):
  Target "cmTC_491e9" links to target
  "CONAN_LIB::openssl_OpenSSL_SSL_libssl_RELEASE" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?
```

Note: the error does not appear if you use another generator like Ninja.

This error was found when working on this pull request: https://github.com/conan-io/conan-center-index/pull/12615
user: fdgStilla
issue_12004: state: open
title: [bug] pylint no-member warning for `tool_requires` and `test_requires`
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 22.04
  * Compiler+version: gcc-11.2
  * Conan version: 1.52.0
  * Python version: 3.10.4

### Steps to reproduce (Include if Applicable)

Within the `conanfile.py` I use:

```python
def build_requirements(self):
        self.test_requires("gtest/1.12.1")
```

Running pylint with the conan plugin results in:

```shell
E1101: Instance of '...' has no 'test_requires' member (no-member)
```

As quick fix, I suppress the warning using `# pylint: disable=no-member`

References:

* pylint no-member warning: https://pylint.pycqa.org/en/latest/user_guide/messages/error/no-member.html

user: hofbi
issue_12000: state: open
title: [bug] [1.52] conan error "ImportError: cannot import name '_get_component_name' from 'conan.tools.gnu.pkgconfigdeps'"
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: ubuntu 20.04
  * Compiler+version: none
  * Conan version: 1.52
  * Python version: 3.8

### Steps to reproduce (Include if Applicable)

```bash
pip3 install conan==1.52
conan --version
```


### Logs (Executed commands with output) (Include/Attach if Applicable)

```bash
conan --version
Traceback (most recent call last):
  File "/home/dash/.local/bin/conan", line 7, in <module>
    from conans.conan import run
  File "/home/dash/.local/lib/python3.8/site-packages/conans/conan.py", line 7, in <module>
    from conans.client.command import main
  File "/home/dash/.local/lib/python3.8/site-packages/conans/client/command.py", line 14, in <module>
    from conans.client.conan_api import Conan, default_manifest_folder, _make_abs_path, ProfileData
  File "/home/dash/.local/lib/python3.8/site-packages/conans/client/conan_api.py", line 13, in <module>
    from conans.client.cmd.create import create
  File "/home/dash/.local/lib/python3.8/site-packages/conans/client/cmd/create.py", line 3, in <module>
    from conans.client.cmd.test import install_build_and_test
  File "/home/dash/.local/lib/python3.8/site-packages/conans/client/cmd/test.py", line 6, in <module>
    from conans.client.manager import deps_install
  File "/home/dash/.local/lib/python3.8/site-packages/conans/client/manager.py", line 7, in <module>
    from conans.client.installer import BinaryInstaller, call_system_requirements
  File "/home/dash/.local/lib/python3.8/site-packages/conans/client/installer.py", line 11, in <module>
    from conans.client.generators import TXTGenerator, write_toolchain
  File "/home/dash/.local/lib/python3.8/site-packages/conans/client/generators/__init__.py", line 23, in <module>
    from .markdown import MarkdownGenerator
  File "/home/dash/.local/lib/python3.8/site-packages/conans/client/generators/markdown.py", line 12, in <module>
    from conan.tools.gnu.pkgconfigdeps import (
ImportError: cannot import name '_get_component_name' from 'conan.tools.gnu.pkgconfigdeps' (/home/dash/.local/lib/python3.8/site-packages/conan/tools/gnu/pkgconfigdeps/__init__.py)
```
user: zhoupeng6d
issue_11988: state: open
title: [bug] environment shell script executed in a windows subsystem don't use the `subsystem_path`
body: Came across this while trying to modernize the msys2 recipe See reproduction steps) and issue #11980 and #11986 

Environment shell scripts executed in the bash of the msys2 recipe contain the Windows formatted paths. Since these scripts are sourced in the bash environment they should be aware of the path formatting.

I don't think that this is a huge issue, because (as far as I'm aware) all the bash commands are called as single shot commands. But it might raise some questions and it is bug prone.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 11
  * Compiler+version: MSVC
  * Conan version: 1.50.2 (also on dev
  * Python version: 3.10.4

### Steps to reproduce (Include if Applicable)

create the package for: https://github.com/Ultimaker/conan-center-index/blob/modernize_autoconf/recipes/msys2/all/conanfile.py
create the package for: https://github.com/Ultimaker/conan-center-index/blob/modernize_autoconf/recipes/autoconf/all/conanfile.py

### Logs (Executed commands with output) (Include/Attach if Applicable)

below is the output of the `conanautotoolchain.sh` notice the Windows formatting of the `deactivation_` script paths
```bash
echo Capturing current environment in "C:\.conan\e6645b\1\build-release\conan\deactivate_conanautotoolstoolchain.sh"
echo "echo Restoring environment" >> "C:\.conan\e6645b\1\build-release\conan\deactivate_conanautotoolstoolchain.sh"
for v in CXX CC CPPFLAGS CXXFLAGS CFLAGS LDFLAGS PKG_CONFIG_PATH
do
    is_defined="true"
    value=$(printenv $v) || is_defined="" || true
    if [ -n "$value" ] || [ -n "$is_defined" ]
    then
        echo export "$v='$value'" >> "C:\.conan\e6645b\1\build-release\conan\deactivate_conanautotoolstoolchain.sh"
    else
        echo unset $v >> "C:\.conan\e6645b\1\build-release\conan\deactivate_conanautotoolstoolchain.sh"
    fi
done

echo Configuring environment variables

export CXX="cl"
export CC="cl"
export CPPFLAGS="$CPPFLAGS -DNDEBUG"
export CXXFLAGS="$CXXFLAGS /std:c++17 -MD -O2 -Ob2"
export CFLAGS="$CFLAGS -MD -O2 -Ob2"
export LDFLAGS="$LDFLAGS"
export PKG_CONFIG_PATH="/c/.conan/e6645b/1/build-release/conan:$PKG_CONFIG_PATH"
```

user: jellespijker
issue_11985: state: open
title: [question] CMakeToolchain & layout: how to run CMake twice with different variables & build folder?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

In conan-center, if shared=True `spirv-cross` recipe needs to run the build twice with different build folder & variables, to build both the library and tools (because tools can't link to shared lib, so the second build forces static build and the build of tools, while the first one builds shared libs only and disables tools): https://github.com/conan-io/conan-center-index/blob/304d808ff74d68da12802fb88417a255d5de269e/recipes/spirv-cross/all/conanfile.py#L88-L137

How to achieve the same logic with layout & CMakeToolchain?
user: SpaceIm
issue_11980: state: open
title: [bug] paths for environment files are not formatted for subsystem when run in win_bash on Windows
body: The `wrapped_user_cmd` in the `subsystems.py` doesn't take the subsystem into account, for the environment `.sh` files after the bash statement

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 11
  * Compiler+version: N/A
  * Conan version: 1.50.1 (and dev)
  * Python version: 3.10.4

### Steps to reproduce (Include if Applicable)
Run the `create` command on a recipe which uses msys2 on Windows.
I'm currently working on my attempt to modernize the `autoconf` recipe https://github.com/Ultimaker/conan-center-index/blob/modernize_autoconf/recipes/autoconf/all/conanfile.py

### Logs (Executed commands with output) (Include/Attach if Applicable)

```powershell
----Running------
> "C:\.conan\376fd79\1\build-release\conan\conanbuild.bat" && "C:\.conan\376fd79\1\build-release\conan\msys2_mode.bat" && C:\.conan\7c3916\1\bin\msys64\usr\bin\bash.exe -c ^". \^"C:\.conan\376fd79\1\build-release\conan\conanbuild.sh\^" ^&^& \^"/c/.conan/376fd79/1/source/configure\^" --prefix=/ --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include ^"
```

notice the formatting of the `conanbuild.sh` path: `C:\.conan\376fd79\1\build-release\conan\conanbuild.sh`



user: jellespijker
issue_11978: state: open
title: [develop2] deployers that could run after generators
body: Lets say that we want to relativize all paths in generated files from CMakeDeps, so we get a relocatable folder with all we need. There are 2 options:
- Make the ``CMakeDeps`` automatically relativize paths when possible
- Run something **after** the generators that relativize paths in files

the problem is that deployers run always before generators (so they can change the base folders, so generators use the deployed folders and not the cache ones). We could think of "post" deployers, or maybe lets call "installers". For example if we want to automate the zip of everything, including the CMakeDeps generated files, it needs to run after the generators. 
The implementation would be very similar to ``deployers`` just differ in the running point.
user: memsharded
issue_11974: state: open
title: [bug] `buildenv_info` of `tool_requires` from host profile are not automatically injected to "build scope"
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: macOS Monterey
  * Compiler+version: Apple Clang 13
  * Conan version: 1.51.3
  * Python version: 3.10.6

### Steps to reproduce (Include if Applicable)

- Create a recipe A intended to be used as a build requirement, and inject a `FOO` env variable with some custom value (like "conan") in `self.buildenv_info` of its `package_info()`.
- create a profile `host_profile` with this recipe A in its `tool_requires`.
- Create a "conan v2" recipe B with a custom CMakeLists and write inside `message(STATUS "FOO: $ENV{FOO}")`. In its conanfile, don't add `VirtualBuildEnv` generator (because recipe B doesn't have `tool_requires` internally).
- call `conan create <path/to/recipeB> recipeB/1.0.0@ -pr:b default -pr:h host_profile`

=> `FOO` value is empty, and it shouldn't because I believe conan should inject `buildenv_info` of `tool_requires` from host profile automatically into "build scope" (indeed, a recipe can't predict tool_requires of host profile, so it shouldn't be its responsibility to hardcode VirtualBuildEnv generator if it doesn't have tool_requires internally).

If I add `FOO` in the legacy `self.env_info` of recipe A, it's properly displayed during CMake configuration of recipe B.

(I'm not in CONAN_V2 mode)

### Logs (Executed commands with output) (Include/Attach if Applicable)


user: SpaceIm
issue_11972: state: open
title: [question] layout: Is there a property to get the "base build dir"?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

In conan-center recipes, I like to keep source files from libraries properly isolated in a subdir (usually called `src` to keep the name short) to achieve true out-of-source build, and avoid any risk of collision:

```python
def layout(self)
    cmake_layout(self, src_folder="src")
```

But in several recipes, a CMakeLists.txt is also provided by the recipe itself, not by original source code, so the final layout in the base build folder looks like this (I also include a `patches` folder coming from the recipe as well):

```
CMakeLists.txt
build/
  <build_type>/
  generatores/
patches/
src/
```

`self.source_folder` is the absolute path to `src` folder, but is there a property which I could rely on to give me the "base build dir" in `generate()`, `build()` or `package()` (which is here the parent folder of `self.source_folder`)? Without layout, this folder is `self.build_folder`, but with a layout like `cmake_layout`, `self.build_folder` gives the absolute path to `build/<build_type>` (for single-config generator).
user: SpaceIm
issue_11969: state: open
title: [feature] Port `conans.tools.get_env()` to `conan.tools.env`
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

It's widely used in conan-center recipes (more than 10% of recipes).
user: SpaceIm
issue_11967: state: open
title: [feature] MSBuild add upgrade_project again
body: Continuing https://github.com/conan-io/conan/issues/11966

The new [MSBuild](https://docs.conan.io/en/latest/reference/conanfile/tools/microsoft.html#msbuild) didn't port `upgrade_project` attribute from old [MSBuild](https://docs.conan.io/en/latest/reference/build_helpers/visual_studio.html#build).

Motivation: I started to port [xz_utils](https://github.com/conan-io/conan-center-index/pull/12308) recipe and it comes with .sln files, and when need to build using the new MSBuild, the expected SDK version is older, and it would be great if I could update the .sln file automatically.

I think it should be a MSBuild attribute as it should not change:

    msbuild = MSBuild(self)
    msbuild.upgrade_project = True (default True)

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: uilianries
issue_11964: state: open
title: [question] cross compiling with existing cmake toolchain file
body: - [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

I'm not 100% sure if this is a conan issue, or just a regular cmake issue:

I am trying to do cross-building using an existing toolchain file for a non-standard linux distro. The file looks like this:
```
set(toolchainpath /path/to/sysroots/folder)

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)

set(CMAKE_C_COMPILER ${toolchainpath}/path/to/c/compiler)
set(CMAKE_CXX_COMPILER ${toolchainpath}//path/to/cxx/compiler)

set(CMAKE_SYSROOT ${toolchainpath}/path/to/sysroot)
set(CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES
  ${toolchainpath}/path/to/c++/6.3.0
)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
```

From what I have read, the easiest way to do cross building is to create a conan package for your existing cmake toolchain file. I have done that like this:

```
from conan import ConanFile
import os

class ToolchainConan(ConanFile):
    name = "Toolchain"
    version = "1.0.0"
    exports_sources=["mytoolchain.cmake"]

    def package(self):
        # Copy all the required files for your toolchain
        self.copy("mytoolchain.cmake", dst=self.package_folder)

    def package_info(self):
        f = os.path.join(self.package_folder, "mytoolchain.cmake")
        self.conf_info.append("tools.cmake.cmaketoolchain:user_toolchain", [f])

```

I then have a conan profile called `CrossCompile` that looks like this:

```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=6
compiler.libcxx=libstdc++11
build_type=Release

[options]

[build_requires]
Toolchain/1.0.0

[env]
```

I can build individual packages just fine, but if I try to build one package using the `CrossCompile` profile which depends on _other_ packages build using the `CrossCompile` profile, then I get the following errors:

```
By not providing "FindEigen3.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Eigen3", but
  CMake did not find one.
```

But if I run with the usual `-pr=default` then things are totally fine. So I am thinking the existing toolchain file is messing up the cmake paths set up by `CMakeDeps`, but I am not sure how. Am I just using the existing toolchain file incorrectly?

Thanks again!
user: JeffHough
issue_11960: state: open
title: [feature] Better build caching support in Conan 2.0 (as compared to 1.x)
body: A topic that was always quite a weak point with Conan 1.x is the topic of build caching support. Obviously since Conan is not a full blown build system one may claim that Conan is also not fully responsible for this topic. Nevertheless it does have a very strong impact on the file system layout during build time and therefore should be held responsible for at least not preventing build caching or making it very difficult to implement/configure.
The minimum I would expect/wish for is a description and some recommendations in the documentation how to use Conan together with ccache locally.
A more advanced requirement would be to better support shared build caches like sccache or similar alternatives.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: johschmitz
issue_11958: state: open
title: [question] Respecting compiler.libcxx abi setting
body: I have the following conan profile:

```
$ conan --version
Conan version 1.51.3

$ conan profile show default
Configuration for profile default:

[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=11
compiler.cppstd=20
compiler.libcxx=libstdc++
build_type=Release
[options]
[conf]
[build_requires]
[env]
```

Note that `compiler.libcxx` is the old ABI (`libstdc++`) and not the new ABI (`libstdc++11`). This is intentional. Also I'm specifying `cppstd=20`.

I then made a custom conanfile for `{fmt}`, which tries to package up fmt 9.0. That looks like, in its entirety:

```python
from conans import ConanFile, CMake, tools
from conan.tools.cmake import CMakeToolchain, cmake_layout

class ConanFmt(ConanFile):
    name = "fmt"
    version = "9.0.0"

    settings = "os", "compiler", "cppstd", "build_type", "arch"

    def source(self):
        git = tools.Git(folder="fmt")
        git.clone("https://github.com/fmtlib/fmt.git", "9.0.0", shallow=True)

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.definitions["FMT_DOC"] = False
        cmake.definitions["FMT_TEST"] = False
        cmake.definitions["FMT_INSTALL"] = True
        cmake.definitions["CMAKE_EXPORT_COMPILE_COMMANDS"] = True
        cmake.configure(source_folder="fmt")
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()

    def package_info(self):
        self.cpp_info.libs = ["fmt"]
```

When I try to go ahead and package this up, like say:

```
$ conan create . demo/testing -s build_type=Release
```

This does actually go ahead and clone the `{fmt}` repo, and correctly build and package up the contents of the library.

Except that:

* there is no `_GLIBCXX_USE_CXX11_ABI` definition set (despite what [this page](https://docs.conan.io/en/latest/howtos/manage_gcc_abi.html#manage-gcc-abi)) says. 
* `{fmt}` was compiled with C++11, not C++20
* ... but it _was_ built with `Release` (`-O3 -DNDEBUG`)

Conan does appear to provide variables like `CONAN_CMAKE_CXX_STANDARD=20`, `CONAN_STD_CXX_FLAG=-std=c++2a`, and `CONAN_LIBCXX=libstdc++`. But `{fmt}`'s build doesn't actually use those, so that isn't very useful.

How do I actually get conan to propagate through these variables properly? Is that something that must be explicitly specified in the `conanfile.py` (even if it's in the profile)?

I also posted this question on [StackOverflow](https://stackoverflow.com/q/73476787/2069064).
user: brevzin
issue_11948: state: open
title: [bug] Tools collect_libs discards suffixes
body: When porting the libpng project to Conan v2, the CCI hook complained that I lied about the library name in `self.cpp_info.libs`, which was supposed to be `["png16.a"]` (on Linux/Mac is `libpng16.a`).

The truth is, the libpng projects creates a relative symbolic link, named as `libpng.a`, so we have two files in `libdirs[0]`:  `libpng16.a` and its symlink `libpng.a`.

When writing the recipe, I avoided `collect_libs` and preferred and real name, so I pointed as:

    self.cpp_info.libs = ["png16"] 

However, our CCI hook has a post cpp_info step which checks if what we declared for `libs` is actually installed in `libdirs`, and it failed. When checking the hook script, it uses `collect_libs` to list those installed libraries and compare with the libraries names from cpp_info.
So, the method `collect_libs` only found `"png"`, which means, it found the symbolic link, but ignored the real library.

Maybe it's a expected behavior, as the symbolic link makes life easier to find the library, but still, it could be customized like `collect_libs(self, ignore_symlinks=True)` so, it would list only real files.

### Environment Details (include every applicable attribute)
  * Operating System+version: Linux and Mac confirmed
  * Compiler+version: N/A
  * Conan version: 1.51.3
  * Python version: 3.10.4 (also tested with 3.9)

### Steps to reproduce (Include if Applicable)

```python
from conan import ConanFile
from conan.tools.files import collect_libs, save, mkdir
import os

class FooConan(ConanFile):
    def package(self):
        lib_folder = os.path.join(self.package_folder, "lib")
        lib_name = os.path.join(lib_folder, "libpng16.a")
        mkdir(self, lib_folder)
        save(self, lib_name, "FOOBAR")
        os.symlink(lib_name, os.path.join(lib_folder, "libpng.a"))

    def package_info(self):
        collected_libs = collect_libs(self)
        self.output.info(f"***** COLLECTED LIBS: {collected_libs}")
        self.cpp_info.libs = collected_libs
        # XXX: Collect libs only finds the symlink
        assert ["png"] == collected_libs
```

    conan create . foo/0.1.0@ -pr:b=default -pr:h=default


### Logs (Executed commands with output) (Include/Attach if Applicable)

Read the last lines of this log, the collected libs is there.

```
% conan create . foo/0.1.0@ -pr:b=default -pr:h=default
[HOOK - conan-center.py] pre_export(): [DEPRECATED GLOBAL CPPSTD (KB-H001)] OK
[HOOK - conan-center.py] pre_export(): [REFERENCE LOWERCASE (KB-H002)] OK
[HOOK - conan-center.py] pre_export(): ERROR: [RECIPE METADATA (KB-H003)] Conanfile doesn't have 'name' attribute. (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H003) 
[HOOK - conan-center.py] pre_export(): ERROR: [RECIPE METADATA (KB-H003)] Conanfile doesn't have 'url' attribute.  (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H003) 
[HOOK - conan-center.py] pre_export(): ERROR: [RECIPE METADATA (KB-H003)] Conanfile doesn't have 'license' attribute.  (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H003) 
[HOOK - conan-center.py] pre_export(): ERROR: [RECIPE METADATA (KB-H003)] Conanfile doesn't have 'description' attribute.  (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H003) 
[HOOK - conan-center.py] pre_export(): ERROR: [RECIPE METADATA (KB-H003)] Conanfile doesn't have 'homepage' attribute.  (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H003) 
[HOOK - conan-center.py] pre_export(): ERROR: [RECIPE METADATA (KB-H003)] Conanfile doesn't have 'topics' attribute.  (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H003) 
[HOOK - conan-center.py] pre_export(): WARN: [HEADER_ONLY, NO COPY SOURCE (KB-H005)] This recipe is a header only library as it does not declare 'settings'. Please include 'no_copy_source' to avoid unnecessary copy steps
[HOOK - conan-center.py] pre_export(): [HEADER_ONLY, NO COPY SOURCE (KB-H005)] OK
[HOOK - conan-center.py] pre_export(): [FPIC OPTION (KB-H006)] OK
[HOOK - conan-center.py] pre_export(): [VERSION RANGES (KB-H008)] OK
[HOOK - conan-center.py] pre_export(): [RECIPE FOLDER SIZE (KB-H009)] Total recipe size: 1.0537109375 KB
[HOOK - conan-center.py] pre_export(): [RECIPE FOLDER SIZE (KB-H009)] OK
[HOOK - conan-center.py] pre_export(): [EXPORT LICENSE (KB-H023)] exports: None
[HOOK - conan-center.py] pre_export(): [EXPORT LICENSE (KB-H023)] exports: None
[HOOK - conan-center.py] pre_export(): [EXPORT LICENSE (KB-H023)] OK
[HOOK - conan-center.py] pre_export(): ERROR: [TEST PACKAGE FOLDER (KB-H024)] There is no 'test_package' for this recipe (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H024) 
[HOOK - conan-center.py] pre_export(): [META LINES (KB-H025)] OK
[HOOK - conan-center.py] pre_export(): [CONAN CENTER INDEX URL (KB-H027)] OK
[HOOK - conan-center.py] pre_export(): [CMAKE MINIMUM VERSION (KB-H028)] OK
[HOOK - conan-center.py] pre_export(): [TEST PACKAGE - RUN ENVIRONMENT (KB-H029)] OK
[HOOK - conan-center.py] pre_export(): [SYSTEM REQUIREMENTS (KB-H032)] OK
[HOOK - conan-center.py] pre_export(): [CONANDATA.YML FORMAT (KB-H030)] OK
[HOOK - conan-center.py] pre_export(): [TEST PACKAGE - NO IMPORTS() (KB-H034)] OK
[HOOK - conan-center.py] pre_export(): [NO AUTHOR (KB-H037)] OK
[HOOK - conan-center.py] pre_export(): [NOT ALLOWED ATTRIBUTES (KB-H039)] OK
[HOOK - conan-center.py] pre_export(): [NO TARGET NAME (KB-H040)] OK
[HOOK - conan-center.py] pre_export(): [NO FINAL ENDLINE (KB-H041)] OK
[HOOK - conan-center.py] pre_export(): [NO REQUIRES.ADD() (KB-H044)] OK
[HOOK - conan-center.py] pre_export(): [DELETE OPTIONS (KB-H045)] OK
[HOOK - conan-center.py] pre_export(): [CMAKE VERBOSE MAKEFILE (KB-H046)] OK
[HOOK - conan-center.py] pre_export(): [CMAKE VERSION REQUIRED (KB-H048)] OK
[HOOK - conan-center.py] pre_export(): [CMAKE WINDOWS EXPORT ALL SYMBOLS (KB-H049)] OK
[HOOK - conan-center.py] pre_export(): [DEFAULT OPTIONS AS DICTIONARY (KB-H051)] OK
[HOOK - conan-center.py] pre_export(): [CONFIG.YML HAS NEW VERSION (KB-H052)] OK
[HOOK - conan-center.py] pre_export(): [PRIVATE IMPORTS (KB-H053)] OK
[HOOK - conan-center.py] pre_export(): [SINGLE REQUIRES (KB-H055)] OK
[HOOK - conan-center.py] pre_export(): [TOOLS RENAME (KB-H057)] OK
[HOOK - conan-center.py] pre_export(): [ILLEGAL CHARACTERS (KB-H058)] OK
[HOOK - conan-center.py] pre_export(): [CLASS NAME (KB-H059)] OK
[HOOK - conan-center.py] pre_export(): [NO CRLF (KB-H060)] OK
[HOOK - conan-center.py] pre_export(): [NO BUILD SYSTEM FUNCTIONS (KB-H061)] OK
[HOOK - conan-center.py] pre_export(): [TOOLS CROSS BUILDING (KB-H062)] OK
[HOOK - conan-center.py] pre_export(): [INVALID TOPICS (KB-H064)] OK
[HOOK - conan-center.py] pre_export(): [NO REQUIRED_CONAN_VERSION (KB-H065)] OK
[HOOK - conan-center.py] pre_export(): [TEST_TYPE MANAGEMENT (KB-H068)] OK
[HOOK - conan-center.py] pre_export(): [TEST PACKAGE - NO DEFAULT OPTIONS (KB-H069)] OK
[HOOK - conan-center.py] pre_export(): WARN: [MANDATORY SETTINGS (KB-H070)] No 'settings' detected in your conanfile.py. Add 'settings' attribute and use 'package_id(self)' method to manage the package ID.
[HOOK - conan-center.py] pre_export(): [MANDATORY SETTINGS (KB-H070)] OK
Exporting package recipe
[HOOK - conan-center.py] post_export(): [CONANDATA.YML REDUCE (KB-H031)] OK
[HOOK - conan-center.py] post_export(): [DEFAULT SHARED OPTION VALUE (KB-H050)] OK
[HOOK - conan-center.py] post_export(): [LICENSE PUBLIC DOMAIN (KB-H056)] OK
foo/0.1.0: The stored package has not changed
foo/0.1.0: Using the exported files summary hash as the recipe revision: 618bfcde05f3183716ed6832be4463a6 
foo/0.1.0: Exported revision: 618bfcde05f3183716ed6832be4463a6
Configuration (profile_host):
[settings]
arch=armv8
arch_build=armv8
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=13
os=Macos
os_build=Macos
[options]
[build_requires]
[env]
[conf]

Configuration (profile_build):
[settings]
arch=armv8
arch_build=armv8
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=13
os=Macos
os_build=Macos
[options]
[build_requires]
[env]
[conf]

foo/0.1.0: Forced build from source
Installing package: foo/0.1.0
Requirements
    foo/0.1.0 from local cache - Cache
Packages
    foo/0.1.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Build

Installing (downloading, building) binaries...
foo/0.1.0: Copying sources to build folder
foo/0.1.0: Building your package in /Users/uilian/.conan/data/foo/0.1.0/_/_/build/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
foo/0.1.0: Generator txt created conanbuildinfo.txt
foo/0.1.0: Aggregating env generators
[HOOK - conan-center.py] pre_build(): [FPIC MANAGEMENT (KB-H007)] 'fPIC' option not found
[HOOK - conan-center.py] pre_build(): [FPIC MANAGEMENT (KB-H007)] OK
foo/0.1.0: Calling build()
foo/0.1.0: WARN: This conanfile has no build step
foo/0.1.0: Package '5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9' built
foo/0.1.0: Build folder /Users/uilian/.conan/data/foo/0.1.0/_/_/build/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
foo/0.1.0: Generated conaninfo.txt
foo/0.1.0: Generated conanbuildinfo.txt
foo/0.1.0: Generating the package
foo/0.1.0: Package folder /Users/uilian/.conan/data/foo/0.1.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
foo/0.1.0: Calling package()
[HOOK - conan-center.py] post_package(): ERROR: [PACKAGE LICENSE (KB-H012)] No 'licenses' folder found in package: /Users/uilian/.conan/data/foo/0.1.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9  (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H012) 
[HOOK - conan-center.py] post_package(): [DEFAULT PACKAGE LAYOUT (KB-H013)] OK
[HOOK - conan-center.py] post_package(): ERROR: [MATCHING CONFIGURATION (KB-H014)] Package for Header Only does not contain artifacts with these extensions: ['h', 'h++', 'hh', 'hxx', 'hpp'] (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H014) 
[HOOK - conan-center.py] post_package(): ERROR: [MATCHING CONFIGURATION (KB-H014)] Packaged artifacts does not match the settings used: os=None, compiler=None (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H014) 
[HOOK - conan-center.py] post_package(): [SHARED ARTIFACTS (KB-H015)] OK
[HOOK - conan-center.py] post_package(): [PC-FILES (KB-H020)] OK
[HOOK - conan-center.py] post_package(): [CMAKE-MODULES-CONFIG-FILES (KB-H016)] OK
[HOOK - conan-center.py] post_package(): [PDB FILES NOT ALLOWED (KB-H017)] OK
[HOOK - conan-center.py] post_package(): [LIBTOOL FILES PRESENCE (KB-H018)] OK
[HOOK - conan-center.py] post_package(): [MS RUNTIME FILES (KB-H021)] OK
[HOOK - conan-center.py] post_package(): [SHORT_PATHS USAGE (KB-H066)] OK
[HOOK - conan-center.py] post_package(): [MISSING SYSTEM LIBS (KB-H043)] OK
foo/0.1.0 package(): Packaged 2 '.a' files: libpng16.a, libpng.a
foo/0.1.0: Package '5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9' created
foo/0.1.0: Created package revision fceead34a403492c2294e026d9a318fa
foo/0.1.0: ***** COLLECTED LIBS: ['png']
[HOOK - conan-center.py] post_package_info(): [CMAKE FILE NOT IN BUILD FOLDERS (KB-H019)] OK
[HOOK - conan-center.py] post_package_info(): [LIBRARY DOES NOT EXIST (KB-H054)] OK
[HOOK - conan-center.py] post_package_info(): ERROR: [INCLUDE PATH DOES NOT EXIST (KB-H071)] Component foo::foo include dir 'include' is listed in the recipe, but not found in package folder. The include dir should probably be fixed or removed. (https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md#KB-H071) 

```

user: uilianries
issue_11945: state: open
title: [question] Cross-compilation with SCons and tool_requires
body: I am trying to setup cross-compilation with SCons where Conan provides the cross-compiler as a binary package.
So, I have created a cross-compiler package which works fine with CMAKE when I add it as tool_requires and set the correct host profile.

For SCons however I am not sure how I can add the location of the cross-compiler binaries to the build environment.
The `SConscript_conan` file does not contain anything regarding the packages installed via *tool_requires*. I would expect that they show up, so that I can add the `BINPATH` to the SCons environment. I can't add the pakckage as normal *requires* because then the build and host environments don't match anymore.

Does anyone have a suggestion what the recommend approach is for cross-compilation with SCons?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: thesummer
labels: component: Build: Build helpers, build systems..
issue_11944: state: open
title: [question] Per-repository variable with CMakeTookchain and conan workspace
body: We have adopted `conan workspace` at the center of our development workflow (most notably because it allows us to work seamlessly on any number of related repositories, without having to explicitly recompile each in order, which is a major win).

Until now, we were generating a custom cmake file from the `conanfile.py` recipe, this file being used to host our custom variables.
e.g.:

    def _generate_cmake_configfile(self):
        """ Generates a conanuser_config.cmake file to forward options to CMake. """
        with open("conanuser_config.cmake", "w") as config:
            config.write("message(STATUS \"Including user generated conan config.\")\n")
            # avoid path.join, on Windows it outputs '\', which is a string escape sequence.
            config.write("set({} {})\n".format("BUILD_tests", self.options.build_tests))

    def generate(self):
        self._generate_cmake_configfile()

This also requires to explicitly `include(conanuser_config.cmake)` in our `CMakeLists.txt`, but appart from being a lot of boilerplate, it worked quite well in different situations (installing a package in the cache, locally developing a single package, or working on several repositories all included in a common workspace).

While migrating to `CMakeToolchain` generator, we tried to replace this `_generate_cmake_configfile()` with:

    def generate(self):
        toolchain = CMakeToolchain(self)
        # cache_variables are written to CMakePresets.json
        toolchain.cache_variables["BUILD_tests"] = str(self.options.build_tests)
        toolchain.generate()

This does work well when developing a single package locally. Sadly, we cannot get it to work for our `conan workspace` based workflow.
We suppose only a single `CMakePresets.json` gets included in the _amalgamation_ of the different repositories, and we lost the ability to control each individually.

* Would you have any suggestion or recommendation to leverage the toolchain variable, on a per-repository basis, in a workspace setup?
* Or should we stick to our custom `conanuser_config.cmake` approach?

user: Adnn
issue_11938: state: open
title: [bug]  libpq/14.2: Error in build() method, line 180 Windows 10, MinGW, Gcc 12.1
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: MinGW 12.1
  * Conan version: 1.51.3
  * Python version: 3.9.8
Profile mingw:
```[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=12
compiler.libcxx=libstdc++11
compiler.threads=posix
build_type=Release
[options]
[build_requires]
[env]
CC=gcc
CXX=g++
CFLAGS=-m64
CXXFLAGS=-m64
LDFLAGS=-m64
```

### Steps to reproduce (Include if Applicable)
conan install libpq/14.2@ --build missing -pr mingw


### Logs (Executed commands with output) (Include/Attach if Applicable)
``` conan install libpq/14.2@ --build missing -pr clang
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=clang
compiler.version=14
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
CC=clang
CFLAGS=-m64
CXX=clang++
CXXFLAGS=-m64
LDFLAGS=-m64
libpq/14.2: WARN: Package binary is corrupted, removing: 740ddc0b690a0b53f67532814015d0310d7d742a
Installing package: libpq/14.2
Requirements
    libpq/14.2 from 'conancenter' - Cache
Packages
    libpq/14.2:740ddc0b690a0b53f67532814015d0310d7d742a - Build
Build requirements
    msys2/cci.latest from 'conancenter' - Cache
Build requirements packages
    msys2/cci.latest:eee3fba89db6d777329de604625af8c30d46f080 - Cache

Installing (downloading, building) binaries...
msys2/cci.latest: Already installed!
msys2/cci.latest: Creating MSYS_ROOT env var : C:\.conan\4d4edc\1\bin\msys64
msys2/cci.latest: Creating MSYS_BIN env var : C:\.conan\4d4edc\1\bin\msys64\usr\bin
msys2/cci.latest: Appending PATH env var with : C:\.conan\4d4edc\1\bin\msys64\usr\bin
libpq/14.2: Applying build-requirement: msys2/cci.latest
libpq/14.2: WARN: Build folder is dirty, removing it: C:\Users\kamil\.conan\data\libpq\14.2\_\_\build\740ddc0b690a0b53f67532814015d0310d7d742a
libpq/14.2: Copying sources to build folder
libpq/14.2: Building your package in C:\Users\kamil\.conan\data\libpq\14.2\_\_\build\740ddc0b690a0b53f67532814015d0310d7d742a
libpq/14.2: Generator txt created conanbuildinfo.txt
libpq/14.2: Aggregating env generators
libpq/14.2: Calling build()
libpq/14.2: run_in_windows_bash: C:\.conan\4d4edc\1\bin\msys64\usr\bin\bash.exe --login -c ^"cd \^"/c/users/kamil/.conan/data/libpq/14.2/_/_/build/740ddc0b690a0b53f67532814015d0310d7d742a/source_subfolder\^" ^&^& PATH=\^"/c/.conan/4d4edc/1/bin/msys64/usr/bin:$PATH\^" ^&^& /c/users/kamil/.conan/data/libpq/14.2/_/_/build/740ddc0b690a0b53f67532814015d0310d7d742a/source_subfolder/configure --help ^"
`configure' configures PostgreSQL 14.2 to adapt to many kinds of systems.

Usage: /c/users/kamil/.conan/data/libpq/14.2/_/_/build/740ddc0b690a0b53f67532814015d0310d7d742a/source_subfolder/configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help              display this help and exit
      --help=short        display options specific to this package
      --help=recursive    display the short help of all the included packages
  -V, --version           display version information and exit
  -q, --quiet, --silent   do not print `checking ...' messages
      --cache-file=FILE   cache test results in FILE [disabled]
  -C, --config-cache      alias for `--cache-file=config.cache'
  -n, --no-create         do not create output files
      --srcdir=DIR        find the sources in DIR [configure dir or `..']

Installation directories:
  --prefix=PREFIX         install architecture-independent files in PREFIX
                          [/usr/local/pgsql]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                          [PREFIX]

By default, `make install' will install all the files in
`/usr/local/pgsql/bin', `/usr/local/pgsql/lib' etc.  You can specify
an installation prefix other than `/usr/local/pgsql' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIR            user executables [EPREFIX/bin]
  --sbindir=DIR           system admin executables [EPREFIX/sbin]
  --libexecdir=DIR        program executables [EPREFIX/libexec]
  --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
  --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
  --libdir=DIR            object code libraries [EPREFIX/lib]
  --includedir=DIR        C header files [PREFIX/include]
  --oldincludedir=DIR     C header files for non-gcc [/usr/include]
  --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
  --datadir=DIR           read-only architecture-independent data [DATAROOTDIR]
  --infodir=DIR           info documentation [DATAROOTDIR/info]
  --localedir=DIR         locale-dependent data [DATAROOTDIR/locale]
  --mandir=DIR            man documentation [DATAROOTDIR/man]
  --docdir=DIR            documentation root [DATAROOTDIR/doc/postgresql]
  --htmldir=DIR           html documentation [DOCDIR]
  --dvidir=DIR            dvi documentation [DOCDIR]
  --pdfdir=DIR            pdf documentation [DOCDIR]
  --psdir=DIR             ps documentation [DOCDIR]

System types:
  --build=BUILD     configure for building on BUILD [guessed]
  --host=HOST       cross-compile to build programs to run on HOST [BUILD]

Optional Features:
  --disable-option-checking  ignore unrecognized --enable/--with options
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --disable-integer-datetimes
                          obsolete option, no longer supported
  --enable-nls[=LANGUAGES]
                          enable Native Language Support
  --disable-rpath         do not embed shared library search path in
                          executables
  --disable-spinlocks     do not use spinlocks
  --disable-atomics       do not use atomic operations
  --enable-debug          build with debugging symbols (-g)
  --enable-profiling      build with profiling enabled
  --enable-coverage       build with coverage testing instrumentation
  --enable-dtrace         build with DTrace support
  --enable-tap-tests      enable TAP tests (requires Perl and IPC::Run)
  --enable-depend         turn on automatic dependency tracking
  --enable-cassert        enable assertion checks (for debugging)
  --disable-thread-safety disable thread-safety in client libraries
  --disable-largefile     omit support for large files

Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-extra-version=STRING
                          append STRING to version
  --with-template=NAME    override operating system template
  --with-includes=DIRS    look for additional header files in DIRS
  --with-libraries=DIRS   look for additional libraries in DIRS
  --with-libs=DIRS        alternative spelling of --with-libraries
  --with-pgport=PORTNUM   set default port number [5432]
  --with-blocksize=BLOCKSIZE
                          set table block size in kB [8]
  --with-segsize=SEGSIZE  set table segment size in GB [1]
  --with-wal-blocksize=BLOCKSIZE
                          set WAL block size in kB [8]
  --with-CC=CMD           set compiler (deprecated)
  --with-llvm             build with LLVM based JIT support
  --with-icu              build with ICU support
  --with-tcl              build Tcl modules (PL/Tcl)
  --with-tclconfig=DIR    tclConfig.sh is in DIR
  --with-perl             build Perl modules (PL/Perl)
  --with-python           build Python modules (PL/Python)
  --with-gssapi           build with GSSAPI support
  --with-krb-srvnam=NAME  default service principal name in Kerberos (GSSAPI)
                          [postgres]
  --with-pam              build with PAM support
  --with-bsd-auth         build with BSD Authentication support
  --with-ldap             build with LDAP support
  --with-bonjour          build with Bonjour support
  --with-selinux          build with SELinux support
  --with-systemd          build with systemd support
  --without-readline      do not use GNU Readline nor BSD Libedit for editing
  --with-libedit-preferred
                          prefer BSD Libedit over GNU Readline
  --with-uuid=LIB         build contrib/uuid-ossp using LIB (bsd,e2fs,ossp)
  --with-ossp-uuid        obsolete spelling of --with-uuid=ossp
  --with-libxml           build with XML support
  --with-libxslt          use XSLT support when building contrib/xml2
  --with-system-tzdata=DIR
                          use system time zone data in DIR
  --without-zlib          do not use Zlib
  --with-lz4              build with LZ4 support
  --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
  --with-ssl=LIB          use LIB for SSL/TLS support (openssl)
  --with-openssl          obsolete spelling of --with-ssl=openssl

Some influential environment variables:
  CC          C compiler command
  CFLAGS      C compiler flags
  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
              nonstandard directory <lib dir>
  LIBS        libraries to pass to the linker, e.g. -l<library>
  CPPFLAGS    (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
              you have headers in a nonstandard directory <include dir>
  CXX         C++ compiler command
  CXXFLAGS    C++ compiler flags
  LLVM_CONFIG path to llvm-config command
  CLANG       path to clang compiler to generate bitcode
  CPP         C preprocessor
  PKG_CONFIG  path to pkg-config utility
  PKG_CONFIG_PATH
              directories to add to pkg-config's search path
  PKG_CONFIG_LIBDIR
              path overriding pkg-config's built-in search path
  ICU_CFLAGS  C compiler flags for ICU, overriding pkg-config
  ICU_LIBS    linker flags for ICU, overriding pkg-config
  XML2_CONFIG path to xml2-config utility
  XML2_CFLAGS C compiler flags for XML2, overriding pkg-config
  XML2_LIBS   linker flags for XML2, overriding pkg-config
  LZ4_CFLAGS  C compiler flags for LZ4, overriding pkg-config
  LZ4_LIBS    linker flags for LZ4, overriding pkg-config
  LDFLAGS_EX  extra linker flags for linking executables only
  LDFLAGS_SL  extra linker flags for linking shared libraries only
  PERL        Perl program
  PYTHON      Python program
  MSGFMT      msgfmt program for NLS
  TCLSH       Tcl interpreter program (tclsh)

Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.

Report bugs to <pgsql-bugs@lists.postgresql.org>.
PostgreSQL home page: <https://www.postgresql.org/>.
libpq/14.2: Calling:
 > /c/users/kamil/.conan/data/libpq/14.2/_/_/build/740ddc0b690a0b53f67532814015d0310d7d742a/source_subfolder/configure --without-readline --without-zlib --without-openssl --prefix=C:/Users/kamil/.conan/data/libpq/14.2/_/_/package/740ddc0b690a0b53f67532814015d0310d7d742a
libpq/14.2: run_in_windows_bash: C:\.conan\4d4edc\1\bin\msys64\usr\bin\bash.exe --login -c ^"cd \^"/c/users/kamil/.conan/data/libpq/14.2/_/_/build/740ddc0b690a0b53f67532814015d0310d7d742a/source_subfolder\^" ^&^& PATH=\^"/c/.conan/4d4edc/1/bin/msys64/usr/bin:$PATH\^" ^&^& /c/users/kamil/.conan/data/libpq/14.2/_/_/build/740ddc0b690a0b53f67532814015d0310d7d742a/source_subfolder/configure --without-readline --without-zlib --without-openssl --prefix=C:/Users/kamil/.conan/data/libpq/14.2/_/_/package/740ddc0b690a0b53f67532814015d0310d7d742a  ^"
configure: loading site script /etc/config.site
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
checking which template to use... win32
checking whether NLS is wanted... no
checking for default port number... 5432
checking for block size... 8kB
checking for segment size... 1GB
checking for WAL block size... 8kB
checking whether the C compiler works... no
configure: error: in `/c/users/kamil/.conan/data/libpq/14.2/_/_/build/740ddc0b690a0b53f67532814015d0310d7d742a/source_subfolder':
configure: error: C compiler cannot create executables
See `config.log' for more details
libpq/14.2:
libpq/14.2: ERROR: Package '740ddc0b690a0b53f67532814015d0310d7d742a' build failed
libpq/14.2: WARN: Build folder C:\Users\kamil\.conan\data\libpq\14.2\_\_\build\740ddc0b690a0b53f67532814015d0310d7d742a
ERROR: libpq/14.2: Error in build() method, line 180
        autotools = self._configure_autotools()
while calling '_configure_autotools', line 100
        self._autotools.configure(args=args)
        ConanException: Error 77 while executing /c/users/kamil/.conan/data/libpq/14.2/_/_/build/740ddc0b690a0b53f67532814015d0310d7d742a/source_subfolder/configure --without-readline --without-zlib --without-openssl --prefix=C:/Users/kamil/.conan/data/libpq/14.2/_/_/package/740ddc0b690a0b53f67532814015d0310d7d742a
```
The sam is with Clang, I have tried update Conan, restart PC. When making manualy using MSYS it works and compile well. 

Update 1: Fix logs formating
user: Kaaml
issue_11937: state: open
title: [question] CMakeToolchain: When use cached_variables vs variables
body: The documentation only explains `CMakeToolchain.variables` and `CMakeToolchain.cached_variables` features, one is better for multiple configuration and another is single configuration:

https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmaketoolchain.html#variables

But it's not clear when each one should be used, based on real examples.

So far, we are migrating recipes in CCI and there is a doubt about which one should be adopted by default when using `CMakeToolchain`.


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: uilianries
issue_11925: state: open
title: [bug] Cached login expires
body: We use baselined VMs to do our build/test. During the vm configuration, we set the user/pass via `conan user` using a artifactory token which we set not expire (although this still shows 365 days expiration...but I digress). However, we are finding that the login still seems to expire (maybe after 30 days?). We can launch the baseline, login again using the same token, and then it continues to work...so it doesn't appear to be a problem with the token. Is there a way to prevent this?

### Environment Details (include every applicable attribute)
  * Operating System+version: Both Windows 10 and RHEL 7
  * Compiler+version: n/a
  * Conan version: 1.48
  * Python version: 3.10.4

### Steps to reproduce (Include if Applicable)
1. login to remote using non-expiring token
2. wait 30 days
3. login stops working

user: rconde01
issue_11922: state: open
title: [bug] Autotools on Windows is problematic
body: I've been working on writing a port for ImageMagick that uses the autotools build scripts for Windows. Here is what I had to do:

```python
    def generate(self):
        tc = AutotoolsToolchain(self)
        env = tc.environment()


        if microsoft.is_msvc(self):
            # FIXME: it seems that PKG_CONFIG_PATH is added as a unix style path
            env.unset("PKG_CONFIG_PATH")
            env.define("PKG_CONFIG_PATH", self.generators_folder)


            # FIXME: otherwise configure reports "ld" as its linker
            env.define("LD", "link")
            # use "compile" script as a compiler driver for cl, since autotools
            # doesn't work well with cl
            compile_script = microsoft.unix_path(self, os.path.join(
                os.getcwd(), self._source_subfolder, "config", "compile"))
            env.define("CC", f'{compile_script} cl.exe -nologo')
            env.define("CXX", f"{compile_script} cl.exe -nologo")


        tc.generate(env)


        # FIXME: without this, AutotoolsDeps generates unix style path
        self.win_bash = False
        td = AutotoolsDeps(self)


        # AutotoolsDeps uses /LIBPATH: which is a linker argument that
        # will be pased incorrectly to the msvc compiler by autotools
        # this replaces /LIBPATH: by  -L, which the "compile" script will
        # fix for us, and replaces /I by -I, which works with the compile script
        env = td.environment
        if microsoft.is_msvc(self):
            ldflags = env.vars(self)["LDFLAGS"].replace("/LIBPATH:", "-L").replace("\\", "/")
            cppflags = env.vars(self)["CPPFLAGS"].replace("/I", "-I").replace("\\", "/")
            env.define("LDFLAGS", ldflags)
            env.define("CPPFLAGS", cppflags)


        # AutotoolsDeps adds all dependencies in the LIBS variable.
        # all these libs make `libtool` do the extra work of finding where they
        # are, which seems to fail on Windows
        # this variable is not needed anyways, since autotools will link against
        # required libraries by itself
        env.unset("LIBS")
        td.generate()


        self.win_bash = True
```
This is a list of the bugs I encountered:
1. `PKG_CONFIG_PATH` is added as a unix path, while autotools will use the pkg-config executable provided by conan, which expects a windows style path.
2. `LD` environment variable is not defined, and autotools incorrectly uses `ld` as a linker.
3. Conan uses `cl` directly as a compiler. I think it should be better to use the `compile` wrapper provided by autotools, which makes `cl` behave as it were `gcc`. This is important for a couple of reasons:
    * Many of the autotools based projects use libtool, which doesn't play well with msvc command syntax.
    * Many of the autotools based projects use compilation command as follows `$CC $f $CFLAGS $LDFLAGS`, and conan adds `/LIBPATH:` linker flags inside `LDFLAGS`, which is not a supported flag by `cl`.
 
   So instead, I suggest conan uses the `compile` wrapper, and uses `-I` `-L` and `-l` flags, which it will accept happily and convert to flags that msvc understands, while giving autotools and libtool the illusion that msvc operates similarly to gcc and clang. 
4. AutotoolsDeps generates unix style paths, while on Windows.
5. `LIBS` environment variable causes more harm than good, especially with libtool. Let's unset it, and give the build script the chance to find the libraries it needs itself.
user: theartful
issue_11919: state: open
title: [question] error on concurrent package creation
body: Hello,

I'm using latest conan 1.51.3 on Linux and Gitlab CI with several jobs building binary for differents target.
But when calling "conan create" or "conan export-pkg" I get randomly following error:

```
error: unrecognized arguments: Settings already up to date
```

For now I use "export-pkg" command with "conan install" and "conan build" called before, to limit concurrency issue with conan cache and also to be able to make Sonar code quality analysis from git clone instead of having build done in cache.
But I have always these random errors at "export-pkg" command  invocation.
The lock file doesn't seems used with this command.
And as documented in https://docs.conan.io/en/latest/mastering/custom_cache.html#concurrency, I don't want to use a cache by CI job, which is very not efficient.

Do you have some tips to avoid this kind concurrency issue?

Regards.
user: EstebanDugueperoux2
issue_11914: state: open
title: [bug] Conan deletes recipe from cache if `conan download` is unable to find recipe
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: N/A
  * Conan version: 1.51.3
  * Python version: 3.9.12

### Steps to reproduce (Include if Applicable)

```sh
conan new testbug/1.0.0
conan export .
conan download testbug/1.0.0@_/_ --remote conancenter  # this will delete the recipe from the local cache, since testbug/1.0.0 does not exist on conancenter
conan inspect testbug/1.0.0   # does not find the testbug/1.0.0 package recipe
```

If you use `export-pkg` then the package folder will remain in the cache after `download`
user: iaavo
issue_11899: state: open
title: [feature] conan2 build tool specific recipe
body: The simplest cmake recipe has over 40 lines of code. 
This is a newly created recipe:
```python
from conan import ConanFile
from conan.tools.cmake import CMakeToolchain, CMake, cmake_layout


class helloRecipe(ConanFile):
    name = "hello"
    version = "1.0.0"

    # Optional metadata
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of hello package here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}

    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "CMakeLists.txt", "src/*", "include/*"

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()

    def package_info(self):
        self.cpp_info.libs = ["hello"]
```

Is it possible to have and inherit `CMakeConanFile` instead of `ConanFile`  which will have default `config_options`, `layout`, `generate`, `build` & `package` methods? `package_info` can be also auto generated if #11897 is implemented.

This way most of the CMake recipes will be reduced to :
```python
from conan import CMakeConanFile


class helloRecipe(CMakeConanFile):
    name = "hello"
    version = "1.0.0"

    # Optional metadata
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of hello package here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}

    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "CMakeLists.txt", "src/*", "include/*"
```

Of course if someone needs to customize any of the steps, will need to override that particular method :
```python
from conan import CMakeConanFile


class helloRecipe(CMakeConanFile):
....
    # Sources are located in the same place as this recipe, copy them to the recipe
    exports_sources = "CMakeLists.txt", "src/*", "include/*"

    # customize generate method
    def generate(self):
        tc = CMakeToolchain(self)
        if self.options.with_fmt:
            tc.variables["WITH_FMT"] = True
        tc.generate()
```


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: bog-dan-ro
issue_11897: state: open
title: [feature] conan2 Use cmake-file-api to get all the project targets info?
body: In conan 1.x cmake projects with multiple targets are not very easy/nice to write recipes for (check vorbis, mpg123, etc.).
It will be great if conan 2 can use [cmake-file-api](https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html) to get all the info for that project.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: bog-dan-ro
issue_11885: state: open
title: [question (bug?)] How to use Conan center packages in a multi-config environment (Visual Studio)
body: **Minimal example**: https://github.com/Adnn/issue_conan-11885

## What we are trying

* Conan 1.51.1
* Windows 10
* CMake 3.23.2
* Visual Studio 2019

We are using the modern CMake generators, , in our `conan/conanfile.py`:

    generators = "CMakeDeps", "CMakeToolchain"

We are following the instruction from [CMakeToolchain](https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmaketoolchain.html#using-the-toolchain-in-developer-flow) to configure a multiconfig build environment. This results in the following commands:

```
conan install conan/
conan install conan/ -s build_type=Debug

conan build conan/
# This next one fails, because the debug build of the upstream lib is found first.
cd build && cmake --build . --config Release
```


## The issue

We would expect it to configure the VS target to link against the Debug (resp. Release) package of the library in the Debug (resp. Release) configuration.

Yet, we observe that both IDE configurations actually have both path (to both Debug and Release packages) configured under `Linker > Input > Additional Dependencies`.

e.g. with spdlog:

![image](https://user-images.githubusercontent.com/3911163/184894673-41acfdb8-79a0-4fab-a29a-13755743e0b5.png)


This leads to the first path always being picked up, only allowing on configuration to successfully link (because of the `_ITERATOR_DEBUG_LEVEL` system of MSVC runtime).

## The questions

* Can we fix our use of Conan to actually get a working multi-config VS solution?
* Is this a bug in Conan/the packages recipe?
  (We tried a few different recipes from Conan center, and most of them had the same problem).

user: Adnn
issue_11877: state: open
title: [bug] "PermissionError: [Errno 13] Permission denied" on windows platform
body: 

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows
  * Compiler+version:
  * Conan version: 1.48.2
  * Python version: 2.7.17rc1

### Steps to reproduce (Include if Applicable)
cannot reproduce, only appear 2 times

### Logs (Executed commands with output) (Include/Attach if Applicable)
when run "conan install .. --build=outdated",
after download several packages, it will failed with following error message: 
`ERROR: videoconf/0.0.1@user/channel: Error in package() method, line 30
        self.copy("*")
        PermissionError: [Errno 13] Permission denied: 'C:\\Users\\l366901\\.conan\\data\\videoconf\\0.0.1\\user\\channel\\build\\646b4443d8c3d67ac7dd2cad293a745d9b3e7baa\\videoconf.zip'`

yes, in package() method, only one line code,
`self.copy("*")`

after it failed, i can rerun install command for lots time, and each time it will raise a same error but for a different package. and the above package is successfully processed.

So the question is why it is appeared, and how to solve it.
user: initlifeinc
issue_11866: state: open
title: [feature] `conan.tools.microsoft`: add an helper to fix msvc static & import libs name/ext
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Meson has made a surprising choice to add lib prefix and .a extension to static libs for msvc. See https://github.com/mesonbuild/meson/issues/7378

Therefore static libs must be renamed from `libfoo.a` to `foo.lib` after installation if compiler is msvc. A function fixing these libs and exposed in `conan.tools.microsoft` would be very helpful (I believe it's a better location than `conan.tools.meson` since it can also be used for msvc libs built with autotools, quite unusual but there are few examples of such libs in CCI like `coin-*` recipes).

Possible implementation here: https://github.com/conan-io/conan-center-index/blob/572a2e775f92253d7b440c78aba47d5e3fe4a89a/recipes/serd/all/conanfile.py#L97-L110

Something more generic could be implemented (it should handle most msvc libname issues with autotools & meson):
- automatically change extension from `.a`/`.dll.lib`/`.dll.a` to `.lib`
- remove `lib` prefix optionally (I guess one may want to disable this behavior in the very unusual situation where the name should really begin by lib for msvc).

```python
from conan.tools.files import rename
from conan.tools.microsoft import is_msvc
import glob
import os

def fix_msvc_libnames(conanfile, remove_lib_prefix=True):
    """change extension of msvc static & import libs to .lib & remove lib prefix"""
    if not is_msvc(conanfile):
        return
    libdirs = getattr(conanfile.cpp.package, "libdirs")
    for libdir in libdirs:
        for ext in [".dll.a", ".dll.lib", ".a"]:
            full_folder = os.path.join(conanfile.package_folder, libdir)
            for filepath in glob.glob(os.path.join(full_folder, f"*{ext}")):
                libname = os.path.basename(filepath)[0:-len(ext)]
                if remove_lib_prefix and libname[0:3] == "lib":
                    libname = libname[3:]
                rename(conanfile, filepath, os.path.join(os.path.dirname(filepath), f"{libname}.lib"))
```
user: SpaceIm
issue_11864: state: open
title: [question] capture cmake commandline options?
body: Hi,
I have a task that for a project, which defines its conanfile.py properly, the primary entrypoint for development should be its CMakeLists.txt so that it can still ve developed via Visual Studio or VA Code.
The idea is to inject manually everything in a CMAKE_PROJECT_INCLUDE_BEFORE, how Conan would do for cmake build —configure (that obviously still means I must provide some minimal set of CMake variables, like Conan profile, build type, etc.)
That would make it possible to setup CMAKE_TOOLCHAIN_FILE at least.
then, after the project() call is finished, I can do a conan install in CMake configure time, then the build could continue “normally”.
Is there a way to capture all CMake parameters that would be provided to CMake when conan build —configure is executed?
Thanks,
user: harsszegi
issue_11863: state: open
title: [bug] Cross compiling with MinGW fails
body: When cross compiling from Linux to Windows using MinGw Conan tries to use `cmake -G "MinGW Makefiles"` but CMake MinGW generator isn't available on Linux.

It worked fine until yesterday (12/8/2022).

### Environment Details (include every applicable attribute)
  * Operating System+version: Manjaro Linux, Ubuntu 22.04
  * Compiler+version: MinGW GCC 12.1, MinGW GCC 10
  * Conan version: 1.51.2, 1.50.0, 1.47.0
  * Python version: 3.10.5, 3.10.4

### Steps to reproduce (Include if Applicable)
add MinGW profile:
```
toolchain=/usr/x86_64-w64-mingw32 # Adjust this path
target_host=x86_64-w64-mingw32
cc_compiler=gcc
cxx_compiler=g++

[env]
CONAN_CMAKE_FIND_ROOT_PATH=$toolchain  # Optional, for CMake to find things in that folder
CONAN_CMAKE_SYSROOT=$toolchain  # Optional, if we want to define sysroot
CHOST=$target_host
AR=$target_host-ar
AS=$target_host-as
RANLIB=$target_host-ranlib
CC=$target_host-$cc_compiler
CXX=$target_host-$cxx_compiler
STRIP=$target_host-strip
RC=$target_host-windres

[settings]
# We are cross-building to Windows
os=Windows
arch=x86_64
compiler=gcc

# Adjust to the gcc version of your MinGW package
compiler.version=11
compiler.libcxx=libstdc++11
build_type=Release
```

create conanfile.txt with a package that fails

libraries that fail to build (for me `fmt`, `glfw` and `boost` failed):
```
[requires]
fmt/9.0.0
```

try `conan install` it with the MinGW profile:
`conan install . --build=outdated -pr=mingw`

get the following error:
```
Configuration:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11
os=Windows
[options]
[build_requires]
[env]
AR=x86_64-w64-mingw32-ar
AS=x86_64-w64-mingw32-as
CC=x86_64-w64-mingw32-gcc
CHOST=x86_64-w64-mingw32
CONAN_CMAKE_FIND_ROOT_PATH=/usr/x86_64-w64-mingw32 # Adjust this path  # Optional, for CMake to find things in that folder
CONAN_CMAKE_SYSROOT=/usr/x86_64-w64-mingw32 # Adjust this path  # Optional, if we want to define sysroot
CXX=x86_64-w64-mingw32-g++
RANLIB=x86_64-w64-mingw32-ranlib
RC=x86_64-w64-mingw32-windres
STRIP=x86_64-w64-mingw32-strip
fmt/9.0.0: WARN: Package binary is corrupted, removing: a054a3505f46390899b536d8af712e4a80b781a7
conanfile.txt: Installing package
Requirements
    fmt/9.0.0 from 'conancenter' - Cache
Packages
    fmt/9.0.0:a054a3505f46390899b536d8af712e4a80b781a7 - Build

Cross-build from 'Linux:x86_64' to 'Windows:x86_64'
Installing (downloading, building) binaries...
fmt/9.0.0: WARN: Build folder is dirty, removing it: /home/vm/.conan/data/fmt/9.0.0/_/_/build/a054a3505f46390899b536d8af712e4a80b781a7
fmt/9.0.0: Copying sources to build folder
fmt/9.0.0: Building your package in /home/vm/.conan/data/fmt/9.0.0/_/_/build/a054a3505f46390899b536d8af712e4a80b781a7
fmt/9.0.0: Generator txt created conanbuildinfo.txt
fmt/9.0.0: Calling generate()
fmt/9.0.0: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
fmt/9.0.0: Aggregating env generators
fmt/9.0.0: Calling build()
fmt/9.0.0: CMake command: cmake -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/vm/.conan/data/fmt/9.0.0/_/_/build/a054a3505f46390899b536d8af712e4a80b781a7/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/vm/.conan/data/fmt/9.0.0/_/_/package/a054a3505f46390899b536d8af712e4a80b781a7" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" -DFMT_DOC="False" -DFMT_TEST="False" -DFMT_INSTALL="True" -DFMT_LIB_DIR="lib" -DFMT_OS="True" "/home/vm/.conan/data/fmt/9.0.0/_/_/build/a054a3505f46390899b536d8af712e4a80b781a7/."
CMake Error: Could not create named generator MinGW Makefiles

Generators
  Green Hills MULTI            = Generates Green Hills MULTI files
                                 (experimental, work-in-progress).
* Unix Makefiles               = Generates standard UNIX makefiles.
  Ninja                        = Generates build.ninja files.
  Ninja Multi-Config           = Generates build-<Config>.ninja files.
  Watcom WMake                 = Generates Watcom WMake makefiles.
  CodeBlocks - Ninja           = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - Ninja             = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
  Kate - Ninja                 = Generates Kate project files.
  Kate - Unix Makefiles        = Generates Kate project files.
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files.

fmt/9.0.0: 
fmt/9.0.0: ERROR: Package 'a054a3505f46390899b536d8af712e4a80b781a7' build failed
fmt/9.0.0: WARN: Build folder /home/vm/.conan/data/fmt/9.0.0/_/_/build/a054a3505f46390899b536d8af712e4a80b781a7/build/Release
ERROR: fmt/9.0.0: Error in build() method, line 89
	cmake.configure(variables=cache_entries)
	ConanException: Error 1 while executing cmake -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/vm/.conan/data/fmt/9.0.0/_/_/build/a054a3505f46390899b536d8af712e4a80b781a7/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/vm/.conan/data/fmt/9.0.0/_/_/package/a054a3505f46390899b536d8af712e4a80b781a7" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" -DFMT_DOC="False" -DFMT_TEST="False" -DFMT_INSTALL="True" -DFMT_LIB_DIR="lib" -DFMT_OS="True" "/home/vm/.conan/data/fmt/9.0.0/_/_/build/a054a3505f46390899b536d8af712e4a80b781a7/."
```
user: Enhex
issue_11853: state: open
title: [question] CMakeDeps: why True/False options are translated to CACHE STRING variables and not CACHE BOOL?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Let's consider a recipe like this:

```python
from conan import ConanFile
from conan.tools.cmake import CMake, CMakeToolchain


class FooConan(ConanFile):
    (...)

    options = {
        bar: [True, False],
    }
    default_options = {
        bar: True,
    }

    (...)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.variables["OPTION1"] = False
        tc.variables["OPTION2"] = self.options.bar
        tc.generate()

    (...)
```

In `conan_toolchain.cmake`, you'll see:

```cmake
set(OPTION1 OFF CACHE BOOL "Variable OPTION1 conan-toolchain defined")
set(OPTION2 "True" CACHE STRING "Variable OPTION2 conan-toolchain defined")
```

Is it intended? Is it robust? Was it deeply tested (various cmake_minimum_required, some if() based on this option in a CMakeLists etc)? I've tested, and if(OPTION2) seems to work fine, but I'm always suspicious with variable expansion in CMake.
user: SpaceIm
issue_11847: state: open
title: [bug] Using 'conan build --configure' with new CMake helper causes cmake --build to be called
body: I noticed when trying out the transition between CMake helpers, that the `--configure` switch to `conan build` was behaving differently, in that the new CMake tooling just carries on after the configure/generation phase into calling `cmake --build`.

The `--configure` flag was used in some example code to stop after an IDE project is generated, since the idea is that the user opens that in the IDE, rather than compiling the project on the command line.

### Environment Details (include every applicable attribute)
  * Operating System+version: Mac (10.14)
  * Compiler+version: Xcode 10.1
  * Conan version: 1.51.1
  * Python version: 3.10

### Steps to reproduce (Include if Applicable)
I've cut down the original reproducible into a simpler gist

https://gist.github.com/foundry-markf/ac831076c782e0e0aaced021904df0b5

Running the runme.sh bash script, executes the same Conan recipe with different options in order to switch between the two CMake helpers.

I haven't tried this on another OS, but the original much larger sample was behaving the same on a Windows box with VisualStudio generators.

Thanks
user: foundry-markf
issue_11837: state: open
title: [bug] Unable to build librdkafka with ssl enabled
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: Visual Studios 16
  * Conan version: 1.51.0
  * Python version: 3.8.2

### Steps to reproduce (Include if Applicable)
Tried to run conan install for librdkafka with ssl set to true

### Logs (Executed commands with output) (Include/Attach if Applicable)

#### Ran following command:
```
conan install librdkafka/1.9.1@ -b missing -o librdkafka:shared=True -o librdkafka:ssl=True -s arch="x86_64" -s os="Windows" -s compiler="Visual Studio" -s compiler.version="16" -g cmake_find_package_multi
```
#### Output from cmd:
```
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pow in m
-- Looking for pow in m - not found
-- Conan: Component target declared 'OpenSSL::Crypto'
-- Conan: Component target declared 'OpenSSL::SSL'
-- Conan: Target declared 'openssl::openssl'
-- Conan: Including build module from 'C:/Users/fier/.conan/data/openssl/1.1.1q/_/_/package/3fb49604f9c2f729b85ba3115852006824e72cab/lib/cmake/conan-official-openssl-variables.cmake'
-- Conan: Target declared 'lz4::lz4'
CMake Error at C:/Users/fier/.conan/data/librdkafka/1.9.1/_/_/build/16183fde105329734d46ba91f26e87d28093f078/build/generators/OpenSSL-Target-release.cmake:119 (target_link_libraries):
  Cannot specify link libraries for target "openssl::openssl" which is not
  built by this project.
Call Stack (most recent call first):
  C:/Users/fier/.conan/data/librdkafka/1.9.1/_/_/build/16183fde105329734d46ba91f26e87d28093f078/build/generators/OpenSSLTargets.cmake:26 (include)
  C:/Users/fier/.conan/data/librdkafka/1.9.1/_/_/build/16183fde105329734d46ba91f26e87d28093f078/build/generators/OpenSSLConfig.cmake:10 (include)
  src/CMakeLists.txt:222 (find_package)


-- Configuring incomplete, errors occurred!
See also "C:/Users/fier/.conan/data/librdkafka/1.9.1/_/_/build/16183fde105329734d46ba91f26e87d28093f078/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/fier/.conan/data/librdkafka/1.9.1/_/_/build/16183fde105329734d46ba91f26e87d28093f078/build/CMakeFiles/CMakeError.log".
librdkafka/1.9.1:
librdkafka/1.9.1: ERROR: Package '16183fde105329734d46ba91f26e87d28093f078' build failed
librdkafka/1.9.1: WARN: Build folder C:\Users\fier\.conan\data\librdkafka\1.9.1\_\_\build\16183fde105329734d46ba91f26e87d28093f078\build
ERROR: librdkafka/1.9.1: Error in build() method, line 123
        cmake.configure()
        ConanException: Error 1 while executing cmake -G "Visual Studio 16 2019" -DCMAKE_TOOLCHAIN_FILE="C:/Users/fier/.conan/data/librdkafka/1.9.1/_/_/build/16183fde105329734d46ba91f26e87d28093f078/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/fier/.conan/data/librdkafka/1.9.1/_/_/package/16183fde105329734d46ba91f26e87d28093f078" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "C:\Users\fier\.conan\data\librdkafka\1.9.1\_\_\build\16183fde105329734d46ba91f26e87d28093f078\src"
```
#### CMakeError.log
```
Determining if the function pow exists in the m failed with the following output:
Change Dir: C:/Users/fier/.conan/data/librdkafka/1.9.1/_/_/build/16183fde105329734d46ba91f26e87d28093f078/build/CMakeFiles/CMakeTmp

Run Build Command(s):C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe cmTC_d874a.vcxproj /p:Configuration=Debug /p:Platform=x64 /p:VisualStudioVersion=16.0 /v:m && Microsoft (R) Build Engine version 16.11.2+f32259642 for .NET Framework

Copyright (C) Microsoft Corporation. All rights reserved.



  Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30141 for x64

  Copyright (C) Microsoft Corporation.  All rights reserved.

  cl /c /Zi /W3 /WX- /diagnostics:column /MP20 /Od /Ob0 /D _MBCS /D WIN32 /D _WINDOWS /D CHECK_FUNCTION_EXISTS=pow /D "CMAKE_INTDIR=\"Debug\"" /Gm- /RTC1 /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_d874a.dir\Debug\\" /Fd"cmTC_d874a.dir\Debug\vc142.pdb" /external:W3 /Gd /TC /errorReport:queue "C:\Program Files\CMake\share\cmake-3.24\Modules\CheckFunctionExists.c"

  CheckFunctionExists.c

LINK : fatal error LNK1104: cannot open file 'm.lib' [C:\Users\fier\.conan\data\librdkafka\1.9.1\_\_\build\16183fde105329734d46ba91f26e87d28093f078\build\CMakeFiles\CMakeTmp\cmTC_d874a.vcxproj]
```
Not sure if this is a bug with librdkafka or if there's something else I'm missing

user: fierdr
issue_11833: state: open
title: [question] Distinguish between conan install and conan create
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Is it somehow possible if the conanfile is invoked by a `conan install` command or a `conan create` command?

I would like to use the distinction to decide if it is a developer environment, where the dependencies are installed or the package creation and than, for example, change some configurations.

Specifically, I would like to read a file which is located inside the project.
If I do a `conan install`, the file lies next to to the `conanfile.py`. But if I do a `conan create`, the file lies in the folder `export_sources` and the `conanfile.py` is inside `export`.


```py
def configuration(self):
   config = read_file_in_project_folder(PATH_TO_FILE)
   # ...
```
user: Viatorus
issue_11832: state: open
title: [bug] `conan install` does not honor `config_options`
body: The behavior between `conan create` and `conan install` are not the same and the later is not behaving like described within the documentation.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: MSVC 2019
  * Conan version: latest (1.51.1)
  * Python version: 3.10.2

### Steps to reproduce

Define conanfile.py:
```python
from conans import ConanFile

class DemoConan(ConanFile):
    name = "demo"
    version = "1.0.0"
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC
```

Execute once
```bash
conan create . -o fPIC=True
```
and once
```bash
conan install . -o fPIC=True
```

In the first case, Conan raise an error as documented [here](https://docs.conan.io/en/latest/reference/conanfile/methods.html?highlight=config_options#configure-config-options):
```bash
ERROR: demo/1.0.0: option 'fPIC' doesn't exist
Possible options are ['shared']
```

Instead, in the case of `conan install`, Conan doesn't raise any error. For some reasons, conan doesn't seem to honor the `conifig_options`. This can be confirmed by executing `conan install` with an invalid option:
```bash
conan install . -o foo=True

ERROR: conanfile.py: option 'foo' doesn't exist
Possible options are ['shared', 'fPIC']
```

user: lucabonifacio
labels: component: ux: No changes to core business logic
component: Conan 1.x: Affects only to Conan 1.x
issue_11829: state: open
title: [bug] centos9: package manager detected as "yum", but should be "dnf
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->


  * Operating System+version: Centos 9 Stream
  * Compiler+version: GCC 11.3
  * Conan version: 1.50.0
  * Python version: 3.9.13

 In /usr/local/lib/python3.9/site-packages/conans/client/tools/oss.py:
```
    @property
    def with_yum(self):
        return self.is_linux and self.linux_distro in ("pidora", "fedora", "scientific", "centos",
                                                       "redhat", "rhel", "xenserver", "amazon",
                                                       "oracle", "amzn", "almalinux", "rocky")

    @property
    def with_dnf(self):
        return self.is_linux and self.linux_distro == "fedora" and which('dnf')
```

Centos moved from yum to dnf in some stage, why not just:
```
    @property
    def with_yum(self):
       return self.is_linux and and which('yum')

    @property
    def with_dnf(self):
        return self.is_linux and and which('dnf')
```
### Steps to reproduce (Include if Applicable)
Build any package with "def system_requirements(self):" on Centos9
- It will detect package manager as 'yum' but it not installed

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: huso113
issue_11800: state: open
title: Can not use conan to get boost library because of the conanfile.py of boost.
body: (dev) PS C:\Users\harry> conan inspect boost/1.79.0
ERROR: Error loading conanfile at 'C:\Users\harry\.conan\data\boost\1.79.0\_\_\export\conanfile.py': Unable to load conanfile in C:\Users\harry\.conan\data\boost\1.79.0\_\_\export\conanfile.py
  File "C:\Users\harry\Anaconda3\envs\dev\lib\imp.py", line 172, in load_source
    module = _load(spec)
  File "<frozen importlib._bootstrap>", line 719, in _load
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "C:\Users\harry\.conan\data\boost\1.79.0\_\_\export\conanfile.py", line 2, in <module>
    from conan.tools.files import rename, rmdir, get
ImportError: cannot import name 'rmdir' from 'conan.tools.files' (C:\Users\harry\Anaconda3\envs\dev\lib\site-packages\conan\tools\files\__init__.py)

OS: Windows
Conan: x86_64.exe  
Conan Version: 1.48  

user: fancygit
issue_11769: state: open
title: [question] Is it a good idea to move POLICY required by conan toolchain logic in CMake presets?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

I've seen this PR https://github.com/conan-io/conan/pull/11098

Is it a good idea? I mean, presets are a 3.19 feature, but conan toolchain is supposed to support CMake >= 3.15.

If you have a build fully managed by conan, and CMake 3.15 is installed, how CMake helper can fallback to not using presets (because I guess the new CMake helper automatically injects generated presets, otherwise it's broken from what I understand), and therefore properly handle policies? (EDIT: ok for this case I see that CMake helper also injects the policy in command line)

In case of a build not managed by conan (for example a simple conanfile.txt just for dependency management), is it a good experience for users to have to manage these policies themselves if presets are not used?
user: SpaceIm
issue_11768: state: open
title: [question] Consuming/exporting libraries build using conan outside of conan
body: Hi 

We have started using conan to manage dependencies in a two C++ projects. One that creates a library and another one to consume it (along with other libraries; gtest for instance). The library is shared through our in-house artifactory repository. That is in good working order, but what I have not been able to piece together is how to consume or export the package to be consumed outside of conan. 
The specific usecase is that I need the library to be part of a java project (build using gradle), where we need two native libraries (one build for windows, another for linux). I would very much like to be able to fetch the pre-build libraries from artifactory as a dependency for the java project. 
So is there a way to consume the packages either directly from artifactory, or how can I "export" a package from my conan build? I've looked a bit at the 'deploy' generator but I can't get a clear picture if that is a viable way or how to use it. 
Any advise on the above?
user: kingudk
issue_11765: state: open
title: [bug] ignored --source-folder option while using 'conan build ...' command with CMakeToolchain and cmake_layout
body: In package development flow using the  `conan build ...` command, I get an error with the CMakeToolchain configure method, because the --source-folder option is ignored.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: Visual Studio 16
  * Conan version: 1.51.0
  * Python version: 3.9.13

### Steps to reproduce (Include if Applicable)
I can reproduce the issue using the fmt recipe written for 2.0 conan here: [recipe ](https://github.com/czoido/conan-center-index/tree/master/recipes/fmt/all)

1. `cd` to the fmt recipe folder
2. use those package development flow commands:
```sh
conan install . fmt/9.0.0@user/channel --install-folder out --output-folder out
conan source . --install-folder out --source-folder out/source
conan build . --source-folder out/source --build-folder out
```

The `conan build ...` command will fail because the CMake configure command will always use the conan recipe folder as source folder and not the one specified in the command line.

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
Using lockfile: 'C:\Users\t.odorico\Downloads\conan_test\conan-center-index\recipes\fmt\all\out/conan.lock'
Using cached profile from lockfile
conanfile.py (fmt/9.0.0@user/channel): Calling build()
conanfile.py (fmt/9.0.0@user/channel): CMake command: cmake -G "Visual Studio 16 2019" -DCMAKE_TOOLCHAIN_FILE="C:/Users/t.odorico/Downloads/conan_test/conan-center-index/recipes/fmt/all/out/build/generators/conan_toolchain.cmake" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DFMT_DOC="False" -DFMT_TEST="False" -DFMT_INSTALL="True" -DFMT_LIB_DIR="lib" -DFMT_OS="True" "C:\Users\t.odorico\Downloads\conan_test\conan-center-index\recipes\fmt\all\."
CMake Warning:
  Ignoring extra path from command line:

   "C:\Users\t.odorico\Downloads\conan_test\conan-center-index\recipes\fmt\all\."


CMake Error: The source directory "C:/Users/t.odorico/Downloads/conan_test/conan-center-index/recipes/fmt/all" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
ERROR: conanfile.py (fmt/9.0.0@user/channel): Error in build() method, line 85
        cmake.configure(variables=cache_entries)
        ConanException: Error 1 while executing cmake -G "Visual Studio 16 2019" -DCMAKE_TOOLCHAIN_FILE="C:/Users/t.odorico/Downloads/conan_test/conan-center-index/recipes/fmt/all/out/build/generators/conan_toolchain.cmake" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DFMT_DOC="False" -DFMT_TEST="False" -DFMT_INSTALL="True" -DFMT_LIB_DIR="lib" -DFMT_OS="True" "C:\Users\t.odorico\Downloads\conan_test\conan-center-index\recipes\fmt\all\."
```
user: todorico
issue_11762: state: open
title: [bug] Using a version range with conan install -u leads to an error in case of empty package cache
body: I am having an empty Conan package cache resp. the package I want to install is not available in the local package cache.
When I now type in 

`conan install pkgname/[^3.0.0]@ci/stable -o ... -o ... -u
`

I get following error message: 

`ERROR: Version range '^3.0.0' from requirement 'pkgname/[^3.0.0]@ci/stable' required by 'virtual' could not be resolved in local cache
`
Looking at the official docs of the -u option this behavior to me seems like a bug since it says that the remote is checked for the newest version matching the version range.

I am using Conan version 1.49

PS. When I leave out the -u it is working in case a version range matching package is available in the first remote from my configured list of remotes.
user: MTomBosch
issue_11761: state: open
title: Conflict for library libiconv requested by both libarchive and boost
body: <!-- What is your question? Please be as specific as possible! -->

Hi, I'm using Conan for fetching some 3rd party libraries into my project. amongst are boost and libarchive. Recently, I've advanced the version of those 2 libraries in Conan.txt, and now getting the following error.

```
ERROR: Conflict in libarchive/3.6.1:
    'libarchive/3.6.1' requires 'libiconv/1.17' while 'boost/1.79.0' requires 'libiconv/1.16'.
    To fix this conflict you need to override the package 'libiconv' in your root package.
```

 Perhaps anyone can explain me how exactly should I resolve this conflict... I understand that both libraries have libiconv as dependency but with different version - but there must be a way to have different version of libiconv on the same target, right? 


I'm using Conan cmake API in the following way : 
```
  conan_cmake_configure(
    REQUIRES
    boost/1.79.0
    libarchive/3.6.1
    GENERATORS
    cmake_find_package)

conan_cmake_autodetect(settings)

    PATH_OR_REFERENCE
    .
    BUILD
    missing
    REMOTE
    conancenter
    SETTINGS
    ${settings})
```


- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: iradization
issue_11750: state: open
title: How can I make the CMakeDeps generator generate a CMake target for an executable?
body: I have a CMake project and in the CMakeLists.txt file I generate two targets: **add_library(myproj::mylib ...)** and **add_executable(myproj::myexec ...)**. The Conan documentation explains well what to write in the **package_info()** method in the **conanfile.py** file to have Conan generate a CMake target for **myproj::mylib** but how can I have Conan generate the CMake target **myproj::myexec**? I want to create a Conan package for **myproj** and consume it in another project. In the other project, I want to reference the executable via its target name **myproj::myexec**. For example:
```
# CMakeLists.txt
find_package(myproj REQUIRED)
add_custom_command(OUTPUT ${SOME_OUTPUT} COMMAND myproj::myexec ARGS ...)
```

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: betheev
issue_11735: state: open
title: [bug] Misleading error messages with permissions issues in virtual repositories
body: I have a virtual repository which passes through to one local and one remote repository. There have been a few times where I get baffling error messages due to permissions issues. 

- I was trying to download a recipe. I would list the available recipes and it would show as available. But when i tried to download it it would say it didn't exist. I think the issue was that the latest recipe wasn't in the remote cache, and the user had only read permissions. Pulling it would add it to the cache, thereby altering the cache...so it denied it. That's my guess at least.
- I had similar things where the permissions were ok on the virtual repository itself, but maybe not on of the constituent repositories, with similar results...an error message saying the recipe didn't exist etc.

I apologize that I don't have a detailed reproduction, but hopefully this is enough to go on.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: rconde01
issue_11722: state: open
title: [feature] Allowing a per-local-cache user declaration of compiler compatibility for all dependents
body: Hi,

This proposal is to satisfy two points of view, discussed between myself and @FnGyula in our products usage of Conan, against a large set of dependent packages (that we maintain).

We follow guidelines in our industry to maximise compatibility in the domain, which often requires a compiler change (across 3 desktop platforms) every year. We are aiming at reducing the initial up-front-cost of trying out new compiler versions in product, without needing a whole library stack rebuild at the same time. Currently, we set the `compiler.version` back in profiles for any dependent that has not been rebuilt, but it is an effort that is then undone when rebuilds eventually occur.

The short of it is to allow users to declare compiler compatibility, per local cache, for dependent packages, without needing to modify any recipes.

## First pov
The main idea here is to avoid the catch22 with compatible packages:
1. You have a recipe
2. Have a new compiler
3. See that it is compatible
4. If I update the recipe to add it as a compatible compiler, change the recipe for the package_id
5. Now I have no binary for that new revision and might as well build it against the new compiler all the same

## Second pov
A generalisation of the existing Intel compiler compatibility with GCC versions, in the global user-space to decide on what they're comfortable with, in order to provide fallbacks for dependent packages while upgrading a product's choice of compiler version.

I have a proof of concept proposal, including an integration test, that I will link to this in a PR shortly.

We have this in mind for Conan 1.x+

- [x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: foundry-markf
issue_11718: state: open
title: Did version_range resolving get error answer?
body: Hi all, feel lucky to use Conan(version 1.38.0) such a good tool to manage my C++ library and APP. 
But I got some problem these day.

I am building an APP, and there are three Conan packages used for this APP, called lib_C, lib_E, lib_D. 
lib_C is depend on the lib_E and lib_D, and the conanfile.py of lib_C is below, where I use version_range to manage the library:
```
from conans import ConanFile, tools
import os


class PackageConan(ConanFile):
  settings = ()

  revision_mode = "scm"
  scm = {
        "type": "git",
        "url": "xxx/lib_C",
        "revision": "auto"
  }
  url = 'xxx/lib_C'

  license = 'aaa'
  description = 'bbb'
  settings = 'os', 'compiler', 'build_type', 'arch'
  generators = 'cmake'

  requires = ("lib_D/[0.0.0> <0.1.0]@lzh/stable",
              "lib_E/[0.1.0>= <0.2.0]@lzh/stable")

  build_requires = ()

  def imports(self):
    pass

  def package(self):
    source_dir = os.environ.get('PACKAGE_SOURCE_DIR')
    build_dir = os.environ.get('PACKAGE_BUILD_DIR')
    install_dir = os.environ.get('PACKAGE_INSTALL_DIR')
    self.copy('*',
              dst='include',
              src='{}/include'.format(install_dir),
              symlinks=True)
    self.copy('*', dst='lib', src='{}/lib'.format(install_dir), symlinks=True)

  def package_id(self):
    self.info.requires.minor_mode()

  def package_info(self):
    self.cpp_info.libs = tools.collect_libs(self)
```

And there are two Conan remotes in my system, called them conan-stable, conan-dev (the priority of conan-stable is higher than conan-dev). And the available version of lib_E in conan-stable is such below:
![image](https://user-images.githubusercontent.com/18378815/181442872-ae7d91b8-69f2-452d-9497-0e539b5cbf9f.png)

however, in conan-dev is:
![image](https://user-images.githubusercontent.com/18378815/181443002-97733a1d-9fde-4621-a174-33da0e70e5f8.png)


Based on the environment, I am creating the lockfile of lib_C, and expect to get the 0.1.0 version of lib_E in the lockfile，but when I run the command：
```
conan lock create conanfile.py --lockfile-out=dep_base.lock --update --base
```
the output of this command is below:
<img width="834" alt="image" src="https://user-images.githubusercontent.com/18378815/181428442-bd2740b5-1357-46f4-8c57-a05cbdb61902.png">

As you can see from this picture, Conan only try to solve version from conan-stable, but not conan-dev, thus got a wrong version of lib_E which should be 0.1.0. And, in my opinion, it should search from conan-dev, since there is not any version in conan-stable satisfy the range [0.1.0>= <0.2.0].
But if I change the require from "lib_E/[0.1.0>= <0.2.0]@lzh/stable" to "lib_E/0.1.0@lzh/stable", it works well.

Is there some mistake in my project or Conan?




user: liao-zhihan
issue_11713: state: open
title: WIP: [autotools / gnu tools] use "-l:" for static libraries
body: attempt to solve issue #11703 - tested with gcc and ld on Ubuntu and a Yocto variant

This PR is WIP:

* TODO: detect that the linker 'ld' is the one in use

Changelog: (Feature | Fix | Bugfix): Describe here your pull request
Docs: https://github.com/conan-io/docs/pull/XXXX

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ ] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 

<sup>**Note:** By default this PR will skip the slower tests and will use a limited set of python versions. Check [here](https://github.com/conan-io/conan/blob/develop/.github/PR_INCREASE_TESTING.md) how to increase the testing level by writing some tags in the current PR body text.</sup>

user: jngrb
issue_11703: state: open
title: [bug] LIBS variable not correct for linking static libraries when building with autoconf tools
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version: gcc-9
  * Conan version: conan 1.47.0
  * Python version: Python 3.8.10

### Steps to reproduce (Include if Applicable)
1. create a dummy conanfile.py for wrapping a static library, e.g. to wrap `/usr/lib/x86_64-linux-gnu/libcrypto.a`, use this package_info method:

```
  def package_info(self):
    self.cpp_info.libdirs = ["/usr/lib/x86_64-linux-gnu"]
    self.cpp_info.libs = ["libcrypto.a"]
```

2. have a second recipe that consumes the dummy recipe and builds a executable or library with autotools. Excerpts from such a conanfile.py:

```
from conans import ConanFile, AutoToolsBuildEnvironment
[...]
  def build(self)
    [...]
    autotools = AutoToolsBuildEnvironment(self, win_bash=tools.os_info.is_windows)
    configure_args = [...]
    autotools.configure(vars=self._autotools_vars, args=configure_args)
    [...]
```

### Actual behaviour

autotools / configure is called with environment variable

```
LIBS=-llibcrypto.a
```

### Expected behaviour

autotools / configure is called with environment variable

```
LIBS=-l:libcrypto.a
```

References:
* see <https://stackoverflow.com/questions/6578484/telling-gcc-directly-to-link-a-library-statically>
* and <https://sourceware.org/binutils/docs/ld/Options.html>

> -l _namespec_: [...] If _namespec_ is of the form _:filename_, ld will search the library path for a file called _filename_, otherwise it will search the library path for a file called _libnamespec.a_ [or _libnamespec.so].

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

I found the relevant python methods to be these:

* [conans/client/build/compiler_flags.py#L244](https://github.com/conan-io/conan/blob/release/1.50/conans/client/build/compiler_flags.py#L244)
* [conan/tools/gnu/gnudeps_flags.py#L73](https://github.com/conan-io/conan/blob/release/1.50/conan/tools/gnu/gnudeps_flags.py#L73)

user: jngrb
issue_11697: state: open
title: [bug] conan-script.py fails because of unicode character in python shebang
body: In `C:\Users\UserWithé\AppData\Local\Programs\Python\Python310\Scripts`, `conan-script.py` seems to be missing a `# -*- encoding: utf-8 -*-` at the top of the file. The shebang that gives the path to the python interpreter looks like this `#!C:\Users\UserWith�\AppData\Local\Programs\Python\Python310\python.exe`.

Without it, I got a "SyntaxError: Non-UTF-8 code starting with '\x91'" error when running conan, because my username has an accent in it.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows Version	10.0.19044 Build 19044
  * Compiler+version:  MSVC 19.29.30145.0 Visual Studio 16 2019
  * Conan version:1.50.0
  * Python version: Python 3.10.5

### Steps to reproduce (Include if Applicable)
1. `conan`

### Logs (Executed commands with output) (Include/Attach if Applicable)

`"failed to create process."`

or `SyntaxError: Non-UTF-8 code starting with '\x91'`

user: Riuzakiii
issue_11695: state: open
title: Missing binary even though conan search finds it
body:   * Operating System+version: Linux Mint 20.3 Cinnamon
  * Compiler+version: clang version 10.0.0-4ubuntu1 
  * Conan version: 1.50.0
  * Python version: 3.8.10

### Steps to reproduce (Include if Applicable)

1. Running `conan install -pr clang_debug . -if bin/ --update` throws a bunch of missing binaries

### Logs (Executed commands with output) (Include/Attach if Applicable)

Running `conan remote list` returns `conancenter: https://center.conan.io [Verify SSL: True]`

My `clang_debug` profile:
```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=clang
compiler.version=10
compiler.libcxx=libstdc++11
compiler.cppstd=14
build_type=Debug


[env]
CC=/usr/bin/clang
CXX=/usr/bin/clang++
```

My `conanfile.py`:
```
from conans import ConanFile, CMake, tools

class AnalysisConan(ConanFile):
    name = "analysis"
    version = "1.0"
    settings = "os", "compiler", "build_type", "arch"
    generators = "cmake_paths"
    requires = "openimageio/2.3.7.2"#, "libiconv/1.17"
```

Finally, running `conan install -pr clang_debug . -if bin/ --update` prints this out:```
```
Requirements
  ade/0.1.1f from 'conancenter' - Downloaded
  autoconf/2.71 from 'conancenter' - Downloaded
  automake/1.16.5 from 'conancenter' - Downloaded
  boost/1.78.0 from 'conancenter' - Downloaded
  brotli/1.0.9 from 'conancenter' - Downloaded
  bzip2/1.0.8 from 'conancenter' - Downloaded
  eigen/3.3.9 from 'conancenter' - Downloaded
  expat/2.4.8 from 'conancenter' - Downloaded
  ffmpeg/4.4 from 'conancenter' - Downloaded
  flac/1.3.3 from 'conancenter' - Downloaded
  fmt/8.1.1 from 'conancenter' - Downloaded
  freetype/2.11.1 from 'conancenter' - Downloaded
  giflib/5.2.1 from 'conancenter' - Downloaded
  gtk/system from 'conancenter' - Downloaded
  hdf5/1.12.1 from 'conancenter' - Downloaded
  jasper/2.0.33 from 'conancenter' - Downloaded
  jbig/20160605 from 'conancenter' - Downloaded
  lcms/2.13.1 from 'conancenter' - Downloaded
  libalsa/1.2.5.1 from 'conancenter' - Downloaded
  libbacktrace/cci.20210118 from 'conancenter' - Downloaded
  libcap/2.62 from 'conancenter' - Downloaded
  libde265/1.0.8 from 'conancenter' - Downloaded
  libdeflate/1.10 from 'conancenter' - Downloaded
  libfdk_aac/2.0.2 from 'conancenter' - Downloaded
  libffi/3.4.2 from 'conancenter' - Downloaded
  libheif/1.12.0 from 'conancenter' - Downloaded
  libiconv/1.16 from 'conancenter' - Downloaded
  libjpeg/9d from 'conancenter' - Downloaded
  libmp3lame/3.100 from 'conancenter' - Downloaded
  libpng/1.6.37 from 'conancenter' - Downloaded
  libsndfile/1.0.31 from 'conancenter' - Downloaded
  libsquish/1.15 from 'conancenter' - Downloaded
  libtiff/4.3.0 from 'conancenter' - Downloaded
  libtool/2.4.6 from 'conancenter' - Downloaded
  libvpx/1.11.0 from 'conancenter' - Downloaded
  libwebp/1.2.2 from 'conancenter' - Downloaded
  libx264/20191217 from 'conancenter' - Downloaded
  libx265/3.4 from 'conancenter' - Downloaded
  libxml2/2.9.14 from 'conancenter' - Downloaded
  m4/1.4.19 from 'conancenter' - Downloaded
  ogg/1.3.5 from 'conancenter' - Downloaded
  onetbb/2020.3 from 'conancenter' - Downloaded
  opencolorio/2.1.0 from 'conancenter' - Downloaded
  opencv/4.5.5 from 'conancenter' - Downloaded
  openexr/2.5.7 from 'conancenter' - Downloaded
  openh264/2.1.1 from 'conancenter' - Downloaded
  openimageio/2.3.7.2 from 'conancenter' - Downloaded
  openjpeg/2.4.0 from 'conancenter' - Downloaded
  openssl/1.1.1o from 'conancenter' - Downloaded
  opus/1.3.1 from 'conancenter' - Downloaded
  protobuf/3.17.1 from 'conancenter' - Downloaded
  ptex/2.4.0 from 'conancenter' - Downloaded
  pugixml/1.12.1 from 'conancenter' - Downloaded
  pulseaudio/14.2 from 'conancenter' - Downloaded
  pystring/1.1.3 from 'conancenter' - Downloaded
  quirc/1.1 from 'conancenter' - Downloaded
  tsl-robin-map/1.0.1 from 'conancenter' - Downloaded
  vaapi/system from 'conancenter' - Downloaded
  vdpau/system from 'conancenter' - Downloaded
  vorbis/1.3.7 from 'conancenter' - Downloaded
  vulkan-headers/1.3.211.0 from 'conancenter' - Downloaded
  vulkan-loader/1.3.211.0 from 'conancenter' - Downloaded
  wayland/1.20.0 from 'conancenter' - Downloaded
  xorg/system from 'conancenter' - Downloaded
  xz_utils/5.2.5 from 'conancenter' - Downloaded
  yaml-cpp/0.7.0 from 'conancenter' - Downloaded
  zlib/1.2.12 from 'conancenter' - Downloaded
  zstd/1.5.2 from 'conancenter' - Downloaded
Packages
  ade/0.1.1f:4ebd68c7311a450e176e0bb0ffc8882b6abd4482 - Missing
  autoconf/2.71:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
  automake/1.16.5:258f6f05ca54813b3d7180161753df7f9ccf7e1d - Download
  boost/1.78.0:98094246420952eab592f95a5a99a5ed09e779e0 - Missing
  brotli/1.0.9:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Download
  bzip2/1.0.8:23219b68e873594c97b915e5b682fd61d2caca86 - Download
  eigen/3.3.9:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
  expat/2.4.8:f107943344aeffd2190b5bfc9516ac5e5cc868bf - Missing
  ffmpeg/4.4:e8487608a6fabf7b659bb3863cee556ff342972c - Missing
  flac/1.3.3:ddfe5f8d8713ba1b36b7c3abc635963db950901c - Missing
  fmt/8.1.1:518189a70e600f323cfde3a70a65f0d5ab9a10ea - Missing
  freetype/2.11.1:7c81318244ae90ae4401f48c7c35d83cda74da43 - Download
  giflib/5.2.1:aefdae7c0ad92293879899c21309c8e60ecebb8a - Download
  gtk/system:cc5e5ca8b619d2dffaaeae1e4924ae3ce085a8f1 - Download
  hdf5/1.12.1:dd3a266ced3d35b19cdd2afb59db13d30ae8e317 - Missing
  jasper/2.0.33:9847a07ff0c033b774ee63c429cc7a16ab6c40fb - Download
  jbig/20160605:698989beb298914c2b0d0a2f03262b7828bd36d0 - Download
  lcms/2.13.1:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Missing
  libalsa/1.2.5.1:6232605ab953dfc4deeba04ad7936bd6514e4a60 - Download
  libbacktrace/cci.20210118:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Download
  libcap/2.62:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Missing
  libde265/1.0.8:e907ab56da208f9569d10623981804efe8ef4f5c - Missing
  libdeflate/1.10:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Missing
  libfdk_aac/2.0.2:4ebd68c7311a450e176e0bb0ffc8882b6abd4482 - Missing
  libffi/3.4.2:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Download
  libheif/1.12.0:212345031a146b5458db0d0e837d9af95cb840a0 - Missing
  libiconv/1.16:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Download
  libjpeg/9d:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Download
  libmp3lame/3.100:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Download
  libpng/1.6.37:2148596ab5ded67db00344debefc9ccb8060352e - Download
  libsndfile/1.0.31:244e2036694f61c00771f1443b05053e29e20633 - Missing
  libsquish/1.15:4ebd68c7311a450e176e0bb0ffc8882b6abd4482 - Missing
  libtiff/4.3.0:28610262c5ae482418532e6e77118db48b5a933e - Missing
  libtool/2.4.6:99862aff33ecc6b40f05cc525b558780f5db8cac - Download
  libvpx/1.11.0:dcd66243bc948155f4f0f0cfd9360d4127dc8a27 - Missing
  libwebp/1.2.2:a09a552b2ea0e3af4ad938637eef2959778a4bcd - Missing
  libx264/20191217:3b18184b035dfe168837de7d82facd5fc5206fee - Download
  libx265/3.4:b0bb968b1ea177898e2255887164f9da9f588aa0 - Missing
  libxml2/2.9.14:4b8bcfd687ee0cb778b8e59589e8eb34d394d024 - Missing
  m4/1.4.19:cc9f9b2b9f92fc82888026414560bf79d8c3a052 - Download
  ogg/1.3.5:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Missing
  onetbb/2020.3:388975d0e388b930ae8bf7be38463627332429c9 - Missing
  opencolorio/2.1.0:ade379e8d3b2b421dadb5aaf77fd523c5e57a22b - Missing
  opencv/4.5.5:5c50c9a7b4b0c110bebcb940592f772cd954219f - Missing
  openexr/2.5.7:a45ea4b6014968e6e9e934f0f5fa5a467fa981bf - Missing
  openh264/2.1.1:4ebd68c7311a450e176e0bb0ffc8882b6abd4482 - Missing
  openimageio/2.3.7.2:e681cd6c647ab27cc55544cea082bca09b24cffc - Missing
  openjpeg/2.4.0:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Download
  openssl/1.1.1o:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Missing
  opus/1.3.1:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Download
  protobuf/3.17.1:fd5e4281291c630948790ffa396a8e6fbb9f42e6 - Missing
  ptex/2.4.0:a45ea4b6014968e6e9e934f0f5fa5a467fa981bf - Missing
  pugixml/1.12.1:4ebd68c7311a450e176e0bb0ffc8882b6abd4482 - Missing
  pulseaudio/14.2:b77dafbb410dfb4fc4ba4d776142e0a7ffd40d0c - Missing
  pystring/1.1.3:4ebd68c7311a450e176e0bb0ffc8882b6abd4482 - Missing
  quirc/1.1:48e7424851f7e11472debc691fdbbdb7a489b345 - Download
  tsl-robin-map/1.0.1:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
  vaapi/system:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
  vdpau/system:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
  vorbis/1.3.7:28b9c709fc5411042bda7fd6a47ad0d4e620d64d - Download
  vulkan-headers/1.3.211.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
  vulkan-loader/1.3.211.0:883f066ff242e0cc5f79101e485ebcc20a77a422 - Missing
  wayland/1.20.0:491924764982d2a8ce5f0d81f7f49331f933b2ff - Missing
  xorg/system:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Download
  xz_utils/5.2.5:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Download
  yaml-cpp/0.7.0:4ebd68c7311a450e176e0bb0ffc8882b6abd4482 - Missing
  zlib/1.2.12:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9 - Missing
  zstd/1.5.2:62a88ab7bbffda63e0c146e4fe66d5d90b946798 - Missing

Installing (downloading, building) binaries...
ERROR: Missing binary: ade/0.1.1f:4ebd68c7311a450e176e0bb0ffc8882b6abd4482
ERROR: Missing binary: boost/1.78.0:98094246420952eab592f95a5a99a5ed09e779e0
ERROR: Missing binary: expat/2.4.8:f107943344aeffd2190b5bfc9516ac5e5cc868bf
ERROR: Missing binary: ffmpeg/4.4:e8487608a6fabf7b659bb3863cee556ff342972c
ERROR: Missing binary: flac/1.3.3:ddfe5f8d8713ba1b36b7c3abc635963db950901c
ERROR: Missing binary: fmt/8.1.1:518189a70e600f323cfde3a70a65f0d5ab9a10ea
ERROR: Missing binary: hdf5/1.12.1:dd3a266ced3d35b19cdd2afb59db13d30ae8e317
ERROR: Missing binary: lcms/2.13.1:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9
ERROR: Missing binary: libcap/2.62:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9
ERROR: Missing binary: libde265/1.0.8:e907ab56da208f9569d10623981804efe8ef4f5c
ERROR: Missing binary: libdeflate/1.10:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9
ERROR: Missing binary: libfdk_aac/2.0.2:4ebd68c7311a450e176e0bb0ffc8882b6abd4482
ERROR: Missing binary: libheif/1.12.0:212345031a146b5458db0d0e837d9af95cb840a0
ERROR: Missing binary: libsndfile/1.0.31:244e2036694f61c00771f1443b05053e29e20633
ERROR: Missing binary: libsquish/1.15:4ebd68c7311a450e176e0bb0ffc8882b6abd4482
ERROR: Missing binary: libtiff/4.3.0:28610262c5ae482418532e6e77118db48b5a933e
ERROR: Missing binary: libvpx/1.11.0:dcd66243bc948155f4f0f0cfd9360d4127dc8a27
ERROR: Missing binary: libwebp/1.2.2:a09a552b2ea0e3af4ad938637eef2959778a4bcd
ERROR: Missing binary: libx265/3.4:b0bb968b1ea177898e2255887164f9da9f588aa0
ERROR: Missing binary: libxml2/2.9.14:4b8bcfd687ee0cb778b8e59589e8eb34d394d024
ERROR: Missing binary: ogg/1.3.5:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9
ERROR: Missing binary: onetbb/2020.3:388975d0e388b930ae8bf7be38463627332429c9
ERROR: Missing binary: opencolorio/2.1.0:ade379e8d3b2b421dadb5aaf77fd523c5e57a22b
ERROR: Missing binary: opencv/4.5.5:5c50c9a7b4b0c110bebcb940592f772cd954219f
ERROR: Missing binary: openexr/2.5.7:a45ea4b6014968e6e9e934f0f5fa5a467fa981bf
ERROR: Missing binary: openh264/2.1.1:4ebd68c7311a450e176e0bb0ffc8882b6abd4482
ERROR: Missing binary: openimageio/2.3.7.2:e681cd6c647ab27cc55544cea082bca09b24cffc
ERROR: Missing binary: openssl/1.1.1o:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9
ERROR: Missing binary: protobuf/3.17.1:fd5e4281291c630948790ffa396a8e6fbb9f42e6
ERROR: Missing binary: ptex/2.4.0:a45ea4b6014968e6e9e934f0f5fa5a467fa981bf
ERROR: Missing binary: pugixml/1.12.1:4ebd68c7311a450e176e0bb0ffc8882b6abd4482
ERROR: Missing binary: pulseaudio/14.2:b77dafbb410dfb4fc4ba4d776142e0a7ffd40d0c
ERROR: Missing binary: pystring/1.1.3:4ebd68c7311a450e176e0bb0ffc8882b6abd4482
ERROR: Missing binary: vulkan-loader/1.3.211.0:883f066ff242e0cc5f79101e485ebcc20a77a422
ERROR: Missing binary: wayland/1.20.0:491924764982d2a8ce5f0d81f7f49331f933b2ff
ERROR: Missing binary: yaml-cpp/0.7.0:4ebd68c7311a450e176e0bb0ffc8882b6abd4482
ERROR: Missing binary: zlib/1.2.12:72c3493baf37f6fd0e9e64ab36754d5a2f6479a9
ERROR: Missing binary: zstd/1.5.2:62a88ab7bbffda63e0c146e4fe66d5d90b946798

ade/0.1.1f: WARN: Can't find a 'ade/0.1.1f' package for the specified settings, options and dependencies:
- Settings: arch=x86_64, build_type=Debug, compiler=clang, compiler.cppstd=14, compiler.libcxx=libstdc++11, compiler.version=10, os=Linux
- Options: fPIC=True
- Dependencies: 
- Requirements: 
- Package ID: 4ebd68c7311a450e176e0bb0ffc8882b6abd4482

ERROR: Missing prebuilt package for 'ade/0.1.1f', 'boost/1.78.0', 'expat/2.4.8', 'ffmpeg/4.4', 'flac/1.3.3', 'fmt/8.1.1', 'hdf5/1.12.1', 'lcms/2.13.1', 'libcap/2.62', 'libde265/1.0.8', 'libdeflate/1.10', 'libfdk_aac/2.0.2', 'libheif/1.12.0', 'libsndfile/1.0.31', 'libsquish/1.15', 'libtiff/4.3.0', 'libvpx/1.11.0', 'libwebp/1.2.2', 'libx265/3.4', 'libxml2/2.9.14', 'ogg/1.3.5', 'onetbb/2020.3', 'opencolorio/2.1.0', 'opencv/4.5.5', 'openexr/2.5.7', 'openh264/2.1.1', 'openimageio/2.3.7.2', 'openssl/1.1.1o', 'protobuf/3.17.1', 'ptex/2.4.0', 'pugixml/1.12.1', 'pulseaudio/14.2', 'pystring/1.1.3', 'vulkan-loader/1.3.211.0', 'wayland/1.20.0', 'yaml-cpp/0.7.0', 'zlib/1.2.12', 'zstd/1.5.2'
Use 'conan search ade/0.1.1f --table=table.html -r=remote' and open the table.html file to see available packages
Or try to build locally from sources with '--build=missing'

More Info at 'https://docs.conan.io/en/latest/faq/troubleshooting.html#error-missing-prebuilt-package'
```

Running `conan search ade/0.1.1f` prints this out:
```
Existing package recipes:

ade/0.1.1f
```

Is this a bug in conan or am I doing something wrong?

P. S. Revisions for all of these packages are 0. E.g:
```
ade/0.1.1f: Not found in local cache, looking in remotes...
ade/0.1.1f: Trying with 'conancenter'...
Downloading conanmanifest.txt completed [0.17k]                                          
Downloading conanfile.py completed [3.58k]                                               
Downloading conan_export.tgz completed [0.25k]                                           
Decompressing conan_export.tgz completed [0.00k]                                         
ade/0.1.1f: Downloaded recipe revision 0
```
user: dyscalculia94
issue_11693: state: open
title: [question] Build Requirement Usage
body: Hello,

I'm trying to use the `build_requires` feature and it's not behaving how I thought I understood it to work. Essentially this is the use case:

- All packages are built with multiple profiles; for this example let's say we have an x86_64 profile and an arm profile
- Package appX requires package buildHelperX for building

Thus, appX lists buildHelperX in its `build_requires` section. appX is built via CMake, so it has something like this in its CMakeLists.txt:
`set(BUILD_HELPERX_BIN_PATH ${CONAN_BIN_DIRS_BUILD_HELPERX}/build_helper)`

`CONAN_BIN_DIRS_BUILD_HELPERX` is set within the generated conanbuildinfo.cmake file.

My problem is that when my build system goes to build (`conan create`) appX for the arm profile, it attempts to execute (within the CMakeLists.txt, using the variable in my example above) the build helper binary for the arm profile instead of that of the build machine (the x86_64 profile).

I tried to explicitly specify a build and host profile for `conan create` by using the `--profile:build <build profile> --profile:host <host profile>` but then I notice that the conanbuildinfo.cmake file does not have path variables for the `build_requires` build helper package. If my CMakeLists.txt does not have the path variables from conanbuildinfo.cmake I'm not sure how I'd know where to find them from within the local Conan cache.

What am I doing wrong?

Thank you!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: radonish
issue_11688: state: open
title: [bug] How to link against system libraries installed in /usr/local/lib on *BSD when using the CMakeDeps generator and Pkg package manager?
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: FreeBSD 13.1
  * Compiler+version: Clang 13.0.0
  * Conan version: 1.50.0
  * Python version: 3.9.13

### Steps to reproduce (Include if Applicable)

Specify `system_libs` for any libraries installed with `pkg` on FreeBSD.
When using the `CMakeDeps` generator, libraries are not found because the link directory `/usr/local/lib` is not communicated to CMake or the linker.
See conan-io/conan-center-index:#11698 for where this issue occurs in the `xorg/system` package.
Note that Conan does correctly determine the location of the libraries when creating the package and CMakeDeps files. The `INTERFACE_LINK_DIRECTORIES` are not set, however, which why this only effects linking. The `INTERFACE_INCLUDE_DIRECTORIES` are set appropriately.

This limits the effectiveness of using the package manager tool `conan.tools.system.package_manager.Pkg`, since the `/usr/local/lib` link directory has to be communicated to Conan by adding the `-L/usr/local/lib` flag to the configuration values `tools.build:exelinkflags` and `tools.build:sharedlinkflags`.

It is important to note that this behavior is inherent to *BSD systems, not just FreeBSD. The *BSD package managers install packages to `/usr/local` and not `/usr`.

### Logs (Executed commands with output) (Include/Attach if Applicable)

https://github.com/bincrafters/system-packages-checks/runs/7368977364?check_suite_focus=true#step:3:17487
user: jwillikers
issue_11686: state: open
title: [feature] Consider allowing overriding install prefix at package creation time
body: At package creation time, Conan 1.x integrations will pass the _package folder_ to the `--prefix` argument (or equivalent, e.g. `CMAKE_INSTALL_PREFIX`), in those cases where we want to rely on existing "install" logic  to cause the files to be placed directly in the package folder by the build scripts, as opposed to explicitly copying them from the build tree.

In some cases, libraries will take the path provided at _configure_ time (via `--prefix` or equivalent) and embed it in the produced files (executables, libraries, config files). This has the potential for issues in some cases (see this [issue](https://github.com/conan-io/conan-center-index/issues/11842) in Conan Center for some examples).

In a lot of other cases (I would like to think the majority of cases), the `--prefix` value is only relevant at package creation time (install time), and not embedded at all in any of the produced files.

Some build systems allow specifying a `--prefix` at configure time, and overriding the final location when invoking the install target ([`DESTDIR`](https://www.gnu.org/prep/standards/html_node/DESTDIR.html) for example, or overriding the prefix when invoking [`cmake --install` ](https://cmake.org/cmake/help/v3.24/manual/cmake.1.html#install-a-project)).


While Conan itself will *not* place packages in system locations (`/usr`, `/usr/local`), there are situations in which a user, acting in the capacity of system administrator or even distribution maintainer, may wish to re-package the binaries inside a Conan package, to be placed at a location relevant to a particular Linux distro setup. For example: creating `.deb` or `.rpm` packages to be installed in "canonical" locations where the final installation location _is_ known. In these cases, it may be useful for those embedded path to point to those locations, rather than the "package folder at package creation time" or other arbitrary locations. 

On the premise that the install prefix at package creation time is arbitrary (there is no universally "good" value), and that most build systems allow overriding it (i.e., provide a value at configure time, and a different value at "install" time to place files in the package folder), we are being requested to consider the following:
* Allow users to override the the install prefix provided at configure time, perhaps via a [tool configuration](https://docs.conan.io/en/latest/reference/config_files/global_conf.html#tools-configurations) such that this can be done without having to modify recipes
* The above is only possible if the impacted build integrations (Autotools, CMake, etc) move to split case where the install prefix is overridden when invoking the install target (via `DESTDIR` or Similar). The new Autotools integration (Conan 2.x) already does this, for different reasons.

This could be helpful for those users that maintain their own binary packages for a narrower scope of target platforms/OS, where the final binaries are installed at a known location using a different mechanism other than Conan. 


user: jcar87
issue_11679: state: open
title: [feature] Add support for DESTDIR for the cmake tool
body: Please add support for the cmake tool to execute the install command with the DESTDIR as a prefix.
Similar to this https://github.com/conan-io/conan/issues/11264 but this was for autotools and we need the same for CMake now.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: derived-coder
issue_11674: state: open
title:  Check for working C compiler: - broken
body: Hello All,

I am new to conan and currently trying to create library package and I am using gcc compiler.

whenever I am trying to create package it is giving following error

but if I am building this library with cmake command, it is building perfectly fine.

I am not able to set cross compile setting for with Conan.

if anyone can guild how can cross compile with  with Conan.


user: himansu2906
issue_11671: state: open
title: [feature] CMakeDeps should publish resource dirs as variable
body: <!-- What is your suggestion? Please be as specific as possible! -->

We're using some conan packages for resource data and/or code generator input that we're using in our build. When trying the new _CMakeDeps_ generator, I noticed that it does not create a variable for the resource dir of the used package (there is only a _xyz_RES_DIRS_DEBUG_ variable that depends on the build setting).

Without this build-setting independent variable I'm not sure how to access the resource dir from CMake in a generic way. Currently it seems like this use case would have to be handled manually in the consumer conanfile.

I suggest making a _xyz_RES_DIRS_ variable available (similar to _xyz_INCLUDE_DIRS_) that can be used directly in CMake.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: fschoenm
issue_11638: state: open
title: [feature] apply same flags for test_package as for parent recipe
body: <!-- What is your suggestion? Please be as specific as possible! -->
If  you use some compilation flags in the build profile, they only applied to a recipe, but not to the test recipe.
I have the following lines in my build profile:
sqlite3:CFLAGS=-fsanitize=address,undefined,leak,integer -march=native -mtune=native
sqlite3:CXXFLAGS=-fsanitize=address,undefined,leak,integer -march=native -mtune=native
sqlite3:LDFLAGS=-fsanitize=address,undefined,leak,integer -march=native -mtune=native

If I call 
`conan-center-index/recipes/sqlite3/all$ conan create . sqlite3/3.38.5@andrei/test --build missing`
I get these errors:
```
/usr/bin/ld: sqlite3.c:(.text+0x3fbb8c): undefined reference to `__asan_report_store4'
/usr/bin/ld: sqlite3.c:(.text+0x3fbc07): undefined reference to `__ubsan_handle_pointer_overflow'
/usr/bin/ld: sqlite3.c:(.text+0x3fbc3d): undefined reference to `__ubsan_handle_type_mismatch_v1'
/usr/bin/ld: sqlite3.c:(.text+0x3fbc7e): undefined reference to `__ubsan_handle_type_mismatch_v1'
/usr/bin/ld: sqlite3.c:(.text+0x3fbcc6): undefined reference to `__asan_report_store4'
/usr/bin/ld: sqlite3.c:(.text+0x3fbd38): undefined reference to `__ubsan_handle_pointer_overflow'
/usr/bin/ld: sqlite3.c:(.text+0x3fbd6e): undefined reference to `__ubsan_handle_type_mismatch_v1'
```
That happens, because arch of recipe and test_recipe does not match.
Is there any way how could I adress specific test_recipe?
I dont want just to use wildcad in this case

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: AndreyMlashkin
issue_11637: state: open
title: [question] Get dependencies of a package in custom generator
body: Previously I was able to get the dependencies of conan packages in a custom generator using something like

```
        for name, info in self.deps_build_info.dependencies:
            if not name in self.conanfile.build_requires:
                if info.components:
                    for _, comp in info.components.items():
                        self.processSingleDependency(comp)
                else:
                    result = self.processSingleDependency(info)
```

which would then attempt to read the things that said dependency depends on, among other needed information.
This still works for things like abseil, grpc (which use components) and seemingly (didn't take a close look yet) a few other required packages.
But it does no longer seem to work for things like json-schema-validator (which depends on nlohmann_json) or sqlitecpp (which depends on sqlite3).

```
    def processSingleDependency(self, info):
        if info.lib_paths:
            self.conanfile.output.info(f'  Lib Directories: {info.lib_paths}')
        if info.requires:
            self.conanfile.output.info(f'  Required packages: {info.requires}')
        if info.include_paths:
            self.conanfile.output.info(f'  Include Directories: {info.include_paths}')
```

It does appear that requires is always empty, despite it actually requiring the dependency to be present (especially in the case of sqlitecpp).

Conan itself seems perfectly aware of the package requiring another package as evidenced by `conan info` and the requirements are in the dependency tree.

Has anything changed in recent history?
How are custom generators supposed to gain the information as to the requirements of libraries currently?

Using conan 1.50

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Sil3ntStorm
issue_11629: state: open
title: [question] How to explicitly control the CMake generator (i.e. cmake -G option)?
body: We are compiling our project with Clang on Windows (in addition to msvc).

The code compiles when we run the CMake and build commands manually. Yet we face a complication when trying to use Conan.
It seems the problem lays with the [CMake generator](https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id9) (the value provided to `cmake -G`) filled-in by Conan when it invokes `cmake`:

* When we compile manually, we use `Unix Makfefiles`
* When we use conan, it sets `MinGW Makefiles`.

Our environment is:
* Conan 1.49.0
* Git-bash shell
* Make 4.3 (installed via [scoop ](https://scoop.sh/)package manager)

Our guess is that Conan deduces `MinGW Makefiles` due to our specific setup.
Is there a way to override this default value to `Unix Makefiles`?
user: Adnn
issue_11627: state: open
title: [question] Possible Workflow with CMake (and CLion)
body: Hello,
I'm currently working on a project with a small team working on a relative small code base. Nevertheless, the code base has some dependencies on external libraries and these external libraries have their dependencies on their own. Up to now, we use a shell script to install the dependencies in docker. The exact versions of the installed dependencies where more or less random and depended on the time of execution.

I've convinced my team to use Conan to install the dependencies and thus to codify our dependency and to pin the exact version, we are using with a specific version of our own project.

We use CMake for the build. We have 3 different build configurations (gcc-debug, gcc-release, clang-debug). So far, I was able to configure Conan to install our dependencies (using the 3 configurations above) and to build the software and their tests.

Now I have a pretty large command line for installing every configuration, which I probably could shorten a little bit, by using profiles and a large command line for the CMake configuration, which I can shorten largely by using presets.

Now, I would like to integrate Conan into CMake. I had the dream, that I could simply checkout our sources and use CMake to configure and build the software and that Conan is integrated into the CMake build, so that it gets called to determine the required include and library paths and of cause, to install missing libraries / dependencies. And of cause, if our Conan configuration changes (which simply can happen, by switching the branch), I don't want to explicitly run Conan, but use CMake to detect the required update.

The preferred method to integrate both, seems to be the CMakeToolchain integration. But in this case, the required toolchain file has to exist already before I call CMake (and as there is a chance, that the project has to be cross build in the future, we probably are going to use the tool chain feature of CMake on our own).

Is there a seamless integration of Conan into CMake that doesn't require me to call Conan before I call CMake? Is my expectation, about what Conan should be used for / should be capable of, somehow wrong? Is there an example project accessible, that integrates CMake and Conan).

best regards,
Torsten


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: TorstenRobitzki
issue_11608: state: open
title: [feature] Provide some more "native" package for debian(-based) OS's
body: As there seem some problems with automatic tools for packaging (see #11590 , also for why forcing pip is no substitute),
a better .deb packaging would be welcome.

-    Use the system python installation
-    Use the system python libs (as good as possible)
-    Possible to ultimately end up in official repos.

I have gone ahead and did the work for debian [here](https://github.com/nolange/conan-deb), currently would only work with debian-unstable or debian-stable with manually installing [python3-patch-ng](https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=python3-patch-ng).

The result would be this:
[python3-conan_1.50.0-1_all.zip](https://github.com/conan-io/conan/files/9083662/python3-conan_1.50.0-1_all.zip)


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: nolange
issue_11601: state: open
title: Add PythonVirtualEnv helper and CMakePythonDeps generator
body: * Add a PythonVirtualEnv helper to facilitate the creation and
  management of python virtual environments. This provides some much
  needed functionality to enable python dependencies to be managed from
  within conan, and makes it substantially easier to interogate virtual
  environments.
* Add a CMakePythonDeps generator to generate CMake targets for each
  executable entry point in a given python environment. This allows
  CMake to find and use executables installed within a python virtual
  environment.

Closes #8626.

This implementation is an exemplar of what python dependency management in conan might look like. It's not perfect, so I'm seeking feedback on the implementation and any improvements that would make it more suitable for inclusion in the conan codebase. This is based largely on the legwork done by @thorntonryan in #8626. I'll leave any implementation of documentation until this PR is in a more mature state.

To describe the basic functionality of these features, it would allow for the creation of a `python-virtualenv/system` recipe:

```python
from conan.tools.python import PythonVirtualEnv

class PythonVirtualEnvironment(ConanFile):
    name = "python-virtualenv"
    version = "system"
    settings = "os_build", "arch_build", "os"
    options = {"requirements": "ANY"}
    default_options = {"requirements": "[]"}
    # python venvs are not relocatable, so we will not have binaries for this on artifactory. Just build it on first use
    build_policy = "missing"

    def package(self):
        # Create the virtualenv in the package method because virtualenv's are not relocatable.
        venv = PythonVirtualEnv(self)
        venv.create(folder=os.path.join(self.package_folder))

        requirements = json.loads(str(self.options.get_safe("requirements", "[]")))
        if requirements:
            self.run(tools.args_to_string([
                venv.pip, "install", *(requirement for requirement in requirements),
            ]))

        for requirement in requirements:
            package = requirement.split("==")[0]
            # Ensure that there's an entry point for everything we've just installed.
            venv.setup_entry_points(
                str(package), os.path.join(self.package_folder, "bin")
            )

    def package_info(self):
        self.user_info.python_requirements = self.options.get_safe("requirements", "[]")
        self.user_info.python_envdir = self.package_folder
```
As you can see, this uses `self.user_info.{python_requirements,python_envdir}` variables to communicate these dependencies to the `CMakePythonDeps` generator. If this is integrated into conan, I assume we'd want to use something other than `user_info` to store this metadata?

I've also opted to allow the specification of the requirements that should be installed via a JSON string as an option to the package. This was probably the best I could hope for with a custom python_requires package and custom generator, but perhaps this should be revisited for inclusion in the conan codebase - would it be worth having a more native way of specifying python requirements? With the JSON string, it strikes me that if the same set of dependencies would generate a different package ID if they were specified in a different order.

But this would allow a downstream C++ project to specify it's own python requirements and generate CMake targets appropriately. An example of the relevant parts of this downstream project conanfile might look like:

```python
class MyPkg(ConanFile):
    name = "mpkg"
    version = "0.1.0"

    exports_sources = "CMakeLists.txt", "src/*", "include/*", "requirements.txt"

    def requirements(self):
        # Could also be a tool_requires?
        self.requires("python-virtualenv/system")
        self.options["python-virtualenv"].requirements = json.dumps([
            "sphinx==5.0.1",
            "sphinx-book-theme==0.3.2",
        ])
        # Or read from a requirements.txt in the project root
        # with pathlib.Path("requirements.txt").open() as requirements_txt:
        #    self.options["python-virtualenv"].requirements = json.dumps([
        #        str(requirement) for requirement in pkg_resources.parse_requirements(requirements_txt)
        #    ])

    def generate(self):
        py = CMakePythonDeps(self)
        py.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
```
This would allow the following syntax in the relevant CMakeLists.txt (probably for documentation):

```cmake
find_package(sphinx REQUIRED)

# Sphinx configuration
set(SPHINX_SOURCE ${CMAKE_CURRENT_SOURCE_DIR})
set(SPHINX_BUILD ${CMAKE_CURRENT_BINARY_DIR}/sphinx)
set(SPHINX_INDEX_FILE ${SPHINX_BUILD}/index.html)

# Only regenerate Sphinx when:
# - Doxygen has rerun
# - Our doc files have been updated
# - The Sphinx config has been updated
add_custom_command(
  OUTPUT ${SPHINX_INDEX_FILE}
  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/index.rst
  COMMAND sphinx::sphinx-build -b html ${SPHINX_SOURCE} ${SPHINX_BUILD}
  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
  COMMENT "Generating documentation with Sphinx")

add_custom_target(Sphinx ALL DEPENDS ${SPHINX_INDEX_FILE})

# Add an install target to install the docs
include(GNUInstallDirs)
install(DIRECTORY ${SPHINX_BUILD}/ DESTINATION ${CMAKE_INSTALL_DOCDIR})
```
I've got working examples of both of these packages for further exploration:
* [python-virtualenv](https://github.com/samuel-emrys/python-virtualenv/tree/develop)
* [sphinx-consumer](https://github.com/samuel-emrys/sphinx-consumer/tree/develop)

Any feedback or suggestions for improvements to the way this being approached would be appreciated.

Changelog: Feature: Add PythonVirtualEnv helper class to create and manage python virtual environments, and CMakePythonDeps generator to facilitate the generation of CMake targets for executables of the packages installed within these virtual environments.

Docs: https://github.com/conan-io/docs/pull/XXXX

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 

<sup>**Note:** By default this PR will skip the slower tests and will use a limited set of python versions. Check [here](https://github.com/conan-io/conan/blob/develop/.github/PR_INCREASE_TESTING.md) how to increase the testing level by writing some tags in the current PR body text.</sup>

user: samuel-emrys
issue_11591: state: open
title: [bug] Linux OpenCV 4.5.1 from Conan center crashes at run time
body: Hey guys,
I'm using OpenCV from Conan Center.
On Windows everything works fine, however on Linux, my application crashes with

`error while loading shared libraries: libopencv_imgproc.so.4.5: cannot open shared object file: No such file or directory`

running 
`ldd MyExecutable` gives me


![grafik](https://user-images.githubusercontent.com/93189163/177995288-5820a571-8758-4bf0-8bc2-7b651f23ad42.png)

libopencv_imageproc is not found. However libopencv_imgcodecs was properly found. I believe there is something missing in the recipe or my project, since parts of opencv are located correctly




```
-- Conan: checking conan executable
 -- Conan: Found program /usr/local/bin/conan
 -- Conan: Version found Conan version 1.50.0
 -- Conan executing: /usr/local/bin/conan install . --build missing --settings build_type=Debug --settings compiler=gcc --settings compiler.version=10 --settings compiler.libcxx=libstdc++11 --settings compiler.cppstd=20
 Configuration:
 [settings]
 arch=x86_64
arch_build=x86_64
build_type=Debug
 compiler=gcc
 compiler.cppstd=20
 compiler.libcxx=libstdc++11
 compiler.version=10
 os=Linux
os_build=Linux
 [options]
[build_requires]
 [env]
```



My (simplified) setup looks like this
```

  list(APPEND CMAKE_MODULE_PATH ${CMAKE_BINARY_DIR})
  list(APPEND CMAKE_PREFIX_PATH ${CMAKE_BINARY_DIR})
  if(NOT EXISTS "${CMAKE_BINARY_DIR}/conan.cmake")
    message(STATUS "Downloading conan.cmake from https://github.com/conan-io/cmake-conan")
    file(DOWNLOAD "https://raw.githubusercontent.com/conan-io/cmake-conan/release/0.18/conan.cmake" "${CMAKE_BINARY_DIR}/conan.cmake")
  endif()
  include(${CMAKE_BINARY_DIR}/conan.cmake)
set(PACKAGE_SHARED_OPTION "shared=True")
 set(OPENCV_ADDITIONAL_OPTIONS
        "opencv:${PACKAGE_SHARED_OPTION}"
        "opencv:with_ade=False"
        "opencv:with_eigen=False"
        "opencv:with_ffmpeg=False"
        "opencv:with_openexr=False"
        "opencv:with_png=True"
        "opencv:with_imgcodec_hdr=True"
        "opencv:with_imgcodec_pfm=True"
        "opencv:with_imgcodec_pxm=True"
        "opencv:with_quirc=False"
        "opencv:with_tiff=False"
        "opencv:with_webp=False"
)

foreach(TYPE ${CMAKE_CONFIGURATION_TYPES})
  conan_cmake_configure(
        REQUIRES
        opencv/4.5.1
        OPTIONS
        "${OPENCV_ADDITIONAL_OPTIONS}"
        GENERATORS
        cmake_find_package_multi
        IMPORTS
        "lib, *.dylib* -> ./bin/${TYPE}"
        "bin, *.dll -> ./bin/${TYPE}"
        "lib, *.so* -> ./bin/${TYPE}"
      )
  conan_cmake_autodetect(settings BUILD_TYPE ${TYPE})
        conan_cmake_install(
          PATH_OR_REFERENCE
          .
          BUILD
          all
          SETTINGS
          ${settings}
   )
endforeach()

find_package(OpenCV CONFIG REQUIRED)
```

my executable setup is as follows
```
set(EXE_NAME "TestExe")
add_executable(${EXE_NAME} "foo.cpp")
target_link_libraries(${EXE_NAME} PRIVATE "opencv::opencv")
```


Am I missing some opencv libs in my target_link_libraries()?
Why is libopencv_imgcodecs  set but not libopencv_imageproc?
When I manually append the build path to the LD_LIBRARY_PATH i can run the executable properly. However I'd like to use a more general solution ;)


Other 3rd parties like Gtest and jsoncpp work fine on windows and linux.

Could you help me out here


### Environment Details (include every applicable attribute)
  * Docker Ubuntu 18
  * Compiler+version: GCC 10:
  * Conan version: 1.50.0
  * Python version: 3.6.9


user: Ju1He1
issue_11590: state: open
title: [bug] conan should not set LD_LIBRARY_PATH, messes up tools
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: debian 11 x86_64
  * Compiler+version: gcc 11.3.0
  * Conan version: 1.50.0 (debian package)
  * Python version: 3.10.5

### Steps to reproduce (Include if Applicable)

Tested this with the conan center gtest recipe, should
be the same problem with all cmake recipies.

```bash
conan create . gtest/1.12.1@
```

Somewhere conan will call the equivalent of `LD_LIBRARY_PATH=/opt/conan cmake`,
which then causes the process to use the outdated/incompatible version
of liblzma.so.5.

Thats a bad idea obviously, and instead the conan binaries/libraries 
should be just specify a runpath so only those use the modified lookup.

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
Exporting package recipe
gtest/1.12.1 exports: File 'conandata.yml' found. Exporting it...
gtest/1.12.1 exports: Copied 1 '.yml' file: conandata.yml
gtest/1.12.1: Calling export_sources()
gtest/1.12.1 export_sources() method: Copied 1 '.txt' file: CMakeLists.txt
gtest/1.12.1: The stored package has not changed
gtest/1.12.1: Exported revision: d2dc3cf651bd7517ee67535e47a300e1
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=11
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

gtest/1.12.1: Forced build from source
Installing package: gtest/1.12.1
Requirements
    gtest/1.12.1 from local cache - Cache
Packages
    gtest/1.12.1:473fac5a451159bef91e2252b31a075ead43201f - Build

Installing (downloading, building) binaries...
gtest/1.12.1: Copying sources to build folder
gtest/1.12.1: Building your package in /home/lano/.conan/data/gtest/1.12.1/_/_/build/473fac5a451159bef91e2252b31a075ead43201f
gtest/1.12.1: Generator cmake created conanbuildinfo.cmake
gtest/1.12.1: Aggregating env generators
gtest/1.12.1: Calling build()
cmake: /opt/conan/liblzma.so.5: version `XZ_5.2' not found (required by /usr/lib/x86_64-linux-gnu/libarchive.so.13)
```

user: nolange
issue_11587: state: open
title: [bug] Overridden requirement still builds original requirement and scrambles options
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: docker ubuntu:jammy-20220531
  * Compiler+version: 
  * Conan version:  pip3 install conan --upgrade
  * Python version: python3 jammy

dockerfile
> FROM ubuntu:jammy-20220531
RUN apt-get update && apt-get install -y \
    autoconf \
    g++ \
    make \
    pkg-config \
    python3-pip \
    && apt-get clean
RUN pip3 install conan --upgrade

### Steps to reproduce (Include if Applicable)
`conan install -b missing -b outdated -b cascade conanfile.txt `

where conanfile has 

> [requires]
openssl/3.0.3
poco/1.11.3
>
> [build_requires]
cmake/3.23.2
>
> [options]
openssl:shared=False
openssl:no_gost=True
openssl:no_asm=True
openssl:no_idea=True
openssl:no_mdc2=True
openssl:no_rc5=True
poco:shared=False
poco:enable_encodings=True
poco:enable_xml=True
poco:enable_json=True
poco:enable_util=True
poco:enable_zip=True
poco:enable_net=True
poco:enable_crypto=True
poco:enable_netssl=True
poco:enable_apacheconnector=False
poco:enable_cppparser=False
poco:enable_data=False
poco:enable_data_mysql=False
poco:enable_data_odbc=False
poco:enable_data_postgresql=False
poco:enable_data_sqlite=False
poco:enable_jwt=False
poco:enable_mongodb=False
poco:enable_pdf=False
poco:enable_pagecompiler=False
poco:enable_pagecompiler_file2page=False
poco:enable_pocodoc=False
poco:enable_redis=False
poco:enable_sevenzip=False
poco:enable_activerecord=False

### Logs (Executed commands with output) (Include/Attach if Applicable)

> WARN: poco/1.11.3: requirement openssl/1.1.1o overridden by your conanfile to openssl/3.0.3
bzip2/1.0.8: Package is up to date
expat/2.4.8: Package is up to date
zlib/1.2.12: Package is up to date
pcre/8.45: Package is up to date
poco/1.11.3: Forced build from source
ERROR: openssl/1.1.1o: option 'no_fips' doesn't exist
Possible options are ['no_threads', 'shared', 'fPIC', 'no_asm', 'enable_weak_ssl_ciphers', '386', 'no_stdio', 'no_tests', 'no_sse2', 'no_bf', 'no_cast', 'no_des', 'no_dh', 'no_dsa', 'no_hmac', 'no_md5', 'no_mdc2', 'no_rc2', 'no_rsa', 'no_sha', 'no_async', 'no_dso', 'no_aria', 'no_blake2', 'no_camellia', 'no_chacha', 'no_cms', 'no_comp', 'no_ct', 'no_deprecated', 'no_dgram', 'no_engine', 'no_filenames', 'no_gost', 'no_idea', 'no_md4', 'no_ocsp', 'no_pinshared', 'no_rmd160', 'no_sm2', 'no_sm3', 'no_sm4', 'no_srp', 'no_srtp', 'no_ssl', 'no_ts', 'no_whirlpool', 'no_ec', 'no_ecdh', 'no_ecdsa', 'no_rfc3779', 'no_seed', 'no_sock', 'no_ssl3', 'no_tls1', 'openssldir']


Also built similar config with additional requirements on Windows without issue

The initial trigger might be the POCO requirements() ?  but why doesn't it stay overridden?

        if self.options.enable_netssl or self.options.enable_crypto or \
           self.options.get_safe("enable_jwt"):
            self.requires("openssl/1.1.1o")

Hopefully I'm confused and you can correct me

user: GregDomjan
issue_11584: state: open
title: [question] How to handle multi config package with dependencies  
body: Hello,

I have a project that depends on both `qt` and `openssl`

* qt package was created with multiconfiguration=True, this means one qt package that contains both debug and release binaries. in this case qt package does not depend on build_type. (2 configs -> 1 package)
* zlib in the other hand is 1 config -> 1 package, this means we have two different packages one for debug and another for release.
* For my project, I'm trying to create two different packages, one for release and one for debug.
 
When I tried to build my project in release mode, everything works as expected. (I'm assuming here that qt package was created using the default zlib config (release)).
However, when I tried to build in debug mode, I got an error `ERROR: Missing prebuilt package for 'qt`, This is probably because conan was looking for qt package that was built with debug zlib. 

* Is my reasoning correct ? 
* How to make a build_type independent package depends on dependencies with multiple build types. 
* Is there any solution for this ? 

Thanks

user: boussaffawalid
issue_11577: state: open
title: [question] How should CONAN_CMAKE_FIND_ROOT_PATH_MODE_PROGRAM actually work?
body: Hi,

I'm a bit puzzled by the usage of CONAN_CMAKE_FIND_ROOT_PATH_MODE_PROGRAM.
Generally CMake does a whole lot of dark voodoo magic during the project() call (e.g. setting up CMAKE_AR, 
CMAKE_C_COMPILER, etc.).

conanbuildinfo.cmake (which practically transforms CONAN_CMAKE_FIND_ROOT_PATH_MODE_PROGRAM into
CMAKE_FIND_ROOT_PATH_MODE_PROGRAM) on its own is pulled in after project() calls - or at least this is the case for bzip2
and some other recipes.

And this is where I'm completely lost (e.g. for me it appears it happens quite late).

I'd like to do cross compilation with Yocto SDK, where it is mandatory that CMAKE_SYSROOT is not searched for any kind of tools (as those tools are the native tools, not the cross compilation compatible ones).

What is the meaning of CONAN_CMAKE_FIND_ROOT*? And how should they be used so that the project() call already sees the changed (by Conan) values?

Thanks,
user: harsszegi
issue_11572: state: open
title: Packaging proto best practice
body: My firm has begun a widespread adoption of conan. We have dozens of separate repositories, each of which produce a conan package. In the first attempt to adopt conan, some individuals decided to include generated protobuf headers in their conan packages. This will cause a compile-time error if an older version of protoc was used to generate those headers (e.g. protobuf/3.6.1), than the version being used by the current project (e.g. protobuf/3.17.1):

```
#error This file was generated by an older version of protoc which is
#error incompatible with your Protocol Buffer headers. Please
#error regenerate this file with a newer version of protoc.
```

By default, in the semver_direct_mode, conan will not complain about dependencies using protobuf/3.W.X vs protobuf/3.Y.Z, but if you include generated headers, you will run into the above compile-time error. To me, it seems obvious that **if you include generated protobuf headers in your package, you should use full_package_mode.**

An alternative approach would be to package only the *.proto files and have consumer packages import them in their imports() methods, and then have consumer CMakeLists.txt generate the *.pb.cc and *.ph.h files.

I found the protobuf example provided in the examples repository to be very limited. It only demonstrates how to generate *.pb.c and *.pb.h files for consumption by the same package which contains the *.proto. I would like to see an enhancement to that examples which involves multiple repositories and outlines best practices on packaging and sharing *.protos, *.pb.h and *.pb.c files.

Additionally, given the complexity of this use case, I would really some guidelines around best practices.
user: atniomn
issue_11564: state: open
title: Bugfix: Follow SONAME to generate BazelDeps correctly
body: Changelog: (Feature | Fix | Bugfix):

- Bugfix: `BazelDeps` generates incorrect `cc_import` when the shared library is versioned by `SONAME`.
        **Description:** If A and B are both shared libraries, and A links to B, the linker assigns the `NEEDED` tag of A according to the `SONAME` tag of B. The file name of B was chosen if and only if the `SONAME` tag of B does not exist. Because of this rule, the `BazelDeps` should generate `cc_import` directive of shared libraries from their `SONAME` tags instead of thier file names. Without that, we meet library loading errors in runtime because the Bazel don't know how to put the file (perhaps a symlink) named by its `SONAME` tag into the cache directory.</sup>

<!--Docs: https://github.com/conan-io/docs/pull/XXXX-->

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [x] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 

<sup>**Note:** By default this PR will skip the slower tests and will use a limited set of python versions. Check [here](https://github.com/conan-io/conan/blob/develop/.github/PR_INCREASE_TESTING.md) how to increase the testing level by writing some tags in the current PR body text.</sup>

user: tonyseek
issue_11563: state: open
title: [question] how to know if building from the cache in a Conan 1.x/2.x compatible way
body: I'm working on making one of our exemplar projects be as 2.x compatible as possible while still working in 1.x.

I want to prevent building/running the unit tests when in the local cache vs running them when building in a development/CI context.

Previously, the package used `exports_sources` and didn't export the test folders, i.e.:

```
    exports_sources = ('CMakeLists.txt', 'src/*', '!src/*/test/*', '!src/cmake-build-*/*', '!src/python/*',
                       '!src/test_common/*')
```

...and if the folders weren't there, the `CMakeLists.txt` just didn't build the tests. And the `build()` method said something like:

```python
    if not self.in_local_cache:
        cmake.test()
```

But now I want to save the Git information and check out from the Git repository as necessary. In doing so, the tests are getting built, and I'd rather not have the time spent, and _especially_ not to run them.

Is there going to be a way to know in Conan 2.x that the build is happening in response to a requirement instead of being at the root of the requirement graph? In other words, what can I use instead of `in_local_cache`?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: datalogics-kam
issue_11551: state: open
title: [question] Mixing shared and static linking
body: Hello,

I have a project that depends on qt and openssl.
Qt links openssl statically and I need to link openssl dynamically. 

I tried defining this in my project recipe.

```
    default_options = {
        "shared": True,
        "openssl:shared": True
```
and also tried:

```
    def config_options(self):
        self.options["openssl"].shared = True
```

But I always end up with with a `Missing binary` error as conan was looking for qt that was compiled with  `"openssl:shared": True`

Is there a way to mix static and shared linking of the same dependency in the same project ?   

user: boussaffawalid
issue_11543: state: open
title: [question] Is there a way to replace VirtuaRunEnv?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
I know VirtualRunEnv would create a activate_run.sh to create virtual env environment, but my project is based on ROS2's colcon and conan-cmake to install conan package from my own artifactory, every package used by colcon is like a project, it's inconvenient to build package B relied on package A having to source activated_run.sh. I need to build  package automatically fill LD_LIBRARY_PATH.
user: Tumb1eweed
issue_11541: state: open
title: [question] opencv with VideoCapture 
body: <!-- What is your question? Please be as specific as possible! -->
I am new to conan package manager, through some cpp files that I have written I tried to use opencv library and specifically the VideoCapture for reading videos, the thing is I did not succeed in any way to make the file compile and more specifically in linking my main.cpp with the required libs.
my conanfile.txt is :
[requires]
opencv/4.5.5
aws-sdk-cpp/1.9.234
openssl/1.1.1n


[generators]
compiler_args

and then I created a makefile like this:
all: conan.install compile
	
conan.install:
	conan install . --build=missing --install-folder build
	
compile:
	g++ src/main.cpp @build/conanbuildinfo.args -o bin/argss -std=c++17

the main.cpp contains only some lines:

#include <opencv2/core.hpp>
#include <opencv2/videoio.hpp>
#include <opencv2/highgui.hpp>

#include <opencv2/opencv.hpp>

#include <iostream>

using namespace std;
using namespace cv;

int main()
{
    VideoCapture cap;
    cout << "All good!!!" << endl;
    return 0;
}

but when I tried to run make all I got the following:

/usr/bin/ld: /home/muhammad/.conan/data/libx264/20191217/_/_/package/52bfaf5780e9ee7fba3fa4a492156dbcf0dff057/lib/libx264.a(analyse-8.o): in function `x264_8_analyse_init_costs':
analyse.c:(.text+0x216c9): undefined reference to `__log2f_finite'
/usr/bin/ld: /home/muhammad/.conan/data/libx264/20191217/_/_/package/52bfaf5780e9ee7fba3fa4a492156dbcf0dff057/lib/libx264.a(analyse-10.o): in function `x264_10_analyse_init_costs':
analyse.c:(.text+0x22dd9): undefined reference to `__log2f_finite'
/usr/bin/ld: /home/muhammad/.conan/data/libx265/3.4/_/_/package/e4cbe407e66aa4f34e55a1264d4af327f26b5f7d/lib/libx265.a(encoder.cpp.o): in function `x265::Encoder::ComputePSNR(x265_picture*, x265_picture*, x265_param*)':
encoder.cpp:(.text+0x2c2a): undefined reference to `__log10_finite'
/usr/bin/ld: encoder.cpp:(.text+0x2db0): undefined reference to `__log10_finite'
/usr/bin/ld: encoder.cpp:(.text+0x2e0e): undefined reference to `__log10_finite'
/usr/bin/ld: /home/muhammad/.conan/data/libx265/3.4/_/_/package/e4cbe407e66aa4f34e55a1264d4af327f26b5f7d/lib/libx265.a(encoder.cpp.o): in function `x265::Encoder::finishFrameStats(x265::Frame*, x265::FrameEncoder*, x265_frame_stats*, int)':
encoder.cpp:(.text+0x53e9): undefined reference to `__log10_finite'
/usr/bin/ld: encoder.cpp:(.text+0x5442): undefined reference to `__log10_finite'

and several lines with a similar content

am I doing something wrong in here????
what should I provide so that it can be compiled and used???
- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: muhflare
issue_11539: state: open
title: [question] full_package_mode also include build requirement in package id 
body: Hello,

Im trying to switch to `full_package_mode` for all packages, so I started defining the `package_id` method bellow for all recipe 

```
    def package_id(self):
        self.info.requires.full_package_mode()
``` 

First, I built meson with 1.11 and then when I tried to build pkgconf with ninja 1.10.2 I got this error

```
'pkgconf/1.7.4-g8709fbd@pmi/stable' requires 'ninja/1.10.2-gb935597@pmi/stable' 
while 'meson/0.62.2-g899c5b6@pmi/stable' requires 'ninja/1.11.0-gde9ebb3@pmi/stable'.
```

Is it expected that full_package_mode also include build requirements when computing package id  ?


user: boussaffawalid
issue_11534: state: open
title: [question] Running binary generated by conan package from CMake
body: I am currently running conan 1.48.1 and CMake 3.23.2. I have a conan recipe that creates a rendering library and a tool used to compile shaders. What I am trying to do is to have CMake execute the shader compilation tool and embed the compiled output into the main application that is being built.

Is there a way to have CMake know about the binary from the conan package and have CMake execute the binary with some arguments?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: slewicki
issue_11531: state: open
title: [question] How to set rpath-link in conan recipe?
body: As I mention in title, I try to develop a conan recipe for TensorRT OSS + TensorRT GA， and  this thing happen:
```
[ 81%] Building CXX object parsers/onnx/third_party/onnx/CMakeFiles/onnx.dir/onnx/defs/nn/defs.cc.o
[ 81%] Linking CXX executable getSupportedAPITest
/usr/bin/ld: warning: libcublas.so.11, needed by /data/.data/tensorrt/8.2.5/_/_/source/TensorRT-8.4.1.5/lib/libnvinfer_plugin.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libcublasLt.so.11, needed by /data/.data/tensorrt/8.2.5/_/_/source/TensorRT-8.4.1.5/lib/libnvinfer_plugin.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libcudnn.so.8, needed by /data/.data/tensorrt/8.2.5/_/_/source/TensorRT-8.4.1.5/lib/libnvinfer_plugin.so, not found (try using -rpath or -rpath-link)
```
What's the proper way to set rpath-link or LD_LIBRARY_PATH when developing conan recipes?

user: Tumb1eweed
issue_11516: state: open
title: [bug] Incorrect macOS M1 arch value
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: macOS 12
  * Compiler+version: Apple Clang 13
  * Conan version: 1.49
  * Python version: 3.10.4


### Steps to reproduce (Include if Applicable)

conan profile new default --detect --force


### Logs (Executed commands with output) (Include/Attach if Applicable)

```ini
[settings]
os=Macos
os_build=Macos
arch=armv8
arch_build=armv8
compiler=apple-clang
compiler.version=13
compiler.libcxx=libc++
build_type=Release
[options]
[build_requires]
[env]
```

i.e. `arch_build=armv8`

Meanwhile, `CmakeFiles/3.23.2/CMakeSystem.cmake`:

```cmake
set(CMAKE_HOST_SYSTEM "Darwin-21.5.0")
set(CMAKE_HOST_SYSTEM_NAME "Darwin")
set(CMAKE_HOST_SYSTEM_VERSION "21.5.0")
set(CMAKE_HOST_SYSTEM_PROCESSOR "arm64")

set(CMAKE_SYSTEM "Darwin-21.5.0")
set(CMAKE_SYSTEM_NAME "Darwin")
set(CMAKE_SYSTEM_VERSION "21.5.0")
set(CMAKE_SYSTEM_PROCESSOR "arm64")

set(CMAKE_CROSSCOMPILING "FALSE")

set(CMAKE_SYSTEM_LOADED 1)
```

i.e. `CMAKE_SYSTEM_PROCESSOR "arm64`

and `clang --version`:

```text
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
```

i.e. `Target: arm64`

Also, `arm64` value is absent in the default `settings.yml`.


Using of `armv8` instead of native `arm64` does not match other tools and requires values mapping in build scripts.
user: DmitrySokolov
issue_11511: state: open
title: [bug] How to export and env variable in all run situations
body: In my recipe, I want to declare an environment variable "CONSUMERVAR" to be in the environ whenever I run an exe built by this recipe.

There are two ways I am running the program:
1) when "installed", ie "conan install package/1.0@ -g VirtualRunEnv"

This seems to work if I:
```
    def package_info(self):
        self.runenv_info.define("CONSUMERVAR", "value")
```

2) The second place is when I do the following inside the package folder: `conan install . -g VirtualRunEnv`    ie to later be followed by `conan source .` (if not a in-source recipe) and `conan build .`, and finally `./cmake-build-release/folder/program`

The package_info() method never gets called in this situation, so this works instead:
```
    def generate(self):
        env1 = Environment()
        env1.define("CONSUMERVAR", "value")
        envvars = env1.vars(self, scope="run")
        envvars.save_script("consumer_env")
```

But I don't understand why this solution doesn't solve the first situation for consumers to use?   It is the "run" scope ...

Do I have to define the environment variables in both places?


### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Conan version: 1.49.0
  * Python version: 3.10

user: paulharris
issue_11509: state: open
title: [bug] Packages using msys2 as a build requirement use wrong compiler when compiling for Mingw64
body: I am using msys2 with the mingw-w64 toolchain as a build system and have noticed a problem with several conan packages using msys2 as a build requirement, e.g. libiconv and bison. 

Here is a minimum example using CMake:

CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.9)
project(TestProject CXX)

list(APPEND CMAKE_MODULE_PATH ${CMAKE_BINARY_DIR})
list(APPEND CMAKE_PREFIX_PATH ${CMAKE_BINARY_DIR})

if(NOT EXISTS "${CMAKE_BINARY_DIR}/conan.cmake")
  message(STATUS "Downloading conan.cmake from https://github.com/conan-io/cmake-conan")
  file(DOWNLOAD "https://raw.githubusercontent.com/conan-io/cmake-conan/0.18.1/conan.cmake"
                "${CMAKE_BINARY_DIR}/conan.cmake"
                TLS_VERIFY ON)
endif()

include(${CMAKE_BINARY_DIR}/conan.cmake)

conan_cmake_configure(REQUIRES libiconv/1.16
                      GENERATORS cmake_find_package)

conan_cmake_autodetect(settings)

conan_cmake_install(PATH_OR_REFERENCE .
                    BUILD libiconv/1.16
                    REMOTE conancenter
                    SETTINGS ${settings})


add_executable(main main.cpp)
```

main.cpp:
```
int main(int argc, char** argv) {
    return 0;
}
```

I installed MSYS2 under G:\msys64\ and with pacman, installed the binutils for mingw64. Therefore, the compiler binaries are located in G:\msys64\mingw64\bin\.
To build, I execute the following steps from the MSYS2 Mingw64 (**not** MSYS) shell:

```
mkdir build
cd build
cmake -G "Ninja" -DCMAKE_BUILD_TYPE=Release ..
```

Conan then installs its own msys2 and after that, builds libiconv in it:

`libiconv/1.16: run_in_windows_bash: C:\.conan\a58c4a\1\bin\msys64\usr\bin\bash.exe --login -c ^"cd \^"/c/users/admin/.conan/data/libiconv/1.16/_/_/build/7e4fe5e99aec5cc8f78973ab8ce64613ed35677c/source_subfolder\^" ^&^& PATH=\^"/c/.conan/a58c4a/1/bin/msys64/usr/bin:$PATH\^" ^&^& make -j16 ^"`

The problem: The wrong gcc compiler is used, because the msys2 installed by Conan already ships with its own MSYS gcc toolchain which is cygwin-based. Due to it adding /c/.conan/a58c4a/1/bin/msys64/usr/bin to the PATH before calling make, this wrong compiler is now used when executing "gcc".
Wrong compiler: C:\.conan\a58c4a\1\bin\msys64\usr\bin\gcc.exe (MSYS/cygwin-based compiler)
Right compiler: G:\msys64\mingw64\bin\gcc.exe (MINGW64 compiler)

As a result, the library does not compile:
```
stat-time.h: In function �get_stat_atime_ns�:
stat-time.h:52:43: error: invalid use of undefined type �const struct _stati64�
   52 | #  define STAT_TIMESPEC(st, st_xtim) ((st)->st_xtim)

```
because the library is not meant to be built inside the MSYS/cygwin environment.

Expected behavior: Conan should recognize that it is being run inside a msys2 MINGW64 environment and set the compiler paths accordingly before calling its own msys2. 
user: syncu2
issue_11508: state: open
title: [bug] No options for build requirements
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 x64, Arch Linux
  * Compiler+version: MSVC 2022, clang14
  * Conan version: 1.49.0
  * Python version: 3.9.7

### Steps to reproduce (Include if Applicable)
Have a conan recipe that has dependencies on other conan packages, which are only there if the package is built, rather than consumer requirements and try to set or check options for these dependencies.

```
from conans import ConanFile, tools
from conans.errors import ConanInvalidConfiguration

class BugDemoConan(ConanFile):
    name = 'bug_demo_project'
    version = '0.2.6'
    author = 'Nobody <nobody@cares.invalid>'
    url = 'www.bugz.com'
    description = 'Bug Demo'
    license = 'Unlicense'
    settings = 'os', 'compiler', 'build_type', 'arch'
    generators = 'cmake'
    build_requires = (
        'nlohmann_json/3.10.5',
        'ms-gsl/4.0.0',
        'spdlog/1.10.0',
    )

    def configure(self):
        self.options['fmt'].header_only = True
        self.options['spdlog'].header_only = True
        if self.settings.os == 'Windows':
            self.options['spdlog'].wchar_support = True
            self.options['spdlog'].wchar_filenames = True

    def validate(self):
        if self.options['fmt'].header_only != True:
            raise ConanInvalidConfiguration('fmt should be used in header_only mode')
        if self.options['spdlog'].header_only != True:
            raise ConanInvalidConfiguration('spdlog should be used in header_only mode')
        if self.settings.os == 'Windows' and not (self.options['spdlog'].wchar_filenames and self.options['spdlog'].wchar_support):
            raise ConanInvalidConfiguration('spdlog should be used with wchar_support and wchar_filenames on Windows')

```


### Logs (Executed commands with output) (Include/Attach if Applicable)
```
conan create .
Exporting package recipe
bug_demo_project/0.2.6: A new conanfile.py version was exported
bug_demo_project/0.2.6: Folder: <snip>\.conan\data\bug_demo_project\0.2.6\_\_\export
bug_demo_project/0.2.6: Exported revision: b215e3b34385bf036a8001d65ff71733
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

ERROR: bug_demo_project/0.2.6: Error in validate() method, line 27
        if self.options['fmt'].header_only != True:
        ConanException: option 'header_only' doesn't exist
Possible options are []
```
user: Sil3ntStorm
issue_11495: state: open
title: [feature] CMake find_package() COMPONENTS syntax across Conan packages
body: - [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

# Example use case: split Qt packages

As an example, imagine we want to split Qt into several Conan packages.

In the user conanfile.txt:
```txt
[requires]
QtWidgets/5.15.2
QtSql/5.15.2

[generators]
CMakeDeps
CMakeToolchain
```

In the user CMakeLists.txt:
```cmake
find_package(Qt5 REQUIRED COMPONENTS Widgets Sql)
# OR
find_package(Qt5Widgets REQUIRED)
find_package(Qt5Sql REQUIRED)
```

For the COMPONENTS syntax of `find_package()`, Cmake requires a file, named `Qt5Config.cmake`.

For the other syntax in above example, CMake requires 2 files, respectively `Qt5WidgetsConfig.cmake` and `Qt5SqlConfig.cmake`.

# What result should we have

After `conan install`, we should end up with CMake package config files for all required Qt libraries, and also `Qt5Config.cmake`.

This example lists the result.
It only lists a set of CMake package config files (`*-Targets*`, `*-data*`, also other dependencies are omitted):
```bash
Qt5Config.cmake
Qt5CoreConfig.cmake
Qt5SqlConfig.cmake
Qt5WidgetsConfig.cmake
```

In `Qt5CoreConfig.cmake`, `Qt5::Core` target will be defined.
The 2 other libraries (Qt5Widgets and Qt5Sql) are defined the same way.

The simplified content of `Qt5Config.cmake` looks like this:
```cmake

foreach(component ${Qt5_FIND_COMPONENTS})
  # Limit the search to CMAKE_PREFIX_PATH
  find_package(Qt5${component}
    QUIET CONFIG
    NO_CMAKE_ENVIRONMENT_PATH NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_PACKAGE_REGISTRY NO_CMAKE_SYSTEM_PATH NO_CMAKE_SYSTEM_PACKAGE_REGISTRY
  )
  if(NOT Qt5${component}_FOUND AND ${Qt5_FIND_REQUIRED_${component}})
    set(Qt5_NOT_FOUND_MESSAGE "Failed to find Qt5 component ${component} config file (Qt5${component}Config.cmake)")
    set(Qt5_FOUND False)
    break()
  endif()
endforeach()
```

Above code will tell `find_package()` to locate the components package config files in `CMAKE_PREFIX_PATH`.

For more information about the CONFIG mode search procedure, see also [find_package() search procedure](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure).

# Express Qt5Config.cmake

conanfile.py for the Qt package:
```python
class QtConan(ConanFile):

  name = "Qt"

  def package_info(self):

    self.cpp_info.set_property("cmake_file_name", "Qt5")
    # ??
```

How can we tell Conan CMake generators to provide the `find_package(Qt5 COMPONENTS ...)` syntax ?

It could be tempting to describe the components in some Qt meta-package:
```python
class QtConan(ConanFile):

  name = "Qt"

  def package_info(self):

    self.cpp_info.set_property("cmake_file_name", "Qt5")

    self.cpp_info.components["QtWidgets"].set_property("cmake_target_name", "Qt5::Widgets")
    # Will this even work ?
    self.cpp_info.components["QtWidgets"].requires = ["QtWidgets"]

    # Put all other Qt components here..
```

At first, I don't know if the above example even could work.

More important: if it can work, we will end up with a package, named `Qt`, that depends on all other Qt packages (QtCore, QtWidgets, QtSql, ...).
So we are back to the monolithic package.
Even if we put options to enable components or not, the problem of combinatorial builds is back.

# Current workaround and more details

If interested, some workaround I try to use, and also some more details about what was tempted, are available [here](https://gitlab.com/scandyna/mdtcmakeconfig/-/blob/experimental/ConanSplitQt.md)
user: scandyna
issue_11494: state: open
title: Artifactory "latest" endpoint poor performance
body: Using the API worked well, but I discovered a performance bug in Artifactory.
Using Conan's logging facility I found that accessing the `latest` REST endpoint took over half a second for each dependency. Here's the line from the log file:
`{"_action": "REST_API_CALL", "duration": 0.5114703178405762, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.15.1 (Python 3.7.3) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": ""}, "method": "GET", "time": 1559059613.903459, "url": "http://localhost:8081/artifactory/api/conan/conan/v2/conans/myproject/0.0.0-3/myuser/testing/latest"}`
I've reported this to service@jfrog.com - I'll be impressed if they're as responsive as you are :)

_Originally posted by @mplatings in https://github.com/conan-io/conan/issues/5198#issuecomment-496888041_
user: memsharded
issue_11490: state: open
title: [bug] Failure to find component include directories
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version: gcc 9.4.0
  * Conan version: 1.49.0
  * Python version: 3.8.19

### Steps to reproduce (Include if Applicable)
A continuation of this [issue](https://github.com/conan-io/conan/issues/11453) I opened a new one since the actual problem is different 

I have a recipe that's being packaged with the following method:
```python
    def package_info(self):
        version = tools.Version(self.version)
        self.cpp_info.set_property("cmake_find_mode", "both")
        self.cpp_info.set_property("cmake_file_name", self.name)
        self.cpp_info.set_property("component_version", self.version) 

        self.cpp_info.components["plist-2.0"].set_property("pkg_config_name", f"{self.name}-{version.major}.0")
        self.cpp_info.components["plist-2.0"].set_property("cmake_target_name", f"{self.name}::{self.name}")
        self.cpp_info.components["plist-2.0"].libs = ["plist-2.0"]
        self.cpp_info.components["plist-2.0"].libdirs = [f"${self.package_folder}/lib"]
        self.cpp_info.components["plist-2.0"].includedirs = [f"${self.package_folder}/include"]

        self.cpp_info.components["plist++-2.0"].set_property("pkg_config_name", f"{self.name}++-{version.major}.0")
        self.cpp_info.components["plist++-2.0"].set_property("cmake_target_name", f"{self.name}::{self.name}++")
        self.cpp_info.components["plist++-2.0"].libs = ["plist++-2.0"]
        self.cpp_info.components["plist++-2.0"].libdirs = [f"${self.package_folder}/lib"]
        self.cpp_info.components["plist++-2.0"].includedirs = [f"${self.package_folder}/include"]
```

which will generate this .pc file when consumed with PkgConfigDeps
```
prefix=/home/wbehrens@staudertech.local/.conan/data/libplist/2.2.0/_/_/package/333130a7c52a93ad8e2e64b2ac7d7bf7377ff65a
libdir1=${prefix}/$/home/wbehrens@staudertech.local/.conan/data/libplist/2.2.0/_/_/package/333130a7c52a93ad8e2e64b2ac7d7bf7377ff65a/lib
includedir1=${prefix}/$/home/wbehrens@staudertech.local/.conan/data/libplist/2.2.0/_/_/package/333130a7c52a93ad8e2e64b2ac7d7bf7377ff65a/include

Name: libplist-2.0
Description: Conan component: libplist-libplist-2.0
Version: 2.2.0
Libs: -L"${libdir1}" -lplist-2.0 
Cflags: -I"${includedir1}" 
```
Now the first problem is that if I remove the `includedirs` and `libdirs` properties from each of the components no default value is added like if I specify only a single target giving me a .pc file like this
```
prefix=/home/wbehrens@staudertech.local/.conan/data/libplist/2.2.0/_/_/package/333130a7c52a93ad8e2e64b2ac7d7bf7377ff65a

Name: libplist-2.0
Description: Conan component: libplist-libplist-2.0
Version: 2.2.0
Libs: -lplist-2.0 
Cflags:
```
I assume this is a bug

The core problem I'm having though is that when I try and use this recipe as a requirement for another that uses the PkgConfigDeps generator, even when I specify the include and lib dirs I still get the error that's shown in the log (even though the file it's searching for does exist on that path)

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
  CCLD     libinternalcommon.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/wbehrens@staudertech.local/.conan/data/libusbmuxd/2.0.2/_/_/build/fbab19ea20aa258681d08b5e318c632364d64e5e/build-release/common'
Making all in src
make[2]: Entering directory '/home/wbehrens@staudertech.local/.conan/data/libusbmuxd/2.0.2/_/_/build/fbab19ea20aa258681d08b5e318c632364d64e5e/build-release/src'
  CC       libusbmuxd.lo
/home/wbehrens@staudertech.local/.conan/data/libusbmuxd/2.0.2/_/_/build/fbab19ea20aa258681d08b5e318c632364d64e5e/./src/libusbmuxd.c:94:10: fatal error: plist/plist.h: No such file or directory
   94 | #include <plist/plist.h>
      |          ^~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:465: libusbmuxd.lo] Error 1
make[2]: Leaving directory '/home/wbehrens@staudertech.local/.conan/data/libusbmuxd/2.0.2/_/_/build/fbab19ea20aa258681d08b5e318c632364d64e5e/build-release/src'
make[1]: *** [Makefile:420: all-recursive] Error 1
make[1]: Leaving directory '/home/wbehrens@staudertech.local/.conan/data/libusbmuxd/2.0.2/_/_/build/fbab19ea20aa258681d08b5e318c632364d64e5e/build-release'
make: *** [Makefile:352: all] Error 2
libusbmuxd/2.0.2: 
libusbmuxd/2.0.2: ERROR: Package 'fbab19ea20aa258681d08b5e318c632364d64e5e' build failed
libusbmuxd/2.0.2: WARN: Build folder /home/wbehrens@staudertech.local/.conan/data/libusbmuxd/2.0.2/_/_/build/fbab19ea20aa258681d08b5e318c632364d64e5e/build-release
ERROR: libusbmuxd/2.0.2: Error in build() method, line 66
        autotools.make()
        ConanException: Error 2 while executing make -j16
```
user: wbehrens-on-gh
issue_11485: state: open
title: [bug] Conan's FindBoost doesn't honor CMake's find_package(... OPTIONAL ...)
body: 
### Environment Details (include every applicable attribute)
  * Operating System+version: WIndows, Linux
  * Compiler+version: Clang-14, Gcc-11, MSVC-17 (VS2022)
  * Conan version: 1.49
  * Python version: 3.10.5

### Steps to reproduce

make a CMakeLists.txt which contains:

```
if(NOT EXISTS "${CMAKE_BINARY_DIR}/conan.cmake")
	message(STATUS "Downloading conan.cmake from https://github.com/conan-io/cmake-conan")
	file(DOWNLOAD
		"https://raw.githubusercontent.com/conan-io/cmake-conan/0.18.1/conan.cmake"
		"${CMAKE_BINARY_DIR}/conan.cmake"
		TLS_VERIFY ON)
endif()
 
include(${CMAKE_BINARY_DIR}/conan.cmake)
 
conan_cmake_configure(
	REQUIRES
		boost/1.78.0
		...
	GENERATORS
		cmake_find_package
		virtualenv
	...
)
conan_cmake_install(
	PATH_OR_REFERENCE .
	BUILD missing
	REMOTE conancenter
)
 
...
 
find_package(Boost 1.78.0
	REQUIRED COMPONENTS
		system
		locale
		filesystem 
		unit_test_framework
	OPTIONAL_COMPONENTS
		# FixMe: conan problems
		stacktrace_basic
		stacktrace_backtrace
		stacktrace_addr2line
		stacktrace_noop
		stacktrace_windbg
)
...
```
Conan's data dir holds some of the optionals (Windows host)

```
D:\.conan_short\b03c59\1\lib
 
 
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        22.04.2022     12:50          29582 libboost_atomic.lib
-a----        22.04.2022     12:50         367324 libboost_chrono.lib
-a----        22.04.2022     12:50         263768 libboost_container.lib
-a----        22.04.2022     12:50           1238 libboost_date_time.lib
-a----        22.04.2022     12:50           1376 libboost_exception.lib
-a----        22.04.2022     12:50         910348 libboost_filesystem.lib
-a----        22.04.2022     12:47         933244 libboost_json.lib
-a----        22.04.2022     12:47        4985308 libboost_locale.lib
-a----        22.04.2022     12:47         281738 libboost_numpy310.lib
-a----        22.04.2022     12:47         383160 libboost_prg_exec_monitor.lib
-a----        22.04.2022     12:47        2013046 libboost_python310.lib
-a----        22.04.2022     12:47           6292 libboost_stacktrace_noop.lib
-a----        22.04.2022     12:47          75818 libboost_stacktrace_windbg.lib
-a----        22.04.2022     12:47          78688 libboost_stacktrace_windbg_cached.lib
-a----        22.04.2022     12:47           1178 libboost_system.lib
-a----        22.04.2022     12:48        7361152 libboost_test_exec_monitor.lib
-a----        22.04.2022     12:48         504998 libboost_thread.lib
-a----        22.04.2022     12:48        7306602 libboost_unit_test_framework.lib
```
running CMake gets

```
[build] -- Conan: Using autogenerated FindBoost.cmake
[build] CMake Error at build/windows-msvc-release/FindBoost.cmake:6 (message):
[build]   Conan: Component 'stacktrace_basic' NOT found in package 'Boost'
[build] Call Stack (most recent call first):
[build]   build/windows-msvc-release/FindBoost.cmake:91 (conan_message)
[build]   CMakeLists.txt:118 (find_package)
[build] 
[build] 
[build] -- Conan: Component 'system' found in package 'Boost'
[build] -- Conan: Component 'locale' found in package 'Boost'
[build] -- Conan: Component 'filesystem' found in package 'Boost'
[build] -- Conan: Component 'unit_test_framework' found in package 'Boost'
[build] -- Configuring incomplete, errors occurred!
```

Inside build directory, the `FindBoost.cmake` is there, but doesn't care about CMake's Find `OPTIONAL_COMPONENTS`

This may be a duplicate of [conan-cmake #416](https://github.com/conan-io/cmake-conan/issues/416) a month ago, but I'm not shure where the  `FindBoost.cmake` is generated from. So, my hope is that I'm right here.

user: opelx
issue_11483: state: open
title: [bug] Specifying `--output-folder` does not move all generated files to the specified folder
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Arch Linux
  * Compiler+version: clang 13.0.0
  * Conan version: 1.49.0
  * Python version: 3.10.4

### Steps to reproduce (Include if Applicable)
When running `conan install` with the `--output-folder` flag, a number of files are generated in the root of the project, as demonstrated below:

```bash
$ conan new libfoo/0.1.0 --template=cmake_lib
$ conan install . --output-folder build
```
Which results in the following structure:

```bash
.
├── build
│   └── build
│       └── generators
│           ├── CMakePresets.json
│           └── conan_toolchain.cmake
├── CMakeLists.txt
├── CMakeUserPresets.json
├── conanbuildinfo.txt
├── conanfile.py
├── conaninfo.txt
├── conan.lock
├── graph_info.json
├── include
│   └── libfoo.h
├── src
│   └── libfoo.cpp
└── test_package
    ├── CMakeLists.txt
    ├── conanfile.py
    └── src
        └── example.cpp
```

Now, I understand that `conaninfo.txt` and `graph_info.json` have been deprecated (maybe `conan.lock` too?) and so won't be generated outputs in Conan 2.0, but `conanbuildinfo.txt` doesn't appear to have been deprecated, yet it appears in the project root. This is in spite of the help text for `conan install`:

```bash
$ conan install --help
...
  -of OUTPUT_FOLDER, --output-folder OUTPUT_FOLDER
                        The root output folder for generated and build files
...
```
Which certainly seems to indicate that all generated files should be placed in the output folder. It would be good if the above were honoured and these files were directed to the folder specified by `--output-folder` - I'd prefer not to have generated files in my project root.

Moving at least `conanbuildinfo.txt` to the directory specified by `--output-folder` would (at least superficially, until an `--output-folder` option is added to the `conan build` interface) resolve my interface concerns raised in #11482.
user: samuel-emrys
issue_11480: state: open
title: [bug] concurrency errors in conan export
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: `macOS 12.3`
  * Compiler+version: `Apple clang version 13.1.6 (clang-1316.0.21.2.5)`
  * Conan version: `Conan version 2.0.0-alpha7`
  * Python version: `Python 3.7.1`

### Steps to reproduce (Include if Applicable)

launch a simple script:
```
import subprocess
import multiprocessing

text = """from conan import ConanFile
class MyConanFile(ConanFile):
    pass
"""

with open("conanfile.py", "w") as f:
    f.write(text)

def run():
    while True:
        try:
            subprocess.check_call(["conan", "export", ".", "--name", "mylib", "--version", "1.0"])
        except:
            pass

jobs = []
for i in range(0, 2):
    process = multiprocessing.Process(target=run)
    jobs.append(process)
for j in jobs:
    j.start()
for j in jobs:
    j.join()
```

### Logs (Executed commands with output) (Include/Attach if Applicable)

observe various random errors:
```
Traceback (most recent call last):
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/shutil.py", line 557, in move
    os.rename(src, real_dst)
OSError: [Errno 66] Directory not empty: '/Users/sse4/.conan2/p/tmp/e9336c83458230ec' -> '/Users/sse4/.conan2/p/0878a4b138b80085'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/site-packages/conans/cli/cli.py", line 163, in run
    command.run(self._conan_api, self._commands[command_argument].parser, args[0][1:])
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/site-packages/conans/cli/command.py", line 157, in run
    info = self._method(conan_api, parser, *args)
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/site-packages/conans/cli/commands/export.py", line 39, in export
    lockfile=lockfile)
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/site-packages/conan/api/subapi/__init__.py", line 21, in wrapper
    return f(subapi, *args, **kwargs)
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/site-packages/conan/api/subapi/export.py", line 21, in export
    return cmd_export(app, path, name, version, user, channel, graph_lock=lockfile)
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/site-packages/conans/client/cmd/export.py", line 62, in cmd_export
    cache.assign_rrev(recipe_layout)
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/site-packages/conans/client/cache/cache.py", line 60, in assign_rrev
    return self._data_cache.assign_rrev(layout)
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/site-packages/conan/cache/cache.py", line 224, in assign_rrev
    shutil.move(self._full_path(layout.base_folder), full_path)
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/shutil.py", line 568, in move
    symlinks=True)
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/shutil.py", line 315, in copytree
    os.makedirs(dst)
  File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/os.py", line 221, in makedirs
    mkdir(name, mode)
FileExistsError: [Errno 17] File exists: '/Users/sse4/.conan2/p/0878a4b138b80085'
```

```
 Traceback (most recent call last):
   File "/Users/sse4/.pyenv/versions/3.7.1/lib/python3.7/shutil.py", line 557, in move
    os.rename(src, real_dst)
OSError: [Errno 66] Directory not empty: '/Users/sse4/.conan2/p/tmp/b366d60a7e3773f7' -> '/Users/sse4/.conan2/p/0878a4b138b80085'
```

```
ERROR: Couldn't remove folder, might be busy or open: /Users/sse4/.conan2/p/0878a4b138b80085
```

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SSE4
issue_11465: state: open
title: [question] Sharing binaries across different linux distros
body: I've read the various comments both on here and in the Documentation on Customising settings / changing my settings.yml to add os.distro field, but I must be missing something.

In my organisation we use a mix of linux distros across developers, and yet different ones again in production.  When I build a recipe on Arch Linux and push it to the repository, none of my Ubuntu-using colleagues can use it.  Everything is linked against different system libraries, etc.

But, surely, this means that central (public) conan repositories are completely useless for linux users?  How do I, as an Arch linux user, pull a linux binary package off conan center, and can be sure that it works?  Is every single user in the world going to agree independently to create os.distro for Linux and use the exact same values/names for Distros?

Surely this needs to be solved at the system level, and not by every linux user individually?   I feel like I'm missing something?
user: macdew
issue_11463: state: open
title: [bug] Bad explanation on error message for unmatched dependency.
body: I have looked at the bug reports for this and i found https://github.com/conan-io/conan/issues/7864 , but I was unable to understand what to do.

I have a fairly small conanfile (excerpt from a bigger project):

```
from conans import ConanFile, CMake

class DiagramServerConan(ConanFile):
    settings = "os", "compiler", "build_type", "arch"

    generators = (
        "cmake_find_package",
        "cmake_paths",
    )

    requires = (
        "flex/2.6.4",
        "bison/3.7.6",
    )
```

this (correctly) tells me that I have an unmatched dependency;

```
ERROR: Conflict in bison/3.7.6:
    'bison/3.7.6' requires 'm4/1.4.19' while 'flex/2.6.4' requires 'm4/1.4.18'.
    To fix this conflict you need to override the package 'm4' in your root package.
```

So I add `m4` in my root package:

```
from conans import ConanFile, CMake

class DiagramServerConan(ConanFile):
    settings = "os", "compiler", "build_type", "arch"

    generators = (
        "cmake_find_package",
        "cmake_paths",
    )

    requires = (
        "flex/2.6.4",
        "bison/3.7.6",
        "m4/1.4.19",
    )
```

and now I have a different error:

```
WARN: flex/2.6.4: requirement m4/1.4.18 overridden by your conanfile to m4/1.4.19 
ERROR: Conflict in flex/2.6.4:
    'flex/2.6.4' requires 'm4/1.4.18' while 'bison/3.7.6' requires 'm4/1.4.19'.
    To fix this conflict you need to override the package 'm4' in your root package.
➜  testconan2 
```

the wording on the error is strange, as adding the m4 to my requires is adding to my root package (if I'm not mistaken).
I also tried to add on build_requires, to the same issue.

user: tcanabrava
issue_11457: state: open
title: [question] Propagating options through the dependency chain
body: Lets assume two following conanfiles:

conanfileA.py
```
from conans import ConanFile, CMake, tools, RunEnvironment

class TestA(ConanFile):
    options = {
        "OptionA": ["foo", "bar"],
    }
    default_options = tuple(["OptionA=foo"])
```

conanfileB.py
```
from conans import ConanFile, CMake, tools, RunEnvironment

class TestB(ConanFile):
    options = {
        "OptionA": ["foo", "bar"],
    }
    default_options = tuple(["OptionA=foo"])


    def configure(self):
      #self.options["PackageA"].OptionA = str(self.options.OptionA)
      pass

    def requirements(self):
      self.requires("PackageA/1.0@ci/local")
```

We then create PackageA using the non-default option:

`conan create /tmp/conanfileA.py A/1.0@ci/local -o OptionA=bar`

attempt to create PackageB with the non-default option (like so - `conan create /tmp/conanfileB.py PackageB/1.0@ci/local -o OptionA=bar`) will fail, without uncommenting the line in `configure` method.

So my question is -- are the options 100% local to the current project, and do not propagate through the dependency chain, even if they have the same name?





- [X ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: w3sip
issue_11423: state: open
title: [question] Feedback: rename `build` and `run` traits
body:  In Conan 2.0 we have those things:
```
self.requires("cmake/1.0", build=True)
```
The `build=True` is very confusing. It looks like we are asking to build `cmake`, while we just ask for it to be available at build time (only??).
I would suggest to rename `build` and `run` traits to `buildtime` and `runtime`.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: ZbigniewRA
issue_11380: state: open
title: [question] cross-compilation issues for packages relying on generators built during compilation
body: For one of our projects we are using conan as our package manager. We are using conan in CMake through the CMake wrapper (https://github.com/conan-io/cmake-conan). Our project is intended to run on multiple platforms, so in order to accomplish this we've built a number of our own toolchains through crosstool-ng (https://crosstool-ng.github.io) and set up the corresponding conan profiles and CMake toolchain files for cross compilation.

Because of our pipeline needs, we are building everything in docker images, with our build image being based on Ubuntu 20.04. Some packages seem to be cross-compiling perfectly fine, e.g. https://conan.io/center/redis-plus-plus, https://conan.io/center/protobuf, https://conan.io/center/asio, ... and are perfectly usable. However certain packages seem to be giving us issues. Especially those which seem to rely on generated binaries used in turn as generators. One example of such a package is https://conan.io/center/sdbus-cpp and more in particular it's dependency selinux, which fails with:

```
libselinux/3.3: Applying build-requirement: flex/2.6.4
libselinux/3.3: Applying build-requirement: m4/1.4.19
libselinux/3.3: Configuring sources in /home/bramv/.conan/data/libselinux/3.3/_/_/source

libselinux/3.3: Copying sources to build folder
libselinux/3.3: Building your package in /home/bramv/.conan/data/libselinux/3.3/_/_/build/96bcd54f9b12eb32134c70b26750be8e77157885
libselinux/3.3: Generator txt created conanbuildinfo.txt
libselinux/3.3: Aggregating env generators
libselinux/3.3: Calling build()
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o assertion.o assertion.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o avrule_block.o avrule_block.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o avtab.o avtab.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o boolean_record.o boolean_record.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o booleans.o booleans.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o conditional.o conditional.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o constraint.o constraint.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o context.o context.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o context_record.o context_record.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o debug.o debug.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ebitmap.o ebitmap.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o expand.o expand.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o handle.o handle.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o hashtab.o hashtab.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o hierarchy.o hierarchy.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ibendport_record.o ibendport_record.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ibendports.o ibendports.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ibpkey_record.o ibpkey_record.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ibpkeys.o ibpkeys.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o iface_record.o iface_record.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o interfaces.o interfaces.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o kernel_to_cil.o kernel_to_cil.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o kernel_to_common.o kernel_to_common.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o kernel_to_conf.o kernel_to_conf.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o link.o link.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o mls.o mls.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o module.o module.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o module_to_cil.o module_to_cil.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o node_record.o node_record.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o nodes.o nodes.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o optimize.o optimize.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o polcaps.o polcaps.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o policydb.o policydb.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o policydb_convert.o policydb_convert.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o policydb_public.o policydb_public.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o policydb_validate.o policydb_validate.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o port_record.o port_record.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ports.o ports.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o services.o services.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o sidtab.o sidtab.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o symtab.o symtab.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o user_record.o user_record.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o users.o users.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o util.o util.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o write.o write.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ../cil/src/cil.o ../cil/src/cil.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ../cil/src/cil_binary.o ../cil/src/cil_binary.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ../cil/src/cil_build_ast.o ../cil/src/cil_build_ast.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ../cil/src/cil_copy_ast.o ../cil/src/cil_copy_ast.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ../cil/src/cil_find.o ../cil/src/cil_find.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ../cil/src/cil_fqn.o ../cil/src/cil_fqn.c
flex -o ../cil/src/cil_lexer.c ../cil/src/cil_lexer.l
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ../cil/src/cil_list.o ../cil/src/cil_list.c
aarch64-cortex_a53-linux-gnu-gcc -g -fPIC -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ../cil/src/cil_log.o ../cil/src/cil_log.c
/home/bramv/.conan/data/flex/2.6.4/_/_/package/1f477ddc5d737c4319f1655902f1498a01405d90/bin/flex: 1: Syntax error: Unterminated quoted string
make: *** [Makefile:71: ../cil/src/cil_lexer.c] Error 2
make: *** Waiting for unfinished jobs....
libselinux/3.3: 
WARN: Remotes registry file missing, creating default one in /home/bramv/.conan/remotes.json
libselinux/3.3: ERROR: Package '96bcd54f9b12eb32134c70b26750be8e77157885' build failed
libselinux/3.3: WARN: Build folder /home/bramv/.conan/data/libselinux/3.3/_/_/build/96bcd54f9b12eb32134c70b26750be8e77157885
ERROR: libselinux/3.3: Error in build() method, line 79
        env_build.make(args=args)
        ConanException: Error 2 while executing make 'libsepol.a' -j16
CMake Error at cmake/conan.cmake:638 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  service/CMakeLists.txt:21 (conan_cmake_install)


-- Configuring incomplete, errors occurred!
See also "/home/bramv/build/build_armv8_64_deb/CMakeFiles/CMakeOutput.log".
The terminal process "/usr/bin/bash '-c', 'cmake -S . -B build_armv8_64_deb -G Ninja -D CMAKE_TOOLCHAIN_FILE=cmake/toolchains/aarch64-cortex_a53-linux-gnu.cmake -D BUILD_SHARED_LIBS=ON -D CMAKE_BUILD_TYPE=Debug -D STAGE_SUB_FOLDER=stage_armv8_64_deb -D CMAKE_PREFIX_PATH="/home/bramv/build/dependencies_armv8_64" -D CMAKE_MODULE_PATH=/home/bramv/build/stage_armv8_64_deb && ninja -C build_armv8_64_deb'" terminated with exit code: 1.
```

As can be seen in the output above, the execution of `/home/bramv/.conan/data/flex/2.6.4/_/_/package/1f477ddc5d737c4319f1655902f1498a01405d90/bin/flex` seems to be causing the issue. It is my feeling that the error message `Syntax error: Unterminated quoted string` is not the actual issue occurring here, considering the following:

```
bramv@iprc00371:~/build$ uname -a
Linux iprc00371 5.14.0-1038-oem #42-Ubuntu SMP Thu May 19 05:03:08 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
bramv@iprc00371:~/build$ /home/bramv/.conan/data/flex/2.6.4/_/_/package/1f477ddc5d737c4319f1655902f1498a01405d90/bin/flex
bash: /home/bramv/.conan/data/flex/2.6.4/_/_/package/1f477ddc5d737c4319f1655902f1498a01405d90/bin/flex: cannot execute binary file: Exec format error
bramv@iprc00371:~/build$ readelf -h /home/bramv/.conan/data/flex/2.6.4/_/_/package/1f477ddc5d737c4319f1655902f1498a01405d90/bin/flex
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0x401bc0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          553568 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           64 (bytes)
  Number of section headers:         36
  Section header string table index: 35
```

It looks more like the build fails because it can't execute the flex binary since the host and build platforms are not the same.

The conan profile file for this particular toolchain is the following (we're using a jinja template):

```
toolchain_root={{os.getenv("CI_PROJECT_DIR")}}
toolchain_name=aarch64-cortex_a53-linux-gnu
toolchain=$toolchain_root/$toolchain_name

[build_requires]

[conf]
tools.gnu.make:jobs={{os.cpu_count()}}
tools.ninja:jobs={{os.cpu_count()}}

[env]
CONAN_CPU_COUNT={{os.cpu_count()}}
CONAN_CMAKE_FIND_ROOT_PATH=$toolchain/bin/
CONAN_CMAKE_SYSROOT=$toolchain/$toolchain_name/sysroot/
CONAN_CMAKE_GENERATOR=Ninja
PATH=[$toolchain/bin/]
CHOST=$toolchain_name
CC=$toolchain_name-gcc
CXX=$toolchain_name-g++
AR=$toolchain_name-ar
AS=$toolchain_name-as
GDB=$toolchain_name-gdb
LD=$toolchain_name-ld
NM=$toolchain_name-nm
OBJCOPY=$toolchain_name-objcopy
OBJDUMP=$toolchain_name-objdump
RANLIB=$toolchain_name-ranlib
STRIP=$toolchain_name-strip

[options]

[settings]
os=Linux
arch=armv8
compiler=gcc
compiler.version=11.2
compiler.libcxx=libstdc++11
build_type={{os.getenv("CMAKE_BUILD_TYPE")}}
```

While the contents of the CMake toolchain file is:

```
###################################################################################################
## Toolchain options (allows overriding locations for local build)
###################################################################################################

include("${CMAKE_CURRENT_LIST_DIR}/../celp/toolchain_config.cmake")

###################################################################################################
## Toolchain properties
###################################################################################################

set(toolchain_name "aarch64-cortex_a53-linux-gnu")
set(toolchain_root "${TOOLCHAIN_FOLDER}/${toolchain_name}")
set(stage_root "${STAGE_FOLDER}/${STAGE_SUB_FOLDER}")

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR armv8)
set(CMAKE_SYSROOT ${toolchain_root}/${toolchain_name}/sysroot)

set(CMAKE_STAGING_PREFIX ${stage_root})

set(CMAKE_C_COMPILER ${toolchain_root}/bin/${toolchain_name}-gcc)
set(CMAKE_CXX_COMPILER ${toolchain_root}/bin/${toolchain_name}-g++)
set(CMAKE_AR ${toolchain_root}/bin/${toolchain_name}-ar)
set(CMAKE_OBJCOPY ${toolchain_root}/bin/${toolchain_name}-objcopy)
set(CMAKE_OBJDUMP ${toolchain_root}/bin/${toolchain_name}-objdump)
set(CMAKE_RANLIB ${toolchain_root}/bin/${toolchain_name}-ranlib)
set(CMAKE_STRIP ${toolchain_root}/bin/${toolchain_name}-strip)

set(CMAKE_BUILD_RPATH "/opt/${toolchain_name}/lib64")
set(CMAKE_INSTALL_RPATH "/opt/${toolchain_name}/lib64")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-dynamic-linker=/opt/${toolchain_name}/lib64/ld-linux-aarch64.so.1")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-dynamic-linker=/opt/${toolchain_name}/lib64/ld-linux-aarch64.so.1")

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE BOTH)
```

The same packages compile just fine for x86_64 with the `Debug` or `Release` build type, but not for the `RelWithDebInfo` build type which seems to yield the following error:

```
pkgconf/1.7.4: Applying build-requirement: meson/0.62.1
pkgconf/1.7.4: Applying build-requirement: ninja/1.10.2
Downloading conan_sources.tgz
pkgconf/1.7.4: Configuring sources in /home/bramv/.conan/data/pkgconf/1.7.4/_/_/source

pkgconf/1.7.4: Copying sources to build folder
pkgconf/1.7.4: Building your package in /home/bramv/.conan/data/pkgconf/1.7.4/_/_/build/252f7e09f641bef29a75fc98d05ac217b842cde4
pkgconf/1.7.4: Generator txt created conanbuildinfo.txt
pkgconf/1.7.4: Aggregating env generators
pkgconf/1.7.4: Calling build()
The Meson build system
Version: 0.62.1
Source dir: /home/bramv/.conan/data/pkgconf/1.7.4/_/_/build/252f7e09f641bef29a75fc98d05ac217b842cde4/source_subfolder
Build dir: /home/bramv/.conan/data/pkgconf/1.7.4/_/_/build/252f7e09f641bef29a75fc98d05ac217b842cde4/build_subfolder
Build type: native build
Project name: pkgconf
Project version: 1.7.4
C compiler for the host machine: x86_64-ubuntu20.04-linux-gnu-gcc (gcc 11.2.0 "x86_64-ubuntu20.04-linux-gnu-gcc (crosstool-NG 1.24.0.535_74d6f26) 11.2.0")
C linker for the host machine: x86_64-ubuntu20.04-linux-gnu-gcc ld.bfd 1.24.0.535
Host machine cpu family: x86_64
Host machine cpu: x86_64
Configuring config.h using configuration
Build targets in project: 2
NOTICE: Future-deprecated features used:
 * 0.56.0: {'meson.build_root', 'meson.source_root'}

pkgconf 1.7.4

  User defined options
    backend        : ninja
    bindir         : bin
    buildtype      : debugoptimized
    default_library: static
    includedir     : include
    libdir         : lib
    libexecdir     : bin
    prefix         : /home/bramv/.conan/data/pkgconf/1.7.4/_/_/package/252f7e09f641bef29a75fc98d05ac217b842cde4
    sbindir        : bin
    sharedstatedir : /home/bramv/.conan/data/pkgconf/1.7.4/_/_/package/252f7e09f641bef29a75fc98d05ac217b842cde4/bin/share
    tests          : False


ERROR: Could not detect Ninja v1.8.2 or newer

A full log can be found at /home/bramv/.conan/data/pkgconf/1.7.4/_/_/build/252f7e09f641bef29a75fc98d05ac217b842cde4/build_subfolder/meson-logs/meson-log.txt
pkgconf/1.7.4: 
pkgconf/1.7.4: ERROR: Package '252f7e09f641bef29a75fc98d05ac217b842cde4' build failed
pkgconf/1.7.4: WARN: Build folder /home/bramv/.conan/data/pkgconf/1.7.4/_/_/build/252f7e09f641bef29a75fc98d05ac217b842cde4
ERROR: pkgconf/1.7.4: Error in build() method, line 101
        meson = self._configure_meson()
while calling '_configure_meson', line 84
        meson.configure(source_folder=self._source_subfolder, build_folder=self._build_subfolder)
        ConanException: Error 1 while executing meson "/home/bramv/.conan/data/pkgconf/1.7.4/_/_/build/252f7e09f641bef29a75fc98d05ac217b842cde4/source_subfolder" "/home/bramv/.conan/data/pkgconf/1.7.4/_/_/build/252f7e09f641bef29a75fc98d05ac217b842cde4/build_subfolder" --backend=ninja -Dprefix="/home/bramv/.conan/data/pkgconf/1.7.4/_/_/package/252f7e09f641bef29a75fc98d05ac217b842cde4" -Dlibdir="lib" -Dbindir="bin" -Dsbindir="bin" -Dlibexecdir="bin" -Dincludedir="include" -Ddefault_library="static" -Dtests="False" -Dsharedstatedir="/home/bramv/.conan/data/pkgconf/1.7.4/_/_/package/252f7e09f641bef29a75fc98d05ac217b842cde4/bin/share" --buildtype=debugoptimized
CMake Error at cmake/conan.cmake:638 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  service/CMakeLists.txt:21 (conan_cmake_install)


-- Configuring incomplete, errors occurred!
See also "/home/bramv/build/build_x86_64_rel/CMakeFiles/CMakeOutput.log".
The terminal process "/usr/bin/bash '-c', 'cmake -S . -B build_x86_64_rel -G Ninja -D CMAKE_TOOLCHAIN_FILE=cmake/toolchains/x86_64-ubuntu20.04-linux-gnu.cmake -D ENABLE_UNIT_TESTS=ON -D BUILD_SHARED_LIBS=ON -D CMAKE_BUILD_TYPE=Release -D STAGE_SUB_FOLDER=stage_x86_64_rel -D CMAKE_PREFIX_PATH="/home/bramv/build/dependencies_x86_64" -D CMAKE_MODULE_PATH=/home/bramv/build/stage_x86_64_rel && ninja -C build_x86_64_rel'" terminated with exit code: 1.
```

In both cases I feel like I'm missing something obvious here and was wondering if maybe you could shed a light on my erroneous ways. Any advice would be appreciated and I'll gladly provide more info if required.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: bram-vanderstreeck
issue_11375: state: open
title: [question] Access Control Lists
body: I'm running Conan server with a custom authenticator. Can I also control the [read/write permissions](https://docs.conan.io/en/latest/uploading_packages/running_your_server.html#permissions-parameters) with a custom authorizer? Or do the permissions have to be listed explicitly in the server.conf? I want to defer to our authorization system to get up-to-date permissions per user.

Could I just modify [this](https://github.com/conan-io/conan/blob/develop/conans/server/launcher.py#L32-L39) to allow loading a custom authorizer plugin like it currently does for authentication plugins? And would that be a contribution you are interested in?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: joshvazquez
issue_11374: state: open
title: [bug] build_requirements are skipped on conan create . --build missing
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: Visual Studio VS2008, VS2015, VS2017, VS2019
  * Conan version: 1.48.1
  * Python version: 3.9.6

### Steps to reproduce
Let's assume this conanfile.py:
```python
from conans import ConanFile

class DemoConan(ConanFile):
    name = "demo"
    version = "0.0.0"
    settings = "os", "compiler", "build_type", "arch"

    def requirements(self):
        self.requires("boost/1.72.0@")

    def build_requirements(self):
        self.build_requires("catch2/2.13.9@")
```
By calling
```bash
conan create .
```

the build-requirements are installed. 
```
demo/0.0.0: Forced build from source
Installing package: demo/0.0.0
Requirements
    boost/1.72.0 from 'conancenter' - Cache
    bzip2/1.0.8 from 'conancenter' - Cache
    demo/0.0.0 from local cache - Cache
    zlib/1.2.12 from 'conancenter' - Cache
Packages
    boost/1.72.0:37050c911e5419517ec6e0761c16c6e262b3e2a3 - Cache
    bzip2/1.0.8:d16a91eadaaf5829b928b12d2f836ff7680d3df5 - Cache
    demo/0.0.0:031f3e634eb2c9302789dfaa70370c3f4ed5009c - Build
    zlib/1.2.12:3fb49604f9c2f729b85ba3115852006824e72cab - Cache
Build requirements
    catch2/2.13.9 from 'conancenter' - Cache
Build requirements packages
    catch2/2.13.9:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache
```

Instead, by calling
```bash
conan create . --build missing
```

the build-requirements are **not** installed.

```
Installing package: demo/0.0.0
Requirements
    boost/1.72.0 from 'conancenter' - Cache
    bzip2/1.0.8 from 'conancenter' - Cache
    demo/0.0.0 from local cache - Cache
    zlib/1.2.12 from 'conancenter' - Cache
Packages
    boost/1.72.0:37050c911e5419517ec6e0761c16c6e262b3e2a3 - Cache
    bzip2/1.0.8:d16a91eadaaf5829b928b12d2f836ff7680d3df5 - Cache
    demo/0.0.0:031f3e634eb2c9302789dfaa70370c3f4ed5009c - Cache
    zlib/1.2.12:3fb49604f9c2f729b85ba3115852006824e72cab - Cache
```

In my opinion, the behavior with the flag `--build missing` is not correct. I would not expect any difference for the build-requirements.

user: lucabonifacio
issue_11364: state: open
title: [question] Mac OS X - Library not loaded
body: We are building an executable and we use Conan to retrieve certain dependencies such as boost and protobuf. The project compiles, however when we launch the executable we get the following error:

Library not loaded: @rpath/libboost_contract.dylib
Referenced from: /Users/apostol.bakalov/Desktop/test/conanTest/test/build/src/bin/test_run
Reason: tried: '/usr/local/lib/libboost_contract.dylib' (no such file), '/usr/lib/libboost_contract.dylib' (no such file)

Conan manages to retrieve and compile boost and protobuf as shared libraries and stores them in its directory. I can locate the above mentioned libraries in the conan folder. What I would like to know whether there is a way to indicate in the case of OS X that it should look for libraries in the conan folder first and then in /usr/lib and /usr/local/lib? The same project compiles and runs without any issues on Linux and Windows.

Thank you in advance.
 
- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: apogza
issue_11362: state: open
title: [feature] conan info to return package_info related data
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Collecting information from an existing conan package through `conan info` returns some useful information but not everything that could be required relating to the consumption of a package.

Could it also return information from the recipe data in `cpp_info` that is created for package consumption in the `package_info()` method?

We are trying to bridge build toolchains where some libraries are packaged as conan packages but need to be consumed without conan. We are thus 'inspecting' a conan package to collect the necessary information to be able to correctly use it in a different toolchain.
user: SeanSnyders
issue_11356: state: open
title: [bug] CI tests broken or inconsistent - unchanged recipe from CCI now won't build
body: Please refer to PR https://github.com/conan-io/conan-center-index/pull/10983

I've been hitting my head against the wall, wondering why my only-slightly-modified HDF5 recipe won't pass the CI tests.

Now I see that the existing CCI recipe won't pass the CI.   I've pushed a PR with a trivial change (in the description) and the recipe fails to pass the CI.

It was able to pass only 26 days ago, in https://github.com/conan-io/conan-center-index/pull/10552

I first attempted to rebuild the original recipe in #10836 ... 
That time the CI built and older version of HDF5, and now I see a completely new error.
```
/home/conan/w/prod/BuildSingleReference/.conan/data/hdf5/1.10.5/_/_/package/1ea8e52079662e1f84321eeeac304c752fdf6af4/lib/libhdf5_debug.so: undefined reference to `H5libhdf5_settings'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```


This is very frustrating, as this isn't even the issue I was struggling with ... now I have more issues to deal with.

My struggles have been related to the new version of HDF5 linking zlib, and the fact that HDF5 wasn't linking to it at all.
Even more confusing, I don't even know why it was able to successfully build+test on some of the linux CIs, and not others.

WHY: When building HDF5 would NOT link zlib into the shared lib, instead it (seemed to) add it to a list of libraries that any linker of the shared library would link to.   BUT, conan's CI/CCI builds all libraries as static, so a shared-hdf5 would link a static zlib.    The consumer programs (like "mirror_server", in hdf5) would not link to zlib at all.    I think.
It is hard to tell because it would build ok on some platforms.

Example:
https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/c3i/misc/logs/pr/10836/9-linux-gcc/hdf5/1.12.1//summary.json
Filter Shared=true, build_type=Release, version=1 (to see both 10 and 11)
It compiled with:
```
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=10
os=Linux
[options]
hdf5:shared=True
```
But failed with:
```
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
[options]
hdf5:shared=True
```


user: paulharris
issue_11353: state: open
title: [feature] Have a way to generate both conanbuild.bat and conanbuild.ps1 files.
body: <!-- What is your suggestion? Please be as specific as possible! -->

It would be handy to have a way `tools.env.virtualenv:powershell` to create _both_ `.ps1` and `.bat` files. 

- `.ps1` to activate within a user's interactive PowerShell if necessary.
- `.bat` for when build scripting is using CMD to issue commands, and it needs to activate the environment to run CMake or some other command.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

This came out of using `conan.tools` to make a Conan 2.0-ish workflow while using Conan 1.

user: datalogics-kam
issue_11344: state: open
title: [question] How to ignore certificate with "conan_build_info create"
body: Hello,

In my context, I have a on premise Artifactory using https but I want to ignore certificate check.
In a usual conan use, my ~/.conan/remotes.json has [Verify SSL: False] attribute but when using "conan_build_info --v2 create buildinfo.json --lockfile updated.lock --user $CONAN_LOGIN_USERNAME --password $CONAN_PASSWORD
" I get following error:

ERROR: HTTPSConnectionPool(host='artifactory.XXX.com', port=443): Max retries exceeded with url: /api/storage/conan/_/boost/1.69.0/_/dbe25b33fdddc843db3a8e68636af20c/export/conan_sources.tgz (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)'),))

I don't know how conan_build_info find the Artifactory URL to use, is it from remotes.json?
In that case, it should consider "Verify SSL" attribute, right?

And if it is the case, why we don't have conan_build_info use by default CONAN_LOGIN_USERNAME and CONAN_PASSWORD environment variables instead of --user and --password parameters? And same of --url parameter?

Regards.
user: EstebanDugueperoux2
issue_11341: state: open
title: [question] Download cache supports concurrent access by different machines?
body: In the official Conan docs it says 

> The download cache implements interprocess exclusive locks, so only 1 process will access at a time to a given cached artifact.

In our case multiple CI build machines (totally independent of each other running on different VMs) have a mounted file share where the download cache is located. Every of this CI build machines is running the Conan client to get the dependencies installed.

Is this scenario also supported by the above mentioned locking mechanism or does "interprocess" mean locking between processes that are in the scope of one virtual/physical machine where multiple CI pipelines are running.

Thank you in advance for the answer.
user: MTomBosch
issue_11332: state: open
title: [bug] intelliSense cannot find `conans` module with Conan installed by Windows Installer.
body: ### Environment Details

  * Operating System+version: **Windows 11**
  * VSCode version: **VSCode 1.67.2**
  * Conan version: **Conan 1.48.1** (by Windows Installer)
  * Python version: **Python 3.9.2**

### Problem Description

For those who don't want to use `pip` to install Conan on Windows, the alternative way is to download the [binaries installer](https://github.com/conan-io/conan/releases/tag/1.48.1). Or we can use Package Manager [`winget`](https://winget.run/pkg/JFrog/Conan) or [`choco`](https://community.chocolatey.org/packages/conan) to install Conan. 

However, I noticed that if we use one of the above-mentioned methods to install Conan, intelliSense of VSCode **CANNOT** find `conans` module in the recipe `conanfile.py`. Although `conan.exe` can **SUCCESSFULLY** work with `conanfile.py`, the message of intelliSense is quite **ANNOYING**.

### Suggestion

How about do the following things:

1. Pacakge `python.exe` or `python3.exe` into Installer.
2. Pacakge the directory of `conans` module into Installer.
3. Append the directory of `conans` module into `PYTHONPATH` env.

So that our `python.exe` can find `conans` module through `PYTHONPATH` env.

### Screenshots

![image](https://user-images.githubusercontent.com/71438617/170410991-97174b0d-08ff-4c83-825f-509f6590329b.png)

user: hwhsu1231
issue_11326: state: open
title: [question] Consuming an existing PackageConfig.cmake with the newer generators.
body: For our modular developments, we maintain a Conan based workflow. It allows us to satisfy both external dependencies (usually fetched from Conan center) and internals dependencies that we host ourselves. All our repositories rely on CMake to generate build files for the different environments.

An important aspect  of our approach is that Conan is not a requirement to build the projects (even though it helps greatly ; ).
This means that a "CMake-only" workflow is also possible, which implies that the CMake scripts produce self-sufficient `PackageConfig.cmake` to be consumed by other CMake projects further downstream.

## Older generators
With older generators, we relied on `CMakePaths` to populate the required CMake variables so the CMake configuration phase would find the different `PackageConfig.cmake` that our internal repositories are producing, and all was working as expected.

## Newer generators
We are not aware of a way to consume the `PackageConfig.cmake` generated by CMake. All generators seems to generate such package config directly.

* Is there a way to directly consume an existing  `PackageConfig.cmake`?
* If not, would there be an interest to officially support it?

---
We understand some of the benefits of having the newer generators fully generate the config file via the content of `package_info()`, in particular with regard to the ability to become "generator agnostic" (i.e. using a generator that does not output for CMake).

In the meantime, there are also several advantages to allowing to directly consume an existing config CMake.
user: Adnn
issue_11322: state: open
title: [question] Setting output_folder of editable using yaml workspace file
body: Hello !
I'm working with workspace using a workspace yaml file and I'm trying to make it work with the new layout function. I am also using a base conanfile class using the python_requires_extend.

This is my base conanfile class
```python
def shred_basic_layout(conanfile, src_folder="."):
    conanfile.folders.build = os.path.join("..", "build_ws")
    if conanfile.settings.get_safe("build_type"):
        conanfile.folders.build = os.path.join(conanfile.folders.build, str(conanfile.settings.build_type))
    conanfile.folders.generators = os.path.join(conanfile.folders.build, "conan")
    conanfile.cpp.build.bindirs = ["."]
    conanfile.cpp.build.libdirs = ["."]
    conanfile.folders.source = src_folder

class ShredBaseConanFile(object):
    def layout(self):
        shred_basic_layout(self)
```
This is just a modified version of the basic_layout

In my conanfile I just set the python_requires_extend to ShredBaseConanFile.

When I run `conan workspace install` with the old version (i.e just using the layout file) all the files generated by my generators where written to the `build_folder` however when I use the layout function only the files generated by the `new_gen` generators (in my case CMakeToolchain) are placed in the build folder. All the `old_gen` generator (in my case cmake_paths and cmake_find_package_multi or cmake_find_package) write their files in the base_folder.

If I'm not mistaken the output_folder of the `old_gen` generators is taken from `conanfile.install_folder` which in turns is `self.folders.base_install`. 

From `conans/client/installer.py` line 481
```python
# New editables mechanism based on Folders
        if hasattr(conanfile, "layout"):
            output = conanfile.output
            output.info("Rewriting files of editable package "
                        "'{}' at '{}'".format(conanfile.name, conanfile.generators_folder))
            self._generator_manager.write_generators(conanfile, conanfile.install_folder,
                                                     conanfile.generators_folder, output)
```

For editables with a layout the install_folder is set to the output_folder of the editable

From `conans/client/installer.py` line 470
```python
if hasattr(conanfile, "layout"):
            conanfile.folders.set_base_folders(base_path, package_layout.output_folder)
```

Using the workspace yaml I did not find a way to set the output_folder of an editable. Is there any way to do so ?
user: FranzPoize
issue_11319: state: open
title: [bug] Autotools: wrong LD_FLAGS are generated for MSVC compiler
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details
  * Conan version: 1.48.2

I'm trying to make cyrus-sasl recipe support Windows. It uses autotools, so I setup it as follows:

```python
    @contextlib.contextmanager
    def _build_context(self):
        if self.settings.compiler == "Visual Studio":
            with tools.vcvars(self):
                env = {
                    "CC": "{} cl -nologo".format(tools.unix_path(self.deps_user_info["automake"].compile)),
                    "CXX": "{} cl -nologo".format(tools.unix_path(self.deps_user_info["automake"].compile)),
                    "CFLAGS": "-{}".format(self.settings.compiler.runtime),
                    "LD": "link",
                    "NM": "dumpbin -symbols",
                    "STRIP": ":",
                    "AR": "{} lib".format(tools.unix_path(self.deps_user_info["automake"].ar_lib)),
                    "RANLIB": ":",
                }
                print(env)
                with tools.environment_append(env):
                    yield
        else:
            yield

    @functools.lru_cache(1)
    def _configure_autotools(self):
        autotools = AutoToolsBuildEnvironment(self, win_bash=tools.os_info.is_windows)

        yes_no = lambda v: "yes" if v else "no"
        rootpath = lambda req: tools.unix_path(self.deps_cpp_info[req].rootpath)
        rootpath_no = lambda v, req: rootpath(req) if v else "no"
        args = [
            # ...
        ]
        autotools.configure(configure_dir=self._source_subfolder, args=args)
        return autotools

    def build(self):
        self._patch_sources()
        with self._build_context():
            env_build = self._configure_autotools()
            env_build.make()
```

Unfortunately it fails in configure script:

```
configure:3963: checking whether the C compiler works
configure:3985: /d/.conan/data/automake/1.16.4/_/_/package/3e48e69237f7f2196164383ef9dedf0f93cbf249/res/automake-1.16/compile cl -nologo -O2 -Ob2 -MD -MD -I/d/.conan/data/openssl/1.1.1m/_/_/package/6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7/include -DNDEBUG -LIBPATH:/d/.conan/data/openssl/1.1.1m/_/_/package/6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7/lib conftest.c libssl.lib libcrypto.lib crypt32.lib ws2_32.lib advapi32.lib user32.lib >&5
conftest.c
LINK : fatal error LNK1181: cannot open input file 'libssl.lib'
```

I believe that's due to the following code:

https://github.com/conan-io/conan/blob/db343feac208a000bc6546556104a8511a584f1e/conans/client/build/compiler_flags.py#L236-L238

that is incorrect. In case of MSVC it makes Conan to generate `LD_FLAGS=-LIBPATH:...` environment variable that is used by autotools to set *compiler* options but `-LIBPATH` is a MSVC *linker* option. So the configure script fails.

I think `format_library_paths` should always prepend `-L` (it's only used by autotools code, right?) For MSVC `automake-1.16/compile` wrapper will convert it to `-link -LIBPATH:path1 -LIBPATH:path2 ...` itself.
user: db4
issue_11305: state: open
title: [bug] conan inspect (and some other commands) do not work with new explicit alias syntax
body: 
### Environment Details (include every applicable attribute)
  * Seen on Linux, but should be reproducible on any os.
  * Conan version: 1.48.1, 1.44.1

### Steps to reproduce
Create an alias to any conan package in the cache. 
E. g.
```
$ conan alias CA/LATEST@user/testing CA/1.0.0@user/testing
```
Then try to inspect it with explicit alias syntax:
```
$ conan inspect -a alias "CA/(LATEST)@user/testing"
```
Which results in an error: "Not found in local cache, looking in remotes..."
(and of course, it is not found on the remotes, either).

Same problem with:
```
$ conan search "CA/(LATEST)@user/testing"
$ conan get "CA/(LATEST)@user/testing" conanfile.py
$ conan upload -r local "CA/(LATEST)@user/testing"
$ conan copy "CA/(LATEST)@user/testing" user2/testing2
$ conan download -r local "CA/(LATEST)@user/testing"
```

These same commands with the classic syntax work:
```
$ conan inspect -a alias "CA/LATEST@user/testing"
$ conan search "CA/LATEST@user/testing"
$ conan get "CA/LATEST@user/testing" conanfile.py
$ conan upload -r local "CA/LATEST@user/testing"
$ conan copy "CA/LATEST@user/testing" user2/testing2
$ conan download -r local "CA/LATEST@user/testing"
```

What does work is an install with the new syntax:
```
$ conan install "CA/(LATEST)@user/testing"
```
... which correctly results in a "CA/1.0.0@user/testing: Already installed!" message, showing that the alias has been resolved.

"conan info" works, as well.
```
$ conan info "CA/(LATEST)@user/testing"
```

Of course, you do not need to use explicit alias syntax on the command line, but some automatic scripts stumbled across this because we are currently starting to introduce explicit alias syntax in our recipes to resolve occasional alias resolution problems (and to start migration towards conan 2.0). We can work around this for now, but it would be nice, if this worked consistently in conan, as well.
(Maybe its more an inconsistency than a bug. Or you might also call it a feature request, depending on how you view this.)

Oh, just seeing:
```
$ conan alias "CA/(LATEST)@user/testing" CA/1.0.0@user/testing
```
creates an alias with braces in the cache:
```
$ conan search "CA/*"
Existing package recipes:

CA/(LATEST)@user/testing
CA/LATEST@user/testing
CA/1.0.0@user/testing
```
I guess, this is asking for trouble when trying to resolve that alias ...
user: fourbft
issue_11303: state: open
title: Login error after changing remote adress for existing remote name
body: We are currently in the phase of migrating from one Artifactory instance to another one.
To make the migration as transparent as possible for the developers and our pipelines we have not introduced new remote names but kept the current remote names and just change the target address. After setting up the updated remotes we sporadically get login 403 errors in our pipelines with following error message: This request is blocked due to recurrent login failures, please try again in 15 seconds. We do not understand why we get this error since locally we cannot reproduce the error and also in the pipeline we can only sporadically get it.

The build machines running pipelines are doing the following:

- Via conan config install get the remotes (remote names are the same for the new remote but the target address has changed)
- Log out of current repos (if there is a login cached somehow) via: conan user --clean
- Source a sh script that sets the user/password env variables that sets per remote name a user/pw pair
- Login to the conan repos using conan user -p -r <repo remote name>
- Do Conan install ...

Important to know is that the same build machine is switching between the old and new Conan repo (via the conan config install and the sourcing of different user/pw env vars) depending on the pipeline job that is executed. Hint: On such build machine can only run one pipeline job at a time so concurrency is not an issue.

I have the feeling that the cached auth key could be an issue here but I am not sure. Any ideas on this issue?

Thank you
user: MTomBosch
issue_11299: state: open
title: [question] passing `-DSOMETHING` to cmake configure command
body: - [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Hi. Following from #4572, I'm curious about the best way to pass certain variables, esp. pertaining to analysis tools such as: `CMAKE_CXX_INCLUDE_WHAT_YOU_USE`, `CMAKE_CXX_CPPCHECK`, and `CMAKE_CXX_CLANG_TIDY`.

They're not really toolchains per se, so setting them through a toolchain wouldn't seem appropriate.

They're not a limited set (the next version of CMake might add new ones), and they're not project-specific (I can imagine applying these to many C++ projects), so adding them to each _conanfile.py_ doesn't seem like the right choice either. For the same reasons, they don't belong in _CMakeLists.txt_ files, which are best left tool-agnostic.

I pass in toolchain files purely to work around this, but I'd rather not. I'd rather be able to pass them explicitly in the `conan install` step and/or in a profile file.

So what's the best solution? Thanks.
user: johnmcfarlane
issue_11288: state: open
title: [question] Remotes unreachable although Ping was still working.
body: I am installing conan-file. And somehow i can't retrieve data from remote server. The Ping command for this server still works. 
Here is the notifications of the problem. 

**eem_mlbevo_toolchain/0.4@eem_mlbevo/testing: Not found in local cache, looking in remotes...
eem_mlbevo_toolchain/0.4@eem_mlbevo/testing: Trying with 'ee-conan-toolchain'...
ERROR: Failed requirement 'eem_mlbevo_toolchain/0.4@eem_mlbevo/testing' from 'conanfile.py (eem_mlbevo_integration/0.1@eem_mlbevo/testing)'
ERROR: HTTPSConnectionPool(host='nexus.edag.de', port=443): Max retries exceeded with url: /nexus/repository/ee-conan-toolchain/v1/ping (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7f5e492f4450>, 'Connection to 10.10.1.10 timed out. (connect timeout=10.0)'))**

**_Unable to connect to ee-conan-toolchain=https://nexus.edag.de/nexus/repository/ee-conan-toolchain
1. Make sure the remote is reachable or,
2. Disable it by using conan remote disable,
Then try again._**

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: tungnguyen279
issue_11287: state: open
title: [bug] cannot create package with tool_requires(cmake)
body: See conan-center-index#10833

```
    def requirements(self):
        self.requires("libcurl/7.80.0")
        self.requires("openssl/1.1.1o", override=True)

    def build_requirements(self):
        self.tool_requires("cmake/3.22.4")
```

Fails with:
```
ERROR: Conflict in cmake/3.22.4:
    'cmake/3.22.4' requires 'openssl/1.1.1n' while 'libcurl/7.80.0' requires 'openssl/1.1.1o'.
    To fix this conflict you need to override the package 'openssl' in your root package.
```
user: paulharris
issue_11274: state: open
title: [bug] working dir in `sources` is `self.folders.sources` which it should not
body: 
### Environment Details (include every applicable attribute)
  * Operating System+version: Linux Ubuntu 20.04
  * Compiler+version:
  * Conan version: 1.48
  * Python version: 3.9

### Steps to reproduce (Include if Applicable)

```Python
class BaseLibrary(ConanFile):
  def source(self):
    print("SRC::",os.getcwd())

  def layout(self):
    self.folders.source = "repo/test/project"
```
When I call `conan create`: the working directory in `source` is including the one from layout, which it should not according to the docs: https://docs.conan.io/en/latest/reference/conanfile/methods.html#layout
BUT the doc here says something different: https://docs.conan.io/en/latest/reference/conanfile/methods.html#source

This makes me unable to specify a subfolder in `layout`.
I want to extract the sources into the default location in  `sources()` (should be the current working dir) folder and then specify a subfolder in `layouts`...

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
base/2.1.0-3-ga808dcb634-dirty@demo/testing: Configuring sources in /home/developer/.conan/data/base/2.1.0-3-ga808dcb634-dirty/demo/testing/source/repo/tests/project
SRC:: /home/developer/.conan/data/base/2.1.0-3-ga808dcb634-dirty/demo/testing/source/repo/tests/project
```
user: gabyx
issue_11263: state: open
title: [bug] Use of find_dependency in CMakeDeps generated modules can cause early termination of script
body: ### Steps to reproduce (Include if Applicable)

* We need a package that has transitive dependencies (e.g. `pkgC` that depends on `pkgA` and `pkgB`)
* Use the new `CMakeDeps`/`CMakeToolchain` generators
* In a consumer package, ensure that we prefer finding modules (e.g. `find_package(pkgC REQUIRED MODULE)`)

* The logic in the files invoked by `FindpkgC.cmake` will eventually result in calling: `find_dependency(pkgA ...)` and `find_dependency(pkgB ...)`

The _first_ invocation of `find_dependency` will cause the entire `FindpkgC.cmake` script to finish and return to the context in which it was called. Update: only when the first dependency is not found successfully (a variable `<pkg_name>_FOUND` was not defined by the time the call finished.

This means that  for the second transitive dependency (`find_package(pkgB)`) will never be issued. This does not necessarily result in a CMake error at this stage: by the time we return control to the calling context, `xxx_FOUND` is already defined and thus cmake considers the dependency found. we may get errors at a later stage, when imported targets are referenced but never defined.

This is more nuanced if we have nested calls: they may be returning at different "levels" and not completing the logic in the generated modules.

This behaviour is observed because `find_dependency()` can only be used in _config_ mode, not in module mode, as per CMake documentation:

<img width="844" alt="Screenshot 2022-05-16 at 10 39 07" src="https://user-images.githubusercontent.com/3535649/168564501-a5dcb259-8223-4076-9189-2ee1197456da.png">

Update: this behaviour only happens when the first dependency is not found, or, more strictly speaking, when the exact `_FOUND` variable is not defined. This is the only case in which `find_dependency()` calls `return()`, as seen here: https://github.com/Kitware/CMake/blob/master/Modules/CMakeFindDependencyMacro.cmake#L58 

This can be seen with Conan as a side-effect of this issue: https://github.com/conan-io/conan/issues/11261, when a recipe overrides the `cmake_module_file_name`. 

user: jcar87
issue_11258: state: open
title: [question] Is it possible to `require` conan 1.x packages from conan 2.x recipe?
body: Currently, I can't add a requirement on a conan 1.x package because it can't find `conans` package which is downloaded after `pip install conan` but I already have installed `pip install conan --pre` and can't install 1.x version along with 2.x because pip does not allow to install multiple versions of the same package

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: xahon
issue_11254: state: open
title: [bug] conan install example doesn't work
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Redhat Enterprise Linux 7.9
  * Compiler+version: gcc 11
  * Conan version: 1.48
  * Python version: 3.10.4

### Steps to reproduce (Include if Applicable)
In the `conan install` [build options documentation](https://docs.conan.io/en/latest/reference/commands/consumer/install.html#build-options) it says you can do this:

`--build=!zlib --build` Build all packages from source, except for zlib.

However, when i tried that I would get "binary missing errors...use --build=XXX" errors for the non-excluded libraries. The workaround was to do:
```
conan install myconanfile.py --build=!abc --build=*
```
Not sure if that's a conan build, or a documentation bug
user: rconde01
issue_11250: state: open
title: [bug] Compiled program searches for binaries in non eistent path
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 21.10
  * Compiler+version: gcc 11
  * Conan version: 1.47
  * Python version: 3.9

### Steps to reproduce (Include if Applicable)

I am compiling a program whose dependencies are managed by conan. In particular imgui. My code compiles but when i run it it triggers an imgui error:

```
BspEditor: /home/conan/w/prod/BuildSingleReference/.conan/data/imgui/1.87/_/_/build/038baac88f4c7bfa972ce5adac1616bed8fe2ef4/source_subfolder/imgui.cpp:2853: void ImGui::PushStyleVar(ImGuiStyleVar, float): Assertion `0 && "Called PushStyleVar() float variant but variable is not a float!"' failed.
Aborted (core dumped)
```

The thing is there is no directory: `/home/conan/w/prod/BuildSingleReference/.conan/data/imgui/1.87/_/_/build/038baac88f4c7bfa972ce5adac1616bed8fe2ef4/source_subfolder/imgui.cpp` in my computer, in fact there isn;t even a `/home/conan` directory.

I have tried recompiling the project and eve wiping my conan directory and recompiling all dependencies. This problem persists. I am not sure what is happenning.
user: Makogan
issue_11245: state: open
title: [question] deterministic build and source dir 
body: I finally manage to achieve 100% deterministic builds. One of the issue was randomness in conan build and source directories when creating conan packages. 

The solution I used with the [old cmake build helper  ](https://docs.conan.io/en/1.43/reference/build_helpers/cmake.html) was to create directory junction and pass them to cmake instead of the conan source and build folders: 

```
mklink /J x:\ci\source\ self.source_folder
mklink /J x:\ci\build\ self.build_folder
```

```
cmake.configure(source_dir="x:\ci\source\", build_dir="x:\ci\build\")
```

Now I switched to the new conan helpers https://docs.conan.io/en/latest/reference/conanfile/tools/cmake.html and it is not possible anymore to override source_dir and build_dir. 

I tried using the layout method

```
def layout(self):
    self.folders.source = "x:\ci\source\"
    self.folders.build = "x:\ci\build\"
```
but I got blocked by source_dir not available in the layout method.

Any advices on how to achieve deterministic build and source dirs in conan.

user: boussaffawalid
issue_11242: state: open
title: [bug] Artifactory can be returning 200 for missing packages
body: ```bash
curl "http://localhost:8080/artifactory/api/conan/conan-local/v2/conans/whatever/version/aPackage/channel/revisions"
{
  "reference" : "packageName/version@aPackage/channel",
  "revisions" : [ ]
}
```

Supposing that such package name doesn't exist.

- It seems our ``conan_server`` returns 404 for this
- It seems other endpoints, like ``/search`` instead of ``/revisions`` can return a 404 too instead of an empty list (both in Artifactory and ``conan_server``)

user: memsharded
issue_11241: state: open
title: Creating package with boost python cannot link boost python numpy libs
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: Visual Studio 16 2019
  * Conan version: 1.48.0
  * Python version: 3.9 (with numpy installed)

### Steps to reproduce (Include if Applicable)
Clone the following repo [here](https://www.github.com/mpconte/sample) and run the command 

`conan create . -o boost:shared=True -o boost:without_python=False -o boost:python_executable=<Path to python 3 exe>`


### Logs 

```
LINK : warning LNK4217: symbol '??1dtype@numpy@python@boost@@QEAA@XZ (public: __cdecl boost::python::numpy::dtype::~
dtype(void))' defined in 'libboost_numpy39.lib(dtype.obj)' is imported by 'main.obj' in function 'main' [D:\software
\.conan\data\sample\1.0\sensoft\testing\build\d9a55a06050e0a7e3de1cbca38d6e88fc6fd70ca\build\code\main.vcxproj]
LINK : warning LNK4217: symbol '??1ndarray@numpy@python@boost@@QEAA@XZ (public: __cdecl boost::python::numpy::ndarra
y::~ndarray(void))' defined in 'libboost_numpy39.lib(ndarray.obj)' is imported by 'main.obj' in function 'main' [D:\
software\.conan\data\sample\1.0\sensoft\testing\build\d9a55a06050e0a7e3de1cbca38d6e88fc6fd70ca\build\code\main.vcxpr
oj]
LINK : warning LNK4217: symbol '?from_data_impl@detail@numpy@python@boost@@YA?AVndarray@234@PEAXAEBVdtype@234@AEBVob
ject@api@34@22_N@Z (class boost::python::numpy::ndarray __cdecl boost::python::numpy::detail::from_data_impl(void *,
class boost::python::numpy::dtype const &,class boost::python::api::object const &,class boost::python::api::object
const &,class boost::python::api::object const &,bool))' defined in 'libboost_numpy39.lib(ndarray.obj)' is imported
by 'main.obj' in function 'main' [D:\software\.conan\data\sample\1.0\sensoft\testing\build\d9a55a06050e0a7e3de1cbca3
8d6e88fc6fd70ca\build\code\main.vcxproj]
main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: char * __cdecl boost::python::nu
mpy::ndarray::get_data(void)const " (__imp_?get_data@ndarray@numpy@python@boost@@QEBAPEADXZ) referenced in function
main [D:\software\.conan\data\sample\1.0\sensoft\testing\build\d9a55a06050e0a7e3de1cbca38d6e88fc6fd70ca\build\code\m
ain.vcxproj]
D:\software\.conan\data\sample\1.0\sensoft\testing\build\d9a55a06050e0a7e3de1cbca38d6e88fc6fd70ca\build\Release\main
.exe : fatal error LNK1120: 1 unresolved externals [D:\software\.conan\data\sample\1.0\sensoft\testing\build\d9a55a0
6050e0a7e3de1cbca38d6e88fc6fd70ca\build\code\main.vcxproj]-->
```
user: mpconte
issue_11224: state: open
title: [feature] Issues with the CMakeToolchain generator
body: We are building custom workspace functionality for Conan 1 based on the existing code, but using CMakeToolchain and the new layout method instead of of the old layout configuration files. It's not that generic at the moment, since it's generating everything dynamically based on our project structure, so it does not need a definition yml file. It's mostly working as it should now, but there are some issues with the toolchain generator.

1. Toolchains are not really suitable for this use case. We want to use the same model that was used in the original workspaces model of using `add_subdirectory`. But that is problematic, since you can only specify the toolchain for the root level cmake file. Our current workaround for this is to just include the toolchain file, which seems to work, except for problem 2. But this is not how cmake toolchains should be used, and it's probably not guaranteed to work in the future, if more stuff is added to the toolchain. Additionally I'm not so sure about the whole idea of using toolchains for setting normal variables and project configuration, IMO toolchains should be reserved for what they actually are meant for, compiler toolchains and stuff. I think that we need a new additional generator that generates just plain cmake files with the project configuration, that can be then included manually. Then  we could include a toolchain file at the top level, if needed, and this generated cmake file in each subproject.  And when the package is actually exported, it would use both files.
1. The variables are set to the cache and not force overwritten. In our case this means that you can't use the same variable in two different projects, which means that they can't be cached. Other use cases need the cache see, https://github.com/conan-io/conan/issues/7832, but even in those cases I believe that the variables should be force set, otherwise you have to delete the cache in order to be able to change the variable from the recipe. So you should probably provide an interface for setting different variable types.
1. You can't provide a template file to the generator, only a static toolchain file. If a template file was allowed, then we would at least have a quite elegant workaround for the issue, by making a custom template that just sets normal variables instead of cache ones. Custom blocks could also be an alternative, but sadly an interface for setting that does not seem to be available either. So I think my current workaround would be to just make a custom class that overrides the internal `_template`, that's not elegant, nor future proof, but at least I think it will work.

I was also considering using cmake external projects instead of `add_subdirectory`, but sadly, the IDE integration for that is not great, so I'm not sure if that's a path I'm willing to take. I have read most of the issues related to workspaces here, and some people are suggesting that, but if you go that way with the official conan 2 integration, you should definitely make sure that the ide integration works properly. 

At least for our use cases, the way I'm doing it now seems to be solving all the issues I had with the existing implementation, and why I decided to write my own. The existing workspaces are too decoupled from the actual recipes, but by utilizing the layout and generators, everything can be shared.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: fredizzimo
issue_11218: state: open
title: [bug] Apple framework paths cached in CMake
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: macOS 12.3.1
  * Compiler+version: clang 13.0.0
  * Conan version: 1.48.0
  * Python version: 3.9.12

### Steps to reproduce (Include if Applicable)

I have a project that depends on a conanized Apple framework. That project uses conan_basic_setup from CMake to setup all conan related things. If I create the CMake cache the first time everything is ok. But if I change the version of the framework and re-run conan+cmake, the CMake cache still references the old version.  I can even delete the conan package from my local cache, re-run conan+cmake and everything seems to work fine until I try to compile it at which point it cannot find the headers for the conan package...

I've analyzed this and found that the cause of this is this call of find_library: https://github.com/conan-io/conan/blob/68378fad044c61a7537fea49c414c2e0f641c9ac/conans/client/generators/cmake_common.py#L859

Solution would be to unset the cache variable first (or use NO_CACHE, but that requires cmake >= 3.21). However I cannot tell whether this is a real bug or intentional behavior. But if it's intentional it behaves different from other libraries I have where I don't need to delete the cmake cache to update the used version.

user: ShadowIce
issue_11216: state: open
title: [bug] [Conan 2] - Better 404 error management in "conan list packages" command
body: When doing `conan list packages zlib/1.2.3#latest -r conancenter`
```
conancenter:
ERROR: 404: Not Found. [Remote: conancenter]
```
When doing: `conan list packages zlib/1.2.3#12312321 -r conancenter`

```
conancenter:
ERROR: Recipe not found: _/zlib/1.2.3/_. [Remote: conancenter]
```

Both different but kind of weird messages. Probably deserve to capture a NotFoundException somewhere.
user: lasote
labels: component: ux: No changes to core business logic
issue_11196: state: open
title: [bug] compatible_packages does not work when used with full_package_mode
body: Using the conanfile below, I'm trying to make Debug package compatible with Release. 

```
from conan import ConanFile


class DemoConan(ConanFile):
    name = "demo"
    version = "1.0.0"

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}

    def requirements(self):
        self.requires("openssl/3.0.2")

    def build(self):
        pass

    def package(self):
        pass

    def package_id(self):
        if self.settings.build_type == "Debug":
            compatible_pkg = self.info.clone()
            compatible_pkg.settings.build_type = "Release"
            self.compatible_packages.append(compatible_pkg)
```

```
conan create . -s build_type=Release
conan install demo/1.0.0@ -s build_type=Debug
```

and it works as expected!

I got this in the output,
```
demo/1.0.0: Main binary package 'b1637c67046517aa98464b47384851bd7e7fcd49' missing. Using compatible package '11f1add483c8e24b17f69a1b8eef4b9630b6f160'
```

---
Now I tried to enable `full_package_mode` in combination with `compatible_packages` , using the following `package_id` method. 

```
    def package_id(self):
        self.info.requires.full_package_mode()
        if self.settings.build_type == "Debug":
            compatible_pkg = self.info.clone()
            compatible_pkg.settings.build_type = "Release"
            self.compatible_packages.append(compatible_pkg)
```
Now it fails with this error:
```
Installing package: demo/1.0.0
Requirements
    demo/1.0.0 from local cache - Cache
    openssl/3.0.2 from 'conancenter' - Cache
    zlib/1.2.11 from local cache - Cache
Packages
    demo/1.0.0:ddc1cbd4116102e8ac9b9f24efe22b12dc141638 - Missing
    openssl/3.0.2:150778ad56d91e99abe6728021fb5e61699efb30 - Cache
    zlib/1.2.11:d98fae1010d1fb9e7f79a1e8a72bbf129d8660a2 - Cache

Installing (downloading, building) binaries...
ERROR: Missing binary: demo/1.0.0:ddc1cbd4116102e8ac9b9f24efe22b12dc141638
```

doing some debugging, I figure out that this issue only happens when the recipe have `requirements`. When I tried to remove `self.requires("openssl/3.0.2")`, `compatible_packages` works again as expected when used with `full_package_mode` 
user: boussaffawalid
issue_11185: state: open
title: [bug] conan_server authorization oddity
body: I noticed a quite unexpected and potentially dangerous oddity with the way `conan_server` handles authorization.

When a package without user and channel is uploaded like "MyPackage/1.0@" the reference gets stored with user=None.
What is odd is that `conan_server` does not check any permission-rules when the user requesting data equals the user of the ref.
This means that even if the permission rules explicitly have a rule like
```
[read_permissions]
*/*@*/*: some_user
```
an anonymous user can still read the package. Further on anonymous users can always read the package-index (`conan search...`) as those seem to be handled as ref belonging to user `None`. On the other hand, if you are logged in as some other user "some_user2", you will be denied to read the package.

This behaviour is due to a shortcut in `authorize.py` (in conans/server/service)  which reads
```
class BasicAuthorizer(Authorizer):
    """
    Reads permissions from the config file (server.cfg)
    """
....
    def check_read_conan(self, username, ref):
        """
        username: User that request to read the conans
        ref: ConanFileReference
        """
        if ref.user == username:
            return

        self._check_any_rule_ok(username, self.read_permissions, ref)
```
Here you can clearly see that rules are not checked for such cases.

This is quite unexpected, not clearly documented and this potentially dangerous.
Anonymous users will always be able to search server-contents and download packages without user/channel - no matter what the server.conf says.
user: hlewin
issue_11181: state: open
title: [question] Why does `conan search --revisions <ref>` require access to the remote?
body: I can do `conan search --revisions` and it appears (as expected) to be an offline operation just listing the contents of the cache
> xz_utils/5.2.4#0
> zlib/1.2.11#b3eaf63da20a8606f3d84602c2cfa854
> zlib/1.2.12#82202701ea360c0863f1db5008067122

and even `conan search --revisions <pattern>` works, e.g. `conan search --revisions zlib`
> zlib/1.2.11#b3eaf63da20a8606f3d84602c2cfa854
> zlib/1.2.12#82202701ea360c0863f1db5008067122

But if I make it a fully-qualified ref e.g. `conan search --revisions zlib/1.2.12@` it seems to want to connect to the associated remote (which, in this case, requires me to be on VPN)

ERROR: HTTPSConnectionPool(host='repository.deere.com', port=443): Max retries exceeded with url: /artifactory/api/conan/jdps-focus-desktop-tools-conan-local/v1/ping (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x0000025FCE7DFD00>: Failed to establish a new connection: [Errno 11001] getaddrinfo failed'))

Yet if I do establish network access, it only shows the revision I have locally, not the other ones available on the remote. It seems weird that filtering to a subset of the information suddenly needs network access that retrieving the whole list did not.

Probably related, it does not seem to be possible to do `conan search --revisions --remote <name>` to get a similar list-with revisions of the remote; am I missing any easy way to find out whether I have locally-cached recipes that are outdated (remote has a newer recipe revision)?
user: puetzk
issue_11180: state: open
title: [feature] Add self.editable_mode
body: Hi,
when using Conan with new CMakeToolchain, and with some dependencies on editable mode, the consumer project will launch the `generate` method for the dependencies into their directories.
The "legacy" generator like virtualrunenv will generate their files at the root of the editable project.

Can we have a way to detect the editable mode in `def generate` method so we can disable it completely ?
I am not sure if it used later anyway since when I remove them all is working fine.
Regards
user: dfleury2
issue_11173: state: open
title: [feature] Share credentials between remotes
body: We have over 10 different conan-remotes on one artifactory instance. All the remotes are using the same user/password.
But I have to type over 10 times the very same password for every single remote.
(I dont know why, but I must about every two weeks retype my password - for every remote)

It would be nice if different remotes could share the same credentials. 

Like:
```
    conan user -r firstremote myuser -p mypass  # like today
    conan user -r secondremote --use-same-as firstremote  # new
    conan user -r thirdremote --use-same-as firstremote   # new
```

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: naggerx
issue_11172: state: open
title: [bug] cmake presets uses different instance variable names for folders than cmake layout
body: conan 1.48

Presets uses `conanfile.source_folder` while layout uses `conanfile.folders.source`.

No CMakeUserPresets.json is generated as a result.
user: jt416
issue_11155: state: open
title: [feature] Compose applied configuration in one profile
body: From this thread:  https://github.com/conan-io/tribe/pull/34#discussion_r862742661

The idea is to provide a way to "freeze" the applied profiles (host + build) by combining all the inputs provided, so with just one file you could reproduce a build. Some ideas:

With a different command:
`conan profile compose --profile:h=foo -s:h arch=x86 -c myconf=1 --profile_out:h=profile_host_windows_x86.txt`

Directly with arguments:
`conan lock create . --profile:h=foo -s:h arch=x86 -c myconf=1 --profile_out:h=profile_host_windows_x86.txt`


user: lasote
issue_11152: state: open
title: [question] How a package can force an option value
body: <!-- What is your question? Please be as specific as possible! -->
Hello,

Here is an example:
Package A has an option `with_feature`, with no default value. 
Package B requires package A, but it works only if option `A:with_feature=True`.
Package C depends on package B. I don't want to set in package C the value of option `A:with_feature`, I want it to be defaulted to `True` because C depends on B.

I tried this in package B recipe:
`default_options = {"A:with_feature":'True'}`

But it has no effect when I do `conan install` of package C, I got this error:
`'with_feature' value not defined`

How can I enforce (at least default) the value of an option so any package that depends on my package has no need to choose option value ?

user: JonathanGirardeau
issue_11139: state: open
title: protobuf install [question] [problem]
body: I am having difficulty in using conan to install the referenced version 3.20.0 of protobuf.
I am running into linkage problems (undefined references in linking my project) which led me to dig around in the code.
I can find the version number in port_def.h and it shows version 3.19.4 (3019004)
Are you referencing the correct version? I do have [requires] protobuf/3.20.0
When I check the github version of port_def.h, it contains the number for 3.20.0 (3020000)
Is there a way to force a download of a specific version other than [requires]?
Is there a manual way to download it and then have conan install it?
I've done embedded work for years and never ventured into cmake and conan.
Using Linux Ubuntu; cross compiling to armv8 - all of which appears to be working properly
Thanks
user: DennisJump
issue_11133: state: open
title: [question] Toolchain cross building integration
body: - Conan version: 1.47.0
- OS: Ubuntu 20.04
- python 3.6

I had a similar question one year ago #8922, so I am trying again to integrate conan deeper into our building system.

I have created a conan package called  `LinaroArm64Toolchain` and a profile `linaro-aarch64-gcc10.2-linux5.4_release.txt` with the following content.

```
include(default)
[settings]
os=Linux
arch=armv8
compiler=gcc
compiler.version=10
compiler.libcxx=libstdc++11
build_type=Release

[tool_requires]
linaro-aarch64/10.2.1

[options]
[env]
```
- Now I can cross build packages with the profile without any issue, and I can see variables such as CC, CXX are populated correctly without any issue.

```
conan create . hsuan/test --profile:host=./profiles/linaro-aarch64-gcc10.2-linux5.4_release.txt --profile:build=./profiles/linux-x86_x64-build-default.txt 
```

What I would like to achieve next is building a project with toolchain integrated with conan using `CMakeToolchain`, for example:

```
conan install ../conanfile.txt --profile:host=./profiles/linaro-aarch64-gcc10.2-linux5.4_release.txt --profile:build=./profiles/linux-x86_x64-build-default.txt 
cmake -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake ..
make
```
However, it seems this still doesn't work, as `env_info` I defined in `LinaroArm64Toolchain` can't be seen `conan_toolchain.cmake`, those 2 are correct
`
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR armv8)
`

But not `CONAN_CMAKE_SYSROOT` nor `CXX`, `CC`.

Same as 1 year ago, this does work with `virtualenv`
```
conan install ../conanfile.txt --profile:host=./profiles/linaro-aarch64-gcc10.2-linux5.4_release.txt --profile:build=./profiles/linux-x86_x64-build-default.txt 
source activate.sh
cmake  ..
make
```
I wonder if there are any alternatives now? for example, if it is possible to customize `conan_toolchain.cmake` in `LinaroArm64Toolchain` ? So we can add what ever we need? Or is there any way we can create a toolchain file defined in `LinaroArm64Toolchain` when we call `conan install` without  `CMakeToolchain`?

Many thanks



user: hsuanguo
issue_11131: state: open
title: [question] How make conan invisible to  library users
body: <!-- What is your question? Please be as specific as possible! -->
- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

I use conan with  cmake generator to develop my library such as mylib and export  cmake  targets to user.
When build mylib  , I use CONAN_PKG::fmt in CMakeLists.txt,but when user link cmake target mylib,it also links to target CONAN_PKG::fmt,when user don't use conan,cmake configure failed.
I can't make CONAN_PKG::fmt PRIVATE in cmake,because mylib may export some C++ template in header files which use <fmt/fmt.h>,must visible to users.
How can I make CONAN_PKG::fmt invisible to library users?
I notice that conanfile.txt can use [imports] to gather actual libraries and headers ,but can't handle cmake targets
user: yooouxin
issue_11128: state: open
title: [feature] Specify settings in profile tool_requires recipes (e.g. android_ndk)
body: The `android-ndk` package is useful, but it's kind of annoying to use since it requires you to manually create a profile with information that is redundant (and thus error-prone) and laborious to track down.

For example:

```
[settings]
os=Android
os.api_level=30
arch=armv8
compiler=clang
compiler.version=11
compiler.libcxx=libc++
[tool_requires]
android-ndk/r24
```
How do I know which version of Clang is in ndk r24? I need to look that up, or track down the clang binary in my cache to run `clang --version`. Also, having to write `compiler=clang` is redundant and potentially error-prone since the only valid value in this case would be 'clang'. Why can't android-ndk provide that information? Especially since it's technically possible for android-ndk to use a different compiler/version based on, say, `os.api_level` (it doesn't afaik, but other recipes might do something like that)

Since profiles already support composition, I think it'd make sense to provide a way for recipes to write values for settings in `package_info`. Even if the recipe provides bad settings in certain cases, they can easily be overridden with a custom profile or CLI flags during install. 

Maybe add a `profile_info` or `profile_hints` counterpart to `package_info` that is only invoked when a recipe is used in a profile?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: AlexRamallo
issue_11115: state: open
title: [bug] Ninja Multi Config Build does not work when CONAN_CMAKE_GENERATOR is set
body: <!--
As described here
https://github.com/conan-io/conan/issues/11097
I stumbled upon a problem with Ninja Multi Config
-->

### Environment Details (include every applicable attribute)
  * Win 10 21H2
  * Any (Tested With MSVC17 and GCC 10):
  * Conan version: 1.47.0
  * Python version: 3.10

### Steps to reproduce (Include if Applicable)
This scenario is working
```
 conan install gtest/1.11.0@ --build=gtest -s build_type=Debug
 conan install gtest/1.11.0@ --build=gtest -s build_type=MinSizeRel
```

**Now clear conan cache. and open a fresh new shell**


This scenario is not working
```

export CONAN_CMAKE_GENERATOR="Ninja Multi-Config"
 conan install gtest/1.11.0@ --build=gtest -s build_type=Debug   => working
 conan install gtest/1.11.0@ --build=gtest -s build_type=MinSizeRel  =>not working

```


this does not only affect gtest but all 3rd parties that are build

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.1.6
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
ninja: error: loading 'build-MinSizeRel.ninja': Das System kann die angegebene Datei nicht finden.

gtest/1.11.0:
gtest/1.11.0: ERROR: Package '7af8278efaf3159080d185e586f1a3d1557fac37' build failed
gtest/1.11.0: WARN: Build folder C:\Users\Julian\.conan\data\gtest\1.11.0\_\_\build\7af8278efaf3159080d185e586f1a3d1557fac37
ERROR: gtest/1.11.0: Error in build() method, line 151
        cmake.build()
        ConanException: Error 1 while executing cmake --build C:\Users\Julian\.conan\data\gtest\1.11.0\_\_\build\7af8278efaf3159080d185e586f1a3d1557fac37\build_subfolder --config MinSizeRel -- -j8

```

user: Ju1He1
issue_11110: state: open
title: [question] How to generate Find<MODULE>.cmake files over CMakeDeps for meta packages
body: Hi everybody,

I have a question regarding the usage of CMakeDeps and its build_context_activated property. 

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

I'll explain the situation with a simplified example:

In our project we have a conanfile.py, where we reference a custom BuildTools Conan package in the build_requires:

```python
from conans import ConanFile
from conan.tools.cmake import CMakeDeps

class ExampleConan(ConanFile):
   settings = "os", "compiler", "build_type", "arch"
   generators = "CMakeDeps"
   build_requires = "BuildTools/0.1@user/dev"

   def generate(self):
      cmake = CMakeDeps(self)
      cmake.build_context_activated = ["BuildTools"]
      cmake.generate()
```
   
Here's the conanfile.py of the BuildTools package:

```python
from conans import ConanFile, CMake

class BuildTools(ConanFile):
   name = "BuildTools"
   version = "0.1"
   settings = "os", "compiler", "build_type", "arch"
   generators = "CMakeDeps"
   requires = ["my_package/1.0.0@user/dev", "other_package/1.0.1@user/dev"]
 ```
	  
The idea of the BuildTools package is that we collect all the required tools for the build process in one spot, so every user could just reference it in their respective conanfile.py and get all tools automatically. Some of these tools also contain some CMake scripts, which users should be able to get e.g. over find_package(my_package). Therefore we would need the Find<PKG_NAME>.cmake (or the <PKG_NAME>config.cmake) files to be generated for packages referenced inside of the BuildTools.

We've tried it out, but unfortunately these files are not generated, but we see that the BuildToolsconfig.cmake (among others) are generated for the BuildTools package, but those are without any mention of my_package and other_package. 

It works perfectly if we directly specify "my_package" and "other_package" as build_requires in ExampleConan, but we want to avoid that every user has to specify all of those tools by themselves, as those tools could be subject to change in the future.

One constraint which I should mention is that we can't apply "force_host_context" to the BuildTools, as some of the referenced tools can't be built with some of the host profiles in our configuration. 

Does anyone have an idea how to approach this issue? 

Thanks a lot!

mjcodigo


user: mjcodigo
issue_11106: state: open
title: [question] semver_direct_mode() bug
body: Hi,

The documentation mentions a bug in current implementation of the semver_direct_mode()
https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html?highlight=semver_direct_mode

Is there any workaround for this?

C -> B -> A -> icu

How to define it so that C and B depend on A using recipe_revision mode and A depends on icu at full_package_mode?

The documentation says that all the direct and indirect dependencies are shown in self.info.requires. Does it mean that every leaf module needs to define the needed revision mode for icu although the icu is not a direct dependency for those?




user: iiknd
issue_11100: state: open
title: [question] conan can't find hidden file like "._<libname>"
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

When I try to build a conan package for tensorrt, it report in build() stage, these .so cannot find
![image](https://user-images.githubusercontent.com/27768261/165236839-d8e44974-8992-4d74-8a18-bf92b53db6ab.png)

![image](https://user-images.githubusercontent.com/27768261/165236796-2e60e485-5d86-4ef1-84c2-1c24ee5bfd1e.png)

But I run "ls -a" check, these .so does exist.
How can I make conan to find this hidden files?

user: Tumb1eweed
issue_11096: state: open
title: [question] How to properly cross-compile for Android with android-ndk package?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

In the official documentation, I found the following link: [https://docs.conan.io/en/latest/integrations/cross_platform/android.html#using-android-ndk-package-tool-require](https://docs.conan.io/en/latest/integrations/cross_platform/android.html#using-android-ndk-package-tool-require), through which I learned that android-ndk can be referenced through `tool_requires`. The documentation states that when we use this package, the toolchain file and the variables required by CMake are generated. But when I execute `conan install` and then pass CMake include `conanbuildinfo.cmake`, I get the following error when I execute CMake initialization:

```
[cmake] CMake Error at /opt/homebrew/Cellar/cmake/3.23.0/share/cmake/Modules/Platform/Android-Determine.cmake:209 (message):
[cmake]   Android: Neither the NDK or a standalone toolchain was found.
[cmake] Call Stack (most recent call first):
[cmake]   /opt/homebrew/Cellar/cmake/3.23.0/share/cmake/Modules/CMakeDetermineSystem.cmake:160 (include)
[cmake]   CMakeLists.txt:24 (project)
```

Obviously, Android NDK related environment variables are not injected into CMake. Then I saw in the [description](https://conan.io/center/android-ndk?tab=recipe) of the android-ndk package that `CMakeDeps` and `CMakeToolchain` need to be specified in generators, but when I After setting up both generators and doing `conan install` I get the following error:

```
[cmake] conanfile.py (conan-cross-platform-build/None): Generator 'CMakeToolchain' calling 'generate()'
[cmake] conanfile.py (conan-cross-platform-build/None): ERROR: Traceback (most recent call last):
[cmake]   File "/usr/local/Cellar/conan/1.47.0/libexec/lib/python3.10/site-packages/conans/client/generators/__init__.py", line 177, in write_generators
[cmake]     generator.generate()
[cmake]   File "/usr/local/Cellar/conan/1.47.0/libexec/lib/python3.10/site-packages/conan/tools/cmake/toolchain/toolchain.py", line 164, in generate
[cmake]     save(self.filename, self.content)
[cmake]   File "/usr/local/Cellar/conan/1.47.0/libexec/lib/python3.10/site-packages/conan/tools/cmake/toolchain/toolchain.py", line 157, in content
[cmake]     context = self._context()
[cmake]   File "/usr/local/Cellar/conan/1.47.0/libexec/lib/python3.10/site-packages/conan/tools/cmake/toolchain/toolchain.py", line 144, in _context
[cmake]     blocks = self.blocks.process_blocks()
[cmake]   File "/usr/local/Cellar/conan/1.47.0/libexec/lib/python3.10/site-packages/conan/tools/cmake/toolchain/blocks.py", line 43, in process_blocks
[cmake]     content = b.get_rendered_content()
[cmake]   File "/usr/local/Cellar/conan/1.47.0/libexec/lib/python3.10/site-packages/conan/tools/cmake/toolchain/blocks.py", line 66, in get_rendered_content
[cmake]     context = self.values
[cmake]   File "/usr/local/Cellar/conan/1.47.0/libexec/lib/python3.10/site-packages/conan/tools/cmake/toolchain/blocks.py", line 58, in values
[cmake]     self._context_values = self.context()
[cmake]   File "/usr/local/Cellar/conan/1.47.0/libexec/lib/python3.10/site-packages/conan/tools/cmake/toolchain/blocks.py", line 308, in context
[cmake]     raise ConanException('CMakeToolchain needs tools.android:ndk_path configuration defined')
[cmake] conans.errors.ConanException: CMakeToolchain needs tools.android:ndk_path configuration defined
```

I've been tossing around for days, and I haven't been able to find a solution by constantly searching for issues, google, conan index example, etc.

The requirements are very simple. I hope to manage NDK through conan tool requires, and correctly inject various environment variables and toolchain information of NDK into my existing CMakeLists.txt and then perform cross-compilation. Because I have implemented various cross-compilation scenarios for Windows, macOS, Linux, and iOS through the existing Conan capabilities, and now it is only Android, I am very distressed.

Can someone give a complete example and tell me how to use it?
user: nmgwddj
issue_11092: state: open
title: Refactor tests with mocks of `conans.ConanFile.dependencies`
body: There are some tests with mocks of `mock.patch('conans.ConanFile.dependencies', new_callable=mock.PropertyMock) as mock_deps`. They can cause infinite loops in CI when using for example `conanfile.dependencies.host.topological_sort`. They should be migrated to integration tests.
user: lasote
issue_11091: state: open
title: [question] require dependency with any option value 
body: Hello,

I have a dependency `libA` that have an option `with_feature`, something like:
```
class DemoConan(ConanFile):
    name = "libA"
    options = {"with_feature": [True, False]}
    default_options = {"with_feature": True}
```

And I have another recipe that depends on `libA`, but it does not matter if it has `with_feature` set to true or false.
Is there a way in conan to depends on any options values for a specific dependency .

I've checked the "ANY" option value from https://docs.conan.io/en/latest/reference/conanfile/attributes.html#options which could be used somehow, but that will require altering the recipe of libA to something like:

```
class DemoConan(ConanFile):
    name = "libA"
    options = {"with_feature": "ANY"}
    default_options = {"with_feature": True}

   def package_id(self):
        if self.option.with_feature == "with_feature":
            del del self.info.options.with_feature
```

Is there a better way todo this at the consumer's level ?



user: boussaffawalid
issue_11087: state: open
title: VSCode extension
body: > Many developers are now on vs code and it's ruling IDE market according to stackoverflow survey 2019. I wish there would be conan extension for vs code.
> 
> https://insights.stackoverflow.com/survey/2019#technology-_-most-popular-development-environments

@KaungZawHtet, @jsgogo  Maybe it's a bit late to reply this thread, but I created the conan extension for VS code, and just published it a couple days ago. Maybe you can check out my extension :) I hope it could be really helpful for the community :)
Here is the link to my extension https://github.com/afri-bit/vsconan

_Originally posted by @afri-bit in https://github.com/conan-io/wishlist/issues/226#issuecomment-1107853636_
user: memsharded
labels: component: ux: No changes to core business logic
issue_11079: state: open
title: [question] Generator CMakeToolchain in conanfile.txt does not pick up compiler specified in a profile as a tool_requires
body: I have a conanfile.txt, specifying the CMakeToolchain generator:

```
...
[generators]
CMakeToolchain
```

and a compiler which exists as a conan package, and which have been added to a profile, under tool_requires:

```
...
[tool_requires]
arm_none_linux_gnueabi/4.8.3
```

Then I create the conan project files using install:

`conan install . -pr:h arm_profile -pr:b=default`

The resulting conan_toolchain.cmake file does not pick up the compiler path (C, CXX variables, e.t.c.), which should be defined as CMAKE_CXX_COMPILER in the toolchain file, for example.

Everything works OK, if I use a conanfile.py instead, and use the CMake() build helper class.

Could it perhaps be the env_info from the compiler (defined in package_info()) which are not propagated properly, when using the CMakeToolchain generator via the conanfile.txt ? Or am I simply not using it properly?
user: sveitech
issue_11076: state: open
title: [bug] Running with win_bash=True handles encoding incorrectly
body: I made an program that outputs some non-ASCII characters and it works well on Windows or inside MSYS2, but when I try to run it inside Conan by invoking the `run` method with `win_bash=True`, the output contains garbage contents. This problem makes it difficult to read the Visual Studio (with localized output) error messages during `conan build`.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 11
  * Compiler+version: Visual Studio 2019
  * Conan version: 1.47.0
  * Python version: built-in with Conan installer

### Steps to reproduce (Include if Applicable)
Create a folder with the following 2 files:
- conanfile.py
```
from conans import ConanFile, tools
import os.path


class MsysTestConan(ConanFile):
    name = "msys-test"
    version = "1.0.0"
    settings = "os", "compiler", "build_type", "arch"

    def build_requirements(self):
        self.build_requires("msys2/cci.latest")

    def build(self):
        with tools.vcvars(self):
            self.run("cl {}".format(os.path.join(self.source_folder, "main.cpp")))
            self.run("./main.exe", win_bash=True)
            self.run("main.exe")
```
- main.cpp (must be saved in `UTF-8 with BOM`)
```
#include <iostream>

using namespace std;

int main() {
    cout << "你好\n";
    cout << "Olá\n";
}
```

Run this in PowerShell:
```
mkdir build
cd build
conan install ..
conan build ..
```

The final output is
```
ÄãºÃ
Ol¨¢
你好
Olá
```

Directly running the `main.exe` in PowerShell or MSYS2 bash outputs:
```
你好
Olá
```

which shows that `self.run("./main.exe", win_bash=True)` does not prints the correct output on the console.

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
C:\Users\taoyouh\source\playgrounds\conan-encoding\build>conan install ..
```

```
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

conanfile.py (msys-test/1.0.0): Installing package
Requirements
Packages
Build requirements
    msys2/cci.latest from 'conancenter' - Cache
Build requirements packages
    msys2/cci.latest:eee3fba89db6d777329de604625af8c30d46f080 - Cache

Installing (downloading, building) binaries...
msys2/cci.latest: Already installed!
msys2/cci.latest: Creating MSYS_ROOT env var : C:\.conan\6696ea\1\bin\msys64
msys2/cci.latest: Creating MSYS_BIN env var : C:\.conan\6696ea\1\bin\msys64\usr\bin
msys2/cci.latest: Appending PATH env var with : C:\.conan\6696ea\1\bin\msys64\usr\bin
conanfile.py (msys-test/1.0.0): Applying build-requirement: msys2/cci.latest
conanfile.py (msys-test/1.0.0): Generator txt created conanbuildinfo.txt
conanfile.py (msys-test/1.0.0): Aggregating env generators
conanfile.py (msys-test/1.0.0): Generated conaninfo.txt
conanfile.py (msys-test/1.0.0): Generated graphinfo
```

```
C:\Users\taoyouh\source\playgrounds\conan-encoding\build>conan build ..
```
```
Using lockfile: 'C:\Users\taoyouh\source\playgrounds\conan-encoding\build/conan.lock'
Using cached profile from lockfile
conanfile.py (msys-test/1.0.0): Calling build()
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.11.11
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
用于 x64 的 Microsoft (R) C/C++ 优化编译器 19.29.30141 版
版权所有(C) Microsoft Corporation。保留所有权利。

main.cpp
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ostream(746): warning C4530: 使用了 C++ 异常处
理程序，但未启用展开语义。请指定 /EHsc
C:\Users\taoyouh\source\playgrounds\conan-encoding\main.cpp(6): note: 查看对正在编译的函数 模板 实例化“std::basic_ostream<char,std::char_trait
s<char>> &std::operator <<<std::char_traits<char>>(std::basic_ostream<char,std::char_traits<char>> &,const char *)”的引用
Microsoft (R) Incremental Linker Version 14.29.30141.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:main.exe
main.obj
conanfile.py (msys-test/1.0.0): run_in_windows_bash: C:\.conan\6696ea\1\bin\msys64\usr\bin\bash.exe --login -c ^"cd \^"/c/users/taoyouh/source/
playgrounds/conan-encoding/build\^" ^&^& PATH=\^"/c/.conan/6696ea/1/bin/msys64/usr/bin:$PATH\^" ^&^& ./main.exe ^"
ÄãºÃ
Ol¨¢
你好
Olá

```
user: taoyouh
issue_11071: state: open
title: [question] search / install package for any revisions matching my config
body: # Short question
Is there a way to perform a `conan search` or `conan install` that would go through all the revisions until it finds a revision where binaries were pre-built for the requested configuration ?

# Context
We started using revisions recently. Previously, when people had some CRLF in their sources files, it would make outdated packages as [explained here in the documentation](https://docs.conan.io/en/latest/faq/using.html#packages-got-outdated-when-uploading-an-unchanged-recipe-from-a-different-machine) as soon as they make conan packages for both Linux & Windows. It was relatively okay to detect it and to fix it. 

However, now we started using revisions, when people face this situation, and they only find half of the package they have just uploaded (i.e. for one OS only) when they perform a `conan search` or `conan install`. The root cause of this issue is quite hard to to detect IMO. It is possible to find out what is going wrong with `conan search <ref> --revisions` and then  `conan search <ref>#rev --table=table.html`  but it is not straightforward at all.

# Proposed solution
Would it be possible for the conan resolver to go through all the revisions until it finds a revision where binaries were pre-built for the requested configuration (settings/options) ? For instance : 
````bash
conan search foo/0.1@user/stable --all-revs --profile linux-gcc7
````

# Added value
That would fix the issue described here above, but that would also fix all the other use cases were partial builds are performed after a minor `conanfile` update (e.g. support a new configuration).



- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: vdsbenoit
issue_11056: state: open
title: [question] conan forgets authentication 
body: Hi,

I've recently updated conan client to 1.47.0 and jfrog artifactory CE to 7.37.14.

With this setup conan client keeps forgetting authentication to the jfrog artifactory server just in a few hours. With previous versions (conan/1.44.0, artifactory/7.29.8) this time period was around 30 days. Is this behavior expected? If so, how can I extend the timeout?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: bukulin
issue_11051: state: open
title: [bug] emscripten minimal example for embind fails when compiled with conan
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04.4 LTS
  * Compiler+version: clang version 10.0.0-4ubuntu1
  * Conan version: Conan version 1.47.0
  * Python version: Python 3.8.10

### Steps to reproduce (Include if Applicable)

I created a [repro](https://github.com/psarka/repro/tree/embind) repository (make sure the branch is embind). It consits of the emscripten oscilator [example](https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html#using-val-to-transliterate-javascript-to-c) with the conan definitions added to the best of my ability.

Unfortunately the best of my ability is not very good at all, so it is quite likely that I simply messed up.

Especially pay attention to the `--bind` flag in CMakeLists line 12, I may be passing it wrong. The official comand to compile the oscilator example (without conan) is using `-lembind` flag like this:

```emcc -O2 -Wall -Werror -lembind -o oscillator.html oscillator.cpp```

And it took me hours to find that *maybe* it has to be passed as `--bind`, as at least this way I can get it to compile (but not to run).

### Logs (Executed commands with output) (Include/Attach if Applicable)

conan builds fine, using the commands in the README of the repo (or using `build.sh`). But the application does not function when
opened on the browser. The console log is as follows:

```
exception thrown: ReferenceError: ___getTypeName is not defined,getTypeName@http://0.0.0.0:8000/build/repro.js:1934:17
requireRegisteredType@http://0.0.0.0:8000/build/repro.js:1942:64
__emval_as@http://0.0.0.0:8000/build/repro.js:1948:20
@http://0.0.0.0:8000/build/repro.wasm:wasm-function[20]:0x8a1
@http://0.0.0.0:8000/build/repro.wasm:wasm-function[18]:0x4de
@http://0.0.0.0:8000/build/repro.wasm:wasm-function[91]:0x1e6c
createExportWrapper/<@http://0.0.0.0:8000/build/repro.js:1554:22
callMain@http://0.0.0.0:8000/build/repro.js:2708:28
doRun@http://0.0.0.0:8000/build/repro.js:2765:31
run@http://0.0.0.0:8000/build/repro.js:2780:5
runCaller@http://0.0.0.0:8000/build/repro.js:2686:19
removeRunDependency@http://0.0.0.0:8000/build/repro.js:1462:7
receiveInstance@http://0.0.0.0:8000/build/repro.js:1643:24
receiveInstantiationResult@http://0.0.0.0:8000/build/repro.js:1660:20
```

And then another one right after:

```
Uncaught (in promise) ReferenceError: ___getTypeName is not defined
    getTypeName http://0.0.0.0:8000/build/repro.js:1934
    requireRegisteredType http://0.0.0.0:8000/build/repro.js:1942
    __emval_as http://0.0.0.0:8000/build/repro.js:1948
    createExportWrapper http://0.0.0.0:8000/build/repro.js:1554
    callMain http://0.0.0.0:8000/build/repro.js:2708
    doRun http://0.0.0.0:8000/build/repro.js:2765
    run http://0.0.0.0:8000/build/repro.js:2780
    runCaller http://0.0.0.0:8000/build/repro.js:2686
    removeRunDependency http://0.0.0.0:8000/build/repro.js:1462
    receiveInstance http://0.0.0.0:8000/build/repro.js:1643
    receiveInstantiationResult http://0.0.0.0:8000/build/repro.js:1660
```
user: psarka
issue_11047: state: open
title: [bug] conan ignores HOME env var -> uses %userprofile% on windows
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 20H2 build 19042.1586
  * Compiler+version: Visual studio 2017 (not relevant for the bug)
  * Conan version: 1.44.1
  * Python version: 3.10.1

### Steps to reproduce (Include if Applicable)

1. Set env var HOME to some arbitrary path like 'C:\\MyName\\home'
2. Execute a conan install command
3. Command succeeds -> but instead of installing in 'C:\\MyName\\home' it seems to install in %userprofile%..
4. I even double checked that python `import os; os.environ.get("HOME")` returns the right path..

Shouldn't CONAN_USER_HOME default to HOME when not set, before falling back to %userprofile% or some other default?
user: cr-dani-koretsky
issue_11042: state: open
title: [feature] Provide `conanrun.env` file when using `VirtualRunEnv` generator.
body: I use VSCode with [CMake-Tools](https://github.com/microsoft/vscode-cmake-tools) plugin to write/debug the CMake project. After the executable is generated, it needs to find those **DLL** files on Windows when using `xxx:shared=True` option. If we don't want to use **[imports](https://docs.conan.io/en/latest/reference/conanfile_txt.html#imports)** section to copy those DLL file to where executable locates, we can use `VirtualRunEnv` generator to use `PATH` to find them. According to the reply: https://github.com/conan-io/conan/issues/11040#issuecomment-1101357775

> Yes, you could use the VirtualRunEnv generator, to generate scripts that will add those paths to the PATH and after sourcing those generated scripts the system will find the dll's for those libraries, please check the [VirtualRunEnv documentation](https://docs.conan.io/en/latest/reference/conanfile/tools/env/virtualrunenv.html) for more detailed information.

However, although `VirtualRunEnv` generators provide scripts(`conanrun.(bat|sh)`) to setup the environment variables, it seems that VSCode doesn't provide the features to preload those `*.bat` or `*.sh` file in `launch.json`, dynamically. The only way to do that is to use `envFile` option to load `*.env` file to setup environment.

If `VirtualRunEnv` generator can generate `conanrun.env` additionally, that would be helpful when using `launch.json` to debug the executable. For example:

![image](https://user-images.githubusercontent.com/71438617/163899736-b94b43a6-8616-463c-9474-5c2d32117973.png)
user: hwhsu1231
issue_11041: state: open
title: [bug] Cross compiling to bare metal targets does not work with CMakeToolchain
body: Conan has os == 'Arduino' type for bare metal compilation, however when generating a project with CMakeToolchain generator and a bare metal compiler cmake fails on compiler check stage.

```
-- Check for working CXX compiler: /usr/local/bin/arm-none-eabi-g++
-- broken
```

Here is the profile I am trying to write for bare metal compilation

```
include(default)
[settings]
arch=armv6
os=Arduino
os.board=none
compiler=gcc
compiler.version=11.2
compiler.libcxx=libstdc++11
build_type=Release
[conf]
tools.build:cxxflags=[]
tools.build:cflags+=[]
[env]
CC=/usr/local/bin/arm-none-eabi-gcc
CXX=/usr/local/bin/arm-none-eabi-g++
CMAKE_SYSTEM_PROCESSOR=arm
```

The solution would be for conan to add `set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)` to conan_toolchain.cmake while generating.

The whole 'Arduino' system as far as I understand is very underdeveloped in conan, however this fix would make cross compiling for embedded targets much easier.
user: serghov
issue_11040: state: open
title: [question] Will `conan install` command modify the `PATH` environment variable in the current shell?
body: I noticed that there are some messages when running `conan install` command:

```
bzip2/1.0.8: Appending PATH environment variable: C:\.conan\a06b72\1\bin
jbig/20160605: Appending PATH environment variable: C:\.conan\f9c8e3\1\bin
libiconv/1.16: Appending PATH environment var: C:\.conan\1c71d0\1\bin
protobuf/3.17.1: Appending PATH environment variable: C:\.conan\fc2f0b\1\bin
...
```

What is the purpose of these messages? Does it mean that Conan will append those `bin` directory to the `PATH` environment variable in the current shell? But I've tried to use `echo %PATH%` to print it out after installing. It didn't show those directories.

![image](https://user-images.githubusercontent.com/71438617/163795518-464ed0ac-cde6-4e92-a3ab-6a2300a60d13.png)



user: hwhsu1231
issue_11033: state: open
title: [bug] kill/crash conan process leaves a lock file containing count -1
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows Server 2012
  * Compiler+version: VS 2017 MSBuild (`17:21:17  Microsoft (R) Build Engine version 16.9.0+5e4b48a27 for .NET Framework`)
  * Conan version: 1.44.1
  * Python version: 2.7.14

### Steps to reproduce (Include if Applicable)

1. Run a conan install command on many packages
2. Kill the conan process in the middle - specifically while a lock file remains
3. Try to run another conan process later - it will fail
4. Try to run "remove locks" -> it will succeed but the count still remains at -1 **[minus one]**

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
16:43:59  gtest/1.10.0@google/stable is locked by another concurrent conan process, wait...
16:43:59  If not the case, quit, and do 'conan remove --locks'
17:20:31  conanfile.txt: Installing package
```

Basically - even running conan remove --locks doesn't help.


Is anyone aware of such a bug?

### Executive summary
Conan dying mid-operation sometimes leaks lock files, even `conan remove --locks` doesn't fix it (and too late anyways, after jobs are indefinitely stuck until intervention).

I think a simple "pid stored in the lock file" can prevent such infinite deadlocks.
Bonus - we avoid the sketchy `conan remove --locks` command which doesn't even help here.

Our only workaround currently is to delete the lock file itself directly..

I'm thinking of the Linux Daemon style classic "If the pid is not alive - just take over the file".
WDYT?
user: cr-dani-koretsky
issue_11032: state: open
title: [question] Trouble linking dependency library package which depends on precompiled libraries.
body: Hello, I have been trying with success to package some precompiled libraries. However, there is a behavior I don't understand. Maybe someone can shed some light on this.

I wanted to package some precompiled libraries (SimConnect), so that they can be consumed by other packages. I have created two packages, one which links to the precompiled libraries and the other one which consumes the first one:

- simconnect_package --> packages precompiled libraries
- simconnect_package_consumer --> consumes precompiled libraries through simconnect_package

This seems to work well, however, if simconnect_package provides some functionality, for instance, if I wanted to make a wrapper for the SimConnect libraries, the simconnect_package library itself is not found when building simconnect_package_consumer. So, from simconnect_package_consumer I have access to the precompiled libraries (thanks to simconnect_package) but I have no access to simconnect_package functionality itself. 

I am using the cmake_find_package_multi generator. After a few hours of trying to make things work, I found out that while the precompiled libraries are found by find_package(simconnect_package) in the simconnect_package_consumer's CMakeLists file, the simconnect_package libraries itself are not found. Hence, they aren't linked and so, any functions referenced in the consumer package result in unresolved external symbols.

I have made a working sample here:

- [simconnect_packaging_working_example](https://github.com/aarangop/simconnect_packaging_working_example.git)

The precompiled simconnect libraries are found within the repo. These are freely available through the Prepar3D SDK.

This are my settings (default profile):
```
[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=Visual Studio
compiler.version=16
build_type=Release
[options]
[conf]
[build_requires]
[env]
```

And this is the list of commands that I've used (after cloning repo and cd'ing to it):

```
cd .\simconnect_package\
mkdir build
cd build
conan install ..
conan create ..
cd ../../
cd .\simconnect_package_consumer\
mkdir build
cd build
conan install .. --build=missing
conan build ..
.\Release\simconnect_consumer.exe
```

The exe should run, but you should get a message reporting failure to open connection, since I assume you don't have Prepar3D v5 on your machine.

The simconnect_package package is successfully exported, simconnect_package_consumer is successfully built and I can run the compiled simconnect_consumer.exe, which uses the precompiled libraries.

So, maybe someone can explain this behavior? Why are the simconnect_package libraries not found by find_package() but the precompiled libraries are?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: aarangop
issue_11030: state: open
title: [bug] --require-override does not work for local dev workflow 
body: `--require-override` works when creating conan package, `conan create` but it fail for local development workflow when running `conan install <source_dir>`


### Environment Details
  * Conan version: 1.47.0

### Steps to reproduce
using this conanfile.py
```
class DemoConan(ConanFile):
    name = "demo"
    version = "1.0.0"

    # Binary configuration
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}

    def requirements(self):
        self.requires("openssl/3.0.2")

    def build(self):
        pass

    def package(self):
        pass
```


`conan create . --require-override  openssl/3.0.1` works as expected. However, when running `conan install <source_dir> --require-override  openssl/3.0.1`  I got this error

```
ERROR: conanfile.py (demo/1.0.0): Error in requirements() method, line 45
	self.requires("openssl/3.0.2")
	ConanException: Duplicated requirement openssl/3.0.1 != openssl/3.0.2
```


### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: boussaffawalid
issue_11026: state: open
title: [question] option `shared` in profile for creating a package
body: When `conan create`, I'd like shared builds.
1. Is it ok to set it in a profile?
2. which one as below is right?
```
[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=Visual Studio
compiler.version=17
compiler.cppstd=17
build_type=Debug
[options]
shared=True
[build_requires]
[env]
```
or
```
[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=Visual Studio
compiler.version=17
compiler.cppstd=17
build_type=Debug
[options]
*:shared=True
[build_requires]
[env]
```
3. recipe, profile, conanfile.txt all can set option `shared`, who override who?

user: playgithub
issue_11021: state: open
title: [bug] Build context dependency options are ignored/overrided by host context
body: Hello,

With the following `conanfile.txt` :

``` ini
[requires]
openssl/1.1.1n

[generators]
...
```

The output of `conan install` is :

``` ini
Configuration (profile_host):
[settings]
arch=x86
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=4.8
os=Linux
[options]
[build_requires]
*: cmake/3.22.3
[env]
[conf]

Configuration (profile_build):
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=10
os=Linux
[options]
[build_requires]
[env]
[conf]

conanfile.txt: Installing package
Requirements
    openssl/1.1.1n from 'conancenter' - Cache
Packages
    openssl/1.1.1n:38baae540f0b20cdabf5788f5e782871b619db94 - Missing
Build requirements
    cmake/3.22.3 from 'conancenter' - Cache
    openssl/1.1.1n from 'conancenter' - Cache
Build requirements packages
    cmake/3.22.3:5c09c752508b674ca5cb1f2d327b5a2d582866c8 - Cache
    openssl/1.1.1n:19729b9559f3ae196cad45cb2b97468ccb75dcd1 - Download
...
```

Now, if I add the following to `conanfile.txt`
``` ini
[options]
openssl:shared=True
```

**or** add `-o:h openssl:shared=True -o:b openssl:shared=False` to the command, it affects *both* openssl hashes :

```
Requirements
    openssl/1.1.1n from 'conancenter' - Cache
Packages
    openssl/1.1.1n:3ab24ba28560454a0301dcbf33090353b0828a30 - Missing
Build requirements
    cmake/3.22.3 from 'conancenter' - Cache
    openssl/1.1.1n from 'conancenter' - Cache
Build requirements packages
    cmake/3.22.3:5c09c752508b674ca5cb1f2d327b5a2d582866c8 - Cache
    openssl/1.1.1n:d0c219631d7c692d7a95436cf4e11fe2891dc312 - Download
```

Aren't the following two lines inconsistent ?

`cmake/3.22.3:5c09c752508b674ca5cb1f2d327b5a2d582866c8` (openssl:shared=False)
`openssl/1.1.1n:d0c219631d7c692d7a95436cf4e11fe2891dc312` (openssl:shared=True)

Shouldn't it be `openssl/1.1.1n:19729b9559f3ae196cad45cb2b97468ccb75dcd1` (openssl:shared=False) ?

### Environment

- Ubuntu 18
- Conan 1.47.0
- Python 3.6.9


Thank you in advance.

Danny
user: DannyLihard
issue_11020: state: open
title: [question] Linking issue while try to create package dependent of other package 
body: Hi, I've tried to create package for OpenVINO project( https://github.com/openvinotoolkit/openvino )

I've made `conanfile.py` in OpenVINO:
```
from conans import ConanFile, CMake

class OpenvinoConan(ConanFile):
    name = "openvino"
    version = "2022.1"
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of Openvino here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}
    generators = ["cmake", "CMakeToolchain", "CMakeDeps", "cmake_paths"]
    exports_sources = ["cmake/*",  "ngraph/*", "scripts/*", "src/*", "thirdparty/*", "tools/*", "CMakeLists.txt"]
  
    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def requirements(self):
        self.requires("onnx/1.11.0")

    def configure_cmake(self):
        self.cmake = CMake(self)
        self.cmake.verbose = True
        self.cmake.definitions["ENABLE_INTEL_CPU"] = "ON"
        self.cmake.definitions["ENABLE_INTEL_CPU"]="ON" 
        self.cmake.definitions["ENABLE_INTEL_GPU"]="OFF" 
        self.cmake.definitions["ENABLE_INTEL_GNA"]="OFF" 
        self.cmake.definitions["ENABLE_INTEL_MYRIAD"]="OFF" 
        self.cmake.definitions["ENABLE_OPENCV"]="OFF" 
        self.cmake.definitions["ENABLE_TESTS"]="OFF" 
        self.cmake.definitions["ENABLE_BEH_TESTS"]="OFF" 
        self.cmake.definitions["ENABLE_FUNCTIONAL_TESTS"]="OFF" 
        self.cmake.definitions["ENABLE_PROFILING_ITT"]="OFF" 
        self.cmake.definitions["ENABLE_SAMPLES"]="OFF" 
        self.cmake.definitions["ENABLE_PYTHON"]="OFF" 
        self.cmake.definitions["PYTHON_EXECUTABLE"] ="/usr/bin/python3" 
        self.cmake.definitions["ENABLE_CPPLINT"]="OFF" 
        self.cmake.definitions["ENABLE_NCC_STYLE"]="OFF" 
        self.cmake.definitions["ENABLE_OV_PADDLE_FRONTEND"]="OFF" 
        self.cmake.definitions["ENABLE_OV_TF_FRONTEND"]="OFF" 
        self.cmake.definitions["ENABLE_TESTS"]="OFF"
        self.cmake.definitions["CMAKE_EXPORT_NO_PACKAGE_REGISTRY"] = "OFF"
        self.cmake.definitions["ENABLE_TEMPLATE"] = "OFF"
        self.cmake.definitions["ENABLE_INTEL_MYRIAD_COMMON"] = "OFF"
        self.cmake.definitions["CMAKE_CXX_FLAGS"] = "-Wno-error=undef -Wno-error=suggest-override"
        self.cmake.definitions["CMAKE_C_FLAGS"] = "-Wno-error=undef -Wno-error=suggest-override"
        self.cmake.configure()

    def build(self):
        self.configure_cmake()
        self.cmake.build()

    def package(self):
        self.cmake.install()

    def package_info(self):
        self.cpp_info.libs = ["openvino"]
        self.cpp_info.build_modules["cmake_find_package"].append("cmake/Findopenvino.cmake")
        self.cpp_info.includedirs = ["runtime/include", "runtime/include/ie", "runtime/include/ngraph", "runtime/include/openvino"]
        self.cpp_info.libdirs = ["runtime/lib/intel64", "runtime/3rdparty/tbb_bind_2_5/lib"]
```
OpenVINO has structure that the external libraries are used as a submodules to create package. I've changed that `ONNX` and `Protobuf` are taken from conan packages (conancenter)
The package has been created correctly.

```
akulikow@akulikow-ubuntu20 ~/projects/openvino/build (conan*?) $ conan search
Existing package recipes:

onnx/1.11.0
openvino/2022.1
protobuf/3.17.1
zlib/1.2.11
```

Additionally I've created small project which use created package
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.20)
project(testApp)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

set(SOURCE ${CMAKE_SOURCE_DIR}/src/main.cpp)

add_executable(${PROJECT_NAME} ${SOURCE})
find_package(openvino)

target_link_libraries(${PROJECT_NAME} PUBLIC openvino::openvino)
```
conanfile.py
```
from conans import ConanFile, CMake, tools


class ConanexampleConan(ConanFile):
    name = "conanexample"
    version = "0.1"
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of Conanexample here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}
    generators = ["cmake", "CMakeToolchain", "CMakeDeps"]
    exports_sources = ["src/*", "CMakeLists.txt"]

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def requirements(self):
        self.requires("openvino/2022.1")

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def imports(self):
        self.copy("*.dll", dst="bin", src="bin")
        self.copy("*.dylib*", dst="bin", src="lib")
        self.copy('*.so*', dst='bin', src='lib')

    def package(self):
        self.copy("*.h", dst="include", src="src")
        self.copy("*hello.lib", dst="lib", keep_path=False)
        self.copy("*.dll", dst="bin", keep_path=False)
        self.copy("*.so", dst="lib", keep_path=False)
        self.copy("*.dylib", dst="lib", keep_path=False)
        self.copy("*.a", dst="lib", keep_path=False)

    def package_info(self):
        self.cpp_info.libs = ["testapp"]
```
main.cpp
```
#include "openvino/openvino.hpp"

int main() {
    ov::Core core;
    return 0;
}
```

When I try to make package by: `conan create .` I see a lot of linking errors. 
Part of output of creating package:
```
Exporting package recipe
conanexample/0.1 exports_sources: Copied 1 '.cpp' file: main.cpp
conanexample/0.1 exports_sources: Copied 1 '.txt' file: CMakeLists.txt
conanexample/0.1: The stored package has not changed
conanexample/0.1: Exported revision: 8b9602c0dfcb12853fe3a7e2c7961b99
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=9
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

conanexample/0.1: Forced build from source
Installing package: conanexample/0.1
Requirements
    conanexample/0.1 from local cache - Cache
    onnx/1.11.0 from 'conancenter' - Cache
    openvino/2022.1 from local cache - Cache
    protobuf/3.17.1 from 'conancenter' - Cache
    zlib/1.2.11 from 'conancenter' - Cache
Packages
    conanexample/0.1:abcefe982f9f165589b73acce478e033970f75f7 - Build
    onnx/1.11.0:4336b64591025595c27a62d8ffedf1b08096ebeb - Cache
    openvino/2022.1:05efaa477688a30b0e70009e5e54cf9af21893e5 - Cache
    protobuf/3.17.1:645a1e1c64ed36f82391f6d395fec125f43abcdd - Cache
    zlib/1.2.11:6af9cc7cb931c5ad942174fd7838eb655717c709 - Cache

Installing (downloading, building) binaries...
zlib/1.2.11: Already installed!
protobuf/3.17.1: Already installed!
protobuf/3.17.1: Appending PATH environment variable: /home/akulikow/.conan/data/protobuf/3.17.1/_/_/package/645a1e1c64ed36f82391f6d395fec125f43abcdd/bin
onnx/1.11.0: Already installed!
openvino/2022.1: Already installed!
conanexample/0.1: Copying sources to build folder
conanexample/0.1: Building your package in /home/akulikow/.conan/data/conanexample/0.1/_/_/build/abcefe982f9f165589b73acce478e033970f75f7
conanexample/0.1: Generator 'CMakeToolchain' calling 'generate()'
conanexample/0.1: Generator cmake created conanbuildinfo.cmake
conanexample/0.1: Generator 'CMakeDeps' calling 'generate()'
conanexample/0.1: Aggregating env generators
conanexample/0.1 imports(): Copied 2 '.so' files: libonnxifi_dummy.so, libonnxifi.so
conanexample/0.1: Calling build()
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan: Adjusting fPIC flag (ON)
-- Conan: Compiler GCC>=5, checking major version 9
-- Conan: Checking correct version: 9
-- Conan: C++ stdlib: libstdc++
-- Conan: Target declared 'openvino::openvino'
-- Conan: Component target declared 'onnx_proto'
-- Conan: Component target declared 'onnxifi'
-- Conan: Component target declared 'onnxifi_dummy'
-- Conan: Component target declared 'onnxifi_loader'
-- Conan: Component target declared 'onnxifi_wrapper'
-- Conan: Component target declared 'onnx'
-- Conan: Target declared 'onnx::onnx'
-- Conan: Component target declared 'protobuf::libprotobuf'
-- Conan: Component target declared 'protobuf::libprotoc'
-- Conan: Target declared 'protobuf::protobuf'
-- Conan: Target declared 'ZLIB::ZLIB'
-- Conan: Including build module from '/home/akulikow/.conan/data/protobuf/3.17.1/_/_/package/645a1e1c64ed36f82391f6d395fec125f43abcdd/lib/cmake/protobuf/protobuf-generate.cmake'
-- Conan: Including build module from '/home/akulikow/.conan/data/protobuf/3.17.1/_/_/package/645a1e1c64ed36f82391f6d395fec125f43abcdd/lib/cmake/protobuf/protobuf-module.cmake'
-- Conan: Including build module from '/home/akulikow/.conan/data/protobuf/3.17.1/_/_/package/645a1e1c64ed36f82391f6d395fec125f43abcdd/lib/cmake/protobuf/protobuf-options.cmake'
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_EXPORT_NO_PACKAGE_REGISTRY
    CMAKE_INSTALL_BINDIR
    CMAKE_INSTALL_DATAROOTDIR
    CMAKE_INSTALL_INCLUDEDIR
    CMAKE_INSTALL_LIBDIR
    CMAKE_INSTALL_LIBEXECDIR
    CMAKE_INSTALL_OLDINCLUDEDIR
    CMAKE_INSTALL_SBINDIR


-- Build files have been written to: /home/akulikow/.conan/data/conanexample/0.1/_/_/build/abcefe982f9f165589b73acce478e033970f75f7
[ 50%] Building CXX object CMakeFiles/testApp.dir/src/main.cpp.o
[100%] Linking CXX executable bin/testApp
/usr/bin/ld: /home/akulikow/.conan/data/openvino/2022.1/_/_/package/05efaa477688a30b0e70009e5e54cf9af21893e5/runtime/lib/intel64/libopenvino.a(ie_core.cpp.o): in function `InferenceEngine::Core::ReadNetwork(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) const':
ie_core.cpp:(.text._ZNK15InferenceEngine4Core11ReadNetworkERKSbIwSt11char_traitsIwESaIwEES6_+0x3a): undefined reference to `ov::util::wstring_to_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)'
/usr/bin/ld: ie_core.cpp:(.text._ZNK15InferenceEngine4Core11ReadNetworkERKSbIwSt11char_traitsIwESaIwEES6_+0x45): undefined reference to `ov::util::wstring_to_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)'
/usr/bin/ld: /home/akulikow/.conan/data/openvino/2022.1/_/_/package/05efaa477688a30b0e70009e5e54cf9af21893e5/runtime/lib/intel64/libopenvino.a(ie_core.cpp.o): in function `std::unique_ptr<pugi::xml_document, std::default_delete<pugi::xml_document> >::~unique_ptr()':
ie_core.cpp:(.text._ZNSt10unique_ptrIN4pugi12xml_documentESt14default_deleteIS1_EED2Ev[_ZNSt10unique_ptrIN4pugi12xml_documentESt14default_deleteIS1_EED5Ev]+0x11): undefined reference to `pugi::xml_document::~xml_document()'
/usr/bin/ld: /home/akulikow/.conan/data/openvino/2022.1/_/_/package/05efaa477688a30b0e70009e5e54cf9af21893e5/runtime/lib/intel64/libopenvino.a(ie_core.cpp.o): in function `ov::Core::read_model(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) const':
ie_core.cpp:(.text._ZNK2ov4Core10read_modelERKSbIwSt11char_traitsIwESaIwEES6_+0x48): undefined reference to `ov::util::wstring_to_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)'
/usr/bin/ld: ie_core.cpp:(.text._ZNK2ov4Core10read_modelERKSbIwSt11char_traitsIwESaIwEES6_+0x58): undefined reference to `ov::util::wstring_to_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)'
/usr/bin/ld: /home/akulikow/.conan/data/openvino/2022.1/_/_/package/05efaa477688a30b0e70009e5e54cf9af21893e5/runtime/lib/intel64/libopenvino.a(ie_core.cpp.o): in function `ov::detail::load_extensions(std::string const&)':
ie_core.cpp:(.text._ZN2ov6detail15load_extensionsERKSs[_ZN2ov6detail15load_extensionsERKSs]+0x31): undefined reference to `ov::util::load_shared_object(char const*)'
/usr/bin/ld: ie_core.cpp:(.text._ZN2ov6detail15load_extensionsERKSs[_ZN2ov6detail15load_extensionsERKSs]+0x5c): undefined reference to `ov::util::get_symbol(std::shared_ptr<void> const&, char const*)'
/usr/bin/ld: /home/akulikow/.conan/data/openvino/2022.1/_/_/package/05efaa477688a30b0e70009e5e54cf9af21893e5/runtime/lib/intel64/libopenvino.a(ie_core.cpp.o): in function `ov::Core::add_extension(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)':
ie_core.cpp:(.text._ZN2ov4Core13add_extensionERKSbIwSt11char_traitsIwESaIwEE+0x2c): undefined reference to `ov::util::wstring_to_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)'
/usr/bin/ld: /home/akulikow/.conan/data/openvino/2022.1/_/_/package/05efaa477688a30b0e70009e5e54cf9af21893e5/runtime/lib/intel64/libopenvino.a(ie_core.cpp.o): in function `ParseXml(char const*)':
ie_core.cpp:(.text._Z8ParseXmlPKc[_Z8ParseXmlPKc]+0x4f): undefined reference to `ov::util::string_to_wstring(std::string const&)'
/usr/bin/ld: ie_core.cpp:(.text._Z8ParseXmlPKc[_Z8ParseXmlPKc]+0x82): undefined reference to `pugi::xml_document::xml_document()'
/usr/bin/ld: ie_core.cpp:(.text._Z8ParseXmlPKc[_Z8ParseXmlPKc]+0x9d): undefined reference to `pugi::xml_document::load_file(wchar_t const*, unsigned int, pugi::xml_encoding)'
/usr/bin/ld: ie_core.cpp:(.text._Z8ParseXmlPKc[_Z8ParseXmlPKc]+0x3d6): undefined reference to `pugi::xml_parse_result::description() const'
/usr/bin/ld: ie_core.cpp:(.text._Z8ParseXmlPKc[_Z8ParseXmlPKc]+0x50a): undefined reference to `pugi::xml_document::~xml_document()'
/usr/bin/ld: /home/akulikow/.conan/data/openvino/2022.1/_/_/package/05efaa477688a30b0e70009e5e54cf9af21893e5/runtime/lib/intel64/libopenvino.a(ie_core.cpp.o): in function `(anonymous namespace)::getStaticPluginsRegistry()':
ie_core.cpp:(.text._ZN12_GLOBAL__N_124getStaticPluginsRegistryEv+0x117): undefined reference to `CreatePluginEngineHETERO'
/usr/bin/ld: ie_core.cpp:(.text._ZN12_GLOBAL__N_124getStaticPluginsRegistryEv+0x1fb): undefined reference to `CreatePluginEngineCPU'
/usr/bin/ld: ie_core.cpp:(.text._ZN12_GLOBAL__N_124getStaticPluginsRegistryEv+0x224): undefined reference to `CreateExtensionSharedCPU'
/usr/bin/ld: ie_core.cpp:(.text._ZN12_GLOBAL__N_124getStaticPluginsRegistryEv+0x2f9): undefined reference to `CreatePluginEngineMULTI'
/usr/bin/ld: ie_core.cpp:(.text._ZN12_GLOBAL__N_124getStaticPluginsRegistryEv+0x5bc): undefined reference to `CreatePluginEngineBATCH'
/usr/bin/ld: /home/akulikow/.conan/data/openvino/2022.1/_/_/package/05efaa477688a30b0e70009e5e54cf9af21893e5/runtime/lib/intel64/libopenvino.a(ie_core.cpp.o): in function `ov::CoreImpl::RegisterPluginsInRegistry(std::string const&)':
ie_core.cpp:(.text._ZN2ov8CoreImpl25RegisterPluginsInRegistryERKSs[_ZN2ov8CoreImpl25RegisterPluginsInRegistryERKSs]+0x8d): undefined reference to `pugi::xml_document::document_element() const'
...
```

It looks that it has some problem with linking libraries inside OpenVINO. Do you know what can cause that kind of issue? 
Maybe should I somehow export internal libraries to the package?  

thanks in advance for your help :)

user: artkuli
issue_11019: state: open
title: [bug] os.version is not passed to objective C compiler/linker flags
body: I noticed this issue when I tried to install glib/2.72.0 from conan center on MacOS with ` -s os.version=10.12 `. I found out that produced glib libraries does not contain minimum version applied as I specified. 

After digging into meson generated ` build.ninja ` I noticed that ` -mmacosx-version-min=10.12 ` flag is NOT added to ` objc_COMPILER ` and `objc_LINKER ` set of flags. Not sure if this is Conan or Meson issue.

### Environment Details (include every applicable attribute)
  * Operating System+version: MacOS 12.2.1
  * Compiler+version: apple-clang 12.0.0
  * Conan version: 1.47.0
  * Python version: 3.9.8

### Steps to reproduce (Include if Applicable)
Command used to install glib: ` conan install glib/2.72.0@ -s os.version=10.12 -o glib:shared=True --build missing `

Output of the ` otool -l libglib-2.0.0.dylib `:
```
...
Load command 9
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform 1
    minos 11.1
      sdk 11.1
   ntools 1
     tool 3
  version 609.8
...
```

user: bkarasm
issue_11010: state: open
title: [bug] Overriding requires of tool_requires does not work
body: I have package (using a conanfile.py) which has multiple tool requires. One is `protobuf` and another one if a custom tool which requires `libarchive`.  
Now since [this commit](https://github.com/conan-io/conan-center-index/commit/c166e63ef4254ee2259813428754be9bfe0aa09a) bumped zlib in `protobuf` my package does not build anymore. And I cannot find any way to override the requirements.

The [documentation](https://docs.conan.io/en/latest/devtools/build_requires.html?highlight=rule%20thumb#declaring-tool-requirements) states that "As a rule of thumb, downstream defined values always override upstream dependency values" but even if I add `zlib/1.2.12` as `tool_requires` in my conanfile.py I get an error.

### Environment Details (include every applicable attribute)
  * Operating System+version: KUbuntu 21.04
  * Compiler+version: gcc 10.3
  * Conan version: 1.47.0
  * Python version: 3.9.5

### Steps to reproduce (Include if Applicable)
Create `conanfile.py` with
```
    tool_requires = [
        "protobuf/3.19.2",
        "libarchive/3.6.0",
    ]
```

### Logs (Executed commands with output) (Include/Attach if Applicable)
<details>

```
ERROR: Conflict in libarchive/3.4.0:
    'libarchive/3.4.0' requires 'zlib/1.2.11' while 'protobuf/3.19.2' requires 'zlib/1.2.12'.
    To fix this conflict you need to override the package 'zlib' in your root package.
```
or (when adding `zlib` explicit to `tool_requires`)
```
ERROR: Conflict in libarchive/3.4.0:
    'libarchive/3.4.0' requires 'zlib/1.2.11' while 'conanfile.py (MyPackage/1.2.3)' requires 'zlib/1.2.12'.
    To fix this conflict you need to override the package 'zlib' in your root package.
```
</details>

user: Psy-Kai
issue_11006: state: open
title: [question] per-developer configured build folder
body: Hi,
On my local machine, I use a build folder convention that uses `cmake-build-debug` and `cmake-build-release`. However, my CI process uses a different layout (e.g. /tmp/build). Additionally I don't want to force developers building my library to use the `cmake-build-*` convention. Specifying the `layout()` in absolute terms will dictate the convention the person building the software will use. Additionally, it may not work with different IDEs.

I have looked at issue #10356 which comes close to working for my use case. However, it does not seem to work with editable packages -- if I set `self.folders.build  = "."`, the consuming package searches for libraries, etc at `/path/to/editable/package/.` instead of `/path/to/editable/package/cmake-build-debug/.` or `/path/to/editable/package/cmake-build-release/.`.

One option would be to provide `-of cmake-build-debug` or `-of cmake-build-release` to `conan editable add`; however, then, how can I differentiate between debug or release? I need to test both in my consuming project.

Finally, I have tried to use the editable layouts file (in fact this worked before if I left `layout()` blank, but doesn't work on newer versions of conan because the generator folder is `None` (#11005)). However this file seems to be ignored if `layout()` is specified.

Thank you very much!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: n-morales
issue_11005: state: open
title: [bug] python exception when consuming editable package with CMakeDeps
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Linux Mint 20.3
  * Compiler+version: gcc 11.2
  * Conan version: 1.47.0
  * Python version: 3.8.10

### Steps to reproduce (Include if Applicable)
1. Create a conanfile.py, omitting the `layout()` and using the CMakeDeps/CMakeToolchain generator
2. `conan editable add /path/to/package package-name@channel/stable`
3. List the package as a dependency in another project using CMakeDeps/CMakeToolchain
4. Run conan install, it fails

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
ERROR: package-name@channel/stable: Error in generate() method, line 45
        tc.generate()
        TypeError: expected str, bytes or os.PathLike object, not NoneType
```

After some python debugging, I found that what was happening is that `self.folders.generators` is `None`, causing the error. Either this should be made clear that you have to define it, or it is a problem with editable packages. This issue doesn't show up with just installing the first package. The workaround is to define `self.folders.generators` in the `layout()` method.

user: n-morales
issue_11002: state: open
title: [bug] conan install command fails to find prebuilt binaries after revisions_enabled changed in config
body: Conan version: any; OS: any.

Steps to reproduce:
1. disable conan package revisions: `conan config set general.revisions_enabled=False`
2. remove `some_package` from cache
3. execute `conan install <some_package> <some_package_options>`
4. enable conan package revisions: `conan config set general.revisions_enabled=True`
5. execute `conan install <some_package> <some_OTHER_package_options> --build=never`

Result:
`ERROR: Missing prebuilt package for 'some_package'` and 
```
Build requirements packages
    <some_package>:<hash> - Missing
```

Expected:
IMO conan should handle change of `revisions_enabled` by updating conanfile.py in cache to regarding package  revisions or at least indicate the actual core problem in error message. Current error message of `Missing prebuilt package` package is IMO confusing and misleading in this case.
user: apyvovar
issue_11001: state: open
title: [feature] less verbose output in CMakeDeps
body: I think CMakeToolchain is too verbose and it would be better to skip these messages.

![Screen Shot 2022-04-09 at 11 12 40 AM](https://user-images.githubusercontent.com/7117696/162567546-37d83801-4b81-43b7-a15b-36374c874d82.png)


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: boussaffawalid
labels: component: ux: No changes to core business logic
issue_10998: state: open
title: [bug] Windows installer package is missing python modules (site / pefile)
body: The Windows installer package is broken since probably version 1.44.0. It doesn't include the full Python standard library anymore and produces the following error message:

```
ModuleNotFoundError: No module named 'site'
ModuleNotFoundError: No module named 'pefile'
```

This bug seems to be related to #10386.

### Environment Details (include every applicable attribute)
Operating System+version: Windows 10 20H2
Compiler+version: not relevant
Conan version: 1.47.0
Python version: not relevant since the windows installer package is used

### Steps to reproduce (Include if Applicable)

Create a simple conanfile.py:

```
from conans import ConanFile
import site  # comment out 'site' to test import pefile
#import pefile

class DemoConan(ConanFile):
    name = "demo"
    version = "1.0.0"
    settings = "os", "build_type", "compiler", "arch"

```

Run any conan command with the conanfile. For example `conan info conanfile.py`.

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
C:\Temp\demo>conan info .
ERROR: Error loading conanfile at 'C:\Temp\demo\conanfile.py': Unable to load conanfile in C:\Temp\demo\conanfile.py
  File "<frozen importlib._bootstrap>", line 684, in _load
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "C:\Temp\demo\conanfile.py", line 2, in <module>
    import site
ModuleNotFoundError: No module named 'site'
```

user: lucabonifacio
issue_10995: state: open
title: [question] Is it possible that a package can override/adjust the compiler/settings for its dependencies?
body: Is it possible that a package can define/override (hardcode) the compiler(settings) for its required dependencies?

We have a consumer `U`:
- who needs package `A`(maintained by us) 
- which needs `B`(zeromq) 
- which needs package `C`(libsodium).

So far with a Conan profile which consumer `U` uses for Windows and `Visual Studio 22`, the package `C` in the chain does not exist and can also not build from source because its not supported.
Is there any way such that consumer `U` or even better the developers for package `A` can define
an exception such that `A`, when definings its requirements in `requires`, overwrites the `settings.compiler` for package `C`.  

So far user `U` can of course define these overrides in his profile, but actually user `U` does not want to 
know this. Is there a way for the maintainers of package `A`?

Thanks very much.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: gabyx
issue_10979: state: open
title: [bug] The new VirtualRunEnv never clean the deactivate script (it should use a temp deactivate file)
body: ### Environment Details
  * Operating System+version: Linux (archlinux)
  * Conan version: 1.47.0
  * Python version: 3.9

### Steps to reproduce (Include if Applicable)
`conanfile.txt`:
```
[requires]
fmt/8.0.0
# testing only deps below
doctest/2.4.6

[generators]
CMakeToolchain
CMakeDeps
VirtualRunEnv
```

```sh
$ conan install . --install-folder=.conanvirtualenv --build=missing --profile:build=default
$ source .conanvirtualenv/conanrun.sh
Capturing current environment in .conanvirtualenv/deactivate_conanrunenv-release-x86_64.sh
Configuring environment variables
$ source .conanvirtualenv/deactivate_conanrun.sh
Restoring environment
$ source .conanvirtualenv/conanrun.sh
Capturing current environment in .conanvirtualenv/deactivate_conanrunenv-release-x86_64.sh
Configuring environment variables
$ source .conanvirtualenv/deactivate_conanrun.sh
Restoring environment
Restoring environment
```
### Explanation of the issue

The issue here is, the more we do activate/deactivate the more the string "Restoring environment" will be displayed (and after a while it can be very annoying on my shell) and the more the script `deactivate_conanrunenv-release-x86_64.sh` will be full. When using the VirtualRunEnv I found that very annoying after a while. I would recommend that:
* the activate script create a temp deactivate file with `mktemp`
* stores the place of the deactivate file in the env variable `CONAN_DEACTIVATE_FILE`
* source $CONAN_DEACTIVATE_FILE in the non temp deactivate script.

I could do a PR for linux with that, but since I don't know how to do that on Windows (I don't have Windows installed at all) I think my PR won't be accepted.

@memsharded @lasote @czoido: I think you guys are the one working on [this recently](https://github.com/conan-io/conan/commits/develop/conan/tools/env) (so I hope it is okay to highlight you), what do you think?
user: CPickens42
issue_10969: state: open
title: [bug] markdown - needs to install system packages and run pkg-config
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

might be also related to https://github.com/conan-io/conan/issues/10967
it's pretty annoying that markdown generator requires user to install system packages, in case if package depends on something like `opengl/system` or `xorg/system`. it would be nice to skip that.
```
ERROR: egl/system: Error in package_info() method, line 75
	self._fill_cppinfo_from_pkgconfig('egl')
while calling '_fill_cppinfo_from_pkgconfig', line 24
	if not pkg_config.provides:
	ConanException: pkg-config command ['pkg-config', '--print-provides', 'egl', '--print-errors'] failed with error: Command 'pkg-config --print-provides egl --print-errors' returned non-zero exit status 1.
Package egl was not found in the pkg-config search path.
Perhaps you should add the directory containing `egl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'egl' found
```

### Environment Details (include every applicable attribute)
  * Operating System+version:
  * Compiler+version:
  * Conan version:
  * Python version:

### Steps to reproduce (Include if Applicable)


### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SSE4
issue_10965: state: open
title: [bug] markdown - remove the list of header files
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

looking at: https://conan.io/center/openssl?tab=recipe
(section `Exposed header files for openssl`)
I don't think it's useful information for the consumer.
first off, for projects like `boost` or `Qt` it could literally take thousands of lines. it makes markdown just unnecessarily long to read.
second, there are some headers that are not supposed for the direct inclusion (e.g. `#include <openssl/__DECC_INCLUDE_EPILOGUE.H>`).
third, it might be slow to scan these headers in file system.
and finally, it requires markdown to download a real package. without this feature, it will be much faster (for some packages, it might be literally gigabytes).

### Environment Details (include every applicable attribute)
  * Operating System+version:
  * Compiler+version:
  * Conan version:
  * Python version:

### Steps to reproduce (Include if Applicable)


### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SSE4
issue_10962: state: open
title: [question] cmake_layout assumptions when running conan install
body: <!-- What is your question? Please be as specific as possible! -->
We're starting to have a mix of msbuild and cmake projects. Do I have to change where I'm calling conan from based on whether I'm building a cmake or msbuild project? The `self.cpp.build.bindirs[0]` is incorrect when building from the project root. I must prepend "build/src" for that directory to pick up any of my artifacts.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: anderson-dev
issue_10947: state: open
title: [bug] Conan mixing up setting variables of profiles when doing cross compilation
body: I cross compile zlib from x86_64 to armv8 like this:
```
conan create cci/recipes/zlib/all 1.2.11@ -pr:h gcc-9.0-qemu-armv8-release-toolchain -pr:b gcc-9.0-linux-x86_x64-release
```
I have created a conan tool chain recipe, which I reference in my profile `gcc-9.0-qemu-armv8-release-toolchain`

However, when executing the create cmd. I get following output:
```
Cross-build from 'Linux:x86_64' to 'Linux:armv8'
Installing (downloading, building) binaries...
ERROR: There are invalid packages (packages that cannot exist for this configuration):
yocto-toolchain/1.0.0@company/stable: Invalid ID: os=Linux, distro=None is not supported by yocto-toolchain (no binaries are available)
yocto-toolchain/1.0.0@company/stable: Invalid ID: os=Linux, distro=None is not supported by yocto-toolchain (no binaries are available)
```

My toolchain recipe has a validate step:
```
def _settings_distro_supported(self):
        return self.conan_data["sources"][self.version]["os"][str(self.settings.os)].get(str(self.settings.os.distro)) is not None
def validate(self):
        if not self._settings_distro_supported():
            raise ConanInvalidConfiguration(f"os={self.settings.os}, distro={self.settings.os.distro} is not supported by {self.name} (no binaries are available)")
```

I created a new sub setting in `settings.yml` called `distro`. For unknown reason this setting is `None` during cross compilation, although it shouldn't be.

See here my profiles used:

with following profiles:
`gcc-9.0-qemu-armv8-release`
```
[settings]
os=Linux
os.distro=custom_distro ## here custom sub settings!!!
arch=armv8
compiler=gcc
compiler.version=9
compiler.libcxx=libstdc++11
build_type=Release
[options]
[build_requires]
[env]
```
`gcc-9.0-qemu-armv8-release-toolchain`
```
include(gcc-9.0-qemu-armv8-release)
[options]
yocto-toolchain:target=armv8
[tool_requires]
yocto-toolchain/1.0.0@company/stable
```

Build profile:
`gcc-9.0-linux-x86_x64-release`
```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=9
compiler.libcxx=libstdc++11
build_type=Release
[options]
[build_requires]
[env]
```
**Remark** here, I do not have the os.distro setting. Not needed IMHO.

So I think conan i using the `gcc-9.0-mbient-armv8-release-toolchain` with the `settings.os` from the build profile.
Which is wrong, I think. Why is it done like this?


### Environment Details (include every applicable attribute)
  * Operating System+version: ubuntu 18.04
  * Compiler+version: h:gcc9+armv8 b:gcc9+x86_64
  * Conan version:1.46.0
  * Python version:3.6.9

### Conan log from profiles during build ###
```
Configuration (profile_host):
[settings]
arch=armv8
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os.distro=custom_distro
[options]
yocto-toolchain:target=armv8
[build_requires]
*: yocto-toolchain/1.0.0@company/stable
[env]

Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
```

user: derived-coder
issue_10944: state: open
title: [bug] Rewrite lock file, get the binary is wrong
body: ### Environment Details (include every applicable attribute)
  * Operating Ubuntu+20.04:
  * Compiler+version: gcc 10.2
  * Conan version: 1.46.2
  * Python version: 3.8.10

Conanfile.py :
```python
from conans import ConanFile, tools
import os
required_conan_version = ">=1.33.0"
class LibaConan(ConanFile):
    name = "liba"
    settings = "os", "arch", "compiler", "build_type", "platform"
    keep_imports = True

    def configure(self):
        if self.options.shared:
            self.options["libsodium"].shared = True
            self.options["libuv"].shared = True

    def requirements(self):
        self.requires("cpcore/[> 2.4.20 < 2.5.0]@liware/stable")
        self.requires("libuv/1.42.0")

    def deploy(self):
        self.copy("*", src="lib", dst="lib", symlinks=True)
        self.copy("*", src="bin", dst="bin")
        self.copy("*", src="etc", dst="etc")

    def imports(self):
        self.copy("*", src="lib", dst="lib",
                  excludes=self.no_import_to_yocto_lib)
        self.copy("*", src="bin", dst="bin",
                  excludes=self.no_import_to_yocto_bin)
        self.copy("*", src="etc", dst="etc")

    def package(self):
        self.copy("*", src="lib", dst="lib", symlinks=True)
        self.copy("*", src="bin", dst="bin")
        self.copy("*", src="etc", dst="etc")
        self.copy("version*", src="", dst="etc")
```


### Steps to reproduce 
1. `conan lock create conanfile.py --user=liware --channel=stable --lockfile-out=base.lock --base`
2. `conan lock create conanfile.py --user=liware --channel=stable --lockfile=base.lock --lockfile-out=release.lock --profile=x64`
3. `conan create . 1.0.0@liware/stable --lockfile=release.lock`
4. Replace ref liba/1.0.0@liware/stable to liba/llatest@liware/stable from release.lock,save to release_daily.lock
5. Update the third-party dependent version. Increase the version of `cpcore` to 2.4.35.
Attention： 
liba/llatest@liware/stable already exists at the artifactory, but the dependency information is lower than the current release.lock.
release.lock 
The version recorded in the release.lock:
cpcore/2.4.33@liware/stable

6. `conan lock install release_daily.lock -if ./install_dir`
7. `cpcore --version`. 

Expect：
version = 2.4.33

Reality：
version = 2.4.35

My workaround：
`conan create . latest@liware/stable --lockfile=release_daily.lock`
`Conan Upload liba/latest@liware/stable -r conan_remote --all`
`conan remove "*" -f`
`conan lock install release_daily.lock`

Result:
`cpcore --version`
version = 2.4.33 ,The version is right.

``
user: DDkuang
issue_10935: state: open
title: [question] how to pass start-group/end-group options to linker with new CMake generators
body: Hello,

I need to have a linker command with `-Wl,--start-group mylib1.a  mylib2.a mylib3.a -Wl,--end-group` because I use a package with cyclic dependencies: MKL.

An issue had been created 2 years ago:
https://github.com/conan-io/conan/issues/6530#issue-563624956
This issue ended by a workaround:
`
self.cpp_info.exelinkflags = ["-Wl,--start-group {0}/lib/libmkl_intel_lp64.a {0}/lib/libmkl_sequential.a\ {0}/lib/libmkl_core.a -Wl,--end-group".format(self.cpp_info.rootpath)]`

It seems the workaround does not work anymore with new CMake generators:
`
/usr/bin/ld: unrecognized option '--start-group [...]/lib/libmkl_intel_lp64.a [...]/lib/libmkl_sequential.a [...]/lib/libmkl_core.a -Wl'`

However I edited the generated file mkl-release-x86_64-data.cmake to try to find a solution, but then I got a new problem:
The link command **begins** with the content of `exelinkflags` so my libs (that depend on mkl) are linked after and has undefined functions (mkl functions).

How can I solve this issue ? How can we prefix with `-Wl,--start-group` and suffix with `-Wl,--end-group` some libraries in the link command ?
user: JonathanGirardeau
issue_10926: state: open
title: [question] Custom generator - how to access conandata.yml?
body: I am currently writing my own Conan generator similar to the Markdown generator, except that I need to create a Docbook file. 
I can get most of the needed information, but I also need to access the license, homepage, and some information only defined in our conandata.yml. 

Is there any way to access the conandata.yml?

Many thanks for your help.
user: sboehmann
issue_10923: state: open
title: [feature] Cross compilation on same os / architecture
body: As strange as it sounds I'm trying to cross compile from Linux x86_64 to Linux x86_64, using a Yocto SDK Toolchain.  
I use two profiles (`-pr:b` and `-pr:h`).  
A lot of recipes work out-of-the-box, but not all. Currently struggling with [libbacktrace](https://github.com/conan-io/conan-center-index/blob/master/recipes/libbacktrace/all/conanfile.py) (because of boost).
It uses autotools.

Here is output of building with two Yocto toolchains, one from x86_64 to armv7hf and one from x86_64 to x86_64:
https://github.com/eirikb/proof-of-conan/runs/5742649170?check_suite_focus=true
The one failing will say:
>  configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.

The `--host` (and `--target`) is not passed.

This seems logical enough, and the check in https://github.com/conan-io/conan/blob/develop/conans/client/tools/oss.py#L460 will check if `host_os` or `host_arch` is not like `build_os` or `build_arch`.

I'm not sure how to solve this, perhaps some additional flag somewhere? Maybe it is already possible?
As I understand using two profiles by itself doesn't necessarily mean cross building.

----
In addition I did some tests, by forcing `cross_building` in oss.py to always return `True`.  
Then `--host` and `--target` would be passed, but automake didn't consider it cross build. I'm not 100% sure why not, could be a similar arch vs arch check? The parameters were _x86_64-linux-gnu_ . If I changed these, to for example _x86_64-linux_ it would cross build, even when they were equal. I did this directly in [autotools_environment.py](https://github.com/conan-io/conan/blob/develop/conans/client/build/autotools_environment.py#L157). 
user: eirikb
issue_10911: state: open
title: [bug] Timeouts uploading large packages to Artifactory
body: Not sure what specifically causes it, but would love to know if possible, and if so how to work around the problem.

On the client side, it seems like the upload completes, then 3 minutes later the request times out:
```
2022-03-28T18:20:45.5757918Z Uploading package 1/1: c37b72a856a3a472e507edcc5b9e7a477dd0c3a9 to '***redacted***'          [0m
2022-03-28T18:20:45.5946725Z 
...
2022-03-28T18:31:53.9083875Z Uploading conan_package.tgz :  99%|#########9| 3.77G/3.79G [01:04<00:00, 92.0MB/s]
2022-03-28T18:31:54.0079369Z Uploading conan_package.tgz :  99%|#########9| 3.77G/3.79G [01:04<00:00, 93.1MB/s]
2022-03-28T18:31:54.1162492Z Uploading conan_package.tgz : 100%|#########9| 3.78G/3.79G [01:04<00:00, 98.7MB/s]
2022-03-28T18:31:54.1164185Z Uploading conan_package.tgz : 100%|#########9| 3.79G/3.79G [01:04<00:00, 96.4MB/s]
2022-03-28T18:31:54.1164743Z                                                                                   
2022-03-28T18:31:54.1166293Z 
2022-03-28T18:31:54.1167084Z Uploaded conan_package.tgz -> Installer/220328.4216+ee6a6afb@ci/branch_releases_22.03.28:c37b [3978144.30k]
2022-03-28T18:34:54.4232074Z [1m[31mERROR: HTTPSConnectionPool(host='conan.ci.eng.***redacted***.com', port=443): Max retries exceeded with url: /artifactory/api/conan/conan-local/v1/files/***redacted***/Installer/220328.4216+ee6a6afb/branch_releases_22.03.28/0/package/c37b72a856a3a472e507edcc5b9e7a477dd0c3a9/0/conan_package.tgz (Caused by ReadTimeoutError("HTTPSConnectionPool(host='conan.ci.eng.***redacted***.com', port=443): Read timed out. (read timeout=60.0)",))[0m

```

On the Artifactory side:
```
2022-03-28 18:31:54,129 [http-nio-8081-exec-9] [INFO ] (o.a.e.UploadServiceImpl:399) - Deploy to 'conan-local:redacted/Installer/220328.4216+ee6a6afb/branch_releases_22.03.28/0/package/c37b72a856a3a472e507edcc5b9e7a477dd0c3a9/0/conan_package.tgz' Content-Length: 4073619764
2022-03-28 18:32:54,836 [http-nio-8081-exec-9] [ERROR] (o.a.a.c.r.ArtifactoryService:542) - Failed to read stream: java.io.EOFException: Unexpected EOF read on the socket
org.jfrog.storage.binstore.ifc.ClientInputStreamException: Failed to read stream: java.io.EOFException: Unexpected EOF read on the socket
	at org.jfrog.storage.binstore.ifc.ClientStream.read(ClientStream.java:36)
	at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1158)
	at org.apache.commons.io.IOUtils.copy(IOUtils.java:878)
	at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1135)
```

Note the timestamps: the upload completes at 18:31:54 from the client side, and `Deploy` action on the server side begins at the same time. The server then errors out a minute later, with the client sitting for another 2 minutes before seeing an error.

This seems to only happen with very large packages, and only in about 70-80% of the cases (e.g. if we retry enough times it will succeed). How can it be fixed?

user: w3sip
issue_10910: state: open
title: [feature] Make build_info time format compatible with JFrog CLI
body: I'm having trouble using JFrog CLI commands which use build_info (such as [build-append](https://www.jfrog.com/confluence/display/CLI/CLI+for+JFrog+Artifactory#CLIforJFrogArtifactory-AggregatingPublishedBuilds)) because Conan uses a [time format](https://github.com/conan-io/conan/blob/develop/conans/build_info/build_info.py#L244) different from the [format expected by JFrog](https://github.com/jfrog/build-info-go/blob/56b486ab4b8acca44c1a874a8a771b0cd9c2dac8/entities/buildinfo.go#L17).

Error message from:
```
> jf rt build-append aggregating-build 10 published-build 1
20:19:07 [🔵Info] Running Build Append command...
20:19:09 [🚨Error] parsing time "2022-03-24T17:34:56.000Z" as "2006-01-02T15:04:05.000-0700": cannot parse "Z" as "-0700"
```
user: GordonJess
issue_10907: state: open
title: [bug] Pylint plugin does not accept python_requires from conans
body: The [pylint_plugin](https://github.com/conan-io/conan/blob/develop/conans/pylint_plugin.py) tries to enforce the use of `conan` instead of `conans`, which will become our future main module. However, some modules are still available only from `conans`, the `python_requies` is one example. In case we use warning as error, it will fail. For instance:

```python
from conan import ConanFile
from conans import python_requires 

base = python_requires("name/version")

class TestConan(ConanFile):
    name = "consumer"
    version = "version"
```

```
export CONAN_PYLINT_WERR=1
conan create . consumer/version@user/channel
...
[HOOK - hooks/recipe_linter.py] pre_export(): consumer.py:2:0: E9000: Using deprecated imports from 'conans'.
```

We need to improve the pylint plugin, or, advance with the module porting.

As workaround, it can be ignore by adding `# pylint: disable=E9000` at line 2.

user: uilianries
issue_10891: state: open
title: Added compiler flags in conanfile.py but doesn't build with those flags? 
body: I have this in my conanfile.py
```
def package_info(self):
        self.cpp_info.cxxflags.append("-fstack-protector-strong")
```
However, I don't see these flags in the build. Is there an alternative way to add this? 
Should I just add the flags in CmakeLists.txt instead? 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: nimit25
issue_10888: state: open
title: [bug] Static Runtime ignored on Visual Studio
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 x64
  * Compiler+version: MSVC 2019
  * Conan version: 1.46.2
  * Python version: 3.9.7

### Steps to reproduce (Include if Applicable)
Similar to #10299 the runtime definition of "MT" / "MTd" is ignored and the Visual Studio project generated by cmake sets the Runtime to "MD" / "MDd" when built using the following conan profile:
```
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=Visual Studio
compiler.cppstd=17
compiler.runtime=MTd
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
```

This will ultimately cause the build to happen with the wrong runtime, which causes linker errors when consuming the recipe.
user: Sil3ntStorm
issue_10887: state: open
title: [bug] get_safe errors out when not defined
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 x64
  * Compiler+version: VS 2022
  * Conan version: 1.46.2
  * Python version: 3.9.7

### Steps to reproduce (Include if Applicable)
The following code in a recipe will cause a warning when used with a profile that does not specify compiler.cppstd option.
```
def configure(self):
    min_cppstd = "17"
    print(self.settings.get_safe("compiler.cppstd"))
    if self.settings.get_safe("compiler.cppstd"):
        print('test')
        tools.check_min_cppstd(self, min_cppstd)
```

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=msvc
compiler.runtime_type=Release
compiler.version=193
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

None
ERROR: test/0.0.1: 'settings.compiler.cppstd' value not defined
```
user: Sil3ntStorm
issue_10881: state: open
title: [question] Profile option depending on build type?
body: Hi,

I have a strange issue.  For our packages in release mode we set some extra package options - which add some release specific tinkering to the package (e.g. digital signature). How can I set this package option in a profile?
E.g. is there a way to specify a profile option depending on the build_type? Or should I simply remove the option if build_type != Debug in configure()?
user: harsszegi
issue_10873: state: open
title: [question] Combining several static libraries into one using Conan
body: Hi,
I have a _static_ library `lib2` of file `lib2cpp.cpp` that requires a _static_ library `lib1` of file `lib1cpp.cpp`.
When building `lib2.lib` (or `lib2.a`), I expect it to have both `lib1cpp.o` and `lib2cpp.o`.
Having `lib1` as a required package of `lib2` in the recipe with `CMake` is the generator, and building `lib2`, `lib2.lib` has only `lib2cpp.o`.
How to make `lib2.lib` have both the .o files?
Thanks
- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Bassem-Ramzy
issue_10871: state: open
title: [question] How to make `layout()` and `conan install --install-folder/--output-folder` work flawlessly?
body: We are facing some troubles where we have a really hard time solveing them correctly.
We really appreciate some help here.

Nameley how to make `conan install` (which we execute from CMake inside the build folder) respecting the build folder when outputting the generated files.

We use the following `conanfile.py` as recipe and receipt:
```python
def layout(self):
    self.folders.source = "repo"
    self.folders.build = "build"
    self.folders.generators = path.join(self.folders.build, "conan")
    self.folders.imports = path.join(self.folders.generators, "imports")

def generate(self):
    deps = CMakeDeps(self)
    deps.build_context_activated = []
    deps.generate()
```

When developers are configuring the build with CMake (yes, we are not calling `conan install` first)
they chose the build folder, e.g. `/mybuildfolder`
CMake then calls `conan install --install-folder /mybuildfolder/conan ...` (cwd:= `/mybuildfolder`) automatically (by [`cmake_conan_install`](https://github.com/conan-io/cmake-conan)) and we want now that
all generated files go directly to `/mybuildfolder/conan`. 
This just seems utterly impossible? 

**What happens:**
With the `layout()` function above which makes sense **when creating the package (in the cache)**, the `conan install --install-folder /mybuildfolder/conan ...` (cwd:= `/mybuildfolder`) just puts them into `/mybuildfolder/conan/build/conan`.

Somehow Conan cannot be turned into the direction we want, and its really limiting. There is also the other option `--output-folder` which behaves the same and is the new command in conan v2 I guess.
How can we modify the `layout()` that in case of `conan install --install-folder/--output-folder` the generated files really go to `/mybuildfolder/conan` and not `/mybuildfolder/conan/build/conan`.

Sidenote: We have a workaround, by setting `self.folders.generators` to an absolute path read from a JSON file. But this is ugly.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: gabyx
issue_10864: state: open
title: [bug] merge refs not found in remote when capturing commit coordinates
body: I am building packages in a pull request verification workflow to ensure that the changes integrate into all consumers.  When the sources are initially checked out, the standard behaviour of Github workflows (checkout action) is to check out the 'merge ref' (i.e. the commit which would be created if the pull request is merged).  

When capturing the commit coordinates using methods in `conan.tools.scm.Git`, conan cannot find these merge refs and falls back to return the local root path instead.  I would still like the merge ref hash to be stored so I can simply promote the same pacakges to another repo when the pull request is merged.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version:
  * Conan version: 1.46.0
  * Python version: 3.7.9

### Logs (Executed commands with output) (Include/Attach if Applicable)
Checkout action:
```
Checking out the ref
  /usr/bin/git checkout --progress --force refs/remotes/pull/1/merge
  Note: checking out 'refs/remotes/pull/1/merge'.
  
  You are in 'detached HEAD' state. You can look around, make experimental
  changes and commit them, and you can discard any commits you make in this
  state without impacting any branches by performing another checkout.
  
  If you want to create a new branch to retain commits you create, you may
  do so (now or later) by using -b with the checkout command again. Example:
  
    git checkout -b <new-branch-name>
  
  HEAD is now at 3d653a0 Merge 7035bcc5162cda71473312dc3670848131af40a3 into cf607d849b3d129d88f1dbfb75fc5628f7909cae
```
Conan output:
```
liba/0.1: WARN: Current commit 3d653a0222f675933f8110ecd3d19c658f0febab doesn't exist in remote origin
This revision will not be buildable in other computer
```
user: GordonJess
issue_10861: state: open
title: [bug] .gitignore preventing .git internal files being copied to cache
body: It seems that adding a path to the .gitignore of an scm conan recipe with sources can cause files under the actual .git directory itself to be excluded from the conan cache. Recipes relying on git info at build time could potentially be broken by this.

### Environment Details:
  * Operating System+version: Ubuntu 18.04 LTS
  * Compiler+version: N/A
  * Conan version: 1.46.2
  * Python version: 3.6.9

### Steps to reproduce (Include if Applicable)
```
mkdir temp && cd temp
conan new foo/1.2.3 -s

Add the following to the conanfile:
scm = {
    "type": "git",
    "subfolder": ".",
    "revision": "auto",
    "url": None
}

echo '*test*' > .gitignore

git init && git add . && git commit -m "Init"

git checkout -b test

ls .git/refs/heads # this should show master and test refs

conan create .

ll /path/to/conan/cache/foo/1.2.3/_/_/build/packageID/.git/refs/heads
You will see only the master ref.

```
#### Expected behavior
I would expect the .git directory in the cache build dir to have the same contents as the recipe dir.
user: ldobinson
issue_10853: state: open
title: [bug] ConanException: Duplicated requirement ignition-cmake/2.10.0 != ignition-cmake/2.10.0
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

from https://github.com/conan-io/conan-center-index/pull/9872

if `test_package` uses an explicit requires like:
```
    def requirements(self):
        self.requires("ignition-cmake/2.10.0@")
```
it fails with the weird error message:
```
ConanException: Duplicated requirement ignition-cmake/2.10.0 != ignition-cmake/2.10.0
```
however, for sure it's the same requirements.
therefore, it should be either no error at all, or error message has to be different (as requirement is equal)

### Environment Details (include every applicable attribute)
  * Operating System+version:
  * Compiler+version:
  * Conan version:
  * Python version:

### Steps to reproduce (Include if Applicable)


### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SSE4
issue_10850: state: open
title: [question] How to set `cmaketoolchain:user_toolchain` for dependency?
body: We have the following profile:

```
[settings]
os=Macos
arch=x86_64
arch_build=x86_64
compiler=clang
compiler.version=12
compiler.libcxx=libstdc++11
build_type=Release

sdl:compiler=apple-clang
sdl:compiler.version=12.0
sdl:compiler.libcxx=libstdc++

[env]
sdl:CC=/usr/bin/clang
sdl:CXX=/usr/bin/clang++

[conf]
tools.cmake.cmaketoolchain:user_toolchain = path-to-our-toolchain.cmake // defines the clang compiler... (NOT APPLE CLANG)
```

1. Is is possible to set these overwrite for `sdl` also inside the `conanfile.py` ? This would be very nice, we have not found a way in the documentation which shows that? Is it not possible?

2. How can we inspect the invocation of CMake when conan builds the package? 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: gabyx
issue_10849: state: open
title: [question] RPATH and crosscompiling on Mac
body: We've been building our stack on x86_64 Mac, using Conan 1.41.1 and CMake 3.19

In this setup, the binaries that are generated include proper rpath (`@rpath` prefix on dependencies)

Now I'm trying to add cross-compilation from x86_64 to Apple Silicon. Things are generally working, except in the resulting binaries there is no rpath set.

What could affect this, and what factors affect rpath generation in this cross setup?

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: w3sip
issue_10847: state: open
title: [question] How to override a dependency shared between both a project and one of its test_requires dependencies?
body: If you have a library which uses something like `fmt` and a testing framework which also uses `fmt`, how are you supposed to override the version of `fmt` for the `test_requires`?
In a situation like this, but dependencies which also use the testing framework as a `test_requires`, I currently get an error message like the following.

```
To` fix this conflict you need to override the package `fmt` in your root package.
```

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: jwillikers
issue_10845: state: open
title: [question] Is `conanfile.in_local_cache` correctly set inside `layout()`?
body: Is `conanfile.in_local_cache` correctly set inside `layout()`?

We are facing the issue that depending on the case that the package is build and installed as dependency
(`in_local_cache = True`) we want to set the build folder differently.


```python

def layout(self):
    assertConanModule(self)
    self.folders.source = "repo"
    
    # We communicate the build folder over a JSON created 
    # from CMake which we read here, to set the below variable correctly if THIS PACKAGE IS NOT BUILDING/INSTALLING in local cache:
    self.folders.build = "build" if self.in_local_cache else loadFromJSON() 
    
    self.folders.generators = path.join(self.folders.build, "conan")
    self.folders.imports = path.join(self.folders.generators, "imports")
```

I am not sure if that variable is already set inside `layout()` when this package gets build(missing)/installed?


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: gabyx
issue_10832: state: open
title: [feature] Provide `PackageName_PACKAGE_FOLDER` (Cache) variable when using `CMakeDeps`.
body: This issue is related to the following issues:

- https://github.com/tonka3000/vscode-qt-tools/issues/69
- https://github.com/conan-io/conan-center-index/issues/9829

### Problem Description

The mechanism of using `CMakeDeps` is to genereate some `*-config.cmake` files inside the build directory folder. Therefore, after calling `find_package(Qt6)` to load the configuration, the `Qt6_DIR` will be the directory of `Qt6Config.cmake`, which is inside the build directory.

However, the mechanism of [vscode-qt-tools](https://github.com/tonka3000/vscode-qt-tools) is to locate some qt tools (such as `designer.exe`) based on the Cache Variable `QtX_DIR` in `CMakeCache.txt` file. Therefore, it will show **"Qt not found"** on the bottom of status bar.

According to this [article](https://blog.conan.io/2022/01/17/New-conan-release-1-44.html#added-variables-to-cmakedeps-to-match-better-with-upstream) of Conan Blog, `CMakeDeps` generator has provided the following variables:

- `PackageName_LIBRARIES`
- `PackageName_INCLUDE_DIRS`
- `PackageName_INCLUDE_DIR`
- `PackageName_DEFINITIONS`
- `PackageName_VERSION_STRING`

### Expected Settings

I notice that there is a variable called `qt_PACKAGE_FOLDER_DEBUG` defined in `Qt6-debug-x86_64-data.cmake` file. Therefore, I have an idea that maybe the problem can be solved by providing this variable and then adding it into `CMakeCache.txt` file.

```
PackageName_PACKAGE_FOLDER: "C:/.conan/9f5af8/1"
```

For example,

```cmake
set(Qt6_PACKAGE_FOLDER ${qt_PACKAGE_FOLDER_DEBUG})
set(Qt6_PACKAGE_FOLDER ${qt_PACKAGE_FOLDER_DEBUG} CACHE PATH "******" FORCE)
```

### Screenshots

![image](https://user-images.githubusercontent.com/71438617/159150055-f63fb782-9562-4f28-b795-d06fe7ddf36d.png)
![image](https://user-images.githubusercontent.com/71438617/159150033-f8fe0847-f191-4efd-8f22-046d336f5637.png)

user: hwhsu1231
issue_10829: state: open
title: [bug] OPENSSL_FOUND and similar variables aren't defined
body: External code often relies on the variable OPENSSL_FOUND being defined. I see code in the OpenSSL package recipe to handle this but I'm a bit confused as to how this is supposed to work. Provided is a test case showing that `OPENSSL_FOUND` is *not* defined but `OpenSSL_FOUND` is defined by default.

### Environment Details (include every applicable attribute)
  * OS: Arch LInux
  * Compiler: GCC 11.2.0
  * Conan version: 1.46.0
  * Python version: 3.10.2

### Steps to reproduce
Test Case: https://github.com/computerquip-work/conan-openssl-fail-case

From source:
```
mkdir -p build;
cd build;
conan install ..;
conan build ..;
```

user: computerquip-work
issue_10827: state: open
title: [bug] self.env_info not resolved in consumer
body: Hi,

I'm not sure if it is a bug, but `self.env_info` seems to behave differently when comparing version 1.38.0 with 1.45.0 or 1.46.0. See below for an example. Is this a bug or is this desired?

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 20H2
  * Compiler+version: -
  * Conan version: 1.38.0, 1.45.0, 1.46.0
  * Python version: 3.8.9

### Steps to reproduce (Include if Applicable)

- Create the following recipe `env_provide/conanfile.py`:

  ```
  #!/usr/bin/env python3
  # -*- coding: utf-8 -*-
  
  from conan import ConanFile
  from pathlib import Path
  
  class TestRecipe(ConanFile):
      name = "env_provide"

      def build(self):
          Path(self.build_folder, "test.txt").touch()

      def package(self):
          self.copy("test.txt")

      def package_info(self):
          self.env_info.TEST_TXT = "MY_TEST_TXT"
  ```

- Create the following recipe `env_consume/conanfile.py`:

  ```
  #!/usr/bin/env python3
  # -*- coding: utf-8 -*-
  
  from conan import ConanFile
  from pathlib import Path
  import os

  class TestRecipe(ConanFile):
      name = "env_consume"
      requires = "env_provide/dev@user/testing"

      def build(self):
          self.output.warn(f"TEST_TXT: {self.deps_env_info.TEST_TXT}")
          self.output.warn(f"TEST_TXT: {os.getenv('TEST_TXT')}")
          Path(self.build_folder, "test.txt").touch()

      def package(self):
          self.copy("test.txt")
  ```

- Create the Conan package for `env_provide`:

  ```
  conan create <path_to_env_provide> env_provide/dev@user/testing
  ```

- Create the Conan package for `env_consume`:

  ```
  conan create <path_to_env_consume> env_consume/dev@user/testing
  ```

- Check output

Using Conan version 1.45.0 or 1.46.0 the output is as follows:

```
env_consume/dev@user/testing: WARN: TEST_TXT: []
env_consume/dev@user/testing: WARN: TEST_TXT: None
```

However, using Conan 1.38.0 the output is as expected (at least for me ;)):

```
env_consume/dev@user/testing: WARN: TEST_TXT: MY_TEST_TXT
env_consume/dev@user/testing: WARN: TEST_TXT: MY_TEST_TXT
```

I have checked the changelog, but haven't found something that would indicate that the change of the behavior is desired. So, I guess it is a bug, isn't it?

Best regards,
Markus
user: gpxricky
issue_10824: state: open
title: [bug] conan docker containers fail to install packages
body: To reproduce:

```
docker run -it -u $(id -u):$(id -g) -v $(pwd):/src -w /src conanio/gcc72:latest bash -c "conan install catch2"
```

errors with

```
ERROR: Can't write version file in '/.conan/version.txt': The folder /.conan does not exist and could not be created (Permission denied).
```

I don't expect this to error.

Most applications have their own docker containers.
To use conan, one needs to install and setup conan within those containers. 

It would be super helpful to document somewhere how to install conan into an already existing container and how to set it up for development. 
user: gnzlbg
issue_10809: state: open
title: [question] Impact of a remote with error "Trying to modify locked package"
body: Hello,

I just understood what causes my CI pipeline to fail from time to time with the error `ERROR: Trying to modify locked package xxx`

Here's what I do:

```
conan remove -f mypkg/*
conan export-pkg ./conan 1.0.0@ci/testing --source-folder . --build-folder ./build -s build_type=RelWithDebInfo
conan upload --all --confirm -r myartifactory mypkg/*
```

The first time it works fine and well: the package is exported on our internal Artifactory 👍 

When I run again my CI to do test some changes on my recipe, `conan export-pkg` completes as usual... before failing with `ERROR: Trying to modify locked package mypkg/1.0.0@ci/testing`

It took me a while to understand why clearing the conan cache with `conan remove` had no effect. And I just found the reason why : I need to clear the packages on Artifactory itself.

So Conan detects this packages already exists on Artifactory while performing the `conan export-pkg` (and not `conan upload`).

My expectation was to be able to override an existing package on a remote. Or at least to fail to do it when running `conan upload`. I am surprised `conan export-pkg` performs this check, and as a user feedback I can say it is quite hard to guess and understand.

How does it work? Why is it talking about a lock when a  package exists on a remote? (this is confusing because the doc talks about locks as local files). Why is this check done when building a local package?

Thanks for your help 😃 
user: aurelienrb
issue_10803: state: open
title: [question] Are empty string and False option values equal for Conan?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

I have a recipe with an option specified as
```
    options = {
        'an_option': [True, False, ''],
        ...
    }
```
It turned out that `False` and `''` values are equal for Conan: they generate the same package ID. Is it intentional behavior?

user: db4
issue_10802: state: open
title: [bug] tools.cmake.cmaketoolchain:user_toolchain feature in 1.46 breaks existing profile usage in 1.45.0
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: any (tested on macOS and Ubuntu)
  * Compiler+version: n/a
  * Conan version: 1.45.0 and 1.46.0
  * Python version: 3.8

### Problem

We distribute centralised Conan profiles to teams and in these profiles we use the property ``tools.cmake.cmaketoolchain:user_toolchain`` and set it to a string value.
This worked fine in Conan <= 1.45.0.
The PR https://github.com/conan-io/conan/pull/10729 breaks this usage, but this PR is associated with "a feature".
I cannot see how Conan semver is appropriate here to roll to 1.46 from 1.45 when this is a breaking change on an public interface level.

At least automatically wrap the value into a list if it is a string or single item to be backwards compatible and adhere to semver.

### Steps to reproduce (Include if Applicable)
Run Conan 1.45.0 and set applicable property as a string in a profile. It works.
Run Conan 1.46.0 and set applicable property as a string in a profile. It does not work.


### Logs (Executed commands with output) (Include/Attach if Applicable)
![image](https://user-images.githubusercontent.com/1384135/158746221-1ac2cff0-9ea7-49b3-bc80-8c898ea8d4bb.png)

```
user_toolchain = self._conanfile.conf.get("tools.cmake.cmaketoolchain:user_toolchain",
  File "/home/sean/.local/lib/python3.8/site-packages/conans/model/conf.py", line 232, in get
    raise ConanException("[conf] {name} must be a {type}-like object. "
conans.errors.ConanException: [conf] tools.cmake.cmaketoolchain:user_toolchain must be a list-like object. The value '$ENV{CONAN_CMAKE_TOOLCHAIN_FILE}' introduced is a str object

ERROR: Error in generator 'CMakeToolchain': [conf] tools.cmake.cmaketoolchain:user_toolchain must be a list-like object. The value '$ENV{CONAN_CMAKE_TOOLCHAIN_FILE}' introduced is a str object

```


<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SeanSnyders
issue_10796: state: open
title: [question] Set conan_meson_cross.ini [properties] field?
body: There is a well known case in meson that it will fail to correctly auto detect if the build machine can execute host binaries if the build machine is Macos and the host is iOS because in my case the arch is arm64 in both. The result is that the build fails because Meson trys to execute the binary as part of of its 'compiler sanity check'. This fails of course, and stops the build, even though it was actually successful.

The suggested fix from Meson is to set

```
[properties]
needs_exe_wrapper=true
```

in conan_meson_cross.ini. However, there doesn't seem to be any way to add [properties] to this field from the Meson Toolchain. There's probably a way to do in the actual meson.build files, but I'd imagine for people trying to use conan for cross-platform, it would be useful to be able to set this at the profile level, or at the very least from the ConanFile via the Meson Toolchain.

Any thoughts on this?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: avetiso
issue_10792: state: open
title: [bug] Qt 5.15.2 without OpenSSL is compiled nevertheless with OpenSSL
body: Compiling Qt 5.15.2 without OpenSSL is compiled nevertheless with OpenSSL when using a conanfile.txt.  I tried various combinations of command line parameters and conanfile.txt settings. The last trial is shown below.

### Environment Details (include every applicable attribute)

  * Operating System+version: Ubuntu 21.04
  * Compiler+version: gcc 10.3
  * Conan version: 1.46
  * Python version: Python 3.9.7 (anaconda)

### Steps to reproduce (Include if Applicable)

command line:
`conan install qt/5.15.2@ --build --profile gcc103 -o qt:openssl=False -o openssl=False`

conanfile.txt:
```
[requires]
qt/5.15.2@

[settings]
compiler=gcc
build_type=Release

[generators]
cmake

[options]
*:shared=True
qt:openssl=False


```
output:

Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=10.3
os=Linux
os_build=Linux
[options]
openssl=False
qt:openssl=False
[build_requires]
[env]
...
openssl/1.1.1m: Forced build from source
...


user: horst98
issue_10777: state: open
title: [question] Is example for `Implementing the scm feature` (migration to Conan 2.0) useful?
body: Hi Conans,

I would like to discuss the example and approach that is given on https://docs.conan.io/en/latest/reference/conanfile/tools/scm/git.html#example-implementing-the-scm-feature:

```
import os
from conan import ConanFile
from conan.tools.scm import Git
from conan.tools.files import load, update_conandata


class Pkg(ConanFile):
    name = "pkg"
    version = "0.1"

    def export(self):
        git = Git(self, self.recipe_folder)
        scm_url, scm_commit = git.get_url_and_commit()
        # we store the current url and commit in conandata.yml
        update_conandata(self, {"sources": {"commit": scm_commit, "url": scm_url}})

    def layout(self):
        self.folders.source = "."

    def source(self):
        # we recover the saved url and commit from conandata.yml and use them to get sources
        git = Git(self)
        sources = self.conan_data["sources"]
        git.clone(url=sources["url"], target=".")
        git.checkout(commit=sources["commit"])
```

I tried to implement the proposal for a Conan 1.x recipe, but it has some limitations I would like you to know:

- Git repositories may require authentication which is a little bit tricky with the code and Git class mentioned above (you need to add it dynamically to the url)
- Git raises an error that the source folder is not empty because some export files (e.g. the `conandata.yml`) are magically added

Furthermore the new approach clones the repository again when using `conan create` which may take much time (we have big repositories here) and prevents me from running this step offline (although package development flow should be fine). Is this really desired here?

My personal feeling is that the `scm` attribute is working fine and much better at present than the Conan 2.0 approach. In general I like the new idea and would ideally add it already to my Conan 1.X recipes, but the drawbacks and limitations mentioned above are a blocker for me.

What do you think?

Best regards,
Markus

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: gpxricky
issue_10776: state: open
title: [bug] `conan remote list_ref` and `conan remote list_pref` don't work if you have editable packages
body: If you try to use `conan remote list_ref` or `conan remote list_pref` while you have any editable packages you get:
`ERROR: Operation not allowed on a package installed as editable`

It seems like you should be able to skip over the editable packages or list them as editable in the output?

This is especially strange with `list_pref` since it gives the error even when the provided reference is not editable.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: Visual Studio 2017
  * Conan version: 1.44.0
  * Python version: 3.8.10

### Steps to reproduce (Include if Applicable)

* Verify there are no editable packages
* Run `conan remote list_ref`
* Add editable package
* Run `conan remote list_ref` --> error

user: nichmj01
issue_10772: state: open
title: [question] What does requires package status `no remote` mean?
body: When you run `conan install` and the requirements are resolved, they will be listed with their current status: `Cache`, `Downloaded`, and `No remote`. What does `No remote` mean and how can I get into this state?

Example:
```
LibA/1.2.0 from 'myserver' - Cache
LibB/3.31.0 from 'myserver' - Downloaded
LibC/9.1.0 from local cache - No remote
```

We've run into issues with binaries not being found for the recipes listed as `No remote` cause the package id isn't what we expect; presumably cause the recipe isn't the one we expect. 

We're using package_id_mode = recipe_revision_mode and we're specifying the recipe revision for all the requires packages.


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: nichmj01
issue_10768: state: open
title: [question] Recipes cannot build due to not specifying CMake as tool/build requirements
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

There are recipes that uses CMake to build, but they do not specify CMake as a `tool_requires` or `build_requires`.
For example `ninja/1.10.2`: https://github.com/conan-io/conan-center-index/blob/master/recipes/ninja/1.10.x/conanfile.py
So when there are no binaries for the particular configuration, and the recipe needs to build them, it does not find the `cmake` binary in the path.

Also a lot of these recipes do not yet use `CMakeDeps` and `CMakeToolchain` but still uses the legacy `cmake` generator.

We are essentially building a set of reusable base Conan recipes and profiles and to isolate ourselves from ConanCenter changes we host 3rd party recipes on our own Artifactory server. For now, we just upload the recipes and have clients build the binaries themselves to their local cache.
This is how this problem became visible: the `ninja/1.10.2` recipe was on our own Artifactory store and when we define `ninja` as a build requirement, it could not be built as `cmake` was not in the path **even though we specify `cmake/3.19.4` as a build requirement ourselves as well** (which does [update](https://github.com/conan-io/conan-center-index/blob/master/recipes/cmake/3.x.x/conanfile.py#L112) the `self._env_info.PATH` to include its binary path to the `cmake` binary), but this never gets triggered as the `ninja/1.10.2` recipe does not set cmake as a dependency of its own.

How is this supposed to be solved? What is the general approach here?
user: SeanSnyders
issue_10767: state: open
title: [question] gather packed installed via conan install as dependencies for artifactory buildinfo
body: Currently I'm doing the following to create a software package and publish it to artifactory:
- jf rt dl --build-name x --build-number y <some packages>
- jf rt bpe x y
- conan install .
- build everything, create installer etc
- jf rt upload --build-name x --build-name y <more opts>
- jf rt bp x y 

This creates my build in artifactory, uploads the binaries and I can see the build dependencies of all other binary assets downloaded via jf rt dl
What I am missing though is the info what conan packages I did pull in via conan install . (direct dependencies and dependencies those pulled in).

I read up about conan_build_info, but it does not seem to do whar I need, As it centers around just using conan, not getting other binaries in via jf and using jf for build info publishing etc.

Is there a way to achieve my goal right now, aka what did I overlook? Or am I in fact stumped right now?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Nicky-D
issue_10764: state: open
title: [question] How to select the binaries for a given package version?
body: <!-- What is your question? Please be as specific as possible! -->

If I want binaries built with a specific version of GCC, for example the spirv-cross binaries generated with gcc 12 for linux:
https://conan.io/center/spirv-cross?tab=configuration&os=

How do I specify that that specific package, and only that package, should use bianries generated with that compiler?

- [ x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Makogan
issue_10761: state: open
title: [question] Is it possible to integrate Conan package with a non-Conan one?
body: Hello,
Let us say my Conan package optionally can use non-Conan one - which is absent in Conan (eg, CMake one), but present on my local system.
The price - rebuilding my package locally - is not too high.
The question though is how to integrate them so that Conan would "understand" that my package now uses something else?
Is it at all possible?
user: gouriano
issue_10737: state: open
title: [bug] searching virtual repository does not search component local repository
body: This is an issue where when a virtual repository contains both a remote repository and a local repository, only the remote repository will be searched when invoking `conan search`, despite the local repository containing non-default configured binaries that will install successfully.

### Environment Details (include every applicable attribute)
  * Operating System+version: Arch Linux
  * Compiler+version: clang 13
  * Conan version: 1.46.0
  * Python version: 3.10.0
  * Artifactory Community Edition (Self Hosted): Conan edition license 7.31.13 rev 73113900 

### Steps to reproduce (Include if Applicable)
1. Set up a virtual repository, similarly to as follows, where `conan-center-builds` is the local repository deployment target of `conan-center-virtual` and `conan-center-remote` is the remote repository pointing at https://center.conan.io
![conan-repo](https://user-images.githubusercontent.com/36361864/157235387-7a3ed108-9225-4fa1-85b7-bd59d3bc58d3.png)
2. Build a package with a non standard configuration:
```bash
$ conan install armadillo/10.7.3@ -o use_lapack=openblas --build=missing
```
3. Upload non-standard binary to virtual:
```bash
$ conan upload armadillo/10.7.3@:28678c86e642de6430f76466384a432cc9b8bd4d --all -r conan-center-virtual
```
4. Wipe this from cache to ensure it has uploaded properly and will download:
```bash
$ conan remove armadillo
$ conan install armadillo/10.7.3@ -o use_lapack=openblas
```
5. Search for this package in the remote
```
$ conan search armadillo/10.7.3@ -r conan-center-virtual | grep 28678c86e642de6430f76466384a432cc9b8bd4d
```
Note that this will return no results, because `conan-center-builds` is not searched. It will however return results for `conan-center-remote`. I get 72 configurations without grepping the above command.


### Logs (Executed commands with output) (Include/Attach if Applicable)

```bash
$ conan remove armadillo
Are you sure you want to delete from 'armadillo/10.7.3' (yes/no): yes
$ conan install armadillo/10.7.3@ -o use_lapack=openblas
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=clang
compiler.libcxx=libstdc++11
compiler.version=13
os=Linux
os_build=Linux
[options]
use_lapack=openblas
[build_requires]
[env]
CC=/usr/bin/clang
CXX=/usr/bin/clang++
armadillo/10.7.3: Not found in local cache, looking in remotes...
armadillo/10.7.3: Trying with 'conan-center-virtual'...
Downloading conanmanifest.txt completed [0.26k]
Downloading conanfile.py completed [13.06k]
Downloading conan_export.tgz completed [0.31k]
Decompressing conan_export.tgz completed [0.00k]
armadillo/10.7.3: Downloaded recipe revision 722293f6c1dcf90989e8f7ff41561f2c
Installing package: armadillo/10.7.3
Requirements
    armadillo/10.7.3 from 'conan-center-virtual' - Downloaded
    hdf5/1.12.0 from 'conan-center-virtual' - Cache
    openblas/0.3.15 from 'conan-center-virtual' - Cache
    zlib/1.2.11 from 'conan-center-virtual' - Cache
Packages
    armadillo/10.7.3:28678c86e642de6430f76466384a432cc9b8bd4d - Download
    hdf5/1.12.0:99f071c4d0b78b591a6ca63057f44e0e6c95701b - Cache
    openblas/0.3.15:9d6665a9a4afaf7838ce20fb44ef94df8bde8e0f - Cache
    zlib/1.2.11:63c2a85d57849e261f98f935b93ecac31ba71b84 - Cache

Installing (downloading, building) binaries...
armadillo/10.7.3: Retrieving package 28678c86e642de6430f76466384a432cc9b8bd4d from remote 'conan-center-virtual'
Downloading conanmanifest.txt completed [44.06k]
Downloading conaninfo.txt completed [1.33k]
Downloading conan_package.tgz completed [565.96k]
Decompressing conan_package.tgz completed [0.00k]
armadillo/10.7.3: Package installed 28678c86e642de6430f76466384a432cc9b8bd4d
armadillo/10.7.3: Downloaded package revision 97a813db630d8de50911bf8282d648dc
openblas/0.3.15: Already installed!
openblas/0.3.15: Setting OpenBLAS_HOME environment variable: /home/user/.conan/data/openblas/0.3.15/_/_/package/9d6665a9a4afaf7838ce20fb44ef94df8bde8e0f
[HOOK - conan-center.py] post_package_info(): [CMAKE FILE NOT IN BUILD FOLDERS (KB-H019)] OK
[HOOK - conan-center.py] post_package_info(): [LIBRARY DOES NOT EXIST (KB-H054)] OK
zlib/1.2.11: Already installed!
[HOOK - conan-center.py] post_package_info(): [CMAKE FILE NOT IN BUILD FOLDERS (KB-H019)] OK
[HOOK - conan-center.py] post_package_info(): [LIBRARY DOES NOT EXIST (KB-H054)] OK
hdf5/1.12.0: Already installed!
[HOOK - conan-center.py] post_package_info(): [CMAKE FILE NOT IN BUILD FOLDERS (KB-H019)] OK
[HOOK - conan-center.py] post_package_info(): [LIBRARY DOES NOT EXIST (KB-H054)] OK
[HOOK - conan-center.py] post_package_info(): [CMAKE FILE NOT IN BUILD FOLDERS (KB-H019)] OK
[HOOK - conan-center.py] post_package_info(): [LIBRARY DOES NOT EXIST (KB-H054)] OK
Aggregating env generators
$ conan search armadillo/10.7.3@ -r conan-center-virtual | grep 28678c86e642de6430f76466384a432cc9b8bd4d
$ 
```
To demonstrate that this does actually return results:
```
$ conan search armadillo/10.7.3@ -r conan-center-virtual | wc -l
1664
```

user: samuel-emrys
issue_10735: state: open
title: [bug] Dependencies in recipe self.deps_cpp_info not available at generate() time
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: macOS 10.15.7
  * Compiler+version: n/a
  * Conan version: 1.45.0
  * Python version: 3.9


### Goal
Similar to issue comment https://github.com/conan-io/conan/issues/10304#issuecomment-1009722203 I also need the dependency information available at `generate()` time such that I can correctly initialise the `CMakeToolchain` generator using **meta info from the dependency**, e.g. something like this:
```
generate(self):
  ...
  target_name = self.deps_cpp_info[<dep>].components[<component>].names["cmake_target_name"]
  tc = CMakeToolchain(self)
  tc.variables["<dep>_TARGET_NAME"] = target_name
  ...
```

and use that set variable from the `CMakeToolchain` in my `CMakeLists.txt` file, e.g. in this case, such that I am always going to use the correct target name from my dependency when I am trying to link to it.


### Steps to reproduce (Include if Applicable)

Use recipe and profile below and call command in terminal:
`conan install . -if=build-debug -pr:h default -pr:h test_deps.profile -pr:b default`

You will see output of `self.deps_cpp_info` having zero elements:
```
conanfile.py: self.deps_cpp_info [0]: odict_items([])
```

`conanfile.py`
```python
from conans import ConanFile

class DependenciesCheck(ConanFile):

    def validate(self):
        self.output.info(f"Running validate...")
        self.output.info(f"self.dependencies [{len(self.dependencies.items())}]: {self.dependencies}")
        for require, dependency in self.dependencies.items():
            self.output.info("Dependency is direct={}: {}".format(require.direct, dependency.ref))

    def generate(self):
        self.output.info("Running generate...")
        self.output.info(f"self.dependencies [{len(self.dependencies.items())}]: {self.dependencies}")
        for require, dependency in self.dependencies.items():
            self.output.info("Dependency is direct={}: {}".format(require.direct, dependency.ref))

        self.output.info(f"self.deps_cpp_info [{len(self.deps_cpp_info.dependencies)}]: {self.deps_cpp_info.dependencies}")
        for name, dep in self.deps_cpp_info.dependencies:
            self.output.info("Dependency {}: {}".format(name, dep))

```
`test_deps.profile`
```
[settings]
[options]
[build_requires]
cmake/3.19.4
gtest/1.11.0#a35bd6be75af15855a7c8c861888cd90
benchmark/1.6.0#abc2853305ae1834eb47ccb84a715c81
[env]
```

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
conan install . -if=build-debug -pr:h default -pr:h test_deps.profile -pr:b default
Configuration (profile_host):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=12.0
os=Macos
os_build=Macos
[options]
[build_requires]
*: cmake/3.19.4, gtest/1.11.0, benchmark/1.6.0
[env]

Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=12.0
os=Macos
os_build=Macos
[options]
[build_requires]
[env]

conanfile.py: Running validate...
conanfile.py: self.dependencies [0]: <conans.model.dependencies.ConanFileDependencies object at 0x10379e560>
conanfile.py: Installing package
Requirements
Packages
Build requirements
    benchmark/1.6.0 from 'conancenter' - Cache
    cmake/3.19.4 from 'conancenter' - Cache
    gtest/1.11.0 from 'conancenter' - Cache
    openssl/1.1.1k from 'conancenter' - Cache
Build requirements packages
    benchmark/1.6.0:2f7a9fc6a21fda7cdeaab303f436ee769d8e964c - Cache
    cmake/3.19.4:cf36af68367ac960cc1360ef3ea3c735fa475414 - Cache
    gtest/1.11.0:9e8e90672d7a216fdaac8d6a37a0bbd4a25f56a6 - Cache
    openssl/1.1.1k:647afeb69d3b0a2d3d316e80b24d38c714cc6900 - Cache

Installing (downloading, building) binaries...
benchmark/1.6.0: Already installed!
gtest/1.11.0: Already installed!
openssl/1.1.1k: Already installed!
cmake/3.19.4: Already installed!
cmake/3.19.4: Appending PATH environment variable: /Users/ssnyder/Development/ConanData_1450_ConanBase_090/cmake/3.19.4/_/_/package/cf36af68367ac960cc1360ef3ea3c735fa475414/bin
conanfile.py: Applying build-requirement: cmake/3.19.4
conanfile.py: Applying build-requirement: gtest/1.11.0
conanfile.py: Applying build-requirement: benchmark/1.6.0
conanfile.py: Applying build-requirement: openssl/1.1.1k
conanfile.py: Generator txt created conanbuildinfo.txt
conanfile.py: Calling generate()
conanfile.py: Running generate...
conanfile.py: self.dependencies [4]: <conans.model.dependencies.ConanFileDependencies object at 0x103825930>
conanfile.py: Dependency is direct=True: cmake/3.19.4
conanfile.py: Dependency is direct=True: gtest/1.11.0
conanfile.py: Dependency is direct=True: benchmark/1.6.0
conanfile.py: Dependency is direct=False: openssl/1.1.1k
conanfile.py: self.deps_cpp_info [0]: odict_items([])
conanfile.py: Aggregating env generators
conanfile.py: Generated conaninfo.txt
conanfile.py: Generated graphinfo
```


user: SeanSnyders
issue_10726: state: open
title: [bug] self.copy : PermissionDenied copying symlinks on Windows
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

from https://github.com/conan-io/conan-center-index/issues/9633

NOTE : it needs so called `Developer Mode` to be enabled as exaplined here: https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/, in order to get symbolic links creation available for non-admin

### Environment Details (include every applicable attribute)
  * Operating System+version: `Windows 10 21H1 19043.1526`
  * Compiler+version: `Microsoft (R) C/C++ Optimizing Compiler Version 19.30.30706 for x86`
  * Conan version: `conan 1.45.0`
  * Python version: `Python 3.9.7`

### Steps to reproduce (Include if Applicable)

run:
```
$ conan install meson/0.60.2@ --build meson
```

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
ERROR: Traceback (most recent call last):
  File "c:\conan\conan\conans\errors.py", line 34, in conanfile_exception_formatter
    yield
  File "c:\conan\conan\conans\client\conanfile\package.py", line 52, in _call_package
    conanfile.package()
  File "C:\Users\sse4\.conan\data\meson\0.60.2\_\_\export\conanfile.py", line 46, in package
    self.copy(pattern="*", dst="bin", src=self._source_subfolder)
  File "c:\conan\conan\conans\client\file_copier.py", line 84, in __call__
    fs = self._copy(src_folder, pattern, src, dst, links, ignore_case, excludes,
  File "c:\conan\conan\conans\client\file_copier.py", line 103, in _copy
    copied_files = self._copy_files(files_to_copy, src, dst, keep_path, symlinks)
  File "c:\conan\conan\conans\client\file_copier.py", line 240, in _copy_files
    shutil.copy2(abs_src_name, abs_dst_name)
  File "C:\Users\sse4\AppData\Local\Programs\Python\Python39\lib\shutil.py", line 443, in copy2
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "C:\Users\sse4\AppData\Local\Programs\Python\Python39\lib\shutil.py", line 265, in copyfile
    with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
PermissionError: [Errno 13] Permission denied: 'C:\\Users\\sse4\\.conan\\data\\meson\\0.60.2\\_\\_\\source\\source_subfolder\\test cases\\frameworks\\35 boost symlinks\\boost\\include\\boost'
```

broken link looks like:
```
03/07/2022  02:12 AM    <SYMLINKD>     boost [../Cellar/boost/0.3.0/include/boost]   
```

might be related to https://bugs.python.org/issue13702


<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SSE4
issue_10722: state: open
title: [question] Unable to tell conan that SSL validation is not required
body: When I try install SDL package I get:

> libcap/2.62: Configuring sources in /home/adam/.conan/data/libcap/2.62/_/_/source
> ERROR: Error downloading file https://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/libcap-2.62.tar.xz: 'HTTPSConnectionPool(host='www.kernel.org', port=443): Max retries exceeded with url: /pub/linux/libs/security/linux-privs/libcap2/libcap-2.62.tar.xz (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1108)')))'
> Waiting 5 seconds to retry...
> ERROR: libcap/2.62: Error in source() method, line 46
>  tools.get(**self.conan_data["sources"][self.version],
>  ConanException: Error downloading file https://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/libcap-2.62.tar.xz: 'HTTPSConnectionPool(host='www.kernel.org', port=443): Max retries exceeded with url: /pub/linux/libs/security/linux-privs/libcap2/libcap-2.62.tar.xz (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1108)')))'

I tried adding SSL certificate of https://www.kernel.org/ to the file ~/.conan/cacert.pem. Used command:

`openssl s_client -showcerts -connect www.kernel.org:443 </dev/null | openssl x509 -text`

I have tried to add conan remotes with ssl_validate flag set to false by:
```
conan remote add kernel www.kernel.org false
conan remote add kernel https://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/ false
conan remote add kernel https://www.kernel.org/ false
```
Is there anything I'm doing wrong or that's a bug that would have to be reported?


user: stepniakadam
issue_10719: state: open
title: [question] Problems with cross compilation on Macos
body: Hello

I am trying to cross-compile [ncbi-cxx-toolkit-public/26.0.1](https://github.com/conan-io/conan-center-index/tree/master/recipes/ncbi-cxx-toolkit-public) for Macos/arm8 and get the following error:

    ERROR: libpng/1.6.37: option 'neon' doesn't exist
    Possible options are ['shared', 'fPIC', 'sse', 'api_prefix']

I have added dependency on itself (because I need a tool from the NCBI package that would work on the native platform):

    def build_requirements(self):
        if hasattr(self, "settings_build") and tools.cross_building(self):
            self.build_requires("{}/{}".format(self.name, self.version))

My OS is macOS Catalina v 10.15.7
Conan version 1.45.0
and I use these profiles:

    Configuration (profile_host):
    [settings]
    arch=armv8
    build_type=Release
    compiler=apple-clang
    compiler.libcxx=libc++
    compiler.version=12.0
    os=Macos
    [options]
    [build_requires]
    [env]

    Configuration (profile_build):
    [settings]
    arch=x86_64
    arch_build=x86_64
    build_type=Release
    compiler=apple-clang
    compiler.libcxx=libc++
    compiler.version=12.0
    os=Macos
    os_build=Macos
    [options]
    [build_requires]
    [env]

I see that [libpng](https://conan.io/center/libpng?tab=recipe) indeed removes neon setting sometimes:

       if not self._has_neon_support:
            del self.options.neon

So, I thought maybe it was some kind of bug in Conan. But then I tried to do a similar thing in the standard [_HelloConan_](https://docs.conan.io/en/latest/creating_packages/getting_started.html) package (old style one, without "template"). I mean I have added this code into its recipe:

    def build_requirements(self):
        if hasattr(self, "settings_build") and tools.cross_building(self):
            self.requires("hello/0.1")
    def requirements(self):
        self.requires("libpng/1.6.37")

and it compiled just fine with the same profiles.

I am sorry, but I have absolutely no clue why it works in [HelloConan](https://docs.conan.io/en/latest/creating_packages/getting_started.html) and does not work in my package. It seems I do the same things. And I do not set or mention "neon" setting in my recipe.
I would appreciate any help or hints.
Thanks

user: gouriano
issue_10709: state: open
title: [bug] cmake error output not shown when using msys2/git bash
body: I've noticed that what cmake writes stderr/stdout isn't captured and proxied by conan to stdout during the configure phase (i think), and so CMake errors aren't showing.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: Visual Studio 2022 (17)
  * Conan version: 1.45.0
  * Python version: 3.9.7
  * CMake version: 3.20.3

### Steps to reproduce (Include if Applicable)
Set up a profile that looks like the following:

```
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
```
Run 
```
conan install bzip2/1.0.8@ --build=missing -pr=vs2022
```

Because this is executed using cmake 3.20.3, the Visual Studio 17 2022 generator doesn't exist, and CMake throws the following error:

```
CMake Error: Could not create named generator Visual Studio 17 2022
```
Unfortunately, this is not displayed when attempting to build using `conan` - I only discovered this after attempting to invoke `cmake` directly

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
$ conan install bzip2/1.0.8@ --build=missing -pr=vs2022
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

bzip2/1.0.8: Not found in local cache, looking in remotes...
bzip2/1.0.8: Trying with 'conan-center'...
Downloading conanmanifest.txt
Downloading conanfile.py
Downloading conan_export.tgz
bzip2/1.0.8: Downloaded recipe revision b056f852bd2d5af96fc7171aadfd6c0b
Installing package:bzip2/1.0.8
Requirements
    bzip2/1.0.8 from 'conan-center' - Downloaded
Packages
    bzip2/1.0.8:53b5fd22ba061620078deefdae9a437c5f693201 - Build

Installing (downloading, building) binaries...
Downloading conan_sources.tgz
bzip2/1.0.8: Configuring sources in C:\Users\user\.conan/data/bzip2\1.0.8\_\_\source

bzip2/1.0.8: Copying sources to build folder
bzip2/1.0.8: Building your package in C:\Users\user\.conan\data\bzip2\1.0.8\_\_\build\53b5fd22ba061620078deefdae9a437c5f693201
bzip2/1.0.8: Generator cmake created conanbuildinfo.cmake
bzip2/1.0.8: Aggregating env generators
bzip2/1.0.8: Calling build()
bzip2/1.0.8:
bzip2/1.0.8: ERROR: Package '53b5fd22ba061620078deefdae9a437c5f693201' build failed
bzip2/1.0.8: WARN: Build folder C:\Users\user\.conan\data\bzip2\1.0.8\_\_\build\53b5fd22ba061620078deefdae9a437c5f693201
ERROR: bzip2/1.0.8: Error in build() method, line 67
        cmake = self._configure_cmake()
while calling '_configure_cmake', line 61
        self._cmake.configure()
        ConanException: Error 1 while executing cd C:\Users\user\.conan\data\bzip2\1.0.8\_\_\build\53b5fd22ba061620078deefdae9a437c5f693201 && cmake -G "Visual Studio 17 2022" -A "x64" -DCONAN_LINK_RUNTIME="/MD" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="Visual Studio" -DCONAN_COMPILER_VERSION="17" -DCONAN_CXX_FLAGS="/MP8" -DCONAN_C_FLAGS="/MP8" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="C:\Users\user\.conan\data\bzip2\1.0.8\_\_\package\53b5fd22ba061620078deefdae9a437c5f693201" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE-INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -DBZ2_VERSION_STRING="1.0.8" -DBZ2_VERSION_MAJOR="1" -DBZ_BUILD_EXE="True" -Wno-dev C:\Users\user\.conan\data\bzip2\1.0.8\_\_\build\53b5fd22ba061620078deefdae9a437c5f693201
```

user: samuel-emrys
issue_10708: state: open
title: [question] static code analysis over multiple packages
body: Hello,

tl;dr: our goal is to run static code analysis over all code used in our final application from multiple component packages, but we don't know how to get the code.

Some background: we are coming from an old monolithic build approach and are looking to migrate to a more modular approach using Conan and CMake. In the old world, we had a long list of files to feed into the compiler, a list of include directories and a list of compiler switches. From there it was rather trivial to re-use these lists as an input for the static code analysis.

We have split our monolith into several components that are each pre-built and packaged with Conan. Then we have an integration recipe for the main app, that "requires" all of the relevant components and some glue code to put it all together. So if you want to build the main app, you just need the integration recipe and the glue code. Since the components are pre-built, Conan will just download the binaries and can build the final app. This is fast and great for the purpose of the regular build. However, the exported sourcecode isn't even downloaded, thus there is no chance to access any of it for the static code analysis.

To add some complexity: our component recipes typically have options which are handed down to CMake to build variants of the components. The options can be used to determine which of the exported .c files are actually used during the build. Since this is done in CMake, Conan does not know which of the files will actually be used. The final app also has many variants that might "require" different components and set different options for these components. Thus, a specific instance of the final app will consist of a certain subset of .c code (and compiler switches). Only that subset should be considered for the static code analysis.

We have thought about just packaging the sourcecode alongside the binaries and importing that in the integration recipe. However, this does not cover the variants described in the last paragraph, unless we move/duplicate the code from the CMake file back into the recipe. Not sure how to handle compiler switches. Also, from our limited experience with Conan, it feels redundant and "incorrect" (but we could be wrong). As described in the beginning, the call of the compile toolchain in the old world was very similar to calling the static code analysis, which steered our minds towards writing our own custom generator for this, but that custom generator would need to be synched to what is used in the CMake build and overall is a daunting endeavour for Conan newbies such as ourselves.

If you've made it this far, thanks for reading! We would love to hear your thoughts!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: AneGris
issue_10680: state: open
title: NDEBUG not set in multi-target when build in conan cache
body: I have a single-target conan project that is consuming a multi-target conan component. I observe that NDEBUG is not set for component when the component is build as part of conan install of the consumer. The same is observed with conan test-package (a simple consumer test). The build is a RELEASE build just that NDEBUG is not set. However, the NDEBUG is set correctly when the subcomponent is build locally via conan build or from VS IDE.

Looking for any pointers to investigate it further.
user: michkrom
issue_10668: state: open
title: [question] Do SIP issues in Build helpers on macOS come from conan or not?
body: In conan-center, a common issue on macOS is "all shared" build of autotools based recipes.

What happen:

- recipe uses `AutotoolsBuildEnvironment` helper since underlying build system is autotools
- recipe has dependencies with `shared` option
- a consumer build from source with `conan install <recipename/version>@ "*":shared=True -b`
- when `configure` script is executed, there are hard errors for native builds while executing `conftest` executable: shared dependencies cannot be located by the loader on macOS. On Linux it works fine AFAIK.

There are 2 workarounds:
- force `autotools.libs = []`, but for complex recipes where dependencies are not found through `PKG_CHECK_MODULES`, it's not an option.
- Patch `configure` on the fly to inject something like `export DYLD_LIBRATY_PATH=<all libdirs of conan dependencies>` (and here we are interested on `requires` by the way) inside this script (see https://github.com/conan-io/conan-center-index/pull/8635/commits/fde36dee223125ce35f574d6b48f75e8e259fe4f). Indeed, any attempt to inject `DYLD_LIBRATY_PATH` with something like `virtualenv`/`VirtualRunEnv` doesn't work, `DYLD_LIBRATY_PATH` is reinitialized somewhere by SIP before `configure` execution.

Question: does this `DYLD_LIBRATY_PATH` reinitialization by SIP come from the way conan calls `configure` in its autotools helpers or not (it relies on `self.run` under the hood)? Do you see this issue in the new helper? Is there a functional test for this case?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: SpaceIm
issue_10660: state: open
title: [question] Tagging packages from beta versions of the compiler
body: Currently we build most of our libraries using Conan on a Jenkins ci server. We build for all the platforms we support using different compilers and push them to Artifactory. Any changes we make to our Conan recipes are pushed to a test channel. When we merge those changes into the main channel, we rebuild the libraries and push them into the stable channel. So far, so good, everything is working well.
We are also trying to build with the latest beta compilers from Apple and Microsoft, so we need to add those compiler versions to settings.yml. 
We are currently deploying these builds in a beta channel. If we want to build our product with these beta compilers, we need to change our consuming conanfile.py to use this channel, which is cumbersome.
Alternatively, we could add an option to all conan recipes and add a tag to all BETA packages, or we could change settings.yml and add a 13.1beta compiler version, for example. What do you think is the best approach?
user: NoWiseMan
issue_10649: state: open
title: [bug] Cache files deleted when running conan info --paths on Windows
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: N/A
  * Conan version: 1.45.0
  * Python version: 3.7.8

### Steps to reproduce (Include if Applicable)

1. Delete Conan cache
2. Run `conan install ..` in the build directory to populate the cache for that project
3. Run `conan info . --paths`
4. Try to generate CMake or build - it will fail due to missing files in the Conan cache

Here is the script we are using to reproduce the problem, running in Git Bash.  It does a `find` on the cache directory, then runs `conan info --paths .`, then runs `find` again and diffs the outputs from the two `find` commands.  The `--paths` is important.  The bug doesn't happen without `--paths`.
```
#!/bin/bash
conan_user_home=/c/Users/myusername

conan_data=$conan_user_home/.conan/data
test -d $conan_data || { echo "No $conan_data"; exit 1; }

conan_bug() {
  list_conan_files() {
    local out=$1
    find $conan_data -ls > $out
  }

  list_conan_files conan_files_before.out

  conan info . --paths > conan_info.out 2>&1

  list_conan_files conan_files_after.out

  if ! diff -q conan_files_{before,after}.out; then
    local diffFile=conan_files.patch
    diff conan_files_{before,after}.out  > $diffFile
    echo "Bug! Diff in $diffFile"
  else
    echo all good
  fi
}

conan_bug
```

One thing: the bug does not trigger for some projects with fewer requirements.

### Logs (Executed commands with output) (Include/Attach if Applicable)

Here is the conan info output from the test script:
<details>
Version ranges solved
    Version range '>=1.2.0-dev' required by 'conanfile.py (tw-base/1.10.0-dev.62781)' resolved to 'tw-utils/1.2.0-dev.90@tw/dev' in local cache

boost/1.76.0
    ID: e25da6736836401d14d18eb2361204b3783cc5f4
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\boost\1.76.0\_\_\export
    source_folder: C:\.conan\e9a2e453\1
    build_folder: C:\.conan\8810d71e\1
    package_folder: C:\.conan\80757b73\1
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://www.boost.org
    License: BSL-1.0
    Description: Boost provides free peer-reviewed portable C++ source libraries
    Topics: libraries, cpp
    Provides: boost
    Recipe: Cache
    Revision: 0807a2f563b4e9b1efa8ef4d96d1e704
    Package revision: 853ea955c5427742f589f367336d6312
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2022-02-17 11:47:10 UTC
    Required by:
        folly/2022.01.31.00
        conanfile.py (tw-base/1.10.0-dev.62781)
    Requires:
        zlib/1.2.11
        bzip2/1.0.8
bzip2/1.0.8
    ID: 589a23dff5fdb23a7fb851223eb766480ead0a9a
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\bzip2\1.0.8\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\bzip2\1.0.8\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\bzip2\1.0.8\_\_\build\589a23dff5fdb23a7fb851223eb766480ead0a9a
    package_folder: C:\Users\EPederson\.conan\data\bzip2\1.0.8\_\_\package\589a23dff5fdb23a7fb851223eb766480ead0a9a
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: http://www.bzip.org
    License: bzip2-1.0.8
    Description: bzip2 is a free and open-source file compression program that uses the Burrows Wheeler algorithm.
    Topics: conan, bzip2, data-compressor, file-compression
    Provides: bzip2
    Recipe: Cache
    Revision: e52d9968609c76bf3a92c1216f6e817a
    Package revision: 583861f1ca1da7cf4354cbb4cfe3bfa9
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-12-29 20:15:04 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
        folly/2022.01.31.00
        boost/1.76.0
caf/0.17.6@bincrafters/stable
    ID: 58f74b542d22ee717e309aab080baa2426fc399b
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\caf\0.17.6\bincrafters\stable\export
    source_folder: C:\Users\EPederson\.conan\data\caf\0.17.6\bincrafters\stable\source
    build_folder: C:\Users\EPederson\.conan\data\caf\0.17.6\bincrafters\stable\build\58f74b542d22ee717e309aab080baa2426fc399b
    package_folder: C:\Users\EPederson\.conan\data\caf\0.17.6\bincrafters\stable\package\58f74b542d22ee717e309aab080baa2426fc399b
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/bincrafters/conan-caf
    Homepage: https://github.com/actor-framework/actor-framework
    License: BSD-3-Clause, BSL-1.0
    Description: An open source implementation of the Actor Model in C++
    Topics: conan, caf, actor-framework, actor-model, pattern-matching, actors
    Provides: caf
    Recipe: Cache
    Revision: f7d94935fc778a3862646aa864d0ec37
    Package revision: 3c732ca7fd85d28e6b75cc7b4112cb30
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-08-04 14:36:30 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
    Requires:
        openssl/1.1.1m
catch2/2.11.0
    ID: 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\catch2\2.11.0\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\catch2\2.11.0\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\catch2\2.11.0\_\_\build\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    package_folder: C:\Users\EPederson\.conan\data\catch2\2.11.0\_\_\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/catchorg/Catch2
    License: BSL-1.0
    Description: A modern, C++-native, header-only, framework for unit-tests, TDD and BDD
    Topics: conan, catch2, header-only, unit-test, tdd, bdd
    Provides: catch2
    Recipe: Cache
    Revision: d8aa8d027d133eddec6135f375b719d8
    Package revision: b5e546836b311b5b59f38f532af5c850
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-03-20 16:46:05 UTC
    Required by:
        tw-utils/1.2.0-dev.90@tw/dev
cppzmq/4.3.0@bincrafters/stable
    ID: 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\cppzmq\4.3.0\bincrafters\stable\export
    source_folder: C:\Users\EPederson\.conan\data\cppzmq\4.3.0\bincrafters\stable\source
    build_folder: C:\Users\EPederson\.conan\data\cppzmq\4.3.0\bincrafters\stable\build\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    package_folder: C:\Users\EPederson\.conan\data\cppzmq\4.3.0\bincrafters\stable\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/bincrafters/conan-cppzmq
    Homepage: https://github.com/zeromq/cppzmq
    License: MIT
    Author: Bincrafters <bincrafters@gmail.com>
    Description: C++ binding for 0MQ
    Topics: conan, cppzmq, zmq-cpp, zmq, cpp-bind
    Provides: cppzmq
    Recipe: Cache
    Revision: 0
    Package revision: dc34311948c2a1bbc9d8c8a2e9677311
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2018-11-21 14:52:02 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
    Requires:
        zmq/4.3.2@bincrafters/stable
double-conversion/3.1.5
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\double-conversion\3.1.5\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\double-conversion\3.1.5\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\double-conversion\3.1.5\_\_\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\double-conversion\3.1.5\_\_\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/google/double-conversion
    License: BSD-3-Clause
    Description: Efficient binary-decimal and decimal-binary conversion routines for IEEE doubles.
    Topics: conan, double-conversion, google, decimal-binary, conversion
    Provides: double-conversion
    Recipe: Cache
    Revision: bf7fceaa33f97d13a341039f49a5ec8f
    Package revision: 402b8eb917c2d7d4a7d15f247c11a008
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-10-02 05:59:10 UTC
    Required by:
        folly/2022.01.31.00
flatbuffers/2.0.5@third-party/stable
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\flatbuffers\2.0.5\third-party\stable\export
    source_folder: C:\Users\EPederson\.conan\data\flatbuffers\2.0.5\third-party\stable\source
    build_folder: C:\Users\EPederson\.conan\data\flatbuffers\2.0.5\third-party\stable\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\flatbuffers\2.0.5\third-party\stable\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: http://google.github.io/flatbuffers
    License: Apache-2.0
    Description: Memory Efficient Serialization Library
    Topics: flatbuffers, serialization, rpc, json-parser
    Provides: flatbuffers
    Recipe: Cache
    Revision: 5075afc7e43d9df571d72a19315fd69a
    Package revision: ac9f7ff9c8fb5e62d7af11159a615a02
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2022-02-10 13:21:52 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
fmt/7.0.3
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\fmt\7.0.3\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\fmt\7.0.3\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\fmt\7.0.3\_\_\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\fmt\7.0.3\_\_\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/fmtlib/fmt
    License: MIT
    Description: A safe and fast alternative to printf and IOStreams.
    Topics: conan, fmt, format, iostream, printf
    Provides: fmt
    Recipe: Cache
    Revision: 2e4cfb84c7647e8c2b5fef1ebb527b7a
    Package revision: 78f609d057d3563e531819c211bfe03b
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-08-08 16:47:08 UTC
    Required by:
        tw-utils/1.2.0-dev.90@tw/dev
        folly/2022.01.31.00
        spdlog/1.8.0
folly/2022.01.31.00
    ID: 2a3b256e38788411e65a55a2f7a6b85b4b995c8b
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\folly\2022.01.31.00\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\folly\2022.01.31.00\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\folly\2022.01.31.00\_\_\build\2a3b256e38788411e65a55a2f7a6b85b4b995c8b
    package_folder: C:\Users\EPederson\.conan\data\folly\2022.01.31.00\_\_\package\2a3b256e38788411e65a55a2f7a6b85b4b995c8b
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/facebook/folly
    License: Apache-2.0
    Description: An open-source C++ components library developed and used at Facebook
    Topics: facebook, components, core, efficiency
    Provides: folly
    Recipe: Cache
    Revision: ff360a7cf824c12f6d1d00b2caf63ee8
    Package revision: b8df5467ad02f84dbb028ad3c0e3a5ff
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2022-02-19 12:15:02 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
    Requires:
        boost/1.76.0
        bzip2/1.0.8
        double-conversion/3.1.5
        gflags/2.2.2
        glog/0.4.0
        libevent/2.1.12
        openssl/1.1.1m
        lz4/1.9.3
        snappy/1.1.8
        zlib/1.2.11
        zstd/1.4.9
        libdwarf/20191104
        libsodium/1.0.18
        xz_utils/5.2.5
        fmt/7.0.3
gflags/2.2.2
    ID: 60e6dddb64f49e7d8f594e57ac47c02ff54576be
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\gflags\2.2.2\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\gflags\2.2.2\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\gflags\2.2.2\_\_\build\60e6dddb64f49e7d8f594e57ac47c02ff54576be
    package_folder: C:\Users\EPederson\.conan\data\gflags\2.2.2\_\_\package\60e6dddb64f49e7d8f594e57ac47c02ff54576be
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/gflags/gflags
    License: BSD-3-Clause
    Description: The gflags package contains a C++ library that implements commandline flags processing
    Topics: conan, gflags, cli, flags, commandline
    Provides: gflags
    Recipe: Cache
    Revision: 906109e9e83ad47452e561036a69f2fb
    Package revision: 776a70a4f6e9ed9b45f9574e4ef8ab16
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2019-11-14 08:47:10 UTC
    Required by:
        folly/2022.01.31.00
        glog/0.4.0
glog/0.4.0
    ID: ec5224ad7a60b4e9949c804ecd11728d8fa7555d
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\glog\0.4.0\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\glog\0.4.0\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\glog\0.4.0\_\_\build\ec5224ad7a60b4e9949c804ecd11728d8fa7555d
    package_folder: C:\Users\EPederson\.conan\data\glog\0.4.0\_\_\package\ec5224ad7a60b4e9949c804ecd11728d8fa7555d
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/google/glog/
    License: BSD-3-Clause
    Description: Google logging library
    Topics: conan, glog, logging
    Provides: glog
    Recipe: Cache
    Revision: 84333f1bce37d868e0d3c6f8d025fc12
    Package revision: e0b5ffa8caa75d355062ee77028a85b5
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-08-14 10:44:56 UTC
    Required by:
        folly/2022.01.31.00
    Requires:
        gflags/2.2.2
jsoncpp/1.9.2
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\jsoncpp\1.9.2\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\jsoncpp\1.9.2\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\jsoncpp\1.9.2\_\_\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\jsoncpp\1.9.2\_\_\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/open-source-parsers/jsoncpp
    License: MIT
    Description: A C++ library for interacting with JSON.
    Topics: conan, json, parser, config
    Provides: jsoncpp
    Recipe: Cache
    Revision: f0bf3adfec139dcb080d6b2b007f6a6f
    Package revision: d24c0a4683530eeca9634c42690391c8
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-09-04 06:46:01 UTC
    Required by:
        tw-utils/1.2.0-dev.90@tw/dev
libcurl/7.71.0
    ID: 0a15b3554d54d89968fdd6ac216f2471a295beb6
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\libcurl\7.71.0\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\libcurl\7.71.0\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\libcurl\7.71.0\_\_\build\0a15b3554d54d89968fdd6ac216f2471a295beb6
    package_folder: C:\Users\EPederson\.conan\data\libcurl\7.71.0\_\_\package\0a15b3554d54d89968fdd6ac216f2471a295beb6
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://curl.haxx.se
    License: MIT
    Description: command line tool and library for transferring data with URLs
    Topics: conan, curl, libcurl, data-transfer
    Provides: libcurl
    Recipe: Cache
    Revision: 7b2537fb315faa8463f8d11e3368ab59
    Package revision: 4cc0cec3c4d527eaf275856588731a71
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-09-18 18:49:56 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
    Requires:
        openssl/1.1.1m
        zlib/1.2.11
libdwarf/20191104
    ID: 31b2acce1b71b1c179eaef3f8b37cd0d0d55ef7a
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\libdwarf\20191104\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\libdwarf\20191104\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\libdwarf\20191104\_\_\build\31b2acce1b71b1c179eaef3f8b37cd0d0d55ef7a
    package_folder: C:\Users\EPederson\.conan\data\libdwarf\20191104\_\_\package\31b2acce1b71b1c179eaef3f8b37cd0d0d55ef7a
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://www.prevanders.net/dwarf.html
    License: LGPL-2.1
    Description: A library and a set of command-line tools for reading and writing DWARF2
    Topics: conan, libdwarf, dwarf2, debugging, dwarf
    Provides: libdwarf
    Recipe: Cache
    Revision: c01616ef4050a22e52de8d0a14f3f25f
    Package revision: bf230ffe068a068ba545b7f807e7b455
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-12-29 15:41:45 UTC
    Required by:
        folly/2022.01.31.00
    Requires:
        libelf/0.8.13
        zlib/1.2.11
libelf/0.8.13
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\libelf\0.8.13\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\libelf\0.8.13\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\libelf\0.8.13\_\_\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\libelf\0.8.13\_\_\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://directory.fsf.org/wiki/Libelf
    License: LGPL-2.0
    Description: ELF object file access library
    Topics: conan, elf, fsf, libelf, object-file
    Provides: libelf
    Recipe: Cache
    Revision: 7c934cfa57f36f306bec85cfd4f19ef6
    Package revision: d3eb14638d4df3bc68470232c34ec8f7
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-12-29 15:42:22 UTC
    Required by:
        libdwarf/20191104
libevent/2.1.12
    ID: 8d05cc4afe9f09aef8bc2db914f3d5f066597fb7
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\libevent\2.1.12\_\_\export
    source_folder: C:\.conan\6e40a080\1
    build_folder: C:\.conan\7d750f5c\1
    package_folder: C:\.conan\d8d81a54\1
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/libevent/libevent
    License: BSD-3-Clause
    Description: libevent - an event notification library
    Topics: conan, libevent, event
    Provides: libevent
    Recipe: Cache
    Revision: 0fbe3dd7e3f0a94ee1ca67fbff84a58c
    Package revision: eb5d74fff0e70ac02cfb255d329cc703
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-09-13 09:23:23 UTC
    Required by:
        folly/2022.01.31.00
    Requires:
        openssl/1.1.1m
libsodium/1.0.18
    ID: 7636e003d0b30e11d0d91a057f66998d4fe1c3d5
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\libsodium\1.0.18\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\libsodium\1.0.18\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\libsodium\1.0.18\_\_\build\7636e003d0b30e11d0d91a057f66998d4fe1c3d5
    package_folder: C:\Users\EPederson\.conan\data\libsodium\1.0.18\_\_\package\7636e003d0b30e11d0d91a057f66998d4fe1c3d5
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://download.libsodium.org/doc/
    License: ISC
    Description: A modern and easy-to-use crypto library.
    Topics: sodium, libsodium, encryption, signature, hashing
    Provides: libsodium
    Recipe: Cache
    Revision: 3368a35ad33989819764a13c486b3573
    Package revision: 938f19d284635078727da13d958ca5c5
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2021-02-19 13:05:29 UTC
    Required by:
        zmq/4.3.2@bincrafters/stable
        folly/2022.01.31.00
llm/3.1.19@llm/prod
    ID: 657057b3e9cdf26f99f866003eb3e4d4cce66c4a
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\llm\3.1.19\llm\prod\export
    source_folder: C:\Users\EPederson\.conan\data\llm\3.1.19\llm\prod\source
    build_folder: C:\Users\EPederson\.conan\data\llm\3.1.19\llm\prod\build\657057b3e9cdf26f99f866003eb3e4d4cce66c4a
    package_folder: C:\Users\EPederson\.conan\data\llm\3.1.19\llm\prod\package\657057b3e9cdf26f99f866003eb3e4d4cce66c4a
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/Tervela/LLM
    License: Commercial; Tervela, Inc
    Author: pfraval@tervela.com
    Description: Low Latency Messaging
    Provides: llm
    Recipe: Cache
    Revision: 2bae4501b8d793e2f93603ec0ff79117f1ba0c0c
    Package revision: 0dd0894151de6fcad23df41ea876725c
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2021-09-18 09:39:47 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
lz4/1.9.3
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\lz4\1.9.3\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\lz4\1.9.3\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\lz4\1.9.3\_\_\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\lz4\1.9.3\_\_\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/lz4/lz4
    Licenses: BSD-2-Clause, BSD-3-Clause
    Description: Extremely Fast Compression algorithm
    Topics: conan, lz4, compression
    Provides: lz4
    Recipe: Cache
    Revision: e8396e6b61f3e272336dec44477da142
    Package revision: 23d9120e589b09e3bafdd2e95e0ec6f4
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2021-01-14 01:13:18 UTC
    Required by:
        folly/2022.01.31.00
openssl/1.1.1m
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\openssl\1.1.1m\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\openssl\1.1.1m\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\openssl\1.1.1m\_\_\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\openssl\1.1.1m\_\_\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/openssl/openssl
    License: OpenSSL
    Description: A toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols
    Topics: conan, openssl, ssl, tls, encryption, security
    Provides: openssl
    Recipe: Cache
    Revision: e7610bf16cd77aae7fe25ac6cce944c4
    Package revision: f7116127de96a7e5b55adeeecbdb413b
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2022-01-13 12:54:13 UTC
    Required by:
        folly/2022.01.31.00
        caf/0.17.6@bincrafters/stable
        conanfile.py (tw-base/1.10.0-dev.62781)
        libcurl/7.71.0
        libevent/2.1.12
protobuf/3.6.1@bincrafters/stable
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\protobuf\3.6.1\bincrafters\stable\export
    source_folder: C:\.conan\ee723c43\1
    build_folder: C:\.conan\ca276044\1
    package_folder: C:\.conan\41eac8d8\1
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/bincrafters/conan-protobuf
    Homepage: https://github.com/protocolbuffers/protobuf
    License: BSD-3-Clause
    Author: Bincrafters <bincrafters@gmail.com>
    Description: Protocol Buffers - Google's data interchange format
    Topics: conan, protobuf, protocol-buffers, protocol-compiler, serialization, rpc, protocol-compiler
    Provides: protobuf
    Recipe: Cache
    Revision: 0
    Package revision: 0
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2019-08-13 12:30:09 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
        protoc_installer/3.6.1@bincrafters/stable
protoc_installer/3.6.1@bincrafters/stable
    ID: 9e449b1ac4341c7bdc87f8a7efe81200c68c405b
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\protoc_installer\3.6.1\bincrafters\stable\export
    source_folder: C:\.conan\dffbc5d4\1
    build_folder: C:\.conan\b08decaa\1
    package_folder: C:\.conan\9ad41eeb\1
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/bincrafters/conan-protobuf
    Homepage: https://github.com/protocolbuffers/protobuf
    License: BSD-3-Clause
    Author: Bincrafters <bincrafters@gmail.com>
    Description: Protocol Buffers - Google's data interchange format
    Topics: conan, protobuf, protocol-buffers, protocol-compiler, serialization, rpc, protocol-compiler
    Provides: protoc_installer
    Recipe: Cache
    Revision: 0
    Package revision: 01eed05f07aa0ff0f865142d4d64a9ca
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2019-08-08 07:30:30 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
    Requires:
        protobuf/3.6.1@bincrafters/stable
snappy/1.1.8
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\snappy\1.1.8\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\snappy\1.1.8\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\snappy\1.1.8\_\_\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\snappy\1.1.8\_\_\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/google/snappy
    License: BSD-3-Clause
    Description: A fast compressor/decompressor
    Topics: conan, snappy, google, compressor, decompressor
    Provides: snappy
    Recipe: Cache
    Revision: 68975c9288f2ac767c4fcb23a1207207
    Package revision: ff6a0ecab81ee5f7f7e10025683f201e
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-07-09 08:21:15 UTC
    Required by:
        folly/2022.01.31.00
spdlog/1.8.0
    ID: 55db45024bed1a2d40f24c02c050b7ca72eeccf4
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\spdlog\1.8.0\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\spdlog\1.8.0\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\spdlog\1.8.0\_\_\build\55db45024bed1a2d40f24c02c050b7ca72eeccf4
    package_folder: C:\Users\EPederson\.conan\data\spdlog\1.8.0\_\_\package\55db45024bed1a2d40f24c02c050b7ca72eeccf4
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/gabime/spdlog
    License: MIT
    Description: Fast C++ logging library
    Topics: conan, spdlog, logging, header-only
    Provides: spdlog
    Recipe: Cache
    Revision: 6f44dcf0c1fdaec5f4b033c5ba872e63
    Package revision: 5d2a79df785a3f62024e9df161bd6cd9
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-10-19 19:02:46 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
    Requires:
        fmt/7.0.3
tbb/2020.1
    ID: 4f1710918aa542fccb5a54d7bd712e4b0750b50d
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\tbb\2020.1\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\tbb\2020.1\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\tbb\2020.1\_\_\build\4f1710918aa542fccb5a54d7bd712e4b0750b50d
    package_folder: C:\Users\EPederson\.conan\data\tbb\2020.1\_\_\package\4f1710918aa542fccb5a54d7bd712e4b0750b50d
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/oneapi-src/oneTBB
    License: Apache-2.0
    Description: Intel Threading Building Blocks (Intel TBB) lets you easily write parallel C++
programs that take full advantage of multicore performance, that are portable and composable, and
that have future-proof scalability
    Topics: conan, tbb, threading, parallelism, tbbmalloc
    Provides: tbb
    Recipe: Cache
    Revision: 0
    Package revision: 0
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-03-26 18:00:19 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
tw-utils/1.2.0-dev.90@tw/dev
    ID: bbed626d4925d898c326b36c373e3fdc5e6face8
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\tw-utils\1.2.0-dev.90\tw\dev\export
    source_folder: C:\Users\EPederson\.conan\data\tw-utils\1.2.0-dev.90\tw\dev\source
    build_folder: C:\Users\EPederson\.conan\data\tw-utils\1.2.0-dev.90\tw\dev\build\bbed626d4925d898c326b36c373e3fdc5e6face8
    package_folder: C:\Users\EPederson\.conan\data\tw-utils\1.2.0-dev.90\tw\dev\package\bbed626d4925d898c326b36c373e3fdc5e6face8
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://gitlab.mycorp.com/core/tw-utils
    License: mycorp
    Description: C++ platform-independent utilities library
    Provides: tw-utils
    Recipe: Cache
    Revision: 811b291270d744b066851176b86415020742d778
    Package revision: ffc6d84be9ede91b859a68f3173b529b
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2022-02-19 19:53:35 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
    Requires:
        catch2/2.11.0
        jsoncpp/1.9.2
        fmt/7.0.3
        zlib/1.2.11
xz_utils/5.2.5
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\xz_utils\5.2.5\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\xz_utils\5.2.5\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\xz_utils\5.2.5\_\_\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\xz_utils\5.2.5\_\_\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://tukaani.org/xz
    License: Public Domain, GNU LGPLv2.1, GNU GPLv2, or GNU GPLv3
    Description: XZ Utils is free general-purpose data compression software with a high compression ratio. XZ Utils were written for POSIX-like systems, but also work on some not-so-POSIX systems. XZ Utils are the successor to LZMA Utils.
    Topics: conan, lzma, xz, compression
    Provides: xz_utils
    Recipe: Cache
    Revision: 108ba9e42edb517d3b8d831a3f00d462
    Package revision: 83f543e8f4574729d8d9fb36811cbb7e
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2021-01-14 01:17:14 UTC
    Required by:
        folly/2022.01.31.00
zlib/1.2.11
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\zlib\1.2.11\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\zlib\1.2.11\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\zlib\1.2.11\_\_\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\zlib\1.2.11\_\_\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://zlib.net
    License: Zlib
    Description: A Massively Spiffy Yet Delicately Unobtrusive Compression Library (Also Free, Not to Mention Unencumbered by Patents)
    Topics: conan, zlib, compression
    Provides: zlib
    Recipe: Cache
    Revision: 1579680eade7cc27626667ca4b143529
    Package revision: 6178a4e11e5a4be8d5c1b68a82c130a4
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-09-04 09:48:36 UTC
    Required by:
        folly/2022.01.31.00
        tw-utils/1.2.0-dev.90@tw/dev
        boost/1.76.0
        libcurl/7.71.0
        libdwarf/20191104
zmq/4.3.2@bincrafters/stable
    ID: 89c72fccbb340a67b234b951f6e7f1deed946833
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\zmq\4.3.2\bincrafters\stable\export
    source_folder: C:\Users\EPederson\.conan\data\zmq\4.3.2\bincrafters\stable\source
    build_folder: C:\Users\EPederson\.conan\data\zmq\4.3.2\bincrafters\stable\build\89c72fccbb340a67b234b951f6e7f1deed946833
    package_folder: C:\Users\EPederson\.conan\data\zmq\4.3.2\bincrafters\stable\package\89c72fccbb340a67b234b951f6e7f1deed946833
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/bincrafters/conan-zmq
    Homepage: https://github.com/zeromq/libzmq
    License: LGPL-3.0
    Description: ZeroMQ is a community of projects focused on decentralized messaging and computing
    Topics: conan, zmq, libzmq, message-queue, asynchronous
    Provides: zmq
    Recipe: Cache
    Revision: 0
    Package revision: 0
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2020-01-25 20:05:35 UTC
    Required by:
        conanfile.py (tw-base/1.10.0-dev.62781)
        cppzmq/4.3.0@bincrafters/stable
    Requires:
        libsodium/1.0.18
zstd/1.4.9
    ID: d057732059ea44a47760900cb5e4855d2bea8714
    BuildID: None
    Context: host
    export_folder: C:\Users\EPederson\.conan\data\zstd\1.4.9\_\_\export
    source_folder: C:\Users\EPederson\.conan\data\zstd\1.4.9\_\_\source
    build_folder: C:\Users\EPederson\.conan\data\zstd\1.4.9\_\_\build\d057732059ea44a47760900cb5e4855d2bea8714
    package_folder: C:\Users\EPederson\.conan\data\zstd\1.4.9\_\_\package\d057732059ea44a47760900cb5e4855d2bea8714
    Remote: conan-local-dev=https://artifactory-new.mycorp.com/artifactory/api/conan/conan-local-dev
    URL: https://github.com/conan-io/conan-center-index
    Homepage: https://github.com/facebook/zstd
    License: BSD-3-Clause
    Description: Zstandard - Fast real-time compression algorithm
    Topics: conan, zstd, compression, algorithm, decoder
    Provides: zstd
    Recipe: Cache
    Revision: 9528d4ee173fd79365bd3aab0541cd16
    Package revision: 936732c00eade5368fa2ac47e3cdf1bc
    Binary: Cache
    Binary remote: conan-local-dev
    Creation date: 2021-08-23 10:47:29 UTC
    Required by:
        folly/2022.01.31.00
conanfile.py (tw-base/1.10.0-dev.62781)
    ID: 03e50b73188e66e66eb58d9d1ca3c9b2b7d770c3
    BuildID: None
    Context: host
    URL: https://gitlab.mycorp.com/core/tw-base
    License: mycorp 
    Description: C++ core & service base library
    Provides: tw-base
    Requires:
        tw-utils/1.2.0-dev.90@tw/dev
        boost/1.76.0
        bzip2/1.0.8
        caf/0.17.6@bincrafters/stable
        cppzmq/4.3.0@bincrafters/stable
        folly/2022.01.31.00
        libcurl/7.71.0
        llm/3.1.19@llm/prod
        openssl/1.1.1m
        protoc_installer/3.6.1@bincrafters/stable
        protobuf/3.6.1@bincrafters/stable
        spdlog/1.8.0
        tbb/2020.1
        zmq/4.3.2@bincrafters/stable
        flatbuffers/2.0.5@third-party/stable
WARN: caf/0.17.6@bincrafters/stable: requirement openssl/1.1.1g overridden by tw-base/1.10.0-dev.62781 to openssl/1.1.1m
WARN: cppzmq/4.3.0@bincrafters/stable: requirement zmq/4.2.5@bincrafters/stable overridden by tw-base/1.10.0-dev.62781 to zmq/4.3.2@bincrafters/stable
WARN: libevent/2.1.12: requirement openssl/1.1.1g overridden by folly/2022.01.31.00 to openssl/1.1.1m
libcurl/7.71.0: WARN: with_openssl, with_winssl, darwin_ssl and with_wolfssl options are deprecated. Use with_ssl option instead.
WARN: libcurl/7.71.0: requirement openssl/1.1.1g overridden by tw-base/1.10.0-dev.62781 to openssl/1.1.1m
</details>

Here is an excerpt of the diff showing missing files (it was 22k lines):
<details>
5c5,8
<  22236523160213118      4 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:22 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_
---
>  22236523160213118      4 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:27 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_
>   1688849860542555      0 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:27 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/build
>   1970324837253212      0 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:27 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/build/e25da6736836401d14d18eb2361204b3783cc5f4
>   1688849860542557      1 -rw-r--r--   1 EPederson 1049089        20 Feb 23 16:27 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/build/e25da6736836401d14d18eb2361204b3783cc5f4/.conan_link
22,19428c25,3200
<   2251799813964334      0 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package
<   1970324837253709      4 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4
<   1970324837253707      4 -rw-r--r--   1 EPederson 1049089      3435 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/conaninfo.txt
<   1970324837253706   1200 -rw-r--r--   1 EPederson 1049089   1227136 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/conanmanifest.txt
<   1970324837253710      0 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:22 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include
<   1970324837253711     96 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost
<   1970324837253712      4 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:22 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators
<   1970324837253713      4 -rw-r--r--   1 EPederson 1049089      1383 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/accumulators.hpp
<   1970324837253714     12 -rw-r--r--   1 EPederson 1049089      8294 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/accumulators_fwd.hpp
<   1970324837253715      4 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:22 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework
<   1970324837253719      4 drwxr-xr-x   1 EPederson 1049089         0 Feb 23 16:22 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/accumulators
<   1970324837253720     12 -rw-r--r--   1 EPederson 1049089     10136 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/accumulators/droppable_accumulator.hpp
<   1970324837253721      4 -rw-r--r--   1 EPederson 1049089      3606 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/accumulators/external_accumulator.hpp
<   1970324837253722      4 -rw-r--r--   1 EPederson 1049089      2537 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/accumulators/reference_accumulator.hpp
<   1970324837253723      4 -rw-r--r--   1 EPederson 1049089      2420 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/accumulators/value_accumulator.hpp
<   1970324837253716      4 -rw-r--r--   1 EPederson 1049089      1462 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/accumulator_base.hpp
<   1970324837253717      4 -rw-r--r--   1 EPederson 1049089       725 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/accumulator_concept.hpp
<   1970324837253718     24 -rw-r--r--   1 EPederson 1049089     23902 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/accumulator_set.hpp
<   1970324837253724     16 -rw-r--r--   1 EPederson 1049089     15173 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/depends_on.hpp
<   1970324837253725      4 -rw-r--r--   1 EPederson 1049089       782 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/external.hpp
<   1970324837253726     12 -rw-r--r--   1 EPederson 1049089     11297 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/extractor.hpp
<   1970324837253727      4 -rw-r--r--   1 EPederson 1049089       923 Feb 23 16:23 /c/Users/EPederson/.conan/data/boost/1.76.0/_/_/package/e25da6736836401d14d18eb2361204b3783cc5f4/include/boost/accumulators/framework/features.hpp
</details>


user: sourcedelica
issue_10622: state: open
title: [bug] Multiline environment variables with `=` are not parsed properly on Windows
body: ### Short summary

Multiline environment variables that contain a `=` are not properly parsed on Windows in [client/tools/win.py](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/tools/win.py#L509). This leads to `ValueError: illegal environment variable name` when [launching](https://github.com/python/cpython/blob/c0da582b227f311126e278b5553a7fa89c79b054/Modules/_winapi.c#L761) Python on Windows with the variables that Conan prepared.


### Environment Details

  * Operating System+version: Windows 10
  * Compiler+version: Does not matter
  * Conan version: 1.28.1 and 1.45
  * Python version: 3.7.7


### Steps to reproduce

1. Inject a multiline variable on Windows with a line that starts with a `=`. Example:
```
Lorem ipsum dolor sit amet
= consectetur adipiscing elit
```
2. Run `conan export-pkg`
3. Observe Python invocation error
```
ERROR: my_package/1.2.3 (test package): Error in test() method, line 24
	cmake.configure(source_folder=str(test_source_folder))
	ValueError: illegal environment variable name
```

### Analysis

When we saw this issue, we thought that it is something in our scripts, but tracing the steps performed by Conan allowed me to find the root cause. Here is a full "traceback" of what happens:)

We use Conan in our GitLab CI, which injects `CI_COMMIT_DESCRIPTION` and `CI_COMMIT_MESSAGE` variables with the commit message in them. The bug happens when the commit message contains any line that _starts_ with a `=` symbol. In our case, both `CI_COMMIT_DESCRIPTION` and `CI_COMMIT_MESSAGE` looked somewhat like this:
```
Fixed bug 123 by implementing intelligent fallback value detection

[Some description]...

== Overview of main changes ==

    = Core changes =

...
```
So when we run `conan export-pkg` a series of things happens:
* We call `cmake.configure()` in `test()` method of our `test_package/conanfile.py` and [invoke default implementation](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/build/cmake.py#L264) of it, as we don't have our own.
* The function prepares the command and [calls](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/build/cmake.py#L302) `self._run()`
* A Windows-specific subsection of the function prepares some environment variables before [executing](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/build/cmake.py#L261) the original command
* `vcvars_dict` [prepares](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/tools/win.py#L497) a `vcvars_command` to run to get the variables
* `vcvars_command` returns a [dummy](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/tools/win.py#L449) command for our case which we can see in our the logs:
```
INFO  :cmake_flags.py [266]: Setting Cross build flags:  [2022-02-16 16:05:21,720]
INFO  :runners.py     [85]: Calling command: echo Conan:vcvars already set && set > "C:\Users\builder\AppData\Local\Temp\tmp8ky5bhqs" [2022-02-16 16:05:21,724]
Conan:vcvars already set 
INFO  :runners.py     [88]: Return code: 0 [2022-02-16 16:05:21,757]
```
* Now Conan effectively [runs](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/tools/win.py#L501) `echo Conan:vcvars already set && set` in the shell (probably not powershell as `set` command behaves a bit differently there).
* After this, we try to [parse](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/tools/win.py#L503) the output and split it into key=value pairs

This is where the issue happens. After running `set` we end up with something like this:
```
...
COMMONPROGRAMFILES=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
COMSPEC=C:\WINDOWS\system32\cmd.exe
FAILURE_VAR=Line 1 beginning of failure_var
= BOOM
Line 2 - end of failure_var
HOME=/c/Users/dmytro.kovalchuk
HOMEDRIVE=C:
HOMEPATH=\Users\dmytro.kovalchuk
...
```

Notice the lack of escaping for a multiline variable `FAILURE_VAR`. Every line of the `FAILURE_VAR` stuff [will be parsed](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/tools/win.py#L509) as a `key=value` pair leading to such pairs:

- "Name": "FAILURE_VAR", "Value": "Line 1 beginning of failure_var"
- "Name": "", "Value": " BOOM"
- "Name": None, "Value": "Line 2 - end of failure_var"

A variable with `None` name [will not be added due to an exception](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/tools/win.py#L530). However, there is no sanity check for a variable name before [adding it to the environment](https://github.com/conan-io/conan/blob/3e5fee62c595124d1b551e3dc5af0a81a1c5b9ad/conans/client/tools/win.py#L528). This is the root cause for our issue - we add an environment variable with _empty_ name and value ` BOOM` which makes Python [throw an error](https://github.com/python/cpython/blob/c0da582b227f311126e278b5553a7fa89c79b054/Modules/_winapi.c#L761).

Notice that if we had another line in our `FAILURE_VAR` like `blah = bwaa` Conan would create and inject a rubbish variable with the name `blah` and value `bwaa`. This adds a potential for more mysterious errors on Windows.

### Workaround
Unset multiline variables before running `conan export-pkg`.

### Possible fixes
1. Check that variable name is not empty in [client/tools/win.py](https://github.com/conan-io/conan/blob/17c58f0c61931f9de218ac571cd97a8e0befa68e/conans/client/tools/win.py#L532)
2. Fix the whole parsing by using Python and JSON(for example). This will prevent Conan from generating rubbish variables. Here is what I mean: instead of [printing all variables with the `set` command,](https://github.com/conan-io/conan/blob/17c58f0c61931f9de218ac571cd97a8e0befa68e/conans/client/tools/win.py#L504) we could use a simple Python script to do the same but with proper escaping and parsing:
```
import os
import json

print(json.dumps(dict(os.environ)))
```


I can deliver the fix number 1 (just give me a heads-up in the comments) but I think it is just a hot-fix rather than a proper solution:)

user: FnDmytroKovalchuk
issue_10617: state: open
title: [bug] interactions between compatible_packages and build/host context
body: When a package using [compatible_packages](https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html#compatible-packages) is present in both the build and host context, the resolved compatible_package from one context appears to interact with the default_options of the other profile and cause errors:

Obviously lots of details were filed off the below in my attempts to provide a minimal test-case, but the "real" scenario is once again winelib/winegcc - I'm trying to use compatible_packages to model the fact that an utility which is being dircted to --settings tool:arch=x86 (it needs to see the 32-bit view of the registry) can satisfy it's request for wine by substituting in an arch=x86_64 build of wine that has [WoW64](https://docs.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications) enabled and is therefore capable of launching this x86 tool.

But it appears that the issue only needs the package to be both contexts; the complication of it being direct in [requires] and transitive in tool_requires, or involving cross-compiling, do not seem to be necessary to provoke the same error.

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 22.04
  * Conan version: 1.45.0
  * Python version: 3.8.7

### Steps to reproduce (Include if Applicable)

#### conanfile-compatible_lib.py
```py
from conan import ConanFile
from conan.errors import ConanInvalidConfiguration

class CompatibleLibConanFile(ConanFile):
    name = "compatible_lib"
    version = "1.0"

    options = {
        "valid": [None, True],
        "variant": ["A","B"],
    }

    def validate(self):
        if self.options.valid.value is None:
            raise ConanInvalidConfiguration("omitting options.valid means to follow compatible_packages")
    
    def package_id(self):
        if self.options.valid.value is None:
            compatible = self.info.clone()
            compatible.options.valid = True
            self.compatible_packages.append(compatible)
```

####  conanfile-consumer.py
```py
from conan import ConanFile

class ConsumerConanFile(ConanFile):
    requires = "compatible_lib/1.0"
    tool_requires = "compatible_lib/1.0"
```

```sh
conan export-pkg ./conanfile-compatible_lib.py -o valid=True -o variant=A
conan export-pkg ./conanfile-compatible_lib.py -o valid=True -o variant=B
conan info conanfile-consumer.py -o compatible_lib:variant=A
```

> compatible_lib/1.0: Main binary package 'INVALID' missing. Using compatible package '66e60fcd0f9490a92b88eedd31d6ad3252856a20'
> ERROR: compatible_lib/1.0:  tried to change compatible_lib/1.0 option valid to None but it was already defined as True

As a second (maybe related) bug, if I try to specificy separate host and build contexts, it does something different but also seemingly wrong. Using the command

```sh
conan install conanfile-consumer.py --options:host compatible_lib:variant=A --options:build compatible_lib:variant=B
```

succeeds (does not give the "tried to change compatible_lib/1.0 option valid to None but it was already defined as True" error, and the output shows profile_host and profile_build with differnet values for `[options]compatible_lib:variant`:

> Configuration (profile_host):
> [settings]
> [options]
> compatible_lib:variant=A
> [build_requires]
> [env]
> [conf]
> tools.cmake.cmaketoolchain:generator=Ninja
> Configuration (profile_build):
> [settings]
> [options]
> compatible_lib:variant=B
> [build_requires]
> [env]
> [conf]
> tools.cmake.cmaketoolchain:generator=Ninja
> compatible_lib/1.0: Main binary package 'INVALID' missing. Using compatible package '46eaae3fef21ab6f5db7d2d17fb23ee58fa932c0'
> conanfile-consumer.py: Installing package
> Requirements
>     compatible_lib/1.0 from local cache - Cache
> Packages
>     compatible_lib/1.0:46eaae3fef21ab6f5db7d2d17fb23ee58fa932c0 - Cache
> Build requirements
>     compatible_lib/1.0 from local cache - Cache
> Build requirements packages
>     compatible_lib/1.0:46eaae3fef21ab6f5db7d2d17fb23ee58fa932c0 - Cache
> 
> Installing (downloading, building) binaries...
> compatible_lib/1.0: Already installed!
> conanfile-consumer.py: Applying build-requirement: compatible_lib/1.0
> conanfile-consumer.py: Generator txt created conanbuildinfo.txt
> conanfile-consumer.py: Aggregating env generators
> conanfile-consumer.py: Generated conaninfo.txt
> conanfile-consumer.py: Generated graphinfo
> 
</details>
but the resultins show shows that this was not honored and both contexts picked the same package_id (which has variant=A, so the profile_host won)

<details><summary>conan.lock</summary>

```json
{
 "graph_lock": {
  "nodes": {
   "0": {
    "options": "compatible_lib:valid=None\ncompatible_lib:variant=A",
    "requires": [
     "1"
    ],
    "build_requires": [
     "2"
    ],
    "path": "conanfile-consumer.py",
    "context": "host"
   },
   "1": {
    "ref": "compatible_lib/1.0#2626a91060b7eabb17d14099ba9aaa71",
    "options": "valid=True\nvariant=A",
    "package_id": "46eaae3fef21ab6f5db7d2d17fb23ee58fa932c0",
    "prev": "47e7576f74c2c47250524a7d54aae7fb",
    "context": "host"
   },
   "2": {
    "ref": "compatible_lib/1.0#2626a91060b7eabb17d14099ba9aaa71",
    "options": "valid=None\nvariant=A",
    "package_id": "46eaae3fef21ab6f5db7d2d17fb23ee58fa932c0",
    "prev": "47e7576f74c2c47250524a7d54aae7fb",
    "context": "build"
   }
  },
  "revisions_enabled": true
 },
 "version": "0.4",
 "profile_host": "[settings]\nbuild_type=RelWithDebInfo\n[options]\ncompatible_lib:variant=A\n[build_requires]\n[env]\n[conf]\ntools.cmake.cmaketoolchain:generator=Ninja",
 "profile_build": "[settings]\nbuild_type=RelWithDebInfo\n[options]\ncompatible_lib:variant=B\n[build_requires]\n[env]\n[conf]\ntools.cmake.cmaketoolchain:generator=Ninja"
}
```
</details>

I don't know not if these two things share the same root cause, but they both seem to show options leaking between the host and build profiles in ways I did not expect. compatible_packages does not seem to be necessary to hit the second bug; I get the collapse into `variant=A` even if I add `--options:host compatible_lib:valid=True --options:build compatible_lib:valid=True` so that the "Main binary package" is found.
user: puetzk
issue_10615: state: open
title: [bug] Conan upload is broken
body: Conan skips the recipe upload when the config is in `semver_direct_mode` + a package was already uploaded with recipe revision mode enabled.

This is very hidden, so you only get the error later when trying to consume the package.
You get an error like this:
`ERROR: Missing binary: dbus/1.12.20:fb2ae32c85d50c7776ed05b57cc10f2bc374880b`

The problematic recipe is the `dbus` in my case: See how the `export` folder for revision `0` is missing.
Although the package is there, however, the recipe is missing.
![image](https://user-images.githubusercontent.com/42534866/154696437-75f6b582-e189-43da-8413-a40e205cd9d5.png)

I upload my package like the conan docu suggest:
```
conan upload dbus/1.12.20@:fb2ae32c85d50c7776ed05b57cc10f2bc374880b -r my-remote --confirm
```
This should upload the binary+recipe. https://docs.conan.io/en/latest/reference/commands/creator/upload.html 

However: It will only upload the package and not the recipe anymore.

Background:

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 18.04 bionic
  * Compiler+version: gcc9
  * Conan version: 1.45.0
  * Python version: 3.6.9

### Steps to reproduce (Include if Applicable)
Upload a conan package with following settings:
```
default_package_id_mode=recipe_revision_mode
revisions_enabled=True
full_transitive_package_id=1
```

Afterwards, create from the same recipe, with no changes another package, but wit following conan conf settings:
```
default_package_id_mode = semver_direct_mode
```

Upload it with the package id, like:
```
conan upload dbus/1.12.20@:fb2ae32c85d50c7776ed05b57cc10f2bc374880b -r my-remote --confirm
```

Also an upload of just the recipe will be skipped.
```
$conan upload dbus/1.12.20@:fb2ae32c85d50c7776ed05b57cc10f2bc374880b -r my-remote --confirm
Uploading to remote 'my-remote':
Uploading dbus/1.12.20 to remote 'my-remote'
Compressing recipe...
Recipe is up to date, upload skipped
Uploading package 1/1: fb2ae32c85d50c7776ed05b57cc10f2bc374880b to 'my-remote'
Compressing package...
Uploading conan_package.tgz -> dbus/1.12.20:fb2a
Uploading conaninfo.txt -> dbus/1.12.20:fb2a
Uploading conanmanifest.txt -> dbus/1.12.20:fb2a

$conan upload dbus/1.12.20@ -r my-remote --confirm
Uploading to remote 'my-remote':
Uploading dbus/1.12.20 to remote 'my-remote'
Recipe is up to date, upload skipped
```

Do it better in from within own docker images, like I did.
user: derived-coder
issue_10614: state: open
title: [bug] default_options hide 'already assigned' error
body: Have two (mutually independent) packages depend on a third one but set an option in different ways. A fourth package depends on both of them to form a "diamond" shape. It is not possible to build the package satisfying both options at once and *sometimes* an error is shown. Conan should always show an error though.

More precisely, the "sometimes" depends on `default_options` being declared in the critical package or not.

### Environment Details

  * Operating System+version: Tested with Linux but probably not relevant
  * Conan version: 1.44.1. 1.45.0
  * Python version: 3.8.5

### Steps to reproduce


1. Check out this repo: https://github.com/a-zw/conan-test
2. Run the test.sh script. No error is shown.
3. Now remove [the default_options in lower/conanfile.py](https://github.com/a-zw/conan-test/blob/main/lower/conanfile.py#L15).
4. Run the test.sh script again. See the error:

        ERROR: lower/1.0.0: mid_right/1.0.0 tried to change lower/1.0.0 option my_option to b
        but it was already assigned to a by mid_left/1.0.0

The behavior should be consistent in step 2 and 4 though.
user: a-zw
issue_10611: state: open
title: [bug] Conan broken for <1.44 due to breaking change in Markupsafe (2.1) affecting Jinja2 (2.11)
body: Main issue in Jinja tracker: https://github.com/pallets/jinja/issues/1587
user: memsharded
issue_10609: state: open
title: [feature] Passing options to compatible_packages that do not affect package_id
body: 

### Environment Details (include every applicable attribute)
  * Operating System+version: ubuntu 20.04
  * Compiler+version:
  * Conan version: 1.45
  * Python version: 3.8.7

### Steps to reproduce (Include if Applicable)

When a package is selected via compatible_packages, the recipe computes package_info according to the settings/options of the chosen alternative, not the original search (this seems reasonable to me). This appears to happen because the package settings/options are overwritten right after selecting a compatible_package:

https://github.com/conan-io/conan/blob/a0f7e9c1c4d87908bce76eaa0f44c2bfaf936766/conans/client/graph/graph_binaries.py#L223-L225

(and also when loading from a lockfile)

https://github.com/conan-io/conan/blob/a0f7e9c1c4d87908bce76eaa0f44c2bfaf936766/conans/client/graph/graph_binaries.py#L190-L191

However, compatible_packages.options is a clone of info.options; it will contain only settings/options which contribute to verbatim the package_id. If one is doing anything like the descriptions in [Defining a Custom package_id](https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html?highlight=package_id#defining-a-custom-package-id), these settings/options values in the to-be-hashed compatible_packages may not be in the same form as the input expected for package_info.

Shouldn't this overwriting be done with the full_options/full_settings, not just the parts/format that contribute to the package_id?

user: puetzk
issue_10607: state: open
title: [feature] Linter for recipes "Conan 2 like"
body: - to be used in conan-center-index
- imports from "conan"
- "self.copy" => "copy(self)"
- ...

@conan-io/barbarians @uilianries @SSE4 
user: lasote
issue_10605: state: open
title: [feature] Ask before system package installation
body: I think it is more user friendly when the user gets asked whether a conan recipe should install some system packages or not.
So the config here: `tools.system.package_manager:mode` https://docs.conan.io/en/latest/reference/conanfile/tools/system/package_manager.html#conan-tools-system-package-manager-config
should be extended with the option: `"ask"`
In this mode, the user gets asked whether conan should install system packages, which he can interactively accept or decline.
Setting some global config somewhere is too complicated and might also sometime not the right value depending on the packages which are getting installed. The new mode should be also the default.

What do you think?


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: derived-coder
issue_10604: state: open
title: Make ``self.export_folder`` available to export hooks
body: Now it is only local to the ``export()`` method.


Hi @memsharded,

This looks to be a very useful function and one we were literally about to look at implementing ourselves. However can I ask you to consider an additional usage scenario: 

We would like to capture to some data in the `conandata.yml` for all our package recipes (literally 100s) when running in CI, and so were planning on using a `post_export` hook. I've checked and the passed `conanfile` arg doesn't have the `export_folder` attribute available for this hook type, hence this new function wouldn't be usable in this scenario. 

Does it sound reasonable to add support for this use case?

_Originally posted by @santhonisz in https://github.com/conan-io/conan/issues/10586#issuecomment-1040864807_
user: memsharded
issue_10588: state: open
title: [question] How to pass Compiler and Linker flags to Conan CMake Generator
body: I'm trying to cross build on windows for an embedded target (arm-none-eabi).
To achieve this, I'm using a cross compiling profile.
Each embedded target has it's own specific compiler and linker flags

My cross compiling profile looks like this
```

target_host=arm-none-eabi
standalone_toolchain=C:/.../toolchains/Windows/gcc-10.2.1/
cc_compiler=gcc
cxx_compiler=g++

[settings]
os=Arduino
os.board=ANY
arch=armv7
compiler=gcc
compiler.version=10
compiler.libcxx=libstdc++11
build_type=Debug

[env]
CONAN_CMAKE_FIND_ROOT_PATH=$standalone_toolchain/$target_host
PATH=[$standalone_toolchain/bin]
CHOST=$target_host
AR=$target_host-ar
AS=$target_host-as
RANLIB=$target_host-ranlib
LD=$target_host-ld
STRIP=$target_host-strip
CC=$target_host-$cc_compiler
CXX=$target_host-$cxx_compiler
CFLAGS="-I $standalone_toolchain/$target_host/include -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 --specs=nosys.specs -v"
CXXFLAGS="-I $standalone_toolchain/$target_host/include -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 --specs=nosys.specs -v"
LDFLAGS="-mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -v"

```

the workflow is the recommended workflow from https://github.com/conan-io/cmake-conan.
it's basically a 
```
conan_cmake_configure() +
conan_cmake_install(PROFILE MY_PROFILE)
```

The workflow is not the issue, I can see that the embedded compiler (in my case gcc 10) is properly recognised. Include paths etc. are set properly. However I'm suspecting that my provided compiler and/or linker flags are ommitted. I would have expected a little more output from the conan build especially after adding a -v to the compiler and linker flags

```

[CMake] tinyxml/2.6.2: Configuring sources in C:\Users\xxx\.conan\data\tinyxml\2.6.2\_\_\source
1> [CMake] 
1> [CMake] tinyxml/2.6.2: Copying sources to build folder
1> [CMake] tinyxml/2.6.2: Building your package in C:\Users\xxx\.conan\data\tinyxml\2.6.2\_\_\build\11b38960141478715841df824e568735e33d702c
1> [CMake] tinyxml/2.6.2: Generator cmake created conanbuildinfo.cmake
1> [CMake] tinyxml/2.6.2: Aggregating env generators
1> [CMake] tinyxml/2.6.2: Calling build()
1> [CMake] -- The C compiler identification is GNU 10.2.1
1> [CMake] -- The CXX compiler identification is GNU 10.2.1
1> [CMake] -- Detecting C compiler ABI info
1> [CMake] -- Detecting C compiler ABI info - done
1> [CMake] -- Check for working C compiler: C:/xxx/toolchains/Windows/gcc-10.2.1/bin/arm-none-eabi-gcc.exe - skipped
1> [CMake] -- Detecting C compile features
1> [CMake] -- Detecting C compile features - done
1> [CMake] -- Detecting CXX compiler ABI info
1> [CMake] -- Detecting CXX compiler ABI info - done
1> [CMake] -- Check for working CXX compiler: C:/xxx/toolchains/Windows/gcc-10.2.1/bin/arm-none-eabi-g++.exe - skipped
1> [CMake] -- Detecting CXX compile features
1> [CMake] -- Detecting CXX compile features - done
1> [CMake] -- Conan: called by CMake conan helper
1> [CMake] -- Conan: called inside local cache
1> [CMake] -- Conan: Adjusting output directories
1> [CMake] -- Conan: Using cmake global configuration
1> [CMake] -- Conan: Adjusting default RPATHs Conan policies
1> [CMake] -- Conan: Adjusting language standard
1> [CMake] -- Conan: Adjusting fPIC flag (OFF)
1> [CMake] -- Conan: Compiler GCC>=5, checking major version 10
1> [CMake] -- Conan: Checking correct version: 10
1> [CMake] -- Conan: C++ stdlib: libstdc++11
1> [CMake] -- Configuring done
1> [CMake] -- Generating done
1> [CMake] CMake Warning:
1> [CMake]   Manually-specified variables were not used by the project:
1> [CMake] 
1> [CMake]     CMAKE_EXPORT_NO_PACKAGE_REGISTRY
1> [CMake]     CMAKE_INSTALL_BINDIR
1> [CMake]     CMAKE_INSTALL_DATAROOTDIR
1> [CMake]     CMAKE_INSTALL_INCLUDEDIR
1> [CMake]     CMAKE_INSTALL_LIBDIR
1> [CMake]     CMAKE_INSTALL_LIBEXECDIR
1> [CMake]     CMAKE_INSTALL_OLDINCLUDEDIR
1> [CMake]     CMAKE_INSTALL_SBINDIR
1> [CMake] 
1> [CMake] 
1> [CMake] -- Build files have been written to: C:/Users/xxx/.conan/data/tinyxml/2.6.2/_/_/build/11b38960141478715841df824e568735e33d702c/build_subfolder
1> [CMake] [1/5] Building CXX object CMakeFiles/tinyxml.dir/source_subfolder/tinystr.cpp.obj
1> [CMake] [2/5] Building CXX object CMakeFiles/tinyxml.dir/source_subfolder/tinyxmlerror.cpp.obj
1> [CMake] [3/5] Building CXX object CMakeFiles/tinyxml.dir/source_subfolder/tinyxmlparser.cpp.obj
1> [CMake] [4/5] Building CXX object CMakeFiles/tinyxml.dir/source_subfolder/tinyxml.cpp.obj
1> [CMake] [5/5] Linking CXX static library lib\libtinyxml.a
1> [CMake] tinyxml/2.6.2: Package '11b38960141478715841df824e568735e33d702c' built
1> [CMake] tinyxml/2.6.2: Build folder C:\Users\xxx\.conan\data\tinyxml\2.6.2\_\_\build\11b38960141478715841df824e568735e33d702c
1> [CMake] tinyxml/2.6.2: Generated conaninfo.txt
1> [CMake] tinyxml/2.6.2: Generated conanbuildinfo.txt
1> [CMake] tinyxml/2.6.2: Generating the package
1> [CMake] tinyxml/2.6.2: Package folder C:\Users\xxx\.conan\data\tinyxml\2.6.2\_\_\package\11b38960141478715841df824e568735e33d702c
1> [CMake] tinyxml/2.6.2: Calling package()
1> [CMake] [0/1] Install the project...
1> [CMake] -- Install configuration: "Debug"
1> [CMake] -- Installing: C:/Users/xxx/.conan/data/tinyxml/2.6.2/_/_/package/11b38960141478715841df824e568735e33d702c/lib/libtinyxml.a
1> [CMake] -- Installing: C:/Users/xxx/.conan/data/tinyxml/2.6.2/_/_/package/11b38960141478715841df824e568735e33d702c/include/tinystr.h
1> [CMake] -- Installing: C:/Users/xxx/.conan/data/tinyxml/2.6.2/_/_/package/11b38960141478715841df824e568735e33d702c/include/tinyxml.h
1> [CMake] tinyxml/2.6.2 package(): Packaged 2 '.h' files: tinystr.h, tinyxml.h
1> [CMake] tinyxml/2.6.2 package(): Packaged 1 '.a' file: libtinyxml.a
1> [CMake] tinyxml/2.6.2 package(): Packaged 1 file: LICENSE
1> [CMake] tinyxml/2.6.2: Package '11b38960141478715841df824e568735e33d702c' created
1> [CMake] tinyxml/2.6.2: Created package revision cd6b06191d5c48b88402bf81c1a3e015
1> [CMake] conanfile.txt: Generator cmake_find_package created Findspdlog.cmake
1> [CMake] conanfile.txt: Generator cmake_find_package created FindTinyXML.cmake
1> [CMake] conanfile.txt: Generator cmake_find_package created Findmagic_enum.cmake
1> [CMake] conanfile.txt: Generator cmake_find_package created Findetl.cmake
1> [CMake] conanfile.txt: Generator cmake_find_package created Findfmt.cmake
1> [CMake] conanfile.txt: Generator qmake created conanbuildinfo.pri
1> [CMake] conanfile.txt: Generator txt created conanbuildinfo.txt
1> [CMake] conanfile.txt: Aggregating env generators
1> [CMake] conanfile.txt: Generated conaninfo.txt
1> [CMake] conanfile.txt: Generated graphinfo
```

Now compiling my project works fine however the linking fails
`error : bin\foo.elf uses VFP register arguments, C:/Users/xxx/.conan/data/tinyxml/2.6.2/_/_/package/11b38960141478715841df824e568735e33d702c/lib/libtinyxml.a(tinyxml.cpp.obj) does not`

=>In my case, I'd like to use the Hardware FPU of my embedded controller. However it looks like conan ignores my Compiler and/or linker flags. 

=>how can i pass specify compiler or linker flags to conan?


Thx for your help :)


- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Ju1He1
issue_10559: state: open
title: [bug] layout: self.folders.generators not working like --install-folder
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: macOS, Windows
  * Compiler+version: Any
  * Conan version: 1.45/1.42
  * Python version: 3.9.10/3.6.6

### Steps to reproduce (Include if Applicable)
Conanfile:
```
from conans import ConanFile

class file (ConanFile):
    
    name = "Testlib"
    version = "1.2.3"

    generators = "cmake_paths"

    default_channel = "testing"
    default_user = "local"

    def layout(self):
        self.folders.generators = "conan"
```

`conan install . `

Current result in file system:
```
conan.lock
conan_paths.cmake
conanbuildinfo.txt
conanfile.py
conaninfo.txt
graph_info.json
```

Expected result in file system:
```
conan
+- conan.lock
+- conan_paths.cmake
+- conanbuildinfo.txt
+- conaninfo.txt
+- graph_info.json
conanfile.py
```

So layout self.folders.generators cannot replace  `conan install . -if conan`.

According to https://docs.conan.io/en/latest/developing_packages/package_layout.html#example-everything-together

user: heili77
issue_10555: state: open
title: [question] Export a package from local cache to directory/zip
body: <!-- What is your question? Please be as specific as possible! -->
Given an existing package in local cache, how to export this specific package to directory?

As suggested in <https://media.jfrog.com/wp-content/uploads/2021/05/25084434/conan-cheatsheet.pdf>, I can use `conan install zlib/1.2.11@ -g deploy` to deploy zlib to current directory. But... how to skip dependency libs and `deploy_manifest.txt`? I only need this one package.

A walk-around is:

```
cp -rf $(conan info zlib/1.2.11@ -j --paths | python3 -c 'import json, sys; print(json.load(sys.stdin)[-1]["package_folder"])') output_dir
```

But this is not clean.

Any suggestions?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: district10
issue_10553: state: open
title: [feature] access to build_requires tools in tools.cmake.cmaketoolchain:user_toolchain
body: I would like to create a profile which directs an unmodified recipe (that uses CMakeToolchain) to use compilers which are themselves delivered as build-context conan package(s). I can accomplish the first part of this by having that recipe contain an appropriate toolchain file and set it as `self.conf_info["tools.cmake.cmaketoolchain:user_toolchain"] = os.path.join(self.package_folder,"fancytoolchain.cmake")`. And a profile can have `[build_requires]`, so I can get part of the second (pull in a package providing tools). But right now the user_toolchain block comes before the find_paths block, so it is not possible for this toolchain file to use find_program to locate executables from these other build_requires; while the cppinfo.bindirs from build_requires will eventually be added to CMAKE_PROGRAM_PATH, it hasn't happened yet.

When actually running from within a conan build() method, this is somewhat ameliorated by bindirs also being added to the PATH environment, but that doesn't help if you are using conan_toolchain.cmake on its own.

It's also possible to provide your own additional block, but it's not documented how to control the order. Peeking under the covers at the implementation, it appears to be a python OrderedDict, which would offer [move_to_end(...)](https://docs.python.org/3/library/collections.html#collections.OrderedDict.move_to_end), but that still does not support insertion in a specific place, and in any case is relying on an undocumented implementation detail. And adding a block won't work with a profile and an ordinary recipe; it means every downstream recipe you want to build in the profile needs to be modified to have a python_requires (to obtain the block) and also switch from `generators = "CMakeToolchain"` to a `generate()` method that modifies toolchain.blocks[]. Which is a lot more invasive than a profile that causes things to build with the compiler corresponding to those settings (e.g. it would no longer work to --build conan-center recipes for this profile, one would have to patch/vendor them).

One easy addition would be to also have `tools.cmake.cmaketoolchain:user_toolchain_late` (that gets included after the default blocks and can thus refer to other conan packages).

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: puetzk
issue_10541: state: open
title: [bug] conans.tools.Git.get_branch returns garbage when in detached HEAD state
body: `conans.tools.Git.get_branch()` returns the branch name `"HEAD (no branch)"` when in detached HEAD state instead of failing.

`get_branch()` runs [`git status -bs --porcelain`](https://github.com/conan-io/conan/blob/f930e501c6c04478dd89ce562e4588010695d4d0/conans/client/tools/scm.py#L305) to get the branch name, which does not returns useful output when in detached HEAD.
A more appropriate command would be something like `git symbolic-ref --quiet --short HEAD`, which exits with a non-zero return code when in detached HEAD. Downside: `symbolic-ref` requires a more modern Git version (how modern?).

### Environment Details
  * Operating System+version: Debian 11
  * Conan version: 1.45.0
  * Python version: 3.9.2
  * Git: 2.30.2

### Steps to reproduce
```sh
git init my-package && cd my-package
cat <<EOT >conanfile.py
from conans import ConanFile, tools
git = tools.Git()
print(f'branch: {git.get_branch()}')
class MyPackage(ConanFile):
    name = 'my-package'
    version = '0.1.0'
EOT
mkdir build && cd build
git commit --allow-empty -m 'initial commit'
git commit --allow-empty -m 'dummy'
conan install .. | grep 'branch:' # shows "branch: main"
git checkout HEAD~1
conan install .. | grep 'branch:' # shows "branch: HEAD (no branch)"
```
user: maxtruxa
issue_10540: state: open
title: [question] Best way to extend Conan's architecture support?
body: <!-- What is your question? Please be as specific as possible! -->

What is the best way to extend Conan's architecture support for having more granular architecture settings which are converted to architecture compiler flags?
This is best illustrated by an example for adding various settings relevant for an Arm microcontroller.

Here are the relevant settings added to the `settings.yml`.

```yaml
arch:
  ...
  thumbv7em:
    float-abi: ["soft", "softfp", "hard"]
    fpu: 
      vfpv4:
      fpv5:
        precision: ["single", "double"]
    processor: [None, "cortex-m4", "cortex-m7"]
```

These settings must be converted to specific compiler flags in GCC.
Take this example profile, for instance.

```ini
[settings]
os=baremetal
arch=thumbv7em
arch.float-abi=hard
arch.fpu=vfpv4
arch.processor=cortex-m4
compiler=gcc
compiler.version=9
compiler.libcxx=libstdc++11
compiler.cppstd=17
compiler.exception=None

[conf]
tools.cmake.cmaketoolchain:system_name=Generic
```

This would be converted into the following architecture flags for GCC.

```sh
-mthumb -mfloat-abi=hard -march=armv7e-m+fp -mtune=cortex-m4
```

For a CMake project, the best point of extensibility appears to be the `CMakeToolchain` generator which has a specific block for configuring the compiler architecture blocks.
At first blush, `python_requires` appears to be the best method for extending this via the `CMakeToolchain` generator, however, this requires all dependent packages to be updated when the requirement is updated which is not as convenient as the behavior of `tool_requires` providing a `user_toolchain` which can be transitively overridden across all dependencies using that same `tool_requires`.
This also requires much less boilerplate in the Conan file itself to incorporate a `python_requires` module and its easy to incorporate a  `test_package` for this as well.

To make it possible to easily support various combinations of these architecture settings, it makes sense to generate the CMake toolchain provided by the package instead of providing a pre-configured file.

The `tool_requires` method, however, only works for static CMake files and not those generated by particular settings since `tool_requires` is evaluated in the build context and not the host context.
This requires using `requires` or `test_requires` instead and manually applying the `user_toolchain` in the generate method.
`test_requires` is not applied across dependencies in the same way that `python_requires` can not be overridden in dependencies, which makes regular `requires` the best choice.
The package id is unaffected by `tool_requires`, which doesn't adequately express the effect on the package as `python_requires` or `requires` do, though there are ways of working around this.
Additionally, using the `user_toolchain` method with a fully generated CMake toolchain can lead to the consumer's toolchain generated by Conan duplicating compiler flags and potentially overriding certain options.
Finally, these methods are all limited to one particular build system, CMake, even though these architecture flags are general enough to apply to other build systems.

With all these considerations in mind, what is the best method for extending Conan's architecture support for these highly extensible architectures like Arm and RISC-V?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: jwillikers
issue_10513: state: open
title: Avoid setting CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH in CMakeToolchain
body: See also the thread started by by @SpaceIm in https://github.com/conan-io/conan/pull/10186#discussion_r782208413_
I didn't see this until looking at the 1.45 changelog, and I figure the review of a month-old merged PR is not best place to raise additional concerns.

setting CMAKE_FIND_ROOT_PATH_MODE_* to BOTH gives me a lot of heartburn. I get the argument that BOTH will still check the places that ONLY would have cheked first, so if ONLY would have succeeded, BOTH gives the same answer. But CMakeToolchain goes with CmakeDeps, which writes package-config.cmake files. So if I'm using find_library (or a FindLibFoo.cmake MODULE mode find_package), it's probably for something that does *not* come from a conan package. And I've been bitten quite a few times when a library was missing in the embedded sysroot, usually some transitive thing I didn't know I should think about, and `BOTH` resulted in CMake just finding something from the build environment. And in fact that may very well even link without error: if the host sysroot is x86-linux and the build environment is an ubuntu with 32-bit multiarch packages installed, gcc isn't necessarily going to see anything wrong. Wrong versions, wrong toolchains, mismatched glibc, etc are still quite like;,, but you might still produce a binary full of [nasal demons](http://www.catb.org/jargon/html/N/nasal-demons.html) without so much as a warning from the linker.

I see the problems with using CMAKE_FIND_ROOT_PATH, though - conan doesn't really want to re-root everybody else's path's either.
My current solution has been to bind mount the conan cache at the same location inside the sysroot, so that it's found prefixed, but that's noo ideal either.

I wonder if CMake could be convinced to implement something like a `CMAKE_FIND_ONLY_PATH` that was kind of the the opposite of [`CMAKE_IGNORE_PATH`](https://cmake.org/cmake/help/latest/variable/CMAKE_IGNORE_PATH.html) for conan 2.0 to use. It could just be a ;-list of prefixes that did not introduce any additional search locations, but made paths (from things like CMAKE_LIBRARY_PATH) eligible to match in CMAKE_FIND_ROOT_PATH_MODE_*  ONLY if they intersected with it. If that existed, conan could list the root paths of packages found in the host context; and if necessary to support older CMake versions, you could still set "BOTH" mode for them (but then only old versions would have to take the risk of accidentally picking up non-conan libraries from the build environment).
user: puetzk
issue_10508: state: open
title: [bug] BazelDeps does not work with shared libraries
body: It is hard-coded in the BazelDeps.py class. I've done a quick fix on my fork but I do have some other pull request open with previous fixes.

Putting this hear to help with the milestone for version 1.46

Possible fix: https://github.com/mohabouje/conan/commit/84621b5791ebb790ecc26745f3835d1b32168ac1


user: mohabouje
issue_10486: state: open
title: [feature] [hooks] filter invocations for dependencies (post_package_info in particular)
body: <!-- What is your suggestion? Please be as specific as possible! -->

from https://github.com/conan-io/hooks/pull/377

right now it's not easy from the hook itself to understand was it called for the main reference (the one `conan create` or `conan install` was invoked on), or some dependency.
in particular, `post_package_info` hook is invoked multiple times.
from the method signature, I don't see an easy way to distinguish if a package is a root graph node or node.
I had to use the ugly `sys.modules` approach.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: SSE4
issue_10473: state: open
title: [bug] conan create is faulty on windows
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: MSVC 2019
  * Conan version: 1.44.1

### Steps to reproduce (Include if Applicable)
a recipe does not really matter
cd ... conan-center-index\recipes\yasm\all
conan create . yasm/1.3.0@ --build missing

### Logs (Executed commands with output) (Include/Attach if Applicable)

> conan create . yasm/1.3.0@ --build missing
ERROR: Package 00dfe7 has an invalid version number: '1'. Valid names MUST begin with a letter, number or underscore, have between 2-51 chars, including letters, numbers, underscore, dot and dash
user: AndreyMlashkin
issue_10463: state: open
title: [bug] Autotools configure fails when there's a space in the path
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

See https://github.com/conan-io/conan-center-index/pull/8644#issuecomment-1024832164

looks like `Autotools` need to adjust the path like `AutoToolsBuildEnvironment` does in https://github.com/conan-io/conan/blob/5d02f0ef495d7b3d3109b41f9b0ebc20c6f6fded/conans/client/build/autotools_environment.py#L175

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
ruby/3.1.0: Calling:
 > C:\Users\Chris McArthur\.conan\data\ruby\3.1.0\_\_\build\f13bef38a30be6c3f44b319a0b1af5bea4ed1074\source_subfolder\win32/configure --disable-install-doc "--prefix=C:/Users/Chris McArthur/.conan/data/ruby/3.1.0/_/_/package/f13bef38a30be6c3f44b319a0b1af5bea4ed1074" --bindir=${prefix}/bin --sbindir=${prefix}/bin --libdir=${prefix}/lib --includedir=${prefix}/include --oldincludedir=${prefix}/include --datarootdir=${prefix}/share
Capturing current environment in deactivate_conanautotoolsdeps.bat
Configuring environment variables
Capturing current environment in deactivate_conanautotoolstoolchain.bat
Configuring environment variables
'C:\Users\Chris' is not recognized as an internal or external command,
operable program or batch file.
```

user: dvirtz
issue_10454: state: open
title: [question] version ranges using same package multiple times
body: I got the following problem:

I have project **A** that requires a specific **libA** and **libB**.
Project **libA** also requires **libB**.

For versioning I use version ranges that only match major and minor version, namely:
`libB/[== 1.3.x]@user/channel`

in both project **A** and **libA**.

for conan install, I now get the following error:

`ERROR: libA/1.3.0@user/channel: requirement libB/[== 1.3.x]@user/channel overridden by A/1.0.0 to libB/1.3.0@user/channel`

Thus, obviously conan is unable to detect that 1.3.0 satisfies 1.3.x and believes this is a clash.
Although `semver.satisfies('1.3.0', '1.3.x')` correctly delivers True.

Remark: there is exactly one recipe for libB available, namely for 1.3.0.


- [X ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: RolfBippus
issue_10444: state: open
title: [question] Do conan components work with editables / layout files
body: I have a cmake project which is split into multiple components. The components are split into their own directories:

- component1
  - include
  - src
- component2
  - include
  - src

When this project is installed/packaged the layout changes is

- include
  - component1
    - &lt;content of component1 include&gt;
  - component2
    - &lt;content of component1 include&gt;
- libs
  - libcomponent1.a
  - libcomponent2.a

This layout is described in the `package_info` and works well. But I am not able to work with editables because I can not provide per-component include-dirs in the layout file. 

I thought there might be a workaround by doing a cmake-install into the build-directory. But even then I have to change the base-directory which is used for the relative include-paths set on the components. 

Is this a known issue? Are there any workarounds? qualified pkg/version@channel scheme? Or let it pick it's requirements from the same channel I'm running "create" for?

- [x]  I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: actual-daniel
issue_10441: state: open
title: [question] How to use a predefined user/channel as "standard" for require()
body: I've the scenario that we've a local conan package repository (mostly because of reducing traffic) which keeps the packages. These packages are based on conan-center packages, but may have small modifications/patches for certain architectures.

Let's say a conan recipe does a `self.requires("libpng/1.6.37")` somewhere, this fails, because conan-center is not there as a remote. `CONAN_USERNAME` and `CONAN_CHANNEL` are deprecated. There's some `default_user` and `default_channel`, but I can't get it running from outside the recipe. Looks like I don't understand how to use these :confused:

What do I need, to make it pick the package from a certain channel (i.e. @foo/stable) on `conan create`, without replacing all requires with a full qualified pkg/version@channel scheme? Or let it pick it's requirements from the same channel I'm running "create" for?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: cajus
issue_10439: state: open
title: [bug] Vulkan Validation layers packages causes conan to crash with generator PkgConfigDeps
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: msvc 17
  * Conan version: 1.44.0
  * Python version: 3.11

### Steps to reproduce (Include if Applicable)

Create this conan.py:

```
from distutils.command.build_clib import build_clib
import os
from conans import ConanFile, tools, Meson
from conans.tools import OSInfo
from conans.tools import os_info, SystemPackageTool
from conan.tools.gnu import PkgConfigDeps


class ConanFileNeverEngine(ConanFile):
    generators = "PkgConfigDeps"

    requires = [
        "vulkan-validationlayers/1.2.182",
    ]

    settings = {
        "os": None,
        "compiler" : None,
        "cppstd": None,
        "build_type" : None}

    def generate(self):
        self.output.error("asaaaaaaaaaaaa")
        pc = PkgConfigDeps(self)
        pc.generate()

    def layout(self):
        build_dir = '_'.join([str(self.settings.compiler).lower().replace(' ', '_'), str(self.settings.build_type).lower()])
        self.folders.build = f'build{build_dir}'
        self.folders.generators = self.folders.build
        self.folders.imports = self.folders.build
        self.folders.source = "src"
 ```
 
 Then run:
 
` conan install . -s build_type=Debug -s compiler.runtime=MDd -s compiler="Visual Studio" -s compiler.version=17 --build=missing`

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=Visual Studio
compiler.runtime=MDd
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

conanfile.py: Installing package
Requirements
    robin-hood-hashing/3.11.3 from 'conancenter' - Cache
    spirv-headers/cci.20210616 from 'conancenter' - Cache
    spirv-tools/2021.2 from 'conancenter' - Cache
    vulkan-headers/1.2.182 from 'conancenter' - Cache
    vulkan-validationlayers/1.2.182 from 'conancenter' - Cache
Packages
    robin-hood-hashing/3.11.3:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache
    spirv-headers/cci.20210616:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Skip
    spirv-tools/2021.2:927df38c63db57e3a69e9c84cf6f819a8d5a71bc - Skip
    vulkan-headers/1.2.182:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache
    vulkan-validationlayers/1.2.182:9e5bdedf4ff8029b6e5a2bd68a73728dbf2a744a - Cache

Installing (downloading, building) binaries...
robin-hood-hashing/3.11.3: Already installed!
vulkan-headers/1.2.182: Already installed!
vulkan-validationlayers/1.2.182: Already installed!
vulkan-validationlayers/1.2.182: Prepending to VK_LAYER_PATH runtime environment variable: C:\.conan\8ed15f\1\bin
conanfile.py: Generator txt created conanbuildinfo.txt
conanfile.py: Generator 'PkgConfigDeps' calling 'generate()'
ERROR: Error in generator 'PkgConfigDeps': 'NoneType' object has no attribute 'includedirs'
```

Note I don;t see this happening with any other package.

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: Makogan
issue_10420: state: open
title: [bug] settings.yml deemed changed on update
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Win 10 x64
  * Compiler+version:
  * Conan version:
  * Python version: 3.9

### Steps to reproduce (Include if Applicable)
Several times since initially installing 1.30, after updating conan I have had issues with settings.yml not being able to be updated for some reason and a settings.yml.new be created.
The thing is sometimes (such as with #10412 ) it is required to have the latest settings.yml.
I have never ever touched the settings.yml manually, nor knowingly though conan commands.

For some reason, updating to newer settings.yml on update does not always work correctly.
I did skip quite a few version between sporadic updates (and I would assume most people do), maybe that has something to do with it? If only the previous versions settings.yml is upgradable, then skipping a release that changes the settings.yml would probably cause this issue.
user: Sil3ntStorm
issue_10418: state: open
title: [question] QMake and library rpath on MacOS
body: I'm working on QMake app which has dynamic library dependencies. Those dependencies are on conan remote and it has wrong paths as rpath (/Users/user1/workspace ...) As a result, when I download the dependencies and try to execute the bundle the app is not running due to unresolved path (user1 is not my user). 

To solve it, I copied the package using conan copy but this time fixing manually rpaths on the libraries. Then I uploaded the package on a different channel but when I try to use that library from remote, rpaths are not being modified on the copied package and the result is the same than previously. 

My question is, what is the best approach to manage this situation? I have read that it could be solved on CMake but nothing on QMake. 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: jngd
issue_10413: state: open
title: [question] How to use cmake interface library with target sources?
body: In my CMakeLists.txt I create an interface library, add sources to it and then link it to an executable. When I try to consume it I get lots of undefined references.
CMakeLists.txt example:
```cmake
add_library(MyLib INTERFACE)
target_sources(MyLib INTERFACE util.cxx)
add_executable(SomeTarget main.cxx)
target_link_libraries(SomeTarget MyLib)
```
[The project where I am creating the library and using it in the tests](https://github.com/werto87/matchmaking_proxy)
[The conan recipe](https://github.com/werto87/conan_matchmaking_proxy)
[The project in which I try to use the library](https://github.com/werto87/matchmaking_proxy_from_lib)

I want conan to create a target like "MyLib" with the sources so I can link to it in the consuming project.
I tried to use "self.cpp_info.srcdirs" but it did not work. 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: werto87
labels: component: Build: Build helpers, build systems..
issue_10387: state: open
title: [feature] CMakeToolchain: remove CMAKE_FIND_PACKAGE_PREFER_CONFIG ON
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

`CMAKE_FIND_PACKAGE_PREFER_CONFIG ON` in `CMakeToolchain` originally addressed this problem:
-  `CMakeDeps` is supposed to be able to work in conjunction with `CMakeDeps` (`cmake_find_package` & `cmake_find_package_multi` removed in conan v2).
-  `CMakeDeps` was supposed to generate only CMake config files.
- by default CMake looks first for Find files, then config files in a call like `find_package(foo)` (without `CONFIG` or `NO_MODULE`).
- it would have been an issue for consumers/recipes depending on recipes packaging libraries listed in https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html#find-modules, since those modules would have take precedence over config files generated by `CMakeDeps`. Indeed, no one in C++ ecosystem has ever written in its CMakeLists `find_package(ZLIB REQUIRED CONFIG)`.

But now:
- `CMakeDeps` has learned generation of Find module files when a recipe set `cmake_find_mode` property to `both` in `package_info()`.
- all CCI recipes listed in https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html#find-modules have been updated so that CMakeDeps will always generate both Find & config files.

There is no more reason to keep `CMAKE_FIND_PACKAGE_PREFER_CONFIG ON`. it may have undesirable side effects. For example an agnostic CMakeLists looking for one of the files in https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html#find-modules, may ends up with the config file which have different target names than the Find file (there are few cases like freetype and expat, which have built-in CMake modules files in CMake installation, and also provide config files. Target names are different but not the Find & config file names).


user: SpaceIm
issue_10373: state: open
title: [bug] graph_info.json generated in unexpected directory for editables
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: macOs 11.6.1
  * Compiler+version: Apple clang version 13.0.0
  * Conan version: Conan version 1.43.0
  * Python version: Python 3.10.0

### Steps to reproduce (Include if Applicable)

After running the following script, there is a spurious file `lib/graph_info.json` generated by the last step, `conan install app`. It is expected that `graph_info.json` is generated in the `lib/generators` folder like files created by other generators.

```
#!/bin/sh -efu

mkdir -p app lib
cat >lib/conanfile.py <<EOF
from conans import ConanFile

class LibConan(ConanFile):
    generators = ()

    def layout(self):
        self.folders.build = "build"
        self.folders.generators = "generators"
EOF

cat >app/conanfile.py <<EOF
from conans import ConanFile

class AppConan(ConanFile):
    generators = ()
    requires = "lib/[>=0]"

    def layout(self):
        self.folders.build = "build"
        self.folders.generators = "generators"
EOF

export CONAN_USER_HOME=$PWD

conan install -if lib/install lib lib/0.0@
conan editable add lib lib/0.0@
conan install -if app/install app app/0.0@
tree
```

### Logs (Executed commands with output) (Include/Attach if Applicable)


```
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=13.0
os=Macos
os_build=Macos
[options]
[build_requires]
[env]

conanfile.py (lib/0.0): Installing package
Requirements
Packages

Installing (downloading, building) binaries...
conanfile.py (lib/0.0): Generator txt created conanbuildinfo.txt
conanfile.py (lib/0.0): Aggregating env generators
conanfile.py (lib/0.0): Generated conaninfo.txt
conanfile.py (lib/0.0): Generated graphinfo
Reference 'lib/0.0@' in editable mode
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=13.0
os=Macos
os_build=Macos
[options]
[build_requires]
[env]

Version ranges solved
    Version range '>=0' required by 'conanfile.py (app/0.0)' resolved to 'lib/0.0' in local cache

conanfile.py (app/0.0): Installing package
Requirements
    lib/0.0 from user folder - Editable
Packages
    lib/0.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Editable

Installing (downloading, building) binaries...
lib/0.0: Rewriting files of editable package 'lib' at '/Users/joki/src/conanbug/lib/generators'
lib/0.0: Aggregating env generators
lib/0.0: Generated toolchain
lib/0.0: Generated conan.lock
conanfile.py (app/0.0): Generator txt created conanbuildinfo.txt
conanfile.py (app/0.0): Aggregating env generators
conanfile.py (app/0.0): Generated conaninfo.txt
conanfile.py (app/0.0): Generated graphinfo
.
├── app
│   ├── conanfile.py
│   └── install
│       ├── conan.lock
│       ├── conanbuildinfo.txt
│       ├── conaninfo.txt
│       └── graph_info.json
├── lib
│   ├── conanfile.py
│   ├── graph_info.json
│   └── install
│       ├── conan.lock
│       ├── conanbuildinfo.txt
│       ├── conaninfo.txt
│       └── graph_info.json
└── test

4 directories, 12 files
```

The `tree` output shows the file `lib/graph_info.json` which isn't supposed to exist in this location. It should be in the `lib/generators` folder as specified by `layout(self)` in `lib/conanfile.py`.
user: jkuebart
issue_10370: state: open
title: [question] With build profile specified the self.copy() does not work for build_required package?
body: I am calling `self.copy()` in `imports()` to copy a build tool binary form a dependency specified as `build_require`. This works normally, the tool is found and copied to build dir. However, when build profile is specified it does not - the tool is not copied.

I can work around the problem by finding out absolute path to the build_required package (from self.dependencies) and then calling self.copy() with this absolute path.

Is this an expected behavior?
user: michkrom
issue_10366: state: open
title: cmake in build_requires cannot find compiler in toolchain
body: [conanfile.txt](https://github.com/conan-io/conan/files/7891428/conanfile.txt)
[profile.txt](https://github.com/conan-io/conan/files/7891429/profile.txt)
[Hello]([url]())

I have a profile like this:
```
[settings]
arch=x86_64
os=Linux
build_type=Debug

compiler=gcc
compiler.version=8.5
compiler.glibc=2.27
compiler.libcxx=libstdc++11

[build_requires]
gcc_8.5.0_glibc_2.27_x86_64/0.0.1
cmake/3.22.0
```


gcc_8.5.0_glibc_2.27_x86_64 contains my compiler toolchain. The package conanfile.py set-up variables required:
```
    def package_info(self):
        path = os.path.join(self.package_folder, "x86_64-linux-gnu")
        sysroot  = os.path.join(self.package_folder, "x86_64-linux-gnu/x86_64-linux-gnu/sysroot")

        self.user_info.PACKAGE_FOLDER = self.package_folder
        self.user_info.C_COMPILER = os.path.join(path, "bin/x86_64-linux-gnu-gcc")
        self.user_info.CXX_COMPILER = os.path.join(path, "bin/x86_64-linux-gnu-g++")
        self.user_info.SYSROOT = sysroot

        self.env_info.CC = os.path.join(path, "bin/x86_64-linux-gnu-gcc")
        self.env_info.CXX = os.path.join(path, "bin/x86_64-linux-gnu-g++")
        self.env_info.SYSROOT = sysroot
        self.env_info.CFLAGS   = "-fPIC            -O0 -ggdb -Wall"
        self.env_info.CXXFLAGS = "-fPIC -std=c++11 -O0 -ggdb -Wall"

        self.env_info.CONAN_CMAKE_SYSROOT = sysroot
        self.env_info.CONAN_CMAKE_FIND_ROOT_PATH = sysroot
        
        self.env_info.CONAN_CMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "NEVER"
        self.env_info.CONAN_CMAKE_FIND_ROOT_PATH_MODE_LIBRARY = "ONLY"
        self.env_info.CONAN_CMAKE_FIND_ROOT_PATH_MODE_INCLUDE = "ONLY"
        self.env_info.CONAN_CMAKE_FIND_ROOT_PATH_MODE_PACKAGE = "ONLY"
```
But cmake does not detect the correct compiler:
```
cmake/3.22.0: Copying sources to build folder
cmake/3.22.0: Building your package in /jenkins/kvasir13/executor_1/kvasir_file_cache/conan/amd64-gcc8/.conan/data/cmake/3.22.0/_/_/build/69461bb05cebfdde826615f89ed40e156920df79
cmake/3.22.0: Generator cmake created conanbuildinfo.cmake
cmake/3.22.0: Aggregating env generators
cmake/3.22.0: Calling build()
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan: Compiler GCC>=5, checking major version 8.5
-- Conan: Checking correct version: 9.3
CMake Error at ../conanbuildinfo.cmake:513 (message):
  Detected a mismatch for the compiler version between your conan profile
  settings and CMake:

  Compiler version specified in your conan profile: 8.5

  Compiler version detected in CMake: 9.3
```

If I remove cmake from the build requirements I get this error while configuring automake/1.16.4:
```
checking whether autoconf is installed... no
configure: error: Autoconf 2.65 or better is required.
    Please make sure it is installed and in your PATH.
automake/1.16.4: 
How can I make cmake acknowledge the compiler in the toolchain?
```

I guess there is some package inthere that it tries to build with cmake if present and otherwise with automake.
It is not clear from the logs which package it is.

In any case, I would like this to work without having to install cmake and/or autoconf on the build system. The packages requiring these should fetch and use them themselves.

Conan 1.43
Using build and host profile set-up.

Rgds
Klaus
user: klausholstjacobsen
issue_10356: state: open
title: [question] How to specify relative paths in layout or obtain the CLI provided install folder?
body: 
When defining a ```layout()``` how can I obtain the CLI provided install/build folder or provide relative paths to it when specifying ```self.folders.generators```? 
 
I am trying to build with V2 using with multiple profiles and necessarily maintain independent build folders for each of my profiles using something like:
 
```bash
 conan install -if cmake-build-target1 -pr:b default -pr:h target1 .
```

If I use the example ```cmake_layout```, it initializes the 
```python
        conanfile.folders.build = "cmake-build-{}".format(build_type)
```
folder which **ignores** the CLI provided folder ```cmake-build-target1```. If I create my own ```layout()``` and just specify 
```python
        self.folders.generators = "conan"
```
The generator folder becomes relative to my conanfile.py recipe and also **ignores** the CLI provided ```cmake-build-target1``` value. 

Which means it is currently impossible to provide any kind of layout and support multiple target profiles specified on the CLI without maintaining multiple source trees or deleting the build folder when switching profiles. 

If I ignore the layout, and just let conan fall back to defaults it at least generates **everything** into the ```cmake-build-target1``` folder but in doing so pollutes my root build folder with 93 generated files in an already large folder.

It seems counter intuitive that the ```layout()``` would not be relative to the user provided CLI install folder, or at the very least offering the recipe some way to know what the CLI install folder is so that it can construct the absolute paths. 


user: drmacdon
issue_10355: state: open
title: [question] Create Conan Package from Source : Recipe and Sources in a Different Repo
body: Hey guys,
I'd like to create a Conan package from an internally hosted gitlab project
I'm currently struggling with the CMake  Configure Step.

CMake Error: The source directory "C:/...../build/e9a552ebe8f994398de9ceee972f0ad207df0658" does not appear to contain CMakeLists.txt.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I have read through https://docs.conan.io/en/latest/creating_packages/external_repo.html

Now my files are getting cloned properly , however the CMakeLists file is is the subdirectory "./hello"
How can I point the CMake class to this subdirectory. I could not find Source Dir Property within that class.

Can you help me out here?

Now my conan recipe is pretty simple
```

class TestConan(ConanFile):
  settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": True, "fPIC": True}
    generators = "cmake"

  
    def source(self):
        git = tools.Git(folder="hello")
        git.clone("https://github.com/conan-io/hello.git", "master")

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def layout(self):
        cmake_layout(self)

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()

    def package_info(self):
        self.cpp_info.libs = ["TestConan"]


```

thx guys :)
user: Ju1He1
issue_10353: state: open
title: Consider overrides of ``test_requires`` in profiles
body: Following https://github.com/conan-io/conan/issues/10353, we would need to consider how to override recipes ``test_requires`` from profiles.

cc / @SeanSnyders


user: memsharded
issue_10352: state: open
title: [feature] Make it possible to forward profile when using `conan search`
body: I would like to search a package via specifying the profile.
e.g:
`conan search zlib/1.2.11@ -pr gcc7 -r my_remote `

instead of specifying via `-q` again the the information from the profile

- [x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: derived-coder
issue_10335: state: open
title: [feature] Documentation missing for CMAKE_OSX_DEPLOYMENT_TARGET flag in cmake build helper
body: <!-- What is your suggestion? Please be as specific as possible! -->

https://github.com/conan-io/conan/pull/9301 Added the feature to set the CMAKE_OSX_DEPLOYMENT_TARGET from the settings.os.version, but it appears that the documentation for this is missing on the CMake build helper page: https://docs.conan.io/en/latest/reference/build_helpers/cmake.html#definitions

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).


user: eliasreid
issue_10332: state: open
title: [question] Cross building Qt using two profile approach
body: Hi,

I tried the following:

`$ conan install qtbase/6.3.0-alpha1@qt/everywhere --build --profile:build=linux-x86_64-gcc --profile:host=unix-android-armv7-clang`

When qtbase is cross-compiled e.g. to Android it needs tools from the qtbase's desktop build (i.e. the build platform) so qtbase needs to be built for the desktop first.

I guess I read the documentation a bit wrong as I was under the impression that when cross-compiling with Conan it will build the very same dependency tree for the build platform first.

Thus the output from the build was that it started to build the android host platform immediately (I tried to investigate why it did not build the build platform first: --profile:build).

After re-reading the docs I noticed that the --profile:build is used for "build_requires"/"tool_requires" so the output I got was expected.

Now the question is can **qtbase** "build_requires"/"tool_requires" **qtbase** in cross build context only somehow?
user: iiknd
issue_10330: state: open
title: [bug] conan.conf proxies not working for downloading source tarball
body: ### Environment Details
  * Operating System+version: CentOS 7.8
  * Compiler+version: gcc 9.1
  * Conan version: 1.44
  * Python version: 3.6

Hello,
I'm trying to build google benchmark library from behind a firewall. I have 2 proxies configured in artifactory, one for conan-center in remotes.txt (this works) and another for github.com. The benchmark recipe is successfully fetched from the conan-center proxy but the step where the tarball is downloaded fails, it's still trying to fetch from github.com instead of my proxy URL. Am I configuring the proxy incorrectly in `conan.conf`?

This is my `conan install` command

```
CONAN_USER_HOME=$(pwd)/build build/conan-venv/bin/conan install --remote=conan-center --build=outdated --profile=build/conan_pkg/profile --install-folder=build/conan_pkg build/conan_pkg/conanfile.txt
```

This is the `[proxies]` section in `build/.conan/conan.conf`

```
[proxies]
https =
  github.com = https://artifactory.xyz.com/artifactory/github-mirror
```
I've also tried changing the scheme to `http` and having both `http` and `https` listed, none them are working. This is the output I get from the conan install command above.

```
conanfile.txt: Installing package
Requirements
    benchmark/1.6.0 from 'conan-center' - Cache
Packages
    benchmark/1.6.0:c4e0c4261b06258cf42aed6006043e5a0ddcc875 - 
Installing (downloading, building) binaries...
benchmark/1.6.0: WARN: Build folder is dirty, removing it: /path/to/conan-build/build/.conan/data/benchmark/1.6.0/_/_/build/c4e0c4261b06258cf42aed6006043e5a0ddcc875
benchmark/1.6.0: WARN: Trying to remove corrupted source folder
benchmark/1.6.0: WARN: This can take a while for big packages
benchmark/1.6.0: Configuring sources in /path/to/conan-build/build/.conan/data/benchmark/1.6.0/_/_/source
ERROR: Error downloading file https://github.com/google/benchmark/archive/v1.6.0.tar.gz: 'HTTPSConnectionPool(host='github.com', port=443): Max retries exceeded with url: /google/benchmark/archive/v1.6.0.tar.gz (Caused by ProxyError('Cannot connect to proxy.', OSError('Tunnel connection failed: 400 Bad Request',)))'
Waiting 5 seconds to retry...
ERROR: benchmark/1.6.0: Error in source() method, line 43
        tools.get(**self.conan_data["sources"][self.version], destination=self._source_subfolder, strip_root=True)
        ConanException: Error downloading file https://github.com/google/benchmark/archive/v1.6.0.tar.gz:  'HTTPSConnectionPool(host='github.com', port=443): Max retries exceeded with url: /google/benchmark/archive/v1.6.0.tar.gz (Caused by ProxyError('Cannot connect to proxy.', OSError('Tunnel connection failed: 400 Bad Request',)))'
```

conanfile.txt

```
[requires]
benchmark/1.6.0@

[build_requires]

[generators]
CMakeDeps

[options]

[imports]
```

And the profile I'm using

```
[settings]
os=Linux
arch=x86_64
compiler=gcc
compiler.version=9.1
compiler.libcxx=libstdc++
compiler.cppstd=17
build_type=RelWithDebInfo
[options]
[build_requires]
[env]
PATH=[/path/to/conan-build/build/conan-venv/bin]
```
user: praetorian20
issue_10317: state: open
title: [question] Feedback on 2.0 tool requirements
body: (Didn't really know where it belonged, so I chose "question")

Hello,

After playing around with tool requirements in 2.0, I'd like to give a bit of feedback.

First, here's some context.

## libcxx in Conan 1.x 

We're packaging our own `libcxx`, mostly to be able to use latest C++ features without any hassle.
This package exposes header files, libraries, and compiler flags. Still we use it as a `build requirement`.

There are two main reasons for that:

1. Adding `libcxx` as a requirement in every recipe/CMakeLists.txt is very tedious (and not upstream-able)
2. It has to expose env variables for non-CMake build helpers

## libcxx in Conan 2.0.0a2

Almost everything changed in 2.0, so I tried my best to adapt the recipe:

* Use the new `CMakeToolchain` generator (Apple-specific flags are handled here)
* Use the `generate` function to "configure" CMake
* Remove every env variable from `package_info`

## Problems

A few issues arose:

1. Flags defined in `cpp_info` were not forwarded to consumers
2. The `os` / `arch` of `libcxx` were the one of the build profile, not the host profile

The latter simply means that you get a linker error when creating a consumer package, which is a bit annoying.

So I figured I had to go back to what I was doing in 1.x, i.e. populating the environment.
But I also had to workaround the fact that the build profile architecture was chosen, and not the host one.

In the end, I had to do a bit like the Android NDK, and build every variant I want (os + sdk + arch) and bundle everything in a single package.

To do that, I had to redefine some of the CMake cross-building vars, and get rid of the CMake build helper. It works, but feels very brittle for a future 2.0.

I've attached both versions of the recipe for 1.x and 2.0 + associated profiles.

Looking forward to seeing your comments!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

[libcxx_1.x.zip](https://github.com/conan-io/conan/files/7848007/libcxx_1.x.zip)
[libcxx_2.0.zip](https://github.com/conan-io/conan/files/7848009/libcxx_2.0.zip)
[profiles.zip](https://github.com/conan-io/conan/files/7848011/profiles.zip)

user: theodelrieu
labels: whiteboard: Put in common
issue_10311: state: open
title: [question] Should system_requirements() of a build_requierement's requirement be called on package build?
body: I know, the title is super confusing. I'll clarify bellow. 

In order to crosscompile packages, we use a Conan packaged SDK which is injected as a `build_requirement` through a profile. Lets call it `mySDK`.
The `mySDK` package declares a package with a toolchain as a requirement, lets call it `myToolchain`. This way when we build a package using the crosscompilation profile we inject `mySDK` and `myToolchain` a `build_requirements`. So far, so good.

To **build** the `myToolchain` package we need some system packages which we're declaring using the `system_requirements` method.  These act as `build_requirements` since they're just build time tools, but since we don't have conan packages for them we used this workaround. 
This works fine to build the `myToolchain` package, but we're also inheriting them on the packages we build with the `myToolchain` package. 
See the following example for clarification:

```
conan create recipes/myPackage/all myPackage/1.2.3@eric/dev -pr:b .x86_64_gcc8 -pr:h arm64
.
.
.
Requirements
    libarchive/3.5.2@eric/dev from local cache - Cache
    libiconv/1.16@eric/dev from 'conan-brewst' - Cache
    zlib/1.2.11@eric/dev from local cache - Cache
Packages
    libarchive/3.5.2@eric/dev:8a8aecf2de6342dba81fda0af2bd34a945be962c - Build
    libiconv/1.16@eric/dev:5b8fe3d9bc066b8f115ca71f7e4238c85a8105d3 - Cache
    zlib/1.2.11@eric/dev:95824abc279878dc33eec520eaf6c1a67c50a078 - Cache
Build requirements
    mySDK/1.0@eric/dev from 'conan-brewst' - Cache
    myToolchain/1.0@eric/dev from 'conan-brewst' - Cache
Build requirements packages
    mySDK/1.0@eric/dev:701bd4d0ac4938df67cb11dc6ace8fbb265dd518 - Cache					<- declared by arm64 profile
    myToolchain/1.0@eric/dev:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache			<- mySDK's requirement

Cross-build from 'Linux:x86_64' to 'Linux:aarch64'
Installing (downloading, building) binaries...
Running: sudo apt-get update															<- myToolchain's system_requirements!
[sudo] password for eric: 
```
I understand how this could be intended behavior as these system_requirements can be runtime dependencies but, can I treat them as build_requirements somehow? What's the best practice here?
Thanks! 
user: ericriff
issue_10305: state: open
title: How can we configure a large project with multiple subfolders and .c and .h files to build with conan and cmake
body: example project structure is 

project->source->folder1->folderA->inc->one.h
                                                                  ->two.h
                                                                  ->three.h
                                                         ->src->first.c(include header and .c files from folder2 and folder3 also)
                                                                  ->second.c(include header and .c files from folder2 and folder3 also)
                          ->folder2..................
                          ->folder3..............
user: NIKHILJIND
issue_10303: state: open
title: [bug] AutoToolsBuildEnvironment produces incorrect flags for Visual Studio 2022
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

using `AutoToolsBuildEnvironment` with Visual Studio 2022, it produces an incorrect flag:
```
cl : Command line warning D9002 : ignoring unknown option '-dynamic'
```
perhaps, it uses `compiler.runtime` as is, but it shouldn't for `msvc` compiler.

### Environment Details (include every applicable attribute)
  * Operating System+version: `Microsoft Windows [Version 10.0.19043.1348]`
  * Compiler+version: `Microsoft (R) C/C++ Optimizing Compiler Version 19.30.30706 for x86`
  * Conan version: `Conan version 1.45.0-dev`
  * Python version: `Python 3.9.7`
### Steps to reproduce (Include if Applicable)


### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SSE4
issue_10296: state: open
title: [bug] Problem with revision after migration to new Artifactory server
body: 

### Environment Details (include every applicable attribute)
  * Artifactory version 7.17
  * Conan version 1.29

### Explanation
After a server migration (From CE community) to Commercial one, we decided to activate revision in our centralized  conan conf file.
Then all "old" packages are now with a recipe revision 0 as expected. New Versions of packages are now associated with their git commitID since we choose SCM mode for revision. So far, so good.
After the migration we clean all local caches in order that no scories exists.
On certain machines (dev or CI machines) and not often, we have trouble with certain conan packages that are installed.
When looking forward and using `conan search PackageName --revision,` theses defect packages are installed but with a bad revision number (a hash or a commit id or something else that doesn't match with existing revision on the artifactory server).
When using the same command with the` --raw` option, a "(No Time) is displayed after the revision number".
The workaround is to remove the package locally with `conan remove PackageRef` and then `conan install` works fine.
The problem is that it is a workaround, that it's not easily reproductible and not possible at all for CI jobs...

PS: Before the migration, I didn't find the way to disable revision in Artifactory server (that the first reason why i choose to enable it in the conan configuration. Without this enabled, I was not allowed to upload a conan packages without revision in the new server), is that normal or did I miss something? 


user: tofDou
issue_10294: state: open
title: [question] Different outputs for short paths at conan info --paths
body: Hello,

I haven't found a detailed answer on the issues or conan docs so I hope I am not repeating this.
We observed different outputs for the `conan info` command when using the different level of settings for short paths feature.

In conan there are 3 sources for the short_path setting in Windows:
1.	Environment variable `CONAN_USE_ALWAYS_SHORT_PATHS`
2.	Config file setting `general.use_always_short_paths`
3.	`short_paths` attribute inside the `conanfile.py`

In the table below there are some test results when using the combination of these settings. 
For the test results, the `long path` means that the output contains the paths from the data location and `short path` output contains the paths from the short path location.               
Example:  
short path output:

```
D:\conan-Artifactory>conan info helloworld/1.0.0@conan_user/testing --paths
helloworld/1.0.0@conan_user/testing
    ID: 456f15897172eef340fcbac8a70811f2beb26a93
    BuildID: None
    Context: host
    export_folder: D:\.conan\data2\helloworld\1.0.0\conan_user\testing\export
    source_folder: D:\.conan\short2\ad9f34\1
    build_folder: D:\.conan\ce51b0\1
    package_folder: D:\.conan\short2\9b007c\1
   .....
```
long path output:
```
D:\conan-Artifactory>conan info helloworld/1.0.0@conan_user/testing --paths
helloworld/1.0.0@conan_user/testing
    ID: 456f15897172eef340fcbac8a70811f2beb26a93
    BuildID: None
    Context: host
    export_folder: D:\.conan\data2\helloworld\1.0.0\conan_user\testing\export
    source_folder: D:\.conan\data2\helloworld\1.0.0\conan_user\testing\source
    build_folder: D:\.conan\data2\helloworld\1.0.0\conan_user\testing\build\456f15897172eef340fcbac8a70811f2beb26a93
    package_folder: D:\.conan\data2\helloworld\1.0.0\conan_user\testing\package\456f15897172eef340fcbac8a70811f2beb26a93
   .......
```
|     Env. Var. CONAN_USE_ALWAYS_SHORT_PATHS    |     conan.conf Setting     general.use_always_short_paths    |     conanfile.py attribute short_paths    |     Test Result for conan info -–paths     |    Expected Result  |
|---------------------------------------------------|---------------------------------------------------------------|-------------------------------------------|---------------------------------------|---------------------|
|     False or not set                                 |     False or not set                                             |     False or not set                         |     long path                         |     long path       |
|     False or not set                                 |     False or not set                                            |     True                                  |     short path                        |     short path      |
|     False                                         |     True                                                      |     False or not set                         |     long path                         |     short path      |
|     not set                                          |     True                                                      |     False or not set                         |     long path                         |     short path      |
|     False or not set                                 |     True                                                      |     True                                  |     short path                        |     short path      |
|     True                                          |     False or not set                                             |     False or not set                         |     short path                        |     short path      |
|     True                                          |     False or not set                                             |     True                                  |     short path                        |     short path      |
|     True                                          |     True                                                      |     False or not set                         |     short path                        |     short path      |
|     True                                          |     True                                                      |     True                                  |     short path                        |     short path      |

When activating only the `conan.conf` setting, the `conan info --paths` displays the long path output but we expected that the behavior is the same as when using the other settings. Is this the desired behavior?
Indeed in the docs of https://docs.conan.io/en/latest/reference/env_vars.html#conan-use-always-short-paths there is no mention about the `conan.conf` setting.


About the location of the `build folder`:
> Enabling short paths management will “link” the source and build directories of the package to a different location, in Windows it will be `C:\.conan\tmpdir`.       

Is this the reason why the `build_folder` is created outside the conan cache? What is the use case behind? When using only the `conan.conf` setting the `build_folder` is kept only in the cache. 

conan version: `1.43.0`    
Python version: `3.9.1`  
OS info: `Windows 10.0.19042`

    

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: AlexandraNegru
issue_10293: state: open
title: [question] output of deps_cpp_info libdirs differs between 'conan create' and 'conan build' (follow up)
body: I've a follow up question to #7529:

Given those two recipes:

- `conanfile.dep.py`

```
from conans import ConanFile

class testDep(ConanFile):
    name = 'test-dep'
    version = "0.0.0"
    description = 'test dep'
    license = "none"
    url = "none"
    author = "none"

    exports_sources = "lib/*"

    def package_info(self):
        # required, because cross compiler errors out on -L<dir> directives
        self.cpp_info.libdirs = []
        self.cpp_info.sharedlinkflags = [f"-i{self.package_folder}/lib", f"-i{self.package_folder}/include"]

    def package(self):
        self.copy("lib/*")
```

- `conanfile.py`

```
from conans import ConanFile

class testApp(ConanFile):
    name = 'test-app'
    version = "0.0.0"
    description = 'test app'
    license = "none"
    url = "none"
    author = "none"

    def build_requirements(self):
        self.build_requires("test-dep/0.0.0@common/snapshot")

    def build(self):
        print("libdirs" + str(self.deps_cpp_info.libdirs) + " / " + str(self.deps_cpp_info["test-dep"].libdirs))
```

and the folder structure:

```
.
├── conanfile.dep.py
├── conanfile.py
└── lib
    └── test-dep.so
```

I call using conan 1.40.4
a)

```
conan create conanfile.dep.py test-dep/0.0.0@common/snapshot
conan create conanfile.py test-app/0.0.0@common/snapshot
```

and get the output `libdirs[] / []`

b) 

```
conan create conanfile.dep.py test-dep/0.0.0@common/snapshot
conan install . -if build
conan build . -if build
```

and get the output `libdirs['/volume/conan_cache/<user_name>/.conan/data/test-dep/0.0.0/common/snapshot/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/lib'] / ['lib']`

My question is: Why are those outputs different? In our real world example, `test-dep` is a [cross compiler](https://www.ti.com/tool/download/C6000-CGT-7-4) and this effectively causes the linker to error out during conan build, but not during conan create. But we would like to be able to use both.



- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Da-LiFe
issue_10290: state: open
title: Specify data dir when calling conan install
body: Hello

I would like to be able to specify the data dir for at given call to conan install.

My scenario is that I use the Clion IDE for development. Here I have multiple enabled configurations/platforms.
When I "refresh" cmake then all enabled platforms will refresh cmake. 
I use the conan.cmake helper to call `conan install...` from cmake. A cmake refresh will thus cause a call to conan install. 
But conan is not always very good at handling multiple simultaneous calls to conan install.

Often clion will decide to stop an ongoing cmake refresh and do it again, leaving conan lock files present. I will then have to remove the locks manually before continuing. If I could specify the conan data dir at the call to `conan install...` There would be no problem with locks at all.

I cannot see how the environment variable CONAN_USER_HOME will work for me, because the two simultanous calls to `conan install ...` will just compete on setting the environment variable, and the last one to set it will be the winner.

Is there a way to solve my problem without specifying the data directory when calling `conan install ...`?

Rgds
Klaus

user: klausholstjacobsen
issue_10289: state: open
title: Found a possible security concern
body: Hey there!

I belong to an open source security research community, and a member (@srikanthprathi) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a `SECURITY.md` file with an email, or another contact method? GitHub [recommends](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository) this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)
user: JamieSlome
issue_10285: state: open
title: [question] cross compile meson packages from CCI
body: I tried to cross compile [fribidi](https://conan.io/center/fribidi) and [glib](https://conan.io/center/glib) from CCI and noticed that it does not work out of the box.

After searching I found this closed ticket https://github.com/conan-io/conan/issues/4529 which introduced `MesonToolchain` and a new `Meson` class documented here https://docs.conan.io/en/latest/reference/conanfile/tools/meson.html.

Now I wondered what is best practice to enable cross compile for meson packages on  CCI.
I could refactor the existing recipes to use the new `MesonToolchain` and `Meson` class but those are experimental and the interface of `Meson` seems to be incompatible. ([new](https://github.com/conan-io/conan/blob/release/1.44/conan/tools/meson/meson.py) vs [old](https://github.com/conan-io/conan/blob/release/1.44/conans/client/build/meson.py))

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: andiwand
issue_10283: state: open
title: [feature] Merged options in transitive dependencies
body: I've been working with the awesome experimental components feature and how to build exactly what you need.  My particular goal is analyzing security impacts of my project, and one of the strategies is minimizing the vulnerability surface.  The useful feature would be to merge options when a dependency is required by multiple 

```
Root -> A, B
A -> C (with feature X)
B -> C (don't need feature X)
```

The result of this is that you need to decide that you need feature X in Root.  C is no longer a simple transitive dependency, but one you have to specify deliberately.  It would be useful if there could be a hook for logic C to say something like `X requested = any(X needed)`.

For components specifically, there could also be more complex logic.  What if there was an option to declare the required components?

```
Root -> A, B
A -> C (components = X,Y)
B -> C (components = Y,Z)
```

Then the logic would be `X requested = ','.join(set(X needed.split(',')))`.  This might not be the best for every use case (because it would result in package for every combination of components), but it would allow a simple way to only build exactly what you want.  This is particularly important if the components aren't quite independent (what if, Z only works if X has a compile-time reference to it?).


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: rddesmond
issue_10282: state: open
title: [question] cmake_build_modules behavior in conan 1.43.0 and conan 1.43.2
body: I am using conan 1.43.2
I have built conan package for google protobuf for my platform using this recipe in conan central.
https://github.com/conan-io/conan-center-index/blob/master/recipes/protobuf/all/conanfile.py
the build recipe sets "cmake_build_modules" in package_info().
`self.cpp_info.components["libprotobuf"].set_property("cmake_build_modules", build_modules)`

// create command
`bash$> conan create .  x.y.z@myuser/mychannel -pr debug64 -pr:b debug64`


In my consumer conanfile.py, I am using CMakeToolchain and CMakeDeps generators

```
class MyProjetConan(ConanFile):
    ....
    requires = "protobuf/x.y.z@myuser/mychannel"

    def generate(self):
        tc = CMakeToolchain(self)
        tc.variables["CMAKE_VERBOSE_MAKEFILE"] = True
        tc.generate()
        deps = CMakeDeps(self)
        deps.generate()

```
I am consuming like this
`bash$ /myproject_root/build/> conan install .. -pr debug64 -pr:b debug64`

However, the build modules (*.cmake files) aren't set in the generated cmake files with conan 1.43.2
```
bash$ /myproject_root/build/> grep protobuf_BUILD_MODULES_PATHS_DEBUG protobuf*
protobuf-debug-x86_64-data.cmake:set(protobuf_BUILD_MODULES_PATHS_DEBUG )  # Not Set!!
```

If I downgrade to conan 1.43.0, then it works.
```
bash$ /myproject_root/build/> conan install .. -pr debug64 -pr:b debug64  # with conan 1.43.0
bash$ /myproject_root/build/> grep protobuf_BUILD_MODULES_PATHS_DEBUG protobuf*
protobuf-debug-x86_64-data.cmake:set(protobuf_BUILD_MODULES_PATHS_DEBUG "${protobuf_PACKAGE_FOLDER_DEBUG/lib/cmake/protobuf/protobuf-generate.cmake" .... )
```


Is it a bug or am I using host and build profiles incorrectly? I am building and consuming on the same physical host.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: rajatgirotra
issue_10280: state: open
title: Remote authentication using environmental variables does not work
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

Authenticating using the [CONAN_LOGIN_USERNAME, CONAN_LOGIN_USERNAME_{REMOTE_NAME}](https://docs.conan.io/en/latest/reference/env_vars.html#conan-login-username-conan-login-username-remote-name) and [CONAN_PASSWORD, CONAN_PASSWORD_{REMOTE_NAME}](https://docs.conan.io/en/latest/reference/env_vars.html#conan-password-conan-password-remote-name) environmental variables does not work. At least searching for packages and installing them does not work with this authentication method in Windows cmd and Powershell and it appears to not work either on Linux with Bash (Docker container based on Ubuntu 18.04).

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 Build 19042.1348
  * Compiler+version: N/A
  * Conan version: 1.44.0
  * Python version: 3.8.6

### Steps to reproduce (Include if Applicable)

In CMD:

```cmd
conan user --clean
set CONAN_LOGIN_USERNAME=<user>
set CONAN_PASSWORD=<password>
conan search -r <remote> <package>
```

Powershell:

```psh
conan user --clean
$env:CONAN_LOGIN_USERNAME="<user>"
$env:CONAN_PASSWORD="<password>"
conan search -r <remote> <package>
```

No packages are found. Error message: "There are no packages matching the '<package>' pattern". Setting a breakpoint at [_get_env_password](https://github.com/conan-io/conan/blob/f230bf104842c160be6ea377497151fe1ea64c38/conans/client/userio.py#L103) it appears the environmental variables are never even loaded.

The user command can be used successfully with the same login and password:

CMD:

``` 
conan user %CONAN_LOGIN_USERNAME% -p %CONAN_PASSWORD%
conan search -r <remote> <package>
```

PSH:

```
conan user $env:CONAN_LOGIN_USERNAME -p $env:CONAN_PASSWORD
conan search -r <remote> <package>
```

Output:

```
Existing package recipes:

<package>/5.5.3@qorvo/beta
<package>/5.5.6@qorvo/release
<package>/5.5.8@qorvo/master
<package>/5.5.9@qorvo/master
<package>/5.8.0@qorvo/release
<package>/6.0.0@qorvo/release
<package>/6.0.1@qorvo/release
...
```

Related tickets:

- #7793
- #5434

This missing feature makes installing Conan packages in a CI/CD environment more tricky than it should be. As mentioned by the Conan documentation "These variables are useful for unattended executions like CI servers or automated tasks". Also note e.g [Gitlab CI specifically documents using these environmental variables to authenticate iof the user command](https://docs.gitlab.com/ee/user/packages/conan_repository/index.html#authenticate-to-the-package-registry). 
user: seppestas
issue_10272: state: open
title: [bug] `CMakeDeps` only looks at top level `cmake_build_modules`
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

packages setting `cmake_build_modules` on a component, like [protobuf](https://github.com/conan-io/conan-center-index/blob/4011e625faf3c9de7b5a3c37cc736a6545ff9152/recipes/protobuf/all/conanfile.py#L227), can't be used with CMakeDeps:

https://github.com/conan-io/conan/blob/70763b67d99c51cf92216f3e5d7b10b2849d2d90/conan/tools/cmake/cmakedeps/templates/target_data.py#L84

### Environment Details (include every applicable attribute)
  * Conan version: 1.44.0

### Steps to reproduce (Include if Applicable)

apply this patch to conan-center-index:
<details>
<summary>protobuf test_package patch</summary>

```diff
diff --git a/recipes/protobuf/all/test_package/CMakeLists.txt b/recipes/protobuf/all/test_package/CMakeLists.txt
index 1c4669f52..6c236a746 100644
--- a/recipes/protobuf/all/test_package/CMakeLists.txt
+++ b/recipes/protobuf/all/test_package/CMakeLists.txt
@@ -1,9 +1,6 @@
 cmake_minimum_required(VERSION 3.1)
 project(test_package)
 
-include("${CMAKE_BINARY_DIR}/conanbuildinfo.cmake")
-conan_basic_setup(TARGETS)
-
 find_package(protobuf CONFIG REQUIRED)
 
 add_executable(${PROJECT_NAME} test_package.cpp addressbook.proto)
diff --git a/recipes/protobuf/all/test_package/conanfile.py b/recipes/protobuf/all/test_package/conanfile.py
index 9cf01fd2d..dd9763e95 100644
--- a/recipes/protobuf/all/test_package/conanfile.py
+++ b/recipes/protobuf/all/test_package/conanfile.py
@@ -1,18 +1,25 @@
-from conans import ConanFile, CMake, tools
+from conans import ConanFile, tools
+from conan.tools.cmake import CMake, CMakeToolchain, CMakeDeps
 import os
 
 
 class TestPackageConan(ConanFile):
     settings = "os", "arch", "compiler", "build_type"
-    generators = "cmake", "cmake_find_package_multi"
 
     def build_requirements(self):
         if hasattr(self, "settings_build") and tools.cross_building(self):
             self.build_requires(str(self.requires["protobuf"]))
 
+    def generate(self):
+        cd = CMakeDeps(self)
+        cd.generate()
+
+        ct = CMakeToolchain(self)
+        ct.variables["protobuf_LITE"] = self.options["protobuf"].lite
+        ct.generate()
+
     def build(self):
         cmake = CMake(self)
-        cmake.definitions["protobuf_LITE"] = self.options["protobuf"].lite
         cmake.configure()
         cmake.build()
```

 </details>

then execute

```shell
conan create -pr:b=default -pr:h=default recipes/protobuf/all/ protobuf/3.17.1@
```

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
CMake Error at CMakeLists.txt:17 (protobuf_generate_cpp):
  Unknown CMake command "protobuf_generate_cpp".
```
user: dvirtz
issue_10270: state: open
title: [bug] self.copy("symlink", symlinks=True) copies the file instead of the symlink
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Debian 9
  * Compiler+version: 6.3
  * Conan version: 1.42.2
  * Python version: 3.6.13

### Steps to reproduce (Include if Applicable)

Create a recipe with:
```python
    def package(self):
        self.run("ln -s somelib.so somelib.so.3")
        self.copy("somelib.so.3", dst="lib", keep_path=False, symlinks=True)
        self.copy("somelib.so", dst="lib", keep_path=False)
```

It will copy `somelib.so.3` as a file instead of a symlink (bad for space). If I replace `self.copy("somelib.so.3", ...` with `self.copy("somelib.so.*",`, it does correctly copy the symlink instead of the file it points to.

I first tried without the `symlinks=True` and the problem was the same, instead of copying the symlink, it was copying the file the symlink was pointing to.
user: evandrocoan
issue_10267: state: open
title: [bug] AutoToolsBuildEnvironment does not recognize target x86_64-w64-mingw32 properly
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Dockerfile conanio/gcc11:latest
  * Compiler+version: Gcc 11.1
  * Conan version: 1.37.2
  * Python version: 3.7.5

### Steps to reproduce (Include if Applicable)
Create a package that is to be used as build requirement and requires the target to be according to the host profile of the package that you want to build.
Expected target is x86_64-w64-mingw32.
 - target os: Windows
 - target arch: x86_64
 - target compiler: gcc

However AutoToolsBuildEnvironment is using the compiler from the host profile, which might be a different one (theoretically) or left out completely (my case, because it is not important for the generated executable).
The following is now used to circumvent this behavior (in the conanfile): 

```
    def _get_target_settings(self):
        _os_target, _arch_target = get_target_os_arch(self)
        if hasattr(self, 'settings_target'):
            if (self.settings_target is not None):
                return _os_target, _arch_target, self.settings_target.get_safe('compiler')
        return _os_target, _arch_target, None

    def package_id(self):
        target_os, target_arch, target_compiler = self._get_target_settings()

        self.info.settings.target_os = target_os
        self.info.settings.target_arch = target_arch
        self.info.settings.target_compiler = target_compiler

    def build(self):
        autotools = AutoToolsBuildEnvironment(self)
        target_os, target_arch, target_compiler = self._get_target_settings()
        target_gnu = get_gnu_triplet(target_os, target_arch, target_compiler)
        autotools.configure(configure_dir=self.folders.source_folder,args=['--disable-multilib'], target=target_gnu)
        autotools.make()
```

I suggest the compiler used for determining the target gnu_triplet is the settings_target compiler.

user: leonschenk
issue_10261: state: open
title: Poc/develop2 exported lockfiles
body: This is a simple POC, that lockfiles can be exported together with a recipe, and if they are found while expanding the dependency graph, they can be used, locking the deps. This is something similar to the ``https://docs.npmjs.com/cli/v8/commands/npm-shrinkwrap`` shrinkwrap concept, but in this case I am proposing a "merge" instead of an independent graph, as dependencies in C++ cannot be isolated in the same way.

It is likely that activation/deactivation of this feature will be necessary, also probably appending lockfiles instead of merge strategy (the merge re-order by version or revision time) to maintain priority of downstream lockfiles.

Close https://github.com/conan-io/conan/issues/6851
user: memsharded
labels: whiteboard: Put in common
issue_10258: state: open
title: [question] CMakeDeps: COMPONENTS check?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

It seems that config file generated by `CMakeDeps` doesn't perform any check among `COMPONENTS` in `find_package()`. Is it intended or not yet implemented? Seems to be intended, it's controlled by `check_components_exist` in CMakeDeps, False by default, really surprising: https://github.com/conan-io/conan/pull/9206#issuecomment-875514043.

To reproduce: In test_package of `poco` recipe:
- In `conanfile.py`, replace `cmake_find_package_multi` by `CMakeDeps`
- In `CMakeLists.txt`, add random COMPONENTS in `find_package()`: `find_package(Poco REQUIRED ${POCO_COMPONENTS} Foo Bar CONFIG)`
- Then call `conan create . poco/1.11.1@`, CMake won't complain during configuration of test_package.
With `cmake_find_package_multi`, it fails to find these random components (and it's the expected behavior): `Conan: Component 'Foo' NOT found in package 'Poco'`. It's worth noting that `cmake_find_package_multi` doesn't properly handle `OPTIONAL_COMPONENTS` (it fails also if an optional component is not found, which is not good).

I think that whether check among `<find_or_config_filename>_FIND_COMPONENTS` is performed or not should be controlled in `package_info()` of the recipe itself, not by downstream recipes which are not supposed to have this kind of control and may not know what is the good behavior, since in CMake it's an upstream decision to create config files with components checks (it's not the default but it's recommended: https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#generating-a-package-configuration-file).

Also I see that currently, when `check_components_exist`, COMPONENT is expected to be target name exactly (with the namespace), it's a bad default.

**Proposal**

COMPONENT name should be:
- by default: last string of `cmake_target_name` split by `::` (if it's not namespace, it should be `cmake_target_name`). `cmake_target_name.split("::")[-1]` should handle all cases.
- a new property (`cmake_component_name`?) should allow to define a custom component name, or an array of components (in some specific cases, multiple `COMPONENTS` can point to the same target, see [`FindCURL.cmake`](https://cmake.org/cmake/help/latest/module/FindCURL.html), it means that `COMPONENTS` don't mean "some target" but a feature). Indeed, COMPONENT name is not always the same name than target name (see `SFML` or `OpenCV` for example).
  Why not relying on `cmake_target_aliases` here to indirectly define desired COMPONENTS? Because it would create an undesirable target.

Possible implementation:
- for each component (and if its `cmake_component_name` is an array, loop into this array): set the variable `<cmake_file_name>_<cmake_component_name>_FOUND` to `TRUE`.
- in config file, call `check_required_components(<cmake_file_name>)`

From standard CMake macro (and usually called at the end) in default config files generated by `configure_package_config_file()`:

```cmake
macro(check_required_components _NAME)
  foreach(comp ${${_NAME}_FIND_COMPONENTS})
    if(NOT ${_NAME}_${comp}_FOUND)
      if(${_NAME}_FIND_REQUIRED_${comp})
        set(${_NAME}_FOUND FALSE)
      endif()
    endif()
  endforeach()
endmacro()
```

But basically, config files generated by conan should honor all keywords and recommendations of https://cmake.org/cmake/help/latest/command/find_package.html#basic-signature.
user: SpaceIm
issue_10256: state: open
title: [question] Capturing revisions from multiple source repos
body: The [SCM](https://docs.conan.io/en/1.44/reference/conanfile/attributes.html#scm) feature by design can only be used with the repo containing the recipe. My team would like something similar but we use multiple repos, some quite large.

#8760 advises:

> [...] a hard-coded commit hash for the sources method. The hash can be hard-coded in a few places: 1. the recipe, 2. a text file like conandata.yml and then read from disk and used inside the source() method.

Hard-coding isn't an option since our sources are updated many times each hour. I think we have to roll our own multi-scm feature, either by (a) by writing a script to generate conandata.yml with the revisions baked in; or (b) have the conanfile itself capture the revisions.

The SCM feature does is tantalizingly close to what we need - as I understand it at export time it runs `git rev-parse HEAD` and stores that in conandata.yml. I've taken a similar approach:

`conanfile.py`:
```
# Example of using MultiSourceConanFile

from conans import CMake
from multisource import MultiSourceConanFile, GitSource

class HelloConan(MultiSourceConanFile):
    name = "hello"
    version = "0.1"
    settings = "os", "compiler", "build_type", "arch"

    def build(self):
        cmake = CMake(self)
        cmake.configure(source_folder="hello")
        cmake.build()

    def package(self):
        self.copy("*.a", dst="lib", keep_path=False)

    def get_sources(self):
        return [
            GitSource("https://github.com/conan-io/hello.git", "hello"),
            # ...
        ]
```

`multisource.py`:
```
import os
import subprocess
from typing import List
import yaml
from conans import ConanFile, tools

class GitSource:
    def __init__(self, url, folder):
        self.url = url
        self.folder = folder

    def source(self, revision=None):
        # Run git clone and optionally check out the specified revision
        git = tools.Git(folder=self.folder)
        git.clone(self.url)
        if revision:
            git.checkout(revision)

    def get_revision(self):
        # Find the revision that's currently checked out.
        # Conan calls export() before calling source() so we must be
        # tolerant of the source not yet existing.
        if not os.path.exists(self.folder):
            return None
        return tools.Git(folder=self.folder).get_revision()

class MultiSourceConanFile(ConanFile):
    exports = ["multisource.py"]
    no_copy_source = True

    def get_sources(self) -> List[GitSource]:
        raise NotImplementedError("Override this to return a list of sources")

    def source(self):
        """
        This method does the actual checkout.
        Derived classes should not implement source() but should
        instead implement a get_sources() method that returns a list
        of source objects.
        """

        #
        if self.conan_data:
            source_revisions = self.conan_data.get("source_revisions", {})
        else:
            source_revisions = {}

        for s in self.get_sources():
            s.source(source_revisions.get(s.folder))

    def export(self):
        # Update conandata.yml with the current source revisions.

        source_revisions = {}

        # Assuming that the recipe is stored in a Git repo at the root
        # of the source folder, find the source folder.
        # We assume that export won't be called once the recipe has
        # already been exported.
        source_folder = os.path.dirname(
            subprocess.check_output(
                ["git", "rev-parse", "--show-toplevel"]
            ).decode()
        )

        with tools.chdir(source_folder):
            for s in self.get_sources():
                revision = s.get_revision()
                if revision:
                    source_revisions[s.folder] = revision

        conan_data = self.conan_data or {}
        conan_data["source_revisions"] = source_revisions

        tools.save(
            os.path.join(self.export_folder, "conandata.yml"),
            yaml.dump(conan_data),
        )
```

This works, but there are a couple of smells:
1. You need to run `conan source` before `conan create`, and since `conan source` calls `export()`, the `export()` method itself can't assert that the sources must be present. (For my team that isn't a problem because we're in the habit of using `conan install`/`source`/`build`/`export-pkg` anyway).
2. `conan create` and `conan export` don't take a source folder argument so we have to infer the source folder from the recipe location.

Any guidance for the best way forward here?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: michaelplatingsarm
issue_10245: state: open
title: [question] Conan 2.0 not working with old released packages?
body: Hi,

The documentation here: https://docs.conan.io/en/latest/conan_v2.html
mentions e.g. that:

> - Use the from conan import ConanFile import instead of the legacy from conans ... 
> - Use generators and helpers only from conan.tools.xxxx space. All the other ones are going to be removed.
> - Do not use self.deps_cpp_info, self.deps_env_info or self.deps_user_info. Use the self.dependencies access to get information about dependencies.

Does this mean that old conan packages (created during the 1.x era) can not be used anymore when people start using Conan 2.0?
Will the 2.x conan client throw an error (invalid import etc.) when running e.g. "conan search"/"conan info" from Artifactory?

If this is the case then consider  the following case:
- Release conan packages are created and uploaded to Artifactory and used by customers
- The recipes are part of the module .git repository + using: `revision_mode = "scm"`
- There is no "easy" way to rebuild the released conan packages, one would need to rebuild all past releases including the changes in the recipes for Conan 2.0 support, test those and prepare a new release (bump the patch level version) from each of those.
- Should the older releases be removed from Artifactory if Conan 2.0 is unable to install those packages?
- What if some customers are switching to Conan 2.0 with slower pace so we'd need to support both Conan 1.x and 2.x users at the same time?

I hope that backwards compatibility is supported by Conan 2.0 in the recipes so that older released conan packages published already  
 via Artifactory does not get broken?


user: iiknd
issue_10242: state: open
title: Configure firewall proxy to Conan build system
body: I am trying to compile a SDK released on GitHub to integrate Alexa skills. GitHub link of the SDK is: https://github.com/alexa/alexa-auto-sdk

Readme says that SDK can be compiled using their builder tool which is based on Conan build system. Since my system works under a firewall, I will have to provide proxy config to bypass it for the builder tool to work.

I tried adding in ~/.conan/.conan.conf, but it does not work. I also did not find any documentation on how to configure proxy so that dependencies are downloaded by the package manager.
Can someone please help me where do I add the proxy configuration for Conan build system.


user: alexaagithuber
issue_10238: state: open
title: [question] How to package library with protobuf-generated code, given a generator is also a package
body: What would be a good approach to package protobuf-generated code?

I want to create a package for library which would also contain *.pb.h header files and associated object-files (*.pb.cc) would be a part of my lib. And what bothers me is that client (the one who uses a package as a dependency) might use different version of protobuf. And I want to make sure that library is get compiled on the host in case current project uses different version of protobuf (already have a case protobuf 2.6 (custom one) vs 3.*)

Maybe any idiomatic mechanics exists for generated code in general? Because the same case might come with any other generated tool (lib part + generator part) that is also a conan-package, and for different versions might generate different code which is tied to a library part of the tool's specific version.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: ngrodzitski
issue_10236: state: open
title: [bug] BazelDeps doesn't support Windows
body: Currently the generator for BazelDeps assumes a Posix style environment. 

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: msvc 2019 / 2022
  * Conan version: 1.43.2
  * Python version: 3.?

### Steps to reproduce (Include if Applicable)

Create a simple conanfile.txt that uses the BazelDeps generator on Windows.

Early attempts to fix this are at the PR #10235

user: photex
issue_10234: state: open
title: Improve PremakeDeps and add tests
body: Hi @Enhex 

Yes, the priority is making sure whatever is in the codebase correctly works, before adding more functionality. Then, please, do not add ``PremakeToolchain`` until tests have been added. Same for the "include all" functionality or file (as the addition in Premake is explicit, it might be everything in the same file).

So lets focus on tests first then. I can setup a test for you in next iteration. Lets merge this for 1.44 and open a new issue for 1.45 to add these tests and improve the integration.

_Originally posted by @memsharded in https://github.com/conan-io/conan/issues/10216#issuecomment-1001960075_
user: memsharded
issue_10229: state: open
title: [feature] CMakeDeps generator: merge cpp_info of different recipes if common `cmake_file_name`
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Sometimes, we want to split components of a project in several recipes while the all project shares a unique CMake config file. conan is not robust to this approach, since `CMakeDeps` generator will override the generated config files to keep at the end information of only one recipe.

Therefore I suggest to track common `cmake_file_name` in the dependency graph, and merge targets sharing this `cmake_file_name` in the same CMake config file generared by `CMakeDeps`, regardless of their recipe origin.

Projects which would benefit of this feature (if they were modularized in conan): Boost, Qt, msgpack
user: SpaceIm
issue_10225: state: open
title: [question] How to prevent dependencies from being propagated?
body: I have a recipe with a number of dependencies. Dependent projects now naturally link against these dependencies. But in this particular case I don't want that. Not even if someone uses `CONAN_LIBS` or the files created by a Conan generator.

In the `package_info` I have already set `self.cpp_info.libs = []` to not propagate the libraries of this recipe. 
But how can I additionally also remove all dependencies?
user: sboehmann
issue_10220: state: open
title: [question] different CMake builds in one conanfile
body: Hello - I hope this is the right place to ask this question!

I am currently trying to build and package [pdf2htmlEX](https://github.com/pdf2htmlEX/pdf2htmlEX) to consume it later in [my CMake project](https://github.com/opendocument-app/OpenDocument.core) as a dependency for mobile and desktop.

pdf2htmlEX depends on poppler and fontforge but not in a usual way. It also wants to access "private" headers which are not exported in a packaged poppler version.

So I wondered if it might be easier to build those dependencies in my conanfile as a pre-build step for pdf2htmlEX.

My question is then: Has this been done before and is there a standard way for doing that?
Or do you see any other solution that would not result in a big change of pdf2htmlEX?

Thank you!
user: andiwand
issue_10218: state: open
title: [bug] Meson build helper overrides "default_library" option
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 21.10
  * Compiler+version: gcc 11.2.0-7ubuntu2
  * Conan version: 1.43.1
  * Python version: 3.9.7

### Steps to reproduce (Include if Applicable)
 1. Set up a conanfile that uses the Meson build helper (the [documented example](https://docs.conan.io/en/latest/reference/build_helpers/meson.html#example) is fine)
 2. In the meson.build, set `'default_library=static'` in the project `default_options`
 3. Run `conan build`

Expected result: `library` targets will be built as static libraries

Actual result: `library` targets are built as shared libraries

### Discussion
This happens because of [this code in meson.py](https://github.com/conan-io/conan/blob/develop/conans/client/build/meson.py#L66):

```
# shared
shared = self._so("shared")
self.options['default_library'] = "shared" if shared is None or shared else "static"
```

This means that Meson is always given a `-Ddefault_library=shared` flag, overriding the `meson.build` file, even if the `shared` Conan option is not set (or does not even exist).

For comparison, ather Conan-to-Meson option translations in this file don't override unless they're actively set in Conan, for example the PIC setting:

```
fpic = self._so("fPIC")
if fpic is not None:
    shared = self._so("shared")
    self.options['b_staticpic'] = "true" if (fpic or shared) else "false"
```

Naively, I'd think the `static` option translation would work similarly.

Regardless, I'd say this behavior should absolutely be documented in the Meson build helper page, ideally along with other Conan options and how they translate to Meson?
user: egnor
issue_10217: state: open
title: [feature] Eliminate Hidden Dependencies
body: One of the things I like most about Conan is that dependencies and versions are explicitly stated in the recipe.  This makes it really easy to hand off a recipe to someone else and have confidence that they can build it too.

The big exception to this are many of the fundamental build requirements.  Most all of the recipes that I have looked at in conan center have build requirements that are not in the recipe.  For example, the recipe for yaml-cpp, https://conan.io/center/yaml-cpp?tab=recipe, requires cmake to build but it is not included as a build requires.  It appears that the expectation is that either a profile is used that specifies a cmake version or a system installed version is already present on the system.  No information is present in the recipe about compatible cmake versions.

I ran into a problem where my project needs a more recent version of cmake than what is available in the system repos.  So a user must either build a newer version from source or use a profile with an adequate (but undocumented) version of cmake.

I understand some of the reasons for not wanting to include these tools in the recipes.  It would be annoying to have to update every the versions of cmake, make, etc in every single recipe every time that a new version comes out and would lead to version conflicts when some recipes are updated and others aren't.

### Proposal
I would propose a simple addition to the profile files that I believe can simplify the use and management of these requirements.  A new section could be introduced called [package_versions].  Much like the build requirements section, the user could specify packages and versions to use.  The key difference would be that the package versions listed would only be used if a recipe included it.
For example
```
[build_requires]
cmake/3.21.4
```
Make cmake a requirement of all packages built with this profile, which can lead to circular dependencies (cmake depends on openssl which now thinks that it depends on cmake if I use this profile).  
This could be replaced with:
```
[package_versions]
cmake/3.21.4
```
The desired behavior would be that only packages that have a requires or build_requires of cmake will be overrided to use this version.  Thus yaml-cpp, could include cmake as a dependency in its conanfile.py, and would use the specified version when built with our profile.  openssl, on the other hand, would not contain cmake as a dependency and would not be impacted.

With this feature in place, it would be desirable to update recipes to include their dependencies on cmake, make, meson, etc.  I believe that this would be good, because the recipes would be explicit about all of the dependencies used, thus making them more portable.  This feature could be quite powerful when coupled with the compatible_packages feature to make it easy to check that the versions specified in the profile is compatible with all of the packages.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: jsallay
issue_10215: state: open
title: [question] build_requires with build and host profiles
body: I have a project where I am using separate build and host profiles to cross compile (using conan create).  My project uses cmake, so I included that in the build_requires section of the build profile.  I discovered today, that this has been using a system installed version of cmake instead of a conan version.  Conan appears to ignore the build requires in the build profile.

After doing some testing I discovered that if I include the build_requires in the host profile, then conan will then download and use the requested version of cmake.  I find this very confusing because I am wanting a cmake package that is specific to my build profile settings.  I'm not sure if this is a bug or expected behavior.

In the section on build/host context it says "The build context ... typically includes all the dev tools like CMake."  It seems odd to me that I would have to declare info for the build context in the host profile.  

How do I know what belongs in the build profile vs the host profile?  I can find examples of host profiles in the docs, but can't find any examples of build profiles.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: jsallay
issue_10210: state: open
title: How to set executable path of compiler provided by [build_requires] in profile
body: Hello
I am trying to cross compile my project for arm.
I have packaged the linaro gcc toolchain in a package of its own.

I have put the new linaro package in the build_requires section of my arm host profile.
But how can the linaro package "communicate" to the profile where the compiler is located so that the profile can set the "CC" variable.

I have tried setting everything in the package_info() method of the linaro package, but the information does not propagate to the profile and my project, resulting in conan/cmake trying to autodetect the compiler and thus finding my installed gcc.

In the ideal world I would like all info about where the compiler is and where the sysroot is to be located in the linaro package itself as this is the one with the knowledge. And then only let my profile or project conanfile set the compiler flags.

I fear that there are concepts within conan that I have completely misunderstood.
Help is appreciated!

Here is relevant files:
linaro conanfile.py:
```
class LinaroGccConan(ConanFile):
    name = "linaro-gcc"
    version = "8.3.0"
    settings = "os", "arch"
    description = "<Description of LinaroGcc here>"
    url = "None"
    license = "None"
    author = "None"
    topics = None

    def build(self):
        url = ("https://armkeil.blob.core.windows.net/developer/Files/downloads/gnu-a/8.3-2019.03/binrel/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf.tar.xz")
        tools.get(url)
        
    def package(self):
        self.copy("*")

    def package_info(self):
        path = os.path.join(self.package_folder, "gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf")

        self.env_info.CC = os.path.join(path, "bin/arm-linux-gnueabihf-gcc")
        self.env_info.CXX = os.path.join(path, "bin/arm-linux-gnueabihf-g++")
        self.env_info.SYSROOT = os.path.join(path, "arm-linux-gnueabihf/libc")
```
Please note that the above `CC` and `CXX` variables seem to have no effect.

host profile:
```
[settings]
arch=armv7hf
os=Linux
build_type=Debug

compiler=gcc
compiler.version=8.3
compiler.libcxx=libstdc++11

[build_requires]
linaro-gcc/8.3.0
```

Rgds
Klaus
user: klausholstjacobsen
issue_10206: state: open
title: [question] ERROR: boost/1.77.0: Error in build() method, line 829 
body: I am trying to install boost 1.77 on M1 in docker container with debian 11.

conanfile
`[requires]
sol2/3.2.3
mongo-cxx-driver/3.6.6
boost/1.77.0

[generators]
cmake`

CMakeLists
`cmake_minimum_required(VERSION 3.1)

project(rncore LANGUAGES CXX)

add_executable(rncore src/main.cpp)
add_definitions("-std=c++14")

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -W -Wall -Wextra -Werror -Wno-unused-parameter")

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()`

[log.txt](https://github.com/conan-io/conan/files/7739504/log.txt)


user: mayerdev
issue_10198: state: open
title: [question] pass common compiler/linker flags for native builds
body: Hello!

I'm trying to configure conan (version 1.43.0) to build packages on Windows 10 using MS Visual Studio 2017. It turns out that I need to add few flags to the Release mode of the packages (namely "/Zi" for C/C++ and "/debug" for linkers, otherwise produced PDB files are unusable for me, and Debug and RelWithDebInfo modes have their own problems). How can I do this?

It looks like there is no environment variables controlling this, and most usable way is to use custom CMake toolchain file. I see a lot of references on how to use it, but for native builds (Windows 10 for Windows 10) nothing is referencing them, so my setting
```
[conf]
tools.cmake.cmaketoolchain:user_toolchain={{ os.path.join(profile_dir, "../../toolchains/whatever.cmake") }}
```
in my profile (I copied that from another question, when cross-compilation was used) is not producing even a warning, and no traces of toolchain files in the build folder. What would be a recommended ways to pass flags to all built packages? Maybe some extra environment variables?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: mbel0
issue_10193: state: open
title: [bug] circular dependency of build tools if used in build profile
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu
  * Compiler+version: gcc-10
  * Conan version: 1.43.0
  * Python version: 3.8.10

### Steps to reproduce (Include if Applicable)
myprofile
```
[settings]
arch=x86_64

compiler=clang
compiler.libcxx=libstdc++11
compiler.version=13

os=Linux

[options]

[build_requires]
build_tool_1/1.0.0@dummy/dummy
build_tool_2/1.0.0@dummy/dummy

[env]
MYPROFILEVAR="myval"

[conf]
```


conanfile_build_tool_1.py
```
from conans import ConanFile, CMake
import os

class pkg(ConanFile):
    name = "build_tool_1"
    version = "1.0.0"
    settings = "os", "arch"
```


conanfile_build_tool_2.py
```
from conans import ConanFile, CMake
import os

class pkg(ConanFile):
    name = "build_tool_2"
    version = "1.0.0"
    settings = "os", "arch"

    def build_requirements(self):
        self.build_requires("build_tool_1/1.0.0@dummy/dummy")
```


conanfile_consumer.py
```
from conans import ConanFile, CMake
import os

class pkg(ConanFile):
    name = "consumer"
    version = "1.0.0"
    settings = "os", "arch", "compiler", "build_type"

```


steps to reproduce:
```
conan export conanfile_build_tool_1.py dummy/dummy
conan export conanfile_build_tool_2.py dummy/dummy

conan create  conanfile_consumer.py -pr:b=./myprofile -pr:h=./myprofile --build=consumer --build=build_tool_1 --build=build_tool_2
issue:
```




### Logs (Executed commands with output) (Include/Attach if Applicable)

```
ERROR: Loop detected in context build: 'build_tool_1/1.0.0@dummy/dummy' requires 'build_tool_2/1.0.0@dummy/dummy' which is an ancestor too
```
user: thorsten-klein
issue_10189: state: open
title: [question] Is there a way to freeze dependency recipe revisions into the recipe upon export?
body: Here's a demonstration of the problem I'm having while trying to set up CI:

```sh
# Create a consumer -> dependency chain
conan new dependency/1.0 --bare
conan create .

conan new consumer/1.0 --bare
echo "    requires = [('dependency/[>=1.0]', 'private')]" >> conanfile.py
conan create .

# Create a new version of dependency
conan new dependency/2.0 --bare
conan create .

# It is no longer possible to install consumer from a binary
conan install consumer/1.0@
```

The `conan install` command fails with `ERROR: Missing prebuilt package for 'consumer/1.0'` because the package ID for the prebuilt binary is based on `dependency/1.0`. The recipe includes a version range which is re-evaluated using `dependency/2.0` and therefore the package would need to be rebuilt from source.

What I would like is a way to bake the resolved dependencies (version numbers and recipe revisions) into the exported recipe, similar to how the `scm` attribute with `revision: auto` will bake the SCM hash into the exported recipe. Then the `conan install` command above would know to fetch the recipe for `dependency/1.0` and therefore find the existing package. Is there a way to accomplish this?

This example uses version ranges, but the same thing happens when using an alias package which is updated over time, or creating new recipe revisions of dependencies.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: tmatheson-arm
issue_10188: state: open
title: Cross-compiling with cmake produces "Detected a mismatch for the compiler version between your conan profile"
body: Hello

I have a small example project set-up to use conan packages for cross compiling with cmake.

Here's my CMakeLists.txt:

```
cmake_minimum_required(VERSION 3.10.0 FATAL_ERROR)
include(${CMAKE_CURRENT_LIST_DIR}/conan.cmake)

conan_cmake_install(
        PATH_OR_REFERENCE ${CMAKE_CURRENT_LIST_DIR}/conanfile.txt
        PROFILE_HOST ${CMAKE_CURRENT_LIST_DIR}/profile.armhf-gcc8
        PROFILE_BUILD ${CMAKE_CURRENT_LIST_DIR}/profile.amd64-gcc7
        BUILD missing
)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)

project(conan-test LANGUAGES CXX)

conan_basic_setup(TARGETS NO_OUTPUT_DIRS)
```

my host profile in profile.armhf-gcc8:
```
[settings]
arch=armv7hf
os=Linux
build_type=Debug

compiler=gcc
compiler.version=8.3
compiler.libcxx=libstdc++11

[build_requires]
linaro-gcc/8.3.0
```

my build profile in profile.amd64-gcc7:
```
[settings]
arch=x86_64
os=Linux
build_type=Debug

compiler=gcc
compiler.version=7.5
compiler.libcxx=libstdc++11
```

my project conanfile.txt:
```
[requires]

[generators]
cmake

[options]
```

I have removed all required packages from the conanfile.txt for simplicity....this does not change the error
I have packaged linaro-gcc 8.3 into its own package and used it in build_requires as shown above.

The conanfile.py for my linaro package looks like this:
```
from conans import ConanFile, tools
import os

class LinaroGccConan(ConanFile):
    name = "linaro-gcc"
    version = "8.3.0"
    settings_build = "os", "arch"
    description = "<Description of LinaroGcc here>"
    url = "None"
    license = "None"
    author = "None"
    topics = None
    exports_sources = "toolchain.cmake"

    def build(self):
        url = ("https://armkeil.blob.core.windows.net/developer/Files/downloads/gnu-a/8.3-2019.03/binrel/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf.tar.xz")
        tools.get(url)
        
    def package(self):
        self.copy("*")

    def package_info(self):
        path = os.path.join(self.package_folder, "gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf")
        self.env_info.PATH.append(os.path.join(path, "bin"))
        self.env_info.CC = os.path.join(path, "bin/arm-linux-gnueabihf-gcc")
        self.env_info.CXX = os.path.join(path, "bin/arm-linux-gnueabihf-g++")
        self.env_info.SYSROOT = os.path.join(path, "arm-linux-gnueabihf/libc")
        self.env_info.CONAN_CMAKE_SYSROOT = os.path.join(path, "arm-linux-gnueabihf/libc")
        self.env_info.CONAN_CMAKE_FIND_ROOT_PATH = os.path.join(path, "arm-linux-gnueabihf/libc")
        self.env_info.CONAN_CMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "NEVER"
        self.env_info.CONAN_CMAKE_FIND_ROOT_PATH_MODE_LIBRARY = "ONLY"
        self.env_info.CONAN_CMAKE_FIND_ROOT_PATH_MODE_INCLUDE = "ONLY"
        self.env_info.CONAN_CMAKE_FIND_ROOT_PATH_MODE_PACKAGE = "ONLY"

        self.env_info.CFLAGS   = "-fPIC            -mfloat-abi=hard -O0 -ggdb -Wall -Wno-psabi -Wno-unused-variable -Wno-unused-value -Wno-parentheses -Wno-format -Wno-sign-compare -Wno-deprecated-declarations -fvisibility=hidden -rdynamic"
        self.env_info.CXXFLAGS = "-fPIC -std=c++11 -mfloat-abi=hard -O0 -ggdb -Wall -Wno-psabi -Wno-unused-variable -Wno-unused-value -Wno-parentheses -Wno-format -Wno-sign-compare -Wno-deprecated-declarations -fvisibility=hidden -rdynamic"
```

When I run cmake it detects my native gcc compiler instead of recognising the linaro compiler configured, and produces the error shown in the subject from conanbuildinfo.cmake.

The "funny" things is that if I start to include packages in the [requires] section of conanfile.txt such as boost and openssl they are fetched and compiled just fine. It seems that the compiler config provided to/by conan does not carry over to cmake. I thought that this was exactly what conanbuildinfo.cmake is there for.

Help would be appreciated.
Thanks

Rgds 
Klaus

user: klausholstjacobsen
issue_10184: state: open
title: CMake,Conan,GithubActions,MacOS - Unable to build TBB library
body: I am experimenting with building a CI pipeline for my project https://github.com/suhasghorp/jason-cpp-starter
As part of the build, I am requiring Conan to download and install TBB library https://conan.io/center/tbb?version=2020.3
The Github Actions workflows build Windows and Linux project successfully and but not Mac OS.

I get following error only on MacOS:
/Applications/Xcode_13.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/stdlib.h:93:15: fatal error: 'stdlib.h' file not found

I am attaching the Build Log (line # 2341 shows the error)

While researching possible solutions, I cam across thread https://stackoverflow.com/questions/65392271/macos-big-sur-11-1-cant-find-stdlib-h-w but I am not sure how to implement the solution suggested here.

Any help is greatly appreciated.
Let me know if you need any additional details.

[3_build (macos-latest).txt](https://github.com/conan-io/conan/files/7727808/3_build.macos-latest.txt)


user: suhasghorp
issue_10179: state: open
title: [question] How to pass options from test_package to package build?
body: - [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- I'm using conan 1.43 binary on windows 10

Hi, I'm having trouble passing option values from test_package to package build when calling `conan create`.

My packaging scenario is I have a repository with code that is built with msvc, but some parts are used as firmware code built with custom compilers. I'd like to have one recipe for both, which I'm trying to achieve by adding compilers to `.conan/settings.yml` and additionally with option `fw_platform` .

Simplified `conanfile.py`
```python
class PackageConanFile(ConanFile):
    name = 'my_package'
    settings = 'os', 'compiler', 'build_type', 'arch'

    options = {
        'fw_platform': [None, 'platform_a', 'platform_b'],
    }

    def log_value(self):
        func_name = inspect.stack()[1].function
        logging.info(f"""{type(self).__name__ + "." + func_name}()
            fw_platform={str(self.options.fw_platform)}""")

    def config_options(self):
        self.log_value()

    def configure(self):
        self.log_value()

    def validate(self):
        self.log_value()

    def build(self):
        self.log_value()
```

Simplified `test_package/conanfile.py`
```python
class PackageTestConanFile(ConanFile):
    name = 'my_package_test'
    settings = 'os', 'compiler', 'build_type', 'arch'

    options = {
        'fw_platform': [None, 'platform_a', 'platform_b'],
    }

    def log_value(self):
        func_name = inspect.stack()[1].function
        logging.info(f"""{type(self).__name__ + "." + func_name}()
            fw_platform={str(self.options.fw_platform)}""")

    def config_options(self):
        self.log_value()

    def configure(self):
        self.log_value()

    def validate(self):
        self.log_value()

    def test(self):
        self.log_value()

    def build(self):
        self.log_value()
```

After calling `conan create . my_package/1.0.0@maciek/devel -o fw_platform=platform_a` from repo's root I get following log:
```
INFO:root:PackageTestConanFile.config_options()
            fw_platform=platform_a
INFO:root:PackageTestConanFile.configure()
            fw_platform=platform_a
INFO:root:PackageConanFile.config_options()
            fw_platform=None
INFO:root:PackageConanFile.configure()
            fw_platform=None
INFO:root:PackageConanFile.validate()
            fw_platform=None
INFO:root:PackageTestConanFile.validate()
            fw_platform=platform_a
INFO:root:PackageConanFile.build()
            fw_platform=None
INFO:root:PackageTestConanFile.config_options()
            fw_platform=platform_a
INFO:root:PackageTestConanFile.configure()
            fw_platform=platform_a
INFO:root:PackageTestConanFile.build()
            fw_platform=platform_a
INFO:root:PackageTestConanFile.test()
            fw_platform=platform_a
```

Could you explain why value of `fw_platform` is set in test_package, but in `package` I get `None`? 

As far as I understood `None` value allows the option to have no value. I'd like to keep it that way instead deleting option, because I want to use it on msvc scenario to specify platform simulation.
user: imaciejjablonski
issue_10172: state: open
title: `conan get package/version@user/channel conan_export.tgz` retrieves broken file
body: When using the above command to retrieve the `conan_export.tgz`, I receive a file that is too short and is not recognized as a tar.gz file.

```
> conan get -r my-remote -raw package/version@user/channel conan_export.tgz | file -
/dev/stdin: Applesoft BASIC program data, first line number 8
> conan get -r my-remote -raw package/version@user/channel conan_export.tgz | wc -c
1105
```
While retrieving the file from the artifactory web UI, I get
```
> file conan_export.tgz 
conan_export.tgz: gzip compressed data, was "conan_export.tgz", max compression, original size modulo 2^32 20480
> wc -l conan_export.tgz
1870 conan_export.tgz
```

Taking a brief look at the `hexdump -C` from both, all characters >= 0x80 are just stripped out! 
some characters


Wow, I guess, you should remove the 7bit-filter with `-raw`! Or in general when `get`ing files?

Current version:
```
> conan -v
Conan version 1.43.0
```

user: tvogel
issue_10169: state: open
title: [bug] conan remove outdated failed
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: Visual Studio
  * Conan version: 1.43.0

### Steps to reproduce (Include if Applicable)
 conan remove "*" -o -f

### Logs (Executed commands with output) (Include/Attach if Applicable)

WARN: No matching packages to remove for automake/1.16.2
WARN: No matching packages to remove for backward-cpp/1.5
WARN: No matching packages to remove for backward-cpp/1.6
WARN: No matching packages to remove for brotli/1.0.9
WARN: No matching packages to remove for bzip2/1.0.8
WARN: No matching packages to remove for ceres-solver/2.0.0
WARN: No matching packages to remove for cmake/3.20.2
WARN: No matching packages to remove for cmake/3.20.4
WARN: No matching packages to remove for cmake/3.21.3
WARN: No matching packages to remove for coin-lemon/1.3.1
WARN: No matching packages to remove for core_builder_windows_image/v2.0.5-3-ga3a92e1cb@gitlab/testing
WARN: No matching packages to remove for core_builder_windows_image/v2.0.6-1-g3fa21d705@gitlab/release
WARN: No matching packages to remove for core_builder_windows_image/v2.0.6-2-gccbf28f7c@gitlab/testing
WARN: No matching packages to remove for core_builder_windows_image/v2.0.7@gitlab/release
WARN: No matching packages to remove for core_builder_windows_image/v2.0.8@gitlab/release
WARN: No matching packages to remove for core_builder_windows_image/v2.0.8-2-g85f4976a3@gitlab/testing
ERROR :search.py      [151]: There is no ConanInfo: D:\.conan\cfc0e1\1\conaninfo.txt [2021-12-13 14:56:27,845]
WARN: No matching packages to remove for diligent-core/ca661f5@gitlab/release
WARN: No matching packages to remove for diligent-core/2.5.1@andrei/test
WARN: No matching packages to remove for diligent-engine/d72a87fa@gitlab/release
WARN: No matching packages to remove for dirent/1.23.2
WARN: No matching packages to remove for draco/1.3.6
WARN: No matching packages to remove for draco/1.4.3
WARN: No matching packages to remove for easyexif/1.0
WARN: No matching packages to remove for eigen/3.3.8
WARN: No matching packages to remove for eigen/3.3.9
WARN: No matching packages to remove for embree3/3.12.0
WARN: No matching packages to remove for expat/2.4.1
WARN: No matching packages to remove for freetype/2.10.4
WARN: No matching packages to remove for freetype/2.11.0
WARN: No matching packages to remove for gflags/2.2.2
WARN: No matching packages to remove for glew/2.1.0
WARN: No matching packages to remove for glew/2.2.0
WARN: No matching packages to remove for glib/2.68.1
WARN: No matching packages to remove for glib/2.68.3
ERROR :search.py      [151]: There is no ConanInfo: D:\.conan\23f3a8\1\conaninfo.txt [2021-12-13 14:56:52,182]
WARN: No matching packages to remove for glib/2.69.1
WARN: No matching packages to remove for glib/2.69.2
ERROR :search.py      [151]: There is no ConanInfo: D:\.conan\8fddad\1\conaninfo.txt [2021-12-13 14:56:54,231]
WARN: No matching packages to remove for glib/2.70.0
WARN: No matching packages to remove for glib/2.70.1
WARN: No matching packages to remove for glm/0.9.9.8
WARN: No matching packages to remove for glog/0.4.0
WARN: No matching packages to remove for glslang/8.13.3559
Traceback (most recent call last):
  File "conans\client\command.py", line 2232, in run
  File "conans\client\command.py", line 1199, in remove
  File "conans\client\conan_api.py", line 93, in wrapper
  File "conans\client\conan_api.py", line 884, in remove
  File "conans\client\remover.py", line 201, in remove
  File "conans\paths\package_layouts\package_cache_layout.py", line 187, in recipe_manifest
  File "conans\model\manifest.py", line 91, in load
  File "conans\util\files.py", line 232, in load
FileNotFoundError: [Errno 2] No such file or directory: 'D:\\.conan\\data\\glslang\\11.7.0\\_\\_\\export\\conanmanifest.txt'

ERROR: [Errno 2] No such file or directory: 'D:\\.conan\\data\\glslang\\11.7.0\\_\\_\\export\\conanmanifest.txt'

user: AndreyMlashkin
issue_10155: state: open
title: [bug] `self.copy` in a repository with a symlink starts to self-recurse and lead to high cpu/mem usage
body: I am still trying to trigger this. 

The repository https://github.com/gabyx/conan-hang 
should at the end trigger the `self.copy` recursion. So far it does not:
with
`cd tests/a && conan export . demo/testing`

If seen already bug reports in this direction which might be caused really by this.
I could trigger it in my setup by doing `self.copy("asd")` with an argument which was not even sensical.
That alone already triggered the deadly self-recursion.

Maybe that function gives you a hint where the problem might lie.


user: gabyx
issue_10148: state: open
title: [question] conan install behavior with path vs. reference
body: My goal is to achieve the behavior of `conan create` but with the created packaged being created at a defined location instead of the local cache.

I looked at the `conan install` command but see different behavior when using paths or references.

What works is:
```
conan create . user/channel -o my_package:some_setting=True --build outdated
conan install my_package/0.0.1@user/channel -o my_package:some_setting=True --install-folder=pkg_folder
```
Inside `pkg_folder/` is see the expected binaries of `my_package`.

But when using:
```
conan install . -o my_package:some_setting=True --install-folder=pkg_folder --build outdated
```
Inside `pkg_folder/` i only see files like `conanbuildinfo.cmake`, `conaninfo.txt` but nothing has been built.

The [documentation](https://docs.conan.io/en/latest/reference/commands/consumer/install.html) of `conan install` says:
```
conan install executes methods of a conanfile.py in the following order:

    config_options()
    configure()
    requirements()
    package_id()
    package_info()
    deploy()

Note this describes the process of installing a pre-built binary package. If the package has to be built, conan install --build executes the following:

    config_options()
    configure()
    requirements()
    package_id()
    build_requirements()
    build_id()
    system_requirements()
    source()
    imports()
    build()
    package()
    package_info()
    deploy()
```
I thought using `--build` would then call the method chain as documented but it looks like it does not when a path is used as argument.

I need this because with `conan create` the `deploy()` method is called to copy package dependencies alongside the binaries. This way, the final product can be shipped.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: ineb
issue_10144: state: open
title: [feature] Remove or increase length limit for package version?
body: <!-- What is your suggestion? Please be as specific as possible! -->
We have a setup for internal development of a library where git branch is part of the package version value.
Error when using conan 1.35.1 says:
```
ERROR: Error parsing lockfile '<...>': 
Value provided for package version, '<long version containing branch name>' (type Version), is too long. 
Valid names must contain at most 51 characters.
```
Is there a technical reason for such a strict limit? If there isn't, is increasing the limit or removing entirely an options? It imposes a restriction on conan usages.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: artem-ogre
issue_10140: state: open
title: [bug] Conan returns incorrect path for Apple Framework when multiple components have the same framework name
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: macOS 12.0.1 (21A559)
  * Compiler+version: Apple clang version 13.0.0 (clang-1300.0.29.3) - Xcode 13.1 (latest)
  * Conan version: 1.42.2
  * Python version: Python 3.9.9

### Description

Since CMake [does not yet natively support XCFrameworks](https://gitlab.kitware.com/cmake/cmake/-/issues/21752) I'm looking for alternative solutions to integrating Apple's new format into our existing codebase.
After some research, I determined that [Conan Components](https://docs.conan.io/en/latest/creating_packages/package_information.html#using-components) together with the `cmake_find_package` generator are a perfect fit for the task at hand.
I will not go in detail what XCFrameworks are, but for anyone interested, the following blog post has a lot of useful info: [PSPDFKit - Supporting XCFrameworks](https://pspdfkit.com/blog/2020/supporting-xcframeworks/).
An XCFramework is basically a folder (+ some metadata) containing different architecture builds (slices) of a framework. It has the following structure:

```
ExampleFramework.xcframework
├── Info.plist
├── ios-arm64
│   └── ExampleFramework.framework
├── ios-x86_64-simulator
│   └── ExampleFramework.framework
├── tvos-arm64
│   └── ExampleFramework.framework
├── tvos-arm64_x86_64-simulator
│   └── ExampleFramework.framework
├── watchos-arm64_32_armv7k
│   └── ExampleFramework.framework
└── watchos-arm64_x86_64-simulator
    └── ExampleFramework.framework
```

The `conanfile.py` for Example Framework looks like this (simplified):

```python
def build(self):
    # Build all slices
    for platform in self._supported_platforms:
        archive_cmd = f"xcrun xcodebuild archive -quiet -project ExampleProject.xcodeproj -scheme 'ExampleFramework' -configuration {self.settings.build_type} -archivePath '{platform}.xcarchive'"
        self.run(archive_cmd)

    # Combine all slices
    create_cmd = f"xcrun xcodebuild -create-xcframework <args> -output '{self.name}.xcframework'"
    self.run(create_cmd)

# "Component" package
def package_info(self):
    self.cpp_info.name = self.name #"ExampleFramework"

    for platform in self._supported_platforms:
        arch_dir = self._arch_for_platform[platform]
        framework_path = os.path.join(self.package_folder, f"{self.name}.xcframework", arch_dir)

        self.cpp_info.components[platform].names["cmake_find_package"] = platform
        self.cpp_info.components[platform].frameworkdirs = [framework_path]
        self.cpp_info.components[platform].frameworks = [self.name]
```

For each supported architecture of the XCFramework, a component is defined with the name of the platform, e.g: iphoneos, iphonesimulator, macosx (names used by Xcode).
__NOTE:__ The framework name specified in `self.cpp_info.components[platform].frameworks` is identical for every component (`self.name`) and this __can't__ be trivially renamed (or symlinked) to e.g. `ExampleFramework_macosx.framework`.

The test_package is a bare minimum CMake project integrating this, with the following `CMakeLists.txt`:

```cmake
cmake_minimum_required(VERSION 3.1)
project(PackageTest)

include(CMakePrintHelpers)
set(CMAKE_C_FLAGS "-fmodules")
set(CMAKE_VERBOSE_MAKEFILE ON)

# cmake_find_package generator required
find_package(ExampleFramework REQUIRED COMPONENTS macosx)

add_executable(example example.m)
target_link_libraries(example ExampleFramework::macosx)
```

Contrary to expectations, running `conan create` yields the following link error:

```
/Applications/CMake-3.21.2.app/Contents/bin/cmake -E cmake_link_script CMakeFiles/example.dir/link.txt --verbose=1
/Applications/Xcode-13.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -fmodules -O3 -DNDEBUG -arch x86_64 -isysroot /Applications/Xcode-13.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk -mmacosx-version-min=10.14 -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/example.dir/example.m.o -o example -F/Users/user/.conan/data/ExampleFramework/0.1.0/user/testing/package/<package-id>/ExampleFramework.xcframework/ios-arm64  -Wl,-rpath,/Users/user/.conan/data/ExampleFramework/0.1.0/user/testing/package/<package-id>/ExampleFramework.xcframework/ios-arm64 -framework ExampleFramework
ld: warning: ignoring file /Users/user/.conan/data/ExampleFramework/0.1.0/user/testing/package/<package-id>/ExampleFramework.xcframework/ios-arm64/ExampleFramework.framework/ExampleFramework, building for macOS-x86_64 but attempting to link with file built for iOS-arm64
Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_TestClass", referenced from:
      objc-class-ref in example.m.o
ld: symbol(s) not found for architecture x86_64
```

It is very interesting to note that __although__ we specified the __macosx__ component, what `FindExampleFramework.cmake` configured was actually the path leading to the __iphoneos__ framework in the subfolder `ios-arm64`.

After a bit of debugging, by inspecting the variables defined by the custom FindExampleFramework.cmake, we observe the following:
- ✅ `ExampleFramework_macosx_FRAMEWORK_DIRS: /Users/user/.conan/data/ExampleFramework/0.1.0/user/testing/package/<package-id>/ExampleFramework.xcframework/macos-arm64_x86_64`
- ❌ `ExampleFramework_macosx_LINK_LIBS: /Users/user/.conan/data/ExampleFramework/0.1.0/user/testing/package/<package-id>/ExampleFramework.xcframework/ios-arm64/ExampleFramework.framework`
- ❌ `ExampleFramework_macosx_LIBS_FRAMEWORKS_DEPS: /Users/user/.conan/data/ExampleFramework/0.1.0/user/testing/package/<package-id>/ExampleFramework.xcframework/ios-arm64/ExampleFramework.framework`

and from this, the target property is also incorrect:
❌ `ExampleFramework::macosx.INTERFACE_LINK_LIBRARIES = "/Users/user/.conan/data/ExampleFramework/0.1.0/user/testing/package/<package-id>/ExampleFramework.xcframework/ios-arm64/ExampleFramework.framework;$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,SHARED_LIBRARY>:>;$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,MODULE_LIBRARY>:>;$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,EXECUTABLE>:>"`

### Solution

It seems that Conan's cmake_find_package generator cannot deal with different components declaring the same framework name. I have traced the behavior to the macro `conan_find_apple_frameworks` in `conans/client/generators/cmake_find_package_common.py`.
Specifically, it checks `if(CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND)` but this global variable doesn't take the different `FRAMEWORKS_DIRS` given to the macro, which can be a disjoint-sets between different components.

The easiest solution to this is to add an `unset(CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND CACHE)` immediately before the `find_library` call.
Personally, I think this is acceptable, as the macro throws a `FATAL_ERROR` if a framework isn't found.

From CMake's [find_library documentation](https://cmake.org/cmake/help/latest/command/find_library.html):
> If the library is found the result is stored in the variable and the search will not be repeated unless the variable is cleared.

I verified that this works as expected by monkey-patching the macro in `test_package/conanfile.py`:
```python
import textwrap
from conans.client.generators.cmake_find_package_common import CMakeFindPackageCommonMacros
CMakeFindPackageCommonMacros.apple_frameworks_macro = textwrap.dedent("""
    macro(conan_find_apple_frameworks FRAMEWORKS_FOUND FRAMEWORKS FRAMEWORKS_DIRS)
        if(APPLE)
            foreach(_FRAMEWORK ${FRAMEWORKS})
                # BUGFIX: Different components with the same framework name should still attempt to find the library
                unset(CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND CACHE)

                # https://cmake.org/pipermail/cmake-developers/2017-August/030199.html
                find_library(CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND NAME ${_FRAMEWORK} PATHS ${FRAMEWORKS_DIRS} CMAKE_FIND_ROOT_PATH_BOTH)
                if(CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND)
                    list(APPEND ${FRAMEWORKS_FOUND} ${CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND})
                else()
                    message(FATAL_ERROR "Framework library ${_FRAMEWORK} not found in paths: ${FRAMEWORKS_DIRS}")
                endif()
            endforeach()
        endif()
    endmacro()
""")
```

A more elaborate solution would require defining separate `CONAN_FRAMEWORK_` variables for each component, and e.g. passing the component name to this function as a suffix.

In any case, I cannot see a reason why this use-case shouldn't be supported (same framework name in different components) and it would certainly make the lives of all Apple devs using Conan much easier in the future.

I'll be very happy to provide more information and code if necessary, as well as answer any questions that might arise.
user: T1T4N
issue_10134: state: open
title: conanfile.py leads to ERROR 2 with cmake build
body: not sure what's going on in my build on the Linux platform. not sure what the core message of this error really is.

    [2021-12-06T10:55:55.153Z] some_dependent_item/2.0.7@some_user/stable: Retrieving package <some_lengthy_package_id> from remote 'remote-server-space'
    [2021-12-06T10:56:06.354Z] CMakeFiles/my_module_Test.dir/build.make:481: recipe for target 'bin/my_module_Test' failed
    [2021-12-06T10:56:06.356Z] make[2]: *** [bin/my_module_Test] Error 139
    [2021-12-06T10:56:06.356Z] make[2]: *** Deleting file 'bin/my_module_Test'
    [2021-12-06T10:56:06.356Z] CMakeFiles/Makefile2:195: recipe for target 'CMakeFiles/my_module_Test.dir/all' failed
    [2021-12-06T10:56:06.356Z] make[1]: *** [CMakeFiles/my_module_Test.dir/all] Error 2
    [2021-12-06T10:56:06.356Z] Makefile:145: recipe for target 'all' failed
    [2021-12-06T10:56:06.356Z] make: *** [all] Error 2
    [2021-12-06T10:56:06.356Z] ERROR: conanfile.py (my_module/6.1.0): Error in build() method, line 41
    [2021-12-06T10:56:06.356Z] 	super().build()
    [2021-12-06T10:56:06.356Z] 	ConanException: Error 2 while executing cmake --build '/home/jenkins/agent/workspace/workspace/<jenkins_branch_name_subdir>/build/coverage/build/my_module' '--' '-j2'

(the only closest ticket i found was #2388 - but its on Windows with further in parts using nmake.)
user: AlexanderStohr
issue_10121: state: open
title: [bug] conan info . --dry-build --graph=file.html build confusing vertical line
body: When build our project graph `conan info . --dry-build --graph=file.html`, I see a big line tying everything together. It makes quite confusing to understand if something depends or not on the other.

![image](https://user-images.githubusercontent.com/5332158/144484805-73e7fa47-8240-4138-9d09-38b791635b48.png)

When using the dot tool alternative, there is no such line and it makes quite clear to understand if something depends on another:
1. https://docs.conan.io/en/latest/extending/template_system/info_graph.html
1. `conan info . --dry-build --graph=file.dot`
1. `dot -Tpng file.dot > file.png`

![image](https://user-images.githubusercontent.com/5332158/144486300-395abc5e-c370-485f-ae03-b8778e503b7e.png)

Why the default `.html` graph have that big line tying almost everything together? How could I remove it?

### Environment Details (include every applicable attribute)
  * Operating System+version: Debian 9
  * Compiler+version: 6.3
  * Conan version: 1.42.2
  * Python version: 3.5

user: evandrocoan
issue_10119: state: open
title: [question] conan search from conanfile.py
body: I have a locally build conan package A that is not always available.
In the `conanfile.py` of project B, I am calling `conan search A/version@ -q "..."` (I omitted the long query) via pythons `subprocess.run`. This always results in A not being found, even if it is in the local cache. Executing the command in a terminal successfully manages to find A.
This probably happens since the environment inside of ` conan create` differs from the normal terminal.
My questions: Is there some way to successfully query for A from the `conanfile.py` of project B?
Also, is there a better way than calling `subprocess.run` to achieve this?

user: raphael-grimm
issue_10111: state: open
title: [feature] clear local cache of packages not on any remote
body: We regularly want to remove packages that were only built locally from the local cache without losing the caching of packages pulled from remote.
Use cases:
- server builds that should start with a clean state without any chance of using a package built by some other server build on this agent
- developers who want to clean up their own cache from past local builds and free disk space
In both cases we want to keep the cache of already-released packages as they would otherwise be downloaded again from remote.

Suggestion would be to add a parameter to `conan remove`, maybe `--purge: purges packages from your local cache that are not available on any remote (anymore), including packages built locally and exported only to local cache. Cannot be used with --remote`

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: SvenStaehs
issue_10108: state: open
title: [bug] Cache/Download cache does not get updated for file permissions in 'conan_sources.tgz'
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Linux / Ubuntu 21
  * Compiler+version: gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
  * Conan version: 1.42.2
  * Python version: Python 3.9.5

### Steps to reproduce (Include if Applicable)

- enable download cache
- conan export pkg/version
- upload a Conan package where the source code contains invalid execute rights for a specific script to Artifactory
  - the Conan package includes the sources
- conan install <pkg> --profile=foo --build --update --remote my-artifactory-remote

The recipe fails to build the package from sources as the script in the sources contain invalid execute rights

- Fix the execute rights for the script in the sources
- $ conan export pkg/version
- upload the Conan package again to Artifactory
- $ conan install <pkg> --profile=foo --build --update --remote my-artifactory-remote

The recipe still fails to build the package from sources as the script in the sources contain invalid execute rights

- **$ rm -rf /path/to/.conan/download_cache/**
- **$ rm -rf /path/to/.conan/data/**
- $ conan install <pkg> --profile=foo --build --update --remote my-artifactory-remote

The install/build succeeds now as it pulls the 'conan_sources.tgz' from Atifactory.

Question/Proposal: file permissions should be included in the package checksum?


user: iiknd
issue_10092: state: open
title: [feature] Allow overriding settings for specific dependencies (tools)
body: Conan allows overriding *options* but not *settings* when installing dependencies (and build dependencies).  You can in the command line determine that you want to build shared objects and link one of your dependencies statically, for example.

There are some packages, though, that are used as tools and for which there's no relation between what you want to build and how you consume that dependency.  For example `cmake` is used as a tool, and you don't need to have a DEBUG build of `cmake` to be able to build your own code in debug mode.

In cases like `cmake` it may be possible to *remove* those bits from the settings (i.e. the settings for the `cmake` package could omit the `build_type` ([§]).  But this cannot be done with other tools like `strawberryperl` which can be both a *tool* in some projects (we use some `perl` in our build system, don't judge!) but can also be a *library*.

There could be different ways of going about this, one would be to separate the *tool* from the *library*, and have `strawberryperl-lib` and `strawberryperl-interpreter` packages, the former having all the options in the `settings`, the latter ignoring a few.  But the point of compiling against the `strawberryperl-lib` would still be to run it in an interpreter, and we are back at having to match the interpreter with the library (which is exactly what we have now with a single package).

An alternative is to postpone the decision to the user.   If you know that you only want the interpreter and you don't care about which you could override either in the recipe or in the command line the settings for the dependency:

```
# Syntax for exposition only, building debug/32
$ conan install my_pkg/1.0 --build=missing -pr debug_32_profile -s strawberryperl:build_type=Release -s strawberryperl:arch=x86_64
```

Note that the `-s:b` and `-s:h` are in the same space, but it may be a bit blunt as it separates all the `build_requires` vs. `requires` in the recipe.  I could imagine that you may have a `build_depends` for which the `build_type` or `arch` matter.

A more radical approach would be to consider that there are really `requires`, `build_requires` and `build_tools` and that the settings/options may apply differently to those three categories.

[§] This is not what `cmake` does in conan-center-index; they include `arch`, `compiler` and `build_type` in the settings but remove `compiler` from the `package_id()`.   This means that I need to have a DEBUG build of `cmake`.  I'm also unsure about the idea of building distinct things with the same identifier in the first place...

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: dribeas
issue_10088: state: open
title: [feature] Emscripten os.threads setting
body: Emscripten binaries are incompatible if they were build with some flags that don't match. For instance `-s USE_PTHREADS=1` is incompatible with libraries without it. Mismatching libraries will fail with the following:

> wasm-ld: error: --shared-memory is disallowed by spdlog.cpp.o because it was not compiled with 'atomics' or 'bulk-memory' features.

I'm considering implementing `os.threads=True` that should correctly set the flags. To implement this, we would need to add a new entry in `settings.yml` and append `-s USE_PTHREADS=1/0` depending on the value of `os.threads`.

I'm not 100% sure how to proceed with the handling of the flags. I have a working hack that allows setting it for CMake by appending the flag to `CONAN_C/CXX_FLAGS` in `cmake_flags.py`, by checking the platform and threads setting. This obviously will only work for CMake, but a similar patch is required for autoconf and other supported toolchains.

I'm unsure what the policy is on adding C/CXX flags, since it's very rarely done in Conan, if there's another better path to take for this, please let me know. Any help and guidelines on how to proceed with implementing this would be greatly appreciated.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Rogiel
issue_10074: state: open
title: [question] Is it possible to update aliases without conan install --update?
body: I am creating an installer that fetches artifacts from our locally run conan server (that fetches in turn from conan center).
In order to get the latest artifacts I am using aliases. For example:

```python
def build_requirements(self):
    self.build_requires("myapp/(latest)@mycompany/stable")
    self.build_requires("myresources/(latest)@mycompany/stable")
```

The idea is that we want a pipeline to create a new installer package after every change to one of the dependencies, so that we always have the latest installer version.

If I run `conan install ..`, it does not update the alias. Only by running `conan install .. --update` it fetches the latest aliases. 
The nasty consequence we are experiencing at the moment is that it updates also all underlaying dependencies, including the latest revision of `gtest 1.10.0` which is not working for us. The library  CONAN_PKG::gtest cannot be found. I guess this syntax is ill-advised, but it still worked for us with an older revision.

So I am wondering right now, is there a way that I can resolve the latest aliases, without forcing to update all dependencies (i.e. fetch the latest revisions)?
Also using aliases in this way, is that actually recommended?





- [ x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: jlemein
issue_10070: state: open
title: Generator qbs deps
body: Changelog: (Feature): QbsDeps generator to generate Qbs modules
Docs: https://github.com/conan-io/docs/pull/XXXX

Part of #10033
Generates qbs [modules](https://doc.qt.io/qbs/qml-qbslanguageitems-module.html) which contain all required informations for linking. The directory with the modules could be passed to qbs via a projects [qbsSearchPaths](https://doc.qt.io/qbs/qml-qbslanguageitems-project.html#qbsSearchPaths-prop) property. Later a qbs [module provider](https://doc.qt.io/qbs/module-providers.html) should use (mostly copy) the generated files.

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one.

<sup>**Note:** By default this PR will skip the slower tests and will use a limited set of python versions. Check [here](https://github.com/conan-io/conan/blob/develop/.github/PR_INCREASE_TESTING.md) how to increase the testing level by writing some tags in the current PR body text.</sup>

user: Psy-Kai
issue_10060: state: open
title: [bug] layout folders are inconsistently generated in local developer workflow
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Win 10 (20H2, OS build 19042.1348)
  * Compiler+version: MSVC 2019, MSVC 2022 (shouldn't matter)
  * Conan version: 1.42.1
  * Python version: 3.10.0

### Steps to reproduce (Include if Applicable)

For testing purposes, I have setup the following directory structure:
```
/
   recipe/
      conanfile.py
   workspace/
```

When using a command line with workspace as the current working directory, I execute the following commands:
```batch
conan install ../recipe
conan source ../recipe
conan build ../recipe
```

Afterwards, I check where the folders specified in `layout()` are generated: (ignoring other files)
```txt
/
   recipe/
      build/
      generators/
      imports/
      conanfile.py
   workspace/
      sources/
```

That is not what I expected. I expected the following directory structure:
```txt
/
   recipe/
      conanfile.py
   workspace/
      build/
      generators/
      imports/
      sources/
```

Trying `conan create ../recipe`. the generated directory structure in the cache is a much closer to what I expected:
```txt
$CONAN_USER_HOME/data/layout-test/0.0.1/_/_/
   export/
      conanfile.py
   build/
      <BUILD_ID>/
         build/
         generators/
         imports/
         sources/
```

I assume that the current working directory somehow gets messed up when using `layout()` in combination with `conan install` or `conan build` and is instead replaced with the recipe path.

---

For reference, this is the conanfile that I used, it barely does anything:

```conanfile.py
from conans import ConanFile, tools

class LayoutTestConan(ConanFile):
    name = 'layout-test'
    url = 'https://github.com/conan-io/hello.git'
    version = '0.0.1'
    generator = 'cmake'

    def source(self):
        git = tools.Git(folder=self.source_folder)
        git.clone(self.url)
        git.checkout('master')

    def build(self):
        pass

    def layout(self):
        self.folders.source = 'sources'
        self.folders.build = 'build'
        self.folders.generators = 'generators'
        self.folders.imports = 'imports'

    def imports(self):
        pass

    def generate(self):
        pass

    def package(self):
        pass
```
user: PengolodhGoedath
issue_10053: state: open
title: [question] Cross compiling embedded with gcc-arm-none-eabi
body: Hey,
I'd like to use conan to cross compile some 3rd parties for an embedded target with gcc-arm-none-eabi compiler (GCC 10 is used)


I've found this info
https://github.com/conan-io/conan/issues/675
bit it looks a little bit outdated to me

What os_target and arch_target should i use for embedded builds. target on embedded is usually "none" but this is not in the list



I tried 
```
  set(settings 
     #host
    "os_build=Windows"
    "arch_build=x86_64"
    #Target
    "os_target=None"
    "arch_target=None")


 conan_cmake_install(
    PATH_OR_REFERENCE
    .
    BUILD
    missing
    REMOTE
    conan-center
    SETTINGS
    ${settings})
```


However it looks like "None" is not a valid arch_target value
The settings.yml currently contains only these (cross) compiling values
```

# Only for cross building, 'os_build/arch_build' is the system that runs Conan
os_build: [Windows, WindowsStore, Linux, Macos, FreeBSD, SunOS, AIX]
arch_build: [x86, x86_64, ppc32be, ppc32, ppc64le, ppc64, armv5el, armv5hf, armv6, armv7, armv7hf, armv7s, armv7k, armv8, armv8_32, armv8.3, sparc, sparcv9, mips, mips64, avr, s390, s390x, sh4le, e2k-v2, e2k-v3, e2k-v4, e2k-v5, e2k-v6, e2k-v7]

# Only for building cross compilation tools, 'os_target/arch_target' is the system for
# which the tools generate code
os_target: [Windows, Linux, Macos, Android, iOS, watchOS, tvOS, FreeBSD, SunOS, AIX, Arduino, Neutrino]
arch_target: [x86, x86_64, ppc32be, ppc32, ppc64le, ppc64, armv5el, armv5hf, armv6, armv7, armv7hf, armv7s, armv7k, armv8, armv8_32, armv8.3, sparc, sparcv9, mips, mips64, avr, s390, s390x, asm.js, wasm, sh4le, e2k-v2, e2k-v3, e2k-v4, e2k-v5, e2k-v6, e2k-v7, xtensalx6, xtensalx106]


```

Is it currently possible to cross compile with gcc arm none eabi using conan, or do I have to manually apply the fix posted here
https://github.com/conan-io/conan/issues/675#issuecomment-262303771


Thx for you answer :)

Edit: I did take a look at
https://docs.conan.io/en/1.6/systems_cross_building/cross_building.html , especially the Windows to Raspberry PI (Linux/ARM) section
but cortex M MCUs don't have arch=armv7
user: Ju1He1
issue_10050: state: open
title: [bug] Workspaces do not work correctly when defining layout method
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: `Ubuntu 21.04`
  * Conan version: `Conan version 1.42.0` 

### Steps to reproduce (Include if Applicable)

I have created a small example repository [here](https://github.com/physhh/conan-monorepo) which can be used to reproduce the behavior. The repository contains two projects with two separated conanfiles. In both conanfiles the `layout` method is used to describe the package which makes it possible to use `AutoPackager`. So far so good - I can can build both packages as expected and the package layout looks exactly how I want. 

Now I want to create a conan workspace for both packages. There is a [script](https://github.com/physhh/conan-monorepo/blob/5f70f4f334d874a8bf58c1bd5c1135bc25ef9f99/workspace/generate.sh) in the workspace subdirectory which shows how I try to generate the workspace. When I execute the script the build files (`conan_paths.cmake` and so on) are put in the root directories of the projects (`hello` and `world`) and I do not know why. According to the [layout definition](https://github.com/physhh/conan-monorepo/blob/5f70f4f334d874a8bf58c1bd5c1135bc25ef9f99/hello/conanfile.py#L23) there should be a build directory. 

This happens as soon as the `layout` method is defined. I think it has something to do with [this special case](https://github.com/conan-io/conan/blob/bcf385540876373ad36001c9bc70ec171fc7cd59/conans/client/installer.py#L465-L486) defined in conan? 
user: ziish
issue_10048: state: open
title: [question] How to apply options to the package and its dependencies?
body: Hello,

assume I have:

App->LibA->LibB->LibC->LibD

[The actual situation is lot worse, lot more components, lot more complex graph]

I want to set fPIC from profile on LibB,C,D but not on LibA and LibB.

Can I do that without specifying all three libs manually in the profile? Is there a way to tell 

LibB*.fPIC=True

in profiles?
Thanks,
user: harsszegi
issue_10042: state: open
title: [feature] Add documentation about setting MSVC Compile Options using MSBuildToolchain
body: Please add example of how to properly set [MSVC Compiler options](https://docs.microsoft.com/en-us/cpp/build/reference/compiler-options-listed-alphabetically?view=msvc-170) using MSBuildToolchain to Docs. 

Using the **MSBuildToolchain** from **conan.tools.microsoft**:

I was facing a problem today when attempting to set compiler options using the **compile_options** field. 

I was attempting to set the `/Zc:strictStrings-` option like so:

```python
tc = MSBuildToolchain(self)
tc.compile_options = {
    "/Zc:strictStrings-" : 1
}
```
This worked fine when building the solution using `conan create`

However when adding the **conantoolchain.props** file, to the VS project using the property manager, to build the package in Visual Studio during development, I was getting an XML formatting error when attempting to build it. Because the name of the option starts with a `/`, the XML element name became a problem.
```xml
<ClCompile>
</Zc:strictStrings->1<//Zc:strictStrings->
</ClCompile>
```

What fixed the issue was adding the option under AdditionalOptions instead, like so: 

```python
tc = MSBuildToolchain(self)
tc.compile_options = {
    "AdditionalOptions" :"/Zc:strictStrings- /WhateverFlags /You /Need"
}
```

It would be nice with an example of setting compiler options such as these in the documentation of MSBuildToolchain, since this took a bit of time for me to figure out on my own.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: vuuk
issue_10041: state: open
title: [bug] Windows conan_toolchain.cmake broken using CMake "CodeBlocks - NMake Makefiles" generator with CLion
body: 
### Environment Details
  * Operating System+version: Windows 10 x64
  * Compiler+version: Visual Studio 2017 and 2019
  * Conan version: 1.42.1
  * Python version: 3.9.2

### Steps to reproduce (Include if Applicable)

CLion invokes the CMake generator with -G "CodeBlocks - NMake Makefiles" and the current code to _get_generator_platform() is detecting a Windows Visual Studio build and returns "x64" here https://github.com/conan-io/conan/blob/develop/conan/tools/cmake/toolchain.py#L567.

This results in the inclusion of the property CMAKE_GENERATOR_PLATFORM here https://github.com/conan-io/conan/blob/develop/conan/tools/cmake/toolchain.py#L503 giving the additional conan_toolchain.cmake line:

```
set(CMAKE_GENERATOR_PLATFORM "x64" CACHE STRING "" FORCE) 
```

This fails because it is apparently not a supported option for the CMake NMake Makefiles. 

If the set CMAKE_GENERATOR_PLATFORM line is not present in the generated conan_toolchain.cmake file, CMake is happy and is able to configure the project.

### Logs (Executed commands with output) (Include/Attach if Applicable)

The error CLion generates is: 
```
CMake Error at CMakeLists.txt:2 (project):
  Generator

    NMake Makefiles

  does not support platform specification, but platform

    x64

  was specified.
``` 
user: drmacdon
issue_10040: state: open
title: [bug] Boost/1.76.0 build failing msvc 
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: MSVC 19.16.27045.0
  * Conan version: 1.42.1
  * Python version: 3.7.1

### Steps to reproduce (Include if Applicable)
use the below conanfile.txt content with above environment details.
[requires]
boost/1.76.0

[generators]
cmake

[options]
boost:shared=False

The winprofile.txt used by me is below:
[settings]
arch=x86_64
arch_build=x86_64
compiler=Visual Studio
compiler.runtime=MD
compiler.version=15
compiler.cppstd=17
compiler.toolset=v141
os=Windows
os_build=Windows

[options]

[build_requires]

[env]
CC=cl.exe
CXX=cl.exe

### Logs (Executed commands with output) (Include/Attach if Applicable)
boost/1.76.0: ERROR: Package 'ddab49c386512c53fc58b4666da19ec799533441' build failed
boost/1.76.0: WARN: Build folder C:\.conan\83e13e\1
ERROR: boost/1.76.0: Error in build() method, line 829
        self.run(full_command, run_environment=True)
        ConanException: Error 1 while executing b2.exe -q numa=on target-os=windows architecture=x86 address-model=64 binary-format=pe abi=ms --layout=system --user-config=C:\.conan\ccfd29\1\source_subfolder\tools\build\user-config.jam -sNO_ZLIB=0 -sNO_BZIP2=0 -sNO_LZMA=1 -sNO_ZSTD=1 boost.locout=system --user-ale.icu=off --disable-icu boost.locale.iconv=off --disable-iconv runtime-link=shared runtime-debugging=on threading=multi visibility=hidden link=stu=off u boost.locaatic variant=debug --with-atomic --with-chrono --with-container --with-context --with-contract --with-coroutine --with-date_time --with-exception -=debugrono --with--with-fiber --with-filesystem --with-graph --with-iostreams --with-json --with-locale --with-log --with-math --with-nowide --with-program_options --files--with-json -with-random --with-regex --with-serialization --with-stacktrace --with-system --with-test --with-thread --with-timer --with-type_erasure --with-wax --wi --with-testve toolset=msvc cxxflags=/std:c++17 pch=on  cxxflags="-fPIC" install --prefix=C:\.conan\fe0c0d\1 -j8 --abbreviate-paths -d0 --debug-configuration -c++17  -j8 --abbre-build-dir="C:\.conan\83e13e\1"
<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: lalit-g-deepr
issue_10033: state: open
title: [feature] Make Qbs Generators ready for conan 2.0
body: The Qbs generators should be on par with CMake. Transparent integration should be possible.  
For this multiple things have to get changed:
*  [ ] QbsProfile generator should _not_ delete the settings directory
*  [ ] in addition to create a file containing a profile the QbsProfile generator has to modify the config in the settings directory
*  [ ] the Qbs build helper needs to detect and pass the settings directory
*  [ ] a QbsDeps generator has to generate Modules for all required components
*  [ ] the QbsDeps generator might generate a file containing additional information like environment variables

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: Psy-Kai
issue_10023: state: open
title: [feature] Extend --require-override to `conan info`
body: Essentially the same as #9392 but for `conan info`.

In our pipeline we use `conan info` to determine which packages need to be built and then build the packages with `conan install ... --build=<package> <additional_cmdline>` where we use the same `additional_cmdline` for both `conan info` and `conan install`. This doesn't work because `conan info` doesn't support the parameter yet.

Is it a sensible assumption that the same parameters regarding the dependency graph (profiles, options, settings, etc.) work for both `conan info` and `conan install` ?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: slietzau
issue_10019: state: open
title: [question] Run code analysis, test and generate documentation in separate steps
body: Hi.

In our project we want to run static code analysis, generate documentation and run unit tests separated from building the program binaries.

What would be the best way to do this?

I have come up with adding an option for this. In the option you can for example specify that documentation shall be created. If option is left out the default is binary. The artifacts will when be in separate packages. Is the way to do it or do they exist any better ways in Conan to do this?

We would like to execute the above in parallel.  Conan is however not thread safe but believe that is related to cache activities. Would it be possible to execute in parallel by creating separate lock files and then run “conan build” in parallel and then builds are finished export the packages. Could “conan create” work in this case? Conan create writes to the cache but the parallel builds will be packaged into separate packages.

BR
Patrik

user: paostman
issue_10006: state: open
title: [question] copy() seems to match patterns only if they start with '*'
body: Using 1.40.1 on Windows.

`copy(pattern="*.dll", dst="/bin") `
works
`copy(pattern="X*.dll", dst="/bin") `
does *not* (no file matched even though they do exist

Similarly
`copy(pattern="*.dll", excludes="X*dll", dst="/bin")`
would *not* exclude X*dll files.

So it appears the only patterns that work must start from '*'?

Is this expected? And if so, the doc should be changed as they refer to fnmatch, in which case it should be working.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: michkrom
issue_9994: state: open
title: [feature] Add option "--ignore-binaries" to conan install or --build=notincache
body: For a subset of packages from https://center.conan.io we get 
```
undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
```
on our build machines. 

To continue the build we use option `--build=<problematic-package>` however this is very annoying for bigger packages which are already rebuilt and available from the local cache.

We understand that glibc version won't be added as a first-class setting into conan. Therefore we request feature to only rebuild specific dependency only when it is not available in the local cache.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: fukanchik
issue_9983: state: open
title: [question] Removing all packages for specific query from local cache
body: When issuing command

```
conan remove '*' --builds --packages --query 'os=Emscripten'
```

I get the error

```
ERROR: '-q' and '-p' parameters can't be used at the same time
```


This is also documented, but does it have to be like this? Why am I restricted to deleting packages matching the query only for a single reference and not for the pattern?
user: DoDoENT
issue_9978: state: open
title: [Bug] `--install-folder` not honoured when using layout.
body: When conan install is executed from cmake (with cmake-conan):

```
-- Conan executing: /home/developer/python-envs/default/bin/conan install /cmake-general/tests/project --install-folder /cmake-general/tests/build/conan --build missing --profile:host default --profile:build default --settings build_type=Release --settings compiler=clang --settings compiler.version=12 --settings compiler.libcxx=libstdc++11
```

and with 

```
def layout(self):
    cmake_layout(self)
```

in the `conanfile.py`, the install folder `--install-folder /cmake-general/tests/build/conan` is not honoured, but the generated files go into
`/cmake-general/tests/project/cmake-build-cona/conan`.

Why is that?
user: gabyx
issue_9967: state: open
title: [question] Components and requirements
body: I am creating a package for Intel MKL. Intel MKL comes with a core library `mkl_core` and optional libraries `mkl_blacs` and `mkl_scalapack`. `mkl_scalapack` requires `mkl_blacs` and `mkl_blacs` requires an MPI library, see [Intel MKL link line advisor](https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl/link-line-advisor.html). Now many libraries need MKL but do not need or use the blacs and scalapack libraries, so I thought I'd make options for blacs and scalapack:

```
options = {"blacs": [True, False], "scalapack": [True, False]}

def requirements(self):
    if self.options.blacs:
        self.requires("intel-mpi/VERSION")
```

Now let's say I have two libraries `lib-no-blacs` and `lib-with-blacs`, where both requires MKL, but only the second one sets "self.options["mkl"].blacs = True" and thus transiently requires `intel-mpi`. Now when I consume both of these packages in my end product `conanfile.txt`

```
[requires]
lib-no-blacs/1.0.0
lib-with-blacs/1.0.0
```

I get a conflict on `conan install` since the MKL packages they try to pull in have different requirements. I have tried to resolve this to no avail, even created "core", "blacs" and "scalapack" as components.

I currently have two workarounds:
1) Override the MKL requirement in the consumer `conanfile.txt` specifying `mkl:blacs=True` and rebuilding `lib-no-blacs` with MKL *with* blacs enabled.
2) Remove `intel-mpi` as a requirement from MKL even when `blacs` is enabled.

Another solution I originally used was to split up MKL into three separate Conan packages `mkl-core`, `mkl-blacs` and `mkl-scalapack` which each could have independent options and requirements. This gave a little redundant recipe duplication but overall worked fine ...until I had to build a package that relied on MKL with Blacs and Scalapack through a Cmake `find_package(MKL COMPONENTS ScaLAPACK)` which would look for a special `MKLROOT` environment variable pointing to the package/lib directory where it assumed all library files would be.

So my question is: Is it possible for a package to ignore an option? i.e. let `lib-no-blacs` not care whether in the end MKL blacs option is true/false and also ignore the requirement on "intel-mpi" as it is not using it anyway?

Or is there another way I should do this?

Also a suggestion: I think the "components" feature currently seems half-baked. They probably could resolve some of the above issues but the resolution of package and component dependencies is not clear to me. I think a much simpler and more general implementation of components would be that components to a large degree are considered separate Conan packages that share some meta data and the source+build+package directory but have independent requirements. This would require making components closer to first-class citizens:

```
class MyPackageWithComponents(ConanFile):
    name = "mypackagewithcomponents"
    ...
    components = ["core", "componentA", "componentB"]

    def requirements(self):
        self.components["core"].requires("some-dependency/1.0.0")
        self.components["componentA"].requires("mypackagewithcomponents::core")
        self.components["componentB"].requires("otherlib/1.2.3")

```
Obviously I haven't thought all of this through, but I can't be the only one struggling with libraries that optionally depend on other libraries, e.g. [freetype](https://conan.io/center/freetype?tab=recipe) also optionally depend on a bunch of other libraries.
- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: fanselm
issue_9941: state: open
title: [question] Should syntax `*:shared` be avoided on package creation?
body: What are the recommendations / best practices when propagating option values to the requirements?

Is it recommended to use `configure()` to assign the value of the requirements options, like here?

``` python
class MyLibConan(ConanFile):
    name = "MyLib"
    version = "2.5"
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False]}

    def configure(self):
        self.options["boost"].shared = self.options.shared
        self.options["openssl"].shared = self.options.shared
        self.options["zlib"]. shared = False

   def requirements(self):
       self.requires("boost/[1.72]@")
       self.requires("openssl/[2.0]@")
       self.requires("zlib/[3.1]@")
```

And then create the package with `conan create . 1.0.0@ -o MyLib:shared=True`

Or is it common practice to use the syntax `*:shared=<value>`?

``` python
class MyLibConan(ConanFile):
    name = "MyLib"
    version = "2.5"
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False]}

    def configure(self):
        self.options["zlib"]. shared = False

   def requirements(self):
       self.requires("boost/[1.72]@")
       self.requires("openssl/[2.0]@")
       self.requires("zlib/[3.1]@")
```

And then create the package with `conan create . 1.0.0@ -o *:shared=True`


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: lucabonifacio
issue_9940: state: open
title: [question] PUBLIC / PRIVATE Link Libraries Separation
body: Let's take following simplified example:

```cmake
find_package(Boost REQUIRED)
find_package(OpenSSL REQUIRED)

add_library(Foo)

target_link_libraries(${PROJECT_NAME}
	PUBLIC
		Boost::Boost
	PRIVATE
		OpenSSL::OpenSSL
)

#...
include(CMakePackageConfigHelpers)
configure_package_config_file(...)
install(...)
```

Now, let's assume we want to consume `Foo`:
```cmake
find_package(Foo REQUIRED)

add_executable(App)

target_link_libraries(${PROJECT_NAME}
    PRIVATE
        Foo::Foo
)
```

Now, having `OpenSSL` defined as a private dependency of `Foo` means that `App` can link against it, but cannot include any API of it. Instead, in case of `Boost`, `App` can use it within the application.

CMake, when generating the Package Configuration Files, uses `$<LINK_ONLY:...>` to specify private link dependencies without other usage requirements.

My question is, how can I describe the PUBLIC / PRIVATE separation within `package_info()`?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: lucabonifacio
issue_9926: state: open
title: [feature] Deploy generator for iOS/OSX universal binaries
body: Based on earlier feedback, the idea of multi-architecture packages in conan is too complex.  For such an attempt see the combination of https://github.com/conan-io/conan/issues/9636 and https://github.com/conan-io/conan/pull/9904 to alter every recipe in a dependency graph.  It works but is very complicated.

Instead, run lipo during deploy.  In that pull @memsharded said "I'd say... leveraging the Conan 2.0 new custom modular commands, start working on a deploy-aggregator with lipo command."

I don't see anything like than in 2.0 but maybe you mean adding a command like:

```
conan lipo openssl/1.0.2u@ -g lipo -b missing -pr x86_64 -pr armv8
```
which is similar to:
```
conan install openssl/1.0.2u@ -b missing -pr x86_64
conan install openssl/1.0.2u@ -b missing -pr armv8
conan install openssl/1.0.2u@ -g deploy -if install_folder
```
The deploy generator only has access to one arch, hence the new command to pass multiple archs to one.  Is the -g flag useful for other lipo generators, like maybe Android?

I have a working directory copier with lipo in this repo.  (It's more complicated than it seems.  For example, recognizing what files are binaries, and consolidating different sets of files between the archs.)

https://github.com/gmeeker/conan-lipo-middleware

I believe this obsoletes https://github.com/conan-io/conan/issues/9636 and https://github.com/conan-io/conan/pull/9904 as well as https://github.com/conan-io/conan-extensions/issues/59 and https://github.com/conan-io/conan/issues/6384

I believe this issue is waiting on finished Conan 2.0 documentation for custom commands:
https://docs.conan.io/en/latest/migrating_to_2.0/commands.html#custom-commands

I have a custom wrapper that might be useful to others.  I'm using in production but I don't know if it's clean enough for others to use.  The idea is to lipo all the locally installed package and patch the generated files to point to the fat library paths instead.  Then your application's conanfile can build universal in Xcode or whatever, but packages still don't contain universal binaries.  I'm not currently working on porting this to 2.0's custom commands, but it could be a starting point for someone else.

https://github.com/gmeeker/BuildConan.git

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: gmeeker
issue_9923: state: open
title: <URGENT> Issue with Conan -- Unable to build or publish
body: Hello, My name is Rajguru from Germany. 
I have severe issues with conan that, it cannot build or publish. It shows 'building environment.. locked by another concurrent conan process, wait....
NOTE : I performed 'conan remove --locks' command, still issue exist. 

Can you please support me in resolving this at the earliest ? 
user: ganzyfrenzy
issue_9917: state: open
title: [question] conan install won't generate FindXXX.cmake
body: Hi,
Sorry for the long post, I tried to cut out some text but didn't want to leave out too much context accidentally.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

I'm trying to integrate [dpdk-kmods](http://git.dpdk.org/dpdk-kmods) as a conan package in my repo. I have this working but currently I have both a `conanfile.py` and `conanfile.txt`. The latter lists `cmake_find_package` as a generator, and `conan install` produces `FindDpdk-kmods.cmake` which I can include in my project.

I'm trying to just maintain `conanfile.py`, since the documentation says a separate `conanfile.txt` shouldn't be necessary, but no matter what I try I can't get it to generate `FindDpdk-kmods.cmake` if I remove `conanfile.txt`.

Here's my setup. I've added `conanfile.py` to dpdk-kmods and can create a conan package from it

```
(conan-venv) [asadanan@b0ae8c0c722c]/local/mnt/workspace/asadanan/dpdk/super/dpdk-kmods% conan --version
Conan version 1.42.0
(conan-venv) [asadanan@b0ae8c0c722c]/local/mnt/workspace/asadanan/dpdk/super/dpdk-kmods% conan create --build=outdated --profile:build=../build/dpdk-kmods/profile . Dpdk-kmods/2021.5-5-gc3387ac-dirty@
Exporting package recipe                                 
<snip>
                                                                    
Installing (downloading, building) binaries...
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Configuring sources in /home/asadanan/.conan/data/Dpdk-kmods/2021.5-5-gc3387ac-dirty/_/_/source                                                                                                                                             
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Copying previously cached scm sources                                                                                                                                                                                                       
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Copying sources to build folder                                                                     
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Building your package in /home/asadanan/.conan/data/Dpdk-kmods/2021.5-5-gc3387ac-dirty/_/_/build/50a5030bbbb13ae56bc4be41915ecd48549cb895
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Generator 'CMakeDeps' calling 'generate()'                                                                                                                                                                                                  
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Aggregating env generators
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Calling build()
<snip>

Dpdk-kmods/2021.5-5-gc3387ac-dirty: Package '50a5030bbbb13ae56bc4be41915ecd48549cb895' built                                                                                                                                                                                    
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Build folder /home/asadanan/.conan/data/Dpdk-kmods/2021.5-5-gc3387ac-dirty/_/_/build/50a5030bbbb13ae56bc4be41915ecd48549cb895                                                                                                               
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Generated conaninfo.txt   
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Generated conanbuildinfo.txt
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Generating the package                                                                                                                                                                                                                      
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Package folder /home/asadanan/.conan/data/Dpdk-kmods/2021.5-5-gc3387ac-dirty/_/_/package/50a5030bbbb13ae56bc4be41915ecd48549cb895                                                                                                           
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Calling package()                                                                                   
Dpdk-kmods/2021.5-5-gc3387ac-dirty package(): Packaged 1 '.ko' file: igb_uio.ko                                                                                                                                                                                                 
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Package '50a5030bbbb13ae56bc4be41915ecd48549cb895' created                                                                                                                                                                                  
Dpdk-kmods/2021.5-5-gc3387ac-dirty: Created package revision 6b0fcea567a25a4d9ecc0cb42610ade8
```

Now I want to generate `FindDpdk-kmods.cmake` for inclusion in my project's `CMakeLists.txt`, so I call `conan install`

```
(conan-venv) [asadanan@b0ae8c0c722c]/local/mnt/workspace/asadanan/dpdk/super/dpdk-kmods% conan install --profile:build=../build/dpdk-kmods/profile --install-folder=../build/cmake_modules . Dpdk-kmods/2021.5-5-gc3387ac-dirty@
<snip>

conanfile.py (Dpdk-kmods/2021.5-5-gc3387ac-dirty): Installing package
Requirements
Packages

Installing (downloading, building) binaries...
conanfile.py (Dpdk-kmods/2021.5-5-gc3387ac-dirty): Generator txt created conanbuildinfo.txt
conanfile.py (Dpdk-kmods/2021.5-5-gc3387ac-dirty): Aggregating env generators
conanfile.py (Dpdk-kmods/2021.5-5-gc3387ac-dirty): Generated conaninfo.txt
```

But the only files I see in the `install-folder` are: `conanbuildinfo.txt  conaninfo.txt  conan.lock  graph_info.json`

This is my `conanfile.py`

```python
from conans import ConanFile, tools, AutoToolsBuildEnvironment

class DpdkKmodsConan(ConanFile):
    name = "Dpdk-kmods"
    license = "BSD-3-Clause"
    url = "http://git.dpdk.org/dpdk-kmods"
    description = "igb_uio kernel module"
    scm = {
        "type": "git",
        "url": "auto",
        "revision": "auto",
    }
    topics = ("thirdparty", "platform", "opensource")
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}
    generators = "cmake_find_package"

    def set_version(self):
        git = tools.Git()
        self.version = git.run(
            "describe --tags --first-parent --always --dirty --match '*-start'")
        # Remove start tag
        self.version = self.version.replace('-start', '')

    def build(self):
        with tools.chdir("linux/igb_uio"):
            atools = AutoToolsBuildEnvironment(self)
            atools.make()

    def package(self):
        self.copy("*.ko", dst="lib", keep_path=False)

    def package_info(self):
        self.cpp_info.name = __class__.name
```

This is the build profile I'm using

```
[settings]
os=Linux
arch=x86_64
compiler=gcc
compiler.version=9.1
compiler.libcxx=libstdc++
compiler.cppstd=17
build_type=RelWithDebInfo
[options]
[build_requires]
[env]
PATH=[/local/mnt/workspace/asadanan/dpdk/super/build/conan-venv/bin]
```

I've also tried using `CMakeDeps` instead of `cmake_find_package` by modifying `conanfile.py` as

```python
# <snip>
    generators = "cmake_find_package"
# <snip>
    def package_info(self):
        self.cpp_info.name = __class__.name
        self.cpp_info.set_property("cmake_find_mode", "both")
```

I see the following messages when I run `conan install`, showing `CMakeDeps` generator is running

```
Installing (downloading, building) binaries...
conanfile.py (Dpdk-kmods/2021.5-5-gc3387ac-dirty): Generator 'CMakeDeps' calling 'generate()'
conanfile.py (Dpdk-kmods/2021.5-5-gc3387ac-dirty): Generator txt created conanbuildinfo.txt
conanfile.py (Dpdk-kmods/2021.5-5-gc3387ac-dirty): Aggregating env generators
conanfile.py (Dpdk-kmods/2021.5-5-gc3387ac-dirty): Generated conaninfo.txt
conanfile.py (Dpdk-kmods/2021.5-5-gc3387ac-dirty): Generated graphinfo
```

It generates these files: `cmakedeps_macros.cmake  conanbuildinfo.txt  conaninfo.txt  conan.lock  graph_info.json`. No `Dpdk-kmods-config.cmake` or `FindDpdk-kmods.cmake`.

So what am I doing wrong?

Thanks for your help!
user: praetorian20
issue_9902: state: open
title: [question] Static dependencies
body: When we started with Conan, the understanding we developed is that if dependency is only needed during build (but not necessarily for the CI/build environment), this dependency was referenced via `build_requires`, and if that dependency is used during runtime, it is referenced via `requires`.

The documentation for 1.41.0 is pretty explicit in disproving this believe. And that makes sense in context of cross-building. However, how do we deal with requirements that are not necessary downstream? 

For example, lets consider a scenario, where my shared library libfoo links with static zlib. libbar then depends on libfoo, but, as a transitive dependency, zlib package will be downloaded anytime during `conan install` for libbar. Is there a way to prevent this, and indicate that a particular `requires` dependency should not be visible to consumers of the recipe using it?


- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: w3sip
issue_9901: state: open
title: [question] Native build
body: Would you consider

```conan create . Proj/1.0@org/local -pr profile```

and 

```conan create . Proj/1.0@org/local -pr:h profile -pr:b profile```

identical commands? I'm seeing differences in behavior, and wonder if it is by design, or a bug.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: w3sip
issue_9877: state: open
title: [question] Managing dependency that is needed for both runtime and build time when cross-compiling
body: Can a recipe have a dependency that is both runtime, and build time? Take CUDA, for example -- if we are to have a CUDA package we'd need an x86_64 one that contains nvcc and other tools, and then another one, targeting arm64.

So, can we do both 
`self.build_requires("cuda/10.2@org/master")`
and
`self.requires("cuda/10.2@org/master")` ?

How would self.deps_cpp_info for the build environment be accessible?

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: w3sip
issue_9872: state: open
title: [bug] self.install_folder and self.build_folder are not available in the layout method
body: Hello,

I'm trying to use the new layout method to define where generator files are being created, I tried both:
```
def layout(self):
    self.folders.generators = os.path.join(self.build_folder, "conan")
```
and

```
def layout(self):
    self.folders.generators = os.path.join(self.install_folder, "conan")
```
But in both cases `self.build_folder` and `self.install_folder` are not defined. 

How can I define self.folders.generators relatively to the build folder.
 

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows
  * Compiler+version: msvc 16
  * Conan version: 1.41.0
  * Python version: 3.7


Best,
Walid

user: boussaffawalid
issue_9870: state: open
title: [bug] ReadTimeoutError from httpConnectionPool
body: ### Environment Details (include every applicable attribute)
  * windows 10, version 1909, OS build 18363.1801
  *compiler version: N/A (binary upload only)
  * Conan version: 1.38.0
  * Python version: N/A (conan windows installation)

### Steps to reproduce (Include if Applicable)
Probably any package with this size (bunch of binaries that are uncompressed about 800MB in size) will output such an error.

### Logs (Executed commands with output) (Include/Attach if Applicable)

Are you sure you want to upload '<package-name>/2021.10.26@<Suffix-name>' to '<Server-name>'? (yes/no): y
Uploading to remote '<Server-name>':
Uploading <package-name>/2021.10.26@<Suffix-name> to remote '<Server-name>'
Uploaded conanfile.py -> <package-name>/2021.10.26@<Suffix-name> [0.24k]
Uploaded conanmanifest.txt -> <package-name>/2021.10.26@<Suffix-name> [0.06k]
Uploaded conan recipe '<package-name>/2021.10.26@<Suffix-name>' to '<Server-name>': http://<URL-Name>:8082/artifactory/api/conan/conan-local
Uploading package 1/4: 01edd76db8e16db9b38c3cca44ec466a9444c388 to '<Server-name>'
Uploaded conan_package.tgz -> <package-name>/2021.10.26@<Suffix-name>:01ed [0.06k]      
Uploaded conaninfo.txt -> <package-name>/2021.10.26@<Suffix-name>:01ed [0.25k]
Uploaded conanmanifest.txt -> <package-name>/2021.10.26@<Suffix-name>:01ed [0.06k]      
Uploading package 2/4: 0a420ff5c47119e668867cdb51baff0eca1fdb68 to '<Server-name>'
Uploaded conan_package.tgz -> <package-name>/2021.10.26@<Suffix-name>:0a42 [391066.44k] 
ERROR: HTTPConnectionPool(host='<URL-Name>', port=8082): Max retries exceeded with url: /artifactory/api/conan/conan-local/v2/conans/<package-name>/2021.10.26/<Suffix-name>/revisions/2969498e68c8e43bff908838954d58f3/packages/0a420ff5c47119e668867cdb51baff0eca1fdb68/revisions/696d0a3e378e26f801fad3520a37d7a6/files/conan_package.tgz (Caused by ReadTimeoutError("HTTPConnectionPool(host='<URL-Name>', port=8082): Read timed out. (read timeout=60.0)",))
Waiting 5 seconds to retry...
Uploaded conan_package.tgz -> <package-name>/2021.10.26@<Suffix-name>:0a42 [391066.44k] 
ERROR: 
Error uploading file: conan_package.tgz, 'HTTPConnectionPool(host='<URL-Name>', port=8082): Max retries exceeded with url: /artifactory/api/conan/conan-local/v2/conans/<package-name>/2021.10.26/<Suffix-name>/revisions/2969498e68c8e43bff908838954d58f3/packages/0a420ff5c47119e668867cdb51baff0eca1fdb68/revisions/696d0a3e378e26f801fad3520a37d7a6/files/conan_package.tgz (Caused by ReadTimeoutError("HTTPConnectionPool(host='<URL-Name>', port=8082): Read timed out. (read timeout=60.0)",))'
Uploaded conaninfo.txt -> <package-name>/2021.10.26@<Suffix-name>:0a42 [0.25k]
Uploaded conanmanifest.txt -> <package-name>/2021.10.26@<Suffix-name>:0a42 [20.87k]     
Uploading package 3/4: 45b43bcd991ec89baf1eb618b595ca3227a3cf0b to '<Server-name>'
Compressing conan_package.tgz completed [0 files]
Uploaded conaninfo.txt -> <package-name>/2021.10.26@<Suffix-name>:45b4 [0.24k]
Uploaded conanmanifest.txt -> <package-name>/2021.10.26@<Suffix-name>:45b4 [0.06k]
Uploading package 4/4: 63c5d5dc6eb958dab897e143053e17f583d55879 to '<Server-name>'
Compressing conan_package.tgz completed [303 files]
Uploaded conaninfo.txt -> <package-name>/2021.10.26@<Suffix-name>:63c5 [0.24k]
Uploaded conanmanifest.txt -> <package-name>/2021.10.26@<Suffix-name>:63c5 [20.87k]
ERROR: <package-name>/2021.10.26@<Suffix-name>:0a420ff5c47119e668867cdb51baff0eca1fdb68: Upload package to '<Server-name>' failed: Execute upload again 
to retry upload the failed files: conan_package.tgz. [Remote: <Server-name>]

ERROR: Errors uploading some packages

### Additional Notes:
Probably I shouldn't have uploaded a package near to the size of 1 GB (I actually didn't realize the library provided to me was this big in size) and should probably distribute it in multiple parts instead. But I thought I'd report it here nonetheless. Note that it is correct that for 2 of the flavors I uploaded no files (As the behaviour I wanted was to only download these dlls on release builds). Also the packages seem to be uploaded correctly, but it does seem like it just wasn't able to read the response from the server.


user: Belpaire
issue_9849: state: open
title: [feature] Parse docstring from `package_info` method and show it in markdown generator
body: Parsing the docstring from the `package_info` method could be a good way to pass information from the recipe to consumers... and this information can be written in the file generated by the `markdown` generator. It can be free text or structured one.

user: jgsogo
issue_9846: state: open
title: [question] Auto-detect compiler version
body: Hi, I'm wondering if there's a way to have Conan automatically detect the compiler version for you, instead of having to manually specify it as a `-s` flag or profile entry? It seems like the code for detecting the version already exists in [detect.py](https://github.com/conan-io/conan/blob/develop/conans/client/conf/detect.py)

My use case is that I'm trying to integrate Conan into a project with an existing build system that has existing auto-configuration code. However, since the version strings in the default `settings.yml` file are not in any consistent format, and they have to match *exactly* otherwise you get an error, it's very painful to write a function that converts them. For example, clang.version has entries like `9, 10, 11` whereas apple-clang.version has entries like `9.0, 9.1, 10.0, 11.0`. My existing build system normalizes them all to three numbers, like `9.0.0`, `9.1.0`, etc. This means I need to have some big ugly logic to handle each case.

My goal is to have the existing build system invoke `conan install`. This is useful because the build system currently supports multiple cross-build targets, so it has all the information needed to generate a `profile` file for each one. Getting the compiler version strings right is difficult though, so having Conan auto-detect it would be helpful. I know that I can use a custom settings.yml file, but I would prefer not to in this case.

Note: I'm posting this as a question rather than a feature request in case this is already possible, or someone has a workaround.

Thanks

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: diggeloid
issue_9845: state: open
title: [question] conandata.yml, changing a single version source, and consistent recipe revisions
body: Hi,

We have a single Git repository in a similiar style to Conan Center for our recipes. We also make use of version agnostic recipes, and data drive it through conandata.yml with a url and a SHA. We also use `revision_mode="scm"` in recipe, so that we have a 1-1 relationship with recipe revisions and the git commit that resulted in the change. This is all nice.

An edge case, that I've not found an example of anyone else dealing with yet, is as follows:
* version agnostic recipe, with a number of versions in the conandata.yml
* a patch is made to a _single_ version source tree, so we have to update the conandata.yml for a SHA on that version only
* changing the conandata.yml implies a new recipe revision... but, actually, we only care about that for the version that was changed

Up until now, we've just bitten the bullet and rebuilt all versions mentioned in the conandata.yml. However, we do have some large recipes in the mix (e.g. Qt), and so it's not desirable in terms of compute, storage, or dev time, to rebuild versions that haven't actually changed.

Of course, if the recipe itself changed, we'd have to rebuild everything, so this is a bit of an edge case.

So what we're considering is only building the version that changed. That imples, for the given package, we may have different recipe revisions per version. I don't think I see that as a problem, but some colleagues are not sure. It's lovely having a consistent view of a package with a 1-1 mapping from Git to Artifactory, but the cost of rebuilding unnecessarily is starting to raise it's head.

What was the intent from your point of view when developing Conan that the behaviour should be in this scenario?

- always build all versions so revisions are always consistent
- just build specific versions when their source SHA changes, and can have different recipe revisions across versions of a package

Thanks.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: foundry-markf
issue_9841: state: open
title: [question] Can not find by boost with components
body: # Env
windows 11
qt creator 5.0.2
conan 1.41.0

# conanfile.py
```py
from conans import ConanFile

class ConanDeps(ConanFile):
   settings = "os", "compiler", "build_type", "arch"
   requires = "boost/1.77.0"
   default_options = { "*:shared": True }
   generators = "CMakeToolchain", "CMakeDeps"

   def imports(self):
      self.copy("*.dll", dst="bin", src="bin")
```

# cmake configure options
```
-GNinja
-DCMAKE_BUILD_TYPE:STRING=Debug
-DCMAKE_PROJECT_INCLUDE_BEFORE:PATH=%{IDE:ResourcePath}/package-manager/auto-setup.cmake
-DQT_QMAKE_EXECUTABLE:STRING=%{Qt:qmakeExecutable}
-DCMAKE_PREFIX_PATH:STRING=%{Qt:QT_INSTALL_PREFIX}
-DCMAKE_C_COMPILER:STRING=%{Compiler:Executable:C}
-DCMAKE_CXX_COMPILER:STRING=%{Compiler:Executable:Cxx}
```

# Problem
CMakeLists.txt
```cmake
...
find_package(Boost REQUIRED COMPONENTS locale) # fails
find_package(Boost REQUIRED) # succeeds and target_link_libraries works, e.g. target_link_libraries(tgt PRIVATE Boost::locale)
...
```
# More Info

tested on `wxWidgets`

`find_package(wxWidgets REQUIRED COMPONENTS core)` succeeds
user: playgithub
issue_9834: state: open
title: [feature] BazelDeps should allow custom path to `load_conan_dependencies`
body: I have a `repository_rule` that wraps `conan install ...` with [BazelDeps](https://docs.conan.io/en/latest/reference/conanfile/tools/google.html) as the generator. However, `conandeps/dependencies.bzl` hardcodes the path to `build_file` as `conandeps/<pkg>/BUILD`. When I call `load_conan_dependencies` from `@custom-repo//conandeps:dependencies.bzl`, the `build_file` turns out to be incorrect.

My suggestion is to allow a `conandeps_root` parameter to `load_conan_dependencies` to allow customization.
user: knzivid
issue_9831: state: open
title: [question] Updating a Buildroot Image into SD card
body: Hello, I saw your guide called "Creating small Linux images with Buildroot" (very helpful).

My questing is basically, what if I modify the image and want to update it to he SD card? Is it possible to do it without formatting the card or losing all the files than I passed to the system, for example cross-compiled files that were supposed to run on that machine.

thank you!!
Luís 


- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: luiscarlos63
issue_9823: state: open
title: [question] check for a new package version
body: Hi,

Is it possible to check for a new version of a package without installing it?

So for example:

available packages on artifactory
```
some_package/0.9.0
some_package/1.0.0
some_package/1.0.2
```

my conanfile.txt
```
[requires]
some_package/1.0.0
```

Now what I looking for is a command which I can see that *some_package/1.0.0* has an update to version *1.0.2* without using wildcard versions.

Is this possible?

If not do you have a suggestion how I can build something like this?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: snailcatcher
issue_9816: state: open
title: [question] How to add requirement with custom define?
body: I want `opencv` with enabled opengl but there is no option for that, however, there's a define `WITH_OPENGL` in the code that toggles this (I guess). I wanted to recompile the package from conan center without altering the recipe. Is there a way to do that?

I've tried this:  
```
def package_info(self):
        self.cpp_info.components["opencv"].defines = ["WITH_OPENGL=1"]
```
it didn't help me

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: xahon
issue_9814: state: open
title: [question] Will there be ways to build various configurations in cmake_layout / layouts simultaneously?
body: The current [cmake_layout](https://docs.conan.io/en/latest/reference/conanfile/tools/layout.html#predefined-layouts) functionality creates unique build directories per `build_type` such as `cmake-build-debug` and `cmake-build-release`.
This integrates very well with CLion, but doesn't allow having build directories based on any of the other configuration settings or options simultaneously.
One common use case I have is to have multiple compiler directories, too, so that I can have both Clang and GCC builds at the same time.
Given the numerous settings and package options, does it make sense to support having more build configurations in more build directories simultaneously for the pre-canned cmake_layout / layouts in general?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: jwillikers
issue_9813: state: open
title: [feature] 'options' seems to be counterproductively overloaded 
body: <!-- What is your suggestion? Please be as specific as possible! -->

In the class definition for the conanfile, you define an options map to specify the options for the package and the possible values these options may take. For example in Arrow:

![image](https://user-images.githubusercontent.com/11447537/137537979-80285db6-b26d-40f5-95e0-2f3c21f6b87a.png)

So, from the class definition, we have an `options` instance variable that is a dict. However when you treat it as a dict, its not what was initialized in the class, but rather references your requires options. This to me is confusing - and that's the motivation for my suggestion, to make it clearer to conan developers what is happening, by not replacing the `options` instance var. 

In order to reference the information you encoded in the dict definition at the top of the class definition, you call it like attributes, i.e. self.options.with_glog. 

I propose we decouple the options from the class definition from the `options` used in the member functions. What if we called the `options` in the class defn something like `my_options_possibilities`  or some such - basically the idea is to make it clear you are definite the options your class has and their possible values. 

We rename `default_options` to `my_options_defaults` (the my is to clearly differentiate this from the requires options)

Then a `my_options` dict is provided in the methods which holds the current values of my options. So not only is it renamed from 'options` as it is now, but it also is completely a map rather than attrs. 

For the options of the requires, we have a `requires_options` double map from require name to its own options map. So if I have a requires on foo and want to see option bar, I do `requires_options["foo"]["bar"]`

So I suppose I have a double suggestion here: 1. dict-ify the options and 2. rename `options` 

Heres an example of what it could look like: 
```
class FooConan(conanfile):
    my_options_possibilities = {"shared" : [True, False]}

    my_options_defaults = {"shared": True}

    def configure(self):
        if self.my_options["shared"]: # using generated my_options
            self.requires_options["whatever_dependency"]["whatever_option"] = whatever_value

...


```

Or at a higher level, perhaps instead the base `ConanFile` has overrideable functions get_my_possible_options and get_my_defualt_options and then functions the exender can call that are {get, set} X {my, dependencies} X {_option}

In this way we can satisfy the dependency inversion principle...and make it absolutely clear that the base classes uses those functions. 
```
class FooConan(conanfile):

   @property 
   def get_my_possible_options(self):
       return {"shared" : [True, False]}

   @property 
   def get_my_default_options(self):
       return {"shared": True}

    def configure(self):
        if self.get_my_option("shared"): # calling supers function
            self.set_dependencies_option("whatever_dependency", "whatever_option", "whatever_value) # calling supers function
...


```
So the `get_my_possible_options` would be expecting a map of a certain structure. namely keys as the option names to values as the option possibilities. get_my_default_options expects map from option name to default value, taken from possible options. We could have exceptions in place to check for this stuff. 

Better still however would be to not require any particular structure to be checked by base class, but rather make it valid simply by the extending class implementing the functions. We make it not necessary for the func to return a map. 

Instead maybe we have a function add_option(self, option_name, option_values, index_of_default)...but perhaps that's overkill. 

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: NolanC33
issue_9809: state: open
title: [bug] `conan info` doesn't show package duplicated in host/build contexts 
body: When a package is duplicated in the `host` and `build` contexts, the `conan info --dry-build` command shows only one of them:

**library.py**
```python
from conans import ConanFile

class Recipe(ConanFile):
    name = 'library'
```

**app.py**
```python
from conans import ConanFile, tools

class Recipe(ConanFile):
    settings = "os", "arch", "compiler", "build_type"
    
    requires = "library/version"
    
    def build_requirements(self):
        self.build_requires("library/version")
```

```
⇒  conan info app/version@ --profile:host=m1 --profile:build=default --dry-build
library/version: Forced build from source
app/version: Forced build from source
app/version
    ID: 8193ec9b73c98e6c194380adacc36502608ea03d
    BuildID: None
    Context: host
    Remote: None
    Provides: app
    Recipe: Cache
    Revision: 8bcebbf9ed94b5d2b867ca6806771363
    Package revision: None
    Binary: Build
    Binary remote: None
    Creation date: 2021-10-15 17:23:41 UTC
    Requires:
        library/version
    Build Requires:
        library/version
library/version
    ID: 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
    BuildID: None
    Context: build
    Remote: None
    Provides: library
    Recipe: Cache
    Revision: fdce5475e1b35dcb7af66b4fe4f7f4f1
    Package revision: None
    Binary: Build
    Binary remote: None
    Creation date: 2021-10-15 17:19:57 UTC
    Required by:
        app/version
        app/version
```

I would expect two entries for package `library/version`, one with `Context: host` and another one with `Context: build`, even if both are the same packageId. Alternatively, `Context: [host, build]`, but having two entries in the output is easier to parse IMHO.

Edit.- In fact, the context reported for `library/version` is UB, at least here I sometimes get `host` and others `build`.


user: jgsogo
issue_9803: state: open
title: [feature] Add support in B2 generator for VS2019 and VS2022
body: The b2 generator translates from Conan's compiler version number to the b2 toolset version number using a special case for VS2017, so that `15` maps correctly to `14.1`:

https://github.com/conan-io/conan/blob/53d06deaa4ee479060431c281b1fe8d27af59bca/conans/client/generators/b2.py#L292-L295

Would it be possible to extend support to VS2019 (`16` maps to `14.2`) and VS2022 (`17` maps to `14.3`) ? 

Support for VS2022 in b2 was added recently: https://github.com/bfgroup/b2/commit/aaf14325ec8e3ca86be9afaa501bca68fcfea8b3

user: sjcooke
issue_9796: state: open
title: [feature] Configure CMAKE_EXECUTABLE_SUFFIX appropriately in the CMakeToolchain generator for bare-metal targets
body: Bare-metal Arm and RISC-V executables are generally compiled in the ELF format, which typically uses the `.elf` file extension.
It would be helpful for the CMakeToolchain generator to handle this detail as part of the generated toolchain file.
Ideally, CMake would automatically handle this behavior, perhaps through the *Platform* selected.
I've opened [issue #22756](https://gitlab.kitware.com/cmake/cmake/-/issues/22756) upstream in CMake in order to try and get this functionality included.
This may require adjusting `CMAKE_SYSTEM_PLATFORM` appropriately if that's how it is solved upstream.
Otherwise, it's possible to override this by setting the individual language executable suffixes in the toolchain file.
Not that setting `CMAKE_EXECUTABLE_SUFFIX` is insufficient as is often overridden and set incorrectly from CMake platform modules.
The following snippet demonstrates how to set the appropriate `CMAKE_EXECUTABLE_SUFFIX` variables.

```cmake
set(CMAKE_EXECUTABLE_SUFFIX_ASM .elf)
set(CMAKE_EXECUTABLE_SUFFIX_C .elf)
set(CMAKE_EXECUTABLE_SUFFIX_CXX .elf)
```

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: jwillikers
issue_9795: state: open
title: [feature] Add a configuration option to configure the linker to use for the CMakeToolchain generator
body: The lld linker is incredibly fast and I'd wish to use it across projects.
Since the CMakeToolchain generator won't us environment variables by default, i.e. `LD`, would it be possible to add a configuration, i.e. `[conf]`, option to set the default linker as this shouldn't effect ABI compatibility? The CMakeToolchain generator can then set the appropriate flags to enable the linker as demonstrated below.

```cmake
set(CMAKE_EXE_LINKER_FLAGS_INIT -fuse-ld=lld)
set(CMAKE_MODULE_LINKER_FLAGS_INIT -fuse-ld=lld)
set(CMAKE_SHARED_LINKER_FLAGS_INIT -fuse-ld=lld)
```

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: jwillikers
issue_9792: state: open
title: [feature] Allow enabling / disabling exceptions for the CMakeToolchain generator
body: Many bare-metal systems disable C++ exceptions, or selectively enable them when using the GNU Arm Embedded compiler.
It would be great if the CMakeToolchain generator would handle disabling / enabling exceptions, perhaps through a compiler setting like the exception one available for Mingw?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: jwillikers
issue_9791: state: open
title: [feature] Default CMAKE_POSITION_INDEPENDENT_CODE to OFF in CMakeToolchain when building for bare-metal targets
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Fedora Silverblue 35
  * Compiler+version: GCC 11
  * Conan version: 1.41.0
  * Python version: 3.10

Position independent code is not always supported for bare-metal targets.
Specifically for Arm targets, PIE support is deprecated for the GNU Arm Embedded compiler.
Enabling PIE can be problematic when building for these targets and cause unexpected crashes.
The CMakeToolchain generator should account for this by defaulting `CMAKE_POSITION_INDEPENDENT_CODE` to `OFF` for bare metal targets.

Reference: https://developer.arm.com/documentation/100748/0612/mapping-code-and-data-to-the-target/bare-metal-position-independent-executables

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: jwillikers
issue_9790: state: open
title: [bug] CMakeToolchain default BUILD_SHARED_LIBS to OFF when building for bare-metal targets
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Fedora Silverblue 35
  * Compiler+version: GCC 11
  * Conan version: 1.41.0
  * Python version: 3.10

Bare-metal targets don't usually have the ability to link to shared libraries, so it would probably make sense to default this to OFF in the CMakeToolchain generator when this is the case.

user: jwillikers
issue_9788: state: open
title: [bug] CMakeToolchain allow bare metal targets to link to the newlib and newlib-nano C libraries
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Fedora Silverblue 35
  * Compiler+version: GCC 11
  * Conan version: 1.41.0
  * Python version: 3.10

### Steps to reproduce (Include if Applicable)

The [newlib C library](https://sourceware.org/newlib/) and the *newlib-nano* variant are commonly used for bare-metal targets.
The GNU Arm Embedded compiler uses newlib by default, but it is also possible to specify `-nostdlib` to remove newlib completely or the linker flag `-specs=nano.specs` can be used to use the smaller newlib-nano variant.
It would be helpful to have settings to indicate these configurations and to have that translated in the CMakeToolchain generator to the necessary linker flags.

user: jwillikers
issue_9786: state: open
title: [question] How to install a local recipe with multiple versions
body: https://github.com/bincrafters/community/tree/main/recipes/wxwidgets

config.yml
```yml
versions:
  "3.1.3":
    folder: "3.1.3"
  "3.1.4":
    folder: "all"
  "3.1.5":
    folder: "all"
```

How to install for version 3.1.5 with a local recipe?
user: playgithub
issue_9785: state: open
title: [bug] creating a package in "shared=True" mode cannot link to another package
body: Hello there,

I have two packages:
- mylib_a: no dependency
- mylib_b: call to mylib_a()

mylib_a package is created in local repo.
When I create a package for mylib_b, everything is fine in "Shared=False" mode but I get unresolved external symbol when "Shared=True".

### Environment Details
  * Operating System+version: Windows 10 Pro 20H2 19042.1237
  * Compiler+version: Visual Studio version 16
  * Conan version: 1.41.0
  * Python version: 3.9.7
  * Cmake version: 3.21.3

### Steps to reproduce
 * mylib_a creation
  `mkdir mylib_a`
  `cd .\mylib_a\`
  `conan new mylib_a/0.1 --template=cmake_lib`
  `conan create . demo/testing`
 * mylib_b creation
  `cd ..`
  `mkdir mylib_b`
  `cd .\mylib_b\`
  `conan new mylib_b/0.1 --template=cmake_lib`
    * add new conanfile.txt
    ` [requires]`
    ` mylib_a/0.1`
    ` [generators]`
    ` cmake`
   * Update CMakeLists.txt: [CMakeLists.txt](https://github.com/conan-io/conan/files/7335394/CMakeLists.txt)
   * Update conanfile.py: [conanfile.py.txt](https://github.com/conan-io/conan/files/7335414/conanfile.py.txt)
  `conan create . demo/testing`
  => sucess
   * Update conanfile.py ("Shared=True"): [conanfile.py.txt](https://github.com/conan-io/conan/files/7335399/conanfile.py.txt)
  `conan create . demo/testing`
  => Error
 



### Logs (Executed commands with output)
PS C:\Users\ja\mylib_b> conan create . demo/testing
Exporting package recipe
mylib_b/0.1@demo/testing exports_sources: Copied 2 '.txt' files: CMakeLists.txt, conanfile.txt
mylib_b/0.1@demo/testing exports_sources: Copied 1 '.cpp' file: mylib_b.cpp
mylib_b/0.1@demo/testing exports_sources: Copied 1 '.h' file: mylib_b.h
mylib_b/0.1@demo/testing: A new conanfile.py version was exported
mylib_b/0.1@demo/testing: Folder: C:\Users\ja\.conan\data\mylib_b\0.1\demo\testing\export
mylib_b/0.1@demo/testing: Package recipe modified in export, forcing source folder removal
mylib_b/0.1@demo/testing: Use the --keep-source, -k option to skip it
mylib_b/0.1@demo/testing: Exported revision: 9bd743017b7f9bb8662ed872a24d63f7
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.cppstd=14
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

mylib_b/0.1@demo/testing: Forced build from source
mylib_b/0.1@demo/testing (test package): Installing package
Requirements
    mylib_a/0.1@demo/testing from local cache - Cache
    mylib_b/0.1@demo/testing from local cache - Cache
Packages
    mylib_a/0.1@demo/testing:3fb49604f9c2f729b85ba3115852006824e72cab - Cache
    mylib_b/0.1@demo/testing:6d2b4ae464e3c3c02c2d57557199caad7282112c - Build

Installing (downloading, building) binaries...
mylib_a/0.1@demo/testing: Already installed!
mylib_b/0.1@demo/testing: Configuring sources in C:\Users\ja\.conan\data\mylib_b\0.1\demo\testing\source
mylib_b/0.1@demo/testing: Copying sources to build folder
mylib_b/0.1@demo/testing: Building your package in C:\Users\ja\.conan\data\mylib_b\0.1\demo\testing\build\6d2b4ae464e3c3c02c2d57557199caad7282112c
mylib_b/0.1@demo/testing: Generator txt created conanbuildinfo.txt
mylib_b/0.1@demo/testing: Calling generate()
mylib_b/0.1@demo/testing: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
mylib_b/0.1@demo/testing: Aggregating env generators
mylib_b/0.1@demo/testing: Calling build()
mylib_b/0.1@demo/testing: CMake command: cmake -G "Visual Studio 16 2019" -DCMAKE_TOOLCHAIN_FILE="C:/Users/ja/.conan/data/mylib_b/0.1/demo/testing/build/6d2b4ae464e3c3c02c2d57557199caad7282112c/build/conan/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/ja/.conan/data/mylib_b/0.1/demo/testing/package/6d2b4ae464e3c3c02c2d57557199caad7282112c" "C:\Users\ja\.conan\data\mylib_b\0.1\demo\testing\build\6d2b4ae464e3c3c02c2d57557199caad7282112c\."
Using Conan toolchain through C:/Users/ja/.conan/data/mylib_b/0.1/demo/testing/build/6d2b4ae464e3c3c02c2d57557199caad7282112c/build/conan/conan_toolchain.cmake.
-- Conan C++ Standard 14 with extensions OFF}
-- Conan toolchain: Setting BUILD_SHARED_LIBS= ON
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19042.
-- The CXX compiler identification is MSVC 19.29.30136.0
-- Detecting CXX compiler ABI info
Using Conan toolchain through .
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Downloading conan.cmake from https://github.com/conan-io/cmake-conan
-- Conan: Using cmake-multi generator
-- Conan: Automatic detection of conan settings from cmake
-- Conan: Detected VS runtime: MD
-- Conan: Settings= -s;arch=x86_64;-s;build_type=Release;-s;compiler=Visual Studio;-s;compiler.version=16;-s;compiler.runtime=MD
-- Conan: checking conan executable
-- Conan: Found program C:/Users/ja/AppData/Local/Packages/PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0/LocalCache/local-packages/Python39/Scripts/conan.exe
-- Conan: Version found Conan version 1.41.0

-- Conan executing: C:/Users/ja/AppData/Local/Packages/PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0/LocalCache/local-packages/Python39/Scripts/conan.exe install C:/Users/ja/.conan/data/mylib_b/0.1/demo/testing/build/6d2b4ae464e3c3c02c2d57557199caad7282112c/conanfile.txt -s arch=x86_64 -s build_type=Release -s compiler=Visual Studio -s compiler.version=16 -s compiler.runtime=MD -g=cmake_multi --build=missing
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.cppstd=14
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

conanfile.txt: Installing package
Requirements
    mylib_a/0.1@demo/testing from local cache - Cache
Packages
    mylib_a/0.1@demo/testing:3fb49604f9c2f729b85ba3115852006824e72cab - Cache

Installing (downloading, building) binaries...
mylib_a/0.1@demo/testing: Already installed!
conanfile.txt: Generator txt created conanbuildinfo.txt
conanfile.txt: Generator cmake created conanbuildinfo.cmake
conanfile.txt: Generator cmake_multi created conanbuildinfo_release.cmake
conanfile.txt: Generator cmake_multi created conanbuildinfo_multi.cmake
conanfile.txt: Aggregating env generators
conanfile.txt: Generated conaninfo.txt
conanfile.txt: Generated graphinfo
-- Conan: Automatic detection of conan settings from cmake
-- Conan: Detected VS runtime: MDd
-- Conan: Settings= -s;arch=x86_64;-s;build_type=Debug;-s;compiler=Visual Studio;-s;compiler.version=16;-s;compiler.runtime=MDd
-- Conan: checking conan executable
-- Conan: Found program C:/Users/ja/AppData/Local/Packages/PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0/LocalCache/local-packages/Python39/Scripts/conan.exe
-- Conan: Version found Conan version 1.41.0

-- Conan executing: C:/Users/ja/AppData/Local/Packages/PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0/LocalCache/local-packages/Python39/Scripts/conan.exe install C:/Users/ja/.conan/data/mylib_b/0.1/demo/testing/build/6d2b4ae464e3c3c02c2d57557199caad7282112c/conanfile.txt -s arch=x86_64 -s build_type=Debug -s compiler=Visual Studio -s compiler.version=16 -s compiler.runtime=MDd -g=cmake_multi --build=missing
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=Visual Studio
compiler.cppstd=14
compiler.runtime=MDd
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

conanfile.txt: Installing package
Requirements
    mylib_a/0.1@demo/testing from local cache - Cache
Packages
    mylib_a/0.1@demo/testing:d057732059ea44a47760900cb5e4855d2bea8714 - Cache

Installing (downloading, building) binaries...
mylib_a/0.1@demo/testing: Already installed!
conanfile.txt: Generator txt created conanbuildinfo.txt
conanfile.txt: Generator cmake_multi created conanbuildinfo_debug.cmake
conanfile.txt: Generator cmake_multi created conanbuildinfo_multi.cmake
conanfile.txt: Generator cmake created conanbuildinfo.cmake
conanfile.txt: Aggregating env generators
conanfile.txt: Generated conaninfo.txt
conanfile.txt: Generated graphinfo
-- Conan: Loading conanbuildinfo_multi.cmake
-- Conan: Using cmake global configuration
-- Library mylib_a found C:/Users/ja/.conan/data/mylib_a/0.1/demo/testing/package/d057732059ea44a47760900cb5e4855d2bea8714/lib/mylib_a.lib
-- Library mylib_a found C:/Users/ja/.conan/data/mylib_a/0.1/demo/testing/package/3fb49604f9c2f729b85ba3115852006824e72cab/lib/mylib_a.lib
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Current conanbuildinfo.cmake directory: C:/Users/ja/.conan/data/mylib_b/0.1/demo/testing/build/6d2b4ae464e3c3c02c2d57557199caad7282112c/build
-- Configuring done
-- Build files have been written to: C:/Users/ja/.conan/data/mylib_b/0.1/demo/testing/build/6d2b4ae464e3c3c02c2d57557199mylib_b/0.1@demo/testing: CMake command: cmake --build C:\Users\ja\.conan\data\mylib_b\0.1\demo\testing\build\6d2b4ae464Microsoft (R) Build Engine version 16.11.1+3e40a09f8 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

  Checking Build System
  Building Custom Rule C:/Users/ja/.conan/data/mylib_b/0.1/demo/testing/build/6d2b4ae464e3c3c02c2d57557199caad7282112c/
  CMakeLists.txt
  mylib_b.cpp
     Creating library C:/Users/ja/.conan/data/mylib_b/0.1/demo/testing/build/6d2b4ae464e3c3c02c2d57557199caad7282112c/b
  uild/Release/mylib_b.lib and object C:/Users/ja/.conan/data/mylib_b/0.1/demo/testing/build/6d2b4ae464e3c3c02c2d575571
  99caad7282112c/build/Release/mylib_b.exp
mylib_b.obj : error LNK2019: unresolved external symbol "void __cdecl mylib_a(void)" (?mylib_a@@YAXXZ) referenced in fu
nction "void __cdecl mylib_b(void)" (?mylib_b@@YAXXZ) [C:\Users\ja\.conan\data\mylib_b\0.1\demo\testing\build\6d2b4ae46
4e3c3c02c2d57557199caad7282112c\build\mylib_b.vcxproj]
C:\Users\ja\.conan\data\mylib_b\0.1\demo\testing\build\6d2b4ae464e3c3c02c2d57557199caad7282112c\build\Release\mylib_b.d
ll : fatal error LNK1120: 1 unresolved externals [C:\Users\ja\.conan\data\mylib_b\0.1\demo\testing\build\6d2b4ae464e3c3
c02c2d57557199caad7282112c\build\mylib_b.vcxproj]
mylib_b/0.1@demo/testing:
mylib_b/0.1@demo/testing: ERROR: Package '6d2b4ae464e3c3c02c2d57557199caad7282112c' build failed
mylib_b/0.1@demo/testing: WARN: Build folder C:\Users\ja\.conan\data\mylib_b\0.1\demo\testing\build\6d2b4ae464e3c3c02c2d57557199caad7282112c\build
ERROR: mylib_b/0.1@demo/testing: Error in build() method, line 40
        cmake.build()
        ConanException: Error 1 while executing cmake --build C:\Users\ja\.conan\data\mylib_b\0.1\demo\testing\build\6d2b4ae464e3c3c02c2d57557199caad7282112c\build --config Release

user: julienalofs
issue_9784: state: open
title: [question] How to override or prevent auto-linking that a requirement does?
body: <!-- What is your question? Please be as specific as possible! -->

Let's start this as a question. What's the best way to override the way a requirement links to a transitive requirement?

Scenario: The new Boost recipe automatically causes linking to `icu::icu`, but we don't want to ship _all_ the ICU dylibs, only the ones that are necessary. To do that, our program links ICU manually. Which is fine, except that the build ends up linking part of ICU (for our program) and then all of ICU (for Boost).

The problem is that on macOS, for instance, if you link to a `.dylib`, it gets included in the loaded dylibs whether you are actually calling it or not, and the program won't start without the dylib being there.

This is my workaround for now:

```python
    def generate(self):
        # The code wants to link a customized list of ICU binaries.
        # Remove the auto-requirements for ICU from Boost before generating
        # the packages.
        def remove_icu(requires):
            if 'icu::icu' in requires:
                requires.remove('icu::icu')
        remove_icu(self.deps_cpp_info['boost'].requires)
        remove_icu(self.deps_cpp_info['boost'].components['locale'].requires)
        remove_icu(self.deps_cpp_info['boost'].components['regex'].requires)

        deps = CMakeDeps(self)
        deps.generate()
```

And then in the `CMakeLists.txt` we do something like:

```cmake
  find_package(ICU REQUIRED COMPONENTS uc in data)
  set(PROG_ICU_LIBS ICU::uc ICU::in ICU::data)
```

...and targets set `${PROG_ICU_LIBS}` as an argument to `target_link_libraries()`.

(And on macOS, we link to imported copies of the ICU dylibs where we used `install_name_tool` to change the `install_name` to use `@rpath`.)

It works, but it seems a little roundabout. Is there a better way?

A related fix might involve fixing up the Boost recipe to only link ICU components that are actually in use.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: datalogics-kam
issue_9783: state: open
title: [bug] CMakeToolchain does not properly set CMAKE_TRY_COMPILE_TARGET_TYPE for bare metal targets
body: ### Environment Details (include every applicable attribute)

  *  Operating System+version: Fedora Silverblue 35
  *  Compiler+version: GCC 11
  *  Conan version: 1.41.0
  *  Python version: 3.10

### Steps to reproduce (Include if Applicable)

For bare metal targets, CMakeToolchain does not set `CMAKE_TRY_COMPILE_TARGET_TYPE` to `STATIC_LIBRARY` which is necessary for CMake to function when building for targets which do not have an operating system and therefore dynamic linking.
CMake will choke during the configure stage for such a target when checking the compiler.
It would probably be necessary to add a `bare` architecture setting in order to detect this scenario, which has been proposed in issue #4216.

This issue is also relevant to issue #9663
user: jwillikers
issue_9782: state: open
title: [bug] CMakeToolchain does not translate the arch setting for armv7hf
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Fedora Silverblue 35
  * Compiler+version: GCC 11
  * Conan version: 1.41.0
  * Python version: 3.10

### Steps to reproduce (Include if Applicable)

Building for many architectures is not yet supported in the CMakeToolchain generator.
For this specific use-case which is a bare-metal target, support for generating the related architecture flags for an Arm Cortex M4, `armv7hf`, is necessary.
Unfortunately, this requires more than just a single architecture flag and this also requires differentiating between `thumb`, i.e. `-mthumb`, instructions and vanilla Arm instructions, `-marm`, which are separate ISA's.
In case it helps, Rust distinguishes between Arm and thumb ISA's by prefixing the Arm version with `thumb`, i.e. `thumbv7em-none-eabihf`.
Alternatively, perhaps `thumb` could be accounted for with a sub-setting?
For `armv7hf`, the floating point unit support should also be accounted for, i.e. `-mfpu=fpv4-sp-d16` or as part of the `-march` flag to GCC like `-march=armv7e-m+fp`.
GCC Arm compiler options are well documented [here](https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html).

user: jwillikers
issue_9779: state: open
title: [feature] CMakeToolchain generator doesn't adequately represent settings nor does it follow a standard method of overriding C, CXX, and linker flags
body: The CMakeToolchain generator lacks critical functionality for implementing various Conan settings from the `settings.yaml` file, and it doesn't provide adequate control for consumers to control settings across dependencies.
The new CMakeToolchain generator is very helpful for orchestrating building and packaging CMake projects, but isn't robust enough to properly propagate settings from consumers to their dependencies.
Environment variables appear to be the only way to adequately propagate necessary compiler settings across dependencies using various build systems.
The new CMakeToolchain generator doesn't use the flags from these variables, but instead requires injecting a toolchain file for a dependency to inherit specific settings.
This seems to go against the idea of Conan's settings / profiles being used to influence configurations of dependencies across various projects and their dependencies since its specific to both the underlying build system of each project and also the Conan generators used by the project.

For a simple bare-metal embedded project which doesn't wish to modify the recipes for all of its dependencies, it must use only CMake dependencies if it wishes to use the `CMakeToolchain` generator and it has to do this through the profile configuration of either `user_toolchain` or `toolchain_file`.
This requires manually translating Conan settings to compiler flags in a toolchain file, which is error-prone and redundant since the compiler flags are capable of being deduced from the Conan settings configured in profiles, such as the architecture being translated to the necessary `-m` flags.

To properly translate Conan settings to compiler flags in the CMakeToolchain, the user can control the templating of the default CMakeToolchain generator, but this must be done for every single dependency and even using `python_requires` this just isn't feasible for people that want to use existing package recipes from Conan Center.

It seems like there should be *way* more settings in `settings.yaml` to translate down to all the various compiler flags for this to work and / or a standard way to inject arbitrary C, CXX, and linker flags across all the various build-system generators directly from profiles.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: jwillikers
labels: component: Build: Build helpers, build systems..
issue_9777: state: open
title: [bug] Conan cannot be installed through Winget due to Windows defender blocking AppInstallerCLI.exe
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Win 11
  * Compiler+version: - 
  * Conan version: 1.41.0
  * Python version: 3.9

### Steps to reproduce (Include if Applicable)

Try to install Conan using Winget.

I use the protected folders feature of Windows Defender, but the Conan installer should not need to modify those folders! The warning that I get is not also related to protected folders.

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

Blocked: AppInstallerCLI.exe
Blocked by: Attack surface reduction
Rule: Use advanced protection against ransomware
Affected: C:\Users\aminy\AppData\Local\Temp\WinGet\JFrog.Conan.1.41.0.exe

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/troubleshoot-asr?view=o365-worldwide

The link says that this only applies to Enterprise Windows, although I am on a normal edition. 

![image](https://user-images.githubusercontent.com/16418197/136927743-b72eb453-1609-4c59-913d-00a5eab10661.png)


user: aminya
issue_9808: state: open
title: [question] Force cross compilation
body: Hello everyone,
I have a question regarding the cross compilation detection in conan. Reading the code I saw we assume cross compilation is enabled if `os` and / or `arch` is different between host and build. I managed to embed a Linux SDK for several targets archs into a conan package of my own. However I face compilation issues for x86 / x86_64 because of missing compilation flags, due to conan not detecting my cross compilation scenario. I was wondering if we shouldn't add an environment variable to force cross compilation, for instance `CONAN_CROSS_COMPILATION`.
NB : The code I build using my SDK is not intended to run on the build machine. I updated my conan settings to ensure all the dependencies get build using my SDK, avoiding contamination. 
Regards
user: upsilona
issue_9775: state: open
title: [bug] not possible to override sub-dependency
body: ### Environment Details (include every applicable attribute)
  * OS independent:
  * Compiler independent:
  * Conan version 1.40:
  * Python version 3.6.9:

### Steps to reproduce (Include if Applicable)
conan install gst-plugins-base/1.19.1@ --build=gst-plugins-base

### Logs (Executed commands with output) (Include/Attach if Applicable)
ERROR: Conflict in flex/2.6.4:
    'flex/2.6.4' requires 'm4/1.4.19' while 'bison/3.7.6' requires 'm4/1.4.18'.
    To fix this conflict you need to override the package 'm4' in your root package.


Ok, we see some probles with dependency, let's try to fix it via conanfile.txt:
[requires]
gst-plugins-base/1.19.1
m4/1.4.19

execute comand:
conan install . --build=gst-plugins-base

get same result:
ERROR: Conflict in flex/2.6.4:
    'flex/2.6.4' requires 'm4/1.4.19' while 'bison/3.7.6' requires 'm4/1.4.18'.
    To fix this conflict you need to override the package 'm4' in your root package.

not possible to  override sub-dependency, but for direct dependency - all ok.



user: udovenkoav1981
issue_9772: state: open
title: [feature] Accept verbose build for Meson
body: The new [Meson](https://docs.conan.io/en/latest/reference/conanfile/tools/meson.html#meson) build helper does not offer a way to execute a verbose build, when used with `MesonToolchain`. So far, we need to trick `target` argument with `--verbose`. My suggestion is adding a new parameter to be used when building:

```python
from conans import ConanFile
from conan.tools.meson import Meson, MesonToolchain

class App(ConanFile):
    settings = "os", "arch", "compiler", "build_type"
    requires = "hello/0.1"
    generators = "pkg_config"

    def generate(self):
        tc = MesonToolchain(self)
        tc.generate()

    def build(self):
        meson = Meson(self)
	    meson.configure(source_folder="src")
	    meson.build(verbose=True)
```

It will be equivalent to:

    meson compile -C "src/" --verbose


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: uilianries
issue_9765: state: open
title: [feature] pkg-config improved UX for custom variables
body: <!-- What is your suggestion? Please be as specific as possible! -->

there is a [pkg_config_custom_content](https://docs.conan.io/en/latest/reference/conanfile/attributes.html?highlight=pkg_config_custom_content) property, but it uses an arbitrary string blob to insert.
it would be nice to have an improved UX to pass a dictionary of variables, just like in CMakeDeps (see #9764, #8360):
```
self.cpp_info.set_property("pkg_config_variables", {'datadir': '${prefix}/res'}, "pkg_config")
self.cpp_info.components["buy"].set_property("pkg_config_variables",  {'datadir': '${prefix}/res'}, "pkg_config")
```
a few examples in conan-center:
https://github.com/conan-io/conan-center-index/blob/master/recipes/glib/all/conanfile.py#L300
https://github.com/conan-io/conan-center-index/blob/master/recipes/wayland/all/conanfile.py#L102
https://github.com/conan-io/conan-center-index/blob/master/recipes/xorg-macros/all/conanfile.py#L73

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: SSE4
issue_9764: state: open
title: [feature] CMakeDeps : custom variables
body: <!-- What is your suggestion? Please be as specific as possible! -->

might be something similar to #8360

need to think about UX a bit, as some variables need conditions
the usage is pretty common in conan-center
examples:
https://github.com/conan-io/conan-center-index/blob/master/recipes/libxml2/all/conanfile.py#L320
https://github.com/conan-io/conan-center-index/blob/master/recipes/freetype/all/conanfile.py#L183
https://github.com/conan-io/conan-center-index/blob/master/recipes/openal/all/conanfile.py#L130
https://github.com/conan-io/conan-center-index/blob/master/recipes/sqlite3/all/conanfile.py#L152
https://github.com/conan-io/conan-center-index/blob/master/recipes/openssl/1.x.x/conanfile.py#L821

the syntax may look like this:
```
self.cpp_info.set_property("cmake_variables", {"LIBXML2_INCLUDE_DIR":  "LibXml2_INCLUDE_DIR"}, "CMakeDeps")
self.cpp_info.components["buy"].set_property("cmake_variables",  {"LIBXML2_INCLUDE_DIR":  "LibXml2_INCLUDE_DIR"}, "CMakeDeps")
```

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: SSE4
issue_9763: state: open
title: boost/1.72.0 bug
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: window 10 pro
  * Compiler+version: gcc + 8
  * Conan version: 1.41
  * Python version:  3.8.8


------ by running this comman >conan install .. --build=missing

ERROR: Error, the file to download already exists: 'C:\Users\Lenovo\.conan\data\boost\1.72.0\_\_\dl\export\conan_sources.tgz'. [Remote: conancenter]
The 'boost/1.72.0' package has 'exports_sources' but sources not found in local cache.
Probably it was installed from a remote that is no longer available.



any clue on this??? 
user: ghost
issue_9738: state: open
title: [feature] github authenticator
body: <!-- What is your suggestion? Please be as specific as possible! -->
Hi. Conan github authenticator can be useful for some cases, like https://github.com/conan-io/conan-center-index/issues/4

user: n-bes
issue_9733: state: open
title: Do not retry a download if there is no more space on the device.
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

ERROR: Download failed, check server, possibly try again
**[Errno 28] No space left on device**
Waiting 0 seconds to retry...

Downloading conan_package.tgz:   0%|          | 700k/655M [00:00<05:38, 2.03MB/s
Downloading conan_package.tgz:   0%|          | 1.17M/655M [00:00<03:54, 2.93MB/
Downloading conan_package.tgz:   0%|          | 1.76M/655M [00:00<03:06, 3.68MB/
Downloading conan_package.tgz:   0%|          | 2.25M/655M [00:00<02:48, 4.07MB/
Downloading conan_package.tgz:   0%|          | 2.83M/655M [00:00<02:34, 4.43MB/
Downloading conan_package.tgz:   1%|          | 3.42M/655M [00:00<02:27, 4.63MB/
Downloading conan_package.tgz:   1%|          | 4.00M/655M [00:01<02:22, 4.81MB/
....



<img width="762" alt="no_space_no_retry" src="https://user-images.githubusercontent.com/52277783/136022117-ffac2525-8979-4c4d-b629-efc69fca54a7.png">


user: dmn-star
issue_9732: state: open
title: [question] Invoking package creation for different patch versions of dependencies
body: The subject doesn't do the question justice, so will explain further here. There is a real example of this which I'm looking at right now, but this is simplified.

Suppose we have:
* a mid-graph package called M, which has a runtime requirement on P, where
* package P at version 5.x.y, which contains shared libraries.
* An application A consumes M.

In theory, due to our default package_ids using semver, I can specify different patch versions of P in A's recipe, without needing to make any changes to M.

Unfortunately, P has a breaking change in a patch release, so doing the above breaks in M. (In reality, I get a runtime symbol lookup error on Mac in a dylib, due to there being different symbols between what was built and was is used at runtime, as a symbol has been removed in the latest patch.)


What I believe I need is a build against M that is different for the different patch versions of P.

I first thought I could reach for changing `semver_mode()` to `full_version_mode()` in M's recipe in respect of P, so that I get different package_ids for different builds of M, and downstream in A, I can specify my desired requirements to match a package_id of M. That sounds like what I want.

But then I had to stop, and think, how do I tell `conan create` (or local workflow), that I want two builds of M, with different versions of P? i.e. how can I affect `self.requires()` in M's recipe from the command line?

It could be a recipe option, but that would then make the package_id change redundant. So that doesn't seem right.

Am I trying to do something that isn't recommended?
Or am I missing a workflow?

Thanks!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: foundry-markf
issue_9729: state: open
title: [question] workaround Azure upload size limit?
body: Hi everyone,

we have some conan packages which are of massive size (6 GB) which now leads to problems when we try to upload those to Artifactory hosted in Azure. It seems that Azure has a size limitation of uploads of 4 GB as is also documented in
https://github.com/MicrosoftDocs/azure-docs/blob/master/includes/application-gateway-limits.md (5th last row)

We are looking already how to split our package to stay clear of this limit, but still i wonder if it wouldn't make sense for conan to handle such issue transparently by splitting conan_package.tgz into multiple files (< 4GB) during upload, and assembling it back locally when downloading.

Would such a feature request (/contribution?) make sense also for others? Would it have a chance to get merged?
user: jsteinhofff
issue_9720: state: open
title: [question] Declaring dependencies with meson subprojects
body: <!-- What is your question? Please be as specific as possible! -->

I have a parent project A and a subproject B, both using meson, I want to compile A which means B must also be compiled. A does not explicitly list most of the dependencies of B, which means that when I try to compile meson fails because it cannot find the pc files (it is searching them in the installation folder of A). Botha A and B have a conan file, what is the recommended approach to setting up the dependencies such that A can compile without having to manually list all the dependencies of B as well?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Makogan
issue_9707: state: open
title: [question] Why requirement overridden by conanfile.txt does not affect package id?
body: I have the following `conanfile.txt`:
```
[requires]
boost/1.75.0-crypto1#4a232389c0e69e97cd1ba355746f3240
folly/2021.05.17.00#22a858c5a5f37e56090a4fe7ff253130
```

When I run `conan install conanfile.txt` here is what I see:
```
Requirements
    boost/1.75.0-crypto1 from local cache - Cache
    folly/2021.05.17.00 from local cache - Cache
Packages
    boost/1.75.0-crypto1:5192f911b1d09eae3e8ed7d7ccb33c7e49d1a208 - Cache
    folly/2021.05.17.00:9e1fadd5f24432ec43e01f6416e3ea0a3d6121dc - Download

WARN: folly/2021.05.17.00: requirement boost/1.75.0 overridden by your conanfile to boost/1.75.0-crypto1 
```

And let's take a look at the selected folly package:
```
$ conan search folly/2021.05.17.00@
Existing packages for recipe folly/2021.05.17.00:

    Package_ID: 9e1fadd5f24432ec43e01f6416e3ea0a3d6121dc
        [options]
            fPIC: True
            shared: False
        [settings]
            arch: x86_64
            build_type: Release
            compiler: clang
            compiler.cppstd: 20
            compiler.libcxx: libstdc++11
            compiler.version: 12
            os: Linux
        [requires]
            boost/1.75.0:5192f911b1d09eae3e8ed7d7ccb33c7e49d1a208
            <other reqs>
        Outdated from recipe: False
```

Conan aknowledged that I am using custom boost version `1.75.0-crypto1`, but it uses folly package built against a different boost version `1.75.0`! Why is that so? I would expect folly to be rebuilt with my version of boost.

I can see how packages for both `boost/1.75.0-crypto1` and `boost/1.75.0` have the same package id. I assume this is ok since they are using the same `settings`, `options` and `requires`. But they have different _version_, which should affect `requries` for folly yielding different package ids for builds against `boost/1.75.0-crypto1` and `boost/1.75.0`.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: mmatrosov
issue_9704: state: open
title: Modernize conan.tools.qbs
body: Changelog: (Fix): Modernize conan.tools.qbs #9702

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 

<sup>**Note:** By default this PR will skip the slower tests and will use a limited set of python versions. Check [here](https://github.com/conan-io/conan/blob/develop/.github/PR_INCREASE_TESTING.md) how to increase the testing level by writing some tags in the current PR body text.</sup>

user: Psy-Kai
issue_9702: state: open
title: [feature] Modernize QbsProfile
body: ``conan.tools.qbs`` need modernization. It needs to remove its dependency to ``from conans import tools``, and use helpers only from ``conan.tools``. Not all of them might be available yet, but will be added as needed.

Meanwhile, this integration might be disabled from 2.0 ``develop2`` branch, because ``from conans import tools`` will be removed in 2.0

cc @Psy-Kai 
user: memsharded
labels: component: Build: Build helpers, build systems..
issue_9700: state: open
title: [question] What's the use of `host_name` in `conan_server` config?
body: I've tried to change it to 127.0.0.1 or 192.168.*.* and reboot,
But the listening address doesn't change, it is always 0.0.0.0

```bash
 $ netstat -tunlp  | grep 9300
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:9300            0.0.0.0:*               LISTEN      554/python3
```
user: playgithub
issue_9695: state: open
title: [question] Unable to connect to conancenter=https://center.conan.io
body: ## Env
OS: Windows 10
conan: 1.40.2

## Log
```
λ conan search boost -r conancenter
ERROR: HTTPSConnectionPool(host='center.conan.io', port=443): Max retries exceeded with url: /v1/ping (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1129)')))

Unable to connect to conancenter=https://center.conan.io
1. Make sure the remote is reachable or,
2. Disable it by using conan remote disable,
Then try again.
```

```
λ conan create . # for local recipe
...
rapidjson/cci.20200410: Not found in local cache, looking in remotes...
rapidjson/cci.20200410: Trying with 'conancenter'...
ERROR: Failed requirement 'rapidjson/cci.20200410' from 'cppjieba/2.0.0'
ERROR: HTTPSConnectionPool(host='center.conan.io', port=443): Max retries exceeded with url: /v1/ping (Caused by SSLError(SSLEOFError(8, 'EOF occurred in violation of protocol (_ssl.c:1129)')))

Unable to connect to conancenter=https://center.conan.io
1. Make sure the remote is reachable or,
2. Disable it by using conan remote disable,
Then try again.
```

## More Info
It worked well several days ago, but failed today.
user: playgithub
issue_9672: state: open
title: Tests failing only on i686-linux 
body: #### Environment Details (include every applicable attribute)

    Operating System+version: GNU Guix, main branch
    Compiler+version: GCC 7.5.0
    Conan version: 1.40.2
    Python version: 3.8.2

#### Steps to reproduce (Include if Applicable)

Build a newly defined conan package for Guix, which is built in a container with the the following direct dependencies:

```
autoconf@2.69 automake@1.16.2 cmake@3.21.1 coreutils@8.32 git-minimal@2.33.0 meson@0.55.1 ninja@1.10.0 pkg-config@0.29.2 python-bottle@0.12.19 python-colorama@0.4.4 python-dateutil@2.8.1
+ python-distro@1.4.0 python-fasteners@0.15 python-future@0.17.1 python-jinja2@2.11.2 python-mock@3.0.5 python-node-semver@0.8.1 python-parameterized@0.7.4 python-patch-ng@1.17.4 python-pluginbase@1.0.1
+ python-pygments@2.7.3 python-pyjwt@1.7.1 python-pytest-xdist@1.34.0 python-pytest@5.3.5 python-pyyaml@5.4.1 python-requests@2.25.0 python-six@1.14.0 python-tqdm@4.43.0 python-urllib3@1.26.7
+ python-webtest@2.0.35 which@2.21
```

#### Logs

These tests all pass on x86_64-linux, but fail on i686-linux:

```
=================================== FAILURES ===================================
_______________________________ test_cpp_package _______________________________
[gw12] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

    def test_cpp_package():
        client = TestClient()
    
        conan_hello = textwrap.dedent("""
            import os
            from conans import ConanFile
            from conan.tools.files import save
            class Pkg(ConanFile):
                def package(self):
                    save(self, os.path.join(self.package_folder, "foo/include/foo.h"), "")
                    save(self, os.path.join(self.package_folder,"foo/libs/foo.lib"), "")
    
                def layout(self):
                    self.cpp.package.includedirs = ["foo/include"]
                    self.cpp.package.libdirs = ["foo/libs"]
                    self.cpp.package.libs = ["foo"]
                 """)
    
        client.save({"conanfile.py": conan_hello})
        client.run("create . hello/1.0@")
    
        conan_consumer = textwrap.dedent("""
            from conans import ConanFile
            class HelloTestConan(ConanFile):
                settings = "os", "compiler", "build_type", "arch"
                requires = "hello/1.0"
                generators = "CMakeDeps"
                def generate(self):
                    info = self.dependencies["hello"].cpp_info
                    self.output.warn("**includedirs:{}**".format(info.includedirs))
                    self.output.warn("**libdirs:{}**".format(info.libdirs))
                    self.output.warn("**libs:{}**".format(info.libs))
            """)
    
        client.save({"conanfile.py": conan_consumer})
        client.run("install .")
        assert "**includedirs:['foo/include']**" in client.out
        assert "**libdirs:['foo/libs']**" in client.out
        assert "**libs:['foo']**" in client.out
>       cmake = client.load("hello-release-x86_64-data.cmake")

conans/test/functional/layout/test_in_cache.py:268: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmplx9g5uofconans/path with spaces/hello-release-x86_64-data.cmake'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmplx9g5uofconans/path with spaces/hello-release-x86_64-data.cmake'

conans/util/files.py:232: FileNotFoundError
_________________ test_exclude_code_analysis[['*']-True-True] __________________
[gw14] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

pattern = "['*']", exclude_a = True, exclude_b = True

    @pytest.mark.parametrize("pattern,exclude_a,exclude_b",
                             [("['*']", True, True),
                              ("['pkga']", True, False),
                              ("['pkgb']", False, True),
                              ("['pkg*']", True, True),
                              ("['pkga', 'pkgb']", True, True),
                              ("['*a', '*b']", True, True),
                              ("['nonexist']", False, False),
                              ])
    def test_exclude_code_analysis(pattern, exclude_a, exclude_b):
        client = TestClient()
        client.save({"conanfile.py": GenConanfile()})
        client.run("create . pkga/1.0@")
        client.run("create . pkgb/1.0@")
    
        conanfile = textwrap.dedent("""
            from conans import ConanFile
            from conan.tools.microsoft import MSBuild
    
            class HelloConan(ConanFile):
                settings = "os", "build_type", "compiler", "arch"
                requires = "pkgb/1.0@", "pkga/1.0"
                generators = "msbuild"
                def build(self):
                    msbuild = MSBuild(self)
                    msbuild.build("MyProject.sln")
            """)
        profile = textwrap.dedent("""
            include(default)
            build_type=Release
            arch=x86_64
            [conf]
            tools.microsoft.msbuilddeps:exclude_code_analysis = %s
            """ % pattern)
    
        client.save({"conanfile.py": conanfile,
                     "profile": profile})
        client.run("install . --profile profile")
>       depa = client.load("conan_pkga_release_x64.props")

conans/test/functional/toolchains/microsoft/test_msbuilddeps.py:684: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmpz4ku0iluconans/path with spaces/conan_pkga_release_x64.props'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmpz4ku0iluconans/path with spaces/conan_pkga_release_x64.props'

conans/util/files.py:232: FileNotFoundError
_______________ PropagateSpecificComponents.test_cmakedeps_multi _______________
[gw2] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

self = <conans.test.functional.toolchains.cmake.cmakedeps.test_cmakedeps_components.PropagateSpecificComponents testMethod=test_cmakedeps_multi>

    def test_cmakedeps_multi(self):
        t = TestClient(cache_folder=self.cache_folder)
        t.run('install middle/version@ -g CMakeDeps')
    
>       content = t.load('middle-release-x86_64-data.cmake')

conans/test/functional/toolchains/cmake/cmakedeps/test_cmakedeps_components.py:72: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmpvp1g27v4conans/path with spaces/middle-release-x86_64-data.cmake'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmpvp1g27v4conans/path with spaces/middle-release-x86_64-data.cmake'

conans/util/files.py:232: FileNotFoundError
________________ test_exclude_code_analysis[['pkg*']-True-True] ________________
[gw17] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

pattern = "['pkg*']", exclude_a = True, exclude_b = True

    @pytest.mark.parametrize("pattern,exclude_a,exclude_b",
                             [("['*']", True, True),
                              ("['pkga']", True, False),
                              ("['pkgb']", False, True),
                              ("['pkg*']", True, True),
                              ("['pkga', 'pkgb']", True, True),
                              ("['*a', '*b']", True, True),
                              ("['nonexist']", False, False),
                              ])
    def test_exclude_code_analysis(pattern, exclude_a, exclude_b):
        client = TestClient()
        client.save({"conanfile.py": GenConanfile()})
        client.run("create . pkga/1.0@")
        client.run("create . pkgb/1.0@")
    
        conanfile = textwrap.dedent("""
            from conans import ConanFile
            from conan.tools.microsoft import MSBuild
    
            class HelloConan(ConanFile):
                settings = "os", "build_type", "compiler", "arch"
                requires = "pkgb/1.0@", "pkga/1.0"
                generators = "msbuild"
                def build(self):
                    msbuild = MSBuild(self)
                    msbuild.build("MyProject.sln")
            """)
        profile = textwrap.dedent("""
            include(default)
            build_type=Release
            arch=x86_64
            [conf]
            tools.microsoft.msbuilddeps:exclude_code_analysis = %s
            """ % pattern)
    
        client.save({"conanfile.py": conanfile,
                     "profile": profile})
        client.run("install . --profile profile")
>       depa = client.load("conan_pkga_release_x64.props")

conans/test/functional/toolchains/microsoft/test_msbuilddeps.py:684: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmpiehi1kr5conans/path with spaces/conan_pkga_release_x64.props'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmpiehi1kr5conans/path with spaces/conan_pkga_release_x64.props'

conans/util/files.py:232: FileNotFoundError
_____________________ test_locally_build_linux[Debug-True] _____________________
[gw22] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

build_type = 'Debug', shared = True
client = <conans.test.utils.tools.TestClient object at 0xf3ad14d8>

    @pytest.mark.skipif(platform.system() != "Linux", reason="Only Linux")
    @pytest.mark.parametrize("build_type,shared", [("Release", False), ("Debug", True)])
    @pytest.mark.tool_compiler
    @pytest.mark.tool_ninja
    def test_locally_build_linux(build_type, shared, client):
        settings = "-s os=Linux -s arch=x86_64 -s build_type={} -o hello:shared={}".format(build_type,
                                                                                           shared)
        client.run("install . {}".format(settings))
        client.run_command('cmake . -G "Ninja" -DCMAKE_TOOLCHAIN_FILE={}'
                           .format(CMakeToolchain.filename))
    
>       client.run_command('ninja')

conans/test/functional/toolchains/cmake/test_ninja.py:68: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:576: in run_command
    self._handle_cli_result(command, assert_error=assert_error, error=ret)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <conans.test.utils.tools.TestClient object at 0xf3ad14d8>
command = 'ninja', assert_error = False, error = 1

    def _handle_cli_result(self, command, assert_error, error):
        if (assert_error and not error) or (not assert_error and error):
            if assert_error:
                msg = " Command succeeded (failure expected): "
            else:
                msg = " Command failed (unexpectedly): "
            exc_message = "\n{header}\n{cmd}\n{output_header}\n{output}\n{output_footer}\n".format(
                header='{:-^80}'.format(msg),
                output_header='{:-^80}'.format(" Output: "),
                output_footer='-' * 80,
                cmd=command,
                output=self.out
            )
>           raise Exception(exc_message)
E           Exception: 
E           ------------------------ Command failed (unexpectedly): ------------------------
E           ninja
E           ----------------------------------- Output: ------------------------------------
E           [1/4] Building CXX object CMakeFiles/mylibrary.dir/hello.cpp.o
E           FAILED: CMakeFiles/mylibrary.dir/hello.cpp.o 
E           /gnu/store/afpgzln8860m6yfhxy6i8n9rywbp85cy-gcc-7.5.0/bin/c++ -D_GLIBCXX_USE_CXX11_ABI=0 -Dmylibrary_EXPORTS  -m64 -g -fPIC -MD -MT CMakeFiles/mylibrary.dir/hello.cpp.o -MF CMakeFiles/mylibrary.dir/hello.cpp.o.d -o CMakeFiles/mylibrary.dir/hello.cpp.o -c /tmp/guix-build-conan-1.40.2.drv-0/tmpor3gzs92conans/pathwithoutspaces/hello.cpp
E           cc1plus: sorry, unimplemented: 64-bit mode not compiled in
E           [2/4] Building CXX object CMakeFiles/myapp.dir/main.cpp.o
E           FAILED: CMakeFiles/myapp.dir/main.cpp.o 
E           /gnu/store/afpgzln8860m6yfhxy6i8n9rywbp85cy-gcc-7.5.0/bin/c++ -D_GLIBCXX_USE_CXX11_ABI=0  -m64 -g -MD -MT CMakeFiles/myapp.dir/main.cpp.o -MF CMakeFiles/myapp.dir/main.cpp.o.d -o CMakeFiles/myapp.dir/main.cpp.o -c /tmp/guix-build-conan-1.40.2.drv-0/tmpor3gzs92conans/pathwithoutspaces/main.cpp
E           cc1plus: sorry, unimplemented: 64-bit mode not compiled in
E           ninja: build stopped: subcommand failed.
E           
E           --------------------------------------------------------------------------------

conans/test/utils/tools.py:592: Exception
_______________ test_exclude_code_analysis[['pkga']-True-False] ________________
[gw15] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

pattern = "['pkga']", exclude_a = True, exclude_b = False

    @pytest.mark.parametrize("pattern,exclude_a,exclude_b",
                             [("['*']", True, True),
                              ("['pkga']", True, False),
                              ("['pkgb']", False, True),
                              ("['pkg*']", True, True),
                              ("['pkga', 'pkgb']", True, True),
                              ("['*a', '*b']", True, True),
                              ("['nonexist']", False, False),
                              ])
    def test_exclude_code_analysis(pattern, exclude_a, exclude_b):
        client = TestClient()
        client.save({"conanfile.py": GenConanfile()})
        client.run("create . pkga/1.0@")
        client.run("create . pkgb/1.0@")
    
        conanfile = textwrap.dedent("""
            from conans import ConanFile
            from conan.tools.microsoft import MSBuild
    
            class HelloConan(ConanFile):
                settings = "os", "build_type", "compiler", "arch"
                requires = "pkgb/1.0@", "pkga/1.0"
                generators = "msbuild"
                def build(self):
                    msbuild = MSBuild(self)
                    msbuild.build("MyProject.sln")
            """)
        profile = textwrap.dedent("""
            include(default)
            build_type=Release
            arch=x86_64
            [conf]
            tools.microsoft.msbuilddeps:exclude_code_analysis = %s
            """ % pattern)
    
        client.save({"conanfile.py": conanfile,
                     "profile": profile})
        client.run("install . --profile profile")
>       depa = client.load("conan_pkga_release_x64.props")

conans/test/functional/toolchains/microsoft/test_msbuilddeps.py:684: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmp8kkzpy1dconans/path with spaces/conan_pkga_release_x64.props'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmp8kkzpy1dconans/path with spaces/conan_pkga_release_x64.props'

conans/util/files.py:232: FileNotFoundError
_______________ test_exclude_code_analysis[['pkgb']-False-True] ________________
[gw16] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

pattern = "['pkgb']", exclude_a = False, exclude_b = True

    @pytest.mark.parametrize("pattern,exclude_a,exclude_b",
                             [("['*']", True, True),
                              ("['pkga']", True, False),
                              ("['pkgb']", False, True),
                              ("['pkg*']", True, True),
                              ("['pkga', 'pkgb']", True, True),
                              ("['*a', '*b']", True, True),
                              ("['nonexist']", False, False),
                              ])
    def test_exclude_code_analysis(pattern, exclude_a, exclude_b):
        client = TestClient()
        client.save({"conanfile.py": GenConanfile()})
        client.run("create . pkga/1.0@")
        client.run("create . pkgb/1.0@")
    
        conanfile = textwrap.dedent("""
            from conans import ConanFile
            from conan.tools.microsoft import MSBuild
    
            class HelloConan(ConanFile):
                settings = "os", "build_type", "compiler", "arch"
                requires = "pkgb/1.0@", "pkga/1.0"
                generators = "msbuild"
                def build(self):
                    msbuild = MSBuild(self)
                    msbuild.build("MyProject.sln")
            """)
        profile = textwrap.dedent("""
            include(default)
            build_type=Release
            arch=x86_64
            [conf]
            tools.microsoft.msbuilddeps:exclude_code_analysis = %s
            """ % pattern)
    
        client.save({"conanfile.py": conanfile,
                     "profile": profile})
        client.run("install . --profile profile")
>       depa = client.load("conan_pkga_release_x64.props")

conans/test/functional/toolchains/microsoft/test_msbuilddeps.py:684: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmpn2zm5e4nconans/path with spaces/conan_pkga_release_x64.props'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmpn2zm5e4nconans/path with spaces/conan_pkga_release_x64.props'

conans/util/files.py:232: FileNotFoundError
______________ test_exclude_code_analysis[['*a', '*b']-True-True] ______________
[gw19] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

pattern = "['*a', '*b']", exclude_a = True, exclude_b = True

    @pytest.mark.parametrize("pattern,exclude_a,exclude_b",
                             [("['*']", True, True),
                              ("['pkga']", True, False),
                              ("['pkgb']", False, True),
                              ("['pkg*']", True, True),
                              ("['pkga', 'pkgb']", True, True),
                              ("['*a', '*b']", True, True),
                              ("['nonexist']", False, False),
                              ])
    def test_exclude_code_analysis(pattern, exclude_a, exclude_b):
        client = TestClient()
        client.save({"conanfile.py": GenConanfile()})
        client.run("create . pkga/1.0@")
        client.run("create . pkgb/1.0@")
    
        conanfile = textwrap.dedent("""
            from conans import ConanFile
            from conan.tools.microsoft import MSBuild
    
            class HelloConan(ConanFile):
                settings = "os", "build_type", "compiler", "arch"
                requires = "pkgb/1.0@", "pkga/1.0"
                generators = "msbuild"
                def build(self):
                    msbuild = MSBuild(self)
                    msbuild.build("MyProject.sln")
            """)
        profile = textwrap.dedent("""
            include(default)
            build_type=Release
            arch=x86_64
            [conf]
            tools.microsoft.msbuilddeps:exclude_code_analysis = %s
            """ % pattern)
    
        client.save({"conanfile.py": conanfile,
                     "profile": profile})
        client.run("install . --profile profile")
>       depa = client.load("conan_pkga_release_x64.props")

conans/test/functional/toolchains/microsoft/test_msbuilddeps.py:684: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmpv5p6iignconans/path with spaces/conan_pkga_release_x64.props'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmpv5p6iignconans/path with spaces/conan_pkga_release_x64.props'

conans/util/files.py:232: FileNotFoundError
_____________ test_exclude_code_analysis[['nonexist']-False-False] _____________
[gw20] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

pattern = "['nonexist']", exclude_a = False, exclude_b = False

    @pytest.mark.parametrize("pattern,exclude_a,exclude_b",
                             [("['*']", True, True),
                              ("['pkga']", True, False),
                              ("['pkgb']", False, True),
                              ("['pkg*']", True, True),
                              ("['pkga', 'pkgb']", True, True),
                              ("['*a', '*b']", True, True),
                              ("['nonexist']", False, False),
                              ])
    def test_exclude_code_analysis(pattern, exclude_a, exclude_b):
        client = TestClient()
        client.save({"conanfile.py": GenConanfile()})
        client.run("create . pkga/1.0@")
        client.run("create . pkgb/1.0@")
    
        conanfile = textwrap.dedent("""
            from conans import ConanFile
            from conan.tools.microsoft import MSBuild
    
            class HelloConan(ConanFile):
                settings = "os", "build_type", "compiler", "arch"
                requires = "pkgb/1.0@", "pkga/1.0"
                generators = "msbuild"
                def build(self):
                    msbuild = MSBuild(self)
                    msbuild.build("MyProject.sln")
            """)
        profile = textwrap.dedent("""
            include(default)
            build_type=Release
            arch=x86_64
            [conf]
            tools.microsoft.msbuilddeps:exclude_code_analysis = %s
            """ % pattern)
    
        client.save({"conanfile.py": conanfile,
                     "profile": profile})
        client.run("install . --profile profile")
>       depa = client.load("conan_pkga_release_x64.props")

conans/test/functional/toolchains/microsoft/test_msbuilddeps.py:684: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmpf7uah9yaconans/path with spaces/conan_pkga_release_x64.props'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmpf7uah9yaconans/path with spaces/conan_pkga_release_x64.props'

conans/util/files.py:232: FileNotFoundError
___________________ test_locally_build_linux[Release-False] ____________________
[gw21] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

build_type = 'Release', shared = False
client = <conans.test.utils.tools.TestClient object at 0xf3986dc0>

    @pytest.mark.skipif(platform.system() != "Linux", reason="Only Linux")
    @pytest.mark.parametrize("build_type,shared", [("Release", False), ("Debug", True)])
    @pytest.mark.tool_compiler
    @pytest.mark.tool_ninja
    def test_locally_build_linux(build_type, shared, client):
        settings = "-s os=Linux -s arch=x86_64 -s build_type={} -o hello:shared={}".format(build_type,
                                                                                           shared)
        client.run("install . {}".format(settings))
        client.run_command('cmake . -G "Ninja" -DCMAKE_TOOLCHAIN_FILE={}'
                           .format(CMakeToolchain.filename))
    
>       client.run_command('ninja')

conans/test/functional/toolchains/cmake/test_ninja.py:68: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:576: in run_command
    self._handle_cli_result(command, assert_error=assert_error, error=ret)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <conans.test.utils.tools.TestClient object at 0xf3986dc0>
command = 'ninja', assert_error = False, error = 1

    def _handle_cli_result(self, command, assert_error, error):
        if (assert_error and not error) or (not assert_error and error):
            if assert_error:
                msg = " Command succeeded (failure expected): "
            else:
                msg = " Command failed (unexpectedly): "
            exc_message = "\n{header}\n{cmd}\n{output_header}\n{output}\n{output_footer}\n".format(
                header='{:-^80}'.format(msg),
                output_header='{:-^80}'.format(" Output: "),
                output_footer='-' * 80,
                cmd=command,
                output=self.out
            )
>           raise Exception(exc_message)
E           Exception: 
E           ------------------------ Command failed (unexpectedly): ------------------------
E           ninja
E           ----------------------------------- Output: ------------------------------------
E           [1/4] Building CXX object CMakeFiles/myapp.dir/main.cpp.o
E           FAILED: CMakeFiles/myapp.dir/main.cpp.o 
E           /gnu/store/afpgzln8860m6yfhxy6i8n9rywbp85cy-gcc-7.5.0/bin/c++ -D_GLIBCXX_USE_CXX11_ABI=0  -m64 -O3 -DNDEBUG -MD -MT CMakeFiles/myapp.dir/main.cpp.o -MF CMakeFiles/myapp.dir/main.cpp.o.d -o CMakeFiles/myapp.dir/main.cpp.o -c /tmp/guix-build-conan-1.40.2.drv-0/tmpnqqi21vtconans/pathwithoutspaces/main.cpp
E           cc1plus: sorry, unimplemented: 64-bit mode not compiled in
E           [2/4] Building CXX object CMakeFiles/mylibrary.dir/hello.cpp.o
E           FAILED: CMakeFiles/mylibrary.dir/hello.cpp.o 
E           /gnu/store/afpgzln8860m6yfhxy6i8n9rywbp85cy-gcc-7.5.0/bin/c++ -D_GLIBCXX_USE_CXX11_ABI=0  -m64 -O3 -DNDEBUG -MD -MT CMakeFiles/mylibrary.dir/hello.cpp.o -MF CMakeFiles/mylibrary.dir/hello.cpp.o.d -o CMakeFiles/mylibrary.dir/hello.cpp.o -c /tmp/guix-build-conan-1.40.2.drv-0/tmpnqqi21vtconans/pathwithoutspaces/hello.cpp
E           cc1plus: sorry, unimplemented: 64-bit mode not compiled in
E           ninja: build stopped: subcommand failed.
E           
E           --------------------------------------------------------------------------------

conans/test/utils/tools.py:592: Exception
__________________________ test_custom_configuration ___________________________
[gw21] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

client = <conans.test.utils.tools.TestClient object at 0xf39d08f8>

    def test_custom_configuration(client):
        """  The configuration may differ from the build context and the host context"""
        conanfile = textwrap.dedent("""
           from conans import ConanFile
           from conan.tools.cmake import CMakeDeps
    
           class Consumer(ConanFile):
               name = "consumer"
               version = "1.0"
               settings = "os", "compiler", "arch", "build_type"
               requires = "liba/0.1"
               build_requires = "liba/0.1"
               generators = "CMakeToolchain"
    
               def generate(self):
                   cmake = CMakeDeps(self)
                   cmake.configuration = "Debug"
                   cmake.build_context_activated = ["liba"]
                   cmake.build_context_suffix["liba"] = "_build"
                   cmake.generate()
           """)
    
        client.save({"conanfile.py": conanfile})
        client.run("install . -pr:h default -s:b build_type=RelWithDebInfo"
                   " -pr:b default -s:b arch=x86 --build missing")
        curdir = client.current_folder
        data_name_context_build = "liba_build-relwithdebinfo-x86-data.cmake"
        data_name_context_host = "liba-debug-x86_64-data.cmake"
        assert os.path.exists(os.path.join(curdir, data_name_context_build))
>       assert os.path.exists(os.path.join(curdir, data_name_context_host))
E       AssertionError: assert False
E        +  where False = <function exists at 0xf774bd60>('/tmp/guix-build-conan-1.40.2.drv-0/tmp19k8sf2sconans/path with spaces/liba-debug-x86_64-data.cmake')
E        +    where <function exists at 0xf774bd60> = <module 'posixpath' from '/gnu/store/jkngay2hcmxzi5y35hajq6ak6flh2108-python-3.8.2/lib/python3.8/posixpath.py'>.exists
E        +      where <module 'posixpath' from '/gnu/store/jkngay2hcmxzi5y35hajq6ak6flh2108-python-3.8.2/lib/python3.8/posixpath.py'> = os.path
E        +    and   '/tmp/guix-build-conan-1.40.2.drv-0/tmp19k8sf2sconans/path with spaces/liba-debug-x86_64-data.cmake' = <function join at 0xf77522b0>('/tmp/guix-build-conan-1.40.2.drv-0/tmp19k8sf2sconans/path with spaces', 'liba-debug-x86_64-data.cmake')
E        +      where <function join at 0xf77522b0> = <module 'posixpath' from '/gnu/store/jkngay2hcmxzi5y35hajq6ak6flh2108-python-3.8.2/lib/python3.8/posixpath.py'>.join
E        +        where <module 'posixpath' from '/gnu/store/jkngay2hcmxzi5y35hajq6ak6flh2108-python-3.8.2/lib/python3.8/posixpath.py'> = os.path

conans/test/functional/toolchains/cmake/cmakedeps/test_cmakedeps.py:240: AssertionError
____________ test_exclude_code_analysis[['pkga', 'pkgb']-True-True] ____________
[gw18] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

pattern = "['pkga', 'pkgb']", exclude_a = True, exclude_b = True

    @pytest.mark.parametrize("pattern,exclude_a,exclude_b",
                             [("['*']", True, True),
                              ("['pkga']", True, False),
                              ("['pkgb']", False, True),
                              ("['pkg*']", True, True),
                              ("['pkga', 'pkgb']", True, True),
                              ("['*a', '*b']", True, True),
                              ("['nonexist']", False, False),
                              ])
    def test_exclude_code_analysis(pattern, exclude_a, exclude_b):
        client = TestClient()
        client.save({"conanfile.py": GenConanfile()})
        client.run("create . pkga/1.0@")
        client.run("create . pkgb/1.0@")
    
        conanfile = textwrap.dedent("""
            from conans import ConanFile
            from conan.tools.microsoft import MSBuild
    
            class HelloConan(ConanFile):
                settings = "os", "build_type", "compiler", "arch"
                requires = "pkgb/1.0@", "pkga/1.0"
                generators = "msbuild"
                def build(self):
                    msbuild = MSBuild(self)
                    msbuild.build("MyProject.sln")
            """)
        profile = textwrap.dedent("""
            include(default)
            build_type=Release
            arch=x86_64
            [conf]
            tools.microsoft.msbuilddeps:exclude_code_analysis = %s
            """ % pattern)
    
        client.save({"conanfile.py": conanfile,
                     "profile": profile})
        client.run("install . --profile profile")
>       depa = client.load("conan_pkga_release_x64.props")

conans/test/functional/toolchains/microsoft/test_msbuilddeps.py:684: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmp1pnx0j21conans/path with spaces/conan_pkga_release_x64.props'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmp1pnx0j21conans/path with spaces/conan_pkga_release_x64.props'

conans/util/files.py:232: FileNotFoundError
___________________________ test_package_from_system ___________________________
[gw2] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

    def test_package_from_system():
        """
        If a node declares "system_package" property, the CMakeDeps generator will skip generating
        the -config.cmake and the other files for that node but will keep the "find_dependency" for
        the nodes depending on it. That will cause that cmake looks for the config files elsewhere
        https://github.com/conan-io/conan/issues/8919"""
        client = TestClient()
        dep2 = str(GenConanfile().with_name("dep2").with_version("1.0")
                   .with_settings("os", "arch", "build_type", "compiler"))
        dep2 += """
        def package_info(self):
            self.cpp_info.set_property("cmake_find_mode", "None")
            self.cpp_info.set_property("cmake_file_name", "custom_dep2")
    
        """
        client.save({"conanfile.py": dep2})
        client.run("create .")
    
        dep1 = GenConanfile().with_name("dep1").with_version("1.0").with_require("dep2/1.0")\
                             .with_settings("os", "arch", "build_type", "compiler")
        client.save({"conanfile.py": dep1})
        client.run("create .")
    
        consumer = GenConanfile().with_name("consumer").with_version("1.0").\
            with_require("dep1/1.0").with_generator("CMakeDeps").\
            with_settings("os", "arch", "build_type", "compiler")
        client.save({"conanfile.py": consumer})
        client.run("install .")
        assert os.path.exists(os.path.join(client.current_folder, "dep1-config.cmake"))
        assert not os.path.exists(os.path.join(client.current_folder, "dep2-config.cmake"))
        assert not os.path.exists(os.path.join(client.current_folder, "custom_dep2-config.cmake"))
>       contents = client.load("dep1-release-x86_64-data.cmake")

conans/test/integration/toolchains/cmake/cmakedeps/test_cmakedeps.py:39: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmp1wasf3l0conans/path with spaces/dep1-release-x86_64-data.cmake'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmp1wasf3l0conans/path with spaces/dep1-release-x86_64-data.cmake'

conans/util/files.py:232: FileNotFoundError
_______________ AutoToolsConfigureTest.test_cross_build_command ________________
[gw19] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

self = <conans.test.unittests.client.build.autotools_environment_test.AutoToolsConfigureTest testMethod=test_cross_build_command>

    def test_cross_build_command(self):
        runner = RunnerMock()
        conanfile = MockConanfile(MockSettings({}), None, runner)
        ab = AutoToolsBuildEnvironment(conanfile)
        self.assertFalse(ab.build)
        self.assertFalse(ab.host)
        self.assertFalse(ab.target)
    
        ab.configure()
        self.assertEqual(runner.command_called, "./configure  ")
    
        ab.configure(host="x86_64-apple-darwin")
        self.assertEqual(runner.command_called, "./configure  --host=x86_64-apple-darwin")
    
        ab.configure(build="arm-apple-darwin")
        self.assertEqual(runner.command_called, "./configure  --build=arm-apple-darwin")
    
        ab.configure(target="i686-apple-darwin")
        self.assertEqual(runner.command_called, "./configure  --target=i686-apple-darwin")
    
        conanfile = MockConanfile(MockSettings({"build_type": "Debug",
                                                "arch": "x86_64",
                                                "os": "Windows",
                                                "compiler": "gcc",
                                                "compiler.libcxx": "libstdc++"}),
                                  None, runner)
        ab = AutoToolsBuildEnvironment(conanfile)
        ab.configure()
        if platform.system() == "Windows":
            # Not crossbuilding
            self.assertFalse(ab.host)
            self.assertFalse(ab.build)
            self.assertIn("./configure", runner.command_called)
            self.assertNotIn("--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32",
                             runner.command_called)
        elif platform.system() == "Linux":
            self.assertIn("x86_64-w64-mingw32", ab.host)
>           self.assertIn("x86_64-linux-gnu", ab.build)
E           AssertionError: 'x86_64-linux-gnu' not found in 'x86-linux-gnu'

conans/test/unittests/client/build/autotools_environment_test.py:494: AssertionError
______________________________ test_test_package _______________________________
[gw2] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

    def test_test_package():
        client = TestClient()
        client.save({"conanfile.py": GenConanfile()})
        client.run("create . gtest/1.0@")
        client.run("create . cmake/1.0@")
    
        client.save({"conanfile.py": GenConanfile().with_build_requires("cmake/1.0").
                    with_build_requirement("gtest/1.0", force_host_context=True)})
    
        client.run("export . pkg/1.0@")
    
        consumer = textwrap.dedent(r"""
            from conans import ConanFile
            class Pkg(ConanFile):
                settings = "os", "compiler", "build_type", "arch"
                generators = "CMakeDeps"
                requires = "pkg/1.0"
            """)
        client.save({"conanfile.py": consumer})
        client.run("install . -s:b os=Windows -s:h os=Linux --build=missing")
>       cmake_data = client.load("pkg-release-x86_64-data.cmake")

conans/test/integration/toolchains/cmake/cmakedeps/test_cmakedeps.py:63: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
conans/test/utils/tools.py:423: in load
    return load(os.path.join(self.current_folder, filename))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = '/tmp/guix-build-conan-1.40.2.drv-0/tmp1pov8p3vconans/path with spaces/pkg-release-x86_64-data.cmake'
binary = False, encoding = 'auto'

    def load(path, binary=False, encoding="auto"):
        """ Loads a file content """
>       with open(path, 'rb') as handle:
E       FileNotFoundError: [Errno 2] No such file or directory: '/tmp/guix-build-conan-1.40.2.drv-0/tmp1pov8p3vconans/path with spaces/pkg-release-x86_64-data.cmake'

conans/util/files.py:232: FileNotFoundError
__________________________ CMakeTest.test_deleted_os ___________________________
[gw10] linux -- Python 3.8.2 /gnu/store/44s0j9is012nbww47d00pkxlznc92g9q-python-wrapper-3.8.2/bin/python

self = <conans.test.unittests.client.build.cmake_test.CMakeTest testMethod=test_deleted_os>

        def test_deleted_os(self):
            partial_settings = """
    os: [Linux]
    arch: [x86_64]
    compiler:
        gcc:
            version: ["4.9"]
    build_type: [ Release]
    """
            settings = Settings.loads(partial_settings)
            settings.os = "Linux"
            settings.compiler = "gcc"
            settings.compiler.version = "4.9"
            settings.arch = "x86_64"
            conanfile = ConanFileMock()
            conanfile.settings = settings
    
            cmake = CMake(conanfile)
            generator = "Unix" if platform.system() != "Windows" else "MinGW"
            cross = ("-DCMAKE_SYSTEM_NAME=\"Linux\" -DCMAKE_SYSROOT=\"/path/to/sysroot\" "
                     if platform.system() != "Linux" else "")
>           self.assertEqual('-G "%s Makefiles" %s-DCONAN_IN_LOCAL_CACHE="OFF" '
                             '-DCONAN_COMPILER="gcc" '
                             '-DCONAN_COMPILER_VERSION="4.9" -DCONAN_CXX_FLAGS="-m64" '
                             '-DCONAN_SHARED_LINKER_FLAGS="-m64" -DCONAN_C_FLAGS="-m64" '
                             '-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" '
                             '-Wno-dev' % (generator, cross),
                             cmake.command_line)
E                            AssertionError: '-G "[14 chars]" -DCONAN_IN_LOCAL_CACHE="OFF" -DCONAN_COMPILE[187 chars]-dev' != '-G "[14 chars]" -DCMAKE_SYSTEM_NAME="Linux" -DCMAKE_SYSROOT=[250 chars]-dev'
E                            Diff is 666 characters long. Set self.maxDiff to None to see it.

conans/test/unittests/client/build/cmake_test.py:873: AssertionError
_________________________ CrossBuildingTest.test_same __________________________
```
user: Apteryks
issue_9663: state: open
title: [question] Cross compile for bare metal with cmake. How to properly setup cmake from conan?
body: Sorry for the long post but I am trying to add all the information that I found, the steps that I performed during my tests.
I am new to Conan,
therefore there is something missing from my understanding but its some day that I am googling for a tutorial / howto / example but I did not found any.

I would like to cross compile from linux  for a bare metal arm device. Next step would be to compile from windows to bare metal.
The steps that I tried to follow are related to:

- create a package for the arm-none-eabi-gcc compiler. I tried to follow what the mingw package is doing. This is the relevant part.

```python
   def package(self):
        self.copy("*", dst="", src=self.basename)
        tools.rmdir(self.basename)

    def package_info(self):  # still very useful for package consumers
        self.cpp_info.includedirs = ["arm-none-eabi/include/", ]

        bindir = os.path.join(self.package_folder, "bin")
        self.output.info("Appending PATH environment variable: {}".format(bindir))
        self.env_info.PATH.append(bindir)
        self.env_info.path.append(bindir)
        self.env_info.CXX = os.path.join(self.package_folder, "bin", "arm-none-eabi-g++").replace("\\", "/")
        self.env_info.CC = os.path.join(self.package_folder, "bin", "arm-none-eabi-gcc").replace("\\", "/")
        self.env_info.LD = os.path.join(self.package_folder, "bin", "arm-none-eabi-ld").replace("\\", "/")
        self.env_info.NM = os.path.join(self.package_folder, "bin", "arm-none-eabi-nm").replace("\\", "/")
        self.env_info.AR = os.path.join(self.package_folder, "bin", "arm-none-eabi-ar").replace("\\", "/")
        self.env_info.AS = os.path.join(self.package_folder, "bin", "arm-none-eabi-as").replace("\\", "/")
        self.env_info.STRIP = os.path.join(self.package_folder, "bin", "arm-none-eabi-strip").replace("\\", "/")
        self.env_info.RANLIB = os.path.join(self.package_folder, "bin", "arm-none-eabi-ranlib").replace("\\", "/")
        self.env_info.STRINGS = os.path.join(self.package_folder, "bin", "arm-none-eabi-strings").replace("\\", "/")
        self.env_info.OBJDUMP = os.path.join(self.package_folder, "bin", "arm-none-eabi-objdump").replace("\\", "/")
        self.env_info.GCOV = os.path.join(self.package_folder, "bin", "arm-none-eabi-gcov").replace("\\", "/")
```
- create a package for the cross compile environment that I would like to use

```python
class TestPkg(ConanFile):
        name = "test_package"
        version = "0.1"
        build_requires =  ["arm-none-eabi-gcc/10.3@tools+arm-none-eabi-gcc/stable", "cmake/3.21.3", "ninja/1.10.2"]

        generators = ["CMakeToolchain", "virtualenv"]

        def generate(self):
                tc = CMakeToolchain(self)
                tc.variables["IN_TRY_COMPILE"] = 1
                tc.generate()

```
- create the relevant part for the configuration in the settings file, therefore I added a arch_build for armv7e, an os_target "bare", an arch armv7e and a compiler arm-none-eabi-gcc

- create a profile for the arm device
```
[settings]
arch=armv7e
build_type=Debug
compiler=arm-none-eabi-gcc
os=Bare

```

- execute the install command

```bash
$ conan install -pr:b=/home/andrea/.conan/profiles/default -pr:h=../profile .. --build missing
Configuration (profile_host):
[settings]
arch=armv7e
build_type=Debug
compiler=arm-none-eabi-gcc
os=Bare
[options]
[build_requires]
[env]

Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

```

- then, I can source the activate.sh file and I have my compiler, cmake, ninja in the path.
- at this point I would like to call cmake, at this moment no sources are involved. But I am not at this stage yet.

```bash
cmake -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake  .. 
```

At this point cmake complains that the compiler (the compiled detected is the correct one) is not able to compile a simple test program. This is a common error that cmake pops out while detecting the compiler provided with the CMAKE_TOOLCHAIN_FILE.

The solution for this is to not compile an executable but to compile a library in order to detect if the compiler works.
in the cmake toolchain file it is easy as adding:

```cmake
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
```

Can someone point out what is the best way for setting this command in the generated conan_toolchain? 
thank you in advance
Andrea


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: andyinno
issue_9619: state: open
title: [feature] Ubuntu PPA
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Could conan get an Ubuntu PPA package, for more automated installation and updates?

I see the pip and DEB packages, but a PPA would also be helpful.
user: mcandre
labels: component: ux: No changes to core business logic
issue_9579: state: open
title: [bug] Can't create package that has symlinks when the conan cache is a symlink
body: When the conan cache dir (`~/.conan`) is a symlink (for `/tmp/.conan` for example) and I'm trying to create a package that includes internal symlinks, the `conan create` command fails. The failure point is when the `export_source` folder contents (in the cache) gets copied over to the `source` dir.  Looking at:
https://github.com/conan-io/conan/blob/ff7b8e6703e8407773968517d68424b9ec59aa30/conans/util/files.py#L412 
You can see that the usage of `os.path.realpath` would resolve the `src`'s symlink, which would completely throw off the `os.path.relpath` call. The solution is to simply remove the `os.path.realpath`:
```
out_of_source = os.path.relpath(linkto, src).startswith(".")
```

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 18.04
  * Compiler+version: Any
  * Conan version: 1.40.0
  * Python version: 3.8.5

### Steps to reproduce (Include if Applicable)
```
mkdir /tmp/.conan
ln -s /tmp/.conan -t ~/
conan new symlink_bug/0.1.0
touch original_file
ln -s original_file link_file
# add the following code to beginning of SymlinkBugConan::build()
#        with open('link_file', 'r') as f:
#            print("link_file found!")
conan create .
```
Result:
```
ERROR: symlink_bug/0.1.0: Error in build() method, line 33
        with open('link_file', 'r') as f:
        FileNotFoundError: [Errno 2] No such file or directory: 'link_file'
```
Expected Result:
Package gets created

user: dscole
issue_9578: state: open
title: multiple link issues in VS16 with grpc installation
body: I have been trying to use grpc 1.39.1 and 1.38.0 with Conan on Windows with Visual Studio 16.0.22 (compiler 14.20.27508). I am getting many unresolved external symbols such as __imp___std_init_once_complete,  __imp___std_init_once_begin_initialize, etc. I see a similar thread about this (https://github.com/conan-io/conan-center-index/issues/4826). Since I am not able to upgrade my compiler, I was wondering if there is a possibility of building grpc and its dependecies with an older VS16 compiler and making it available in the Conan repo? Or do you have any suggestion on how to fix this problem with my version of compiler?
Thanks
user: vabdollahi
issue_9572: state: open
title: [bug] handle package that needs its x86_64 version to cross-compile
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 18.04
  * Compiler+version: gcc5
  * Conan version:  1.33 and 1.40
  * Python version: 3.7

### Steps to reproduce (Include if Applicable)

I'm working on a Conan recipe for the CycloneDDS package: https://github.com/eclipse-cyclonedds/cyclonedds
This package has a peculiarity: x86_64 builds generate a binary that is needed for cross-compilation.
See more details here https://github.com/eclipse-cyclonedds/cyclonedds/issues/794#issuecomment-884417083

The way I'm handling this is by listing the package itself as a `build_requirement` when cross-compiling.
This works, i.e. I can properly cross-compile the package, however there's a problem.
Even if I have already built the x86_64 version of the package, this is always re-built during cross-compilation, thus doubling the total compilation time.

This is how I'm listing the build requirement:
```
def build_requirements(self):
        if tools.cross_building(self.settings):
            self.build_requires("cyclonedds/{}@{}/{}".format(
                self.version,
                self.user,
                self.channel))
```

Then I'm building using the following command

```
conan create ./recipes/cyclonedds/all cyclonedds/0.8.0beta6@brewst/stable -pr:b ./.conanprofiles/x86_64 -pr:h ./.conanprofiles/x86_64
conan create ./recipes/cyclonedds/all cyclonedds/0.8.0beta6@brewst/stable -pr:b ./.conanprofiles/x86_64 -pr:h ./.conanprofiles/my_cross_compilation_profile
```

From the logs in the cross-compilation command I can see the following:

```
cyclonedds/0.8.0beta6@asoragna-dev/stable: Forced build from source
cyclonedds/0.8.0beta6@asoragna-dev/stable: Forced build from source
...
cyclonedds/0.8.0beta6@asoragna-dev/stable (test package): Installing package
Requirements
    cyclonedds/0.8.0beta6@asoragna-dev/stable from local cache - Cache
Packages
    cyclonedds/0.8.0beta6@asoragna-dev/stable:1f520fec810ff376e09741e3105d5ee80cdaf301 - Build
Build requirements
    cyclonedds/0.8.0beta6@asoragna-dev/stable from local cache - Cache
Build requirements packages
    cyclonedds/0.8.0beta6@asoragna-dev/stable:b80d46004713aa37d6a90b42e2a326a056a237b5 - Build
```

It looks like since I'm asking to create `cyclonedds/0.8.0beta6` all its instances will be rebuilt, even when listed as requirements.

Let me know if you need more information and/or access to the complete conan recipe.
user: alsora
issue_9552: state: open
title: [bug] If the same dependency is in both `requires` and ` build_requires`, the default options might get overwritten. 
body: Hi,

I have a library which is cross compiled for iOS (and Android).
My library uses `protobuf`, which means:
- the library itself needs the `protobuf` library (listed in **requires**)
- during compilation I need to run `protoc` (it compiles `.proto` files to `.h` and `.cpp`) which is part of `protobuf` (listed in **build_requires**).

This setup with host and build profiles works like a charm on Android.
But for iOS I can't build `protoc`. Since I actually don't need it, I added a `with_protoc` option to the recipe of `protobuf`.

In the `protobuf`'s recipe  `with_protoc` is set to `True` by `default_options`. In `configure()` I have:
```py
if self.settings.os == "iOS":
    self.options.with_protoc = False
```

If I do a `conan create` without cross-compile this work as expected.
But if I build my library in cross-compilation, this `configure()` runs twice:
1. It runs for the host: `os == "iOS"`  and `self.options.with_protoc == True` at the beginning of `configure()` (and `False` at the end as we would expect)
2. It runs for the build: `os == "Macos"` and `self.options.with_protoc == False` at the beginning of `configure()`. So it seems the initial values are from the previous run and not from the defaults.

Is this a bug, or did I do something wrong?

### Environment Details (include every applicable attribute)
  * Operating System+version: Mac 11.5.2 + iOS
  * Compiler+version: clang 12.0
  * Conan version: 1.39.0
  * Python version: 3.8.2

user: takacsd
issue_9519: state: open
title: [question] Intended Way of Customer Delivery
body: I am currently looking a little into how we can deliver a product to a customer. The project is based on Conan and the question can be explained with the standard CI example:
[Conan Lockfiles and CI](https://docs.conan.io/en/latest/versioning/lockfiles/ci.html#lockfiles-in-continuous-integration)

The project does host a set of libraries plus an application built out of the lib, the dependency management is handled by making use of version ranges.
The issue is that we are not only delivering the application but also the libraries to customers. They can built their own application with the libs. For this product release we need a way of defining the set of libraries which we used for the application as its a safety sensitive environment and the combination needs to be tested.

So we are good when we create a dependency lock where the application itself is not locked
`conan lock create delivery_app/conanfile.py --user=user --channel=testing --lockfile-out=delivery_app_deps.lock`
The resulting app_deps.lock can be delivered and used to build other apps. It works even if the non locked app package name differs.
> Update: Sorry, checked it again, even this is not possible currently. Only using the lockfile for installation plus a clean cache does work, but building with the lockfile another system is still highly preferred. 

Issues are coming up once the customer application does use another lockfile with e.g. another well defined set of libs (verified to work together). The `conan lock update` seems not to work, so we can create a dependency lock for the customer app and update it with our two lockfiles:

```
conan lock create customer_app/conanfile.py --user=user --channel=testing --lockfile  --lockfile-out=customer_app_deps.lock
conan lock update customer_app_deps.lock other_lib_set.lock <- fails as its not originating from the same system
```

That would be question one. **Is delivering a lockfile like that/ for this purpose an intended workflow?** Is the a better way of solving the problem?

The next issue comes with build_requires used to introduce build tools (e.g. app code generators) in the scenario. We want to consume them via build_requires so they are consumed with the build context / profile. The build_requirement versions specified in the lock file (e.g. delivery_app_deps.lock) are completely ignored it seems. The version range is evaluated like without having the lock.
This would be question two. **Can we force a conan create to use the specified build_require versions in a lockfile?**

The only solution we currently see is code generating a conanfile.py which specifies all the dependency versions explicitly (no version ranges).
user: dev-789
issue_9506: state: open
title: [bug] Conan workspace ignores shared option
body:   * Operating System+version: Ununtu 20.04
  * Compiler+version: clang5
  * Conan version: 1.33.1

I have a workspace with a few packages and one of them is supposed to build into a shared library. In the `conanfile.py` for this package I have
```    
options = {
    "includeMocks": [True, False],
    "shared": [True, False],
    "fPIC": [True, False],
}

default_options = {
    "includeMocks": False,
    "fPIC": True,
    "shared": True,
}
```
When I build it as a single package everything is fine but when I create it as part of the workspace it is built into a static library. I see in the log that option `shared` works and it is true but later in `build.ninja` it says `# Link the static library...`. So it seems like it simply ignores this option. Put `shared=True` in the `conan workspace install` command doesn't change anything too.

user: asarayev
labels: whiteboard: Put in common
issue_9497: state: open
title: [feature] Ability for a recipe to modify another package
body: Hello,

I think it may be better for me to describe my use-case that I think is not currently covered by Conan than give a suggestion.

There are cases when I need to modify a package. For example if I have a Qt installation, I might need to add an additionally purchased module to the installation. (in my case I buy the TreeView for QQC2 and install it in my Qt package in the Conan cache) Another example I have come across is installing plugins for Alsa  (https://github.com/conan-io/conan-center-index/pull/7098#discussion_r697920460).

So I was wondering if there could be a mechanism where a package could somehow be modified by the consumer to produce a new package.

The current workflow:
- Run conan install
- Each developer manually compiles / installs the extra module to the conan installation

- [✓] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: daravi
issue_9494: state: open
title: [question] .proto files (gRPC) cross compilation
body: I'm trying to cross build a project from `x64` to `ARMv7` that requires `protobuf`/`gRPC` to create stubs for `.proto` files.

Due to cross compilation, `conan install ...` installs/builds two `protoc` binaries  (along with `grpc plugin`) and places them into `~/.conan/data/...`: one for `x64` one for `ARMv7`. Unfortunately, during `cmake --build`, the `ARMv7` binary is taken and therefore the build process fails (see log below)

Conan installs `grpc` (and other dependencies) twice: Once for `x64` and once for `ARMv7`. That's fine. But:
According to my understanding, Conan adds both these package's `bindirs` to `$PATH`. Therefore, both `protoc` binaries are in the `$PATH` competing against each others. Unfortunately, the `ARMv7` package seems to take precedence in my case.

What's the "Conan way" of forcing the system to use the right `protoc` binary? Note that everything works fine if I'm not compiling natively.

### Environment Details (include every applicable attribute)
  * Operating System+version: `Ubuntu 20.04.3 LTS`
  * Compiler+version: `gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
` and `arm-linux-gnueabihf-g++-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0`
  * Conan version: `1.39.0`
  * Python version: `Python 2.7.18` (default) / `Python 3.8.10` (also installed)

### Steps to reproduce

- clone https://github.com/raphaelzulliger/grpc_crosscompile_conan
- follow the `README.md`

Follwing `README.md` will show the failure. To compare with "non-crosscompilation", run:

```sh
cmake -DCMAKE_BUILD_TYPE=Debug -H. -Bbuild/Debug -G Ninja
cmake --build build/Debug
```

### Logs

```sh
[1/5] Running cpp protocol buffer compiler on interface.proto. Custom options:
FAILED: protos/interface.pb.h protos/interface.pb.cc /tmp/grpc_cross/build/Debug/protos/interface.pb.h /tmp/grpc_cross/build/Debug/protos/interface.pb.cc 
cd /tmp/grpc_cross/build/Debug/protos && /home/raphael/.conan/data/protobuf/3.17.1/_/_/package/6bfdfebba5ad33ebacf2eb06b37d3a0160d10da9/bin/protoc --cpp_out /tmp/grpc_cross/build/Debug/protos -I /tmp/grpc_cross/protos /tmp/grpc_cross/protos/interface.proto
/bin/sh: 1: /home/raphael/.conan/data/protobuf/3.17.1/_/_/package/6bfdfebba5ad33ebacf2eb06b37d3a0160d10da9/bin/protoc: Exec format error
[2/5] Running grpc protocol buffer compiler on interface.proto. Custom options:
FAILED: protos/interface.grpc.pb.h protos/interface.grpc.pb.cc /tmp/grpc_cross/build/Debug/protos/interface.grpc.pb.h /tmp/grpc_cross/build/Debug/protos/interface.grpc.pb.cc 
cd /tmp/grpc_cross/build/Debug/protos && /home/raphael/.conan/data/protobuf/3.17.1/_/_/package/6bfdfebba5ad33ebacf2eb06b37d3a0160d10da9/bin/protoc --grpc_out /tmp/grpc_cross/build/Debug/protos --plugin=protoc-gen-grpc= -I /tmp/grpc_cross/protos /tmp/grpc_cross/protos/interface.proto
/bin/sh: 1: /home/raphael/.conan/data/protobuf/3.17.1/_/_/package/6bfdfebba5ad33ebacf2eb06b37d3a0160d10da9/bin/protoc: Exec format error
ninja: build stopped: subcommand failed.
```
user: raphaelzulliger
issue_9492: state: open
title: [feature] Reverse sorting of CONAN_BUILD_MODULES_PATHS for CMake generator
body: Hello,

the CMake generator currently fills the CONAN_BUILD_MODULES_PATHS and CONAN_BUILD_MODULES_PATHS_<build_type> variables within the conanbuildinfo.cmake based on the node traversal of the conan dependency graph by appending the build_module paths. In CMake, build modules of dependencies are thus included after those of their dependents.

Could you please revert the sorting of the paths such that build modules of dependencies are included in CMake before those of dependent nodes?

Example to make it clear:
- suppose you have 3 packages: C depends on B and B depends on A
- A adds a CMake script A.cmake and B adds B.cmake to their cpp_info.build_modules respectively

Then the order in which these scripts are currently called in C's cmakebuildinfo.cmake is first B.cmake and then A.cmake, which is the reverse order we'd expect.

It would be nice that A.cmake can provide some info for its users (in B.cmake and C) and the calling in correct order would support this.

In our case, our packages provide in their cpp_info.build_modules additional CMake code for finding the targets easier. It would really help a lot if these scripts are called in transitive order from farthest to nearest graph distance.

We suggested the following change in the cmake generator file conans/client/generators/cmake.py line 69 (1.39.0) to achieve this:

```
class DepsCppCmake(object):
    def __init__(self, cpp_info, generator_name):
        ...
        # reversed build_modules_paths are now in transitive order from farthest to nearest dependency
        self.build_modules_paths = join_paths(reversed(cpp_info.build_modules_paths.get(generator_name, [])))
```

I'd be very glad if you could consider this change and hope you keep up the great work!
Thank you!

- [ X ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: burgerkiller79
issue_9489: state: open
title: [bug] Cross building to iphonesimulator, cmake system picks iphoneos SDK instead of iphonesimulator SDK
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: macOS 11.5.2
  * Compiler+version: apple-clang 12.0
  * Conan version: 1.39.0
  * Python version:  3.9.0

### Steps to reproduce (Include if Applicable)

Cross building to iphonesimulator any cmake based package (c-ares is an example)


### Logs (Executed commands with output) (Include/Attach if Applicable)
<details><summary> conan install output</summary>

```
Configuration (profile_host):
[settings]
arch=x86_64
build_type=Debug
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=12.0
os=iOS
os.version=12.0
[options]
[build_requires]
[env]

Configuration (profile_build):
[settings]
arch=x86_64
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=12.0
os=Macos
[options]
[build_requires]
[env]

c-ares/1.17.1: WARN: Package binary is corrupted, removing: 4ff8ed1a642b72de555f2983e764c1573ec11938
gtest/1.8.1: WARN: gtest recipe lacks information about apple-clang compiler support.
conanfile.py: Installing package
Requirements
    boost/1.72.0 from 'conancenter' - Cache
    c-ares/1.17.1 from 'conancenter' - Cache
    gtest/1.8.1 from 'conancenter' - Cache
    jsoncpp/1.8.3 from 'conancenter' - Cache
    libcurl/7.71.1 from 'conancenter' - Cache
    ogg/1.3.4 from 'conancenter' - Cache
    openssl/1.1.1k from 'conancenter' - Cache
    opus/1.3.1 from 'conancenter' - Cache
    zlib/1.2.11 from 'conancenter' - Cache
Packages
    boost/1.72.0:24a3393048699ecf713711c94a034b685c282c22 - Build
    c-ares/1.17.1:4ff8ed1a642b72de555f2983e764c1573ec11938 - Build
    gtest/1.8.1:a9f0959d2275b1389efebdab9a3392336712f723 - Build
    jsoncpp/1.8.3:5d31188d78eb92b3c1fa24a8a1208380449972e3 - Build
    libcurl/7.71.1:aed602a2f72e25c1977ff1b1ca77f124782d0016 - Build
    ogg/1.3.4:aa273f0939bd3dea57282a95fdeb4be156f1ab8c - Build
    openssl/1.1.1k:aa273f0939bd3dea57282a95fdeb4be156f1ab8c - Build
    opus/1.3.1:aa273f0939bd3dea57282a95fdeb4be156f1ab8c - Build
    zlib/1.2.11:aa273f0939bd3dea57282a95fdeb4be156f1ab8c - Build
Build requirements
    autoconf/2.71 from 'conancenter' - Cache
    automake/1.16.3 from 'conancenter' - Cache
    b2/4.5.0 from 'conancenter' - Cache
    libtool/2.4.6 from 'conancenter' - Cache
    m4/1.4.18 from 'conancenter' - Cache
    pkgconf/1.7.4 from 'conancenter' - Cache
Build requirements packages
    autoconf/2.71:cc471ed355602ffa7007968c83aa4e7e648a38b5 - Cache
    automake/1.16.3:3c28ba69276b46fd46e9c2060ba991d725ccab43 - Cache
    b2/4.5.0:46f53f156846659bf39ad6675fa0ee8156e859fe - Cache
    libtool/2.4.6:f82f59608a22017ca5ceea2114611456d4373a12 - Cache
    m4/1.4.18:801752c0480319b8e090188c566245a78e9abcf4 - Cache
    pkgconf/1.7.4:647afeb69d3b0a2d3d316e80b24d38c714cc6900 - Cache

Cross-build from 'Macos:x86_64' to 'iOS:x86_64'
Installing (downloading, building) binaries...
b2/4.5.0: Already installed!
c-ares/1.17.1: WARN: Build folder is dirty, removing it: /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938
c-ares/1.17.1: Copying sources to build folder
c-ares/1.17.1: Building your package in /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938
c-ares/1.17.1: Generator cmake created conanbuildinfo.cmake
c-ares/1.17.1: Aggregating env generators
c-ares/1.17.1: Calling build()
-- The C compiler identification is AppleClang 12.0.5.12050022
-- The CXX compiler identification is AppleClang 12.0.5.12050022
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan: Adjusting fPIC flag (ON)
-- Looking for res_servicename
-- Looking for res_servicename - not found
-- Looking for res_servicename in resolv
-- Looking for res_servicename in resolv - not found
-- Performing Test IOS_V10
-- Performing Test IOS_V10 - Failed
-- Performing Test MACOS_V1012
-- Performing Test MACOS_V1012 - Failed
-- Looking for gethostbyname
-- Looking for gethostbyname - not found
-- Looking for gethostbyname in nsl
-- Looking for gethostbyname in nsl - not found
-- Looking for gethostbyname in socket
-- Looking for gethostbyname in socket - not found
-- Looking for socket
-- Looking for socket - not found
-- Looking for socket in socket
-- Looking for socket in socket - not found
-- Looking for clock_gettime
-- Looking for clock_gettime - not found
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - not found
-- Looking for include file sys/types.h
-- Looking for include file sys/types.h - not found
-- Looking for include file sys/socket.h
-- Looking for include file sys/socket.h - not found
-- Looking for include file arpa/inet.h
-- Looking for include file arpa/inet.h - not found
-- Looking for include file arpa/nameser_compat.h
-- Looking for include file arpa/nameser_compat.h - not found
-- Looking for include file arpa/nameser.h
-- Looking for include file arpa/nameser.h - not found
-- Looking for include file assert.h
-- Looking for include file assert.h - not found
-- Looking for include file errno.h
-- Looking for include file errno.h - not found
-- Looking for include file fcntl.h
-- Looking for include file fcntl.h - not found
-- Looking for include file inttypes.h
-- Looking for include file inttypes.h - not found
-- Looking for include file limits.h
-- Looking for include file limits.h - not found
-- Looking for include file malloc.h
-- Looking for include file malloc.h - not found
-- Looking for include file memory.h
-- Looking for include file memory.h - not found
-- Looking for include file netdb.h
-- Looking for include file netdb.h - not found
-- Looking for include file netinet/in.h
-- Looking for include file netinet/in.h - not found
-- Looking for include file netinet/tcp.h
-- Looking for include file netinet/tcp.h - not found
-- Looking for include file net/if.h
-- Looking for include file net/if.h - not found
-- Looking for include file signal.h
-- Looking for include file signal.h - not found
-- Looking for include file socket.h
-- Looking for include file socket.h - not found
-- Looking for include file stdbool.h
-- Looking for include file stdbool.h - not found
-- Looking for include file stdint.h
-- Looking for include file stdint.h - not found
-- Looking for include file stdlib.h
-- Looking for include file stdlib.h - not found
-- Looking for include file strings.h
-- Looking for include file strings.h - not found
-- Looking for include file string.h
-- Looking for include file string.h - not found
-- Looking for include file stropts.h
-- Looking for include file stropts.h - not found
-- Looking for include file sys/ioctl.h
-- Looking for include file sys/ioctl.h - not found
-- Looking for include file sys/param.h
-- Looking for include file sys/param.h - not found
-- Looking for include file sys/select.h
-- Looking for include file sys/select.h - not found
-- Looking for include file sys/stat.h
-- Looking for include file sys/stat.h - not found
-- Looking for include file sys/time.h
-- Looking for include file sys/time.h - not found
-- Looking for include file sys/uio.h
-- Looking for include file sys/uio.h - not found
-- Looking for include file time.h
-- Looking for include file time.h - not found
-- Looking for include file dlfcn.h
-- Looking for include file dlfcn.h - not found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - not found
-- Looking for include files winsock2.h, windows.h
-- Looking for include files winsock2.h, windows.h - not found
-- Looking for 3 include files winsock2.h, ..., windows.h
-- Looking for 3 include files winsock2.h, ..., windows.h - not found
-- Looking for include files winsock.h, windows.h
-- Looking for include files winsock.h, windows.h - not found
-- Looking for include file windows.h
-- Looking for include file windows.h - not found
-- Performing Test HAVE_SOCKLEN_T
-- Performing Test HAVE_SOCKLEN_T - Failed
-- Performing Test HAVE_TYPE_SOCKET
-- Performing Test HAVE_TYPE_SOCKET - Failed
-- Performing Test HAVE_BOOL_T
-- Performing Test HAVE_BOOL_T - Failed
-- Performing Test HAVE_SSIZE_T
-- Performing Test HAVE_SSIZE_T - Failed
-- Performing Test HAVE_LONGLONG
-- Performing Test HAVE_LONGLONG - Failed
-- Performing Test HAVE_SIG_ATOMIC_T
-- Performing Test HAVE_SIG_ATOMIC_T - Failed
-- Performing Test HAVE_STRUCT_ADDRINFO
-- Performing Test HAVE_STRUCT_ADDRINFO - Failed
-- Performing Test HAVE_STRUCT_IN6_ADDR
-- Performing Test HAVE_STRUCT_IN6_ADDR - Failed
-- Performing Test HAVE_STRUCT_SOCKADDR_IN6
-- Performing Test HAVE_STRUCT_SOCKADDR_IN6 - Failed
-- Performing Test HAVE_STRUCT_SOCKADDR_STORAGE
-- Performing Test HAVE_STRUCT_SOCKADDR_STORAGE - Failed
-- Performing Test HAVE_STRUCT_TIMEVAL
-- Performing Test HAVE_STRUCT_TIMEVAL - Failed
-- Looking for AF_INET6
-- Looking for AF_INET6 - not found
-- Looking for O_NONBLOCK
-- Looking for O_NONBLOCK - not found
-- Looking for FIONBIO
-- Looking for FIONBIO - not found
-- Looking for SIOCGIFADDR
-- Looking for SIOCGIFADDR - not found
-- Looking for MSG_NOSIGNAL
-- Looking for MSG_NOSIGNAL - not found
-- Looking for PF_INET6
-- Looking for PF_INET6 - not found
-- Looking for SO_NONBLOCK
-- Looking for SO_NONBLOCK - not found
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID - Failed
-- Performing Test HAVE_LL
-- Performing Test HAVE_LL - Failed
-- Looking for bitncmp
-- Looking for bitncmp - not found
-- Looking for closesocket
-- Looking for closesocket - not found
-- Looking for CloseSocket
-- Looking for CloseSocket - not found
-- Looking for connect
-- Looking for connect - not found
-- Looking for fcntl
-- Looking for fcntl - not found
-- Looking for freeaddrinfo
-- Looking for freeaddrinfo - not found
-- Looking for getaddrinfo
-- Looking for getaddrinfo - not found
-- Looking for getenv
-- Looking for getenv - not found
-- Looking for gethostbyaddr
-- Looking for gethostbyaddr - not found
-- Looking for gethostbyname
-- Looking for gethostbyname - not found
-- Looking for gethostname
-- Looking for gethostname - not found
-- Looking for getnameinfo
-- Looking for getnameinfo - not found
-- Looking for getservbyport_r
-- Looking for getservbyport_r - not found
-- Looking for getservbyname_r
-- Looking for getservbyname_r - not found
-- Looking for gettimeofday
-- Looking for gettimeofday - not found
-- Looking for if_indextoname
-- Looking for if_indextoname - not found
-- Looking for inet_net_pton
-- Looking for inet_net_pton - not found
-- Looking for inet_ntop
-- Looking for inet_ntop - not found
-- Looking for inet_pton
-- Looking for inet_pton - not found
-- Looking for ioctl
-- Looking for ioctl - not found
-- Looking for ioctlsocket
-- Looking for ioctlsocket - not found
-- Looking for IoctlSocket
-- Looking for IoctlSocket - not found
-- Looking for recv
-- Looking for recv - not found
-- Looking for recvfrom
-- Looking for recvfrom - not found
-- Looking for send
-- Looking for send - not found
-- Looking for setsockopt
-- Looking for setsockopt - not found
-- Looking for socket
-- Looking for socket - not found
-- Looking for strcasecmp
-- Looking for strcasecmp - not found
-- Looking for strcmpi
-- Looking for strcmpi - not found
-- Looking for strdup
-- Looking for strdup - not found
-- Looking for stricmp
-- Looking for stricmp - not found
-- Looking for strncasecmp
-- Looking for strncasecmp - not found
-- Looking for strncmpi
-- Looking for strncmpi - not found
-- Looking for strnicmp
-- Looking for strnicmp - not found
-- Looking for writev
-- Looking for writev - not found
-- Looking for __system_property_get
-- Looking for __system_property_get - not found
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CARES_MSVC_STATIC_RUNTIME
    CMAKE_EXPORT_NO_PACKAGE_REGISTRY


-- Build files have been written to: /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/build_subfolder
[  4%] Building C object source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__get_hostent.c.o
[  4%] Building C object source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__parse_into_addrinfo.c.o
[  4%] Building C object source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__close_sockets.c.o
[  6%] Building C object source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__readaddrinfo.c.o
[  8%] Building C object source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__read_line.c.o
[  8%] Building C object source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__timeval.c.o
[  9%] Building C object source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__sortaddrinfo.c.o
[ 11%] Building C object source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares_android.c.o
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__timeval.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:68In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__parse_into_addrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:68:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/cdefs.h:816:2: error: Unsupported architecture
#error Unsupported architecture
 ^
:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/cdefs.h:816:2: error: Unsupported architecture
#error Unsupported architecture
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__close_sockets.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:68:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/cdefs.h:816:2: error: Unsupported architecture
#error Unsupported architecture
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__read_line.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:68:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/cdefs.h:816:2: error: Unsupported architecture
#error Unsupported architecture
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__parse_into_addrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:33:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported
#error architecture not supported
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__timeval.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:33:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported
#error architecture not supported
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__parse_into_addrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
typedef __int64_t       __darwin_blkcnt_t;      /* total blocks */
        ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__close_sockets.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__timeval.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
typedef __int64_t       __darwin_blkcnt_t;      /* total blocks */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_blksize_t;     /* preferred block size */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_dev_t;         /* dev_t */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_gid_t;         /* [???] process and group IDs */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.hIn file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__get_hostent.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:68:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/cdefs.h:816:2: error: Unsupported architecture
#error Unsupported architecture
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__readaddrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:68:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/cdefs.h:816:2: error: Unsupported architecture
#error Unsupported architecture
 ^
note: '__int128_t' declared here
:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:33:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported
#error architecture not supported
 ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_blksize_t;     /* preferred block size */
        ^:61:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_id_t;          /* [XSI] pid_t, uid_t, or gid_t*/
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'; did you mean '__uint128_t'?
typedef __uint64_t      __darwin_ino64_t;       /* [???] Used for 64 bit inodes */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'; did you mean '__uint128_t'?
typedef __uint16_t      __darwin_mode_t;        /* [???] Some file attributes */
        ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__sortaddrinfo.c:37:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:68:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/cdefs.h:816:2: error: Unsupported architecture
#error Unsupported architecture
 ^

note: '__int128_t' declared here
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__readaddrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:33:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported
#error architecture not supported
 ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:71In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__read_line.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:33:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported
#error architecture not supported
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__get_hostent.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:33:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported
#error architecture not supported
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__close_sockets.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
typedef __int64_t       __darwin_blkcnt_t;      /* total blocks */
        ^
note: '__int128_t' declared here
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__get_hostent.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
typedef __int64_t       __darwin_blkcnt_t;      /* total blocks */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_blksize_t;     /* preferred block size */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_dev_t;         /* dev_t */
        ^
note: '__int128_t' declared here
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__readaddrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
:57:In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__read_line.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
typedef __int64_t       __darwin_blkcnt_t;      /* total blocks */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_blksize_t;     /* preferred block size */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_dev_t;         /* dev_t */
        ^
note: '__int128_t' declared here
typedef __int64_t       __darwin_blkcnt_t;      /* total blocks */
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:60typedef __int32_t       __darwin_blksize_t;     /* preferred block size */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_dev_t;         /* dev_t */
        ^
note: '__int128_t' declared here
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__sortaddrinfo.c:37:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:33:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported
#error architecture not supported
 ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_gid_t;         /* [???] process and group IDs */note:: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_gid_t;         /* [???] process and group IDs */
        ^
note: '__uint128_t' declared here

        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_blksize_t;     /* preferred block size */
        ^
note: '__int128_t' declared here
9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_dev_t;         /* dev_t */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_id_t;          /* [XSI] pid_t, uid_t, or gid_t*/
        ^
9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_gid_t;         /* [???] process and group IDs */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:60:9typedef __int64_t       __darwin_off_t;         /* [???] Used for file sizes */
        ^
note: '__int128_t' declared here
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_id_t;          /* [XSI] pid_t, uid_t, or gid_t*/
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
:61:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__sortaddrinfo.c:37:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
typedef __uint32_t      __darwin_id_t;          /* [XSI] pid_t, uid_t, or gid_t*/
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h        ^
note: '__uint128_t' declared here
typedef __int64_t       __darwin_blkcnt_t;      /* total blocks */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:72:9: error: :unknown type name '__int32_t'; did you mean '__int128_t'?
57:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_dev_t;         /* dev_t */
        ^
note: '__int128_t' declared here
typedef __uint32_t      __darwin_gid_t;         /* [???] process and group IDs */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'; did you mean '__uint128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'; did you mean '__uint128_t'?
typedef __uint64_t      __darwin_ino64_t;       /* [???] Used for 64 bit inodes */
        ^
note: '__uint128_t' declared here
typedef __int32_t       __darwin_pid_t;         /* [???] process and group IDs */
        ^
note: '__int128_t' declared here/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:60:9: error: typedef __uint64_t      __darwin_ino64_t;       /* [???] Used for 64 bit inodes */        ^
typedef __int32_t       __darwin_blksize_t;     /* preferred block size */note: unknown type name '__uint32_t'; did you mean '__uint128_t'?
'__uint128_t' declared here/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h
:61:9:
 error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_id_t;          /* [XSI] pid_t, uid_t, or gid_t*/
        ^
note: '__uint128_t' declared here

        ^
note: '__int128_t' declared here

        ^/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_sigset_t;      /* [???] signal set */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_dev_t;         /* dev_t */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_suseconds_t;   /* [???] microseconds */
        ^
note: '__int128_t' declared here
62:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'; did you mean '__uint128_t'?
typedef __uint64_t      __darwin_ino64_t;       /* [???] Used for 64 bit inodes */
        ^
note: 9: error: unknown type name '__uint64_t'; did you mean '__uint128_t'?
typedef __uint64_t      __darwin_ino64_t;       /* [???] Used for 64 bit inodes */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_gid_t;         /* [???] process and group IDs */
        ^
note: '__uint128_t' declared here
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_id_t;          /* [XSI] pid_t, uid_t, or gid_t*/
        ^
note: '__uint128_t' declared here
typedef __uint32_t      __darwin_gid_t;         /* [???] process and group IDs */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'; did you mean '__uint128_t'?
typedef __uint64_t      __darwin_ino64_t;       /* [???] Used for 64 bit inodes */
        ^
note: '__uint128_t' declared here
'__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_id_t;          /* [XSI] pid_t, uid_t, or gid_t*/
        ^/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_uid_t;         /* [???] user IDs */
        ^
note: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'; did you mean '__uint128_t'?
typedef __uint16_t      __darwin_mode_t;        /* [???] Some file attributes */
        ^
'__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'; did you mean '__uint128_t'?
typedef __uint16_t      __darwin_mode_t;        /* [???] Some file attributes */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_useconds_t;    /* [???] microseconds */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
typedef __int64_t       __darwin_off_t;         /* [???] Used for file sizes */
        ^
note: '__int128_t' declared here

note: '__uint128_t' declared here/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_pid_t;         /* [???] process and group IDs */
        ^
note: '__int128_t' declared here
:68:9: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.hIn file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__timeval.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_sigset_t;      /* [???] signal set */
        ^
note: '__uint128_t' declared here
note: '__uint128_t' declared here
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */
        ^
error: unknown type name '__darwin_natural_t'
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */
        ^/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'; did you mean '__uint128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'; did you mean '__uint128_t'?
:62:9:typedef __int64_t       __darwin_off_t;         /* [???] Used for file sizes */typedef __uint16_t      __darwin_mode_t;        /* [???] Some file attributes */typedef __uint16_t      __darwin_mode_t;        /* [???] Some file attributes */

 :/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h43:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_wctype_t;
        ^

        ^
note: '__uint128_t' declared here
note: '__uint128_t' declared here
        ^
note: '__uint128_t' declared here
error: unknown type name '__uint64_t'; did you mean '__uint128_t'?
typedef __uint64_t      __darwin_ino64_t;       /* [???] Used for 64 bit inodes */
        ^
note: '__uint128_t' declared here

:74:9: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.herror: unknown type name '__int32_t'; did you mean '__int128_t'?
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__timeval.c:15:
typedef __int32_t       __darwin_suseconds_t;   /* [???] microseconds */        ^
:71:9: 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h        ^
:notenote71: errorIn file included from '__int128_t' declared here:
/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h: 9: unknown type name '__int64_t'; did you mean '__int128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:'__int128_t' declared here70:9
:214:
In file included from :/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h :33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:31:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/types.h:37:2: error: architecture not supported
#error architecture not supported
 ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_pid_t;         /* [???] process and group IDs */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_uid_t;         /* [???] user IDs */
        ^
note: '__uint128_t' declared here
: error: unknown type name '__int64_t'; did you mean '__int128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __int64_t       __darwin_off_t;         /* [???] Used for file sizes */
        ^
typedef __uint32_t      __darwin_sigset_t;      /* [???] signal set */
typedef __int64_t       __darwin_off_t;         /* [???] Used for file sizes */error: unknown type name '__uint16_t'; did you mean '__uint128_t'?
typedef __uint16_t      __darwin_mode_t;        /* [???] Some file attributes */
        ^
note: '__uint128_t' declared here

        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:76:9: error: note: '__int128_t' declared here
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_pid_t;         /* [???] process and group IDs */
        ^
unknown type name '__uint32_t'; did you mean '__uint128_t'?
note: '__int128_t' declared here
typedef __uint32_t      __darwin_useconds_t;    /* [???] microseconds */
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__timeval.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:32:9:        ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.hnote : '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
typedef __int64_t       __darwin_off_t;         /* [???] Used for file sizes */
        ^
note:74:9error: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h: :/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:73'__int128_t' declared here:
:68:9: error: unknown type name '__darwin_natural_t'
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */
: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_suseconds_t;   /* [???] microseconds */
        ^
note: '__int128_t' declared here
9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
unknown type name '__darwin_va_list'
typedef __darwin_va_list va_list;
        ^
72:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_pid_t;         /* [???] process and group IDs */
        ^
note: '__int128_t' declared here
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:75:9: errorIn file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__parse_into_addrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_pid_t;         /* [???] process and group IDs */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h::typedef __uint32_t      __darwin_sigset_t;      /* [???] signal set */
:         ^64unknown type name '__uint32_t'; did you mean '__uint128_t'?:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:43:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h73

typedef __uint32_t      __darwin_uid_t;         /* [???] user IDs */
        ^typedef __uint32_t      __darwin_wctype_t;:
:
note: '__uint128_t' declared here
70:9:note:  error: unknown type name '__uint16_t'; did you mean '__uint128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
'__uint128_t' declared here        ^9: error: typedef __uint16_t      __darwin_mode_t;        /* [???] Some file attributes */


note: unknown type name '__uint32_t'; did you mean '__uint128_t'?typedef __uint32_t      __darwin_sigset_t;      /* [???] signal set */
        ^'__uint128_t' declared here
fatal error
        ^
note: : 
'__uint128_t' declared heretypedef __uint32_t      __darwin_sigset_t;      /* [???] signal set */too many errors emitted, stopping now [-ferror-limit=]/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h
        ^
note: 

note: '__uint128_t' declared here
:74:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_suseconds_t;   /* [???] microseconds */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__parse_into_addrinfo.c:typedef __uint32_t      __darwin_useconds_t;    /* [???] microseconds */
        ^/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int64_t       __darwin_off_t;         /* [???] Used for file sizes */
        ^
typedef __int32_t       __darwin_suseconds_t;   /* [???] microseconds */'__uint128_t' declared here


note16:         ^note:

'__int128_t' declared herenote
: : '__uint128_t' declared here
'__int128_t' declared here
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:31:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/types.h:37:2: error: architecture not supported
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.htypedef __uint32_t      __darwin_uid_t;         /* [???] user IDs */
        ^:
74:note: #error architecture not supported
 ^
'__uint128_t' declared here9: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h
error: unknown type name '__int32_t'; did you mean '__int128_t'?
:typedef __int32_t       __darwin_suseconds_t;   /* [???] microseconds */
        ^
72:9: note: error: unknown type name '__int32_t'; did you mean '__int128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h'__int128_t' declared here
:75:9typedef __int32_t       __darwin_pid_t;         /* [???] process and group IDs */
        ^
note: '__int128_t' declared here
: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_uid_t;         /* [???] user IDs */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:75:9typedef __uint32_t      __darwin_useconds_t;    /* [???] microseconds */
        ^
note: '__uint128_t' declared here
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__read_line.c: error: :17:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.hunknown type name '__uint32_t'; did you mean '__uint128_t'?:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h::7321476:9: error: :unknown type name '__uint32_t'; did you mean '__uint128_t'?9typedef __uint32_t      __darwin_uid_t;         /* [???] user IDs */:

In file included from : error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h
typedef __uint32_t      __darwin_useconds_t;    /* [???] microseconds */
        ^
typedef __uint32_t      __darwin_sigset_t;      /* [???] signal set */        ^
note: '__uint128_t' declared herenote: '__uint128_t' declared here

:
        ^
33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.hnote: '__uint128_t' declared here
:71:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:43:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_wctype_t;
        ^
note: '__uint128_t' declared here
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__parse_into_addrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__close_sockets.c/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h::75In file included from 17:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__read_line.c:
::In file included from 7476/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:::322149:99::
:In file included from  In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__sortaddrinfo.c:37:
error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
 error: /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:17:typedef __uint32_t      __darwin_useconds_t;    /* [???] microseconds */
        ^:

 In file included from unknown type name '__int32_t'; did you mean '__int128_t'?
/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.hnote:typedef __int32_t       __darwin_suseconds_t;   /* [???] microseconds */33In file included from 
        ^
: :error/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:
214note: '__uint128_t' declared here:: In file included from :
unknown type name '__darwin_va_list'In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h214'__int128_t' declared here
:/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33
typedef __darwin_va_list va_list;
:
:
In file included from In file included from         ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:31:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/types.h:37:2: error: architecture not supported
#error architecture not supported
 ^
64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:43:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_wctype_t;
        ^
note: '__uint128_t' declared here/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h
:75:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_uid_t;         /* [???] user IDs */
        ^
note: '__uint128_t' declared here
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__sortaddrinfo.c:37:
In file included from In file included from 64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:43:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_wctype_t;
        ^
note: '__uint128_t' declared here
/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__get_hostent.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:43:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_wctype_t;
        ^
noteIn file included from : '__uint128_t' declared here/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:31:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/types.h:37:fatal error
: too many errors emitted, stopping now [-ferror-limit=]
2: error: architecture not supported
#error architecture not supported
 ^
/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__close_sockets.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:31:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/types.h:37:2: error: architecture not supported
typedef __uint32_t      __darwin_useconds_t;    /* [???] microseconds */
        ^
note: '__uint128_t' declared here
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__get_hostent.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:31:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/types.h:37:2: error: architecture not supported
#error architecture not supported
 ^
[ 12%] Building C object source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares_cancel.c.o
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__read_line.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:32:9: error: unknown type name '__darwin_va_list'
typedef __darwin_va_list va_list;
        ^
#error architecture not supported
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__sortaddrinfo.c:37:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.hIn file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__readaddrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:43:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_wctype_t;
        ^
note: '__uint128_t' declared here
:32:9: error: unknown type name '__darwin_va_list'
typedef __darwin_va_list va_list;
        ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__readaddrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
fatal error: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:31:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/types.h:37In file included from too many errors emitted, stopping now [-ferror-limit=]
:/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__get_hostent.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:32:9: error: unknown type name '__darwin_va_list'
2: error: architecture not supported
typedef __darwin_va_list va_list;
        ^
#error architecture not supported
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__close_sockets.c:17:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:32:9: error: unknown type name '__darwin_va_list'
typedef __darwin_va_list va_list;
        ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
fatal error: too many errors emitted, stopping now [-ferror-limit=]
fatal error: too many errors emitted, stopping now [-ferror-limit=]
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares__readaddrinfo.c:16:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:32:9: error: unknown type name '__darwin_va_list'
typedef __darwin_va_list va_list;
        ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_cancel.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:68:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/cdefs.h:816:2: error: Unsupported architecture
#error Unsupported architecture
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_cancel.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:33:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported
#error architecture not supported
 ^
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_cancel.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:27:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
typedef __int64_t       __darwin_blkcnt_t;      /* total blocks */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_blksize_t;     /* preferred block size */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_dev_t;         /* dev_t */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_gid_t;         /* [???] process and group IDs */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_id_t;          /* [XSI] pid_t, uid_t, or gid_t*/
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'; did you mean '__uint128_t'?
typedef __uint64_t      __darwin_ino64_t;       /* [???] Used for 64 bit inodes */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'; did you mean '__uint128_t'?
typedef __uint16_t      __darwin_mode_t;        /* [???] Some file attributes */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t'; did you mean '__int128_t'?
typedef __int64_t       __darwin_off_t;         /* [???] Used for file sizes */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_pid_t;         /* [???] process and group IDs */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_sigset_t;      /* [???] signal set */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t'; did you mean '__int128_t'?
typedef __int32_t       __darwin_suseconds_t;   /* [???] microseconds */
        ^
note: '__int128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_uid_t;         /* [???] user IDs */
        ^
note: '__uint128_t' declared here
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_useconds_t;    /* [???] microseconds */
        ^
note: '__uint128_t' declared here
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_cancel.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:71:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_types.h:43:9: error: unknown type name '__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t      __darwin_wctype_t;
        ^
note: '__uint128_t' declared here
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_cancel.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:31:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/machine/types.h:37:2: error: architecture not supported
#error architecture not supported
 ^
20 errors generated.
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_cancel.c:15:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/ares_setup.h:214:
In file included from /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/source_subfolder/src/lib/setup_once.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/stdio.h:64:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/_stdio.h:75:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk/usr/include/sys/_types/_va_list.h:32:9: error: unknown type name '__darwin_va_list'
typedef __darwin_va_list va_list;
        ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
make[2]: *** [source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__parse_into_addrinfo.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
20 errors generated.
20 errors generated.
make[2]: *** [source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__timeval.c.o] Error 1
make[2]: *** [source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__close_sockets.c.o] Error 1
20 errors generated.
20 errors generated.
20 errors generated.
make[2]: *** [source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__get_hostent.c.o] Error 1
make[2]: *** [source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__readaddrinfo.c.o] Error 1
make[2]: *** [source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__read_line.c.o] Error 1
20 errors generated.
make[2]: *** [source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares__sortaddrinfo.c.o] Error 1
20 errors generated.
make[2]: *** [source_subfolder/src/lib/CMakeFiles/c-ares.dir/ares_cancel.c.o] Error 1
make[1]: *** [source_subfolder/src/lib/CMakeFiles/c-ares.dir/all] Error 2
make: *** [all] Error 2
c-ares/1.17.1: 
c-ares/1.17.1: ERROR: Package '4ff8ed1a642b72de555f2983e764c1573ec11938' build failed
c-ares/1.17.1: WARN: Build folder /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938
ERROR: c-ares/1.17.1: Error in build() method, line 68
	cmake.build()
	ConanException: Error 2 while executing cmake --build '/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/build_subfolder' '--' '-j8'
```
</details>

<details><summary> c-ares cmake options</summary>

```
/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/build_subfolder
cmake . -L
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan: Adjusting fPIC flag (ON)
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/build/4ff8ed1a642b72de555f2983e764c1573ec11938/build_subfolder
-- Cache values
CARES_BUILD_CONTAINER_TESTS:BOOL=OFF
CARES_BUILD_TESTS:BOOL=False
CARES_BUILD_TOOLS:BOOL=True
CARES_INSTALL:BOOL=ON
CARES_SHARED:BOOL=False
CARES_STATIC:BOOL=True
CARES_STATIC_PIC:BOOL=OFF
CMAKE_BUILD_TYPE:STRING=Debug
CMAKE_INSTALL_PREFIX:PATH=/Users/jeanyvesdumaquis/.conan/data/c-ares/1.17.1/_/_/package/4ff8ed1a642b72de555f2983e764c1573ec11938
CMAKE_OSX_ARCHITECTURES:STRING=x86_64
CMAKE_OSX_SYSROOT:STRING=iphoneos
```

</details>

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: Einh06
issue_9482: state: open
title: [question] Overriding renamed requirements
body: Is it possible to override the name of an requirement?

There is:
PkgA/1.0
PkgA/1.1
PkgB/1.0 requires PkgA/1.0
MyPkg/1.0 requires PkgB/1.0 and can overwrite PkgB's dependency of PkgA to PkgA/1.1

What if "PkgA" was renamed to "pkg_a" in version 2.0. How can MyPkg overwrite PkgB's dependency for "PkgA/1.0" to the new "pkg_a/2.0"?


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: naggerx
issue_9469: state: open
title: [bug] tools.get(...) broken symlinks when extracting zip files
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

cc: @a4z 

The NDK r23 zip file contains the symlinks now. 
>lrwxr-xr-x  1 enh  primarygroup         8 Aug 23 12:47 clang -> clang-12
lrwxr-xr-x  1 enh  primarygroup         5 Aug 23 12:47 clang++ -> clang
-rwxr-xr-x  1 enh  primarygroup  75426096 Jul 30 17:06 clang-12

After unzipping we have two text files clang und clang++.
<img width="628" alt="symlinks" src="https://user-images.githubusercontent.com/52277783/130581648-a956ec08-2900-4d9e-805f-c69be6cb139a.png">


### Environment Details (include every applicable attribute)
  * Operating System+version: macOS Catalina 10.15.7
  * Conan version: 1.39
  * Python version: 3.9.1

### Steps to reproduce (Include if Applicable)

1) conan install android-ndk/r23@
2) $ANDROID_NDK_ROOT/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ --version
<img width="762" alt="ndk23_failed" src="https://user-images.githubusercontent.com/52277783/130581236-f2760798-ef47-4b18-954f-6f05cda3a1bf.png">

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: dmn-star
issue_9467: state: open
title: [question] How can I (re)build everything except the build requirements?
body: <!-- What is your question? Please be as specific as possible! -->
 conan install --build without arguments  will rebuild from sources all dependencies. That is exactly what I need, but I' d like to not have to rebuild the build requirements every time. Maybe something like this conan install --build=skip_build_requirements already exist? Or what is the easiest way to achieve this?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: dmn-star
issue_9464: state: open
title: [feature] add QNX stdlib libc++/libstdc++ support to settings.yml
body: Hi there,
my feture request is to add the following elements to the ```settings.yml```.
qcc -> libcxx -> "libc++" and "libstdc++"

### Background
Since QNX 7.0 the compiler QCC supports the parameter ```stdlib```. This selects the C++ library the compiler uses, as QNX supports different C++ library implementations out-of-the-box ([see docs here](https://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx.doc.neutrino.utilities/topic/q/qcc.html)).

This maps internally as follows:
-stdlib= | -Y | Library
-- | -- | --
libc++ | _cxx | LLVM C++
libstdc++ | _gpp | GNU C++

Best regards.
user: Johnnyxy
issue_9458: state: open
title: [bug] Vulkan packages stopped working on Ubuntu 21.04
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 21.04 (currently, formerly 20.04)
  * Compiler+version: g++ 10.3.0
  * Conan version: 1.39.0
  * Python version: 3.9.5

### Steps to reproduce (Include if Applicable)
Create a vulkan application that should create a validation error. Download the packages:
```
"vulkan-headers/1.2.184",
"vulkan-loader/1.2.182",
"vulkan-validationlayers/1.2.182"
 ```
 Compile and run the application. The net result should be that validation layers are loaded but do not trigger when expected.
  
 ### Details
When I was in Ubuntu 20.04 using these packages validation layers worked properly. However, after upgrading to the newest Ubuntu version validation layers are no longer triggered. If instead of using the conan packages I use the SDK validation layers do trigger as expected. 

To be clear, I am setting the environment variables:
```
VK_LAYER_PATH
LD_LIBRARY_PATH 
```

If I set them with the SDK validation works, if I instead set them to the conan installed packages validation is not triggered.

user: Makogan
issue_9450: state: open
title: [question] Conan python: can't open file "No such file or directory" error when installing or packaging a library on Windows 10
body: <img width="935" alt="b" src="https://user-images.githubusercontent.com/6761729/130101483-97e26ae9-3f2d-4d21-ad90-637a657095bd.png">
The python open file path  is wrong，how to fix it？
user: chenyiliang
issue_9444: state: open
title: [bug] find_package: missing or wrongly named variables
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details
  * Conan version: 1.39.0

### Steps to reproduce

* combining
  - `conan install`
    - `conanfile.txt`: `boost/1.69.0` + (`cmake_paths`, `cmake_find_package`)
  - `cmake -GNinja -B . -S .. -DCMAKE_TOOLCHAIN_FILE=conan_paths.cmake`
    - `link_directories(${Boost_LIBRARY_DIRS})`
    - `target_link_libraries(...... boost_stacktrace_addr2line)`
* --> leads to `cannot find -lboost_stacktrace_addr2line`

### Problem

Conan cmake generator is missing some `find_package()` variables or setting it in wrong name. CMake `Find${something}` is designed to give result variables including `..._LIBRARY_DIRS` and so on.

The list of variables I found missing:
- `*_LIBRARY_DIRS` (only `*_LIB_DIRS exists`)
- `*_<COMPONENT>_LIBRARY` (only `*_<COMPONENT>_LIBS` exists)

Espcially, `_LIBRARY_DIRS` is useful when using CMake `link_directories()`, for legacy library linking env compatibility. (yes, this is my case)

For example, [FindBoost offers](https://cmake.org/cmake/help/latest/module/FindBoost.html#result-variables) `Boost_LIBRARY_DIRS`, `Boost_INCLUDE_DIRS`, `Boost_LIBRARY_DIRS`, `Boost_<COMPONENT>_LIBRARY`(e.g. `Boost_system_LIBRARY`) variables. Conan sets `Boost_INCLUDE_DIRS`, `Boost_LIB_DIRS` but not `Boost_LIBRARY_DIRS`. Same things happen to other parts like `Boost_<COMPONENT>_LIBRARY`, having `Boost_<COMPONENT>_LIBS` instead.

### Related code lines

https://github.com/conan-io/conan/blob/42beaf2a402157f23f11ba5ba8b15030b51c2251/conans/client/generators/cmake_find_package_common.py#L6-L27

https://github.com/conan-io/conan/blob/42beaf2a402157f23f11ba5ba8b15030b51c2251/conans/client/generators/cmake_find_package.py#L97-L116

https://github.com/conan-io/conan/blob/42beaf2a402157f23f11ba5ba8b15030b51c2251/conans/client/generators/cmake_find_package_multi.py#L124-L139

### attachment: CMake FindBoost official documentation

https://cmake.org/cmake/help/latest/module/FindBoost.html#result-variables

```
This module defines the following variables:

Boost_FOUND
    True if headers and requested libraries were found.
Boost_INCLUDE_DIRS
    Boost include directories.
Boost_LIBRARY_DIRS
    Link directories for Boost libraries.
Boost_LIBRARIES
    Boost component libraries to be linked.
Boost_<COMPONENT>_FOUND
    True if component <COMPONENT> was found (<COMPONENT> name is upper-case).
Boost_<COMPONENT>_LIBRARY
    Libraries to link for component <COMPONENT> (may include target_link_libraries() debug/optimized keywords).
```

### attachment: part of generated FindBoost

```
set(Boost_COMPILE_DEFINITIONS "BOOST_STACKTRACE_ADDR2LINE_LOCATION=\"/usr/bin/addr2line\""
                        "BOOST_STACKTRACE_USE_ADDR2LINE"
                        "BOOST_STACKTRACE_USE_BACKTRACE"
                        "BOOST_STACKTRACE_USE_NOOP")
set(Boost_COMPILE_OPTIONS_LIST "" "")
set(Boost_COMPILE_OPTIONS_C "")
set(Boost_COMPILE_OPTIONS_CXX "")
set(Boost_LIBRARIES_TARGETS "") # Will be filled later, if CMake 3
set(Boost_LIBRARIES "") # Will be filled later

# <<<<<<<< `Boost_LIBRARY_DIRS` missing!

set(Boost_LIBS "") # Same as Boost_LIBRARIES
set(Boost_SYSTEM_LIBS dl rt pthread)
set(Boost_FRAMEWORK_DIRS )
set(Boost_FRAMEWORKS )
set(Boost_FRAMEWORKS_FOUND "") # Will be filled later
set(Boost_BUILD_MODULES_PATHS )
```
user: igxactly
issue_9434: state: open
title: [bug] the wrong command line argument `-stdlib=libstdc++`
body: There is the wrong command line argument `-stdlib=libstdc++`.

```
clang++: warning: argument unused during compilation: '-stdlib=libstdc++' [-Wunused-command-line-argument]
```

### Environment Details (include every applicable attribute)
  * Windows Server 2019 
  * `Visual Studio 16 ClangCl` or `Clang 13`
  * Conan version: 1.41.0
  * Python version: 3.9.6

### Steps to reproduce (Include if Applicable)
`conan install . --install-folder build --build=outdated -s build_type=Debug -s compiler.cppstd=17 -s compiler.version=16 -s compiler="Visual Studio" -s compiler.toolset=ClangCL -e CC=clang-cl -e CXX=clang-cl`

user: arttet
issue_9426: state: open
title: [question] Support for atomic bulk promotion using lockfiles CI
body: # Summary

How can we use the lockfiles CI technique documented in https://docs.conan.io/en/latest/versioning/lockfiles/ci.html to atomically build 2 or more packages for promotion?

# Background

With much very appreciated help from the Conan team, we have implemented a lockfiles-based CI following the example in https://docs.conan.io/en/latest/versioning/lockfiles/ci.html .

As we are in a larger organization and do not have permissions to create Artifactory repositories on the fly, and since Artifactory move operations for multiple packages are not guaranteed to be atomic, for the moment we have settled on a practice of using a single stable Artifactory repo, and trusting that lockfile-based builds will ensure the consistency.

Roughly, we do the following:

Our conan configuration installed by all users including our Jenkins build job user contains:

```
[general]
default_package_id_mode = package_revision_mode
```

This is because we can't trust that our organization's packages respect semver, and we need to ensure correctness.  So any change in a binary package revision should cause Conan to calculate that all other dependent packages must be rebuilt.


First, we `conan create` build the desired package to be promoted itself, for the required build profiles, e.g. debug and release:

```
                        def buildProfiles = conan_build_profiles.tokenize(',')

                        conanClient.run(buildInfo: buildInfo, command: "lock create ./conanfile.py --version ${conan_package_version} --user ${conan_package_user} --channel ${conan_package_channel} --build=${conan_build_policy} ${conan_lock_create_base_recipe_information_only_additional_parameters} ".toString())

                        conanClient.run(buildInfo: buildInfo, command: "export . ${packageNameFromInspect}/${conan_package_version}@${conan_package_user}/${conan_package_channel}  ${conan_lock_export_recipe_with_full_reference_additional_parameters}".toString())

                        def builtPackages = [].toSet()

                        buildProfiles.each {

                            conanClient.run(buildInfo: buildInfo, command: "lock create ./conanfile.py --version ${conan_package_version}  --user=${conan_package_user} --channel=${conan_package_channel} --lockfile-out=package_per_profile_deps_${it}.lock --profile ${it} --build=${conan_build_policy} ${conan_lock_create_package_per_profile_additional_parameters}".toString())

                            conanClient.run(buildInfo: buildInfo, command: "info ${packageNameFromInspect}/${conan_package_version}@${conan_package_user}/${conan_package_channel} --graph=dependency_graph_${it}.html -l package_per_profile_deps_${it}.lock  --build=${conan_build_policy} ${conan_info_graph_per_profile_additional_parameters}".toString())

                            conanClient.run(buildInfo: buildInfo, command: "create . ${conan_package_version}@${conan_package_user}/${conan_package_channel} --json conanCreateOutput_${it}.json --lockfile=package_per_profile_deps_${it}.lock ${conan_additional_create_parameters}".toString())

                            // We created different conanCreateOutput_<someprofile>.json for each buildProfiles element.
                            def conanCreateOutputJson = readJSON file: "conanCreateOutput_${it}.json"
                            builtPackages = created_refs(builtPackages, conanCreateOutputJson)
                            echo "builtPackages[${builtPackages}] after conan create for profile[${it}]"
                        }
```

As we go, we parse `created_refs` from the json output of the conan create commands, to build a list of built packages which should be uploaded to Artifactory, if the entire build succeeds.

Then we proceed with what we called our "buildall verification" using `conan install`:

```
                            // Create base lock file for distribution
                            conanClient.run(buildInfo: buildInfo, command: "lock create --reference=${conan_distribution_name}/${conan_distribution_version}@${conan_distribution_user}/${conan_distribution_channel} --build=${conan_build_policy} ${conan_lock_create_base_distribution_additional_parameters}".toString())

                            // Create distribution-based lock files and build-order for each profile
                            buildProfiles.each {
                                echo "Distribution lockfile for buildProfile[${it}]"
                                env.MY_FAILURE_STAGE = STAGE_NAME + "__conan_buildall_verification_build_order_distribution_loop_profile_${it}"

                                conanClient.run(buildInfo: buildInfo, command: "lock create --reference=${conan_distribution_name}/${conan_distribution_version}@${conan_distribution_user}/${conan_distribution_channel} --build=${conan_build_policy} ${conan_lock_create_distribution_per_profile_additional_parameters} --lockfile-out=distribution_per_profile_deps_${it}.lock --profile ${it}".toString())

                                conanClient.run(buildInfo: buildInfo, command: "lock build-order distribution_per_profile_deps_${it}.lock --json build_order_${it}.json".toString())
                            }

                            // Looping through the build order files to try building downstream packages
                            buildProfiles.each {
                                echo "Building downstream packages for buildProfile[${it}] using build-order file build_order_${it}.json"
                                env.MY_FAILURE_STAGE = STAGE_NAME + "__conan_buildall_verification_downstream_build_loop_profile_${it}"

                                def buildOrderFile_json = readJSON file: "build_order_${it}.json"
                                buildOrderFile_json.each { level ->
                                    echo "Building build-order level"
                                    level.each { array ->
                                        def package_ref = array[0]
                                        def package_id = array[1]
                                        def context = array[2]
                                        def id = array[3]

                                        echo "Building build-order item: package_ref[${package_ref}] package_id[${package_id}] context[${context}] id[${id}]"

                                        def (String verify_name, String verify_ver, String verify_user, String verify_channel, String verify_packageRevision) = parseReference(package_ref.toString())
                                        echo "verify package_ref[" + package_ref.toString() + "] verify_name[" + verify_name + "] verify_ver[" + verify_ver + "] verify_user[" + verify_user + "] verify_channel[" + verify_channel + "] verify_packageRevision[" + verify_packageRevision + "]"

                                        conanClient.run(buildInfo: buildInfo, command: "install ${package_ref} --build=${package_ref}  --json conanBuildallInstallOutput_${verify_name}_${it}.json --lockfile=distribution_per_profile_deps_${it}.lock --lockfile-out=distribution_per_profile_deps_${it}_updated.lock".toString())

                                        // We created different conanBuildallInstallOutput_<package>_<someprofile>.json for each package that needed to be rebuilt to verify the build.
                                        def conanBuildallInstallOutputJson = readJSON file: "conanBuildallInstallOutput_${verify_name}_${it}.json"
                                        builtPackages = created_refs(builtPackages, conanBuildallInstallOutputJson)
                                        echo "builtPackages[${builtPackages}] after conan install build for profile[${it}]"

                                        conanClient.run(buildInfo: buildInfo, command: "lock update distribution_per_profile_deps_${it}.lock distribution_per_profile_deps_${it}_updated.lock".toString())
                                    }
                                }
                            }
                        }

```

Notice that during the iteration through the buildOrderFile_json, we augment the lock file using `lock update`, and also continued to append to builtPackages with the `created_refs` from each `conan install` operation.

Finally we upload all builtPackages to Artifactory:

```
                            builtPackages.each {
                                def builtPackage = "${it}"
                                echo "builtPackage[${builtPackage}]"

                                // Ensure we have a valid package reference for the upload.
                                // Work around https://github.com/conan-io/conan/issues/6862
                                if ( builtPackage.indexOf('@') == -1 ) {
                                    echo 'builtPackage does not contain @'
                                    if ( builtPackage.indexOf('#') == -1 ) {
                                        echo 'builtPackage does not contain #, appending @'
                                        builtPackage = builtPackage + '@'
                                    } else {
                                        echo 'builtPackage does contain #, inserting @ immediately before it'
                                        builtPackage = builtPackage.replaceFirst('#', '@#')
                                    }
                                }

                                def command = "upload ${builtPackage} --all -r ${artifactoryUploadRemote} ${conan_additional_upload_parameters}"
                                conanClient.run buildInfo: buildInfo, command: command.toString()
```

At this point, we believe we've guaranteed that our stable Artifactory repo contains a set of packages, the newest revision of each builds consistently with all the others.

# The Question

This mechanism allows us to use `conan create` initially to build/update a single package and test that its updated version won't break the build of any package in the dependency DAG.  But sometimes we have found that in order to make breaking changes to a package, it's necessary to be able to prepare and submit for 'promotion' N packages at a time, and then test the build of all N of those packages together, along with the subsequent buildall verification of all dependent packages later.

How can we fit this concept into the current lockfiles CI based workflow described above?

# Pretty Pictures

We have the following build DAG.  We wish to promote a new version of package E which we do with our initial `conan create` command.  We then use lockfiles and Conan calculates that F,G,I,H will be affected by this change, and will need to be rebuilt, which we will do using `conan install` over the build_order calculated from the lockfile:

![image](https://user-images.githubusercontent.com/2184330/129420758-09531d94-a3fd-4801-8e58-341666980a56.png)

However, we've made a change in E which we know will be a breaking change for G:

![image](https://user-images.githubusercontent.com/2184330/129420906-cfd2d276-f110-4d16-a4af-1433b99f0c51.png)

How can we change our build workflow so that we can `conan create` both E and G and then submit them to the build DAG verification using `conan install`?



- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: michaelmaguire
issue_9425: state: open
title: [bug] self.folders.generators does not work with virtualrunenv
body: I tried the new layout feature to set `self.folders.generators`
```
    def layout(self):
        self.folders.generators = os.path.join(self.folders.build, "generators")
```

* it works as expected with `CMakeDeps`: files are generated in **generators** directory
* it DOES NOT WORK with `virtualrunenv`: files are still generated in the root build directory


### Environment Details (include every applicable attribute)
  * Operating System+version: windows 10
  * Compiler+version: msvc 16.
  * Conan version: 1.39.0
  * Python version: 3.9

user: boussaffawalid
issue_9420: state: open
title: [question] Multidirectory project layout and setup with unit tests
body: I am trying to set up my project using Conan and Cmake. My goal is to have a unit tested library package. How do I link everything together via Cmake and Conan? I think the issue is somewhere in my CMakeLists.txt files but I do not know where. What I have so far:

Project structure
![image](https://user-images.githubusercontent.com/55909434/129243186-a63d46a0-dab7-4928-a34d-c780c559f2eb.png)

When I run `conan create .. user/testing` in build directory I get:
```
Exporting package recipe
kata_lib/0.1@user/testing: A new conanfile.py version was exported
kata_lib/0.1@user/testing: Folder: C:\Users\simon\.conan\data\kata_lib\0.1\user\testing\export
kata_lib/0.1@user/testing: Package recipe modified in export, forcing source folder removal
kata_lib/0.1@user/testing: Use the --keep-source, -k option to skip it
kata_lib/0.1@user/testing: Exported revision: 00f0a9ee032aa0fa3d3204ce63d0b4a5
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=Visual Studio
compiler.cppstd=20
compiler.runtime=MDd
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

kata_lib/0.1@user/testing: Forced build from source
kata_lib/0.1@user/testing (test package): Installing package
Requirements
    kata_lib/0.1@user/testing from local cache - Cache
Packages
    kata_lib/0.1@user/testing:37c40aea661afde5d67eb2057cb0ff32cb5d16b4 - Build
Build requirements
    gtest/1.8.1 from 'conancenter' - Cache
Build requirements packages
    gtest/1.8.1:bb9f026619c43208dfbf77d9a92d6de72d14c141 - Cache

Installing (downloading, building) binaries...
gtest/1.8.1: Already installed!
kata_lib/0.1@user/testing: Applying build-requirement: gtest/1.8.1
kata_lib/0.1@user/testing: WARN: Build folder is dirty, removing it: C:\Users\simon\.conan\data\kata_lib\0.1\user\testing\build\37c40aea661afde5d67eb2057cb0ff32cb5d16b4
kata_lib/0.1@user/testing: Configuring sources in C:\Users\simon\.conan\data\kata_lib\0.1\user\testing\source
kata_lib/0.1@user/testing: Copying sources to build folder
kata_lib/0.1@user/testing: Building your package in C:\Users\simon\.conan\data\kata_lib\0.1\user\testing\build\37c40aea661afde5d67eb2057cb0ff32cb5d16b4
kata_lib/0.1@user/testing: Generator cmake created conanbuildinfo.cmake
kata_lib/0.1@user/testing: Calling build()
CMake Error: The source directory "C:/Users/simon/.conan/data/kata_lib/0.1/user/testing/build/37c40aea661afde5d67eb2057cb0ff32cb5d16b4" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
kata_lib/0.1@user/testing:
kata_lib/0.1@user/testing: ERROR: Package '37c40aea661afde5d67eb2057cb0ff32cb5d16b4' build failed
kata_lib/0.1@user/testing: WARN: Build folder C:\Users\simon\.conan\data\kata_lib\0.1\user\testing\build\37c40aea661afde5d67eb2057cb0ff32cb5d16b4
ERROR: kata_lib/0.1@user/testing: Error in build() method, line 25
        cmake.configure()
        ConanException: Error 1 while executing cd C:\Users\simon\.conan\data\kata_lib\0.1\user\testing\build\37c40aea661afde5d67eb2057cb0ff32cb5d16b4 && cmake -G "Visual Studio 16 2019" -A "x64" -DCONAN_LINK_RUNTIME="/MDd" -DCONAN_CMAKE_CXX_STANDARD="20" -DCONAN_CMAKE_CXX_EXTENSIONS="OFF" -DCONAN_STD_CXX_FLAG="/std:c++latest" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="Visual Studio" -DCONAN_COMPILER_VERSION="16" -DCONAN_CXX_FLAGS="/MP16" -DCONAN_C_FLAGS="/MP16" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="C:\Users\simon\.conan\data\kata_lib\0.1\user\testing\package\37c40aea661afde5d67eb2057cb0ff32cb5d16b4" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -Wno-dev C:\Users\simon\.conan\data\kata_lib\0.1\user\testing\build\37c40aea661afde5d67eb2057cb0ff32cb5d16b4
```
kata_lib/conanfile.py
```
import os
from conans import ConanFile, CMake, tools


class KataLibConan(ConanFile):
    name = "kata_lib"
    version = "0.1"
    license = "<Put the package license here>"
    author = "<Put your name here> <And your email here>"
    url = "<Package recipe repository url here, for issues about the package>"
    description = "<Description of KataLib here>"
    topics = ("<Put some tag here>", "<here>", "<and here>")
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False], "fPIC": [True, False]}
    default_options = {"shared": False, "fPIC": True}
    generators = "cmake"
    build_requires = "gtest/1.8.1"

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
        self.run(os.sep.join("bin", "test"))

        # Explicit way:
        # self.run('cmake %s/hello %s'
        #          % (self.source_folder, cmake.command_line))
        # self.run("cmake --build . %s" % cmake.build_config)

    def package(self):
        self.copy("*.h", dst="include", src="kata_lib")
        self.copy("*kata_lib.lib", dst="lib", keep_path=False)
        self.copy("*.dll", dst="bin", keep_path=False)
        self.copy("*.so", dst="lib", keep_path=False)
        self.copy("*.dylib", dst="lib", keep_path=False)
        self.copy("*.a", dst="lib", keep_path=False)

    def package_info(self):
        self.cpp_info.libs = ["kata_lib"]
```
kata_lib/CMakeLists.txt
```
cmake_minimum_required(VERSION 3.1)
project(kata_lib CXX)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

add_subdirectory(src)
add_subdirectory(test)
add_subdirectory(test_package)

add_library(kata_lib basic_op.h
                     basic_op.cpp)
target_link_libraries(kata_lib ${CONAN_LIBS})

add_test (
    NAME test
    WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/bin
    COMMAND test
)
```
kata_lib/src/CMakeLists.txt
```
add_library(
    kata_lib
    basic_op.h
    basic.op.cpp
)
```
kata_lib/src/basic_op.h
```
#pragma once
#include <map>
#include <functional>

namespace kata_lib {
    static int basic_op(char op, int val1, int val2);
}
```
kata_lib/src/basic_op.cpp
```
#include "basic_op.h"

namespace kata_lib {
    static int basic_op(char op, int val1, int val2) {
        return (std::map<char, std::function<int(int, int)>>{{'-', std::minus<>()},
                                                            {'+', std::plus<>()},
                                                            {'*', std::multiplies<>()},
                                                            {'/', std::divides<>()}}).at(op)(val1, val2);
    }
}
```
kata_lib/test/CMakeLists.txt
`add_executable(test main.cpp)`
kata_lib/test/main.cpp
```
#include <gtest/gtest.h>

int main(int argc, char **argv) {
    ::testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}
```
kata_lib/test/basic_op_test.cpp
```
#include <gtest/gtest.h>

#include "basic_op.h"

TEST(basic_op, one_plus_one_should_be_two) {
    ASSERT_EQ(2, kata_lib::basic_op('+', 1, 1));
}
```
kata_lib/test_package/CMakeLists.txt
```
cmake_minimum_required(VERSION 3.1)
project(test_package CXX)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

add_executable(test_package test_package.cpp)
target_link_libraries(test_package ${CONAN_LIBS})
```
kata_lib/test_package/conanfile.py
```
import os

from conans import ConanFile, CMake, tools


class KataLibTestConan(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    generators = "cmake"

    def build(self):
        cmake = CMake(self)
        # Current dir is "test_package/build/<build_id>" and CMakeLists.txt is
        # in "test_package"
        cmake.configure()
        cmake.build()

    def imports(self):
        self.copy("*.dll", dst="bin", src="bin")
        self.copy("*.dylib*", dst="bin", src="lib")
        self.copy('*.so*', dst='bin', src='lib')

    def test(self):
        if not tools.cross_building(self):
            os.chdir("bin")
            self.run(".%sexample" % os.sep)
```
kata_lib/test_package/test_package.cpp
```
#include "basic_op.h"

int main() {
    kata_lib::basic_op('+', 1, 1);
}

```
- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: SimonBrazda
issue_9414: state: open
title: [question] CMakeDeps + CmakeToolchain collision with package find modules
body: Is there a way to tell `CMakeDeps` to not generate a config file for certain dependencies from the consumer side? Also is there a way to make the `CMakeToolchain` add the package paths to the module path, like `cmake_paths` generator did?

I'm using the package for `pybind11`, which ships its own `pybind11-config.cmake`, which contains useful macros. I'm also seeing a file by the same name generated via the `CMakeDeps`, of course without the macros. The toolchain only appends `CMAKE_BINARY_DIR` to the module path, so the generated one is found when I need to find the one within the package.

More generally:

CMake's `find_package` searches the module path to find `FindFoo.cmake` or `Foo-config.cmake`. In the context of conan (assuming I want to only find conan packages, not system-installed libs), there are a few places such files would normally be found:
- Within the CMakes installation's modules folder 
- Within a conan package folder in the cache. This is the case if:
  - The library itself provides its own `Foo-config.cmake`. Mature libraries based on CMake are advised to provide this.
  - The recipe for `Foo` exports a `FindFoo.cmake`.
- Within `CMAKE_BINARY_DIR` when `CMakeDeps` generator is used

When using `CMakeDeps` + `CMakeToolchain`, only the last one is effectively possible. Other generators, like `cmake_paths` add package folders to the module path, but this is no the case with `CMakeDeps` + `CMakeToolchain`. However, conan intends to sunset `cmake_paths` and other cmake generators in favor of `CMakeDeps`. 

The config files within the package should take precedent because it has been specialized for the particular package and provides necessary macros. To enable this, I believe `CMakeToolchain` needs to add the package folders to the module path, like `cmake_paths` does, and `CMakeDeps` needs a way to be prevented from generating config files for individual packages.

You could consider this partly a bug in the recipe for `Foo`. The recipe should set `self.cpp_info.set_property("skip_deps_file", True)` if it is providing its own config file. However, it would be super convenient to affect this from the consumer side so I don't have to fork the recipe. Even after that, I have to do some manual steps to get the `Foo` package folder in the module path.

Less critically, I'd also expect that the default find-modules in the cmake installation should take precedent over the generated config files. `CMakeToolchain` has defeated this by setting `set(CMAKE_FIND_PACKAGE_PREFER_CONFIG ON)`. I believe I can override this in my `generate` method, but I'm surprised the default is to take the generated config files over the handcrafted ones.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: kenfred
issue_9412: state: open
title: [bug] Downloading a big package fails with Incorrect Content-Range header 
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version: clang 9
  * Conan version: 1.39.0
  * Python version: 3.8.10

### Steps to reproduce (Include if Applicable)
* Simply trying to run `conan install android-ndk/r21d@` yields the error, the download fails, keep retrying and failing the same way.
* The same error happens with a different android NDK package.

This seems similar to #7498 except the package is on Conan center in this case.

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
conan install android-ndk/r21d@
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=clang
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
CC=/usr/bin/clang-9
CXX=/usr/bin/clang++-9
Installing package: android-ndk/r21d
Requirements
    android-ndk/r21d from 'conan-center' - Cache
Packages
    android-ndk/r21d:4db1be536558d833e52e862fd84d64d75c2b3656 - Download

Installing (downloading, building) binaries...
android-ndk/r21d: Retrieving package 4db1be536558d833e52e862fd84d64d75c2b3656 from remote 'conan-center' 
Downloading conanmanifest.txt completed [1028.25k]                                       
Downloading conaninfo.txt completed [0.20k]                                              
Downloading conan_package.tgz completed [1056295.44k]                                    
ERROR: Download failed, check server, possibly try again
Download failed, check server, possibly try again
Error in resumed download from https://center.conan.io/artifactory/api/conan/conan-center/v1/files/_/android-ndk/r21d/_/5013605c2f2c7c4cd448ea2d5c77e274/package/4db1be536558d833e52e862fd84d64d75c2b3656/f0d2c0a89bfe4745335cfea2ce9fd5d4/conan_package.tgz
Incorrect Content-Range header 
Waiting 0 seconds to retry...
Downloading conan_package.tgz completed [1057303.94k]                                    
ERROR: Download failed, check server, possibly try again
Download failed, check server, possibly try again
Error in resumed download from https://center.conan.io/artifactory/api/conan/conan-center/v1/files/_/android-ndk/r21d/_/5013605c2f2c7c4cd448ea2d5c77e274/package/4db1be536558d833e52e862fd84d64d75c2b3656/f0d2c0a89bfe4745335cfea2ce9fd5d4/conan_package.tgz
Incorrect Content-Range header 
Waiting 0 seconds to retry...
```

user: jblort
issue_9406: state: open
title: [question] use conanfile.py var in profile env section
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
## My build system download tool chain independently and config by Linux environment value.
In my build system, we compressed pre-built tool chains (GCC or LLVM) and saved them to some cloud storage, which could be downloaded by python SDK or link. I use profile.txt to save ENV of compiler and linker, such as CC=/path/to/downloaded/gcc and LD=/path/to/downloaded/ld. 
## In which procedure should I download and decompress the tool chain package?
Now my question is, should I download tool chain in conanfile.py? If so, I have to set the download path like ".toolchain" str to profile, but it is conanfile.py to define which place the tool chain saved. However, loading of profile is ahead of conan dealing with conanfile.py, though profiles support jinja2 now, I still have no method to get any symbol from conanfile.py.
## Which way is more conan-thic？
If I call a python function "download tool chain" independently, it will be much more convenient to call Conan by some python API method rather than os.system("conan build ..."), since Conan is written with python (I haven't found any API like this. In doc.conan.io "Other System" section, it seems Conan prefers to reserve those tool chain prepared work to other system like Yocto).
Would you please to tell me which method is in harmony with Conan design philosophy? To call download tool chain ahead of time or Conan source() makes it?
Thank you.
user: benet96
issue_9391: state: open
title: [bug] QNX 7 builds are failing due to the -std=c++11
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Mac OS 11.3.1
  * Compiler+version: qcc SDP 7.0
  * Conan version: 1.39.0
  * Python version: 3.9.6

### Steps to reproduce (Include if Applicable)
Building Alexa Auto SDK for QNX platform on Mac
QNX SDP 7.0 is installed.
QNX profile :
```
include(default)
[settings]
os=Neutrino
os.version=7.0
arch=armv8
compiler=qcc
compiler.version=5.4
compiler.libcxx=cxx
[options]
[build_requires]
[env]
CC="qcc -Vgcc_ntoaarch64le -Y_cxx"
CXX="q++ -lang-c++ -Vgcc_ntoaarch64le -Y_cxx"
CPP="qcc -Vgcc_ntoaarch64le -E"
QNX_HOST=/Users/<name>/qnx700/host/darwin/x86_64
QNX_TARGET=/Users/<name>/qnx700/target/qnx7
```
Command used to build
```
$  conan create modules/core --profile aac-qnx -b missing
```
It is observed that the conan is  additionally adding `-std=c++11` to the compile flag that caused the qcc compile to fail. When manually removed the flag the compilation goes thru.

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->
```
Building CXX object CMakeFiles/AACECore.dir/engine/src/Logger/Sinks/FileSink.cpp.o
/Users/<user>/qnx700/host/darwin/x86_64/usr/bin/q++  -lang-c++ -Vgcc_ntoaarch64le -Y_cxx -lang-c++ -DAACECore_EXPORTS -DAAC_DEFAULT_LOGGER_ENABLED -DAAC_DEFAULT_LOGGER_LEVEL -DAAC_DEFAULT_LOGGER_LEVEL_INFO -DAAC_DEFAULT_LOGGER_SINK -DAAC_DEFAULT_LOGGER_SINK_CONSOLE -DNDEBUG -DRAPIDJSON_HAS_STDSTRING -I/Users/<user>/.conan/data/rapidjson/1.1.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include -I/Users/<user>/.conan/data/nlohmann_json/3.8.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include -I/Users/<user>/.conan/data/sqlite3/3.32.3/_/_/package/fcff8ec1a1f8a9d4a09d4f949e4c4f01048812f2/include -I/Users/<user>/.conan/data/aac-module-core/dev/_/_/build/419913d4b251896f5fc5501f6a4fce19cce715ac/AACECore -I/Users/<user>/.conan/data/aac-module-core/dev/_/_/build/419913d4b251896f5fc5501f6a4fce19cce715ac/engine/include -I/Users/<user>/.conan/data/aac-module-core/dev/_/_/build/419913d4b251896f5fc5501f6a4fce19cce715ac/platform/include -Wall -O2   -O3 -DNDEBUG -O3 -DNDEBUG  -fPIC -std=c++11 -Wp,-MD,CMakeFiles/AACECore.dir/engine/src/Logger/Sinks/FileSink.cpp.o.d -Wp,-MT,CMakeFiles/AACECore.dir/engine/src/Logger/Sinks/FileSink.cpp.o -Wp,-MF,CMakeFiles/AACECore.dir/engine/src/Logger/Sinks/FileSink.cpp.o.d -o CMakeFiles/AACECore.dir/engine/src/Logger/Sinks/FileSink.cpp.o -c /Users/<user>/.conan/data/aac-module-core/dev/_/_/build/419913d4b251896f5fc5501f6a4fce19cce715ac/engine/src/Logger/Sinks/FileSink.cpp
```

Build error:
```
In file included from /Users/<user>/.conan/data/aac-module-core/dev/_/_/build/419913d4b251896f5fc5501f6a4fce19cce715ac/engine/src/Logger/Sinks/FileSink.cpp:26:0:
/Users/<user>/.conan/data/aac-module-core/dev/_/_/build/419913d4b251896f5fc5501f6a4fce19cce715ac/engine/src/Logger/Sinks/FileSink.cpp: In static member function 'static std::__1::shared_ptr<aace::engine::logger::sink::FileSink> aace::engine::logger::sink::FileSink::create(const string&, const string&, const string&, uint32_t, uint32_t, bool)':
/Users/<user>/.conan/data/aac-module-core/dev/_/_/build/419913d4b251896f5fc5501f6a4fce19cce715ac/engine/src/Logger/Sinks/FileSink.cpp:50:41: error: no matching function for call to 'stat::stat(const value_type*, stat*)'
         ThrowIf(stat(path.c_str(), &info) != 0, "invalidPath");
                                         ^
/Users/<user>/.conan/data/aac-module-core/dev/_/_/build/419913d4b251896f5fc5501f6a4fce19cce715ac/engine/include/AACE/Engine/Core/EngineMacros.h:32:13: note: in definition of macro 'ThrowIf'
         if (arg) {                            \
             ^
In file included from /Users/<user>/.conan/data/aac-module-core/dev/_/_/build/419913d4b251896f5fc5501f6a4fce19cce715ac/engine/src/Logger/Sinks/FileSink.cpp:22:0:
/Users/<user>/qnx700/target/qnx7/usr/include/sys/stat.h:212:8: note: candidate: stat::stat()
 struct stat {
        ^
/Users/<user>/qnx700/target/qnx7/usr/include/sys/stat.h:212:8: note:   candidate expects 0 arguments, 2 provided
/Users/<user>/qnx700/target/qnx7/usr/include/sys/stat.h:212:8: note: candidate: constexpr stat::stat(const stat&)
/Users/<user>/qnx700/target/qnx7/usr/include/sys/stat.h:212:8: note:   candidate expects 1 argument, 2 provided
/Users/<user>/qnx700/target/qnx7/usr/include/sys/stat.h:212:8: note: candidate: constexpr stat::stat(stat&&)
/Users/<user>/qnx700/target/qnx7/usr/include/sys/stat.h:212:8: note:   candidate expects 1 argument, 2 provided
```
user: raghucsbe
issue_9390: state: open
title: [bug] Using --profile:build makes private dependencies disappear from CONAN_PKG:: targets
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04.2
  * Compiler+version: N/A
  * Conan version: 1.39.0
  * Python version: 3.8.10

### Steps to reproduce (Include if Applicable)
Sample project available [here](https://github.com/Paultergeist/conan_cmake_private_deps)
In short:
Add private requirement to the recipe
Build without `--profile:build` - builds fine.
Build with `--profile:build` - CMake can't find corresponding `CONAN_PKG::target`.
Make requirement public - builds fine.

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
% conan create .
...
libTest/1.0: Created package revision d12aa99fb1d5a5830c83aa3f8aaf1757
% conan create . -pr default
...
libTest/1.0: Created package revision d12aa99fb1d5a5830c83aa3f8aaf1757
% conan create . -pr default -pr:b default
...
-- Configuring done
CMake Error at CMakeLists.txt:7 (add_library):
  Target "libTest" links to target "CONAN_PKG::gtest" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?
...
CMake Generate step failed.  Build files cannot be regenerated correctly.
libTest/1.0:
libTest/1.0: ERROR: Package '54899e12a3af6fe447947590ce807456934636ce' build failed
libTest/1.0: WARN: Build folder /home/paul/.conan/data/libTest/1.0/_/_/build/54899e12a3af6fe447947590ce807456934636ce
ERROR: libTest/1.0: Error in build() method, line 27
        cmake.configure(source_folder="src")
        ConanException: Error 1 while executing cd '/home/paul/.conan/data/libTest/1.0/_/_/build/54899e12a3af6fe447947590ce807456934636ce' && cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Release" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="gcc" -DCONAN_COMPILER_VERSION="9" -DCONAN_CXX_FLAGS="-m64" -DCONAN_SHARED_LINKER_FLAGS="-m64" -DCONAN_C_FLAGS="-m64" -DCONAN_LIBCXX="libstdc++" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="/home/paul/.conan/data/libTest/1.0/_/_/package/54899e12a3af6fe447947590ce807456934636ce" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCONAN_CMAKE_POSITION_INDEPENDENT_CODE="ON" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -Wno-dev '/home/paul/.conan/data/libTest/1.0/_/_/build/54899e12a3af6fe447947590ce807456934636ce/src'
% perl -npe "s#private=True#private=False#" -i conanfile.py
% git diff
diff --git a/conanfile.py b/conanfile.py
index c7feff5..7e3b4ae 100644
--- a/conanfile.py
+++ b/conanfile.py
@@ -16,7 +16,7 @@ class LibTestConan(ConanFile):
     exports_sources = "src/*"

     def requirements(self):
-        self.requires("gtest/1.10.0", private=True)
+        self.requires("gtest/1.10.0", private=False)

     def config_options(self):
         if self.settings.os == "Windows":
% conan create . -pr default -pr:b default
...
libTest/1.0: Created package revision a075cba8e91cc194d7ae6ad6effe3882
```
<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: Paultergeist
issue_9388: state: open
title: [bug] conan lock create --base accepts version ranges but subsequent conan lock created doesn't
body: In a Jenkinsfile we have to perform a 'buildall' CI verification ( https://docs.conan.io/en/latest/versioning/lockfiles/ci.html ) which checks that a package promotion won't break any other packages which depend on it, we must specify the 'universe' or 'distribution' within which to check for downstream breaks.

The workflow describes first creating a `--base` profile-independent lockfile, when using that lockfile as input to create a profile-specific lockfile, which is later used to check all packages in the build DAG against the newly built candidate package.

We found a distribution with a version range expression was supported in the conan lock create --base case, but not in subsequent conan lock create --profile cases.

Is that intentional?


### Environment Details (include every applicable attribute)
  * Operating System+version:  Windows 2012 Server
  * Compiler+version: vs2015_14_v140
  * Conan version: Conan version 1.36.0
  * Python version: Python 3.8.10

### Steps to reproduce (Include if Applicable)

```
conan lock create --reference conan-distribution-nx/[>=0.0.3]@PORT/stable --base
conan lock create --reference=conan-distribution-nx/[>=0.0.3]@PORT/stable --profile vs2015_14_v140_Debug
```

### Logs (Executed commands with output) (Include/Attach if Applicable)

We have a `conan-distribution-nx/0.0.3@PORT/stable` meta-package which represented our 'universe'.  We'd like our CI for any other package promotion to be able to work against the latest version of that meta-package universe that becomes available in our buildall Artifactory repo.

So we tried using a version range:  `conan-distribution-nx/[>=0.0.3]@PORT/stable`.  It seemed to work fine in the `conan lock create --base` case, correctly finding the newest version `0.0.4` of the package:

```
[Pipeline] runConanCommand
16:15:40  [conan_rebuild_everything_from_source] $ cmd.exe /C "conan lock create "--reference=conan-distribution-nx/[>=0.0.3]@PORT/stable" "--build=*" --build=!bde-monolith/3.42.0.4@PORT/stable --build=!phql_lib/0.1@PORT/stable --lockfile-out=base.lock --base && exit %%ERRORLEVEL%%"
16:15:42  conan-distribution-nx/0.0.4@PORT/stable: Not found in local cache, looking in remotes...
16:15:42  conan-distribution-nx/0.0.4@PORT/stable: Trying with '03e8a51d-0a17-45c5-98f5-ed1002b77183'...
16:15:42  Downloading conanmanifest.txt
16:15:42  Downloading conanfile.py
16:15:42  conan-distribution-nx/0.0.4@PORT/stable: Downloaded recipe revision 6e8de3dda8e6658b73dbe3f799cf8b3b
```

but subsequently failed when we tried to create the profile-specific lockfile:

```
[Pipeline] runConanCommand
16:16:18  [conan_rebuild_everything_from_source] $ cmd.exe /C "conan lock create "--reference=conan-distribution-nx/[>=0.0.3]@PORT/stable" "--build=*" --build=!bde-monolith/3.42.0.4@PORT/stable --build=!phql_lib/0.1@PORT/stable --lockfile=base.lock --lockfile-out=per_profile_vs2015_14_v140_Debug.lock --profile vs2015_14_v140_Debug && exit %%ERRORLEVEL%%"
16:16:19  ERROR: Version ranges not allowed in 'conan-distribution-nx/[>=0.0.3]@PORT/stable' when using lockfiles
```

user: michaelmaguire
issue_9385: state: open
title: jenkins ci automation for myproject dependency graph
body: lockfile bundle: i created two lockfiles for 2 different applications. after that i bundle them then i got build order. which lockfile i have to pass in single build pipeline for common dependencies in two applications
user: ramisetty1
issue_9383: state: open
title: [feature] Build packages in parallel
body: Would it be possible for conan to build packages in parallel? Similar to `colcon`, which just shows the overall status (Like `building packages 4/18` ) conan should know the correct order from the overall build tree.

WHY? it would speed up the total process, since many small conan packages do not saturate higher core CPUs with building (cmake, packaging etc is all single core anyways)

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: blackliner
issue_9369: state: open
title: [bug] Revisions are not updated
body: Hello,

I am producing revisions for versions (enabled on server and client).
In short - no matter what I tried to do, I dont seem to be able to get new version, only if I delete packages locally and pull new.
We are using SCM for revisions, therefore the revision is GIT sha and not the default hash.

### Environment Details
  * Operating System+version: Ubuntu 20.04
  * Conan version: 1.35.1
  * Python version: 3.9.5

### Steps to reproduce
Create intial revision
pull on client via command:
conan install "pkg/12.0.0@user/stable" --update -r server -o app=app -o variant=debug -o server_build=True
Create new version
Run again conan install "pkg/12.0.0@user/stable" --update -r server -o app=app -o variant=debug -o server_build=True

Output:
Installing package: x/y@z/stable
Requirements
    x/y@z/stable from 'server' - Cache
Packages
    x/y@z/stable:23d871b02677d94407dd30d3bcf29c0dabdfa428 - Cache
Installing (downloading, building) binaries...
Already installed!

**list local revision (returns old one)**
```
root@ca8832285a96:/usr/local# conan search "application/4.5.3@user/stable" --rev
Revisions for 'application/4.5.3@user/stable':
4ea97533e216bc63ac1fd9e4d96f15e6d44342a1 (2021-08-03 16:25:31 UTC)
```

**list revisions on server - notice new one**
```
root@ca8832285a96:/usr/local# conan search "application/4.5.3@user/stable" --rev -r server
Revisions for 'application/4.5.3@user/stable' at remote 'server':
4b1ece5f4134ad22e57262a5ee68acb5a43ce65b (2021-08-03 16:39:58 UTC)
4ea97533e216bc63ac1fd9e4d96f15e6d44342a1 (2021-08-03 16:25:31 UTC)
```

**finally try to update**
```
root@ca8832285a96:/usr/local# conan install "application/4.5.3@user/stable" --update -r server -o app=application -o variant=debug -o server_build=True
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=9
os=Linux
os_build=Linux
[options]
app=application
server_build=True
variant=debug
[build_requires]
[env]

Installing package: application/4.5.3@user/stable
Requirements
    application/4.5.3@user/stable from 'server' - Cache
Packages
    application/4.5.3@user/stable:23d871b02677d94407dd30d3bcf29c0dabdfa428 - Cache

Installing (downloading, building) binaries...
application/4.5.3@user/stable: Already installed!
```

user: GitHubAre
issue_9368: state: open
title: [question] ConanToolchain and sysroot
body: - [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

conan verion: 1.39

I'm trying to use the ["new" `ConanToolchain` feature](https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmaketoolchain.html)
My goal is to cross-compile to `arm`.
How and where does the sysroot get set when cross compiling?
I'm using two profiles. for the `build` profile I use `default` and for the `host` i use:
```
target_host=aarch64-linux-gnu
cc_compiler=gcc
cxx_compiler=g++

[env]
CHOST=$target_host
AR=$target_host-ar
AS=$target_host-as
RANLIB=$target_host-ranlib
CC=$target_host-$cc_compiler
CXX=$target_host-$cxx_compiler
STRIP=$target_host-strip
SYSROOT=<path-to-sysroot>

[settings]
os=Linux
arch=armv8
compiler=gcc
compiler.version=9
compiler.libcxx=libstdc++11
```

just setting the env variable `SYSROOT` did not work, so I tried a workaround in the `conanfile.py`
```
def generate(self):
    tc = CMakeToolchain(self)
    #if os.getenv("SYSROOT"): # does not work, because not set
    tc.variables["CMAKE_SYSROOT"] = os.getenv("SYSROOT")
    tc.variables["CMAKE_FIND_ROOT_PATH"] = os.getenv("SYSROOT")
```

however the variable sysroot is not set when `generate()` is getting called. So my question is, how to set the `sysroot`?
Please also consider that sysroot might be itself a conan package, so I can't rely on some kind of magic relative path.

user: qwertzui11
issue_9366: state: open
title: [question] Build time optimization level
body: Hi All, 

I couldn't find any info online so I'm opening an issue here to hear from the experts.

Does conan / conan recipes have a saying on the optimization level set when building a package (-O1, -O2, etc)?
Is it expected for the build system of each package to set this? Should `build_type` set any of these flags?

Thanks!
user: ericriff
issue_9352: state: open
title: [question] Post-install hook in binary-only packages
body: Hello! I am trying to make a binary-only library package, which runs a code-hardening procedure on the binary after being `conan install`ed. Our hardening procedure is a python script. My expectation is that the artifactory would store non-hardened binaries, and that when a consumer downloads these via `conan install`, conan would call our hardener automatically on the consumer-side to modify the downloaded binary. 

(The hardening needs to be consumer-side, because the user needs to customize various aspects of the hardening to make the library work with their project)

I thought this would be a simple matter of plugging in our code-hardener into one of the conanfile.py methods (like `deploy()`, since it comes at the end of `conan install`), but have not found a way that works. It also shouldn't actually be a hook, as it needs to be part of the package. Any input would be much appreciated :) 
user: regisverdin
issue_9344: state: open
title: [question] ERROR: Invalid setting 'aarch64' is not a valid 'settings.arch' value.
body: good day/night I want to ask if canon support aarch64? i want to install cpr in termux but got error ERROR: Invalid setting 'aarch64' is not a valid 'settings.arch' value.
user: A91K3C1l
issue_9337: state: open
title: [question] Cross Building Mac (CLion) and Raspberry Pico
body: Good morning,

What is the correct profile to use to compile from mac (CLion) to Raspberry PICO? 

I have already read and reread the [examples from cross building](https://docs.conan.io/en/latest/systems_cross_building/cross_building.html#cross-building-examples-profiles) but I'm not able to compile! :( 

Thanks a lot!!,
JBP


PS: 
This is my current profile:
```
toolchain=/usr/local/bin/arm-none-eabi-gcc

[settings]
os_build=Macos
arch_build=x86_64

os=Linux
arch=armv6
compiler=apple-clang

compiler.version=12.0
compiler.libcxx=libc++
build_type=Release

[options]
[build_requires]
[env]
CONAN_CMAKE_FIND_ROOT_PATH=$toolchain
CONAN_CMAKE_SYSROOT=$toolchain

```

And the error that I receive is: 

```
Configuration:
[settings]
arch=armv6
arch_build=x86_64
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=12.0
cppstd=20
os=Linux
os_build=Macos
[options]
[build_requires]
[env]
CONAN_CMAKE_FIND_ROOT_PATH=/usr/local/bin/arm-none-eabi-gcc
CONAN_CMAKE_SYSROOT=/usr/local/bin/arm-none-eabi-gcc
kissfft/131.1.0: WARN: Package binary is corrupted, removing: bf282559a8d301e96e6e78973b1a7d9d4cec6385
conanfile.txt: Installing package
Requirements
    kissfft/131.1.0 from 'conancenter' - Cache
Packages
    kissfft/131.1.0:bf282559a8d301e96e6e78973b1a7d9d4cec6385 - Build

Cross-build from 'Macos:x86_64' to 'Linux:armv6'
Installing (downloading, building) binaries...
kissfft/131.1.0: WARN: Build folder is dirty, removing it: /Users/jure.prah/.conan/data/kissfft/131.1.0/_/_/build/bf282559a8d301e96e6e78973b1a7d9d4cec6385
kissfft/131.1.0: Copying sources to build folder
kissfft/131.1.0: Building your package in /Users/jure.prah/.conan/data/kissfft/131.1.0/_/_/build/bf282559a8d301e96e6e78973b1a7d9d4cec6385
kissfft/131.1.0: Generator cmake created conanbuildinfo.cmake
kissfft/131.1.0: Calling build()
-- The C compiler identification is AppleClang 12.0.5.12050022
-- The CXX compiler identification is AppleClang 12.0.5.12050022
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - broken
CMake Error at /usr/local/Cellar/cmake/3.21.0/share/cmake/Modules/CMakeTestCCompiler.cmake:66 (message):
  The C compiler

    "/Library/Developer/CommandLineTools/usr/bin/cc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /Users/jure.prah/.conan/data/kissfft/131.1.0/_/_/build/bf282559a8d301e96e6e78973b1a7d9d4cec6385/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/usr/bin/make -f Makefile cmTC_e0584/fast && /Library/Developer/CommandLineTools/usr/bin/make  -f CMakeFiles/cmTC_e0584.dir/build.make CMakeFiles/cmTC_e0584.dir/build
    Building C object CMakeFiles/cmTC_e0584.dir/testCCompiler.c.o
    /Library/Developer/CommandLineTools/usr/bin/cc --sysroot=/usr/local/bin/arm-none-eabi-gcc    -MD -MT CMakeFiles/cmTC_e0584.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_e0584.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_e0584.dir/testCCompiler.c.o -c /Users/jure.prah/.conan/data/kissfft/131.1.0/_/_/build/bf282559a8d301e96e6e78973b1a7d9d4cec6385/CMakeFiles/CMakeTmp/testCCompiler.c
    Linking C executable cmTC_e0584
    /usr/local/Cellar/cmake/3.21.0/bin/cmake -E cmake_link_script CMakeFiles/cmTC_e0584.dir/link.txt --verbose=1
    /Library/Developer/CommandLineTools/usr/bin/cc --sysroot=/usr/local/bin/arm-none-eabi-gcc CMakeFiles/cmTC_e0584.dir/testCCompiler.c.o -o cmTC_e0584 
    ld: library not found for -lSystem
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[1]: *** [cmTC_e0584] Error 1
    make: *** [cmTC_e0584/fast] Error 2
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "/Users/jure.prah/.conan/data/kissfft/131.1.0/_/_/build/bf282559a8d301e96e6e78973b1a7d9d4cec6385/CMakeFiles/CMakeOutput.log".
See also "/Users/jure.prah/.conan/data/kissfft/131.1.0/_/_/build/bf282559a8d301e96e6e78973b1a7d9d4cec6385/CMakeFiles/CMakeError.log".
kissfft/131.1.0: 
kissfft/131.1.0: ERROR: Package 'bf282559a8d301e96e6e78973b1a7d9d4cec6385' build failed
kissfft/131.1.0: WARN: Build folder /Users/jure.prah/.conan/data/kissfft/131.1.0/_/_/build/bf282559a8d301e96e6e78973b1a7d9d4cec6385
ERROR: kissfft/131.1.0: Error in build() method, line 64
        cmake = self._configure_cmake()
while calling '_configure_cmake', line 59
        cmake.configure()
        ConanException: Error 1 while executing cd '/Users/jure.prah/.conan/data/kissfft/131.1.0/_/_/build/bf282559a8d301e96e6e78973b1a7d9d4cec6385' && cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Release" -DCMAKE_SYSTEM_NAME="Linux" -DCONAN_CMAKE_FIND_ROOT_PATH="/usr/local/bin/arm-none-eabi-gcc" -DCMAKE_SYSROOT="/usr/local/bin/arm-none-eabi-gcc" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="apple-clang" -DCONAN_COMPILER_VERSION="12.0" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="/Users/jure.prah/.conan/data/kissfft/131.1.0/_/_/package/bf282559a8d301e96e6e78973b1a7d9d4cec6385" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCONAN_CMAKE_POSITION_INDEPENDENT_CODE="ON" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -DKISSFFT_PKGCONFIG="False" -DKISSFFT_STATIC="True" -DKISSFFT_TEST="False" -DKISSFFT_TOOLS="False" -DKISSFFT_DATATYPE="float" -DKISSFFT_OPENMP="False" -DKISSFFT_USE_ALLOCA="False" -Wno-dev '/Users/jure.prah/.conan/data/kissfft/131.1.0/_/_/build/bf282559a8d301e96e6e78973b1a7d9d4cec6385'
```


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: jBernavaPrah
issue_9334: state: open
title: [question] How to show dependency graph with full options?
body: Is it possible to display the dependencies and options of a conanfile.py?

Something like:
``conan info . -o my_pkg:my_option=True -o a_dependency:another_option=True``

with output:
```
...
a_dependency/0.0.1
  ...
  Options: 
    another_option=True
  ...
...
```

Maybe i missed a flag but i was not able to achieve this via `conan info`.

However, with ``conan build`` i was able to retrieve the desired informations.
The generated `conaninfo.txt` when `conan build` is finished basically contains all the sections i need (`requires`, `full_options`) but this file is only available after all dependencies are locally available.

The reason why i want this information beforehand is to consume a conanfile.py but with certain requirements being removed from the dependency tree (but not their transitive requirements). 

For example, imagine this tree with `OpenSSL/1.0.2l` removed but not `zlib/1.2.11` (and options of zlib)
![conan tree](https://docs.conan.io/en/1.13/_images/info_deps_html_graph.png)

Is there an easier way to alter the dependency tree and remove some nodes in the graph before anything is built?
user: ineb
issue_9318: state: open
title: [bug] run conan from cmake lets pip packaging fail for pybind11 python extension
body: Using conan in a cmake configuration lets the pip packaging process `pip install . -v` (from within the python project) fail.

More precisely:
I am including conan in my project via the following `Conan.cmake` file:
```
macro(run_conan)
  # Download automatically
  if(NOT EXISTS "${CMAKE_BINARY_DIR}/conan.cmake")
    message(
      STATUS
        "Downloading conan.cmake from https://github.com/conan-io/cmake-conan")
    file(DOWNLOAD "https://github.com/conan-io/cmake-conan/raw/v0.15/conan.cmake"
         "${CMAKE_BINARY_DIR}/conan.cmake")
  endif()
  
  include(${CMAKE_BINARY_DIR}/conan.cmake)
  
  conan_add_remote(NAME bincrafters URL
                   https://api.bintray.com/conan/bincrafters/public-conan)
  
  conan_cmake_run(
    CONANFILE deps/conanfile.txt
    CONAN_COMMAND ${CONAN_PATH}
    ${CONAN_EXTRA_REQUIRES}
    OPTIONS
    ${CONAN_EXTRA_OPTIONS}
    BASIC_SETUP
    CMAKE_TARGETS # individual targets to link to
    BUILD
    missing)
endmacro()
```

In the main CMakeLists.txt I then call the following lines:
```
#include(Conan.cmake)
#run_conan()
#include(${PROJECT_BINARY_DIR}/conanbuildinfo.cmake)
#include(${CMAKE_BINARY_DIR}/conan_paths.cmake)
```
This lets the pip install command fail (actually softly passes, but useless since the extension module is not present then) with the following error:
```
running install_lib
  warning: install_lib: 'build/lib.linux-x86_64-3.8' does not exist -- no Python modules to install
```

Uncommenting the four conan lines the main CMakelists sees the build pass just fine. This is important to me because I want to use pybind11 via conan and not as a git submodule, since my project also has other dependencies handled by conan. 
I suspect that some environment variable is changed by Conan which `pip` uses to build the wheel, but I don't have enough knowledge of conan's workings to debug this. 

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version: GCC 10
  * Conan version: 1.37.2
  * Python version: 3.8

### Steps to reproduce (Include if Applicable)
Clone my fork from the pybind11 example, which works fine without conan. 
```
git clone --recursive https://github.com/maichmueller/cmake_example.git
```
Then from within a (virtual) environment:
```
cd cmake_example
pip install . -v
```

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
  conanfile.txt: Generator cmake_paths created conan_paths.cmake
  conanfile.txt: Generator cmake created conanbuildinfo.cmake
  conanfile.txt: Generator cmake_find_package created FindGTest.cmake
  conanfile.txt: Generator cmake_find_package created Findpybind11.cmake
  conanfile.txt: Generator txt created conanbuildinfo.txt
  conanfile.txt: Generated conaninfo.txt
  conanfile.txt: Generated graphinfo
  -- Conan: Loading conanbuildinfo.cmake
  -- Conan: Adjusting output directories
  -- Conan: Using cmake targets configuration
  -- Library gtest_main found /home/michael/.conan/data/gtest/1.10.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest_main.a
  -- Library gmock_main found /home/michael/.conan/data/gtest/1.10.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock_main.a
  -- Library gmock found /home/michael/.conan/data/gtest/1.10.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgmock.a
  -- Library gtest found /home/michael/.conan/data/gtest/1.10.0/_/_/package/e019a06362b932ca5d1b082b6c112aa150c88de4/lib/libgtest.a
  -- Conan: Adjusting default RPATHs Conan policies
  -- Conan: Adjusting language standard
  -- Current conanbuildinfo.cmake directory: /tmp/pip-req-build-8t7ffaro/build/temp.linux-x86_64-3.8
  -- Conan: Compiler GCC>=5, checking major version 10
  -- Conan: Checking correct version: 10
  -- pybind11 v2.6.1
  -- Found PythonInterp: /home/michael/anaconda3/envs/testpkg/bin/python (found version "3.8.10")
  -- Found PythonLibs: /home/michael/anaconda3/envs/testpkg/lib/libpython3.8.so
  -- Performing Test HAS_FLTO
  -- Performing Test HAS_FLTO - Success
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /tmp/pip-req-build-8t7ffaro/build/temp.linux-x86_64-3.8
  [1/2] Building CXX object CMakeFiles/cmake_example2.dir/src/main.cpp.o
  [2/2] Linking CXX shared module lib/cmake_example2.cpython-38-x86_64-linux-gnu.so
  installing to build/bdist.linux-x86_64/wheel
  running install
  running install_lib


> warning: install_lib: 'build/lib.linux-x86_64-3.8' does not exist -- no Python modules to install


  running install_egg_info
  running egg_info
  writing cmake_example2.egg-info/PKG-INFO
  writing dependency_links to cmake_example2.egg-info/dependency_links.txt
  writing requirements to cmake_example2.egg-info/requires.txt
  writing top-level names to cmake_example2.egg-info/top_level.txt
  reading manifest file 'cmake_example2.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  adding license file 'LICENSE'
  writing manifest file 'cmake_example2.egg-info/SOURCES.txt'
  Copying cmake_example2.egg-info to build/bdist.linux-x86_64/wheel/cmake_example2-0.0.1-py3.8.egg-info
  running install_scripts
  adding license file "LICENSE" (matched pattern "LICEN[CS]E*")
  creating build/bdist.linux-x86_64/wheel/cmake_example2-0.0.1.dist-info/WHEEL
  creating '/tmp/pip-wheel-sy49n8ig/tmp1r7ftp9y/cmake_example2-0.0.1-cp38-cp38-linux_x86_64.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
  adding 'cmake_example2-0.0.1.dist-info/LICENSE'
  adding 'cmake_example2-0.0.1.dist-info/METADATA'
  adding 'cmake_example2-0.0.1.dist-info/WHEEL'
  adding 'cmake_example2-0.0.1.dist-info/top_level.txt'
  adding 'cmake_example2-0.0.1.dist-info/RECORD'
  removing build/bdist.linux-x86_64/wheel
  Building wheel for cmake-example2 (PEP 517) ... done
  Created wheel for cmake-example2: filename=cmake_example2-0.0.1-cp38-cp38-linux_x86_64.whl size=2467 sha256=98fa4eb130daabccbce9c1e6384202b91f437c6dae14983c0918c6334491dcd7
  Stored in directory: /tmp/pip-ephem-wheel-cache-xv_9dkwg/wheels/64/c2/a7/38270846cb5435f7041e0e38ad78185b72c8a70ba4c1b79781
Successfully built cmake-example2
Installing collected packages: cmake-example2
Successfully installed cmake-example2-0.0.1
```


To see that this example would work fine without conan:
```
git clone --recursive https://github.com/pybind/cmake_example.git
cd cmake_example
pip install . -v
user: maichmueller
issue_9306: state: open
title: [feature] Bump MinGw
body: <!-- What is your suggestion? Please be as specific as possible! -->
Relates to https://github.com/conan-io/conan-center-index/issues/6432#issuecomment-883500615

Please, update the MinGw version in conan

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: AndreyMlashkin
issue_9305: state: open
title: [question] Is there a "wildcard any" syntax for versions in a Conan workspace definition file?
body: We are trying out [Conan Workspaces](https://docs.conan.io/en/latest/developing_packages/workspaces.html).

We have a well established list of related repositories we want to be editable toghether in the workspace, so we list their recipe references in the `conanws.yml` file.

Is there a way to use a wildcard for the `version` component of the recipe reference?

I.e, having something like:

```
editables:
    myrepo/[*]@adnn/develop:
```

instead of

```
editables:
    myrepo/ab78c1cc78@adnn/develop:
```

Thank you for reading!


user: Adnn
issue_9303: state: open
title: [feature] exclude some deps from conan dependency graph 
body: Conan dependency graph is a very useful feature but it become very difficult to use when having too many dependencies.  

This is how our current dependency graph looks like, it is almost unreadable and we are adding more dependencies. 

<img width="721" alt="Screen Shot 2021-07-21 at 2 30 38 PM" src="https://user-images.githubusercontent.com/7117696/126497056-6a7695f8-c58b-44c7-b076-1e7ca5c58d59.png">

It would be very handy to add the ability to exclude some dependencies from this graph. For example excluding third party deps that rarely get changed.

user: boussaffawalid
labels: component: ux: No changes to core business logic
issue_9287: state: open
title: [bug] Makefile won't build successfully
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Compiler+version: g++ 9.3.0
  * Conan version: 1.38.0
  * Python version: 3.8.10

### Steps to reproduce (Include if Applicable)
Follow the official Doc to build with Makefile generator.
https://docs.conan.io/en/latest/integrations/build_system/make.html

**conanfile.txt**
```
[requires]
poco/1.9.4

[generators]
make
```

**Makefile**
```
 #----------------------------------------
 #     Prepare flags from make generator
 #----------------------------------------

 include conanbuildinfo.mak
 $(call CONAN_BASIC_SETUP)

 #----------------------------------------
 #     Make variables for a sample App
 #----------------------------------------

 SRCS          = main.cpp
 OBJS          = main.o
 EXE_FILENAME  = main

 #----------------------------------------
 #     Make Rules
 #----------------------------------------

 .PHONY                  :   exe
 exe                     :   $(EXE_FILENAME)

 $(EXE_FILENAME)         :   $(OBJS)
	g++ $(OBJS) $(CXXFLAGS) $(LDFLAGS) $(LDLIBS) -o $(EXE_FILENAME)

 %.o                     :   $(SRCS)
	g++ -c $(CPPFLAGS) $(CXXFLAGS) $< -o $@

```

Code
```
#include "Poco/MD5Engine.h"
#include "Poco/DigestStream.h"

#include <iostream>


int main(int argc, char** argv)
{
    Poco::MD5Engine md5;
    Poco::DigestOutputStream ds(md5);
    ds << "abcdefghijklmnopqrstuvwxyz";
    ds.close();
    std::cout << Poco::DigestEngine::digestToHex(md5.digest()) << std::endl;
    return 0;
}
```

**Steps**
1. conan install .
2. make exe

### Logs (Executed commands with output) (Include/Attach if Applicable)

![image](https://user-images.githubusercontent.com/6712103/126128277-47fa1748-657d-476d-9e31-7d578e71fb19.png)


<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: ibmboy19
issue_9279: state: open
title: [feature] Add ability to have multiple named configurations
body: It's possible that you might work on multiple projects which have:
* Different settings
* Different configurations
* Different Remote list
* etc.

It would be cool if you could create isolated configurations with settings.yml, conan.conf, etc. Each config would have it's own cache as well. Then you would have an optional argument for commands such as:

```
conan install . --config-name myProject1
```

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: rconde01
issue_9264: state: open
title: [question] How to get recipe name? How to provide an option value only for created recipe?
body: We have a CI process that validate all pushes via a command of the form

          conan create  \
          -o ${{ recipe_name }}:build_tests=True -s compiler.cppstd=${{ matrix.cppstd }}  \
          conan/

We have a problem making it generic though, because of the options that are present on the recipe, but not on the test packages.
In this case, this is the `build_tests` option.

If we do not scope the option with the recipe name, the `conan create` call fails complaining that the option is not present on the test package. We are not aware of a way to solve that without prefixing the option with the actual `name` from the `conanfile.py` of the root package (Is there an alternative?)

At the same time, we cannot find a "compact" way to retrive the `name` field from the recipe, in order to make the prefix solution generic (at the moment, we have to touch every specific workflow file to change this value).
(As read elsewhere, the recipe name might be derived from other places, but that would be just a convention, and since there is an explicit `name` field we might as well use it).

Thank you for reading!
user: Adnn
issue_9255: state: open
title: [question] How to control which available compiler will be used when generating a profile by detection?
body: We are using Conan to drive our CI processes.

The CI cloud provider offers different _runners_ (available worker machines). On one of them, both **gcc** and **clang** are available. The runners are ephemeral (virtual machines starting from a clean default state on each run).

We run the build process via:

    conan create conan-path/ ${package}/${version}@

This triggers the automatic detection and creation of the default profile.
This automatically picks-up the `gcc` compiler.

* How could we detect another profile for `clang`?

(It would be impractical to create the clang profile manually, because we have no control over when the provider does compilers' version updates).


user: Adnn
issue_9254: state: open
title: [question] Override warning when using unrelated mode
body: Background - We have a bunch of packages which are pulled into a root SDK package.  Some of these packages build shared objects exposing C interfaces and some are static libs.  Some of these packages rely on each other.

Our conan.conf contains - 
default_package_id_mode = full_package_mode
default_python_requires_id_mode = full_version_mode

After updating a static lib package version and updating one of the packages to use the new version, we realised that some dependencies could not be resolved.  We realise it's because the version is being overriden to the root package version and  full package mode is being used and the package IDs are including the requires too.

So it got us thinking....If we bump the major for breaking changes and use major mode  where appropriate we can be more flexible.  For final SDKs we would usually be looking at making versions consistent, but by changing the modes it allows devs to reuse existing released binaries where compatible.   Also, we don't care which version of a certain foundational lib is used with our SO/DLLs which expose the C interface (some we do, some we don't).  The lib is fully encapsulated and no data is passed that directly maps to anything in the lib.   Adding the following to our recipes helps us - 

    def package_id(self):
        self.info.requires.major_mode()
        self.info.requires["foundation"].unrelated_mode()


While the deps are resolved OK, we get the following warning - 

"WARN: configuration/2.1.0.2@xxx/stable: requirement foundation/3.0.0.2@xxx/stable overridden by dm/3.0.0.2@xxx/stable to foundation/4.0.0.1@xxx/stable"

I can see why we get the warning, but wondering if it should be output when using unrelated mode?  Is it to warn of the scenario where maybe you use build missing and could end up with a shared object built with one version of a static lib baked in and another version in another build because the dep was overridden?

It means for this specific lib, when we update it we have to update everywhere (which isn't necessary) to avoid the warning.  


user: sd185233
issue_9249: state: open
title: [bug] tools.get() hangs after first download 2GB+ archive
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Linux, RHEL7
  * Compiler+version: Any/NA
  * Conan version: 1.34.0
  * Python version: python: 2.7.16, python3: 3.7.3

### Steps to reproduce (Include if Applicable)
0. Follow [the documentation for pre-compiled binaries](https://docs.conan.io/en/latest/creating_packages/existing_binaries.html) to download the package/tarball from the package_info() step. Use package_info() step because build() step will not be called when you export-pkg.
1. Have a dependency which has a large tarball to be downloaded and unpacked by tools.get() in this fashion. Mine is 2348365.35k according to the tools.get() dialog/console output.
2. Run `conan install $DIR --build=missing` to build all your project's dependencies. Everything downloads, unpacks, and builds just find.
3. Run `conan create $DIR`.
4. Now the mysterious parts. conan create will display all your requirements and packages as in Cache, ie:
   Requirements
    BoostSIMD/3.1.0@me/testing from 'conan-prod-gsd' - Cache
    CUDA/10.0.130@me/testing from 'conan-prod-gsd' - Cache
Packages
    BoostSIMD/3.1.0@me/testing:4db1be536558d833e52e862fd84d64d75c2b3656 - Cache
    CUDA/10.0.130@me/testing:4db1be536558d833e52e862fd84d64d75c2b3656 - Cache
5. conan create will then proceed to tell you the dependencies are already installed, but it will still download the tarballs once again because package_info() is going to be called.
6. tools.get() will hang on the larger tarball. This will happen once that tarball has already been downloaded always.

user: rthomaskelly
issue_9247: state: open
title: [question] handling pre-compiled binaries in an export-pkg + download in build() method manner
body: <!-- What is your question? Please be as specific as possible! -->

I read [the docpage about handling pre-compiled binaries](https://docs.conan.io/en/latest/creating_packages/existing_binaries.html) a couple times. The page seems to recommend two things:
0. Use export-pkg as opposed to any conan create/build/install/etc...
1. Download the binary from a static link in the build() method of your conanfile.py. If it is a tarball use tools.get() to unpack it.

I gave this a try but found that the build() method is not called in my pre-compiled binary conan recipe. I found on a different doc page that of the 13 conanfile methods, 5-11 (I think) are not called when using export-pkg. I think build() was 5 on that list so it then makes sense that it was not called.

So how do I rightly package pre-compiled binaries if the steps of export-pkg + download in build() are incompatible?

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: rthomaskelly
issue_9243: state: open
title: Make tools.collect_libs() case insensitive on windows
body: Hi,

I've been using conan a bit now, and we're moving to hosting binaries on artifactory servers instead of checking in binaries in source control. 

In order to do this (as there are a decent number of libraries we use), I scripted some of the upload process. I noticed a build problem with a certain library and didn't understand at first why I was receiving linker errors. Looking into it, it seems that some of the library files in the /lib directory had .LIB as extension, and this is the reason they were not picked up and added as dependencies.

As NTFS is case insensitive I think this collecting of libs should also be case insensitive.

Kind regards.
user: Belpaire
issue_9241: state: open
title: [question][workspaces] How to generate and provide CMake toolchain when developing within Conan workspaces?
body: We are trying out Conan experimental features, in order to enhance the development experience.

[Workspaces](https://docs.conan.io/en/latest/developing_packages/workspaces.html) and [Toolchains](https://docs.conan.io/en/latest/creating_packages/toolchains.html) seem very promising.
Yet we cannot figure out how to use both in conjunction.
In particular, we do not know how to properly generate the CMake toolchain to be provided on CMake configuration step.

As an example, all our recipes now define two generators:

        generators = "cmake_paths", "CMakeToolchain"

* `cmake_paths` is used to satisfy the requirements (dependencies)
* `CMakeToolchain` is used to describe the build parameters (following the ideas in #5691)

When using such recipes within `workspaces`, there is still one toolchain file `conan_toolchain.cmake` generated in each package build folder. Yet now there is a single CMake configuration step for all packages, executed at the workspace build folder level. For e.g. taken from the doc:

     cmake .. -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release

Because of that, it seems we would need a single toolchain file to be fed in the command above. But we do not know if that is possible (or even correct, see second section). Even with a workspace yaml file containing:

```
workspace_generator:
  - cmake
  - CMakeToolchain
```

There is still only `conanworkspace.cmake` file generated in the workspace build folder.

---

This raise an additional question regarding how to approach the problem in general. From the [doc](https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmaketoolchain.html#cmaketoolchain):

> The CMakeToolchain is the toolchain generator for CMake. It will generate toolchain files that can be used in the command line invocation of CMake with the -DCMAKE_TOOLCHAIN_FILE=conantoolchain.cmake. **This generator translates the current package configuration, settings, and options, into CMake toolchain syntax**.

It seems the generated toolchain file should take care of defining the required CMake variable depending on the recipe's options (presumably via ` CMakeToolchain().variables` python dictionary).

Yet, this options are per-recipe, which would imply a different toolchain file for each package in the `Workspace`? 
If so, how could we successfully use a `Workspace` -- which wraps the different packages under a common CMake toplevel project -- with the toolchain base approach? (Is it possible to feed different toolchain files to the different sub-projects?)
user: Adnn
issue_9229: state: open
title: Consuming an external package that contains an cmake config-file package 
body: > I also have a case where the conan package (hosted in a private artifactory) provides its own config.cmake files. However in that case the package is not a build requirement but a regular requirement of the code being built. Are you saying that the only way to get this "included" is to declare it as a build requirement?

Hi @bldrvnlw 

Using the internal package xxxx-config.cmake is still possible, that is only restricted in ConanCenter, because you should be aware of 2 main CMake limitations regarding xxxx-config.cmake:

- Internal package xxx-config.cmake will not work in multi-config environments, because CMake cannot locate or cannot do generator expressions over ``find_package()``. So if you want to switch Debug/Release configuration from Visual Studio or XCode IDEs, that will not work
- Internal package xxx-config.cmake often have problems with transitivity, and they might find a transitive dependency in the system, instead of a Conan package.

If despite these limitations you still want to use the internal xxx-config.cmake, you can do it, by avoiding the ``CMakeDeps`` generator altogether, as you don't want Conan to generate the xxxx-config.cmake files for the dependencies. The ``CMakeToolchain`` might still be useful and it is intended to allow locating the xxx-config.cmake inside the packages too.

This discussion is mostly about the extra cmake modules that the ``CMakeDeps`` generator will be injecting, which is a different issue than wanting to use your internal xxx-config.cmake modules. 

Please let me know if this helps.


@SeanSnyders yes, we know it is still not very clear, we are still heavily working and changing things in all this area, that is the reason the docs are still scarce and confusing. We are trying to stabilize and provide full examples (like https://github.com/conan-io/examples/pull/90)

_Originally posted by @memsharded in https://github.com/conan-io/conan/issues/9112#issuecomment-869649357_
user: bldrvnlw
issue_9222: state: open
title: [QUESTION]Problems creating a package with with .sa library extension
body: I'm trying to build a package using a private library with .sa extension.

I add it like this:
`self.cpp_info.libs = ['asn-decoder-lib','libosstoed.sa']`

But when I run the conan test for the package it says
`/usr/bin/ld: cannot find -llibosstoed.sa
`
libosstoed.sa is a thirdparty library that is the same as the static one (libosstoed.a) but is built with object code suitable for use in a shared library.)

The link.txt file generated:
`/usr/bin/c++ -O3 -DNDEBUG -rdynamic CMakeFiles/example.dir/example.cpp.o -o bin/example-SOVERSION -ldl /root/.conan/data/asn-decoder-lib/0.1.0/exfo/stable/package/97e1027d2f33d6f3782268dfae4c519b4f10e2e8/lib/libasn-decoder-lib.a -llibosstoed.sa`
user: manape3
issue_9214: state: open
title: [feature] conan editable could work without explicit package name and version on reference argument
body: Currently, `conan editable add` command requires version and package name to be provided on reference argument. If it is not provided the following message is promted:

`ERROR: Name and version from reference (gsl/test) and target conanfile.py (pkg_name/1.0.2) must match`

My proposal is to modify this command to mimic `conan create` command, on which, if package name and version is not provided, conanpacakge.py info is used.

I assume this is straightforward as it is done already on `conan create` and the conanfile.py is also available on this command, but I would inderstand if current implementation of `conan editable add` is done on purpose.

This would make my workflow much easier as currently I generate version dynamically on conanfile.py based on git tag, with dirty and hash flags which makes inconvenient to have to write version on the reference.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: guiserle
issue_9193: state: open
title: [question] How to read host and build profile in the Conan recipe
body: Hi,

is there a way to read the configured profile (both host and build) in a Conan recipe? I didn't find a property or method to get that information.

Many thanks for your help.
gpxricky

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: gpxricky
issue_9177: state: open
title: [feature] Environment variables for self-consumption
body: Hi @memsharded, I'd like to follow up on #8534

I assumed that when installing package with `develop = True` (i.e. `conan install .` in a directory with the recipe) means that I want to run it as well.

In my case it would be a simplification if `<build_folder>/bin` was added to `PATH` so I can run tests with same command as if I installed my package by reference (or other variables I set in `package_info`).

However I couldn't find way to add more variables to produced neither build_env nor run_env from inside recipe. `package_info` is not called in this case and `VirtualEnv` class doesn't provide means to add custom variables before calling its `generate()` method.

Something similar to layouts duality: local vs in the cache.

I wonder if this use-case makes sense or your (a Conan team) thoughts about it.
user: ytimenkov
issue_9135: state: open
title: [bug] While using cmake_find_package* generators <PKG-NAME>_LIBS and <PKG-NAME>_LIBRARIES differ.
body: When I use `cmake_find_package` generator I expect to have the `<PKG-NAME>_LIBS` and `<PKG-NAME>_LIBRARIES` variables set to the same value after `find_package(<PKG-NAME>)`. This is also written in the [documentation](https://docs.conan.io/en/latest/reference/generators/cmake_find_package.html#variables-in-find-pkg-name-cmake)

But it doesn't have the same value, because in the generated `Find<PKG-NAME>.cmake` the contents of the `<PKG-NAME>_LIBRARIES` gets copied to `<PKG-NAME>_LIBS` here:
https://github.com/conan-io/conan/blob/80f344c101f892a18104fa12fedc2feeb993fdd1/conans/client/generators/cmake_find_package_common.py#L57

but then it gets altered later here:
https://github.com/conan-io/conan/blob/80f344c101f892a18104fa12fedc2feeb993fdd1/conans/client/generators/cmake_find_package_common.py#L59-L71


### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 21.04
  * Compiler+version: gcc 10.3
  * Conan version: 1.37.2
  * Python version: 3.9

Or did I miss something?
user: takacsd
issue_9134: state: open
title: [feature] show uploaded files size in `conan upload`
body: <!-- What is your suggestion? Please be as specific as possible! -->
It would be very convenient to provide the size of files which will be upload to specific remote via `conan upload ...` in diagnostic purposes, e.g. sometimes artifacts could be very large and CI could refuse its uploading, see e.g. [this StackOverflow question](https://stackoverflow.com/questions/64329087/gitlab-self-hosted-error-uploading-artifacts-as-archive-to-coordinator-to) as example of related CI error. With this change CI administrators could adjust the file limit at CI without trial and error changing of CI configs.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: leha-bot
labels: component: ux: No changes to core business logic
issue_9133: state: open
title: conan install .. and conan create ...   commands throws "Permission Denied" error against Artifactory Repo
body: Environment
=========
- Artifactory Server Version: Enterprise Plus 7.19.4 rev 71904900
- Conan Version :  1.37.2
- Python: 3.6.8  and 2.7.5 
- Client Platform: Docker Container based on RedHat 7.9 , GCC Version: 4.8

Problem
======
"conan install -s build_type=Release /work/src/conanfile_codegen.py"  throws  the following Error:

ERROR: Permission denied for user: ****. [Remote: artifactory]

This is happening after successful run of following "conan remote .." and "conan user .. " command as follows:

conan remote add artifactory https://abc.com/artifactory/api/conan/transmission-conan-release
conan user -p **** -r artifactory ****
Changed user of remote 'artifactory' from 'None' (anonymous) to ****
conan remote add artifactory_thirdparties https://abc.com/artifactory/api/conan/oss-conan-release
conan user -p **** -r artifactory_thirdparties ****
Changed user of remote 'artifactory_thirdparties' from 'None' (anonymous) to ****

While running the above directly from a Laptop or Docker Container is working fine. But when we run the same from a Jenkins CI Pipeline throws out the error. Same Docker image is used for testing locally as well as for CI Build.

However, if we install individual packages using the following commands, instead of specifying the conanfile, it works:

conan install Avro/1.9.1@gridiq/stable -s build_type=Release                              (from artifactory_thirdparties)
conan install XercesC/3.2.2@gridiq/stable -s build_type=Release                         (from artifactory_thirdparties)
conan install Boost/1.70.0@gridiq/stable -s build_type=Release                          (from artifactory_thirdparties)
conan install CimCpp/4.0.139@gridiq/testing -s build_type=Release                   (from artifactory)
conan install DbdefModel/3.3.348@gridiq/stable -s build_type=Release             (from artifactory)

Even if we work-around the problem by individually installing packages one by one instead of using conanfile, still "conan create ... " command fails with the same kind of error:

conan create --test-folder=None -s build_type=Release  /work/src/conanfile_codegen.py  gridiq/stable

ERROR: Permission denied for user: ****. [Remote: artifactory]

I have taken the Debug Trace Log for both conan install ..    and  conan create commands and is attached here.

Let me know if any further information required.

Thanks & Regards
Darby Abraham
[conan_install_create_trace.log](https://github.com/conan-io/conan/files/6690019/conan_install_create_trace.log)

user: darbysobha
issue_9125: state: open
title: How to add an alias so that the library can be used outside the build
body: My library is setup in a very similar manner to this:
[modern cmake sample](https://github.com/pabloariasal/modern-cmake-sample). I use an alias target in the top level CMakeLists file:

`add_library(JSONUtils::jsonutils ALIAS jsonutils)`

Then in the test folder CMakeLists I use the target:

`target_link_libraries(json_utils_test gtest_main JSONUtils::jsonutils)`

My question is given the above linked project as an example how can we apply modern cmake practices using conan. I am specifically interested in how to setup the tests folder CMakeLists to access the library through an alias. 
 

user: shavesha
issue_9120: state: open
title: [question] conan config install + version of installed git/svn repository
body: Hi,

as Conan scrubs .git after installing a given config repository it is practically impossible to decide whether a configuration repository needs to be "reinstalled" (newer version exists in the remote repo) or not before any given Conan command is executed.
What is the expected behaviour here? How should this situation be handled?
Thanks,
user: harsszegi
issue_9111: state: open
title: [question] package_info and automatic prefixing of library name
body: Adding
`self.cpp_info.libs = [ "foo" ]`
to package_info would result the client library expecting libfoo on *nix systems and foo.lib on Windows. Is there a way to avoid this behavior for projects, where the library is named libfoo.[extension] across all the OSs?


- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: w3sip
issue_9097: state: open
title: [question] channel semantics in conan 2.0
body: This is a follow up issue on this discussions within [this PR](https://github.com/conan-io/tribe/pull/25), especially this [comment](https://github.com/conan-io/tribe/pull/25#issuecomment-856136690) of @memsharded:

> For Conan 2.0, we probably shouldn't use anymore the channels as a versioning mechanism, and let it be just a general label, same as the "user" part. Channels shouldn't be used for flow control or dependency resolution logic, and using different servers and following the immutability principle of packages should be the approach to follow. 

This is our context: We are using conan in a research institute to develop and deploy c/c++ packages for our quite complex systems. We do not have a real production or "ops" environment nor do we have products we want to sell. So basically, we use conan in a pure development environment and sometimes we need to run cutting edge versions of a software during a demonstration.

We started to use conan around ~ 1.16 / 1.18 with this version of the [FAQ](https://docs.conan.io/en/1.18/faq/using.html#is-there-any-recommendation-regarding-which-user-or-channel-to-use-in-a-reference):

> From the perspective of a library developer, channels could be used to create different scopes of your library. For example, use rc channel for release candidates, maybe experimental for those kind of features, or even qa/testing before the library is checked by QA department or testers.

So we designed a promotion workflow based on gtiflow: any branch gets _snapshot_ assigned as channel and is uploaded to a snapshot repo. Release branches become _unstable_, tags become stable. Latter are uploaded to a release repo. This semantics in the channel helps our devs to judge the maturity of the package by inspecting just the reference. Devs should use stable releases for the demos, but packages of any maturity are available to them and to demos (i.e. we have a virtual remote covering snapshot and release repo). Having a _stable_ release channel in a pre-release repo (as proposed [here](https://github.com/conan-io/tribe/pull/25#issuecomment-856127743)) hides this information behind a conan info call which can be time consuming when using >50 conan packages on our systems.

Just recently, this FAQ [changed](https://github.com/conan-io/docs/commit/9057c6cf40fa626ff76d2cb0fb52b0d3de8e62fc), but the commit doesn't provide any real clue, why. We are getting afraid that our workflow might get deprecated / stop working at some time in the future. Therefore, I wanted to start a discussion about the channel semantics in conan 2.0:

- what is its intented use in future? What would be an example of _just a general label, same as the "user" part_
- will our "channel based promotion" be something supported in conan 2.0? What could be some potentional drawbacks using it in conan 2.0?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Da-LiFe
issue_9082: state: open
title: [feature] Provide multiple build() methods
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Assuming one uses a cross compilation toolchain from within Conan.
Assuming further you need to build two different types of binaries (say native and cross) during that build.
Example: Protoc for executing it on amd64 and Protobuf entirely in aarch64 for linking against another aarch64 executable.
When the build generator (e.g. CMake or a special custom one) uses a cache, this might lead to trouble.

Proposal:
It would be nice to have something like a `build_native()` one can optionally override, in parallel to the already existing `build()`.
This `build_native()` would need a dedicated `self.build_native_folder`, so that you have each build type strictly separated.
In the packaging phase one could then either copy / take from the `self.build_folder` or from the `self.build_native_folder`.
One could also implement N different `build()` methods in kind of an abstract way, in case you need more than two independent builds.

Known and working solutions for now:
- In `build()` first build native binary, then use `tools` to delete the cache, copy binary in target directory, then build cross binary (Maybe existing CMake wrapper already offers deleting cache?)
- In `build()` create directories using `tools` per each required build, run the cross, native build in those dedicated directories (but they are located in `self.build_folder`).

user: tiolan
issue_9078: state: open
title: [question] Determine remote recipe version when building locally
body:    As part of our workflow we are creating RPM during the conan packaging step which use the Jenkins build number as the release label. When the build happens in the local cache the release numbers can get out of sync. Is there an attribute or method that can be used in the conanfile.py to determine the current version of the remote recipe? Thanks.
user: marknva1
issue_9074: state: open
title: [bug] conan info does not respect --remote if the recipe/binary has already been cached from a different remote
body: It seems that subsequent calls to `conan info` using a `--remote` argument will not respect the given `--remote` if the package/recipe/binary has already been cached from a different remote. 

This seems at odds with the help text for `--remote`
```
-r REMOTE, --remote REMOTE                               
                      Look in the specified remote server
```


### Environment Details (include every applicable attribute)
  * Operating System+version: SLES12SP3
  * Compiler+version: GCC 4.8
  * Conan version: 1.36.0
  * Python version: 3.8.1

### Steps to reproduce (Include if Applicable)

1. Run `conan info {package} --remote {remote_A}` using a `remote` that you know contains the recipe/binary
2. Run `conan info {package} --remote {remote_B}` using a `remote` that you know **does not** contain the recipe/binary. Conan info will still serve you information about the package that was cached from `remote_A`.

user: wKavey
issue_9052: state: open
title: [feature] Setup virtual environment without the need to invoke scripts and file creation
body: I want to start a tool via conan, this required for me to do following atm:
```
conan install mytool/latest@company/stable -u -g virtualenv -g virtualrunenv
source activate.sh && source activate_run.sh
mytool
```
I would like to avoid the step: `source activate.sh && source activate_run.sh`
Which additionally required an writable, directory because files are written do disk.
Which should be avoided too.

I would like to have something like that:
```
conan install mytool/latest@company/stable -u -g run_env
mytool
```

or shorter with a new cmd:
```
conan setup-env mytool/latest@company/stable 
mytool
```

or:
```
conan start-app mytool/latest@company/stable 
```




- [ x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: derived-coder
issue_9041: state: open
title: CONAN_CMAKE_CXX_STANDARD not set when building a workspace
body: I have a workspace with a few connan+CMake projects. In my `conanfile.py` I can see that during configuration `settings.compiler.cppstd` has the correct value from my profile. This value does not propagate to `CONAN_CMAKE_CXX_STANDARD` in CMake. Consequently `CMAKE_CXX_STANDARD` is not set.

### Environment Details
  * Operating System: Windows 10
  * Compiler: MSVC 19.29.30037
  * Conan version: 1.36
  * Python version: 3.8.6

### Steps to reproduce
I have something along the lines of
```
conan workspace install "$SRC_DIR/conan-workspace.yml --profile "$SRC_DIR/conan-msvc-profile"
cmake "$SRC_DIR"
```

user: sogartar
issue_9033: state: open
title: [feature] CMake generator: create targets for package executables
body: Currently there doesn't seem to be a good way to access executable targets of a package dependency in the CMake generator. For example, the [glslang](https://conan.io/center/glslang) package provides a library but also a compiler that can be used by a dependent package.

Currently conan generates targets for each package library target (e.g.` CONAN_LIB::<package_name>-<target-name>`) but not for executables. This means the only way to get the actual executable is through CMake's `find_program` feature. This seems to defeat the point of using a package manager for dependencies in the first place.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: n-morales
issue_9029: state: open
title: [question] Is activate_run recursive ?
body: (I'm working on Windows)

I'm building an application that uses a shared library that I'm developing at the same time. That shared library depends on GLEW, which it obtains via Conan (`glew/2.2.0`).

I've marked the shared library as editable.

I'm running `activate_run` in the build directory of my application (which uses the `cmake_multi` and `virtualrunenv` generators) to ensure that the shared library will be found by the application.

The problem is that `activate_run` puts my shared library into the path, but not its dependency GLEW.

Am I missing something ?
user: JPGygax68
issue_9023: state: open
title: Error installing boost 1.74.0 on Raspberry Pi 4
body: I am trying to install boost but i get this error

```
ERROR: boost/1.74.0: Cannot load recipe.
Error loading conanfile at '/home/pi/.conan/data/boost/1.74.0/_/_/export/conanfile.py': Unable to load conanfile in /home/pi/.conan/data/boost/1.74.0/_/_/export/conanfile.py
  File "/home/pi/.conan/data/boost/1.74.0/_/_/export/conanfile.py", line 510
    tools.get(**self.conan_data["sources"][self.version],destination=self._source_subfolder, strip_root=True)
                                                        ^
SyntaxError: invalid syntax
```

### This my conanfile.py
```
from conans import ConanFile, CMake

class ConanPackage(ConanFile):
    name = 'network-monitor'
    version = "0.1.0"

    generators = 'cmake_find_package'

    requires = [
        ('boost/1.74.0')
    ]

    default_options = (
        'boost:shared=False'
    )
```
user: MHeshamG
issue_9018: state: open
title: [question] How to improve the following workflow
body: Hi,

My project lets call it "game" needs  a project lets call it "shared".
I made a conan package for "shared" and can use it in "game".
"shared" is useless for people who are not using "game".
"shared" depends on some other packages I created which are kinda usefull.


If some one wants to build "game"
1. he has to  check out "shared" and its dependencies receipts.
2. run conan export and create for all depencencies of "shared" and "shared" in the correct order.
3. build game by running conan install  and cmake

How to improve this workflow?

I think its possible to do something like this to build "game"
1. add a repo to conan with add remotes
2. build "game" by running conan install  and cmake

I am not interested in hosting the packages by myself. I think its some how possible to add the receipts to git and build it from sources using conan install in "game".






user: werto87
issue_9006: state: open
title: [feature] Add --build parameter to build all packages not in local cache
body: On our Linux CI/CD server I want to prevent that we download binary packages that are built against a newer libc version.
The easiest solution for that seems to build all packages that are not in the local cache from source. However as fas as I can find the `--build` option for conan install, conan create etc doesn't support this build policy yet.

I think it would be useful to allow `conan install .... --build=not_in_cache`. The `not_in_cache` parameter is of course only an example and can be changed as fit.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: wdobbe
issue_9001: state: open
title: [feature] Add rpath information to conanbuildinfo.xcconfig
body: ## 💬 Description 
When using Conan together with the Xcode generator the resulting `conanbuildinfo.xcconfig` contains build settings for 

* HEADER_SEARCH_PATHS
* LIBRARY_SEARCH_PATHS
* OTHER_LDFLAGS
* GCC_PREPROCESSOR_DEFINITIONS
* OTHER_CFLAGS
* OTHER_CPLUSPLUSFLAGS
* FRAMEWORK_SEARCH_PATHS

Which is nice!

But when using shared libraries this does not seem to be enough in some cases. Shared libraries often have a relative `rpath` which looks like this `@rpath/libcpr.dylib (compatibility version 0.0.0, current version 0.0.0)` in this case one could not just consume the `xcconfig` and it will work. If the lib in question is not installed in the system you would get something like 

```shell
dyld: Library not loaded: @rpath/libcpr.dylib
  Referenced from: /Users/thomas/Library/Developer/Xcode/DerivedData/proj-elsucpilyuumllaivhcqwpcjftdv/Build/Products/Debug/proj
  Reason: image not found
```

In order to actually load the shared lib one needs to adjust the `Runpath Search Paths` setting in Xcode and add the path to the lib in the Conan cache directory. Something along the lines of 
```
/Users/thomas/.conan/data/cpr/1.4.0/stable/package/9a5c1a1574011969dc1ef0de332d315d4b063399/lib
```

## 💁 Suggestion
This could be added to the `xcconfig` file via the `LD_RUNPATH_SEARCH_PATHS` setting! This way there would be no adjustment in Xcode necessary and the build config would just work!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: p0fi
issue_9000: state: open
title: [feature] Allow to generate more than one Find/config CMake file per recipe
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Currently, for a given recipe, `cmake_find_package` and `cmake_find_package_multi` can generate one and only one CMake Find/config file, based on the value of `self.cpp_info.filenames["cmake_find_package"]`/`self.cpp_info.filenames["cmake_find_package_multi"]` in `package_info()`.

Unfortunately, some libraries provide several config files for their components. In CCI, at least these recipes can't properly model official config files:

- mongo-c-driver
- mongo-cxx-driver
- spirv-tools
- google-cloud-cpp

A simple solution would be to allow `self.cpp_info.filenames["cmake_find_package"]` and `self.cpp_info.filenames["cmake_find_package_multi"]` to take a tuple, and duplicate the same Find/config files when conan generators are executed. `mongo-cxx-driver` recipe relies on this trick to duplicate the generated config file of `mongo-c-driver` at build time to satisfy its build system without the need to patch it: https://github.com/conan-io/conan-center-index/blob/master/recipes/mongo-cxx-driver/all/conanfile.py#L146-L151

It would also be nice to support this feature in the new generator `CMakeDeps` for conan 2.0
user: SpaceIm
issue_8995: state: open
title: [question] is conan impossible to use in a monorepo?
body: ## Question

Is it possible to use conan in a monorepo to manage multiple packages?

## Current situation

We have a monorepo with one huge CMake based superproject and use conan as a consumer only. We want to split this superproject up into separate conan packages (each containing multiple libraries/CMake targets), that have a certain dependencies to each other. Those packages shall have their conan recipe right with the code ([aka in-source recipe](https://docs.conan.io/en/latest/creating_packages/package_repo.html)), because it makes sense, right? Conan will be the **native build** infrastructure for those packages, so there will not be any other `build.sh` **per package**, maybe one for the whole monorepo.

The "products" of this monorepo will be executables and libraries that go to customers, and conan packages which will be consumed by other departments in the same company. This might be relevant to udnerstand the need for versioning of packages.

## Problems
### RREV

With in-source recipes, **any** change in the recipe **or** the sourcecode will result in a new RREV. This will propagate throughout the whole dependency tree, which sounds like a lot of maintainance/tooling required. Assume the following dependency graph:
![image](https://docs.conan.io/en/latest/_images/conan-info_deps_html_graph.png)

Lets assume all those packages represent in-source recipes. When a new PR is created to change even a comment in `zlib`, a new RREV is calculated for this package. `poco` now needs to be updated, because it had the old RREV as part of the `self.requires` call. The same needs to happen for `pcre`, and since its RREV also changed, we need to go back to `poco`'s recipe and update the RREV to `pcre` too. This will become maintainence hell 😞
One idea I had was to come up with some advanced tooling (like a python package or a `python_requires` conan package), that will abstract the dependencies away by calling something like `tool.requires(pcre)` (no version, no RREV) and a **centrally** defined list of package/version/RREV combination, for example at the repo root. But this now breaks the conan build process, because this information is not available when the sourcecode is copied to the conan local build cache

### Versioning

The common monorepo approach does not see it required/possible to have independend versioning of you libraries, as the whole repo must have a consistent state. Versions are defined in source (could be the conanfile, or reading from a version.txt). But conan very much relies on version numbers for caching, so I see some conflicting solutions:

a) each package has version 1.0, and the depend to each other with just `self.requires("package_a/1.0.0")`: This will probably disable conans caching feature, and create packages with the same version, but different RREV's. This may not be an issue if you always export all your recipes before starting to build anything, but you very likely will get problems when an conan repo comes into play and provides hundreds of alternative packages with the same version number. So lets use RREV? 😞 see above, and also we would need a solution to provide "real" versioning to packages that represent our external interface (aka "products")

b) each package will have its own, independend version. This means that for **any** change you must update the version you changed, and consequently all packages that depend on this changed package, because if their dependency changes, their `self.requires` changes, which is a change in the source. This is the same issue as with RREV's above.

---
- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: blackliner
issue_8994: state: open
title: [question] Qt6: How to make a dependency on the host lib?
body: Qt6 for Android (for instance) now requires the host binaries (i.e. Qt6 for Windows/macOS/Linux) to be built and used (androiddeployqt).

Is it possible to make a dependency

```py
class Qt6(ConanFile):
    name = "Qt6"
    version = "6.1.0"

    def requirements(self):
        # Add dependency on the host Qt libs/binaries
        os_ = self.settings.get_safe("os", default="None").lower()
        tag_ = f"@{self.user}/{self.channel}" if self.user and self.channel else ""
        if os_ == "android":
            self.requires(f"{self.name}/{self.version}{tag_}")
            # ??? add something to require Qt6 for Windows package
```

user: DmitrySokolov
issue_8992: state: open
title: Can't connect to conan_server through apache
body: I've been trying to get conan_server up and running through apache by following the docs here: https://docs.conan.io/en/latest/uploading_packages/running_your_server.html

### Environment Details (include every applicable attribute)
  * Operating System+version: RHEL 7.9
  * Apache version: 2.4.6 with mod_wsgi 4.7.1
  * Conan version: 1.35.2
  * Python version: 3.6

### Steps to reproduce (Include if Applicable)
I have the authentication working, and the conan client makes the initial connection to retrieve the host, port, and URL info, but then it fails to upload any files due to 'connection actively refused' errors. Comparing the apache log file with the output of running conan_server manually (which I'm able to connect to just fine), I noticed that the Bottle server is never getting started. Digging into the python code a bit, it seems the issue is that main() never gets called in server_launcher.py because \_\_name\_\_ isn't "\_\_main\_\_"; it's "_mod_wsgi_XXX". Updating that line to include checking for \_\_name\_\_.startswith('\_mod_wsgi\_') results in the Bottle server starting, but then the conan client will just hang until the request_timeout is reached, at which point it fails with "max retries exceeded." I've tried increasing the timeout to as much as a half an hour with the same result.

Any ideas why the client is never able to connect? Is the main() issue an expected local modification that needs to be made when running with WSGI or is it a symptom of something I have misconfigured? I understand conan_server is mainly used for testing, but I would really like to get this working. Any help would be greatly appreciated.

### Logs (Executed commands with output) (Include/Attach if Applicable)

Apache log (after the .startswith('\_mod_wsgi\_') modification):
```
[wsgi:error] [pid 30791] ***********************
[wsgi:error] [pid 30791] Using config: /usr/share/httpd/.conan_server/server.conf
[wsgi:error] [pid 30791] Storage: /usr/share/httpd/.conan_server/data
[wsgi:error] [pid 30791] Public URL: http://XXX.com:9300/v1
[wsgi:error] [pid 30791] PORT: 9300
[wsgi:error] [pid 30791] ***********************
[wsgi:error] [pid 30791] Bottle v0.12.19 server starting up (using WSGIRefServer())...
[wsgi:error] [pid 30791] Listening on http://0.0.0.0:9300/
[wsgi:error] [pid 30791] Hit Ctrl-C to quit.
```
httpd.conf:
```
<VirtualHost *:80>
        DocumentRoot /var/www/html
        ServerName      XXX.com

        WSGIScriptAlias /conan /usr/local/lib/python3.6/site-packages/conans/server/server_launcher.py
        WSGICallableObject app
        WSGIPassAuthorization On

        <Directory /usr/local/lib/python3.6/site-packages/conans>
                Require all granted
        </Directory>
</VirtualHost>
```


user: lcipolla8
issue_8979: state: open
title: [bug] Two completely different configurations
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

Please merge the two `conanfile.txt` and `conanfile.py` configuration methods into a single, unified system. The latter is verbose, but the former can't even declare a new package.

The divergence requires maintaining twice as much documentation. (And twice as much reading!) Quite the confusing user experience.

For example, deprecate conanfile.txt.
user: mcandre
issue_8973: state: open
title: [question] CMAKE_BUILD_TYPE and CMAKE_CONFIGURATION_TYPES behaviour
body: Well, I'll try to be short and clear...

The current steps which conducted me to the problem (and current question) : 
- I'm trying to build an internal project with MSVC, the project has a conanfile.py to manage its dependencies
-  some (well, all) of its requirements are currently missing on my system, thus a call to `conan install . -if build -s build_type=Debug --build=missing` triggers the build of the requirements (soooo cool)
- one of the requirement is REALLY sensitive to the possible build type values (MUST be Release or Debug)
- as the environement is multi-configuration capable (MSVC), the `CMAKE_BUILD_TYPE` is NOT set by conan when calling the build (YES, that's totally accurate)
- BUT the symmetric option `CMAKE_CONFIGURATION_TYPES` is NOT set by conan too
- and thus the requirement is build with a (CMake) default setup of Release,Debug,RelWithDebInfo,MinSizeRel
- which triggers a beautiful (but not expected nor intended) failure ...

So, shouldn't https://github.com/conan-io/conan/blob/develop/conans/client/build/cmake_flags.py
```python3
def build_type_definition(new_build_type, old_build_type, generator, output):
    if new_build_type and new_build_type != old_build_type:
        output.warn("Forced CMake build type ('%s') different from the settings build type ('%s')"
                    % (new_build_type, old_build_type))

    build_type = new_build_type or old_build_type
    if build_type and not is_multi_configuration(generator):
        return {"CMAKE_BUILD_TYPE": build_type}
    return {}
```
be modified as below 
```python3
def build_type_definition(new_build_type, old_build_type, generator, output):
    if new_build_type and new_build_type != old_build_type:
        output.warn("Forced CMake build type ('%s') different from the settings build type ('%s')"
                    % (new_build_type, old_build_type))

    build_type = new_build_type or old_build_type
    if build_type:
        if is_multi_configuration(generator):
            return {"CMAKE_CONFIGURATION_TYPES": build_type}
        else:
            return {"CMAKE_BUILD_TYPE": build_type}
    return {}
```

Can submit a PR later if required, but have no idea how to set up tests for this (haven't look yet). 
(side note : would be great to have a mentor-apprentice system for people who wants to be more implied into the conan/conan-center recipes development process)

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: oleurodecision
issue_8968: state: open
title: [feature] globally specify build folder
body: By default (on Linux), conan creates a build folder under `/home/user/.conan/data/package/version/_/_/build/hash/`

In this layout are 3 important sub directories:

- source: Downloaded exactly once per version, read only data, preferred to keep on persistent storage
- package: Create once per version and configuration, then read only. Most expensive to create. Should definitly be kept on persistent storage.
- build: Created once per version and configuration, read once per version and configuration. Potentially many intermediate reads and writes. Can be discarded after a package was created.

This small overview describes the situation when the recipe is "production-ready". When still developing the recipe, some deviation from the above observations are to be expected.

To avoid expensive disk writes and to speed up building (*) I propose adding a configuration switch for specifying a common (base) build directory. The idea here is that users would potentially choose a tmpfs or something similar on other OSes. The current solution to change the build directory with the `-bf` option is too cumbersome when creating many packages.

(*) A benchmark using `conan create` is still missing. I observed speedups up to 50% when compiling large code bases like LLVM having the CMake build directory under /tmp.


- [ x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).


user: Flow-It
issue_8962: state: open
title: [feature] Project Root folder as default
body: This opinion is based on my usage of other tools.
I have been searching multiple times and for many hours if those features exists, are planned or exists on issues.
I am sorry if it's already a duplicate.

There are a lot a file created by and for conan. Wouldn't it be better to bundle them in a `conan` folder?

Most commands need to know the path to a file, so i specify my project's root folder.
It would be nice to be able to use by default the root project as for git which goes up the file-tree to find a .git folder.

The package installation works great but all packages are installed globally under `~/.conan/{package}/{version}`.
As python has venv, or npm/yarn use .node_modules folders, I think it should be possible to install it in the project folder

It would be nice to have the `--save` option of npm/yarn to automaticly edit the conanfile.txt

Finally, having a quickstart command that would, given a default generator, create the base structure of the project (CmakeLists.txt with content, conan files, maybe basic gitignore, ...)

Thank you for reading.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: divad1196
issue_8955: state: open
title: [question] How to handle recipes that at the same time package tools during cross compilation
body: Hello Everyone,

I was wondering how recipes that also package tools in the form of executables should be handled. 
Such examples are:

* Qt (https://github.com/conan-io/conan-center-index/issues/5018, https://github.com/bincrafters/conan-qt/pull/70)
* protobuf (https://github.com/conan-io/conan/issues/8443, https://github.com/conan-io/conan-center-index/pull/4863)
* Limxml2 (https://github.com/conan-io/conan-center-index/blob/master/recipes/libxml2/all/conanfile.py#L23)

The interesting case for these recipes are during cross-compilation. The recipes build and package tools that are used during compilation (i.e. build context). So we need native binaries for the tools. The tools are usually used to produce code (or validate code) and might even be used during the compilation of the package itself (e.g. Qt). So the problem arise from the fact that a recipe has dual purpose. I.e. the recipe is being used at the same time as a build tool (in the build context) and as delivered library (for the host context). 

From what I have seen, the potential solutions to this problem are:

* Include the same package as requires and build_requires at the same time. The question is, if we can have different options for the same package in different contexts (i.e. host and build context). 

* Have a recipe that only packages the tools and use that recipe as a build_requires. The potential disadvantage might be that both the consumer and the recipe will have to use that package as build_requires.

Am I missing something? What should be the general approach in these cases? Is conan 2 considering these use cases?

Kind regards,

Vasileios


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: anagno
issue_8954: state: open
title: [feature] Search with ability to filter only with existing prebuilt binaries
body: It'd be nice to have a convenience flag to search for only packages which have prebuilt binaries for a given profile

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: xahon
issue_8949: state: open
title: [feature] Improving install step in the new CMake helper
body: CMake 3.15 introduced a new `cmake --install` command: https://cmake.org/cmake/help/latest/manual/cmake.1.html#install-a-project. It has several benefits over currently used `cmake --build . --target install`:
- does not involve a build tool (i.e. Ninja) so is faster to execute (especially for a header-only library)
- have additional options like `strip` that could also be exposed in the helper interface.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: mpusz
issue_8939: state: open
title: [feature] Default MSVC runtime configuration
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Let's make it easier to configure conan for MSVC with less boilerplate required. Pick a default setting for compiler.runtime.
user: mcandre
issue_8938: state: open
title: [question] Recommended way to get binaries for all required packages and transitive dependencies
body: Given the following scenario:
- We have a project which requires several conan packages, configured in one or more conanfile.py files
- Many of those requirements have non-default options

We want...
- ...all recipes and transitive dependencies to have binary packages on our conan server
- ...to build all those packages on our target platforms so that e.g. GLIBC versioning is not an issue

I see this as a possible way to accomplish this:
1. Configure a machine with the required tools (compilers etc.)
2. Clear the conan cache
3. For each conanfile.py, build the packages via `conan install --build=all --profile my_profile conanfile.py`
4. `conan upload -r my_conan_server --all "*"`

This approach has several problems:
- only want to build binaries not currently in our cache, but this builds everything...so adding 1 new dependency is massively inefficient
- if different conanfile.py use the same package and settings, will needlessly build multiple times
- overwrites binary packages already on the server?

Hopefully there's a better way to do this? I could think of some new commands and switches which could facilitate this, but let me know if there's already something better before I go through explaining those.

- [X ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: rconde01
issue_8934: state: open
title: Best way to promote packages
body: As we use pipelines to build packages and then run tests, we thought we would use an Artifactory repo promotion scheme to "upgrade" the status of our packages.  For example, we build and create a package on a dev branch, and upload its binaries to conan-dev.  Then spend time running through system tests.  Once the package is vetted (could take weeks), we would move the package from a conan-dev repo to a conan-release repo in Artifactory.
The separate repos has an advantage of we can setup separate purge policies on each repo. (packages will only stay in conan-dev for 3 months, but will stay forever in conan-release).
It looks like from you documentation you never talk about moving packages or package promotion like this, but instead you may use a strategy of changing the channel reference of a package, so that   name/version@user/dev  will get renamed to name/version@user/release, but the package would stay in the same artifactory repo.

1) Do you have a recommendation for the best strategy or industry standard for promotion of packages?
2) If indeed you want to move a package to a different repo, is the best mechanism to do a conan download then conan upload?
2a) We also have to sneaker net a mass amount of packages to another network and Artifactory.  What is the best option to do a mass copy of packages?
user: MichaelHCline
issue_8933: state: open
title: [workspace] conan workspace install virtualenv generator
body: I am using conan workspace for setting up a big repository containing multiple sub packages. I found it quite useful and efficient when you have many changes across packages. However, the `conan workspace install ` doesn't support virtualenv generator and normally for running the executable I will need to enter into virtualnev by `source activate.sh`. 

I tried to generate them manually but I found out those editable packages are compiled with local source files, but at runtime it's linking to binaries in cache. It will be ideal that the virtualenv generator will remove the `LD_LIBRARY_PATH` from those editable packages.

If you need more details, we can talk further more. Thanks for your help, looking forward to your feedback.
- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: XDinEuro
issue_8922: state: open
title: [question] CMakeToolchain and cross build profiles
body: conan version : 1.36.0

The CMakeToolchain generator feature is very exciting, it's good to see that we are making progress in this direction, not sure if this is something possible at this moment: 

- I have one `linaro-aarch64-gcc10.2-linux5.4_release.txt` which defines the host toolchain

and I have `generate()` defined in `conanfile.py`
```
def generate(self):
    tc = CMakeToolchain(self)
    tc.generate()
    deps = CMakeDeps(self)
    deps.generate()        
```   

Ideally, what I tried to achieve was:
```
conan install conanfile.py --profile=../conan/profiles/linaro-aarch64-gcc10.2-linux5.4_release.txt
cmake -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake ..
make
```

Was hoping that the compiler variables such as `CONAN_CMAKE_SYSTEM_PROCESSOR`, `CC`, `CXX` can be ported to conan_toolchain.cmake automaticlly.

I can see the `conan_toolchain.cmake` is generated after conan instal, but none of the CMAKE definitions in linaro-aarch64-gcc10.2-linux5.4_release.txt is defined if conan_toolchain.cmake, so the dependencies in conanfile.py are built and generated correctly using the linaro-aarch64-gcc10.2 toolchain, but it will still use the x86 compilers in the build x86 machine, so I wonder is there any step missing or this feature is not there yet.


Thanks
user: hsuanguo
issue_8921: state: open
title: [feature] Make copy consistent for import + RPATH/RUNPATH breaking issues.
body: So I am unsure if anyone ran into issue with RUNPATH/RPATH for conan modules.

A (.so) and B (.so) built on build machine, both have runpaths of build machine.
B requires A.

C (.so) is built on dev machine, requires B. C is built successfully, sets RUNPATH/RPATH to conan cache.

Yet on further inspection (ldd -d C) , we see that A is required, but not found.

It's not found because C is not using A directly and B in conan cache has RUNPATH/RPATH of build machine and not current dev machine, so it cannot find A on dev machine.

Enter $ORIGIN, our saviour, ability to replicate Windows build flow, copy .so to build folder, set RUNPATH/RPATH to $ORIGIN and everything is fixed. (This should seriously be documented).

But there is an issue, for some reason copy within imports() is trying to be unique snowflake and doesn't follow copy of deploy and package. There is no option to follow or not to follow symlinks, by default it does no follow symlinks. In a sense that you have to copy all related symlinks to get something working.

Say B generated b.so, b.so.1, b.so.1.0.1
Importing b.so or b.so.1 won't work, error will be thrown claiming that linking files are not found.
Importing b.so.1.0.1 will work, but C is linked against b.so.1 and not b.so.1.0.1, so while we can build we cannot execute.

We can do : `self.copy("*.so*", src="lib", dst=self.output_dir)`
Which will copy all of the files which does work, but it does not work on shared or mounted drives, as symlinks are not supported, which is what most of us use for dev work.

I've scoured source code to see how import is copying dependencies and came up with this:

```
   os.makedirs(self.output_dir, exist_ok=True)
            for pkg, cpp_info in self.deps_cpp_info.dependencies:
               for p in Path(os.path.join(cpp_info.rootpath, "lib")).glob("*.so??"):
                  shutil.copy2(p, self.output_dir, follow_symlinks=True)

```
Which copies just single b.so.1 which is no longer symlink but full fledged .so
It works on shared/mounted drives. But there is no beautiful imports statements stating how many files were imported, no logging, nothing and its not exactly conan way of doing things.

Yes I could try ripping out more of source code to enable logging/output for imports method, but it just seems wrong.
There needs to be option not to follow symlink while copying during import.
user: at185190
issue_8911: state: open
title: [question] Have single conan recipe defining multiple packages
body: Hello,

is it possible to define a single generic recipe that will define an infinite set of package versions? I would like to specify the package like this:
1. The source code for the package can be found in given git repository
2. Existing versions of the package are defined by git tags in the repository
3. Build steps are at given git tag revision in the repo as well. e.g. in conanfile.py

I upload such a recipe only once. When in a week I push a new git tag to the source repo, the original recipe will be able to proxy the changes to consumer. Attempt to check for newer versions would just look into the specified repo and search the git tags to see what is the latest relevant version. The same would go for build.

I am looking for a Carthage replacement and I would like to restrict from having to run a job or upload new recipe every time a semantic version has to change.  Especially for source-only dependencies. Using git tags is convenient and easy. I know conan is very powerful as we use it in other scenarios so I hope there is a way to make this happen as well.

Thanks for any answer,

Jakub
user: JakubBednar
issue_8909: state: open
title: [bug] conan profile:host options apply to build_requires dependencies.
body: ### Environment Details
  * Operating System+version: Arch Linux
  * Compiler+version: gcc 8 + 9 / cross-compiling
  * Conan version: 1.35.1
  * Python version: 3.9.4

### Steps to reproduce

I try to bundle firmware with conan by installing armv7hf components via [requires] and x86_64 tools to package via [build_requires].
Everything works fine, but it seems although openssl,libcurl and libzip are dependencies of softwareupdate which is in [build_requires], I have to give --options:host *:shared=True for to find these packages. The profile_build includes these options but they are ignored and taken from profile_host.

### Logs

```
# conanfile.txt
[requires]
bitstream/r42326@acnst052/yocto
image/1.0.0@acnst052/yocto
installerplugin/0.0.1@acnst052/yocto

[build_requires]
softwareupdate/0.0.1@

[imports]
boot, prefix* -> ./bnrb
., prefix* -> ./bnrb
., prefix* -> ./bnrb
```

BAD
```
$ conan install . --profile:host=yocto-sdk-env --settings:host=build_type=Release --profile:build=cpp-linux-x86_64-gcc8 --profile:build=shared-release -g virtualenv
Configuration (profile_host):
[settings]
arch=armv7hf
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
[options]
[build_requires]
[env]

Configuration (profile_build):
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
[options]
*:shared=True
[build_requires]
[env]
CC=/usr/bin/gcc-8
CXX=/usr/bin/g++-8
WARN: libzip/1.7.3: requirement openssl/1.1.1h overridden by softwareupdate/0.0.1 to openssl/1.1.1k 
WARN: libcurl/7.75.0: requirement openssl/1.1.1j overridden by softwareupdate/0.0.1 to openssl/1.1.1k 
conanfile_fw_1.0.0.txt: Installing package
Requirements
    bitstream/r42326@acnst052/yocto from local cache - Cache
    image/1.0.0@acnst052/yocto from local cache - Cache
    installerplugin/0.0.1@acnst052/yocto from local cache - Cache
Packages
    bitstream/r42326@acnst052/yocto:8911e3125cf349053169ac28a5c91273e2206249 - Cache
    image/1.0.0@acnst052/yocto:3386fb6a91a12a047a2d351791c92b1cd6efb4e2 - Cache
    installerplugin/0.0.1@acnst052/yocto:88693babce4de939d98aba779e5198c09cfe7445 - Cache
Build requirements
    libcurl/7.75.0 from 'external-conan' - Cache
    libzip/1.7.3 from 'external-conan' - Cache
    openssl/1.1.1k from 'external-conan' - Cache
    softwareupdate/0.0.1 from local cache - Cache
    zlib/1.2.11 from 'external-conan' - Cache
Build requirements packages
    libcurl/7.75.0:86e78c3decac64e7b79c84e88e3c36f54c53169e - Missing
    libzip/1.7.3:f32681b8b9a525ddcaf872ebcba7ffb0f9d004cb - Missing
    openssl/1.1.1k:1d877a3df840030e6a8abb74c5ffb9088d08b47a - Missing
    softwareupdate/0.0.1:c7c3efa818cb040c827d3f021572a80ec814fe39 - Cache
    zlib/1.2.11:1d877a3df840030e6a8abb74c5ffb9088d08b47a - Download

Cross-build from 'Linux:x86_64' to 'Linux:armv7hf'
Installing (downloading, building) binaries...
ERROR: Missing binary: libcurl/7.75.0:86e78c3decac64e7b79c84e88e3c36f54c53169e
ERROR: Missing binary: libzip/1.7.3:f32681b8b9a525ddcaf872ebcba7ffb0f9d004cb
ERROR: Missing binary: openssl/1.1.1k:1d877a3df840030e6a8abb74c5ffb9088d08b47a

openssl/1.1.1k: WARN: Can't find a 'openssl/1.1.1k' package for the specified settings, options and dependencies:
- Settings: arch=x86_64, build_type=Release, compiler=gcc, compiler.version=8, os=Linux
- Options: 386=False, fPIC=True, no_aria=False, no_asm=False, no_async=False, no_bf=False, no_blake2=False, no_camellia=False, no_cast=False, no_chacha=False, no_cms=False, no_comp=False, no_ct=False, no_deprecated=False, no_des=False, no_dgram=False, no_dh=False, no_dsa=False, no_dso=False, no_engine=False, no_filenames=False, no_gost=False, no_hmac=False, no_idea=False, no_md4=False, no_md5=False, no_mdc2=False, no_ocsp=False, no_pinshared=False, no_rc2=False, no_rmd160=False, no_rsa=False, no_sha=False, no_sm2=False, no_sm3=False, no_sm4=False, no_srp=False, no_srtp=False, no_sse2=False, no_ssl=False, no_threads=False, no_ts=False, no_whirlpool=False, openssldir=None, shared=False
- Dependencies: 
- Requirements: 
- Package ID: 1d877a3df840030e6a8abb74c5ffb9088d08b47a

ERROR: Missing prebuilt package for 'libcurl/7.75.0', 'libzip/1.7.3', 'openssl/1.1.1k'
Try to build from sources with '--build=libcurl --build=libzip --build=openssl'
Use 'conan search <reference> --table table.html'
Or read 'http://docs.conan.io/en/latest/faq/troubleshooting.html#error-missing-prebuilt-package'
```

GOOD

```
$ conan install . --profile:host=yocto-sdk-env --settings:host=build_type=Release --profile:build=cpp-linux-x86_64-gcc8 --profile:build=shared-release --options:host *:shared=True -g virtualenv
Configuration (profile_host):
[settings]
arch=armv7hf
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os_build=Linux
[options]
*:shared=True
[build_requires]
[env]

Configuration (profile_build):
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
[options]
*:shared=True
[build_requires]
[env]
CC=/usr/bin/gcc-8
CXX=/usr/bin/g++-8
WARN: libzip/1.7.3: requirement openssl/1.1.1h overridden by softwareupdate/0.0.1 to openssl/1.1.1k 
WARN: libcurl/7.75.0: requirement openssl/1.1.1j overridden by softwareupdate/0.0.1 to openssl/1.1.1k 
conanfile_fw_1.0.0.txt: Installing package
Requirements
    bitstream/r42326@acnst052/yocto from local cache - Cache
    image/1.0.0@acnst052/yocto from local cache - Cache
    installerplugin/0.0.1@acnst052/yocto from local cache - Cache
Packages
    bitstream/r42326@acnst052/yocto:8911e3125cf349053169ac28a5c91273e2206249 - Cache
    image/1.0.0@acnst052/yocto:3386fb6a91a12a047a2d351791c92b1cd6efb4e2 - Cache
    installerplugin/0.0.1@acnst052/yocto:88693babce4de939d98aba779e5198c09cfe7445 - Cache
Build requirements
    libcurl/7.75.0 from 'external-conan' - Cache
    libzip/1.7.3 from 'external-conan' - Cache
    openssl/1.1.1k from 'external-conan' - Cache
    softwareupdate/0.0.1 from local cache - Cache
    zlib/1.2.11 from 'external-conan' - Cache
Build requirements packages
    libcurl/7.75.0:049002579c003cd388d7af79171e951ae7e088d5 - Cache
    libzip/1.7.3:79980cfe9cde57b506d23b23c33c6b57f08f5b2f - Cache
    openssl/1.1.1k:1dab02a32a1a97c1102b3e06d1e2208a835226a4 - Cache
    softwareupdate/0.0.1:c7c3efa818cb040c827d3f021572a80ec814fe39 - Cache
    zlib/1.2.11:0a1a884e04a04c49e60b3bed4351187be5c53e3b - Cache

Cross-build from 'Linux:x86_64' to 'Linux:armv7hf'
Installing (downloading, building) binaries...
bitstream/r42326@acnst052/yocto: Already installed!
image/1.0.0@acnst052/yocto: Already installed!
installerplugin/0.0.1@acnst052/yocto: Already installed!
openssl/1.1.1k: Already installed!
zlib/1.2.11: Already installed!
libcurl/7.75.0: Already installed!
libzip/1.7.3: Already installed!
libzip/1.7.3: Appending PATH environment variable: /home/markus/.conan/data/libzip/1.7.3/_/_/package/79980cfe9cde57b506d23b23c33c6b57f08f5b2f/bin
softwareupdate/0.0.1: Already installed!
conanfile_fw_1.0.0.txt: Applying build-requirement: softwareupdate/0.0.1
conanfile_fw_1.0.0.txt: Applying build-requirement: libzip/1.7.3
conanfile_fw_1.0.0.txt: Applying build-requirement: libcurl/7.75.0
conanfile_fw_1.0.0.txt: Applying build-requirement: openssl/1.1.1k
conanfile_fw_1.0.0.txt: Applying build-requirement: zlib/1.2.11
conanfile_fw_1.0.0.txt: Generator txt created conanbuildinfo.txt
conanfile_fw_1.0.0.txt: Generator virtualenv created activate.ps1
conanfile_fw_1.0.0.txt: Generator virtualenv created deactivate.ps1
conanfile_fw_1.0.0.txt: Generator virtualenv created environment.ps1.env
conanfile_fw_1.0.0.txt: Generator virtualenv created activate.sh
conanfile_fw_1.0.0.txt: Generator virtualenv created deactivate.sh
conanfile_fw_1.0.0.txt: Generator virtualenv created environment.sh.env
conanfile_fw_1.0.0.txt: Generated conaninfo.txt
conanfile_fw_1.0.0.txt: Generated graphinfo
conanfile_fw_1.0.0.txt imports(): Copied 1 '.bitstream,s=r42326,h=1' file: prefix.bitstream,s=r42326,h=1
conanfile_fw_1.0.0.txt imports(): Copied 1 '.1' file: prefix.installer.plugin,s=0.0.1
conanfile_fw_1.0.0.txt imports(): Copied 1 '.0' file: prefix.image,s=1.0.0
```
user: mklntf
issue_8905: state: open
title: [question] How to build with msvc inside a Cygwin bash?
body: I am trying to build https://github.com/bincrafters/conan-libiconv version 1.15 with msvc. It works fine when I use these commands and it correctly uses msvc:
```
$ cmd
$ call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86
$ conan install conanfile.py -s arch=x86 -s build_type=Release -s compiler=Visual Studio -s compiler.version=14 -s 
compiler.runtime=MD -s compiler.runtime=MT -g=cmake --build=missing
Configuration:
[settings]
arch=x86
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MT
compiler.version=14
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
```

But if I do this inside a Cygwin shell, it tries to use gcc instead of msvc:
```
$ cmd
$ call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86
$ bash
$ conan install conanfile.py -s arch=x86 -s build_type=Release -s compiler=Visual Studio -s compiler.version=14 -s 
compiler.runtime=MD -s compiler.runtime=MT -g=cmake --build=missing
Configuration:
[settings]
arch=x86
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MT
compiler.version=14
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

...
18:00:25 libiconv/1.15@bincrafters/stable: Copying sources to build folder
18:00:28 libiconv/1.15@bincrafters/stable: Building your package in C:\cygwin\home\user\.conan\data\libiconv\1.15\bincrafters\stable\build\79c71dbda360a634692376cd2ed5aafa18493952
18:00:28 libiconv/1.15@bincrafters/stable: Generator txt created conanbuildinfo.txt
18:00:28 libiconv/1.15@bincrafters/stable: Calling build()
18:00:28 libiconv/1.15@bincrafters/stable: CONAN_BASH_PATH=None
18:00:28 libiconv/1.15@bincrafters/stable: MSYS_BIN=C:\.conan\c17366\1\bin\usr\bin
18:00:28 libiconv/1.15@bincrafters/stable: using bash.exe from: C:\.conan\c17366\1\bin\usr\bin\bash.exe
18:00:33 libiconv/1.15@bincrafters/stable: WARN: Error running `configure --help`: Error 1 while executing /c/cygwin/home/user/.conan/data/libiconv/1.15/bincrafters/stable/build/79c71dbda360a634692376cd2ed5aafa18493952/source_subfolder/configure --help
18:00:33 libiconv/1.15@bincrafters/stable: Calling:
18:00:33  > /c/cygwin/home/user/.conan/data/libiconv/1.15/bincrafters/stable/build/79c71dbda360a634692376cd2ed5aafa18493952/source_subfolder/configure --enable-static --disable-shared --prefix=C:/cygwin/home/user/.conan/data/libiconv/1.15/bincrafters/stable/package/79c71dbda360a634692376cd2ed5aafa18493952 --host=i686-w64-mingw32
18:00:33 libiconv/1.15@bincrafters/stable: run_in_windows_bash: C:\.conan\c17366\1\bin\usr\bin\bash.exe --login -c ^"cd \^"/c/cygwin/home/user/.conan/data/libiconv/1.15/bincrafters/stable/build/79c71dbda360a634692376cd2ed5aafa18493952/source_subfolder\^" ^&^& PATH=\^"/c/.conan/c17366/1/bin/usr/bin:$PATH\^" ^&^& /c/cygwin/home/user/.conan/data/libiconv/1.15/bincrafters/stable/build/79c71dbda360a634692376cd2ed5aafa18493952/source_subfolder/configure --enable-static --disable-shared --prefix=C:/cygwin/home/user/.conan/data/libiconv/1.15/bincrafters/stable/package/79c71dbda360a634692376cd2ed5aafa18493952 --host=i686-w64-mingw32 ^"
18:00:34 libiconv/1.15@bincrafters/stable: 
18:00:34 libiconv/1.15@bincrafters/stable: Creating /dev/shm directory failed.
18:00:34 libiconv/1.15@bincrafters/stable: POSIX semaphores and POSIX shared memory will not work
...
18:01:01 ERROR: Package '79c71dbda360a634692376cd2ed5aafa18493952' build failed
18:01:01 libiconv/1.15@bincrafters/stable: WARN: Build folder C:\cygwin\home\user\.conan\data\libiconv\1.15\bincrafters\stable\build\79c71dbda360a634692376cd2ed5aafa18493952
18:01:01 ERROR: libiconv/1.15@bincrafters/stable: Error in build() method, line 127
18:01:01  autotools = self._configure_autotools()
18:01:01 while calling '_configure_autotools', line 112
18:01:01  self._autotools.configure(args=configure_args, host=host, build=build)
18:01:01  ConanException: Error 77 while executing /c/cygwin/home/user/.conan/data/libiconv/1.15/bincrafters/stable/build/79c71dbda360a634692376cd2ed5aafa18493952/source_subfolder/configure --enable-static --disable-shared --prefix=C:/cygwin/home/user/.conan/data/libiconv/1.15/bincrafters/stable/package/79c71dbda360a634692376cd2ed5aafa18493952 --host=i686-w64-mingw32
```

How can I tell conan to build things with msvc instead of gcc ?

I do I am calling conan from inside Cygwin because our build system (which create installable packages) is built using shell scripts, and after configuring everything, it calls conan to build the project.

I tried running a nested cmd shell inside Cygwin, i.e.:
```
$ cmd
$ call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86
$ bash 
$ cmd
$ conan install conanfile.py -s arch=x86 -s build_type=Release -s compiler=Visual Studio -s compiler.version=14 -s 
compiler.runtime=MD -s compiler.runtime=MT -g=cmake --build=missing
```
But conan still trying to use gcc instead of msvc.

How conan detect it is running inside Cygwin or `cmd.exe` ? Is it using some exported environment variable ? If so, which variable would it be so I can unset it ?
user: evandrocoan
issue_8889: state: open
title: MSVC compiler.version is not allowed to contain `.`
body: We needed to keep track of subversions of MSVC, i.e. 16.8 vs 16.9. Why? because MSVC LTCG (LTO) is not compatible between minor versions. So if you compile a static library with LTCG in 16.8 you can't link it to with 16.9.

We thought this was a easy solution - just change compiler.version to 16.8 instead of 16. But there are several assumptions in the conan codebase about the value of this setting, here is one: https://github.com/conan-io/conan/blob/develop/conans/client/tools/win.py#L429

For now I am adding `compiler.minorversion` but maybe this should be fixed.
user: tru
issue_8888: state: open
title: [question] --profile:build --profile:host and build_requires the same package reference issue
body: Hi,

I have the following issues when trying to get qtbase to cross-compile for Android.
I'm working on with the two profile approach for cross-compiling qtbase.

E.g. the Android build needs tools from the desktop linux/win/mac build thus I need to
build_require the same package reference. This is luckily now supported by Conan.

**--profile:build**

```
[settings]
    os=Linux
    arch=x86_64
    compiler=gcc
    compiler.version=9.3
    compiler.libcxx=libstdc++11
    build_type=Release
[options]
*:release=yes
*:shared=yes
[build_requires]
[env]
CONAN_CMAKE_GENERATOR=Ninja
```

**--profile:host**

[settings]
    os=Android
    os.api_level=8
    arch=armv8
    compiler=clang
    compiler.version=11
    compiler.libcxx=libstdc++11
    build_type=Release
[options]
*:release=yes
*:shared=yes
*:platform=android-clang
*:android_ndk=/home/<user>/Android/Sdk/ndk/21.1.6352462
*:android_sdk=/home/<user>/Android/Sdk
*:android_abis=arm64-v8a
[build_requires]
qtbase/<version>@qt/test
[env]
CONAN_CMAKE_GENERATOR=Ninja


**Issue 1:**

I first tried to put the build_requires in the recipe, but it will cause:

> ERROR: Loop detected in context host: 'qtbase/<version@qt/test' requires 'qtbase/<version>@qt/test' which is an ancestor too

```
class QtBase(ConanFile):
    name = "qtbase"
    ...
    def _is_cross_build(self) -> bool:
        return not getattr(self, 'settings_target')

    def build_requirements(self):
        if self._is_cross_build():
            self.build_requires("qtbase/<version>@qt/test", force_host_context=True)
```

Once removing the build_requires from the recipe and adding it to the android -profile the above error is not given anymore.
Is there something wrong in my implementation regards the recipe?


**Issue 2:**

Conan options are aggregated from --profile:host into build context.
This appears to be as documented: https://docs.conan.io/en/latest/devtools/build_requires.html#properties-of-build-requirements

But the issue I'm facing now is that when Conan is building the build_requires in build context it will "inherit" option platform=android-clang which is simply wrong for building the qtbase in the build context (desktop) thus the build fails.
Also other Android related options are "inherited" as well which should not be used in the build context build.

As I can deduce the build context in the recipe is there a way to access options from the --profile:build only?
I saw documentation mentioning **self.settings_build** but nothing about e.g. self.options_build?


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: iiknd
issue_8886: state: open
title: [feature] Don't require compiler.version parameter
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Please drop the requirement to input a `-s compiler.version` when setting the compiler name. When I set the compiler name, to clang, I simply want to use whatever version of clang is on my system. I don't care which version.
user: mcandre
issue_8872: state: open
title: [question] How to pass compiler and version from conan to CMake
body: How to I pass the compiler and version from the profile into CMake? Suppose default is gcc 7 (gcc --version yields 7.5) and I also have gcc 6 (gcc-6 --version is 6.5). Then I have two profiles, one for gcc 7 and one for gcc 6. How do I let CMake use the compiler and version from the conan profile?

In the conanfile.py can do 
cmake.configure(defs = {"CMAKE_C_COMPILER": "gcc-6", "CMAKE_CXX_COMPILER": "g++-6"})
but how to I obtain the compiler names from conan?

Thanks,
Jochen
user: Jochen0x90h
issue_8868: state: open
title: Consider cmake and Xcode versions for Xcode generator in CMakeToolchain
body: CMake <3.19 will not work properly for Xcode>11 when using Xcode CMake generator. That's what forced us to add [cmake 3.19 as a requirement for some tests](https://github.com/conan-io/conan/pull/8849) to be able to update Xcode to the latest version on the ci.
We should also consider these requirements in `CMakeToolchain` when `generator==xcode`.
From CMake 3.19 using generator Xcodethere's an environment variable [CMAKE_XCODE_BUILD_SYSTEM](https://cmake.org/cmake/help/latest/variable/CMAKE_XCODE_BUILD_SYSTEM.html#variable:CMAKE_XCODE_BUILD_SYSTEM) to switch to the XCode 11.X build system, also [can be set by the command line](https://cmake.org/cmake/help/latest/release/3.19.html#generators) (-T buildsystem=1).
user: czoido
issue_8866: state: open
title: [FR] Integrate better with update-alternatives, cc, c++
body: <!-- What is your suggestion? Please be as specific as possible! -->

On Ubuntu, conan is picking up the wrong compiler by default.

I have configured update-alternatives to use clang and clang++. The `cc` and `c++` binaries already point to clang and clang++. But still, somehow conan's compiler detection system ignores this and defaults to gcc anyway.

I think I can explicitly configure conan to prefer certain toolchains. But I would rather conan do the right thing out of the box.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: mcandre
issue_8853: state: open
title: [feature] Log User for Remote in Verbose Mode
body: <!-- What is your suggestion? Please be as specific as possible! -->
When trying to download a package from a repo which hides existence of unauthorized resources (like Artifactory) trying to download a package results in an error that the package could not be found on the repo. Even when enabling the most verbose logging mode its nowhere written which user is used to get the package.

```
package/1.0.2@repo/stable: Trying with 'gitlab'...
DEBUG :rest_client_common.py[160]: REST: ping: https://gitlab.com/api/v4/packages/conan/v1/ping [2021-04-22 22:52:03,502]
DEBUG :rest_client.py [58]: REST: Cached capabilities for the remote: [] [2021-04-22 22:52:03,644]
DEBUG :rest_client_common.py[188]: REST: get: https://gitlab.com/api/v4/packages/conan/v1/conans/package/1.0.2/repo/stable/download_urls [2021-04-22 22:52:03,645]
DEBUG :rest_client_common.py[30]: REST ERROR: <class 'conans.errors.NotFoundException'> [2021-04-22 22:52:03,703]
ERROR: Unable to find 'package/1.0.2@repo/stable' in remotes
```

It would be a massive help if the user used for the remote could be found in those log lines!

It would may be even more helpful if the user used for the remote is logged in the general output not only in verbose mode. It could be something like 

```
package/1.0.2@repo/stable: Trying with 'anonymus' @ 'gitlab'...
```

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: p0fi
labels: component: ux: No changes to core business logic
issue_8848: state: open
title: [feature] Custom storage path per project
body: I work on my own pc and do my pet projects on same pc and often switching between my own conan repositories and company's ones. When i switch back and forth i always rename my `C:\conan` directory into something like `C:\conan1` to download all the packages from scratch because they intersect each other and it causes errors. It would be great if we could set `storage.path` per project and we could easily scope package source per project. I don't know how it can be done the easy and comfortable way but it can reduce the number of renaming `storage.path` directory back and forth to zero. What do you think about it?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: xahon
issue_8842: state: open
title: [question] how to set dependencies to components
body: Hi!

I have requires = "boost/1.75.0", "glfw/3.3.3" and now want to use only some components of boost. Is this already supported for boost? When I do self.cpp_info.requires = ['boost::asio', 'glfw'] in method package_info then I get this error:
ConanException: roomcontrol/main package_info(): Package require 'glfw' not used in components requires

Any ideas?
Thanks,
Jochen
user: Jochen0x90h
issue_8841: state: open
title: conan inspect with conan-center is failing on windows platform
body: 

### Environment Details (include every applicable attribute)
  * Operating System+version:  Windows 10 
  * Compiler+version:
  * Conan version:  Conan version 1.35.2
  * Python version: 3.8.2

### Steps to reproduce (Include if Applicable)
conan inspect poco/1.9.4 -r conan-center

its asking for password and not able to authenticate it.


### Logs (Executed commands with output) (Include/Attach if Applicable)
Please log in to "conan-center" to perform this action. Execute "conan user" command.
If you don't have an account sign up here: https://bintray.com/signup/oss
Remote 'conan-center' username: penugondac
Please enter a password for "penugondac" account:
ERROR: Wrong user or password
Remote 'conan-center' username:


I am not sure why it needs to ask for username and password for conan-center. 

When i tried to login using browser with the same credentials its working.


user: cpenugon
issue_8837: state: open
title: [question] Playing with channel names
body: This is not really an issue, but more a request for feedback. I want to hear how other think about this, if they gained any experience with it.

We've been struggling a bit to give all our recipes a clean structure, expecially when they combine different "build" methods.
So basically, when packaging 3rd party libraries you have one of three cases:
- You build from source. Awesome.
- You download something that has been prebuild (often the case for Windows pure C libraries, which can only be build with MinGW or which you don't even want to attempt to build yourself - YAY for C ABI compatibility)
- You write a wrapper around a system package

So often, the Conan recipes are a mix of the approaches, and they get dirty really easily.
On the consumer side, you will also have stupid code like

```
def requirements(self):
  if self.settings.compiler == "gcc":
    if self.settings.compiler.version == "5":
      self.requires("protobuf/2.6.1@user/stable")
    if self.settings.compiler.version == "7":
      self.requires("protobuf/3.0.0@user/stable")  
  elif self.settings.compiler == "Visual Studio":
    self.requires("protobuf/3.5.0@user/stable")   
```

YUCK, you see what this leeds to.

We might just have code like 
```
def requirements(self):
  self.requires("protobuf/[>=2.6.0]@user/stable")   
```

We can do it, it kind of works, but it breaks, when we do want to fall back to a system versions in a place where a newer from source build is also available.
(We do have builds, where we say we would like to use system versions, wherever possible, in order to be able to create a .deb package which matches the distro for example).

So this is why we had the idea, to move different recipe implementations to different channels.
```protobuf/3.0.0@user/system```
```protobuf/3.5.0@user/source```

So in that usecase, channels are not used for testing / stable (which is discouraged anyways), but for different implementations of basically the same package.

## So my questions are:
- How does this behave with overrides? A lib might require only a specific version but does not care about the channel, but then the app wants to specify how things are build. Can I leave out the channel completely? Can I override the channel completely?
```
(lib.py)
def requirements(self):
   self.requires("protobuf/[>=3.0.0]@user/*")
```

```
(app.py)
def requirements(self):
   # we should check ubuntu instead of gcc...
   if self.settings.compiler == "gcc":
     self.requires("protobuf/[>=3.0.0]@user/system")
   else:
     self.requires("protobuf/3.5.0@user/source")
```
- Is this a good or rather a bad idea?

I am looking forward for any feedback and experiences :)
user: KerstinKeller
issue_8834: state: open
title: [question] Explicit setting propagating to dependencies
body: Looking at the [`conan install` documentation](https://docs.conan.io/en/latest/reference/commands/consumer/install.html), it seems that if I want to specify a specific setting to apply to only one package, I would say:

`conan install -s mypackage:arch=x86 .`

Which kind of works fine. Except when `mypackage` has its own dependencies (that it declares as `requires = ...` in its recipe). When Conan installs those dependencies, it will take the profile settings instead of propagating the `arch=x86` setting that I explicitly specified for `mypackage` and which I expected to propagate to its dependencies.

Is this by design, am I doing it wrong, or it is some kind of bug?

user: theodor96
issue_8830: state: open
title: [bug] Conanfiles loaded by path fail when named options override starred ones
body: Thank you for the great work on conan.  When working with on developing recipes I found an issue with how profiles are used for requests by path.  I was using the `source(...)` function in the python api, but the CLI shown below has the same behavior.

When loading a conanfile,  options are processed differently if you take a path vs a reference.  Specifically, when you load by path, profile entries that are named (e.g. `ImportantRecipe:option=False`) will be ignored. The steps uses `conan info`, but I imagine any API call that can take a path would be susceptible.

For the error outcome below, it seems like having a stared property paired with the named one is a requirement.

### Environment Details (include every applicable attribute)
  * Operating System+version: CentOS Linux 7 (Core)
  * Conan version: Conan version 1.35.2 (also tested with the same behavior in 1.20 and 1.10)
  * Python version: Python 3.6.8

### Steps to reproduce (Include if Applicable)

1. Create a simple conanfile which has a some required option
    ```python
    class ImportantRecipe(ConanFile):
        name = "ImportantRecipe"
        version = '1.0'
        user = 'user'
        channel = 'channel'
        options = {"shared": [True]}
        default_options = {"shared": True}
    ```
2. Create a default profile that includes both a starred default and a package-specific variant.  (The order doesn't matter)
    ```
    [options]
    *:shared=False
    ImportantRecipe:shared=True
    ```
3. Export the recipe (this isn't required for the failure, but we'll use it to verify the reference version of commands work)
    ```
    conan export /path/to/importantrecipe/conanfile.py
    ```
4. Show that `conan info` for the reference works as expected
    ```
    conan info ImportantRecipe/1.0@user/channel
    ```
5. Test conan info for the file path. **_This step produces the unexpected behavior._**
    ```
    conan info /path/to/importantrecipe/conanfile.py
    ```
6. Update the default profile to include just an invalid named option.
    ```
    [options]
    ImportantRecipe:shared=False
    ```
7. Show that `conan info` for the reference fails as expected
    ```
    conan info ImportantRecipe/1.0@user/channel
    ```
8. Show that `conan info` for the file path fails as expected
    ```
    conan info /path/to/importantrecipe/conanfile.py
    ```

### Logs (Executed commands with output) (Include/Attach if Applicable)

Step 4 works as expected, and steps 7/8 fail as expected. Step 5 unexpectedly fails with:
```
ERROR: /path/to/importantrecipe/conanfile.py: 'False' is not a valid 'options.shared' value.
Possible values are ['True']
```

user: rddesmond
issue_8824: state: open
title: Package version conflict although a version range exists (diamond problem)
body: Hello,

if two depending packages (B, C) has different version requirements of the same package (A), you have to resolve the conflict in root package:

`To fix this conflict you need to override the package '...' in your root package.`

But I thought or would prefer, if one of them has a version range to A, this could be automatic resolved. But this does not happen.

**lib-a**
```py
class Lib(ConanFile):
    name = "lib-a"
    version = "0.0.2" # Or 0.0.1
```

**lib-b**
```py
class Lib(ConanFile):
    name = "lib-b"
    version = "0.0.1"
    requires = "lib-a/0.0.1"
```

**lib-c**
```py
class Lib(ConanFile):
    name = "lib-c"
    version = "0.0.1"
    requires = "lib-a/[0]"
```

**lib-d**
```py
class Lib(ConanFile):
    name = "lib-d"
    version = "0.0.1"
    requires = "lib-b/0.0.1", "lib-c/0.0.1"
```

See and run create.sh in https://github.com/Viatorus/conan-test-diamond

Runnig conan 1.34.0.
user: Viatorus
issue_8795: state: open
title: [feature] Adding interface sources
body: It is often the case especially on embedded projects that libraries expect certain definitions to be defined. Stuff like buffer sizes, clock speeds etc. This means that often such libraries cannot be pre-built but expect consumers to pull their sources in their project where project-specific configurations are available. These libraries are not header-only and they have the advantage of better iterative builds. 

CMake already supports such libraries by providing INTERFACE target_sources. Eg you provide an INTERFACE library and consuming projects normally find_package and link and the library's sources are added to the final target. 

This has another important advantage other than better iterative builds (compared to header-only libraries) and that's trivial cross-compiling support. While conan now has very good support for most cross-building scenarios, exposing libraries in this way could provide a smooth way to integrate conan on such cross-compiling ecosystems before getting more familiar with the necessarily more complex cross-building support.

What I am suggesting is adding some method to express such sources, maybe extending the cpp_info object. All the cmake generators could then benefit from this and perhaps other build systems may benefit too.
user: liarokapisv
issue_8774: state: open
title: [feature] architectures for embedded development
body: Hi, 

in my company we use conan for embedded development. For this we need certain architectures to be defined in the `settings.yml` file. Until now, we added them our self, but it would be nice if conan could support them by default. Therefore I would like to suggest to add the following architectures to the default values of the `settings.yml` file:
* `armv6s-m`
* `armv7-m`
* `armv7e-m`
* `armv8-m.base`
* `armv8-m.main`

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: georghirn
issue_8771: state: open
title: [question] Why does deleting option from package Id, does not stop option appearing in dependency option list
body: If you delete an option from package ID to stop option from affecting package id, it should also remove that option appearing as an option that influences package ID when the package is being pulled in as a dependency.

    def package_id(self):
        del self.info.options.clean
        .....


ourlib/1.0.1@some/where: WARN: Can't find a 'ourlib/1.0.1@some/where' package for the specified settings, options and dependencies:
- Settings: arch=x86_64, build_type=Release, compiler=Visual Studio, compiler.runtime=MD, compiler.version=15, os=Windows
- Options: build_tests=True, clean=False, emulator=True, execute_tests=True, shared=False, sign=False, test_args=None, version=False, wchar=True,

Most of those options are not affecting package ID.
Options that were directly deleted in config_options() does not seem to appear in the list, but that's not good solution as we actually want to use these options in our recipes.
user: at185190
issue_8759: state: open
title: [question] What is the advocated way to run unit tests
body: Our unit tests are being kicked off after building within the build method.  Tests can be disabled using a Conan option which is deleted from the package ID.   

However, we came across the CONAN_RUN_TESTS env var.  From what I understand, this will disable running of the "test" method.  Is the test method designed for running basic tests against a package or is it designed also for running unit tests?

Options for us are:
-Running tests from the build method depending on a custom option + deleting from the package ID.  When using a build policy which causes dependencies to build, it means having to pass *:tests=False.
-Run tests from the build method conditionally based on CONAN_RUN_TESTS 
-Run tests from the test method - which is not run if CONAN_RUN_TESTS  is false?

What is the recommended way to run?

Thanks
Scott

user: sd185233
issue_8757: state: open
title: [bug] Problems with configuration files generated with `CMakeDeps`
body: It seems that configuration files generated with `CMakeDeps` do not raise an error when a package is not found.

Because of some unknown reason, Doxygen stopped working with Conan a few days ago:
https://github.com/mpusz/units/actions/workflows/documentation.yml

CMake file requires both Sphinx and Doxygen:
https://github.com/mpusz/units/blob/c4e9ff7f66c0ee34d8d91c0d6598f1befde2dd53/cmake/documentation.cmake#L25-L26

But only Sphinx is found by CMake:
https://github.com/mpusz/units/runs/2253391970?check_suite_focus=true#step:10:34

I cannot reproduce the issue on my local machine. Locally the log looks as follows:
```
[cmake] -- Project documentation generation: True
[cmake] -- Found Doxygen: /home/mpusz/.conan/data/doxygen/1.8.20/_/_/package/b170ec83ff42c70053bd078cb1ed89b94af0307e/bin/doxygen (found version "1.8.20") found components: doxygen dot 
[cmake] -- Found Sphinx: /home/mpusz/.local/bin/sphinx-build  
[cmake] -- Configuring done
[cmake] -- Generating done
[cmake] -- Build files have been written to: /home/mpusz/repos/units_latest/build/GCC 10.2.0
```

which clearly states that the Doxygen was found. This is not the case on the GitHub CI where it fails.

As the generated configuration files did not force CMake to fail on the configuration step (even though `REQUIRED`) is being used in `find_package()` it badly fails during build phase:
https://github.com/mpusz/units/runs/2253391970?check_suite_focus=true#step:11:11.

Configuration files generated by Conan should force an error when the package is not found and `REQUIRED` is being used.
user: mpusz
issue_8714: state: open
title: [Question] Quotations in .env files generated by virtualrunenv
body: <!-- What is your question? Please be as specific as possible! -->

Hi,
is there a specific reason for quoting every item separately inside the env var lists of .env files generated by the `virtualrunenv` generator? If the possible spacing in paths is the only concern wouldn't adding quotes only at the beginning and the end of a variable value be sufficient?

meaning this:
```
LD_LIBRARY_PATH="/dummy/path:/home/user/test/build/lib:/dummy/path"
```
instead of this (current behavior):
```
LD_LIBRARY_PATH="/dummy/path":"/home/user/test/build/lib":"/dummy/path"
```

I'm asking about this because I'm often debugging binaries that use shared libraries from Conan from the VS Code (with Microsoft's C++ plugin) debugger. In their task configuration it's possible to set the environment variables with an .env file which would mean perfect integration with Conan's `virtualrunenv` generator. Unfortunately, the cpptools plugin loads the variables from the .env file in a way that only strips the outer quotes, which is something I noticed that packages like node's `dotenv` and python's `python-dotenv` do as well (well, the python package just errors out if it the var has any internal quotes). Hence, in my above example, gdb would get the `LD_LIBRARY_PATH` var with value `/dummy/path":"/home/user/test/build/lib":"/dummy/path` which is invalid and it won't be able to find any shared libs. So in the end what I need to do after each `conan install` is to remove these quotes manually before starting the debugger.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: aleksa2808
issue_8711: state: open
title: [feature] Add runtime (only) requirements to lower build times
body: Alongside build requirements and requirements can you add runtime requirements which are not installed during build time but only during install time of the final Conan package? Or alternatively add a flag to a requirement that let's Conan know that it is not needed during build time?
Some of our runtime requirements are very large but are downloaded for every build. Even if the download cache is used it is just not efficient.

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: johschmitz
issue_8708: state: open
title: [question] Is there a way to split test requirements from application ones?
body: I wanted to add gtest library to my project that already contains some packages needed for work of my application. I realized that my program links to gtest libraries which is not good at all. Can I somehow split these packages needed just for unit testing purposes using built-in conan features? How to manage that the right way?
There is a `build_requires` and I expected something like `test_requires`

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: xahon
issue_8707: state: open
title: [bug] Inconsistent settings when using non default compiler.toolset and compiler.version
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->
When using a profile requesting a non-default Visual Studio compiler and toolset duplet, created package settings seemingly get mutated to fit the default.
I'm not sure whether this is a bug or intended behavior, looking back I realize `toolset` is a compiler dependent setting that only makes sense in the context of Visual Studio builds, it's fair Conan tries to re-establish alignment, albeit surprising at first

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: Visual Studio 16
  * Conan version: 1.34.1
  * Python version: 3.9.2

### Steps to reproduce (Include if Applicable)

1. Create a recipe with compiler settings
2. Call conan create with a VS profile that does not match the default, i.e MSVS 16 with v141 build tools
3. Inspect created conaninfo.txt or call conan search

conanfile.py
```python
from conans import ConanFile


class DummyConan(ConanFile):
    name = "dummy"
    version = "0.1"
    settings = "os", "compiler", "build_type", "arch"

    def package(self):
        pass
```

### Logs (Executed commands with output) (Include/Attach if Applicable)
```bash
> conan create . -s compiler="Visual Studio"  -s compiler.toolset=v141 -s compiler.version=16
Exporting package recipe
dummy/0.1: A new conanfile.py version was exported
dummy/0.1: Folder: E:\dev\.conan\data\dummy\0.1\_\_\export
dummy/0.1: Using the exported files summary hash as the recipe revision: cd95449ab4f8b9af2476504472e516d7
dummy/0.1: Exported revision: cd95449ab4f8b9af2476504472e516d7
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.toolset=v141
**compiler.version=16**
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
...
dummy/0.1: Package '6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7' created
dummy/0.1: Created package revision b3bdc8c4699b8828dc268253bef801c2
```

```bash
> conan search dummy/0.1@
Existing packages for recipe dummy/0.1:

    Package_ID: 6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7
        [settings]
            arch: x86_64
            build_type: Release
            compiler: Visual Studio
            compiler.runtime: MD
            **compiler.version: 15**
            os: Windows
        Outdated from recipe: False
```

user: remysalim
issue_8699: state: open
title: [question] version conflict requires and build_requires
body: We're having an issue with requires, build_requires and version conflicts after upgrading a package.

Scenario:

3 packages, PkgA, PkgB and PkgC. PkgC has been updated from 3.0.0 to 3.1.0 (binary compatible with 3.0.0). Only PkgA cares about the updates to PkgC.

PkgA requires PkgC/3.1.0@dev/dev
PkgA build_requires PkgB/3.0.0@release/stable (required for unit testing only, hence build_requires)
PkgB requires PkgC/3.0.0@release/stable

When trying to create PkgA (after upgrading to new PkgC version) conan complains of a conflict:

```
ERROR: Conflict in PkgB/3.0.0@release/release:
    'PkgB/3.0.0@release/release' requires 'PkgC/3.0.0@release/release' while 'conanfile.py (PkgA/1.0.0)' requires 'PkgC/3.1.0@dev/dev'.
    To fix this conflict you need to override the package 'PkgC' in your root package.
```
    
To fix this issue we found that we had to completely rebuild PkgB against the new PkgC component and create a new PkgB/3.1.0 package, despite the changes to PkgC being entirely binary compatible. To release these components, the PkgB component version would have to increase for no reason.

Is there a simple way to override PkgB's dependency on PkgC through the PkgA component, so the PkgB component does not need updating?

Thank you.

- [*] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: keithrob91
issue_8693: state: open
title: [question] "inheriting" dynamic options of dependencies (requires)?
body: Hi,

we have the following scenario:

ModuleA:
- a **lot** of options how this can be configured
- options may vary between different versions of ModuleA
- we want to dynamically set the "options = { ... }" for the conanfile.py, parsed from a file inside the ModuleA's .git repository

ModuleB
- we want to have the **same** options declared here as for ModuleA

ModuleC, ModuleD, ModuleE ....
- repeats regarding the options

A <- B <- C <- D .....

The problem is that the options dictionary is populated during "conan export" and the other modules besides ModuleA do not have direct access to the moduleA.git:some_file.json where the options can be parsed from.

Is there any way for a conanfile.py to "query" the options dictionary of a Conan package it "requires"?
If this is possible is it possible to use the RREV of the ModuleA in conjunction?


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: iiknd
issue_8684: state: open
title: [feature] conan lock extract-profiles
body: In experimenting with workflows surrounding lockfiles, and in slack conversations several users have expressed interest or need in extracting the profile string from a lockfile for various purposes.  For example, creating new lockfiles from scratch for related packages.  So, the request is for something like:

`conan lock extract-profiles <host_profile_name> <build_profile_name>`

Since this feature seem relatively trivial and low risk to implement, it seems reasonable to add support for it now.  It does seem like the kind of feature which provides a good building block for adding flexibility to the existing lockfile featureset. 

Alternative to: https://github.com/conan-io/conan/issues/8580

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: solvingj
issue_8681: state: open
title: [feature] Add build policy: missing prefer release
body: <!-- What is your suggestion? Please be as specific as possible! -->

Please add a new build policy or something similar:
--build=missing_prefer_release

Almost no packages if any are available for RelWithDebInfo.
For third party packages I don't need the debug information and I don't wish to compile those for RelWithDebInfo.
If this option was available this would definitely assist us with our development flow... 

In case prebuilt is available for RelWithDebInfo use the prebuilt,
But if not this policy should try taking the Release and only if both aren't available should build from source.  

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: orgroman-cg
issue_8680: state: open
title: [bug] Reuploading package to another remote while original remote disabled causes an error
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 (also applicable to linux)
  * Compiler+version: MSVC 16
  * Conan version: 1.34.1
  * Python version: 3.8.5

### Steps to reproduce (Include if Applicable)
1. Download (conan install) some package from any remote (for example from conan-center)
2. Disable that remote
3. Upload the package to your custom remote
4. Error

### Logs (Executed commands with output) (Include/Attach if Applicable)
> ERROR: \<package\>: Upload recipe to '\<my remote\>' failed: Remote '\<original remote\>' is disabled

user: xahon
issue_8674: state: open
title: [question] Conan workspace without specifying versions of editables or using wildcards?
body: Is it possible to use the Conan workspace without specifying versions of editables or using wildcards for versions? I don't want to bump versions workspace yml each time when I bump versions in my editables. 

Something like

```
editables:
    say:
        path: say
    hello:
        path: hello
    chat:
        path: chat
layout: layout_gcc
workspace_generator: cmake
root: chat
```

Is it supported somehow?

Thanks


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Ambrase
issue_8663: state: open
title: [bug] 'conan download' fails when recipe has a py_requires
body: I want to download a recipe only (without caring about configuration settings or dependencies).  But after download, conan fails because a `py_require` is not in the local cache.

Any workaround would also be appreciated.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 (64-bit)
  * Compiler+version: n/a
  * Conan version: 1.34.1
  * Python version: 1.37

### Steps to reproduce (Include if Applicable)
`conan download libb/0.1@user/channel#rrev-r conan-tmp --recipe`

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
Downloading conanmanifest.txt

Downloading conanfile.py

Downloading conan_export.tgz

ERROR: Error loading conanfile at 'C:\Jenkins\job\workspace\.conan\data\libb\0.1\user\channel\export\conanfile.py': Version range '~1' from requirement 'my_py_requires/[~1]@user/channel' required by 'py_require' could not be resolved in local cache

script returned exit code 1
```
user: GordonJess
issue_8661: state: open
title: [question] Working with multiple packages in a repository with External Sources. 
body: Hi 
We from disroop are having multiple Conan packages in one repository. With Conan-Workspace or Conan-Editable were are able to work simultaneously on multiple Conan Packages at once but we hit the limit when we are dealing with external source code in a conanfile.py. An example would be I am using Conan source function to get external .cpp and .hpp files from a repository and I add an internal CMakeLists.txt file to build those sources. The current solution is to export all those packages with external sources and then using Conan workspace install. Afterwards to build the application we are using pure CMake commands. Which are well supported by the most popular IDEs. Here we are facing another problem with our approach the compile-commands.json which is generated by the top workspace CMakelist.txt doesn't include the pre-exported packages. The compile-commands.json file is used by the IDE for code completion.  It would be nice if we could work on those Conan packages with external sources as it would be a "normal" Conan package with internal sources. Is there already a solution for that? Or is something coming in the near future. I already heard you rethink the whole workspace workflow.

- [ X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: mymichu
issue_8652: state: open
title: Meson/gstreamer and crosscompiling 
body: Hi,

We normally use cmake generator, so trying to build gstreamer with conan is a bit of a new avenue.

That being said, native Macos built in a jiffy. But trying to crosscompile to iOS hitting an obstacle right out of the gate: Meson (?) builds a test aarch64 executable (build/meson-private/sanitycheckc.exe), but then tries to run it and obviously fails.

What am I missing? What is the proper way of asking Meson to ... well, not do that.

Tried with both Conan 1.23.0 (currently deployed version) and 1.34.1
user: w3sip
issue_8640: state: open
title: [question] "build_requires" tools from the same package but from different build configuration (settings)?
body: Hi,

the scenario is the following:

The module (.git repository) can be built for different targets (linux, windows, android, iOS, ...). To cross-compile for e.g. android/iOS certain tools are needed from the host build of the same module. So without Conan one builds and installs the module (cmake) first e.g. for Linux and then for android/iOS using the tools from the host-only build.

I tried to search through [cross-building](https://docs.conan.io/en/latest/systems_cross_building/cross_building.html#cross-building) and [build-requirements](https://docs.conan.io/en/latest/devtools/build_requires.html#build-requirements) but didn't find any direct answer so far?

So is it possible to "build_require" the same package but from different settings i.e. from different target build configuration?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: iiknd
issue_8638: state: open
title: [feature] Binary Conan options should be expressed as an `option()` in CMake when generated with CMakeToolchain
body: This is common to have `True`/`False `options in `conanfile.py`. For example:

```python
    options = {
        "build_docs": [True, False]
    }
```

the above is translated by the `CMakeToolchain` to

```cmake
set(UNITS_BUILD_DOCS "True" CACHE STRING "Variable UNITS_BUILD_DOCS conan-toolchain defined")
```

This is seen in a GUI as:

![image](https://user-images.githubusercontent.com/506260/110933671-5c493280-832d-11eb-9926-1396d124d3f3.png)


However, it would be nicer if those would be generated either as:

```cmake
set(UNITS_BUILD_DOCS "True" CACHE BOOL "Variable UNITS_BUILD_DOCS conan-toolchain defined")
```

or

```cmake
option(UNITS_BUILD_DOCS "Variable UNITS_BUILD_DOCS conan-toolchain defined" ON)
```

The new behavior better states the purpose of the option and also improves CMake cache variable presentation in GUIs:

![image](https://user-images.githubusercontent.com/506260/110933876-96b2cf80-832d-11eb-8d4d-443910160a81.png)


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: mpusz
issue_8634: state: open
title: [question] Passing package_id mode downstream & custom direct mode
body: Hi Conan community,

I need some clarification on the package_id concept in case I deviate from semver_direct_mode

Let's assume we have some **app** package which requires a package **libA**, which in turn requires **libB** which again in turn requires **libC**.

If I don't change anything in the conan configuration or **libA**'s package_id method, _semver_direct_mode_ is applied, so ABI compatibility for all minor versions of **libB** is assumed and **libA**'s package_id does only depend on **libB**'s major version, disregarding **libC**'s version. 

Question 0: Is this correct?

---
Problem 1: 

What if **libB** doesn't follow semver (we have this use case in our company)? If I know that **libB** guarantees ABI compatibility for all patch versions, I could set in **libA**'s conanfile:
```
def package_id(self):
    self.info.requires["libB"].minor_mode() 
```

**libA** needs to get the ABI compatibility information somehow. In my example **libA**'s developer must get this information on some other communication channel to implement the the package_id method. It's quite tedious and error prone to keep track and implement this in **libA**'s conanfile in case there are more requirements. From my understanding it would make perfect sense to define the recommended mode in **libB** somehow and automatically apply it in **libA**, but I'm probably missing something.

Question 1: 
Is there any way **libB** can tell its consumers which mode to use / which versions are guaranteed to be ABI compatible (except for following semver)?

---
Problem 2:

Actually, even after overwriting **libB**'s mode in **libA**'s conanfile (see Problem 1), the mode for transitive requirements of **libB** (i.e. **libC**) will not be overwritten causing **libA**'s package_id to possibly change if **libB** changes its requirements (depending on the default package_id_mode of course), even if this was guaranteed to be ABI compatible (otherwise **libB** would increment its version). And I do not want to set **libC**'s mode in **libA**'s conanfile which doesn't even explicitly require **libC**.

I quite like the behavior of the semver_direct_mode in respect to ignoring sub-requirements and assuming they are handled correctly in their respective conanfiles (breaking ABI compatibility with requirements updates will cause an incremented major version). As our regulatory constraints are quite strict, I want to use _package_revision_mode_ as default mode, but only for direct dependencies. I implemented a package_id method with this behavior, I call it _package_revision_direct_mode_. Actually, I think a direct variant would make sense for all modes. I implemented it in **libA**'s package_id method:
```
def package_id(self):
    for dep in self.info.requires.pkg_names:
        if self.info.requires[dep]._indirect:
            self.info.requires[dep].unrelated_mode()
        else:
            self.info.requires[dep].package_revision_mode()
    # referencing problem 1, I might overwrite specific requirements' modes.
    self.info.requires["libB"].minor_mode()
```

That is not clean as I use a private attribute of the RequirementsInfo object and I cannot set this behavior as default in my conan.conf, so all Conan packages in my company must implement it in their conanfiles. 

Feature proposal:
I thought of handling "direct" as a parameter to each mode (like `package_revision_mode(direct=True)`), but I guess this would conflict with the syntax of the conan.conf and envvar settings at the current state.

Question 2:
Does this make sense or am I completely off track? Our internal packages don't follow semver, so I definitely need to alter the default behavior, but I still want my **app** to use any binary of **libA** which was built with the same minor, but different patch versions of **libB** respectively, without needing to rebuild **libA**.

Sorry for all the text, but I guess ABI compatibility is quite a complicated issue :)
I hope this makes sense to you and you can give me some hints. Thanks in advance!

Regards
Dom

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: domfellner
issue_8628: state: open
title: [question] libftdi1 issues loading dylib
body: Hey guys,

Sorry if this was asked several times but I read all examples and conan documentation but still haven't figured out how to fix this.

I am running conan 1.34.0 on MacOSX and working on an application for which I would like to consume libftdi. In the conan center unfortunately the version is rather old [(0.20)](https://conan.io/center/libftdi).

I am trying to create a package using [libftdi1](https://www.intra2net.com/en/developer/libftdi/download.php).
Following the recipe for the version 0.20 and the conan documentation on creating packages I managed to compile and create the package in my local cache. This is the package recipe.

```
from conans import ConanFile, CMake, tools
import os

class LibFtdi1Conan(ConanFile):
    name = "libftdi1"
    description = "libFTDI - FTDI USB driver with bitbang mode"
    url = "https://www.intra2net.com/en/developer/libftdi/download/libftdi1-1.5.tar.bz2"
    license = "LGPL-2.0"
    version = "1.5"
    exports_sources = "CMakeLists.txt", "patches/**"
    settings = "os", "arch", "compiler", "build_type"
    options = {
        "shared": [True, False],
        "fPIC": [True, False],
        "enable_cpp_wrapper": [True, False],
    }
    default_options = {
        "shared": True,
        "fPIC": True,
        "enable_cpp_wrapper": False,
    }
    generators = "cmake", "cmake_find_package"
    source_subfolder = "libftdi1-{}".format(version)

    _cmake = None

    def config_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def configure(self):
        if self.options.shared:
            del self.options.fPIC
        if not self.options.enable_cpp_wrapper:
            del self.settings.compiler.libcxx
            del self.settings.compiler.cppstd

    def source(self):
        tools.get(self.url)

    def requirements(self):
        self.requires("libusb/1.0.24")
        self.requires("libconfuse/3.3")

        if self.options.enable_cpp_wrapper:
            self.requires("boost/1.75.0")

    def _configure_cmake(self):
        if self._cmake:
            return self._cmake
        self._cmake = CMake(self)
        self._cmake.definitions["FTDIPP"] = self.options.enable_cpp_wrapper
        self._cmake.definitions["PYTHON_BINDINGS"] = False
        self._cmake.definitions["EXAMPLES"] = False
        self._cmake.definitions["DOCUMENTATION"] = False
        self._cmake.configure(source_dir=self.source_subfolder)
        return self._cmake

    def _patch_sources(self):
        tools.replace_in_file(os.path.join(self.source_subfolder, "CMakeLists.txt"), "CMAKE_BINARY_DIR", "PROJECT_BINARY_DIR")
        tools.replace_in_file(os.path.join(self.source_subfolder, "CMakeLists.txt"), "CMAKE_SOURCE_DIR", "PROJECT_SOURCE_DIR")
        tools.replace_in_file(os.path.join(self.source_subfolder, "ftdipp", "CMakeLists.txt"), "CMAKE_SOURCE_DIR", "PROJECT_SOURCE_DIR")

        # Patching files for proper build with conan
        find_confuse_pkg_file = "./" + self.source_subfolder + "/cmake/FindConfuse.cmake"
        find_usb1_pkg_file = "./" + self.source_subfolder + "/cmake/FindUSB1.cmake"
        os.remove(find_confuse_pkg_file)
        os.remove(find_usb1_pkg_file)
        os.rename("./Findlibconfuse.cmake", find_confuse_pkg_file)
        os.rename("./Findlibusb.cmake", find_usb1_pkg_file)
        tools.replace_in_file(os.path.join(self.source_subfolder, "CMakeLists.txt"), "project(libftdi1 C)",
                              '''project(libftdi1 C)
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()''')
        tools.replace_in_file(os.path.join(self.source_subfolder, "src","CMakeLists.txt"), "target_link_libraries(ftdi1 ${LIBUSB_LIBRARIES})",
                              '''target_link_libraries(ftdi1 ${LIBUSB_LIBRARIES} ${CONAN_LIBS})''')

    def build(self):
        self._patch_sources()
        cmake = self._configure_cmake()
        cmake.build()

    def package(self):
        self.copy(pattern="COPYING*", src=self.source_subfolder, dst="licenses")
        cmake = self._configure_cmake()
        cmake.install()

        tools.rmdir(os.path.join(self.package_folder, "lib", "pkgconfig"))

    def package_info(self):
        if self.options.enable_cpp_wrapper:
            self.cpp_info.libs.append("ftdipp1")
        self.cpp_info.libs.append("ftdi1")
```

The application also builds fine, this is my conanfile:

```
from conans import ConanFile, CMake

class ExampleConan(ConanFile):
  settings = ('os', 'compiler', 'build_type', 'arch')
  requires = (
    'gtest/1.8.1@bincrafters/stable',
    'libftdi1/1.5@build/testing'
  )
  generators = 'cmake'

  def build(self):
    cmake = CMake(self)
    cmake.verbose = True
    cmake.configure()
    cmake.build()

  def imports(self):
    self.copy('*.dll', src='bin', dst='bin')
    self.copy('*.dylib*', src='lib', dst='lib')
    self.copy('*.so', src='lib', dst='lib')
```

Unfortunately, when I try to run the binary I receive the following error:

> dyld: Library not loaded: libftdi1.2.dylib

I know I am probably messing up with rpaths and dynamic linkage. If I inspect the binary with otool I get:

>otool -L bin/UnitTests
>bin/UnitTests:
>        **libftdi1**.2.dylib (compatibility version 2.0.0, current version 2.5.0)
>        /Users/miname/.conan/data/libpq/11.5/_/_/package/629b9f80b519063e4c405aab7332f604318faa5b/lib/**libpq**.5.dylib (compatibility version 5.0.0, current version 5.11.0)
>        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
>       ...

From this I see that libpq, another library that my application depends on and that I **do not** build myself, points to the library in my local conan cache; libftdi1 on the other hand, that I build myself, does not contain the full path to the dylib.

Apparently the issue is already present when I build the conan package myself for libftdi1; if I build libftdi1 examples I get the same problem on the dynamic library linkage. The vanilla libftdi1 repo is not meant to be built with conan so I am perhaps missing something in the integration conan - cmake. I read all the documentation I could but I am running out of ideas. Could someone help?
user: matte86
issue_8626: state: open
title: [feature] Packageable pip installable Python venv based utilities
body: <!-- What is your suggestion? Please be as specific as possible! -->

## Description

What if Conan had the capability to capture/package pip installable python utilities (e.g. Sphinx) or thunked scripts and turn them into a package a project could `build_requires` for use during builds?

My coworker @puetzk has developed a couple nifty little utility packages that allows us to do just that.

Would there be any interest in adding first class support for such a capability in Conan? Maybe under `conan.tools.*` ?

It's bending Conan's packaging model a little, but the capability is powerful. Feel free to close the issue if it's not in alignment with your project goals -- totally understand.

But we're doing something cool, if not a little outside the box, and I figured it'd be worth floating the concept to see what you think.

As always, thanks for all your hard work! Conan is now an integral part of our workflow. And everyone does an amazing job delivering such a high quality tool! Keep up the great work!

## Motivation

One of the unforseen benefits of moving to Conan, has been the mandatory requirement that Python is now a first class prerequisite for most of our C++ projects. This actually gives us greater flexibility in developing build and other utility scripts in Python (instead of bash or bat) for use throughout our build process.

But sometimes utility scripts depend on other pip packages, etc. How do we share utility scripts and make sure everyone has the right packages installed?

Our solution was to leverage Python virtual environments and package them with Conan.

We started by developing a Python `venv` generator, that would install any pip installable script as a python `venv` inside your build folder using the same version of Python Conan was using -- that way we could ensure you had a Python environment capable of running our utility script.

But this was a little inefficient. It meant that if you had multiple projects depending on the same "python-*" venv utility, you'd install the same utility into multiple build folders. Totally works, but is a little bit heavy.

Is there a way to better leverage Conan to avoid re-creating these packages?

The bit of a "hack" we settled on, was making these Python venv based utility packages to have a `build_policy="missing"`. That way the package was created once, and lives in your Conan cache. Packages binaries are never uploaded / shared, but are built once, locally, on a given developer's machine and can then be re-used across projects.

* Pros
    ✔️ Easy create a package from a pip installable library or tool
    ✔️ Easy to create a package from a python utility script (for problems that can't easily be solved in CMake)
* Cons
    ❌ Package binaries can't be uploaded because it depends on creating a Python venv locally in your build cache.
    ❌ Obviously, uninstalling Python (perhaps because you're upgrading to a newer version), could break existing venvs packages sitting in your package cache built against an older version.

But for us, the benefits far outweighed the cons.

We've developed python packages for Sphinx, for processing a custom InnoSetup style template (git ignore style pattern matching for matching Conan dependencies and creating InnoSetup install rules), generating WinSparkle style appcast snippets (including DSA signature checks over our binaries, etc.). If you can write it in Python, you can get at it from Conan.

And again, each of these utility scripts likely depends on a variety of Python packages/libraries that need pip installed, but these venv packages handle all the dependency mess in a convenient way.


## Example

For example, my project uses [Sphinx](https://www.sphinx-doc.org/en/master/) to build our documentation.

In my `conanfile.py`, I have the following:
```python
    build_requires = (
        ...
        "python-sphinx/3.2.1@user/channel",
        ...
    )
```

And our package has a `Modules/python-sphinx-config.cmake`, which helps CMake find `sphinx-build` relative to its `package_folder`.

```cmake
cmake_minimum_required(VERSION 3.12)

if(NOT TARGET python3::sphinx-build)
    add_executable(python3::sphinx-build IMPORTED)
    set_target_properties(python3::sphinx-build PROPERTIES
		IMPORTED_LOCATION "${CMAKE_CURRENT_LIST_DIR}/../bin/sphinx-build.exe"
	)
endif()

if(NOT TARGET python3::sphinx-apidoc)
    add_executable(python3::sphinx-apidoc IMPORTED)
    set_target_properties(python3::sphinx-apidoc PROPERTIES
		IMPORTED_LOCATION "${CMAKE_CURRENT_LIST_DIR}/../bin/sphinx-apidoc.exe"
	)
endif()

if(NOT TARGET python3::sphinx-autogen)
    add_executable(python3::sphinx-autogen IMPORTED)
    set_target_properties(python3::sphinx-autogen PROPERTIES
		IMPORTED_LOCATION "${CMAKE_CURRENT_LIST_DIR}/../bin/sphinx-autogen.exe"
	)
endif()

if(NOT TARGET python3::sphinx-quickstart)
    add_executable(python3::sphinx-quickstart IMPORTED)
    set_target_properties(python3::sphinx-quickstart PROPERTIES
		IMPORTED_LOCATION "${CMAKE_CURRENT_LIST_DIR}/../bin/sphinx-quickstart.exe"
	)
endif()
```

So that way from my `CMakeLists.txt`, I can reference the target `python3::sphinx-build` in custom commands, etc. to build my documentation. 

```cmake
add_custom_command(
	...
	COMMAND python3::sphinx-build # ${python3::sphinx-build}
	${_args_SOURCEDIR}
	...
)
```

No need to install sphinx manually. I just add the conan package reference. And everything "magically" works.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: thorntonryan
issue_8623: state: open
title: Android compiler.libcxx=c++_shared not respected
body: **_Updated, actually issue is different than described here before_**
This is happening when cross building for android from windows using android.toolchain.cmake as per recommended way of building android and also when building using existing ndk toolchain : https://docs.conan.io/en/latest/integrations/cross_platform/android.html#using-existing-ndk approach

When building with android.toolchain.cmake ANDROID_STL is not set and examples doesn't specify to set it and profile compiler.libcxx attribute is ignored all together, resulting c++_static ( -static-libstdc++) being used, which is not what is specified in profile.

When building using existing ndk example and not android toolchain compiler.libcxx=c++_shared is also ignored and static flags are used instead.

Even though on both occasions, conan itself outputs:
-- Conan: C++ stdlib: c++_shared
Yet if I manually output all the flags my self , you'll see this (rest of the flags are truncated)
-- Linker flags: -static-libstdc++

And this is snipped from android.toolchain.cmake

```
elseif(ANDROID_STL STREQUAL c++_static)
  list(APPEND ANDROID_LINKER_FLAGS "-static-libstdc++")
elseif(ANDROID_STL STREQUAL c++_shared)
elseif(ANDROID_STL STREQUAL none)
  list(APPEND ANDROID_COMPILER_FLAGS_CXX "-nostdinc++")
  list(APPEND ANDROID_LINKER_FLAGS "-nostdlib++")
else()
```

There should be no flag used with c++_shared

Here is android documentation just for reference
https://developer.android.com/ndk/guides/cmake#android_stl

user: at185190
issue_8615: state: open
title: Support detection/configuration of intel oneAPI compilers on Mac OS
body: The intel compilers are now free with the oneAPI download.
Trying to create a conan configuration on my mac failed and I have no idea on how to get around the problem.
Would it be possible to correctly support this configuration?
```bash
michel@Michels-MacBook-Pro cmake-intel % export CC=icc
michel@Michels-MacBook-Pro cmake-intel % export CXX=icpc
michel@Michels-MacBook-Pro cmake-intel % conan profile new intel --detect
CC and CXX: icc, icpc 
ERROR: Not able to automatically detect 'icc' version
ERROR: Unable to find a working compiler
Profile created with detected settings: /Users/michel/.conan/profiles/intel

michel@Michels-MacBook-Pro cmake-intel % icc --version
icc (ICC) 2021.1 Beta 20201112
Copyright (C) 1985-2020 Intel Corporation.  All rights reserved.

```

user: FunMiles
issue_8591: state: open
title: [feature] tools.PkgConfig should honor $PKG_CONFIG.
body: (My Version Info: Conan 1.33, pip-installed on Debian unstable)

Many thanks for providing conan! I might have a suggestion how to improve the tools.PkgConfig integration, as it is currently not behaving as expected-by-convention: It is ignoring the PKG_CONFIG env…

The autotools documentation mentions this in [1] that one can specify the pkg-config tool to be used by setting env PKG_CONFIG. It's also mentioned in the manpage of pkg-config (autotools macro section). Also, cmake mentions it in
[2] and my experiments shows that indeed autotools and cmake honors it. Calling ./configure, on projects needing it, without pkg-config being present tells you to set PKG_CONFIG to point to the executable [3].

Unfortunately conan's tools.PkgConfig does not honor it; so the "wrong" pkg-config will be called. Of course, tools.PkgConfig can be hinted explicitly, but this is cumbersome to do so in every recipe if not using the documented PKG_CONFIG way.

My use case: I'm running into a pkg-config bug [4]  Until that one is fixed, I need a local wrapper to work around the problem and the script is provided by an conan package and overrides the default pkg-config (but still needs to call it.)

This would make it more easy to check other pkg-config implementations, e.g pkgconf (which did not help with my issue, as it has the same issue [5]…)

[1] https://autotools.io/pkgconfig/cross-compiling.html  -- Section 5.2. Tool Calling Conventions
Quote:  "This is supported by the autoconf macros provided by the package, as they all respect $PKG_CONFIG if set in the environment,"
[2] https://cmake.org/cmake/help/latest/module/FindPkgConfig.html#variables-affecting-behavior
Quote: The PKG_CONFIG environment variable can be used as a hint.
[3] https://autotools.io/pkgconfig/pkg_check_modules.html -- see the example output in 3.4. Optional Modules section or
     another IRL example at https://bugs.debian.org/528169
[4] https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/52
[5] https://github.com/pkgconf/pkgconf/issues/213

user: coldtobi
issue_8590: state: open
title: [question] Using conan create and cmake on a subfolder
body: I have a project where we have the releasable code and test code in a single project/repo but package and distribute the main libraries and the test libraries separately. The test libraries are used by tests in downstream projects. For example:

* projectA/
  * include/
  * src/
  * tests/
    * include/
    * src/
    * conanfile.py
    * CMakeLists.txt
  * conanfile.py
  * CMakeLists.txt
* projectB/
  * include/
  * src/
  * tests/
    * include/
    * src/
    * conanfile.py
    * CMakeLists.txt
  * conanfile.py
  * CMakeLists.txt

In the above setup, you would end up with dependencies such as:
* test_A
  * libTestA
    * libA
* test_B
  * libTestB
    * libTestA
      * libA
    * libB
      * libA

The projectX/CMakeLists.txt does not use projectX/tests/CMakeLists.txt so that the tests build independently of the top-level libraries. To build & run the tests, the top-level libraries have to be built & installed first.

I can use conan create to make the top-level packages (libA and libB), which is nice because it means that --build=missing will work. However, I can't get conan create to work to build libTestA (or libTestB). I can use the conan commands (conan install, conan build, etc) and everything will build so it seems like when I manually run the commands I'm doing something different from what conan create does. Because the files are together in the repo, the source step clones all the files (I'm using the scm attribute), even though I don't need the top-level project files, which I'm okay with... but it looks like conan then builds using the top-level project CMakeLists.txt and not the tests/CMakeLists.txt file. I'm using the CMake build helper in the conanfile to do the build.

I've tried a few different things with no luck:
- os.chdir into the tests folder before I call CMake::configure
  - I change into the directory but it seems like the helper still uses the top-level CMakeLists.txt (as this is self.source_folder)
- Specify the source_folder in the CMake::configure call
  - I get a CMake error "... prefixed in the build directory" presumably cause the conan build_folder is the parent to source_folder
- Specify the source_folder and build_folder in the CMake::configure call
  - conan_paths.cmake is not found (I'm using the cmake_paths generator) since it's sitting at the top-level and the tests/CMakeLists.txt file expects it to in CMAKE_CURRENT_BINARY_DIR.

Any thoughts?


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: nichmj01
issue_8587: state: open
title: [question] Fall back dependencies
body: **Short**: I am looking for a proper way to have a primary and a secondary dependency. In the way that if primary is not there, then use secondary.

**Long**:
Our product consists of tree parts: Foo, Zum and Baz. Each with sources in its own git repo.
Zum and Baz, are libraries used by Foo.

When a either Zum, Baz and Foo is build from main branch, they are uploaded to stable channel.
When build from some feature branch, they are uploaded to the experimental channel.
( we do have other branches and channels, but let's keep it simple here)

So far a pretty common setup i think.

When I do development. I branch out on an feature branch, let's say feature/greatThing, So far no issue.
But often the work on a feature includes more than just the library or the main program.

So let's say that my greatThing involves changes to Foo and Baz, but not Zum
I created feature branches of same name in both Foo and Baz repos.

When I build Foo it must require the latest Baz build from my feature branch and latest Zum build from stable 

I could take the tedious job of changing the conan file for Foo on the feature branch, and pray that I never forget to change it back when merging into stable.

But I would like to automate this, And was considering using the channels for this, thus making a channel for each feature, (easily done I would just reuse the branch name) 
So now my Foo should require `Baz/[>0]@user/greatThing` and `Zum[>0]@user/stable`

To do this automatically Foo somehow needs to know if Baz or Zum is available on the `greatThing` channel and if not require latest from stable.

I created this ugly hack.
``` python
    def requirements(self):
        mybuf = StringIO()
        self.run('conan search baz/*@user/greatThing --raw -r all', output=mybuf)
        if 'baz' in mybuf.getvalue() :
            self.requires( "baz/[>0, include_prerelease=True]@user/greatThing")
        else :
            self.requires( "baz/[>0, include_prerelease=True]@User/stable")

```
*In this example `greatThing` is hardcoded, in real code it is a variable, but I like to KISS. ;-)

**So now my question:** Is this a missing feature in Conan, or is there another/better way to achieve the same?



- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: DdOtzen
issue_8584: state: open
title: [bug] smc field is accessed before requirements are resolved in conan 1.34
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: any
  * Compiler+version: any
  * Conan version: 1.34.0
  * Python version: any

### Steps to reproduce (Include if Applicable)
Hi,
in some of our older conanfiles we used to calculate the scm property with the help of a build_requires recipe.
```python
class Recipe(ConanFile):
    ...
    _scm = None
    @property
    def scm(self):
        if not self._scm:
            self._scm = ... # import and call python method exported by SCMExtension to get scm the scm info
        return self._scm

    def build_requirements(self):
        self.build_requires("SCMExtension/1.0.0@user/stable")
```
Now this is something conan can do by its own now and is not needed anymore. Or could be done with python_requires.

However with #8377 the scm property is accessed before the build_requirements are resolved. The problem we have is that the mentioned recipe is old but used in many other recipes as requirement. As a result this change breaks all those recipes and they can't be built as this also affects transitive dependencies.

Please let me know what you think about it and if it would be possible to call resolve the requirements beforehand as they are resolved in the conan info anyway (but at a later time).



user: sorekz
issue_8570: state: open
title: [feature] post_install command hook
body: <!-- What is your suggestion? Please be as specific as possible! -->

Hi. The only hook that I have thought would be useful to me is a `post_install` for example:
1. I would be able to remove my project's CMakeCache.txt file or run `cmake --build . --target clean` after a `conan install`
2. I would be able to update my code editor's include directory paths

So I was wondering:
- Is it possible to add custom hooks or to achieve what I want through other methods?
- If not I would like to request a `post_install` hook.

Edit: To clarify, I need to add some commands to be run after install is done for DevOps purposes.

The workflow is as follows:
- Developer locally modifies a dependency and exports the package to local cache
- Developer then re-runs conan install on the consuming project
- Developer then needs to remove CMakeCache.txt and update their IDE's include paths because the paths have changed

This is definitely not a crucial problem. But it would be nice to be able to manage this step with Conan as well if possible.

[✓] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: daravi
issue_8565: state: open
title: [question] query source of setting/option value
body: Hi there,
is it possible to determine the source of a specific recipe option or setting.
My library uses Boost. And the user can specifiy through profiles/commandline that Boost is used as header-only or linked as binary (e.g. -o boost:header_only=True).

My library preferres to use Boost as ```header_only```. As the library can be compiled for several targets. Those targets can be quite old where ```boost:header_only``` is not possible and Boost has to be linked through binaries.

Normally the ```boost:header_only``` option is not set explicitly. In this case I want to be able to set the ```boost:header_only``` based on the employed compiler.

Question
----------
How can I detect where the value of a specific option has been set?
- default value
- profile
- command line
- ...

At the moment it would suffice if I could determine if the value has been set by the user or if it is the default value.
Comparing the current value to the default value is insufficient as the user could specify a value which is the same as the default value.



Best regards
user: Johnnyxy
issue_8564: state: open
title: package_info() and editable mode: components libdirs empty and loss of customization
body: When settings a package in editable mode with a layout file, the libdirs setting is lost components (`cpp_info.components["comp"].libdirs`). Moreover, all the customization on the libdirs in `package_info()` is overwritten by the layout file.

As a user, I would rather have access to the `build_folder`, which resides in the layout file to set as a base path or at least to be able to have access to a `build_folder` attribute that is set to the layout's `build_folder` when the package is in editable mode with a layout defined allowing `package_info()` written like this:
```
def package_info(self):
    [...]
    self.cpp_info.components["comp"].libdirs = [os.path.join(self.build_folder or '', "mylibfolder")]
    [...]
```

Those changes, for example, implement this:
```
diff --git a/conans/client/installer.py b/conans/client/installer.py
index 44dc9faf..e2e58cfc 100644
--- a/conans/client/installer.py
+++ b/conans/client/installer.py
@@ -454,20 +454,25 @@ class BinaryInstaller(object):
         # Get source of information
         package_layout = self._cache.package_layout(node.ref)
         base_path = package_layout.base_folder()
-        self._call_package_info(node.conanfile, package_folder=base_path, ref=node.ref)
+
+        editable_cpp_info = package_layout.editable_cpp_info()
+        if editable_cpp_info:
+            build_folder = editable_cpp_info.folder(node.ref, EditableLayout.BUILD_FOLDER,
+                                                        settings=node.conanfile.settings,
+                                                        options=node.conanfile.options)
+        else:
+            build_folder = None
+
+        self._call_package_info(node.conanfile, package_folder=base_path, ref=node.ref, build_folder=build_folder)

         node.conanfile.cpp_info.filter_empty = False
         # Try with package-provided file
-        editable_cpp_info = package_layout.editable_cpp_info()
         if editable_cpp_info:
             editable_cpp_info.apply_to(node.ref,
                                        node.conanfile.cpp_info,
                                        settings=node.conanfile.settings,
                                        options=node.conanfile.options)

-            build_folder = editable_cpp_info.folder(node.ref, EditableLayout.BUILD_FOLDER,
-                                                    settings=node.conanfile.settings,
-                                                    options=node.conanfile.options)
             if build_folder is not None:
                 build_folder = os.path.join(base_path, build_folder)
                 output = node.conanfile.output
@@ -606,7 +611,7 @@ class BinaryInstaller(object):
         subtree_libnames = [node.ref.name for node in node_order]
         add_env_conaninfo(conan_file, subtree_libnames)

-    def _call_package_info(self, conanfile, package_folder, ref):
+    def _call_package_info(self, conanfile, package_folder, ref, build_folder=None):
         conanfile.cpp_info = CppInfo(conanfile.name, package_folder)
         conanfile.cpp_info.version = conanfile.version
         conanfile.cpp_info.description = conanfile.description
@@ -626,8 +631,9 @@ class BinaryInstaller(object):
                 with conanfile_exception_formatter(str(conanfile), "package_info"):
                     conanfile.layout.set_base_package_folder(package_folder)
                     conanfile.layout.set_base_source_folder(None)
-                    conanfile.layout.set_base_build_folder(None)
+                    conanfile.layout.set_base_build_folder(build_folder)
                     conanfile.layout.set_base_install_folder(None)
+
                     self._hook_manager.execute("pre_package_info", conanfile=conanfile,
                                                reference=ref)
                     conanfile.package_info()
```

user: ericjulien
issue_8561: state: open
title: [question] private vs public requirement 
body: Hello,

I use conan to build a **windows** application, and I have a confusion regarding private conan requirement, are they analogic to cmake private linking?

Here is the situation: 
* Tensorflow and zlib are shared library 
* MyLib links tensorflow and zlib privatetly ( Final application must not link them )
* Mylib is a conan package package that create multiple libraries. 

Now the challenge:

### If I define zlib and tensorflow as public conan requirements
The linking information will propagate to `Final application` and I ended up with my `Final application` linking both Tensorflow and zlib which I dont want to.

### If I define zlib and tensorflow as private conan requirements
The linking information will not propagate to `Final application` which is the appropriate behavior. **However** `Final application` does not know about Tensorflow and zlib anymore but they are still needed as we need the DLLs as runtime deps.
 
Any suggestion how to fix this ? 


![image](https://user-images.githubusercontent.com/7117696/109282053-5592c980-781d-11eb-9e8d-9171f71f8c9e.png)


user: boussaffawalid
issue_8555: state: open
title: [bug] g++ clang frontend on Windows (mingw) not supported by CMake build helper
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

In our project we want to use the clang compiler with g++ front end on Windows.
My toolchain is based on [llvm-mingw](https://github.com/mstorsjo/llvm-mingw), which I built manually and created a conan package afterwards. This package is then used as build requirement in a new build profile "mingw_clang110_x64" :

```
include(_win_x64)

[settings]
compiler=clang
compiler.version=11
compiler.cppstd=14
compiler.libcxx=libc++
compiler.runtime=MD
compiler.driver=g++

[env]
CC=clang.exe
CFLAGS= --target=x86_64-pc-windows-gnu
CXX=clang++.exe
CXXFLAGS= --target=x86_64-pc-windows-gnu -std=c++14 -stdlib=libc++ -lc++abi
RC=windres.exe

CONAN_MAKE_PROGRAM=ninja
CONAN_CMAKE_GENERATOR="Ninja"

[build_requires]
ninja/1.10.2@local/testing
llvm-mingw/11.0.0@local/testing
```

Please note that we prefer packaged tools over locally installed tools. This is the reason why we have the "ninja" and "llvm-mingw" packages here.

So far this approach went very well. But on your CI server I've got a ConanException at `cmake.configure()` in the build method of conanfile.py in any module I want to build.

```
    def build(self):
        cmake = conans.CMake(self)
        cmake.configure()
        cmake.build()
```

After a search in the Internet and a look into the conan sources, I figured out that the [CMake class](https://github.com/conan-io/conan/blob/develop/conans/client/build/cmake.py) tries to open a vc shell if clang is detected. (This matches the difference between my development computer and the CI server, where I don't have Visual Studio installed.)

The root cause of this problem is the clang detection in the CMake class, which does not take into account, that clang can be used with mingw too. In this case the front end is g++ and the vc shell is not needed.

To solve this issue, one can utilize the "driver" setting introduced by https://github.com/conan-io/conan/pull/5705.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10, 64 bit
  * Compiler+version: clang 11.0 [llvm-mingw](https://github.com/mstorsjo/llvm-mingw)
  * Conan version: 1.16.1 (all versions from 1.16.1 to the latest are affected)
  * Python version: 3.7.2

### Steps to reproduce (Include if Applicable)
call `conan create . user/channel -pr mingw_clang110_x64`

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

> ERROR: SomeModule/1.0.0@user/channel: Error in build() method, line xx
> cmake.configure()
> ConanException: compiler.version setting required for vcvars not defined

user: mbeier21
labels: component: Build: Build helpers, build systems..
issue_8549: state: open
title: [bug] conan export gets confused by nested symlinks-to-dirs
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 16.04
  * Conan version: develop (2020-02-24), but also 1.33.0
  * Python version: 3.6.8

### Steps to reproduce
Create a conanfile.py with an `exports_sources` attribute (it doesn't actually matter what is exported).

Here's the tricky bit: attempt to create a directory and symlink to that directory so that `ls -U` orders the symlink _before_ the directory:
```
mkdir dir1
ln -s dir1 symlink1
ls -U
```
If the `ls -U` command lists `dir1` before `symlink1`, delete them and try again.

Put another symlink-dir pair inside `dir1`:
```
mkdir dir1/dir2
ln -s dir2 dir1/symlink2
```

Now run `conan export . test/test`.

### Logs (Executed commands with output)

```
> conan export . test/test
Exporting package recipe
crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50@test/test exports_sources: Copied 3 '.patch' files: breakpad-includes.patch, crashpad-crypto-link-order.patch, mini_chromium-windows-crt.patch
ERROR: The file is a broken symlink, verify that you are packaging the needed destination files: '/home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/a_symlink'.You can skip this check adjusting the 'general.skip_broken_symlinks_check' at the conan.conf file.
```

I added some extra debug to conan to make it clearer what's going on:

```
> conan export . test/test
Exporting package recipe
Copying from '/local/amerry/conan/conan-crashpad/' to '/home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/'
Files: ['breakpad-includes.patch'], links: ['a_symlink', 'dir2/symlink2']
Keeping /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/a_symlink which points to /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/dir1
discarding /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/dir1/symlink2 because /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/dir1/dir2 does not exist
Copying from '/local/amerry/conan/conan-crashpad/' to '/home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/'
Files: ['crashpad-crypto-link-order.patch'], links: ['a_symlink', 'dir2/symlink2']
Keeping /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/a_symlink which points to /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/dir1
discarding /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/dir1/symlink2 because /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/dir1/dir2 does not exist
Copying from '/local/amerry/conan/conan-crashpad/' to '/home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/'
Files: ['mini_chromium-windows-crt.patch'], links: ['a_symlink', 'dir2/symlink2']
Keeping /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/a_symlink which points to /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/dir1
discarding /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/dir1/symlink2 because /home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/dir1/dir2 does not exist
crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50@test/test exports_sources: Copied 3 '.patch' files: breakpad-includes.patch, crashpad-crypto-link-order.patch, mini_chromium-windows-crt.patch
ERROR: The file is a broken symlink, verify that you are packaging the needed destination files: '/home/amerry/.conan/data/crashpad/adf40ba77cd633257e3957b6671e70cc1e0a0c50/test/test/export_source/a_symlink'.You can skip this check adjusting the 'general.skip_broken_symlinks_check' at the conan.conf file.
```
user: amerry
issue_8545: state: open
title: [bug] activate.sh doesn't set environment variables correctly
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Debian 10 x86_64 GNU/Linux 
  * Compiler+version: gcc (Debian 8.3.0-6) 8.3.0
  * Conan version: 1.33.1
  * Python version: 3.7.3

### Steps to reproduce (Include if Applicable)

`activate.sh` sets environment variables under quotes twice.

This is the content of the `environment.sh.env` file:
`mypackagepath="/root/.conan/data/mypackage/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9"`

This is the environment variable after being set by `/bin/sh ./activate.sh` :
`mypackagepath='"/root/.conan/data/mypackage/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9"'`

Due to this quotation, paths can't be accessed. For example: `cd $mypackagepath` doesn't work.
My temporary solution was to remove all quotes in the  `environment.sh.env`  file before I called `activate.sh`


user: armtir
issue_8543: state: open
title: [question] How to disable warnings from headers from dependencies
body: I am using some dependency packages in my project and their headers generate a lot of warnings when compiling with my code.
Is there a way to mark the dependencies' headers as system headers similar to gcc's `-isystem` flag? So that the warnings will be ignored.
user: kakashidinho
issue_8536: state: open
title: [question] cross compile for iOS, first time compile failed, then success.
body: Hi, I am cross compiling for iOS on MacOS Big Sur 11.2.1. My `profile` and `conanfile.py` as fellows:

```
// ios_profile
include(default)

[settings]
os=iOS
os.version=12.0
arch=armv8
compiler=apple-clang
compiler.version=12.0
compiler.libcxx=libc++
build_type=Release

[build_requires]
darwin-toolchain/1.0.8@theodelrieu/stable

[options]
build_framework=True
```

```python
from conans import ConanFile, tools, CMake

class KwaiLoggerConan(ConanFile):
    name = "xxx"
    version = "0.1"
    license = "xxx"
    author = "xxx"
    url = "xxx"
    description = "xxx"
    topics = ("conan")
    settings = "os", "compiler", "build_type", "arch"
    options = {
        "shared": [True, False],
        "fPIC": [True, False],
        "no_crypt": [True, False],
        "build_framework": [True, False],
        "build_sample": [True, False],
    }
    default_options = {
        "shared": True,
        "fPIC": True,
        "no_crypt": False,
        "build_framework": False,
        "build_sample": False,
    }
    generators = "cmake"
    exports_sources = "*"
    requires = ("gtest/1.10.0", "zlib/1.2.11", "zstd/1.4.8")
    build_policy = "missing"

    def configure_options(self):
        if self.settings.os == "Windows":
            del self.options.fPIC

    def configure(self):
        if self.settings.compiler == "Visual Studio":
            del self.settings.compiler.runtime

    def _configure_cmake(self):
        cmake = CMake(self)
        if self.options.no_crypt:
            cmake.definitions["NO_CRYPT"] = "ON"
        else:
            cmake.definitions["NO_CRYPT"] = "OFF"
        if self.options.build_framework:
            cmake.definitions["BUILD_FRAMEWORK"] = "ON"
        else:
            cmake.definitions["BUILD_FRAMEWORK"] = "OFF"
        if self.options.build_sample:
            cmake.definitions["BUILD_SAMPLE"] = "ON"
        else:
            cmake.definitions["BUILD_SAMPLE"] = "OFF"

        cmake.configure(source_folder=".")
        return cmake

    def build(self):
        cmake = self._configure_cmake()
        cmake.build()

    def package(self):
        self.copy("include/*.h", dst=".", keep_path=True)
        self.copy("README.md", dst=".", keep_path=False)
        self.copy("AUTHORS", dst=".", keep_path=False)
        self.copy("samples/cpp/*.cc", dst=".", keep_path=True)
        self.copy("samples/cpp/*.h", dst=".", keep_path=True)
        self.copy("samples/cpp/CMakeLists.txt", dst=".", keep_path=True)
        self.copy("tools/*", dst=".", keep_path=True)
        self.copy("cmake/*", dst=".", keep_path=True)
        self.copy("doc/*", dst=".", keep_path=True)
        self.copy("*.lib", dst="lib", keep_path=False)
        self.copy("*.dll", dst="bin", keep_path=False)
        self.copy("*.so", dst="lib", keep_path=False)
        self.copy("*.dylib", dst="lib", keep_path=False)
        self.copy("*.a", dst="lib", keep_path=False)

    def package_info(self):
        self.cpp_info.includedirs = ["include/kwai"]
        self.cpp_info.libs = ["libklogger"]
```

Then I run `conan install . --profile ios_profile`, After that, the fitst time I run `conan build .`, it failed, if I run build comman second time it success.

I checked the make comman in verbose mode, the first time is:
```
[ 7%] Building CXX object CMakeFiles/klogger.dir/src/logger.cc.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ 
-DKLOGGER_DLL -Dklogger_EXPORTS 
-I/Users/jiabw/.conan/data/gtest/1.10.0///package/a03c78ef2173cd2c0e478a90a61a4b868e6b6880/include 
-I/Users/jiabw/.conan/data/zlib/1.2.11///package/108e68814533f28957889ee7075ad46a8396869
8/include 
-I/Users/jiabw/.conan/data/zstd/1.4.8///package/108e68814533f28957889ee7075ad46a83968698/include 
-I/Users/jiabw/Project/cpp/kwai-logger/include -I/Users/jiabw/Project/cpp/kwai-logger/src 
-I/Users/jiabw/Project/cpp/kwai-logger/build 
-O3 -DNDEBUG -ffunction-sections -fdata-sections 
-fno-rtti -fno-exceptions -fno-asynchronous-unwind-tables 
-fno-unwind-tables -O3 -DNDEBUG 

-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.4.sdk 
-miphoneos-version-min=12.0 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Os -std=gnu++17 
-o CMakeFiles/klogger.dir/src/logger.cc.o 
-c /Users/jiabw/Project/cpp/kwai-logger/src/logger.cc
```

the second is:
```
[ 7%] Building CXX object CMakeFiles/klogger.dir/src/logger.cc.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ 
-DKLOGGER_DLL -Dklogger_EXPORTS 
-I/Users/jiabw/.conan/data/gtest/1.10.0///package/a03c78ef2173cd2c0e478a90a61a4b868e6b6880/include 
-I/Users/jiabw/.conan/data/zlib/1.2.11///package/108e68814533f28957889ee7075ad46a8396869
8/include 
-I/Users/jiabw/.conan/data/zstd/1.4.8///package/108e68814533f28957889ee7075ad46a83968698/include 
-I/Users/jiabw/Project/cpp/kwai-logger/include -I/Users/jiabw/Project/cpp/kwai-logger/src 
-I/Users/jiabw/Project/cpp/kwai-logger/build 
-O3 -DNDEBUG -ffunction-sections -fdata-sections 
-fno-rtti -fno-exceptions -fno-asynchronous-unwind-tables 
-fno-unwind-tables -O3 -DNDEBUG 
-arch arm64 
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.4.sdk 
-miphoneos-version-min=12.0 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Os -std=gnu++17 
-o CMakeFiles/klogger.dir/src/logger.cc.o 
-c /Users/jiabw/Project/cpp/kwai-logger/src/logger.cc

```

We can see that the first time miss `-arch arm64`, I am wandering why the first time I run `conan build` will miss this, and next build will success?


user: jowishu
issue_8531: state: open
title: [feature] 💡Generator for workspaces
body: From workspace discussions in https://github.com/conan-io/tribe/pull/19 was thinking that major setback of workspaces is a lack of custom generator.

Now with new-style generators and python requirements I think it would be fairly easy to add such support to workspaces:
1. Add `python_requires`  field to workspace definition.
2. Add `generators` field in same form as `python_requires_extend`: `<pkg-name>.<ClassName>`. Then conan can just go through that list, instantiate generator with workspace definition and then call `generate()` method (or `generate_workspace`).

This should be enough to start experimenting more.
user: ytimenkov
issue_8523: state: open
title: [bug] Transitive `shared` option is not affecting the package ID (in semver_direct_mode)
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: CentOS 8
  * Compiler+version: Clang 10.0.1
  * Conan version: 1.33.0
  * Python version: 3.8.6

### Steps to reproduce (Include if Applicable)
Create a package with:
```
conan create somepkg:shared=True ...
```

Then try to create the same package as follows:
```
conan create *:shared=True ...
```
The second run returns:
```
The stored package has not changed
```
Due to the package IDs being the same, even though the transitive options are different. (In the first case the requirements have `shared=False`)

### Logs (Executed commands with output) (Include/Attach if Applicable)
Pretty straight forward to test IMO. But if you require more logs please let me know how you prefer I run the test for you.
user: daravi
issue_8522: state: open
title: Transforming existing header-only library into package
body: I'm trying to create a conan package from existing header-only library. It's not your textbook example with include folder. Structure looks as follows:

```
public/SomeHeader.hpp
public/CHeader.h
public/anotherFolder/AnotherHeader.hpp
```

Here is my **conanfile.py** based on [Documentation](https://docs.conan.io/en/latest/howtos/header_only.html#how-to-package-header-only-libraries) and https://github.com/conan-io/conan/issues/4212.

```
from conans import ConanFile

class MyLibConan(ConanFile):
    name = "MyLib"
    version = "1.0"

def package_info(self):
    self.cpp_info.includedirs = ["public", "public/anotherFolder"]

def package(self):
    self.copy("*.hpp", dst="public", keep_path=False)
    self.copy("*.h", dst="public", keep_path=False)
```
Should I use self.copy in package() method or cpp_info.includedirs? What's the difference?

I export package like this, no errors so far

` export . demo/test`

Then in my main project I have **conanfile.txt** as follows:

```
 [requires]
 MyLib/1.0@demo/test

 [generators]
 cmake
```

My **CMakeLists.txt** previously simply linked exec to MyLib (INTERFACE library) 

```
include_directories(MyLibFolder)
add_executable(someTarget ...)
target_link_libraries(someTarget MyLib)
```

now it is modified like this

```
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()
...
add_executable(someTarget ...)
target_link_libraries(someTarget ${CONAN_LIBS})
```

After compiling project

```
mkdir build && cd build
conan install ..
cmake .. -G Ninja
cmake --build .
```

I get errors... :(

```
fatal error: anotherFolder/AnotherHeader.hpp: No such file or directory
#include <anotherFolder/AnotherHeader.hpp>
```

I'm super fresh to conan and I cannot for the love of god grasp how to write conanfile.py. I've tried so many different combinations but without much success. I've read documentation and still no clue!

Thanks in advance,

cheers
user: marcinszumlanski
issue_8488: state: open
title: [bug/question] unable to load cmake modules in cross-compile when using new -pr:b and -pr flags
body: Consider this example: 
[conan-issue-build-profile.zip](https://github.com/conan-io/conan/files/5972324/conan-issue-build-profile.zip)

It contains Conan package `tool`, which provides a tool that will be a build requirement of the project `tool_user` that could be cross-compiled. The `tool` package contains an executable and CMake helper script that should be used by the consumer.

Now, if I don't do cross-compilation, everything works as expected:

```
cd tool
conan create . user/testing
cd ..
mkdir build && cd build
conan install ../tool_user -pr macos-ninja-x64-clang-12.0.0 -g cmake
cmake -GNinja ../conan-issue-build-profile/tool_user
ninja
```

builds as expected.

However, when using the `-pr:b -pr` combination for `conan install`, as it will be mandatory in Conan 2.0, I get the following issue:

```
mkdir build-android && cd build-android
conan install ../tool_user -pr:b macos-ninja-x64-clang-12.0.0 -pr android-ndk-r21d-arm64-v8a -g cmake
cmake -GNinja -DCMAKE_TOOLCHAIN_PATH=/path/to/Android/NDK/r21d/cmake/toolchain ../tool_user
```

CMake fails with:

```
CMake Error at CMakeLists.txt:11 (include):
  include could not find load file:

    helper

CMake Error at CMakeLists.txt:13 (postprocess):
  Unknown CMake command "postprocess".
```

It appears that `helper.cmake`, which is part of the `tool` package is not added to CMake's module search path in generated `conanbuildinfo.cmake`.

This makes it impossible for me to migrate some of our projects using old `arch_build, os_build` settings to new build and host profile mechanism.

Just to be complete, if I rewrite the `conanfile.py` of the `tool` to the "old way" with using `arch_build` and `os_build`: 
[conan-issue-build-profile-old.zip](https://github.com/conan-io/conan/files/5972390/conan-issue-build-profile-old.zip), then it works correctly if I build and install the android version using the following commands:

```
mkdir build-android && cd build-android
conan install ../tool_user -pr android-ndk-r21d-arm64-v8a -g cmake
cmake -GNinja -DCMAKE_TOOLCHAIN_PATH=/path/to/Android/NDK/r21d/cmake/toolchain ../tool_user
ninja
```

Now, since Conan v2.0 is about to deprecate `arch_build` and `os_build` settings, how should I achieve the behaviour of the "old way" using the new build and host profile mechanisms.

### Environment Details (include every applicable attribute)
  * Operating System+version: MacOS BigSur 11.2
  * Compiler+version: Xcode 12.0.0 + Android NDK r21d
  * Conan version: 1.33.1
  * Python version: 3.9

user: DoDoENT
issue_8487: state: open
title: [feature] Arguments --build --build= and --build=* should be the same (Conan 2.0)
body: Running our current Conan version (1.33.1) we have the follow behavior:

Build all packages from source:

    conan install boost/1.75.0@ --build
    [...]
    Packages
    boost/1.75.0:d9d3e501899335bccbe5205508f9a4801424ce7d - Build
    bzip2/1.0.8:da606cf731e334010b0bf6e85a2a6f891b9f36b0 - Build
    libiconv/1.16:6af9cc7cb931c5ad942174fd7838eb655717c709 - Build
    zlib/1.2.11:6af9cc7cb931c5ad942174fd7838eb655717c709 - Build

However, if we pass `--build=` it's an error, because it's considered an empty string:

    conan install boost/1.75.0@ --build=
    [...]
    ERROR: No package matching '' pattern
    Packages
    boost/1.75.0:d9d3e501899335bccbe5205508f9a4801424ce7d - Cache
    bzip2/1.0.8:da606cf731e334010b0bf6e85a2a6f891b9f36b0 - Cache
    libiconv/1.16:6af9cc7cb931c5ad942174fd7838eb655717c709 - Cache
    zlib/1.2.11:6af9cc7cb931c5ad942174fd7838eb655717c709 - Cache

You can say, "of course, we passed '=' but there is no value". But let's see what happens when we have multiple builds. For instance, we want to build zlib and bzip2 from sources:

    conan install boost/1.75.0@ --build=zlib --build=bzip2
    [...]
    Packages
    boost/1.75.0:d9d3e501899335bccbe5205508f9a4801424ce7d - Cache
    bzip2/1.0.8:da606cf731e334010b0bf6e85a2a6f891b9f36b0 - Build
    libiconv/1.16:6af9cc7cb931c5ad942174fd7838eb655717c709 - Cache
    zlib/1.2.11:6af9cc7cb931c5ad942174fd7838eb655717c709 - Build

Next, we pass `--build` + zlib to be built:
Considering it, we can do:

    conan install boost/1.75.0@ --build=!zlib --build=*
    conan install boost/1.75.0@ --build=!zlib --build=
    conan install boost/1.75.0@ --build=!zlib --build

Build all from sources, except zlib. If we don't have zlib built in our cache, an error should be thrown.

Of course, we have the 1.0 stability rule, but I see it more as a hotfix than a feature, because there is an ambiguous parameter.
    conan install boost/1.75.0@ --build=zlib --build
    Packages
    boost/1.75.0:d9d3e501899335bccbe5205508f9a4801424ce7d - Cache
    bzip2/1.0.8:da606cf731e334010b0bf6e85a2a6f891b9f36b0 - Cache
    libiconv/1.16:6af9cc7cb931c5ad942174fd7838eb655717c709 - Cache
    zlib/1.2.11:6af9cc7cb931c5ad942174fd7838eb655717c709 - Build

Only `zlib` is listed to be built, but we asked to build all from sources, it was ignored.


Now if we try to use `--build=`, still is an error:

    conan install boost/1.75.0@ --build=zlib --build=
    ERROR: No package matching '' pattern
    Packages
    boost/1.75.0:d9d3e501899335bccbe5205508f9a4801424ce7d - Cache
    bzip2/1.0.8:da606cf731e334010b0bf6e85a2a6f891b9f36b0 - Cache
    libiconv/1.16:6af9cc7cb931c5ad942174fd7838eb655717c709 - Cache
    zlib/1.2.11:6af9cc7cb931c5ad942174fd7838eb655717c709 - Build


However, as we use `fnmatch` to parse, if we pass `*` as value, we will build all packages and doesn't if another package is listed:

    conan install boost/1.75.0@ --build=zlib --build=*
    [...]
    Packages
    boost/1.75.0:d9d3e501899335bccbe5205508f9a4801424ce7d - Build
    bzip2/1.0.8:da606cf731e334010b0bf6e85a2a6f891b9f36b0 - Build
    libiconv/1.16:6af9cc7cb931c5ad942174fd7838eb655717c709 - Build
    zlib/1.2.11:6af9cc7cb931c5ad942174fd7838eb655717c709 - Build

We should consider an equal rule when building. Both `--build`, `--build=` and `--build=*` should be considered "build all from sources" and doesn't matter if another package is listed, once added to the command line, all packages should be built from sources. To illustrate:

    conan install boost/1.75.0@ --build=zlib --build=*
    conan install boost/1.75.0@ --build=zlib --build=
    conan install boost/1.75.0@ --build=zlib --build
    conan install boost/1.75.0@ --build
    conan install boost/1.75.0@ --build=

Any of these commands will build all packages from sources. I prefer keeping a simplified behavior and avoiding more confusion with this new feature. We have 3 different behaviors for the same parameter (ambiguous).

- [ X ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: uilianries
issue_8479: state: open
title: [feature] Local build policy
body: Hi all. 
It would be nice to have the build policy that for forbids download binary packages from remote. When this policy applied package sources should already be in local cache and if binary missed in local cache then it should be build and can be used later by other packages. 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: euttsov
issue_8464: state: open
title: CMAKE_CXX_STANDARD variables not populated
body: Hi, I have a trivial hello world.
My conanfile.txt is trivial with a cmake generator, I have a cmake with just the
```
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()
```
lines in it, and the minimal cmake project and add_executable directives.
Running conan install generates the conanbuildinfo.cmake, but that does NOT include the CONAN_CMAKE_CXX_STANDARD variables, and hence the C++ standard isn't handled.
I'm using conan 1.32.1
Am I missing something obvious?
user: markfoodyburton
issue_8453: state: open
title: [bug] venv modified vars do not take into account other venvs
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: MSVC2019
  * Conan version: 1.33.1
  * Python version: 3.9.1

If you use multiple venv (such as activate & activate_run) at the same time errors might occur. When generating the venv files conan checks which env vars exists and treats those differently than new variables it will create when activating a venv.

When you activate two venv this assumption does not necessarily hold true, as a var might be new for activate, but when doing activate_run it is modified.

We could move the detection of new vs existing to the venv script itself. This way it does not matter when the venv scripts are generated and when they are run.
user: mjvankampen
issue_8452: state: open
title: [bug] Conan on windows very slow on uploading
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: doesn't matter, we only use export / import feature, don't compile anyway
  * Conan version:1.32.1
  * Python version:3.8.6

### Steps to reproduce (Include if Applicable)

We have around 1GB with 4 large library to export and upload to conan.
Same level of library on linux/macos takes 3 minutes in same network condition.
Windows usually takes 20 minutes. 

I have tried parallel, doesn't help.
Loging didn't really print time sensitive information, the log I saw looks like it was compresing long time and upload in the meanwhile.

However from the task manager level, I can see disk IO, CPU, network all at low level.
It's 32 core 32GB very high speed SSD, why it didn't use all those capabilities? 
It appears using single core doing one thing at a time.



### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: jacobjiangwei
issue_8448: state: open
title: [question] Why does the CMake generator define INTERFACE IMPORTED targets rather than only IMPORTED?
body: My understanding is that INTERFACE targets are for when an actual library file does not exist on disc and you just want to group together and add a logical set of flags, sources, headers etc. in the compile/link process of another target.

However, in some cases the dependencies resolved through Conan do have an actual library file.  And in these cases I might like to know where this library file is stored on disc (in my particular use case I want to extract symbols from it).  For IMPORTED targets I would normally use something like the [IMPORTED_LOCATION property](https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_LOCATION.html) or the `$<TARGET_FILE:tgt>` generator expression, but this is not possible for INTERFACE targets which only support "whitelisted" INTEFRACE_ properties.

Maybe there a reason for this I'm not aware of.  If so, can you suggest any other way I might be able to get the location of these INTERFACE IMPORTED library files?  If not, I'd like to propose that dependencies which have a library are defined as IMPORTED only.
user: GordonJess
issue_8414: state: open
title: [bug] meson doesn't use the compiler specified in profile
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Linux 4.15.3-1-generic
  * Compiler+version: Clang 9.0.1
  * Conan version: 1.33.0
  * Python version: 3.5.3

My profile:
```
[settings]
build_type=Debug
arch=x86_64
arch_build=x86_64
os=Linux
os_build=Linux
compiler=clang
compiler.version=9
compiler.libcxx=libc++

[env]
CC=clang-9
CXX=clang++-9
```

### Steps to reproduce (Include if Applicable)
1. `conan install glib/2.58.3@bincrafters/stable -pr profile_with_clang --build`

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
The Meson build system
Version: 0.53.0
Source dir: /home/user/conan/glib/2.58.3/my/stable/build/37ffc1180646bccd34925cc993d4062477e4c510/source_subfolder
Build dir: /home/user/conan/glib/2.58.3/my/stable/build/37ffc1180646bccd34925cc993d4062477e4c510/build_subfolder
Build type: native build
Project name: glib
Project version: 2.58.3

meson.build:1:0: ERROR: Unknown compiler(s): [['clang-7']]
The follow exceptions were encountered:
Running "clang-7 --version" gave "[Errno 2] No such file or directory: 'clang-7'"

A full log can be found at /home/user/conan/glib/2.58.3/my/stable/build/37ffc1180646bccd34925cc993d4062477e4c510/build_subfolder/meson-logs/meson-log.txt
glib/2.58.3@my/stable: 
glib/2.58.3@my/stable: ERROR: Package '37ffc1180646bccd34925cc993d4062477e4c510' build failed
glib/2.58.3@my/stable: WARN: Build folder /home/user/conan/glib/2.58.3/my/stable/build/37ffc1180646bccd34925cc993d4062477e4c510
ERROR: glib/2.58.3@my/stable: Error in build() method, line 123
        meson = self._configure_meson()
while calling '_configure_meson', line 98
        build_folder=self._build_subfolder, defs=defs)
        ConanException: Error 1 while executing meson "/home/user/conan/glib/2.58.3/my/stable/build/37ffc1180646bccd34925cc993d4062477e4c510/source_subfolder" "/home/user/conan/glib/2.58.3/my/stable/build/37ffc1180646bccd34925cc993d4062477e4c510/build_subfolder" --backend=ninja -Dlibmount="True" -Dbindir="bin" -Ddefault_library="static" -Db_staticpic="true" -Dlibexecdir="bin" -Dlibdir="lib" -Dprefix="/home/user/conan/glib/2.58.3/my/stable/package/37ffc1180646bccd34925cc993d4062477e4c510" -Dselinux="True" -Dinternal_pcre="False" -Dsbindir="bin" -Dincludedir="include" --buildtype=debug
```

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: xahon
issue_8403: state: open
title: [question] What is best way to use conan with xcode projects for ios application?
body: Hello,

I have a large multiplatform application. It has code that is for each platform and C++ code that is platform independent and 3rd party C++ libraries that uses.
Now I am trying to use conan for those 3rd party libraries. And I have troubles make it work for iOS.
I have UI xcode project for ios application. It depends on C++ xcode project which is generated from cmake. The C++ code depends on 3rd party libraries which are committed in our git repository as include files and binaries. The binaries for iOS are fat so they include all needed architectures for an ios application (armv7, arm64, x86_64)

Since conan does not support making of fat libraries, how to make my cmake to refer libraries for both architectures. I want to be able to build the application from xcode. And when switch the build from simulator to device and back everything to work.

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: kdonev
issue_8390: state: open
title: [question] builddirs and build_modules for build requirements are not generated
body: Continuing on flatc vs flatbuffers issues...

I'm using `cmake_find_package` generator with separate host/build profiles.

After upgrade from 1.29 to 1.33 I've noticed that `Findflatc.cmake` file no longer generated.

Opening Conan source code I found that only user and env info and binary/library paths are propagated which means there is no way to find build modules provided by a build requirement.

What do you think: is it a valid use-case for build requirement to provide a build module?

Although personally I would like to resolve whether there should be a single package for 2 contexts (tool + lib) or 2 packages, each for its own context. (Or in my case flatbuffers + flatc or just flatbuffers).
user: ytimenkov
issue_8386: state: open
title: [feature] Implement cached_property
body: Right now, we have so many `cmake`s whice are cached in the manual way like this:

```
    _cmake = None
...
    def _configure_cmake(self):
        if self._cmake:
            return self._cmake
        self._cmake = CMake(self)
        # setting some args
        return self._cmake
```

This is also not the only thing, which is cached, for example:
https://github.com/conan-io/conan-center-index/pull/4319

What I would like to have instead:
```
from conans import tools
...
    @tools.cached_property
    def _configure_cmake(self):
        cmake = CMake(self)
        # setting some args
        return cmake
```

There are already existing implementations like this: https://pypi.org/project/cached-property/
But it might make sense to reimplement this in the most simple (non-threaded, without lru, only property) way.

I personally think that it makes the code much more clear, essentially makes the code to do the same thing, more pythonic and if someone didn't cache `cmake` yet, caching it with this decorator makes it only one line change (`tools` are normally included).

I would like to ask the community for the opinion on this idea.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: mathbunnyru
issue_8378: state: open
title: [bug] conan source requires conanfile.py to accept default profile settings
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 (64-bit)
  * Compiler+version: MSVC 2019 16.8, clang 11, gcc 9.3
  * Conan version: 1.33.0, 1.32.1, 1.24.0
  * Python version: 3.8.2, 3.6.x

### Steps to reproduce (Include if Applicable)

`conan source` does not work on recipes which do not accept the settings of the default profile. It doesn't matter whether the package actually does anything in the `source()` method, conan errors out long before it gets there.

If there is no default profile, `conan source` will generate one.

It would be nice if `conan source` either worked without requiring a profile/those settings, or if those parameters could be provided via arguments.

Example (for a 64-bit system, switch arch otherwise):
```
from conans import ConanFile

class BuggyConan(ConanFile):
    name = "buggy"
    version = "1.0"
    settings = { "arch": ["x86"], "os": None, "compiler": None, "build_type": None }
```

### Logs (Executed commands with output) (Include/Attach if Applicable)

With default profile:
```
> conan source .
ERROR: The recipe is contraining settings. Invalid setting 'x86_64' is not a valid 'settings.arch' value.                                                                                         ' value.
Possible values are ['x86']
Read "http://docs.conan.io/en/latest/faq/troubleshooting.html#error-invalid-setting"
```

Without default profile:
```
> conan source .
Auto detecting your dev setup to initialize the default profile (C:\Users\PengolodhGoedath\.conan\profiles\default)
Found Visual Studio 16
Found gcc 9.3
Found clang 11.0
Default settings
        os=Windows
        os_build=Windows
        arch=x86_64
        arch_build=x86_64
        compiler=Visual Studio
        compiler.version=16
        build_type=Release
*** You can change them in C:\Users\PengolodhGoedath\.conan\profiles\default ***
*** Or override with -s compiler='other' -s ...s***


ERROR: The recipe is contraining settings. Invalid setting 'x86_64' is not a valid 'settings.arch' value.
Possible values are ['x86']
Read "http://docs.conan.io/en/latest/faq/troubleshooting.html#error-invalid-setting"
```
user: PengolodhGoedath
issue_8364: state: open
title: [question] How to integrate build-adjacent concerns into CI workflow using conan?
body: I do hope this is the right place for this kind of question.

I am currently designing a CI workflow for a collection of projects using conan as their package manager. But aside from just building the binaries, the CI workflow should also create other artifacts (depending on circumstances any or all of: static analysis reports, unit test results, documentation, ...) and also deploy them to several different targets.

I'm currently stuck on the most maintainable approach to reach all these goals. My biggest concern isn't about achieving each of the parts individually, but how to compose them into a maintainable fashion (ideally allowing for enabling different artifacts at will) and allowing the reuse of pipelines for different recipes.

I've come up with several approaches, with distinct pro's and con's, but I'm not quite happy with any of them.

### Approach # 1

Use a different conanfile for each artifact.

Pro's:

- Easy to grasp on a conceptual level.
- Easy to get individual artifacts (`conan install name/version@ -g deploy`)
- Streamlined CI process, only a handful of different pipelines necessary (recipe-independent)

Con's:

- Likely duplication of project descriptions. Might be salvageable by sharing a project template python file between individual conanfiles.
- Synchronization nightmare. ("Which binary package revision belongs to this documentation package revision?")

### Approach # 2

Use options or settings to enable/disable features on request. No removal of options from `package_id`.

Pro's:

- Can be automated via profiles for different use cases.
- Single conanfile (+ centralized shared `python_requires` library) for each project.
- No synchronization nightmare. Each package contains everything pertaining to it, and anything outside is irrelevant.
- Streamlined CI process, only a handful of different pipelines necessary (recipe-independent)

Con's:

 - Need to pick individual artifacts from generated packages. Could be negated by enforcing a strict package layout and/or being able to deploy individual components.
 - Combinatorial explosion of package options, and resulting combination mismatches. ("You wanted to use package A from local cache with a small patch? Too bad you didn't build the documentation, so conan now either doesn't find a match due to incompatible options or uses a better match from remote with documentation.")

Can work, but would require tight discipline among different users. Might be viable for packages with only infrequent changes. Another option to make it work would be the ability to match any value for a given option ("I don't care whether the option `enable_static_analysis` was set, I just want the binaries").

### Approach # 3

Use options or settings to enable/disable features on request. Options get removed from `package_id`.

Pro's: (as approach # 2)

Con's:

 - Need to pick individual artifacts from generated packages. Could be negated by enforcing a strict package layout and/or being able to deploy individual components.
 - Either: Pandora's packages. I'm unable to tell from the outside whether any given package contains the wanted artifacts (besides binaries).
 - Or: Bloated packages. Every package on the remote has to contain everything - which means each user has to download everything even if only parts are needed.

Can work, but would require strict controls on which packages can be uploaded to remote. Impact of bloated packages could maybe be reduced if conan were able to only download individual components instead of whole packages.

### Approach # 4

Using custom generators for alternative artifacts. Results effectively are the same as approach # 3, as used generators aren't used in `package_id` calculation (otherwise, the results would be similar to approach # 2 in case of generator combinations. Might be feasible if only using one specific generator for each `package_id`, e.g. generating a "documentation-package", "test-report-package" etc. per recipe).

Might be of interest if generators could be instructed with a specific location where to put the artifacts outside of the `build_folder` (or was it `install_folder`?).

### Approach # 5

Instrumenting build via environment variables. Artifacts besides binaries/headers are not packaged at all.

Pro's:

 - Somewhat easy to setup on CI. Artifacts besides binaries are in specified locations. conan packages only contain binaries, headers etc.

Con's:

 - Hard to replicate for individual developers.
 - conanfile is littered with references to environment variables. Adieu reproducible builds :(

It works, unless you need reproducible builds, then it can be hard to verify that those environment variables don't subtly change things around. CI can be somewhat streamlined unless some recipes need special attention (regarding instrumentation or later deployment of artifacts).

###Approach # 6

conanfile gets instructed (via option or environment variable) to directly deploy other artifacts. Said other artifacts are not included in resulting conan package.

Pro's:

 - Not hard to setup per se.

Con's:

 - Likely security breach ("Why does this recipe know the credentials of that server?!?"), unless credentials are passed in from CI, and even then the conanfile is bound to existing infrastructure.
 - Very hard if not impossible to replicate for individual developers.
 - Other concerns bleed into conanfile. conanfile cannot easily be ported into a different CI infrastructure.
 - Very hard to streamline CI pipelines. Likely needing a different pipeline (or at the very least a different configuration of environment variables) per recipe.

Just no.

###Question

Have I missed any substantial different approaches? What are the recommended approaches for integrating conan into a CI workflow? conan seems to excel at building and distributing binaries, but there doesn't seem to be a clear path regarding how to treat other build-adjacent artifacts.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: PengolodhGoedath
issue_8363: state: open
title: [bug] SystemPackageTool fails when using redhat/devtoolset < 9
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Redhat 7 docker container on windows host
  * Compiler+version: n/a
  * Conan version: 1.32.1
  * Python version: 3.16.12

### Steps to reproduce (Include if Applicable)
In system_requirements() call:
```
installer = tools.SystemPackageTool()
installer.install("lapack")
```

I get:
```
Running: sudo -A yum check-update -y
/var/tmp/sclWkVEFS: line 8: -A: command not found
```
user: rconde01
issue_8359: state: open
title: [feature] config install interval - don't reinstall same config
body: `config_install_interval` is great.  We have it set to a pretty low interval (1 hour) so that changes to the config get picked up as quickly as possible so we don't have to ask developers to manually update the config.  However, it's annoying to have same config installed over and over again.  It would be helpful to have it the interval logic check to see of the current config is the same and if so don't reinstall.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: sourcedelica
issue_8357: state: open
title: [bug] Cmake's find_package fails even with requirements set
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Linux
  * Compiler+version: clang 7.0.1
  * Conan version: 1.31.0
  * Python version: 3.7.4

### Steps to reproduce (Include if Applicable)
I'm trying to create a package for a third-party library that uses PulseAudio as a dependency. I've added that dependency into `def requirements(self)` from bincrafters repo. It fails to configure cmake with that output

> ... a bunch of stuff above ...
> Package 'libpng', required by 'freetype2', not found
> -- Found Fontconfig: /usr/lib64/libfontconfig.so  
> CMake Error at proj/cmake/platform_linux.cmake:139 (find_package):
>   By not providing "FindPulseAudio.cmake" in CMAKE_MODULE_PATH this project
>   has asked CMake to find a package configuration file provided by
>   "PulseAudio", but CMake did not find one.
> 
>   Could not find a package configuration file provided by "PulseAudio" with
>   any of the following names:
> 
>     PulseAudioConfig.cmake
>     pulseaudio-config.cmake
> 
>   Add the installation prefix of "PulseAudio" to CMAKE_PREFIX_PATH or set
>   "PulseAudio_DIR" to a directory containing one of the above files.  If
>   "PulseAudio" provides a separate development package or SDK, be sure it has
>   been installed.
> Call Stack (most recent call first):
>   CMakeLists.txt:29 (include)
> 
> 
> -- Configuring incomplete, errors occurred!
> See also "/home/user/conan/Cinder/0.9.5/_/_/build/0ee6551d361945debc13c78a4ba71d22a111c8b3/CMakeFiles/CMakeOutput.log".
> Cinder/0.9.5: 
> Cinder/0.9.5: ERROR: Package '0ee6551d361945debc13c78a4ba71d22a111c8b3' build failed
> Cinder/0.9.5: WARN: Build folder /home/user/conan/Cinder/0.9.5/_/_/build/0ee6551d361945debc13c78a4ba71d22a111c8b3
> ERROR: Cinder/0.9.5: Error in build() method, line 45
>         cmake = self._configure_cmake()
> while calling '_configure_cmake', line 33
>         _cmake.configure()
>         ConanException: Error 1 while executing cd '/home/user/conan/Cinder/0.9.5/_/_/build/0ee6551d361945debc13c78a4ba71d22a111c8b3' && cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="clang" -DCONAN_COMPILER_VERSION="7.0" -DCONAN_CXX_FLAGS="-m64" -DCONAN_SHARED_LINKER_FLAGS="-m64" -DCONAN_C_FLAGS="-m64" -DCONAN_LIBCXX="libstdc++11" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="/home/user/conan/Cinder/0.9.5/_/_/package/0ee6551d361945debc13c78a4ba71d22a111c8b3" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCONAN_CMAKE_POSITION_INDEPENDENT_CODE="ON" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -Wno-dev '/home/user/conan/Cinder/0.9.5/_/_/build/0ee6551d361945debc13c78a4ba71d22a111c8b3'
> 

The recipe

```
from conans import ConanFile, CMake


class CinderConan(ConanFile):
    name = "Cinder"
    description = "Cinder is a community-developed, free and open source library for professional-quality creative coding in C++."
    topics = ["graphics", "3d", "2d", "image-processing"]
    url = "https://github.com/cinder/Cinder"
    homepage = "https://github.com/cinder/Cinder"
    license = "2-Clause BSD License"
    generators = "cmake"
    settings = "os", "arch", "compiler", "build_type"

    options = {
        "shared": [True, False],
        "fPIC": [True, False],
    }
    default_options = {
        "shared": False,
        "fPIC": True,
    }

    git_url = "file:///home/user/dev/m/cinder-conan/Source"
    source_folder = "_source"
    install_folder = "_source"

    def requirements(self):
        if self.settings.os == "Linux":
            self.requires("pulseaudio/13.0@bincrafters/stable")

    def _configure_cmake(self):
        _cmake = CMake(self)
        _cmake.configure()
        return _cmake

    def config_options(self):
        if self.settings.os == "Windows":
            self.options.fPIC = False

    def source(self):
        self.run("git clone --depth 1 %s %s" % (self.git_url, self.source_folder))
        self.run("cd %s" % self.source_folder)

    def build(self):
        cmake = self._configure_cmake()
        cmake.build()

    def package(self):
        cmake = self._configure_cmake()
        cmake.install()
        self.copy(pattern="COPYING", dst="licenses", src=self.source_folder)


```
user: xahon
issue_8351: state: open
title: BugFix: Gnu Triplet for profiles with custom os are wrong/should be able to be overriden from profile
body: closes: #8290
based on: #8266

Changelog: BugFix: Gnu Triplet for profiles with custom os are wrong/should be able to be overriden from profile
Docs: omit

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 

<sup>**Note:** By default this PR will skip the slower tests and will use a limited set of python versions. Check [here](https://github.com/conan-io/conan/blob/develop/.github/PR_INCREASE_TESTING.md) how to increase the testing level by writing some tags in the current PR body text.</sup>

user: SSE4
issue_8347: state: open
title: Fix: Allow modification of system/cpu_family/cpu/endian in generated MesonToolchain toolchain file
body: closes: #8312

based on #8266

Changelog: Fix: Allow modification of system/cpu_family/cpu/endian in generated MesonToolchain toolchain file
Docs: omit

- [x] Refer to the issue that supports this Pull Request.
- [x] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
- [x] I've read the [Contributing guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [x] I've followed the PEP8 style guides for Python code.
- [ ] I've opened another PR in the Conan docs repo to the ``develop`` branch, documenting this one. 

<sup>**Note:** By default this PR will skip the slower tests and will use a limited set of python versions. Check [here](https://github.com/conan-io/conan/blob/develop/.github/PR_INCREASE_TESTING.md) how to increase the testing level by writing some tags in the current PR body text.</sup>

user: SSE4
issue_8331: state: open
title: [question] How to add/change a require in lock file properly
body: In our project we have a `conanfile.txt` recipe, and for each build configuration we have a lock file. We have a few dependency management scenarios that raise issues, and we do not seem to find a good description anywhere on how to do them.
- updating a dependency version
- adding a new dependency
- removing a dependency

We've been trying to do this by adding/changing the dependency in the recipe, then using some command to update the lock files, but this has proven beyond our understanding.

`conan install` will throw an error that one of the dependencies in the lock file is missing or superfluous.
`conan lock create` using an input lock file, will throw an error, that the lock file does not contain the package named in the recipe.
`conan lock create` without an input lock file but then calling `conan lock update` will also throw an error due to dependency mismatch.

Could you please provide me with a definitive guide of doing these simple steps? I'm sorry, I feel these are so basic, yet I couldn't find any documentation that clearly states how such use-cases can be accomplished without manually editing or replacing the lock file. Or is it intended for lock files to be manually replaced with new ones when dependencies change?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: refactorTractor
issue_8325: state: open
title: Block [requires] of conaninfo.txt file is not handled
body: ### Environment Details
  * Operating System+version: ubuntu16 64bits
  * Conan version: 1.28.0
  * Python version: 3.5

### Steps to reproduce

- Module A depends on Module B with version in minor_mode
  - Module A -> conanfile.py -> package_id() -> self.info.requires["Module B"].minor_mode
  - package generated for Module A -> conaninfo.txt contains [requires] block with Module A/1.1.Z -> that's right :-)
- Module C depends on Module A
  - Module C want to use pre-packaged Module A
    - Module C don't know that Module A depends on Module B and version compatibility constraints
  - Dependency resolution fails for Module A because the package_id calculated for Module A not match :-(
    - the reason is the block [requires] of Module A conaninfo.txt is not taken into account and the minor_mode info is ignored
    - **method loads() of ConanInfo use hard coded "semver_direct_mode" instead of information coming form [requires] block**

user: cvignol
issue_8323: state: open
title: [feature] config_install_url_update to support migrations
body: The `config_install_interval` attribute now supported in `conan.conf` (  https://github.com/conan-io/conan/pull/6824  ) is great.  Thanks.

We've found, though, that we sometimes need to support migrating users to a new config repo location.

Could we add support for a `config_install_url_update` `conan.conf` attribute so that if we have:

```
C:\dev\src>conan config install --list
0: {'type': 'git', 'uri': 'git@github.dev.myorg.com:oldorg/oldrepo.git', 'verify_ssl': True, 'args': None, 'source_folder': None, 'target_folder': None}
```

and then `https://bbgithub.dev.bloomberg.com/oldorg/oldrepo/blob/master/config/conan.conf` is changed to contain:

```
git@github.dev.myorg.com:neworg/newrepo.git
```

then conan config install list will be updated to:

```
C:\dev\src>conan config install --list
0: {'type': 'git', 'uri': 'git@github.dev.myorg.com:neworg/newrepo.git', 'verify_ssl': True, 'args': None, 'source_folder': None, 'target_folder': None}
```


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: michaelmaguire
issue_8318: state: open
title: [feature] lock files should contain (optional) a remote 
body: Installing dependencies via a lock file is awesome, the lockfile contains the whole profile information, and package revisions, so when distributing lock files to a project, a project is nearly independent of the config a developer has on their machine.

Back then , I needed to setup everything local
```
conan config set general.revisions_enabled=True
conan config set general.default_package_id_mode=full_version_mode
conan remote add name url
```
publish the config, and make users run `conan config install. ...` 

while `conan config install` solves a lot , it does not solve the problem when things change, and people forget to update the config.

this has some problems, mostly, developers are not perfect, and they forget. 
configurations might change, profiles certainty do, remote url might need an update

lockfiles seem to take most things away, things like revisions_enabled, default_package_id_mode and pofiles should not influence the result when installing dependencies via a lockfile.

But the remote is not part of a lockfile, this comes still from a user.

It would be awesome being able to also add a remote (optional) to a lockfile, so a project can be self containing, and a user just needs to have conan installed ....

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: a4z
issue_8316: state: open
title: [bug] Inject PIC through CMake helper if shared and fPIC option not exists
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

`definitions["CONAN_CMAKE_POSITION_INDEPENDENT_CODE"] = True` should be injected if not Windows, shared option exists but not fPIC option.

Indeed, CMake files of projects might rely on intermediate OBJECT or STATIC targets linked into SHARED targets.

So basically remove this condition: https://github.com/conan-io/conan/blob/41315b6b90a20404665c125dd6ac30d1b30fd6a7/conans/client/build/cmake_flags.py#L371
user: SpaceIm
issue_8314: state: open
title: [question] How to model header only libraries that have a runtime dependency?
body: Hi,

Tha basic question is which model to use for recipes that are header only libraries that have a dependency at runtime on a library? It doesn't get covered in https://docs.conan.io/en/latest/howtos/header_only.html.

A example of this is cppzmq, as it's modelled here: https://github.com/conan-io/conan-center-index/blob/master/recipes/cppzmq/all/conanfile.py

It has `settings`, and `requires` (on ZeroMQ), but package_id wipes all that ABI information out with `self.info.header_only()`.

Looking at the Conan Center Artifactory (https://conan.io/center/cppzmq?tab=configuration&os=) there is a single build there (expected for header only).

However, in the more general sense, if we wanted to write a test_package recipe for a header only library that needs to exercise different variations of its dependent runtime library, how is that meant to be modelled? For example, say if H is the header only lib, that requires the runtime lib R, but we know we have different needs to use it in both shared=True and shared=False modes of R, how is that modelled in a recipe for H and make it testable at package creation time?

Obviously, it would be nice not to have duplicates of H for every variation of R we're interested in, but that does seem like the only solution, and not to use header_only().

Thanks!
Mark

- [x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: foundry-markf
issue_8312: state: open
title: [feature] Allow modification of system/cpu_family/cpu/endian in generated MesonToolchain toolchain file
body: Hello,

I'm currently creating recipes+packages aimed for the Nintendo Switch.
I added `Nintendo Switch` to `os` in my `settings.yml`.

While creating a recipe for the mesa port, I'm using the MesonToolchain class.
This creates the following section:
```
[build_machine]

system = 'linux'
cpu_family = 'x86_64'
cpu = 'x86_64'
endian = 'little'

[host_machine]

system = 'nintendo switch'
cpu_family = 'aarch64'
cpu = 'armv8'
endian = 'little'

[target_machine]

system = 'nintendo switch'
cpu_family = 'aarch64'
cpu = 'armv8'
endian = 'little'
```

The correct data for nintendo should be:
```
[host_machine]
system = 'horizon'
cpu_family = 'aarch64'
cpu = 'armv8'
endian = 'little'
```

What I'm asking for is a feature to override these default/calculated values.

Right now, the `toolchain` method is the following:
```python
    def toolchain(self):
        tc = MesonToolchain(self)
        tc.generate()
```
It would be useful to make this possible:
```
    def toolchain(self):
        tc = MesonToolchain(self)
        tc.host_machine.system = "horizon"
        tc.target_machine.system = "horizon"
        tc.generate()
```
Or something similar...

CC'ing @SSE4 for being the strong man behind `MesonToolchain`.
user: madebr
issue_8304: state: open
title: [feature] compiler.cppstd should be set to the IDE default, if not provided.
body: <!-- What is your suggestion? Please be as specific as possible! -->

All recent major IDEs (VS, XCode, Clion) pass the **default IDE** c++ language standard **settings** (-std=c++<...>)  to the compiler. [According ](https://docs.conan.io/en/latest/howtos/manage_cpp_standard.html)  Conan will detect the default language standard of compiler, if the compiler.cppstd option not set.  But it will detect the default compiler[ mode](https://github.com/conan-io/conan-center-index/pull/3977#issuecomment-756086528) only, what is not very useful.

@SSE4 

Please follow https://github.com/conan-io/conan-center-index/pull/3977



Visual Studio 2019 (default /std:c++14)
https://docs.microsoft.com/de-de/cpp/build/reference/std-specify-language-standard-version?view=msvc-160

XCode 12 (default /std:c++14)
(man clang )

Clion 2020 (default /std:c++14)
![Clion_cpp_standard](https://user-images.githubusercontent.com/52277783/104003054-34f5ae00-51a2-11eb-8dd1-37ecc55f7ab4.png)

vs. 

 C++98 (C++03) compiler defaults

https://gist.github.com/ax3l/53db9fa8a4f4c21ecc5c4100c0d93c94


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).


user: dmn-star
issue_8290: state: open
title: [bug] Gnu Triplet for profiles with custom os are wrong/should be able to be overriden from profile
body: Hello,

I'm currently creating conan recipes for key packages for the Nintendo Switch homebrew toolchain.
For this, I have added `os=Nintendo Switch` to my `settings.yml`.

The problem I'm facing is that conan uses `os=Nintendo Switch` for generating the gnu triplets.
When building `mpg123/1.26.4`, the following arguments are passed to the autotools configure script.
```
...  '--datarootdir=${prefix}/share' --build=x86_64-linux-gnu --host=aarch64-nintendo switch
```
Besides the fact that the space in *Nintendo Switch* is not escaped, the triplet is unknown.
```
configure: WARNING: you should use --build, --host, --target
checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration `aarch64-nintendo': system `nintendo' not recognized
configure: error: /bin/sh source_subfolder/build/config.sub aarch64-nintendo failed
```

It would be nice to have a way in the profile to override the host triplet.
e.g. adding the following section to the host profile.
```
[overrides]
gnu-triplet=aarch64-none-elf
```

The used command to build mpg123 is:
```
conan install mpg123/1.26.4@ -pr:h nintendo-switch -pr:b default64 --build missing
```

The used host profile (`nintendo-switch`) is:
```
[settings]
os=Nintendo Switch
arch=armv8
compiler=gcc
compiler.version=10.2
compiler.libcxx=libstdc++11
build_type=Release
[build_requires]
devkitA64/38
[env]
```

The used build profile (`default64`) is:
```
[settings]
os=Linux
arch=x86_64
compiler=gcc
compiler.version=9
compiler.libcxx=libstdc++11
build_type=Release
[options]
[build_requires]
[env]
CC=gcc
CXX=g++
AS=gcc
ASM=gcc
CFLAGS=-m64
CXXFLAGS=-m64
ASFLAGS=-m64
ASMFLAGS=-m64
LDFLAGS=-m64
```

/cc @jgsogo as you're the goto guy for cross build affairs.
user: madebr
issue_8275: state: open
title: [feature] Support resolving conflicts between different packages that provide the same feature
body: Conan v1.28 introduced the support for [provides attribute](https://docs.conan.io/en/latest/reference/conanfile/attributes.html#provides) which allows for multiple recipes to provide the same functionality and thus avoid ODR violations.

This is a great feature, but currently supports only reporting an error if multiple libraries in the graph provide the same functionality, but does not support resolving that error.

For example, if `conan install` for my package raises the following error:

```
At least two recipes provides the same functionality:
 - 'libjpeg' provided by 'libjpeg/9d', 'libjpeg-turbo/2.0.5'
```

I can only wait for all dependencies of my packages to agree on either using `libjpeg` or `libjpeg-turbo`.

I think it would be great if my package could somehow "override" the dependencies by selecting only one of those packages. In the example above, my package would override to use `libjpeg-turbo/2.0.5` and that should inform conan to replace `libjpeg/9d` in entire graph with `libjpeg-turbo/2.0.5`, just like it does when it encounters a conflict between multiple different versions of the same package.
user: DoDoENT
issue_8241: state: open
title: [question] Random install failures?
body: In my CI environment I am periodically seeing `conan install` failures as indicated in the log below. For this specific instance it looks like the conanmanifest.txt file failed to properly download. Has anyone seen something similar? Is this a bug or a CI environment configuration issue?

Thanks

**Environment**

- Conan Version: 1.32.1
- Operating System: Red Hat Enterprise Linux 7.4
- Python Version: 3.7.1

**Steps to Reproduce**

1. `conan install`
ie. conan install ../repo/utils/ user/stable -if . -pr=profile-x86_64-rhel

**Log**
```
[2020-12-19T16:30:46.316Z] configutils/1.0.0@user/stable: Not found in local cache, looking in remotes...

[2020-12-19T16:30:46.316Z] configutils/1.0.0@user/stable: Trying with '09570ca2-676b-4b91-bf11-07275d777efa'...

[2020-12-19T16:30:46.329Z] Downloading conanmanifest.txt

[2020-12-19T16:30:46.337Z] Downloading conanfile.py

[2020-12-19T16:30:46.346Z] configutils/1.0.0@user/stable: Downloaded recipe revision c65a9187a96d2179e9a2eafc58d83760

[2020-12-19T16:30:46.590Z] configutils/1.0.0@user/stable: ERROR: Exception while getting package: 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9

[2020-12-19T16:30:46.590Z] configutils/1.0.0@user/stable: ERROR: Exception: <class 'FileNotFoundError'> [Errno 2] No such file or directory: '/jenkins_server/workspace/build/conanHome/.conan/data/configutils/1.0.0/user/stable/dl/pkg/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/conanmanifest.txt'

[2020-12-19T16:30:46.590Z] ERROR: [Errno 2] No such file or directory: '/jenkins_server/workspace/build/conanHome/.conan/data/configutils/1.0.0/user/stable/dl/pkg/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/conanmanifest.txt'
```
user: radonish
issue_8240: state: open
title: file names case sensitivity
body: Hi all, 
I recently updated my conan version from 1.17.0 to 1.32.0.
my company legacy-code has package that contains 2 files with very similar names, separated only by case sensitivity..e.g.:
foo.cpp
Foo.cpp
in old conan, 1.17.0 can run "conan create" with no problem, however in 1.32.0 "conan create" is failing with error of not finding "foo.cpp"

Putting aside good/bad practice for filenames that are different only by case, we would like to have support for our legacy code with new conan versions.

Is this behavior created on purpose? is it a bug? 

user: galikrosentalik
issue_8233: state: open
title: Allow manual search/installation from disabled remotes
body: Conan allows to disable some remotes. And currently a disabled remote is just a line in `conan remote list` output. User can do nothing with them. Only enable it back. What if allow certain actions on such remotes when user manually specify them via `-r` parameter.

Just an example. We use a recommended package promotion scheme to copy packages from dev to prod repo. When someone builds a package, she would like to test how a local project compiles with an updated package. Currently she has to enable dev repo to download the package. What if she could just run `conan install my_package/1.1@ -r dev` to install it into the local cache and not affect the scope where conan searches new packages? Keeping `dev` repo always on is not good because someone could forget to promote a new package to prod, and the incident won't be noticed immediately because conan will find the package in the dev repo.
user: kdsx
issue_8229: state: open
title: [bug] Pinned revision still uses old conanfile.py
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: MSVC VS 16
  * Conan version: 1.32.1
  * Python version: 3.5.2 (python3) 2.7.12 (python) pip 20.1 from /usr/local/lib/python3.5/dist-packages/pip (python 3.5)

### Steps to reproduce (Include if Applicable)

Boost was installed with the latest (or a newer revision) boost/1.74.0. then to avoid a bug in the package it was pinned to boost/1.74.0#3b52fbf45879b8b288e59d454d1c4765, and CONAN_REVISIONS_ENABLED=1 was set (conan was also updated in the process).

Then I was still getting errors as if using the newer revision, but it looked like I had the pinned revision:
```
$ conan search boost/1.74.0 -rev
Existing package recipes:

boost/1.74.0#3b52fbf45879b8b288e59d454d1c4765
```
The error
```
ERROR: boost/1.74.0: Error in package_info() method, line 1164
        assert len(non_used) == 0, "These libraries were not used in conan components: {}".format(non_used)
        AssertionError: These libraries were not used in conan components: {'boost_nowide'}
```
This is not in the recipe [pinned](https://conan.io/center/boost?version=1.74.0&revision=3b52fbf45879b8b288e59d454d1c4765&tab=recipe&os=)  but it is here [newer](https://conan.io/center/boost?version=1.74.0&revision=762204d1a4a3d27eb3d082b371c3cf30&tab=recipe)

I then removed all packages `conan remove "boost*" -f` and executed again
```
conan.exe install ./conanfile.txt -g visual_studio --install-folder .\Release\.conan "-pr=vs16release" -s compiler.cppstd=17 --build=outdated --update`
```
and then it worked.

I did the same thing on linux which worked fine without removing boost.

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: gummif
issue_8227: state: open
title: [question] Package ID unexpected behavior
body: I discovered a weird behaviour in the generation of the package ID for a recipe that requires qt.

Here is the minimal example:

- `conanfile.txt`
```
[requires]
qt/5.15.2@bincrafters/stable
```

Environment:
- docker image `conanio/gcc7`
- `conan profile new --detect default`
- `conan profile update settings.compiler.libcxx=libstdc++11 default`
- `conan remote add bincrafters https://api.bintray.com/conan/bincrafters/public-conan`

Default package ID mode:
- `cat $HOME/.conan/conan.conf | grep default_package_id_mode`
```
default_package_id_mode = semver_direct_mode # environment CONAN_DEFAULT_PACKAGE_ID_MODE
```

If I run `conan info -n id .` I get:
```
conanfile.txt
    ID: a13c4ee5c4526b19b1ae512ddd11c56d93c7e2f2
```

But now If I run `conan info -n id -o qt:with_mysql=False .`, I get:
```
conanfile.txt
    ID: 967981d76f1d4beb7a6e8b10a88a7548c314e7d2
```

Has you can see the package ID of my recipe changes depending on option set on its qt dependencies. The package ID only changes if the option of qt I used actually changes qt recipe own requirements.

Is this behaviour expected ? Because if I look at https://blog.conan.io/2019/09/27/package-id-modes.html, this shouldn't be the case but there is maybe something I missed.



- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Forbinn
issue_8220: state: open
title: [question] relative rpath set in  binaries when 
body: Not entirely sure if this is related to conan or rather to cmake, but still...

I need to use **CONAN_USER_HOME** to persist the conan cache between multiple docker containers.

When i set the var to the build directory, the resulting binaries have a relative RPATH, meaning they can only be executed in the root of the build directory.

setting **CONAN_USER_HOME** to /tmp results in an absolute RPATH and the binaries consistantly work throughout the entire filesystem. (which is what i need)

/tmp/.conan/data/iowa/5289_04.00.00.00_14.00.0002/ETMConanRepo/stable/package/2d4cb6bece343267ae8c75de4e6c320bb0079a0d/bin/libWCCILAggregationTimer.so

do you have any idea what's causing this?

user: SimplyLiz
issue_8212: state: open
title: [question] Generators are not called for recipe defining custom build_id
body: Conan 1.31.1.

I'm trying to create a workflow which creates 2 binary packages in one go: one with tests and one without (pretty much one described in the https://docs.conan.io/en/latest/reference/conanfile/methods.html#build-id).

However I noticed that custom generators are not called when build directory already exists (only the built-in ones like `TXTGenerator`).

Somewhere in `installer.py` / `build_package`: generators are written in the `self._build(...)` which is not invoked if `skip_build`, however `TXTGenerator` is invoked in `_package()` right before calling recipe's `package()`.

This leads to inconsistent results.

My custom generator tries to capture all options / settings to minimize the number of command-line parameters which need to be passed. Even CMake generator exports `CONAN_SETTINGS_*` variables). Not to mention that requirements can be different.

However those differences are fine for the build because package will do incremental build anyways (most build systems do build missing stuff in `install` step). Or on contrary will skip building the "main" code if test package was built first.

Also I really don't want to build packages twice because the second build will be a wasted work in most cases and it will double the work needed to build already big number of configurations.

Since this is the question: what are the reasons for not calling generators when skipping the build?
user: ytimenkov
issue_8206: state: open
title: [bug] Generated find package fails with fatal error if optional components are not found
body: ### Environment Details
  * Operating System+version: Ubuntu 18.04
  * Compiler+version: Clang 11
  * Conan version: 1.32.0
  * Python version: 3.8.5
  * CMake version: 3.18.2

### Steps to reproduce

`conanfile.py`
```.py
from conans import ConanFile, CMake

class ConanTest(ConanFile):
    name = "hello"
    version = "1.0.0"
    requires = "boost/1.74.0"
    exports = ["CMakeLists.txt"]
    generators = "cmake", "cmake_find_package"

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
```

```CmakeLists.txt```
```
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

find_package(Boost 1.74 OPTIONAL_COMPONENTS mpi)
```

### Logs 

```
conan create . --build outdated --update
```

```
-- Conan: Using autogenerated FindBoost.cmake
-- Found Boost: 1.74.0 (found suitable version "1.74.0", minimum required is "1.74") 
CMake Error at FindBoost.cmake:6 (message):
  Conan: Component 'mpi' NOT found in package 'Boost'
Call Stack (most recent call first):
  FindBoost.cmake:90 (conan_message)
  CMakeLists.txt:4 (find_package)
```
user: planetmarshall
issue_8200: state: open
title: [question] How to cross-build for Windows target from Linux host using profile + build_requires?
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

I want to set up a simple example to demonstrate cross-build using profile + build_requires. By referring to various documents (especially [Cross building](https://docs.conan.io/en/latest/systems_cross_building/cross_building.html#cross-building), [Conan Profiles and Build Requires](https://bincrafters.github.io/2017/12/05/Conan-Profiles-and-Build-Requires/)), previous github issues and slack channel, I created a profile (posted below). I get errors with both mingw and msys2.


* I noticed on conan-center, many of the "installer" packages (mingw, msys2, cygwin) are marked as legacy. If this means they are "deprecated", what should be used instead?

* What could I try next to resolve the issues and get a working cross-build example? [I do not need to use a specific compiler for this example.]

<!---->
**Profile**:

    [settings]
    os=Windows
    os_build=Windows
    arch=x86_64
    arch_build=x86_64
    compiler=gcc
    compiler.libcxx=libstdc++11
    compiler.version=7.1
    compiler.exception=seh
    compiler.threads=posix
    
    [build_requires]
    #mingw_installer/1.0@conan/stable    ## commented out to try with msys2
    msys2_installer/20161025@bincrafters/stable

**Error when building with mingw**:

    CMake Error: Could not create named generator MinGW Makefiles
    
    Generators
    * Unix Makefiles               = Generates standard UNIX makefiles.
      Green Hills MULTI            = Generates Green Hills MULTI files
                                     (experimental, work-in-progress).
      Ninja                        = Generates build.ninja files.
      Ninja Multi-Config           = Generates build-<Config>.ninja files.
      Watcom WMake                 = Generates Watcom WMake makefiles.
      CodeBlocks - Ninja           = Generates CodeBlocks project files.
      CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
      CodeLite - Ninja             = Generates CodeLite project files.
      CodeLite - Unix Makefiles    = Generates CodeLite project files.
      Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
      Sublime Text 2 - Unix Makefiles
                                   = Generates Sublime Text 2 project files.
      Kate - Ninja                 = Generates Kate project files.
      Kate - Unix Makefiles        = Generates Kate project files.
      Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
      Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.

**Error when building with msys2**:
    
    CMake Error at /home/aravind/.local/lib/python3.8/site-packages/cmake/data/share/cmake-3.18/Modules/CMakeTestCCompiler.cmake:66 (message):
      The C compiler
    
        "/usr/bin/cc"
    
      is not able to compile a simple test program.
    
      It fails with the following output:
    
        Change Dir: /home/aravind/.conan/data/gtest/1.10.0/_/_/build/f387ff0abe3f37c7cf59bfb1ffa8567fdbbccce8/CMakeFiles/CMakeTmp
        
        Run Build Command(s):/usr/bin/make cmTC_6e432/fast && /usr/bin/make  -f CMakeFiles/cmTC_6e432.dir/build.make CMakeFiles/cmTC_6e432.dir/build
        make[1]: Entering directory '/home/aravind/.conan/data/gtest/1.10.0/_/_/build/f387ff0abe3f37c7cf59bfb1ffa8567fdbbccce8/CMakeFiles/CMakeTmp'
        Building C object CMakeFiles/cmTC_6e432.dir/testCCompiler.c.obj
        /usr/bin/cc    -o CMakeFiles/cmTC_6e432.dir/testCCompiler.c.obj -c /home/aravind/.conan/data/gtest/1.10.0/_/_/build/f387ff0abe3f37c7cf59bfb1ffa8567fdbbccce8/CMakeFiles/CMakeTmp/testCCompiler.c
        Linking C executable cmTC_6e432.exe
        /home/aravind/.local/lib/python3.8/site-packages/cmake/data/bin/cmake -E cmake_link_script CMakeFiles/cmTC_6e432.dir/link.txt --verbose=1
        /home/aravind/.local/lib/python3.8/site-packages/cmake/data/bin/cmake -E rm -f CMakeFiles/cmTC_6e432.dir/objects.a
        /usr/bin/ar cr CMakeFiles/cmTC_6e432.dir/objects.a @CMakeFiles/cmTC_6e432.dir/objects1.rsp
        /usr/bin/cc -Wl,--whole-archive CMakeFiles/cmTC_6e432.dir/objects.a -Wl,--no-whole-archive -o cmTC_6e432.exe -Wl,--out-implib,libcmTC_6e432.dll.a -Wl,--major-image-version,0,--minor-image-version,0 
        /usr/bin/ld: unrecognized option '--major-image-version'
        /usr/bin/ld: use the --help option for usage information
        collect2: error: ld returned 1 exit status
        make[1]: *** [CMakeFiles/cmTC_6e432.dir/build.make:107: cmTC_6e432.exe] Error 1
        make[1]: Leaving directory '/home/aravind/.conan/data/gtest/1.10.0/_/_/build/f387ff0abe3f37c7cf59bfb1ffa8567fdbbccce8/CMakeFiles/CMakeTmp'
        make: *** [Makefile:140: cmTC_6e432/fast] Error 2
        
        
    
      
    
      CMake will not be able to correctly generate this project.
    Call Stack (most recent call first):
      CMakeLists.txt:2 (project)
    
    
    -- Configuring incomplete, errors occurred!


user: dragondive
issue_8199: state: open
title: [feature] `conan lock update` should update package-ids of consumers when possible
body: package-id mode: `package_revision_mode` 

When deriving new lockfiles for each configuration/profile of a change, the `package-id`s of the consumers are unknown.  If my understanding is correct this is because it is impossible to know the package revision `prev` of the changed package before it is built.

```
conan lock create ../conanfile.py --user=user --channel=channel --lockfile-out=locks/libb_deps_base.lock  --build --base
conan export .. libb/0.2@user/channel --lockfile=locks/libb_deps_base.lock --lockfile-out=locks/libb_base.lock
conan lock create --reference=libb/0.2@user/channel --lockfile=locks/libb_base.lock --lockfile-out=locks/release.lock -s build_type=Release --build=missing
conan lock build-order locks/release.lock --json=build_order/build_order.json

[[('libc/0.1@user/channel#0c089e63b9257da0f5c0e54b7ab7497c49be8943', 'b3fb0c7cc19cd0b04b840bafdf9e18adc3ca1246', 'host', '5')], [('libd/0.1@user/channel#dea4d51a7d43deadb40c226510cc2bedd6c22b77', 'Package_ID_unknown', 'host', '4')], [('app1/0.1@user/channel#7929e9808ff776b6afc5135394bf00b210a64c3b', 'Package_ID_unknown', 'host', '3')]]
```

Once I build the package and update the lockfile it should now be possible to determine the `package-id`:
```
conan install libc/0.1@user/channel#0c089e63b9257da0f5c0e54b7ab7497c49be8943 --build=libc/0.1@user/channel#0c089e63b9257da0f5c0e54b7ab7497c49be8943 --build=missing --lockfile=locks/release.lock --lockfile-out=locks/updated_release.lock
conan lock update locks/release.lock locks/updated_release.lock
```

I would like for the `Package_ID_unknown` entries to be updated accordingly when possible.

My main goal here is to ensure each entry in the top level of build-order has a known `package-id`.  Currently after building the first level, updating the main config lockfile, and recomputing the build-order, this is not the case. 

```
conan lock build-order locks/release.lock --json=build_order/build_order.json

[[('libd/0.1@user/channel#dea4d51a7d43deadb40c226510cc2bedd6c22b77', 'Package_ID_unknown', 'host', '4')]]
```
user: GordonJess
issue_8193: state: open
title: [bug] dpkg-query: command not found
body: We are planning to upgrade from conan 1.22.4 to 1.31.4, but we are facing an issue with the detection of the package manager in OSInfo() because the detection mechanism was changed:

https://github.com/conan-io/conan/blob/58dd8268d94f27f49a50b4f155c45c1c05476d44/conans/client/tools/oss.py#L180

We are running opensuse with the `zypper-aptitude` package installed. Therefore, both checks within OSInfo.with_apt() succeed when using the `SystemPackageTool`:

```
> which apt-get
/usr/bin/apt-get
> apt-get moo
   \\\\\
  \\\\\\\__o
__\\\\\\\'/_
```

However, `SystemPackageTool` cannot check for existing packages, because we don't have dpkg-query installed.

### Environment Details (include every applicable attribute)
  * Operating System+version:
PRETTY_NAME="openSUSE Leap 15.1"
  * Compiler+version:
gcc (SUSE Linux) 7.5.0
  * Conan version:
1.31.4
  * Python version:
Python 3.6.8

### Steps to reproduce (Include if Applicable)
call `conan install` for a package using `tools.SystemPackageTool().installed()`

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
> conan install CMake/3.10.3@3rdparty/stable

CMake/3.10.3@3rdparty/stable: Downloaded package revision ca498ea68f017bded5f04fa2a68ac0cd
/bin/sh: dpkg-query: command not found
CMake/3.10.3@3rdparty/stable: ERROR: while executing system_requirements(): required system package 'libcurl-devel' is missing
ERROR: Error in system requirements
```
user: Da-LiFe
issue_8188: state: open
title: [bug] `conan info -g` giving three different results depending on order of packages in a recipe
body: Given a list of package references, I have been experimenting with getting the build order of said package using the Conan commands. I've read a few github issues that have suggested using `conan info -g out.dot` to do so.

Bear in mind that the list of package references could be anything, in particular, probably multiple versions of packages of interest in building.

My initial experiment was to list them in a conanfile.txt, under build requirements (was my first thought, but bear with me), and to my surprise, I got this error:

```
conan info -g out.dot .
ERROR: True
```

With a bit more experimentation, I've encountered two additional results, based on the _order in which I write the packages in the conanfile.txt_. This surprised me as I think of the text file version of recipes as declarative, so a change of behaviour by ordering of data was unexpected.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 Pro
  * Conan version: 1.32.0
  * Python version: 3.8

### Steps to reproduce (Include if Applicable)
I have put all the repro steps into a public gist with a Windows batch file to run in a Python3 virtual environment: https://gist.github.com/foundry-markf/3441fa19cea9318e7f1bfb14c9658cae

It contains three recipes; one that doesn't give an error producing a dot file (*), one that gives a more meaningful error, and then the error "True" as mentioned above.

The output I see is
```
"Trying one set of ordering which created a dot file, although missing one of the zlib versions"
[build_requires]
zlib/1.2.8@
zlib/1.2.11@
libpng/1.6.37@
digraph {
        "libpng/1.6.37" -> "zlib/1.2.11"
        "createsdot_conanfile.txt" -> "zlib/1.2.11"
        "createsdot_conanfile.txt" -> "libpng/1.6.37"
}

"Trying another set of ordering that gives a reasonable error"
[build_requires]
zlib/1.2.11@
zlib/1.2.8@
libpng/1.6.37@
ERROR: Conflict in libpng/1.6.37:
    'libpng/1.6.37' requires 'zlib/1.2.11' while 'meaningfulerror_conanfile.txt' requires 'zlib/1.2.8'.
    To fix this conflict you need to override the package 'zlib' in your root package.

"Trying another set of ordering that gives a weird error"
[build_requires]
libpng/1.6.37@
zlib/1.2.11@
zlib/1.2.8@
ERROR: True
```

(*) One observation is that given two versions of zlib as input, only one appears in the build order. I suspect this is because Conan's dependency graph only ever wants a single version of a package (which is how I interpret the more meaningful error message).

I debugged Conan and found that the "True" exception is coming from [_conflicting_references](https://github.com/conan-io/conan/blob/develop/conans/client/graph/graph_builder.py#L279-L299) which returns either a bool or a string (or raises), and the exception is raised from [this call point](https://github.com/conan-io/conan/blob/develop/conans/client/graph/graph_builder.py#L247-L249) when a bool is returned as opposed a string message.

My questions are:
1) should I expect package ordering in the recipe to affect behaviour?
2) is it a bug in _conflicting_references that should raise (in both code paths) instead of returning a string?
3) for my initial intent, if I do have a list of packages that includes multiple versions of packages, how _can_ I determine the build order of all packages list through Conan's commands?

Thanks!
user: foundry-markf
issue_8185: state: open
title: [question] Why is "fPIC" always set in conan if "shared" is activated?
body: Hi there,

I ran into some linker-issues with `fPIC` and have a question about a behavior which I didnt expected.

My situation:
I am building a library lets call it `my_libA`.
And I am building a library lets call it `my_libB` which link against `my_libA`.
(when builing, I mean the gcc54 compiler on a ubuntu 64-bit Plattform, I am not cross-compiling or something like that).
Both libraries have the `fPIC` and the `shared` option, because I want to provide the variants.

So when I am building the variant: 
`my_libA` (with options: `shared=False` && `fPIC=False`) and `my_libB` (with options: `shared=True` && `fPIC=False`)  
Which should be technically be possible linking a static lib into a shared one ...
-> I am getting a linker error which tells me, something like that:
```
<my_libA>: relocation R_X86_64_PC32 against symbol `<symbol-name>' can not be used when making a shared object; recompile with -fPIC
```

I assume, that it want's to tell me that I want to link one library without `fPIC` against one with `fPIC`.

I was looking into the log and was able to reproduce the behavior with a clean package. And now I come to my question:

Why is conan ignoring the option `fPIC` when the option shared is true, and `fPIC` is false?
* If both options `fPIC` && `shared` exists AND the `shared` option is on `true`, then `fPIC`-adjust log-msg always appears, even if fPIC is set to false!
* log message appears `-- Conan: Adjusting fPIC flag (ON)`

-> I assmune that results in fPIC is always set even if the option is set to false ...

Steps to reproduce:
1. create a clean package e.g. `conan new cool_name`
2. go into the recipy and add the fPIC option so the options should look something like that:
```
options = {"shared": [True, False], "fPIC": [True, False]}
default_options = {"shared": False, "fPIC": False}
```
3. build the package with the following options `conan create . user/channel -o cool_name:shared=True -o cool_name:fPIC=False`
4. terminal message appears. `-- Conan: Adjusting fPIC flag (ON)`

Is this behavior intended? how can I build a shared library in two variants? with & without fPIC?


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).


edit:
I found It is the code, but I still dont understand why this is done.
https://github.com/conan-io/conan/blob/edb3a4a1f7739027c0665749b82b1cc473453ab6/conans/client/build/cmake_flags.py#L367-L373

user: tharilya
issue_8179: state: open
title: [bug] private dependencies cannot resolve conflicts
body: 
### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: 
  * Conan version: 1.28.2
  * Python version: 3.8.5

### Steps to reproduce (Include if Applicable)
In my dependencies I have a conflict in the requirements. As the current recipe results an executable I do not want to propagate the requirements and declared them private. 
When installing, I get a conflict error. When I make the requirement, that solves the conflict, public everything works fine, but I propagate dependencies unnecessarily and the users will have to solve unnecessary conflicts. 



user: heili77
issue_8176: state: open
title: [question] how to handle testing framework that depends on other (normal) libs
body: Relates to #8170

From my current understanding of https://docs.conan.io/en/latest/devtools/build_requires.html, a library used as a testing framework (e.g. gtest, catch2), that is not directly used in/by the final binary code (only used in the separated test code, that will not be part of the final binary of the package) should be declared as a `build_requires` (with `force_host_context=True` then using the new Build and Host contexts).

The problem in our case is, that our custom test framework has as requirements libraries that are also used in the final binaries, which seems to cause problems.

Our setup (note that basically all also need `boost`, which I left out for simplicity. also left out some other libs, that should not be relevant):
- `libA`
- `libB`  requires `libA`
- `libC` requires `libA` and `libB`
- `testFrameworkForC` requires `libB` and `libC`
- `libD` requires `libA`, `libB` and  `libC`
  - the unit test of `libD` also uses `testFrameworkForC`
- `app` requires `libA`, `libB`,  `libC` and  `libD`
  - the unit test of `libD` also uses `testFrameworkForC`

`testFrameworkForC` is a special (header only) testing framework, that helps writing unit test for code that uses `libC`. It will not be part of the final binary of a package.

Previously we declared in `libD` and `app` a private `requires` on `testFrameworkForC`. Besides the issue found in #8170, switching the private `requires` to a `build_requires` worked fine for `libD`.

When I wanted to switch it also in `app`, I however got an error:

```
ERROR: libC/conan: Incompatible requirements obtained in different evaluations of 'requirements'
    Previous requirements: [boost/1.69.0@conan/stable, libB/conan, libA/conan]
    New requirements: [boost/1.69.0@conan/stable, libB/4.2.0+alias.conan.test.build, libA/7.1.0+alias.conan.test.build]
```
Above the error are the following warnings:
```
WARN: libB/conan: requirement libA/[^7.1.0] overridden by your conanfile to libA/conan
WARN: libC/conan: requirement libB/[^4.2.0] overridden by your conanfile to libB/conan
WARN: libC/conan: requirement libA/[^7.1.0] overridden by your conanfile to libA/conan
WARN: libU1/conan: requirement libA/[^7.1.0] overridden by your conanfile to libA/conan
WARN: libU2/conan: requirement libA/[^7.1.0] overridden by your conanfile to libA/conan
WARN: libD/conan: requirement libC/[^4.1.0] overridden by your conanfile to libC/conan
WARN: libD/conan: requirement libB/[^4.2.0] overridden by your conanfile to libB/conan
WARN: libD/conan: requirement libU1/[^5.2.0] overridden by your conanfile to libU1/conan
WARN: libD/conan: requirement libU2/[^4.1.0] overridden by your conanfile to libU2/conan
WARN: libD/conan: requirement libA/[^7.1.0] overridden by your conanfile to libA/conan
WARN: libC/conan: requirement libB/[^4.2.0] overridden by testFrameworkForC/conan to libB/4.2.0+alias.conan.test.build
```

The `libB/conan` and `libA/conan` is what is explicitly set in `app`.
In `testFrameworkForC`  we have set the requirements using version ranges: `libC/[^4.1.0]@` and `libB/[^4.2.0]`. Same for the other libs.
Currently `libA/7.1.0+alias.conan.test.build` is an alias to `libA/conan`, `libB/4.2.0+alias.conan.test.build` and alias to `libB/conan` (this aliases are supposed to get removed in the future, and from my understanding should not be related to the problem)

Is my assumption about `build_requires` wrong, and `testFrameworkForC` (and similar test frameworks) should stay as a normal (private) `requires`?
Or is this just a current limitation/bug of `build_requires`, and in theory `build_requires` would be the correct way to specify the requirement of the unit test on `testFrameworkForC`?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: lieser
issue_8161: state: open
title: [bug] Wrong auto path_flavor in tools.unix_path if MinGW installed with Msys2
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: gcc10
  * Conan version: 1.32.0
  * Python version: 3.7.1

### Steps to reproduce (Include if Applicable)

- Install MinGW with msys2.
- On Windows, build a recipe relying on environment variables defined in `package_info()` of `autoconf` recipe in CCI (libxcrypt for example: https://github.com/conan-io/conan-center-index/issues/3356). These environment variables use `tools.unix_path()` with default `path_flavor`
=> /mnt will be added to path, leading to error. I guess that it detects WSL for some weird reason: https://github.com/conan-io/conan/blob/61d75d945a0e16a56a320926789cff2d297ac76a/conans/client/tools/win.py#L624)

Surprinsingly, if I download a prebuild mingw without msys2, I can't reproduce this error (but I've tested on another computer with WSL disabled).

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
/usr/bin/bash: /mnt/c/Users/spaceim/.conan/data/autoconf/2.69/_/_/package/ca33edce272a279b24f87dc0d4cf5bbdcffbc187/bin/autoreconf.exe: No such file or directory
```

user: SpaceIm
issue_8152: state: open
title: [feature] Be able to not set dependency option as opposed to setting it to default
body: <!-- What is your suggestion? Please be as specific as possible! -->

Consider this scenario:
- Package `A` requires packages `B` and `C`
- Package `B` requires package `C`
- Package `C` has and option `someOpt`, with default value `val0`
- Package `A` does not care about `C:someOpt`
- Package `B` wants to set `C:someOpt` to some other value, `val1`

In the above scenario I have to set `C:someOpt` to `val1` in `A` in order to avoid building `C` with the default option. However `A` does not care about this option. If later on `B` decides it wants to use `val2`, `A` has to update its recipe to `val2`.

Q) Is my understanding accurate? There is no way currently to say `A` does not care about an option, is there?

My suggestion is to introduce a mechanism for consumers to say they don't care about a particular option (and possibly also to be able to say they don't care about any options not explicitly set).

- [✓] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: daravi
issue_8145: state: open
title: [question] find_package with components behavior
body: I've recently started using the (still under development) recipe of boost which introduces components support and I've noticed a strange behavior when we use `findBoost.cmake` when we specify the components we want instead of looking for the whole boost. Maybe it is the normal behavior, I'm not sure.
The "issue" that I'm seeing is that if you ask `find_package()` to provide you with some of the boost components, the log makes it look like conan still looks for all of them. This a portion of the `test_package` of said recipe:

```
    if(WITH_RANDOM)
        find_package(Boost COMPONENTS random REQUIRED)
        add_executable(random_exe random.cpp)
        target_link_libraries(random_exe PRIVATE Boost::random)
    endif()
```

So I would expect `FindBoost.cmake` to give me just `boost.random`. The log shows:

```
-- Conan: Using autogenerated FindBoost.cmake
-- Found Boost: 1.74.0 (found version "1.74.0") 
-- Conan: Component 'random' found in package 'Boost'
-- Library boost_program_options found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_program_options.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_program_options.a
-- Library boost_stacktrace_noop found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_noop.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_noop.a
-- Library boost_wserialization found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_wserialization.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_wserialization.a
-- Library boost_stacktrace_addr2line found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_addr2line.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_addr2line.a
-- Library boost_stacktrace_backtrace found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_backtrace.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_backtrace.a
-- Library boost_stacktrace_basic found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_basic.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_basic.a
-- Library boost_math_c99f found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99f.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99f.a
-- Library boost_timer found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_timer.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_timer.a
-- Library boost_math_tr1 found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1.a
-- Library boost_math_c99l found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99l.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99l.a
-- Library boost_math_c99 found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99.a
-- Library boost_math_tr1l found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1l.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1l.a
-- Library boost_math_tr1f found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1f.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1f.a
-- Library boost_nowide found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_nowide.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_nowide.a
-- Library boost_wave found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_wave.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_wave.a
-- Library boost_unit_test_framework found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_unit_test_framework.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_unit_test_framework.a
-- Library boost_prg_exec_monitor found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_prg_exec_monitor.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_prg_exec_monitor.a
-- Library boost_test_exec_monitor found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_test_exec_monitor.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_test_exec_monitor.a
-- Library boost_graph found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_graph.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_graph.a
-- Library boost_serialization found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_serialization.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_serialization.a
-- Library boost_contract found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_contract.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_contract.a
-- Library boost_iostreams found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_iostreams.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_iostreams.a
-- Library boost_type_erasure found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_type_erasure.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_type_erasure.a
-- Library boost_coroutine found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_coroutine.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_coroutine.a
-- Library boost_fiber found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_fiber.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_fiber.a
-- Library boost_context found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_context.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_context.a
-- Library boost_log_setup found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_log_setup.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_log_setup.a
-- Library boost_log found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_log.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_log.a
-- Library boost_regex found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_regex.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_regex.a
-- Library boost_filesystem found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_filesystem.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_filesystem.a
-- Library boost_random found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_random.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_random.a
-- Library boost_locale found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_locale.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_locale.a
-- Library boost_thread found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_thread.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_thread.a
-- Library boost_date_time found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_date_time.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_date_time.a
-- Library boost_atomic found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_atomic.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_atomic.a
-- Library boost_exception found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_exception.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_exception.a
-- Library boost_container found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_container.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_container.a
-- Library boost_chrono found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_chrono.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_chrono.a
-- Library boost_system found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_system.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_system.a
-- Library boost_numpy27 found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_numpy27.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_numpy27.a
-- Library boost_python27 found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_python27.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_python27.a
-- Conan: Using autogenerated FindZLIB.cmake
-- Found ZLIB: 1.2.11 (found version "1.2.11") 
-- Library z found /home/eric/brewst/.conan/data/zlib/1.2.11/brewst/stable/package/1d877a3df840030e6a8abb74c5ffb9088d08b47a/lib/libz.a
-- Found: /home/eric/brewst/.conan/data/zlib/1.2.11/brewst/stable/package/1d877a3df840030e6a8abb74c5ffb9088d08b47a/lib/libz.a
-- Conan: Using autogenerated FindBZip2.cmake
-- Found BZip2: 1.0.8 (found version "1.0.8") 
-- Library bz2 found /home/eric/brewst/.conan/data/bzip2/1.0.8/eriff-dev/stable/package/a5875aed3fc7ae8dd0488f7e5e99acbc480d721d/lib/libbz2.a
-- Found: /home/eric/brewst/.conan/data/bzip2/1.0.8/eriff-dev/stable/package/a5875aed3fc7ae8dd0488f7e5e99acbc480d721d/lib/libbz2.a
-- Conan: Using autogenerated FindIconv.cmake
-- Found Iconv: 1.16 (found version "1.16") 
-- Library iconv found /home/eric/brewst/.conan/data/libiconv/1.16/eriff-dev/stable/package/1d877a3df840030e6a8abb74c5ffb9088d08b47a/lib/libiconv.a
-- Found: /home/eric/brewst/.conan/data/libiconv/1.16/eriff-dev/stable/package/1d877a3df840030e6a8abb74c5ffb9088d08b47a/lib/libiconv.a
-- Library boost_python27 found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_python27.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_python27.a
-- Library boost_numpy27 found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_numpy27.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_numpy27.a
-- Library boost_system found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_system.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_system.a
-- Library boost_chrono found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_chrono.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_chrono.a
-- Library boost_container found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_container.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_container.a
-- Library boost_exception found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_exception.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_exception.a
-- Library boost_atomic found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_atomic.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_atomic.a
-- Library boost_date_time found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_date_time.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_date_time.a
-- Library boost_thread found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_thread.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_thread.a
-- Library boost_locale found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_locale.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_locale.a
-- Library boost_random found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_random.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_random.a
-- Library boost_filesystem found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_filesystem.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_filesystem.a
-- Library boost_regex found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_regex.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_regex.a
-- Library boost_log found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_log.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_log.a
-- Library boost_log_setup found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_log_setup.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_log_setup.a
-- Library boost_context found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_context.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_context.a
-- Library boost_fiber found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_fiber.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_fiber.a
-- Library boost_coroutine found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_coroutine.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_coroutine.a
-- Library boost_type_erasure found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_type_erasure.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_type_erasure.a
-- Library boost_iostreams found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_iostreams.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_iostreams.a
-- Library boost_contract found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_contract.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_contract.a
-- Library boost_serialization found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_serialization.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_serialization.a
-- Library boost_graph found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_graph.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_graph.a
-- Library boost_test_exec_monitor found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_test_exec_monitor.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_test_exec_monitor.a
-- Library boost_prg_exec_monitor found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_prg_exec_monitor.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_prg_exec_monitor.a
-- Library boost_unit_test_framework found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_unit_test_framework.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_unit_test_framework.a
-- Library boost_wave found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_wave.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_wave.a
-- Library boost_nowide found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_nowide.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_nowide.a
-- Library boost_math_tr1f found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1f.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1f.a
-- Library boost_math_tr1l found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1l.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1l.a
-- Library boost_math_c99 found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99.a
-- Library boost_math_c99l found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99l.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99l.a
-- Library boost_math_tr1 found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_tr1.a
-- Library boost_timer found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_timer.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_timer.a
-- Library boost_math_c99f found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99f.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_math_c99f.a
-- Library boost_stacktrace_basic found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_basic.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_basic.a
-- Library boost_stacktrace_backtrace found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_backtrace.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_backtrace.a
-- Library boost_stacktrace_addr2line found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_addr2line.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_addr2line.a
-- Library boost_wserialization found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_wserialization.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_wserialization.a
-- Library boost_stacktrace_noop found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_noop.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_stacktrace_noop.a
-- Library boost_program_options found /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_program_options.a
-- Found: /home/eric/brewst/.conan/data/boost/1.74.0/eriff-dev/stable/package/0fdc43fcd9ad9cbd2530f4b832dbf5f2bb7ec3d1/lib/libboost_program_options.a
-- Configuring done
-- Generating done
```

Which is incredibly chatty, but also makes it look like is looking for all the targets.
I have a project which, just like these `test_package`, calls `find_package(Boost COMPONENS xxxx)` multiple times which ends up producing thousands of lines in the log and makes the configure step of CMake way slower compared with the "official" `findBoost.cmake` package.

Anyways, could someone take a look at this and tell me if it is expected behavior?

Thanks!
user: ericriff
labels: component: ux: No changes to core business logic
issue_8127: state: open
title: conan returns package not found whithout anonymous usage enabled in artifactory from #4930
body: In #4930 the reason for "package not found" was in the artifactory-return-code-404 (instead of 403).
That is an explanation **why** the behavior of conan is wrong, but it does not remedy the behavior. i.e. it's **still broken**.

expected behavior:
- When trying to find a package on an artifactory-repository, but the permissions are insufficient for that request, conan must always behave accordingly:
-- if the user has logged in but does not have permissions, show "insufficient permissions"
-- if the user has NOT logged in (anonymous), conan must ask for credentials.

How this is done between artifactory, it's return-code and conan does not matter. The user must be **informed correctly** what is going on.
user: TamiKra
issue_8123: state: open
title: [bug] "conan install .." not working in pwsh
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 Version 2004
  * Compiler+version: 
  * Conan version: 1.31.4 and 1.30.2 (just checked if this problem was from a new version)
  * Python version: ? (used binaries from scoop)

### Steps to reproduce (Include if Applicable)
Follow steps [here](https://docs.conan.io/en/latest/getting_started.html) until `conan install ..`.

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
conan install ..
'[path to my conan.exe]/conan.exe' is not a Conan command. See 'conan --help'.

ERROR: Unknown command '[path to my conan.exe]/conan.exe'
```
<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

### Additional Information
This might not be a problem with Conan, but the Powershell. The problem can be solved via `conan install ./..` (note the `./..` instead of `..`). I just thought this should be documented somewhere.

user: RefusesNames
issue_8120: state: open
title: [feature] conan config install from a conan package
body: [`conan config install` currently supports getting configs from a git repository, local file or folder or zip file (local or http)](https://docs.conan.io/en/latest/reference/commands/consumer/config.html#). I would like to be able to do this from a conan recipe.

Why? Because I would like to use conan to manage my dependencies but find that I am instead using git for my configs. This is particularly annoying with managing credentials in Docker -- I need Docker to have access both to an external git remote and a conan remote. Having everything in the conan remote would be easier and I think it makes some sense to manage the dependencies of my conan project using conan! It would also allow for versioning.

I figure I could probably home-spin this myself by making a conan package for my conan configs, installing them, and then using `conan config install` on the directory they were installed, but that seems more messy.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: peter-moran
labels: component: ux: No changes to core business logic
issue_8109: state: open
title: [question] problem with collecting .so libs that have a . in the name
body: I'm using conan to collect libraries (.so) in a specific directory.
Edit: Since it's not obvious. I'm using cmake.

All libraries are found, but the ones that don't have a lib prefix AND a `.` in the name are not added correctly.
I get an linker error. You can see in the log below, that all libs have the full path appended, but those "special name" libs are added via -l and thus fail

is this a bug?

Idk if you need more information. those are just external libraries (not built by me) in directory and i use this in the conanfile packaging step: 
```
        self.copy("*", "bin", "IOWA/SDK/bin/"
        self.cpp_info.libdirs = ["lib", "bin"]  # Default value is 'lib', we have so / dll files in bin
        self.cpp_info.libs = tools.collect_libs(self)
```

to gather those libraries and use them.
most start with `lib` and do not have dots in the name, but a few do...

```
[881/3885] Linking CXX shared library lib/libOaBasicsV40.so

FAILED: lib/libOaBasicsV40.so 

: && /usr/bin/c++ -fPIC -Wall -O3 -g -DNDEBUG   -shared -Wl,-soname,libOaBasicsV40.so -o lib/libOaBasicsV40.so Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/OaBasics_NoPosix_autogen/mocs_compilation.cpp.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/OaFileSystemWatcher.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/FileSystemWatcherQtImpl.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/GetTask.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/IOSUtil.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/Mutex.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/OaNoPosix.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/OaSharedLib.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/OPCBrowser.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/OSInfo.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/ScopeMutex.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/SecureSocket.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/Socket.cxx.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/SslWrapper.cpp.o Libs/OaBasics/NoPosix/CMakeFiles/OaBasics_NoPosix.dir/Win32Utils.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/Adler32.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/CRC.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/Cipher.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/CryptoHash.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/HTTP.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/MsgBuffer.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/OaFileSys.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/OaResources.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/ServerSocket.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/OaConfigFile.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/OaStrUtil.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/TcpLineSocket.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/TcpSocket.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/TimeDiff.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/Timer.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/UdpSocket.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/LangIdConvertor.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/LangTextParser.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/SinglePeerConnConfig.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/PeerConnConfig.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/DistPeerConnConfig.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/VisibleDistSystemEntry.cxx.o Libs/OaBasics/Utilities/CMakeFiles/OaBasics_Utilities.dir/ReduPeerConnConfig.cxx.o Libs/OaBasics/Variables/CMakeFiles/OaBasics_Variables.dir/CmdHdlVar.cxx.o Libs/OaBasics/Variables/CMakeFiles/OaBasics_Variables.dir/ConnHdlVar.cxx.o Libs/OaBasics/Variables/CMakeFiles/OaBasics_Variables.dir/FileVar.cxx.o Libs/OaBasics/Variables/CMakeFiles/OaBasics_Variables.dir/IDispatchVar.cxx.o Libs/OaBasics/Variables/CMakeFiles/OaBasics_Variables.dir/RecHdlVar.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/ChallengeHandler.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/ChallengeHandlerList.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/ChallengeHandlerFactory.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/Crypto.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/CryptoQt.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/CryptoSslWrapper.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/Envelope.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/Key.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/KeySsl.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/KeyWinCertStore.cxx.o Libs/OaBasics/Crypto/CMakeFiles/OaBasics_Crypto.dir/Signature.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/Average0Accu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/Average1Accu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/AverageAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/BaseAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/CountAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/CountBitChangesAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/CyclicPG.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/DiffAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/EndValueAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/FloatingAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/Integral0Accu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/Integral1Accu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/IntermitCyclicPG.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/MaxAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/MaxTimeAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/MinAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/MinTimeAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/NextValidIntermitTime.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/NextValidListTime.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/NextValidTime.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/PeriodAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/SampleAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/SumAccu.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/SyncedCyclicPG.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/SyncedPG.cxx.o Libs/OaBasics/Accu/CMakeFiles/OaBasics_Accu.dir/TimeBitStateAccu.cxx.o Libs/OaBasics/Core/CMakeFiles/OaBasics_Core.dir/LanguageDefRec.cxx.o Libs/OaBasics/Core/CMakeFiles/OaBasics_Core.dir/LanguageFallbackTable.cxx.o Libs/OaBasics/Core/CMakeFiles/OaBasics_Core.dir/OaApplicationNames.cxx.o Libs/OaBasics/Core/CMakeFiles/OaBasics_Core.dir/OaLocale.cxx.o Libs/OaBasics/Core/CMakeFiles/OaBasics_Core.dir/OaLocaleImpl.cxx.o Libs/OaBasics/Core/CMakeFiles/OaBasics_Core.dir/OaStringToken.cxx.o  -Wl,-rpath,/work/WinCCOA/****/linux-debian-x86_64/****/ExternLibs/Qt4/lib:/root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin: ExternLibs/Qt4/lib/libQt5Core.so.5.15.1 ExternLibs/Qt4/lib/libQt5Network.so.5.15.1 -lz /root/.conan/data/openssl/1.1.1f/ETMConanRepo/stable/package/53e971e3e755dae548d0fd37209eb2f392b21992/lib/libcrypto.a /root/.conan/data/openssl/1.1.1f/ETMConanRepo/stable/package/53e971e3e755dae548d0fd37209eb2f392b21992/lib/libssl.a -ldl /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libCfCore.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libRTILtrace.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libStreamingFileTransfer.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILAggregationTimer.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILAlarmService.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILAuditService.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILAuditTrailPluginSQLite3.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILAuditTrailService.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILCDSService.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILComDrv.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILContextLogging.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILContextLoggingPluginSQLite.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILGIDSService.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILLoggingBase.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILLoggingConfiguration.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILOnlineBackup.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILPaHostV1.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILPaHostV2.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILPersistentBuffer.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILPmonClient.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILQueryFilterAssembly.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILRdfMerge.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILRdfMigration.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILRecurrenceCalculator.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILStandardAggregationPlugin.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILbasics.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILchromApi.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILclientSideLibrary.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILmanager.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILpersistency.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILpersistencyDataMan.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libWCCILresources.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libpq.so /root/.conan/data/iowa/5289_04.00.00.00_14.00.0001/ETMConanRepo/stable/package/6db3fd1a57086e2d41f7434cc560e2d180b4dbfc/bin/libpqxx.so -lhmitr.eapi.license -lhmitr.eapi.main -lhmitr.eapi.serverconfig -lhmitr.eapi.tracing -lhmitr.eapi.transfer -lhmitr.scs.common -lhmitr.scs.rt /root/.conan/data/openssl/1.1.1f/ETMConanRepo/stable/package/53e971e3e755dae548d0fd37209eb2f392b21992/lib/libcrypto.a && :

/usr/bin/ld: cannot find -lhmitr.eapi.license

/usr/bin/ld: cannot find -lhmitr.eapi.main

/usr/bin/ld: cannot find -lhmitr.eapi.serverconfig

/usr/bin/ld: cannot find -lhmitr.eapi.tracing

/usr/bin/ld: cannot find -lhmitr.eapi.transfer

/usr/bin/ld: cannot find -lhmitr.scs.common

/usr/bin/ld: cannot find -lhmitr.scs.rt```
user: SimplyLiz
issue_8102: state: open
title: Best practise for unit test integration with CMake and Conan
body: <!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Currently building on OSX, but eventually needs cross-platform support (Win, Linux, wasm).

I'm trying to integrate unit testing into my library using plain default CMake generator and `CMakeLists.txt` files, and would like advice on the best practises for that in terms of:

1. project layout (folder and project files structure: do I need a Conan project for my unit tests, or can only CMake suffice?)
2. Conan dependencies handling (what if my library to test uses Conan for dependencies, how to draw those into my unit test CMake project)
3. rpath handling for the unit test project (the unit test executable needs to link to the build folder of the library to test and do we need to copy the libraries out to the same folder? or can it just be hardcoded rpaths as it is unit testing and used when built from source on client machine through Conan build process)

I have a working CMake project and Conan recipe that builds static or shared version of my library, as well as a `test_package` Conan recipe to test it. This all works fine.

I'm struggling getting unit testing working via CTest and Conan's CMake build helper `CMake.test()` function which gets called by my library's main Conan recipe `build()` method. I'm getting rpath handling issues, but I think this stems deeper in terms of project structure layout and best practises.
I've read various discussion I could get on rpath handling, and tried various options, but my unit test executable points to `@rpath/libXXX.dylib` and (on OSX) there is no rpath encoded into the unit test executable. My library top-level `CMakeLists.txt` includes the unit test CMake project via `add_subdirectory()` if unit tests are to be built via a flag.

Are there any best-practice templates, examples? Possible options and direction would be appreciated.

Herewith a truncated example of what I have set up so far:

Top-level library `CMakeLists.txt`
```
cmake_minimum_required(VERSION 3.13)
project(MyLibrary)

set(CMAKE_CXX_STANDARD 17)
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

....
....

add_library("${LIBNAME}" ${LIB_MODE} ${SRCS})

target_link_libraries("${LIBNAME}" PRIVATE ${CONAN_LIBS})
target_include_directories("${LIBNAME}"
        PUBLIC
            ${CMAKE_CURRENT_SOURCE_DIR}/include
        PRIVATE
            ${CMAKE_CURRENT_SOURCE_DIR} ${CONAN_INCLUDE_DIRS}
        )
target_compile_definitions("${LIBNAME}" PUBLIC ${LIB_MODE_DEFINITIONS})

if(LIB_BUILD_TESTS)
    add_definitions(-DUNITTEST)
    enable_testing()
    add_subdirectory("unittests")
endif(LIB_BUILD_TESTS)
```

Relevant parts of library Conan recipe:
```

def build(self):
   self.output.info("Running build...")
   cmake = self._configure_cmake()
   cmake.build()
   # run unit tests only if env variable is set and we are not cross-building (as we cannot run tests if we built for a different target)
   if self._run_tests:
       cmake.test(output_on_failure=True)
```

Unit test CMake project `unittests/CMakeLists.txt`:
```
cmake_minimum_required(VERSION 2.8.12)
project(MyLibraryUnitTests CXX)

set(CMAKE_CXX_STANDARD 17)

add_executable("${APPNAME}" ${SRCS})

target_include_directories("${APPNAME}"
        PRIVATE
        ${CMAKE_CURRENT_SOURCE_DIR}
        ${CONAN_INCLUDE_DIRS}
        "../" "../include" # required due to unit tests accessing internal headers and not just public headers of project
        )

target_link_directories("${APPNAME}" PUBLIC "${CMAKE_BINARY_DIR}/lib" ${CONAN_LIB_DIRS})
target_link_libraries("${APPNAME}" MyLibrary ${CONAN_LIBS})

add_test(NAME "${APPNAME}"
          WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/bin
          COMMAND ${APPNAME})

```













user: SeanSnyders
issue_8089: state: open
title: [feature] Audit (block) system environment variables
body: Conan does keep the system environment uintact and will thus pick up (system) environment variables.
Because build environments differ, this can cause builds to inexplicably fail.
See e.g. https://github.com/conan-io/conan-center-index/issues/3619.

I think it would be useful to have a way to audit these sneaky variables.
As a first step, printing these variables variables before building would be useful to have a paper trail what variables are set.

Conan being a C/C++ package manager, I think only the relevant variables should be logged.
Such as: PKG_CONFIG_PATH, CC, CXX, CFLAGS, CXXFLAGS, CPPFLAGS, LIBS, CC_BUILD, CXX_BUILD, CC_FOR_BUILD, CXX_FOR_BUILD, CC_BUILD_FLAGS, ... (All variables with CC/CXX/CFLAGS/CXXFLAGS/LDFLAGS/LIBS/... in them)

Extending on this feature, the following things become possible:
- make it possible to error when a build system environment variable is detected (fail hard to attract attention to a potential problem)
- make it possible to block these build environment variables in a profile (I think this would have avoided https://github.com/conan-io/conan-center-index/issues/3619) by removing them

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: madebr
labels: component: Build: Build helpers, build systems..
issue_8087: state: open
title: [bug] 1.31.0 breaks building packages in parallel 
body: Since upgrading to 1.31.0 my parallel builds are failing when multiple process try to access the downloaded conan_package.tgz.  Seems to be related to the new feature #7886 to hold this file in the cache.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 64-bit
  * Compiler+version: n/a
  * Conan version: 1.31.0
  * Python version: 3.7.3

### Steps to reproduce (Include if Applicable)
In parallel:
```
conan install pkga/0.1@user/testing#<rref>--build=pkga/0.1@user/testing#<rref> --build=missing --lockfile=locks/app_debug.lock --lockfile-out=locks/app_debug_node1_updated.lock 
conan install pkgb/0.1@user/testing#<rref>--build=pkgb/0.1@user/testing#<rref> --build=missing --lockfile=locks/app_debug.lock --lockfile-out=locks/app_debug_node2_updated.lock 
```

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
Traceback (most recent call last):

  File "c:\python37\lib\shutil.py", line 398, in _rmtree_unsafe

    os.unlink(fullname)

PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Jenkins\\workspace\\pkgb\\.conan\\data\\pkgb\\0.1\\user\\testing\\dl\\pkg\\<pkg_id>\\conan_package.tgz'

```
user: GordonJess
issue_8068: state: open
title: [bug] Inconsistent processing of config_options and assigning overridden values
body: ### Environment Details (include every applicable attribute)
  * Conan version: 1.31.1
  * Python version: 3.8.5

## conanfile.py
```
from conans import ConanFile

class TestConan(ConanFile):

    name = "test"
    version = "1.0"

    options = {"testing": [True, False]}
    default_options = {
        "testing": False
    }

    def config_options(self):
        self.options.testing = True

    def requirements(self):
        self.output.info(f"testing is: {self.options.testing}")
```

## Test
```
$ conan create .
test/1.0: testing is: True
$ conan create . -o testing=False
test/1.0: testing is: False
$ conan install .
conanfile.py (test/1.0): testing is: True
$ conan install . -o testing=False
conanfile.py (test/1.0): testing is: True
```

## Original use-case
I'd like to provide different default options depending on whether package is being developed (i.e. dependencies are installed via `conan install <path> ...`) or created / consumed as a dependency (or via `conan create <path>`) but in all cases it should be possible to override this default.

My initial idea was to make `default_options` a property and take into account `self.in_local_cache`.

After discussion @ericLemanissier pointed out that `config_options` can be used for this purpose and indeed values set in `config_options` are later overridden with ones from the command line in most cases (See https://github.com/conan-io/conan-center-index/pull/3341#issuecomment-717958354) but one: when conan install command is called with path. In this case value set in `config_options` always takes precedence.

My wild guess this has something to do with how options are propagated to the upstream packages and how graph is built for those different cases (including an extra virtual conanfile).


user: ytimenkov
issue_8058: state: open
title: [question] Parallel build steps
body: Suppose you've got the following recipe:

    class MinimalConan(ConanFile):
        name = "minimal"
        version = "0.0"

        def build(self):
            self.run("some heavy I/O bound and long lasting process")
            self.run("another heavy I/O bound and long lasting process")

Since the two `run` commands are independent from each other, I'd like to run them in parallel. The most straightforward approach would be to use Python's multiprocess module:

    class MinimalConan(ConanFile):
        name = "minimal"
        version = "0.0"

        def worker(self, command):
            self.run(command)

        def build(self):
            with Pool(processes=2) as pool:
                first = pool.apply_async(MinimalConan.worker, args=(self, "some heavy I/O bound and long lasting process"))
                second = pool.apply_async(MinimalConan.worker, args=(self, "another heavy I/O bound and long lasting process"))
                first.get()
                second.get()

But this doesn't work and raises an exception:

    ERROR: minimal/0.0@me/testing: Error in build() method, line 21
            first.get()
            PicklingError: Can't pickle <class '761fd480-25c5-11eb-be1d-74e5f9c92489.MinimalConan'>: import of module '761fd480-25c5-11eb-be1d-74e5f9c92489' failed

I suppose this has something to do with the fact that Conan loads the recipes dynamically at runtime. Such behavior seems to be incompatible with the multiprocess module since it transfers internal state between processes via pickle.

Is there another way to run these two commands in parallel?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: pwaehnert
issue_8045: state: open
title: [feature] MSBuild helper: Automatic selection of vcvars_ver based on compiler.version and compiler.toolset
body: Although it is already possible to manually set the `vcvars_ver` version, I think it would be good to have the option to let Conan automatically detect and chose the correct version. Maybe even consider making this the default.

Use case for us:
In our CI we use the Build Tools for Visual Studio 2019, which also includes a compiler for Visual Studio 2017 (platform toolset (`compiler.toolset` in Conan) v141, VCToolsVersion (`vcvars_ver`) 14.16).

When we build in the CI for compiler toolset v141, the compilation fails without specifying the `vcvars_ver` argument:
```
error MSB8052: MSVC Toolset Version '14.27.29110' is not compatible with 'v141' Platform Toolset. Please either change Platform Toolset to v142 or MSVC Toolset Version (VCToolsVersion property) to  the version with the format '14.1*.*'. To use default MSVC Toolset Version for a given Platform Toolset don't set VCToolsVersion property. 
```
As we also want to support building using other platform toolsets (e.g. v142), we do not want to hardcore the `vcvars_ver` argument.

Visual Studio itself has in e.g. `C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build` already a mapping of (installed/supported) platform toolset to VCToolsVersion, which I think makes sense to reuse.
Another possibility would be using an internal mapping in Conan using the short notation for vcvars_ver, e.g. `v141`->`14.1`, `v142`->`14.2`.

We currently use the following code to automatically select the `vcvars_ver` to set:
```python
    def _get_vcvars_ver(self, compiler_version, compiler_toolset):
        # type: (conans.model.settings.SettingsItem, conans.model.settings.SettingsItem) -> None
        ''' Select the correct VCToolsVersion to use based on compiler version and toolset '''
        if compiler_toolset.value is None:
            self.output.info(
                "Using default VCToolsVersion (no specific toolset provided)")
            return None
        vc_tools_version_dir = os.path.join(tools.vs_installation_path(
            compiler_version.value), "VC", "Auxiliary", "Build")
        vc_tools_version_file = os.path.join(
            vc_tools_version_dir, "Microsoft.VCToolsVersion.%s.default.txt" % compiler_toolset.value)
        if os.path.isfile(vc_tools_version_file):
            content = tools.load(vc_tools_version_file)
            vc_tools_version = content.partition("\n")[0].strip()
            self.output.info("Using VCToolsVersion %s" % vc_tools_version)
            return vc_tools_version
        self.output.info(
            "Using default VCToolsVersion (no specific version found for toolset %s)" % compiler_toolset)
        return None
```

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: lieser
issue_8028: state: open
title: [bug] Documentation does not list self.cpp_info.frameworks
body: The [`cpp_info` documentation](https://docs.conan.io/en/latest/reference/conanfile/methods.html#cpp-info) does not mention `self.cpp_info.frameworks`.
Is this attribute, aimed for Macos, valid and supported?
It's used by some recipes at conan-center-index.

user: madebr
issue_8025: state: open
title: [bug] CMAKE_SYSTEM_PROCESSOR isn't set
body: from https://github.com/conan-io/conan-center-index/pull/3392
/cc @KristianJerpetjon

[CMAKE_SYSTEM_PROCESSOR](https://cmake.org/cmake/help/v3.7/variable/CMAKE_SYSTEM_PROCESSOR.html) is not set by conan in CMake build helper.
as result, cross-compiling for armv8 fails for certain recipes (at least **libpng** and **libjpeg-turbo**)

```
if the variable is wrong then it selects sse instead of neon.. no need to explain that bit

you get a linker error when trying to link sse assembly into arm compiled code which is obvius
```

<!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: macOS Catalina
  * Compiler+version: Apple clang version 11.0.3 (clang-1103.0.32.62)
  * Conan version: Conan version 1.31.0-dev
  * Python version: Python 3.8.0

### Steps to reproduce (Include if Applicable)

I reproduced it by running:
```
conan create . libjpeg-turbo/2.0.5@ -k -pr ios
```
out:
```
CMake Warning at source_subfolder/simd/CMakeLists.txt:5 (message):
  SIMD extensions not available for this CPU ().  Performance will suffer.
```
profile:
```
Configuration for profile ios:

[settings]
os=iOS
os.version=9.0
arch=armv8
compiler=apple-clang
compiler.version=11.0
compiler.libcxx=libc++
build_type=Release
os_build=Macos
arch_build=x86_64
[options]
[build_requires]
[env]
```


### Logs (Executed commands with output) (Include/Attach if Applicable)

```
cmake_minimum_required(VERSION 2.8.12)
project(cmake_wrapper)
message("CONAN_CMAKE_SYSTEM_PROCESSOR  $ENV{CONAN_CMAKE_SYSTEM_PROCESSOR} ")
message("CMAKE_SYSTEM_PROCESSOR ${CMAKE_SYSTEM_PROCESSOR}")
include(conanbuildinfo.cmake)
conan_basic_setup(NO_OUTPUT_DIRS)
add_subdirectory("source_subfolder")
Result when running conan create is.. 
CONAN_CMAKE_SYSTEM_PROCESSOR   
```

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SSE4
issue_8019: state: open
title: [bug] Option gets set for private requirement of requirement.
body: When a consumer package sets an option for a requirement which is also used as a private requirement by another of its requirements this options gets also set for that private requirement, leading to possible errors.

This goes against the following statement from https://docs.conan.io/en/latest/reference/conanfile/attributes.html#options:
> a dependency can be declared as private if it is going to be fully embedded and hidden from consumers of the package 

See below for a simple reproduction.

### Environment Details
  * Operating System: Windows 10
  * Conan version: 1.31.0
  * Python version: 3.9.0

### Steps to reproduce:

`common_old/conanfile.py`:
```python
from conans import ConanFile

class CommonConan(ConanFile):
    name = "common"
    version = "1.0"
```

`req/conanfile.py`:
```python
from conans import ConanFile

class ReqConan(ConanFile):
    name = "req"
    version = "1.0"

    requires = [("common/1.0@test/test", "private"), ]
```

`common_new/conanfile.py`:
```python
from conans import ConanFile

class CommonConan(ConanFile):
    name = "common"
    version = "2.0"

    options = {"new_opt": [True, False]}
```

`main/conanfile.py`:
```python
from conans import ConanFile

class MainConan(ConanFile):
    name = "main"
    version = "1.0"

    requires = ["common/2.0@test/test", "req/1.0@test/test"]

    default_options = {"common:new_opt": False}
```

Export packages of the requirements:
```
conan export common_old test/test
conan export req test/test
conan export common_new test/test
```

Try to create the main package:
```
conan create main test/test
```

This fails with the following error:
```
ERROR: common/1.0@test/test: option 'new_opt' doesn't exist
Possible options are []
```
user: thvdburgt
issue_8017: state: open
title: [feature] Enable override of requirements from "conan install" CLI
body: When developing upstream packages and building downstream packages it would be convenient to override dependencies from command line.

For example, building `pkgB`, dependent from `pkgA`. `pkgB` depends on version `pkgA/1.0.0`. I am changing `pkgA` and create a new version in local cache `pkgA/1.1.0`. Convenient command to test the new package would be:

    conan install . --require pkgA/1.1.0

The result would be the same as changing the version in `conanfile.py` of `pkgA`.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: klimkin
issue_8013: state: open
title: Conan omits empty directories when compressing a package
body: When Conan compresses a built package before upload, it omits all empty directories of the package. In some cases it can cause issue.

Example:
```py
from conans import ConanFile
import os


class EmptyDirTestConan(ConanFile):
    name = "empty-dir-test"
    version = "1.0"
    settings = None

    def build(self):
        os.makedirs(os.path.join(self.package_folder, "test", "empty_dir"))
        os.symlink("empty_dir", os.path.join(self.package_folder, "test", "link"))
```

We use two repositories for Conan packages (development and production). Packages are proposed from dev to prod when ready. Proposal is done via a sequence of `conan download` and `conan upload`. And here we face the issue. If a package contains an empty directory and a symlink which points to that directory, then we can't transfer it from one repo to another. When Conan uploads the package to a dev repo, it creates an archive without empty directories, thus symlinks became broken. After we do a transfer (download/upload), and Conan complains that the package has broken symlinks. I know that this check could be disabled, but this is not a proper solution.

### Environment Details (include every applicable attribute)
  * Operating System+version: Arch Linux (but it also reproduces on other distros)
  * Conan version: 1.31.0
  * Python version: 3.8.6
user: kdsx
issue_8012: state: open
title: [bug] build fails if build folder is only partially cleaned.
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 
  * Conan version: 1.28.0 
  * Python version:  3.7 latest windows cpython

### Steps to reproduce (Include if Applicable)

This is not critical but it feels still a bit like a bug:

1. build a binary package that that uses deeply nested directory structure.
2. clean the build folder with windows rmdir from the console. Because of "windows" rmdir in our case resulted in state where build directory was cleaned only partially. Eg, directory like `/d/conan_build_root/spdlog/1.5.0/vendor/stable/build/479e5c321685f6e20cbbf93c38ae334c54ade580` still existed and it had a directory in it with few sub directories and bunch of files there still .. 
3. re-build the package again.
4. build fails with exception.


First off, our use of rmdir was easily fixed so this is definitely not a blocker but i feel like there's some logic issue somewhere within conan that doesn't trigger the cleanup  (because only the build folder with its subs exists, everything else is gone!) during the build and then fails when build directory is being created .. 


### Logs (Executed commands with output) (Include/Attach if Applicable)

```
Traceback (most recent call last):
File "J:\j\workspace\vendor-spdlog-pipeline\spdlog\spdlog_venv\lib\site-packages\conans\client\installer.py", line 113, in _prepare_sources
shutil.copytree(source_folder, build_folder, symlinks=True)
File "C:\python3\lib\shutil.py", line 324, in copytree
os.makedirs(dst)
File "C:\python3\lib\os.py", line 221, in makedirs
mkdir(name, mode)
FileExistsError: [WinError 183] Cannot create a file when that file already exists: 'D:\\conan_build_root\\spdlog\\1.5.0\\vendor\\stable\\build\\479e5c321685f6e20cbbf93c38ae334c54ade580'
```
user: rasjani
issue_8003: state: open
title: [feature] Interlize chmod as Conan tool
body: Hi!

As you may know, [chmod](https://linux.die.net/man/1/chmod) is a nice Unix tool, which is used to handle file permission.

On Python, we have [os.chmod](https://docs.python.org/3/library/os.html#os.chmod), but it's limited in terms of solution on Windows (see #7966). 

Doing a quick [search](https://github.com/conan-io/conan-center-index/search?q=chmod) on CCI we have `os.chmod` present there, but there is no pattern for its usage, sometimes we force the permission number, sometimes we just update (add/remove) what we need.

My suggestion is adding a wrapper for `chmod`:

    tools.chmod(os.path.join(self.package_folder, "bin", "foo"), stat.S_IEXEC)

Or

    tools.chmod_x(os.path.join(self.package_folder, "bin", "foo"))
    tools.chmod_w(os.path.join(self.package_folder, "bin", "foo"))
    tools.chmod_r(os.path.join(self.package_folder, "bin", "foo"))

Or

    tools.chmod(os.path.join(self.package_folder, "bin", "foo"), read=True, write=False, exec=True)

A plus for the third option: Windows users/developers may not know about numerical permission. 

Also, as `os.chmod` is limited for Windows, we could include the project [oschmod](https://github.com/YakDriver/oschmod), which is able to fix the permission on Windows. Thus, `tools.chmod` would be effective for any OS. There is a nice blog post about `oschmod` on [Medium](https://medium.com/faun/securing-files-on-windows-macos-and-linux-7b2b9899992).

/cc @a4z @solvingj 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: uilianries
issue_8002: state: open
title: [feature] generic tool to check for minumum compiler support
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

There is this piece of boiler plate that get's copied a LOT in CCI, but it's also something large project that migrate to newer compilers need to handle as well...

Would this be something that could be added to `conans.tools` ?

```py
    @property
    def _minimum_cpp_standard(self):
        return 14

    @property
    def _minimum_compilers_version(self):
        return {
            "Visual Studio": "15",
            "gcc": "5",
            "clang": "3.4",
            "apple-clang": "5.1",
        }

    def validate(self):
        if self.settings.compiler.get_safe("cppstd"):
            tools.check_min_cppstd(self, self._minimum_cpp_standard)
        min_version = self._minimum_compilers_version.get(str(self.settings.compiler))
        if not min_version:
            self.output.warn("{} recipe lacks information about the {} compiler support.".format(
                self.name, self.settings.compiler))
        else:
            if tools.Version(self.settings.compiler.version) < min_version:
                raise ConanInvalidConfiguration("{} requires C++{} support. The current compiler {} {} does not support it.".format(
                    self.name, self._minimum_cpp_standard, self.settings.compiler, self.settings.compiler.version))
```
user: prince-chrismc
issue_7963: state: open
title: [question] How to generate protobuf source-only library
body: I'm trying to achieve the following: Creation of a proto repository, separated from it's clients. I use several languages, so the only true source code files of this repo are .proto definitions itself. Then use protoc to generate source files in C++, java, python etc. The generated files need to be packaged in whatever the language uses (jar/maven for java, wheels/pip for python and conan/cmake for c++). Generating the .pb.cc and .pb.h files is easy, both in python and cmake it can be done. 

But then packaging it up such that it can be used in other conan based projects is harder. I either have to compile libraries for each used OS/architecture and upload it to our artifactory server.
Or, I can regard the generated .pb.cc and .pb.h files as the output artifact and compile in the client application. This has my preference. When I search "source only conan" it brings me to the "header only" section. It's not the same, I think? How would I package a source-only and import it correctly using cmake find_package correctly?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: RonaldOlsthoorn
issue_7937: state: open
title: [feature] Vulnerability scan for a Conan recipe
body: Package managers for other programming languages (i.e npm) provide the capability to scan for known vulnerabilities. This kind of scannings are based on the list of versions for the 3rd party components & libraries obtained with these package managers. Then, these component/library versions are checked against official databases that record known vulnerabilities (i.e https://nvd.nist.gov/vuln/search). So, at the end you get a list of known vulnerabilities that apply for your software.

The most interesting part of this feature is that it can be integrated with CI/CD environments. We all know that software lifecycles can be very long, thus vulnerabilities can be discovered time after a dependency is introduced. That's why having a vulnerability scan integrated as part of the CI/CD pipeline allows to detect them very soon and this opens the door for an early upgrade/patch of the vulnerable components.

So, considering the increasing importance of cybersecurity in nowadays software development, I was wondering if there are plans to include a feature like that in Conan. It would be great to have a command to scan for known vulnerabilities given a Conan recipe file. Is there anything related in the project roadmap?


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: joaquimvila
issue_7933: state: open
title: [question] How to extend virtualenv-generator environment-variables from within a consumer
body: The provider recipe provides a virtualenv-generator with the needed environment variables. If the consumer recipe requires a package that has environment variables, how can the consumer append these variables to the provided activate.sh ?
- Should he first source activate.sh of the provider than run its own virtual-env generator to get his own environment variables from his dependencies or there is another way for this ?
user: mhanitaw
issue_7903: state: open
title: [feature] Support for cpp_info.names in b2 generator
body: Add support for `cpp_info.name` and `cpp_info.names` in b2 generator.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: grisumbras
issue_7899: state: open
title: [question] I was traumatized while trying to build the qt package. Is this a common problem and if so are there ideas on how building large dependency trees could be made more stable?
body: # The Trauma
I am trying to integrate conan into a little private toy project that uses Qt. This project is build on Windows and Ubuntu. I build it in 5 different configurations *VS2019-shared-debug*, *VS2019-static-release*, *Clang-shared-debug*, *Clang-static-release* and *Gcc-shared-debug*. 

I tried all available versions of the Qt package starting with 5.12.6. That is 11 Versions. Guess what, none of them compiled for all of my configurations. Considering now that one Qt build takes quite some time, you can imagine that getting this data alone cost me a weekend. Also interesting about this is, that I countent at least 7 different reasons for the build to fail. Here are some of them:

* ```make[10]: *** [Makefile.xcb_qpa_lib:5240: .obj/qxcbkeyboard.o] Error 1``` Here I was not able to see what went wrong.
* ```ERROR: Conflict in pcre/8.41:``` At least a descriptive error message.
* ```ModuleNotFoundError: No module named '_lzma'```
* ```make[9]: *** [Makefile:789: .obj/qxkbcommon.o] Error 1```
* One was a low level python error that I could fix by updating conan.

My point here is, that the build was not broken by one problem, but by a large number of different problems. Often deep down in the dependency tree of the original project I wanted to build. These dependencies may be using build-systems that I am not familiar with. This makes deciphering the build-log in order to find the root cause of an error hard.

# Discussion
I know that this is not exactly a problem of conan or the conan qt package, but is rather caused by having large and very heterogenious dependency trees. I also have the feeling that the use of system libraries is also a source of constant trouble because they are not handled by conan or at least not consistently handled by conan. Then adding to that come the dependency version requirement conflicts. I think the only way to really solve those would be to allow multiple versions of one package to exist in the dependency tree. But at least cmake does not support that and I am not aware that any other build-system does.

 So in short ... It is a mess!

# Questions
* So are there any ideas on how building large heterogeneous dependency trees can be made more robust?
* Is this a problem that is discussed "up the food-chain" maybe in standard comitee circles?
* Are you guys, as the ones who have to suffer most from this problem, have any initiatives going that try to fix this?

Cheers
Knitschi

## References

The project that  I used to test the qt package and that contains the different conanfiles can be found at:
[ConanQtPackageTest](https://github.com/Knitschi/ConanQtPackageTest)

user: Knitschi
issue_7882: state: open
title: [feature] Simplify rpath setup with qmake
body: Using the qmake generator I would like it to be more automatic to do this:

CONFIG += conan_basic_setup
include($$PWD/conanbuildinfo.pri)
QMAKE_RPATHDIR += $${CONAN_XXX_ROOT}/lib $${CONAN_YYY_ROOT}/lib $${CONAN_ZZZ_ROOT}/lib

I was unable to use the CONAN_LIB_DIRS variable (it is undefined) and I would not like it to contain "-L" flag.

Thanks in advance,
Paolo
user: stardast
issue_7879: state: open
title: conan remove clarification
body: Quick question -- `conan remove -f [ref]` vs `conan remove -f -b -s [ref]` -- my understanding is the former will remove everything related to the ref, while `-f -b -s` version will only remove build and source files (preserving the package). Is that correct?

user: w3sip
issue_7872: state: open
title: [bug] License files are not copied into the same directory hierarchy when using conanfile.txt over conanfile.py
body: ### Environment Details
  * Operating System+version: macOS 10.15.6
  * Compiler+version: AppleClang 11.0.3.11030032
  * Conan version: 1.27.0
  * Python version: 3.8.5

### Steps to reproduce

As per https://docs.conan.io/en/latest/howtos/collect_licenses.html

Have this section in the `conanfile.txt`

```
[imports]
., license* -> ./licenses @ folder=True, ignore_case=True
```

and then running `conan install` will produce a hierarchy with the following contents in the build directory:

```
$ tree licenses                     
licenses
├── boost
│   └── licenses
│       └── LICENSE_1_0.txt
└── qt
    └── licenses
        └── LICENSE.LGPLv3
```

whereas if having `conanfile.py` with 

```
self.copy("license*", dst="licenses", folder=True, ignore_case=True)
```

and then running `conan install` will produce a hierarchy with the following contents in the build directory:

```
$ tree licenses    
licenses
├── boost
│   └── LICENSE_1_0.txt
├── qt
│   └── LICENSE.LGPLv3
```

Is this a bug or should one use another notation to use with `conanfile.txt` to get the license files under the package name directory directly (without having the `licenses` subdirectory)?

It's not critical, but it would be great to have the same directory hierarchy for both conan file types.


user: alexey-tereshenkov-oxb
issue_7853: state: open
title: [feature] Make virtualenv's activate.sh more robust
body: Hi,

While trying to use the virtualenv on Cygwin with Zsh, I stumbled on backslashes problems. After investigating, I discovered it came from the different default handing of backslashes by echo between sh and zsh (see https://stackoverflow.com/questions/16430628/zsh-escape-backslash).

Therefore, I think it might be a good idea to explicit echo's handling of backslashes in the activate.sh script generated by the virtualenv generator, that is changing the following line:
```
LINE="$(eval echo $line)";
```
into
```
LINE="$(eval echo -E $line)";
```
This forces the default behavior of echo:
```
-E     disable interpretation of backslash escapes (default)
```
This is similar to #6301 and #6314, and might explain other behaviors such as mentioned in #6662. It shouldn't change anything for Bash users, while making it work for Zsh users. And explicit is better :)

Note that a possible workaround on Zsh is to set the option BSD_ECHO, but this is cumbersome.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: antoine-bussy
issue_7845: state: open
title: [feature] outdated build_policy on current package but not it's dependencies 
body: Hello,

Build policy as described here https://docs.conan.io/en/latest/mastering/policies.html is a powerfull feature, but we would like to **only** build current package if outdated but not the dependencies. 

Currently we use `outdated` policy to optimize CI builds avoiding non necessary builds if the package already exist, however sometime this silently triggers rebuilds of the dependencies which is an undesirable behavior.   

If there a way to achieve that right now by only applying `outdated` on the current package but not the dependencies? and is there any plan to add this ability ?

Thanks,
Walid
user: boussaffawalid
issue_7844: state: open
title: [question] Managing large binary 3rd party dependencies
body: We are building a conan package based on a large (closed-source) 3rd party dependency that exceeds several GB in size.  I wanted to use conan because I can bundle the dependency as a conan package and our CI/CD pipelines will automatically fetch the dependency.  Otherwise, I have to manually add the dependency to our build machine.  

I have a simple recipe : 
```
from conans import ConanFile
class Party3rdConan(ConanFile):
    name = "Party3rd"
    version = "1.0.1"
    settings = "os", "arch"
    description = "Large Dependency"
    url = ""
    license = "Commercial"
    author = "ACME"
    topics = None

    def package(self):
        self.copy("*")

    def package_info(self):
        pass
```

I run export-pkg and it properly creates the conan package.  However, if I try to upload the package to our artifactory server it fails to complete because of the size of the dependency.  I think conan is crashing or over-consuming on the OS side which is causing it to crash.  The binary is about 6GB and compressed version is 3.5GB.  I'm wondering if there is a way to tell upload to split the binary package into parts and re-assemble those parts.  This would break up the binary size and allow parallization of the upload. 


user: walterj-adsk
issue_7831: state: open
title: [bug] CMakeToolchain can no longer configure pre-3.13 CMake options
body: https://github.com/conan-io/conan/commit/a77b97817a73fbdd2fbeb5f7038ad400aafd1803 switched from using cached variables to normal cmake variables. This means that there is no mechanism to specify cmake options with the CMake toolchain for old versions of cmake (pre 3.13), or when a cmake project is using old policies. See https://cmake.org/cmake/help/v3.13/policy/CMP0077.html.

### Environment Details (include every applicable attribute)
  * Conan version: 1.30.0
  * Python version: 3.6, 3.7, 3.8

### Steps to reproduce (Include if Applicable)
CMakeLists.txt
```cmake
cmake_minimum_required(VERSION 3.12)
project(my_project)
option(my_option "my option" ON)
```

conanfile.py
```python
class MyClass(ConanFile):
    ...
    def toolchain(self):
        toolchain = CMakeToolchain(self)
        toolchain.variables["my_option"] = "OFF"
        toolchain.write_toolchain_files()
```


user: ohanar
issue_7829: state: open
title: [feature] Add OpenBSD support
body: Conan can't work on OpenBSD.

```
ERROR: Invalid setting 'OpenBSD' is not a valid 'settings.os' value.
Possible values are ['AIX', 'Android', 'Arduino', 'Emscripten', 'FreeBSD', 'Linux', 'Macos', 'Neutrino', 'SunOS', 'Windows', 'WindowsCE', 'WindowsStore', 'iOS', 'tvOS', 'watchOS']
```
user: Liorst4
issue_7816: state: open
title: [feature] CMakeToolchain + Emscripten PoC
body: Implement a proof of concept of using the new CMakeToolchain feature for building Emscripten/WebAsm projects:

- From Linux
- From Windows

Notes:
- Emscripten can be assumed installed
- Focused on creating/building 1 package, both local flow (conan install + native cmake) and ``conan create`` flow.
- Integration test.
- Test can be skipped for CI, but should work locally, annotate assumptions and installation details
- No env-var configuration at all
- All code must be private and local to the toolchains package
- New cross-build model with contexts must be used if necessary, not the old os_build, arch_build
- If enough time to implement reuse of a package, the ``cmake_find_package_multi`` generator must be used

user: memsharded
labels: component: Build: Build helpers, build systems..
issue_7815: state: open
title: [feature] CMakeToolchain + WSL2 PoC
body: Implement a proof of concept of using the new CMakeToolchain feature for building in WSL2:

- From Windows, using WSL2

Notes:
- WSL2 can be assumed installed
- Focused on creating/building 1 package, both local flow (conan install + native cmake) and ``conan create`` flow.
- Integration test.
- Test can be skipped for CI, but should work locally, annotate assumptions and installation details
- No env-var configuration at all
- All code must be private and local to the toolchains package
- New cross-build model with contexts must be used if necessary, not the old os_build, arch_build
- If enough time to implement reuse of a package, the ``cmake_find_package_multi`` generator must be used

user: memsharded
labels: component: Build: Build helpers, build systems..
issue_7806: state: open
title: [bug] user_property_file_name causes "error MSB4115: The "exists" function only accepts a scalar value" in MSBuild with with vs2015 
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows Server 2012 R2
  * Compiler+version: VS2015, Microsoft (R) Build Engine version 14.0.25420.1
  * Conan version: Conan version 1.29.0
  * Python version: Python 3.8.6


Using `user_property_file_name` as follows in my conanfile.py:

```
    def build(self):
        msbuild = MSBuild(self)
        msbuild.build("MyProject.sln", user_property_file_name=os.path.join(self.build_folder, "conanbuildinfo.props"))
```

doesn't seem to work for me in either of the `conan build` or `conan create` cases. 

Here's the error for `conan build`:

```
C:\dev\src\nx\platform\build>conan build ..

[...]

----Running------
> call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC/vcvarsall.bat" amd64 && msbuild "C:\dev\src\nx\platform\Platform.sln" /p:Configuration="Debug" /p:UseEnv=true /p:Platform="x64" /m:8 /p:PlatformToolset="v140" /verbosity:normal /p:ForceImportBeforeCppTargets="C:\dev\src\nx\platform\build\conan_build.props;C:\dev\src\nx\platform\build\conanbuildinfo.props"
-----------------
Microsoft (R) Build Engine version 14.0.25420.1

[...]

   20>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Current.targets(14,11): error MSB4115: The "exists" function only accepts a scalar value, but its argument "$(ForceImportBeforeCppTargets)" evaluates to "C:\dev\src\nx\platform\build\conan_build.props;C:\dev\src\nx\platform\build\conanbuildinfo.props" which is not a scalar value. [C:\dev\src\nx\platform\SolutionPlatformCommonTasks\SolutionPlatformCommonTasks.vcxproj]

```

and here's the error for `conan create`:

```
C:\dev\src\nx\platform>conan create . PORT/stable

[...]

----Running------
> call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC/vcvarsall.bat" amd64 && msbuild "C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\Platform.sln" /p:Configuration="Debug" /p:UseEnv=true /p:Platform="x64" /m:8 /p:PlatformToolset="v140" /verbosity:normal /p:ForceImportBeforeCppTargets="C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\conan_build.props;C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\conanbuildinfo.props"
-----------------
Microsoft (R) Build Engine version 14.0.25420.1

[...]

    20>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Current.targets(14,11): error MSB4115: The "exists" function only accepts a scalar value, but its argument "$(ForceImportBeforeCppTargets)" evaluates to "C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\conan_build.props;C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\conanbuildinfo.props" which is not a scalar value. [C:\dev\conan\platform\0.0.1\PORT\stable\build\0b258a3cc8a011fb233dfdd231934614cdc10438\SolutionPlatformCommonTasks\SolutionPlatformCommonTasks.vcxproj]
```

In both cases I can confirm it's setting the right directory for `conanbuildinfo.props`, but doesn't seem to like a semi-colon separated list of items for `$(ForceImportBeforeCppTargets)`.  Maybe a vs2015 issue?


( Note: I understand from discussion in https://github.com/conan-io/conan/issues/7805#issuecomment-703165920 that it's probably suboptimal to try to inject `conanbuildinfo.props` this way, but nevertheless I wouldn't have expected this error, which would also impede setting any other .props file )


### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: michaelmaguire
issue_7793: state: open
title: [bug] CONAN_LOGIN_USERNAME ignored when cached credentials exists for the remote
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Conan version: 1.26.0
  * Python version: 3.8.2

### Steps to reproduce (Include if Applicable)

```
$ conan user --clean
$ export CONAN_LOGIN_USERNAME=read_only_user CONAN_PASSWORD=ro_user_password
$ conan user
Current user of remote 'foo' set to: 'None' (anonymous)
$ conan upload --force --all test/1.0.0@test/stable -r=foo
1.0.0
Uploading to remote 'foo':
Uploading test/1.0.0@test/stable to remote 'foo'
Compressing conan_export.tgz completed [10 files]
Compressing conan_sources.tgz completed [20 files]
ERROR: test/1.0.0@test/stable: Upload recipe to 'foo' failed: Permission denied for user: 'read_only_user'. [Remote: foo]

ERROR: Errors uploading some packages
$ conan user
Current user of remote 'foo' set to: 'read_only_user' [Authenticated]
$ export CONAN_LOGIN_USERNAME=read_write_user CONAN_PASSWORD=rw_user_password
$ conan upload --force --all test/1.0.0@test/stable -r=foo
1.0.0
Uploading to remote 'foo':
Uploading test/1.0.0@test/stable to remote 'foo'
Compressing conan_export.tgz completed [10 files]
Compressing conan_sources.tgz completed [20 files]
ERROR: test/1.0.0@test/stable: Upload recipe to 'foo' failed: Permission denied for user: 'read_only_user'. [Remote: foo]

ERROR: Errors uploading some packages
$ conan user
Current user of remote 'foo' set to: 'read_only_user' [Authenticated]
```

Conan should check the cached credentials refers to the same user as CONAN_LOGIN_USERNAME and if not re-log-in.
user: odormond
issue_7790: state: open
title: [question] consumer package overrides to version lower than required by another dependency?
body: I have 2 libraries and an application: libsystem, libcore, and myapp such that:
- libsystem: no dependencies
- libcore --> libsystem
- myapp --> libcore & libsystem

myapp requires specific versions: 
- libcore/1.0.1
- libsystem/1.0.0 

I'm explicitly calling out libsystem as I want to ensure a specific version in myapp

libcore/1.0.1 uses a range for libsystem where the minimum version is a prerelease version later than 1.0.0 
- libsystem/[>=1.1.0-dev.1.2, include_prerelease=True] 

as there was a feature added to the prerelease version of libsystem that is required by libcore/1.0.1

That version range resolves to libsystem/1.1.0, which is the official release that includes the feature libcore needs.

When I run conan info/install on myapp I get a warning that the libsystem requirement specified by libcore/1.0.1 is overridden down to libsystem/1.0.0 such that the dependencies installed are libcore/1.0.1 and libsystem/1.0.0

This seems strange to me. I would have expected conan to yell at me that libsystem/1.0.0 is incompatible with libcore/1.0.1? Am I missing something?

Even if I take it that I specified libsystem/1.0.0 so conan is letting me shoot myself in the foot, the warning is the same for when conan overrides to a higher version, so it's easy to overlook the downgrade. Or maybe a way to tell conan to terminate if this happens seems like it would be useful?

I'm using conan 1.29.2.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: nichmj01
issue_7778: state: open
title: [feature] Add an ability to show outdated packages in conan install
body: The idea is that it is quite a good idea to always use latest version (performance / security issues and so on)

For example I have libA, which I really need to use.
And I do install it using conan install.

Then new version gets released, but it's quite hard to follow manually all the packages updates.
I would like conan install to tell me that:
`You're using libA version 1.0, version 2.0 is available`.

It gets worse, when some library is used as a dependency and it's version is hardcoded in the conanfile.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: mathbunnyru
issue_7772: state: open
title: [question] Enforcing a minimum C++ standard for consumers of a package while remaining compiler and platform independent
body: I have a library that uses some C++17 language features and I am in the process of trying to package it up using Conan so it can be easily consumed by any build system. Because some of the header files in my library use C++17 features, the consumer of the library is also required compile their code with at least a minimum standard of C++17 otherwise compilation will fail.

In the `package_info` section of my conanfile I can tell it to use the proper compiler flag:

```python
self.cpp_info.cxxflags = ["-std=c++17"]
```

But this has two issues:

1. This compiler flag is not recognized by all compilers. For example this works with gcc, but if I try to use MSVC I will get an error `warning D9002: ignoring unknown option '-std=c++17'` and the code will fail to compile.

2. This locks the consumer of the package into using C++17 when a newer standard would work. What happens when the consumer decides they want to use my library but they want to compile their code using C++20?
________

With a pure CMake project that doesn't use Conan this is handled quite elegantly by just adding:

```cmake
target_compile_features(<target> PUBLIC cxx_std_17)
```

This will automatically pass the minimum standard requirement to the consumer of the target AND should they decide to compile their code with a newer standard (like C++20) CMake will account for that and the entire library will be compiled with the newer standard instead.
_______

While the pure CMake solution is nice, I can't rely on it and still have my library be consumable by users who decide to use a different build system other than CMake. How can I solve this problem with Conan?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: tjwrona
issue_7767: state: open
title: VTK 9.0.1 (hdf5) with apple-clang 12
body: Something about the cmake.configure() method prevents VTK9 from properly compiling with apple-clang 12. This seems more like a cmake configuration error than a conan bug, but I can only reproduce it with conan.

Building VTK 9.0.1 with apple-clang 12 using conan package fails with a surprising definition inclusion error.
https://github.com/divergentscott/conan-vtk/blob/master/conanfile.py

Essentially the same VTK recipe worked with apple-clang 11.
I can build VTK 9.0.1 with apple-clang 12 using their default cmake.
I can build VTK 9.0.1 on linux with gcc and that same conan recipe.
I can even build VTK 8.2.0 (which has similar hdf5 structure) with apple-clang 12 and the same conan recipe with the version swapped out.

Specifically VTK 9 + conan + apple-clang 12 appears to have include errors when building hdf5

### Environment Details 
  * Operating System+version: OSX 10.15.6
  * Compiler+version: apple-clang 12
  * Conan version: 1.29
  * Python version: 3.7.7

### Steps to reproduce (Include if Applicable)

On recipe:

https://github.com/divergentscott/conan-vtk/blob/master/conanfile.py

conan create 
using apple-clang 12

This results in a linking or inclusion error with hdf5:
`
VTK9/ThirdParty/hdf5/vtkhdf5/src/H5Fsuper.c:1397:16: error: implicit declaration of function 'vtkhdf5_H5O__fsinfo_set_version' is
      invalid in C99 [-Werror,-Wimplicit-function-declaration]
            if(H5O__fsinfo_set_version(f, &fsinfo) < 0)
               ^
VTK9/ThirdParty/hdf5/vtkhdf5/src/vtk_hdf5_mangle.h:1882:33: note: expanded from macro 'H5O__fsinfo_set_version'
#define H5O__fsinfo_set_version vtkhdf5_H5O__fsinfo_set_version

`

Any ideas about what could be going on?
user: divergentscott
issue_7756: state: open
title: [question] Manage precompiled headers
body: Hello people,

I'm converting a C++ project from cmake only to conan + cmake.
The old project was "cmake driven" where we were calling conan from within cmake to get dependencies but internal project dependencies (application and internal libraries) were build using cmake only.

Now we want to move "conan driven" where we create packages for each of our libraries and use cmake to only build single projects.

In the old project we were using a lot cmake funcion target_precompile_headers in this way:

target_precompile_headers(${ProjectId}
  PUBLIC
	$<$<COMPILE_LANGUAGE:CXX>:${CMAKE_CURRENT_SOURCE_DIR}/${HEADERS}>
        ...)

to let the consumers to generate precompiled headers with dependency headers too.
How can we do the same thing in a "conan driven" build?


user: thegwydd
issue_7753: state: open
title: [question] build requirement (e.g. rootpath) information in custom generator
body: Using `--profile:build` and a custom conan generator I am currently able to iterate over the _host requirements_ in `self.deps_build_info.dependencies` to create a list of dependency name, rootpath tuples.

I would like to do the same with the _build requirements_ but haven't been able to locate the required information (i.e. dependency names and rootpaths) anywhere.

Is it accessible?
user: ngladitz
issue_7752: state: open
title: [question] Windows and CMake, Ninja not picked by conan?
body: - Conan 1.29
- Windows MSVC2019
- CMake 3.17.1
- Ninja 1.10.0

The main projects CMakeLists.txt uses conan_cmake_run() to build the dependencies needed by the project.

> cmake -GNinja -DCMAKE_BUILD_TYPE=Release ......
> cmake --buiild .

The Ninja is picked correctly on Mac and Linux to build the dependency (conan_cmake_run()) but on Windows is has no effect?
On Windows it seems to always reference 'vcxproj'?

// no effect
> $ conan config set general.cmake_generator=Ninja

// no effect
> set CONAN_CMAKE_GENERATOR=Ninja

Then I found this: https://github.com/conan-io/conan/issues/5312

But as suggested the vcvars.bat had no effect.

I had to edit the recipe of the module (built by the conan_cmake_run()) as follows:

    def build(self):
        args = [cmake_tool, "-GNinja", "-DCMAKE_INSTALL_PREFIX=" + install_dir, os.getcwd()]
        self.run(" ".join(args))

With this change I was able to get it working on Windows, but I would not like to hard code the Ninja usage in the recipe.

How to make it pick the Ninja correctly on Windows?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: iiknd
issue_7748: state: open
title: Pre Recipe Check Hook
body: Summary
======
I would be helpful if there was a hook that was called before Conan checks if it can find the recipes. Editable mode make it easy to work with multiple package without a constant commit-push-build-download cycle, but if you then push all of your packages to their repositories, a build server may try to use a recipe that was not yet uploaded to the Conan repository.

Use Case
======
In the set_version() method, we automatically insert the revision into the Conan package version such that we have repeatable builds and can always see from which revision a package was made.

I have a number of packages in editable mode (which is a fantastic feature) and when I am done I commit everything, update the requirements and push the packages to their git repositories. Each package has its own git repository.

Recipes are uploaded only to the Conan repository after a successful build on the build server. We do not want recipes in the repository of which it is known that they do not build anyway. That would make it cumbersome for a developer who needs to use a package.

Problem
======
The build servers watch the git repositories and trigger a build when a new commit is made. Suppose that we have the following situation. Package A/1.0.0.revision1 depends on package B/1.0.0.revision1. I have edited and push both of them, so now package A/1.0.0.revision2 depends on package B/1.0.0.revision2. 

If a build server first builds package B/1.0.0.revision2, then everything works fine. If it is successful it uploads the recipe and the package. If the build fails, then the build of A/1.0.0.revision2 will also fail, as it should.

However, if a build server first checks the repository of package A, and wants to build A/1.0.0.revision2, then it will look for the recipe of B/1.0.0.revision2. That recipe was not built yet, and it therefore not in the package repository or the local cache. The build fails. 

Even if we would duplicate the Conan dependencies in the build server configuration (which would be a nightmare) it still wouldn't know which revisions of A depends on which revision of B. Only Conan knows that.

Workaround
========
Currently I abuse the set_version() method to work around this. This method was chosen because

1. It is called before conan checks the recipes.
2. It has access to the recipe_folder. Not the most important reason, but very handy.

In set_version() I go over the requirements and check if Conan can find them. If not, then I download the recipe from the git server based on the name (which must match the repository name) and the revision. I demand that conanfile.py is in the root of the repository. I create a directory named self.recipe_folder + "ensure_that_recipes_are_in_local_cache" and put the script there. Then I 'conan export' that script to the local cache. This recursively triggers the mechanism and if there are indirect recipes that have not yet been built, they will be exported too. Afterwards, I delete self.recipe_folder + "ensure_that_recipes_are_in_local_cache". Having access to self.recipe_folder make this recursion trivial since I do not have to worry about conflicting directory names. Because the downloaded recipe is inside the "ensure_that_recipes_are_in_local_cache" subdirectory, it will download any missing recipes one level deeper and so on. 

Having a hook that is called before Conan checks the recipes would avoid the need for hacking into the set_version() method. In this case access to self.recipe_folder is handy, but if I use an environment variable then I could use that instead to create recursively nested directories. I don't really like environment variables, but it still seems cleaner than expanding the scope of recipe_folder.

In general, I think more users that want to avoid uploading bad recipes will run into this problem. Editable mode makes it convenient to short-circuit the commit-push-build-download cycle, but if there is no upload step before build, it creates problems. Given that many people will have a different setup, dedicated feature does not seem feasible, but an additional hook seems like a good solution.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: markovandooren
issue_7747: state: open
title: Conan recipe custom step
body: @jgsogo As requested, this is a description of my Conan/Visual Studio integration.
I tried to be as detailed as possible such that it is also clear what I am
trying to achieve and why. Perhaps there is a better way to do all of this.

Standalone Conan
================
In the standalone Conan scenario, as used on the build server, 
the build() method does the following:

    def build(self):
        ...
        MSBuild(...)
        
        self.index_sources()
        ...

    def index_sources(self):
        # Use self.deps_cpp_info and self.deps_user_info
        # to create the source indexing stream of the PDB.
        #
        # For header files, or static libraries, we use
        # information from the dependencies to create the
        # source indexing mapping. Each package inserts the
        # the type of version control, the repository URL,
        # and the revision into deps_user_info.
        ...

Visual Studio Standard Conan Workflow
=====================================
A. DLLs

In the local development workflow, everything works fine for DLLs and header files. 
For DLLs, the PDB that is next to the DLL is used. The header files are part of the packages.
The propertysheets generated by Conan ensure that Visual Studio can find everything it needs.

B. LIBs

For static libraries, however, this does not work. Suppose program P uses a static
library of package A. That static library contains the information that it is compiled
from C:\whatever\the\path\was\on\the\build\server\a.cpp. Even if the developer would
have a.cpp locally, it is not in the same directory as that of the build server, and 
possibly not the same revision.

When our Conan package does the source indexing for the static library, it inserts the 
mapping for C:\whatever\the\path\was\on\the\build\server\a.cpp. Visual Studio, however,
does not create source indexing. That is done by external tools. Therefore its build
output does not contain the source indexing for a.cpp. If you want to debug and
step into the code of a.cpp, Visual Studio will ask you to locate the source manually.
So even though the Conan file of package A has inserted the source indexing into the PDB,
it is not being used.

Visual Studio Extra Conan Integration
=====================================
To solve this problem, I change our custom generator and our shared Conan code.

The generator creates an additional propertysheet that triggers the source indexing
for a binary that was built.This propertysheet is included by the generated C++ Conan propertysheet.

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
        <Target Name="IndexSources" AfterTargets="Build">
            <Message Importance="High" Text="Indexing sources for $(TargetName)."/>
            <Exec Command="cd &quot;D:\dev\workspace\platform&quot; &amp; set SOURCE_INDEXING_TARGET=$(OutDir)\$(TargetName)&amp; conan build ."/>
        </Target>
    </Project>

We somehow have to tell Conan do call the index_source() method described above because
it has all the knowledge about the dependencies to know where the PDB is on the local system.

Problem
=======
Since we cannot just call the index_sources() method, we have to abuse nother method.
I thought that the least inappropriate place would be the build() method. If the build()
method detects that it is not in the local cache, we let it skip the MSBuild step, and
just do the source indexing.

In addition, we have to be able to pass information about what binary to source index.
Some binaries, such as unit tests, are not part of package P, to the Conan file does
not know about them. Also, because builds run in parallel, we cannot just index all of them
because then it can start indexing a PDB that Visual is still creating and that will
give an error. 

We now use an environment variable SOURCE_INDEXING_TARGET to pass this information.
If we are not building in the local cache, we index only that target. Otherwise, we
indexing everything that is part of the package. This is all quite hacky, and I have broken
the regular build server behavior at times when developing this.

Context
=======
The context for this particular custom method would be

1. The context as it is at the start of the build() method. It needs the deps_cpp_info,
   deps_user_info, and the information about the current package.
2. An externally provided name that indicates what must be source indexed.

At first sight it seems that the context at the start of build() is sufficient for most 
if not all customizations. So if I could run e.g.

    conan --context=build --target=index_sources "my source indexing target"

The corresponding method in the Conan file would then be:

    def index_sources(self, source_indexing_target):

That would give a lot of possibilities for integrating parts of the proces into
the local development toolchain. Some custom steps might need multiple arguments.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: markovandooren
issue_7742: state: open
title: [bug] package settings in profile not considered for `self.settings_target`
body: It seems that [package settings](https://docs.conan.io/en/latest/reference/profiles.html#package-settings-and-env-vars) are not considered when accessing `self.settings_target`.

I encountered this issue when trying to use my cross-compiler package.  One of the consumers of this package must use a certain version of the compiler so I hard-coded it in the profile using package settings:

```
compiler.version=6.1
my_lib:compiler.version=6.2
```

But when I build `my_lib` and the value for this setting is inferred from settings_target, it takes the global `compiler.version=6.1` instead of the expected `compiler.version=6.2`.

I made an example to reproduce the problem, but used `arch` as a target option to simplify it.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 64-bit
  * Compiler+version: n/a
  * Conan version: 1.29.2
  * Python version: 3.7.3

### Steps to reproduce (Include if Applicable)
[package_settings_fails_when_crossbuilding.zip](https://github.com/conan-io/conan/files/5264336/package_settings_fails_when_crossbuilding.zip)

### Logs (Executed commands with output) (Include/Attach if Applicable)

Configuration (profile_host):
[settings]
arch=x86
build_type=Release
libb:arch=x86_64  **<--- package settings in profile**
[options]
[build_requires]
*: my_compiler/1.0.0@user/testing
[env]

Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

libb/1.0.0@user/testing: Forced build from source
my_compiler/1.0.0@user/testing: being used as a build requires
my_compiler/1.0.0@user/testing: target_arch: x86  **<--- used setting**

user: GordonJess
issue_7733: state: open
title: [bug] Artifactory returns 200 when user without permissions removes packages
body: The issue happens when using Artifactory API v1 (revisions disabled). Some user without DELETE permissions in an Artifactory repo tries to remove packages, no error message is thrown and a 200 response code is returned by Artifactory.

 * Conan version: 1.29.2
 * Artifactory version: 7.7.3 pro

### Steps to reproduce (Include if Applicable)

Create an user in Artifactory without DELETE permissions on a repo. Configure that repo in Conan.

```
$ conan new pkg/1.0 && conan create .
$ conan upload pkg/1.0 -r artifactory -c --all
$ conan config set general.revisions_enabled=0
$ conan remove "pkg/1.0" -r artifactory -f
Nothing happens
$ conan config set general.revisions_enabled=1
$ conan remove "pkg/1.0" -r artifactory -f
ERROR: Permission denied for user: 'carlos'. [Remote: artifactory]
```

user: czoido
issue_7723: state: open
title: [bug] self.copy(symlinks=True) has no effect
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Macos  (Linux is affected as well)
  * Compiler+version:
  * Conan version: 1.23.0
  * Python version: 3.7.3

### Steps to reproduce (Include if Applicable)
Use symlinks=True during package stage

For example:
        self.copy("libglib*", dst="glib-2.0/lib", src=self.kWorkfolder+"/lib/aarch64-linux-gnu", symlinks=True)
Contents of the source folder:
$ ls -la /Volumes/nvidia/usr/lib/aarch64-linux-gnu/libglib*
-r--r--r--  1 root  wheel  1986314 Jul  3  2019 /Volumes/nvidia/usr/lib/aarch64-linux-gnu/libglib-2.0.a
lr-xr-xr-x  1 root  wheel       23 Jul  3  2019 /Volumes/nvidia/usr/lib/aarch64-linux-gnu/libglib-2.0.so -> libglib-2.0.so.0.5600.4
lr-xr-xr-x  1 root  wheel       23 Jul  3  2019 /Volumes/nvidia/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0 -> libglib-2.0.so.0.5600.4
-r--r--r--  1 root  wheel  1035584 Jul  3  2019 /Volumes/nvidia/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0.5600.4
lr-xr-xr-x  1 root  wheel       22 Apr  1  2018 /Volumes/nvidia/usr/lib/aarch64-linux-gnu/libglibmm-2.4.so.1 -> libglibmm-2.4.so.1.3.0
-r--r--r--  1 root  wheel   542696 Apr  1  2018 /Volumes/nvidia/usr/lib/aarch64-linux-gnu/libglibmm-2.4.so.1.3.0
lr-xr-xr-x  1 root  wheel       42 Apr  1  2018 /Volumes/nvidia/usr/lib/aarch64-linux-gnu/libglibmm_generate_extra_defs-2.4.so.1 -> libglibmm_generate_extra_defs-2.4.so.1.3.0
-r--r--r--  1 root  wheel   162752 Apr  1  2018 /Volumes/nvidia/usr/lib/aarch64-linux-gnu/libglibmm_generate_extra_defs-2.4.so.1.3.0

Contents of package/glib-2.0/lib after executing the package step:
$ ls -la package/glib-2.0/lib/
total 7320
drwxr-xr-x  10 alex  staff      320 Sep 18 10:09 .
drwxr-xr-x   6 alex  staff      192 Sep 18 10:09 ..
-rw-r--r--   1 alex  staff  1986314 Sep 17 21:52 libglib-2.0.a
-rw-r--r--   1 alex  staff       23 Sep 17 21:52 libglib-2.0.so
-rw-r--r--   1 alex  staff       23 Sep 17 21:52 libglib-2.0.so.0
-rw-r--r--   1 alex  staff  1035584 Sep 17 21:52 libglib-2.0.so.0.5600.4
-rw-r--r--   1 alex  staff       22 Sep 17 21:52 libglibmm-2.4.so.1
-rw-r--r--   1 alex  staff   542696 Sep 17 21:52 libglibmm-2.4.so.1.3.0
-rw-r--r--   1 alex  staff       42 Sep 17 21:52 libglibmm_generate_extra_defs-2.4.so.1
-rw-r--r--   1 alex  staff   162752 Sep 17 21:52 libglibmm_generate_extra_defs-2.4.so.1.3.0

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: w3sip
issue_7713: state: open
title: Default files that can be overridden 
body:  Hi.

I would like to create a Conan recipe that installs files but only if files are not available in a local git clone.
In other terms I would like to install dependencies but files could be overridden by local versions. This too create inheritance, i.e. default files that can be replaced by project repo files.
Is this possible in Conan? Any other ways to achieve this behavior?

/Patrik
user: paostman
issue_7710: state: open
title: [bug]  Not clear conan work with defaul_options
body: In some cases, the conan ignore default_options in conanfile.py

### Environment Details 
  * Operating System+version: Any
  * Compiler+version: Any
  * Conan version: 1.28
  * Python version:  3.8

### Steps to reproduce 
Local cache contains 1 prebuilt package dep1 with default_options(dep1:option1=False).

```python3
from conans import ConanFile

class DepConan(ConanFile):
    name = "dep1"
    version = "0.0.1"
    exports_sources = "src/*"
    settings = "os", "build_type"
    options = {"option1":[True, False]}
    default_options = {"option1": False}
```


We have an application recipe that depends on dep1:option1=True.
```python3
from conans import ConanFile


class AppConan(ConanFile):
    name = "app"
    version = "0.0.1"
    exports_sources = "src/*"
    settings = "os", "build_type"
    options = {"option1":[True, False] }
    requires = ["dep1/0.0.1@integration_tests/case12"]
    default_options = { "dep1:option1": True  }
```
When trying to build an application with default options, conan uses dep1:option1=False instead of dep1:option1=True.

Lockfile application, which was built with default options:
``` json
    "nodes": {
      "0": {
        "ref": "app/0.0.1@integration_tests/case12",
        "options": "option1=False\ndep1:option1=False",
        "requires": [
          "1"          
        ],
        "context": "host",
        "modified": true,
        "build_requires": null
      },
      "1": {
        "ref": "dep1/0.0.1@integration_tests/case12#502d5b56a23e26bbea62e1e4a010aa84",
        "options": "option1=False",
        "context": "host",
        "modified": true,
        "requires": null,
        "build_requires": null
      }
    }
  },
```

What is the logic of conan when it works with default_options?
user: AlekseyKovy
issue_7708: state: open
title: [question] How to reset --package-folder value in "conan build" to undefined?
body: I'd like to prevent `conan build` from altering installation paths, i.e. avoid conan from taking `if self._conanfile.package_folder` branch in `conans/client/build/cmake_flags.py`. However, `conan build` sets default value `{build_folder}/package` if `-pf` is not specified. Is there any way to prevent conan from messing with `CMAKE_INSTALL_` variables?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: annulen
issue_7706: state: open
title: [feature] Use multithreaded gzip
body: Compression is excruciatingly slow for large packages. This is mostly due to the fact, that Python gzip package is single-threaded. So no matter how fast of a build machine is being used, when it comes to compressing a large package, it's being wasted, 

Switching conan to mgzip should be fairly quick, and performance gains it promises are significant.  If it doesn't pan out, switching to an alternative compression method, such as lz4, will be a far bigger change, but may be worth looking at.
user: w3sip
issue_7693: state: open
title: [feature] Improve compatibility with compiler caches like ccache or sccache
body: We recently set up sccache with a local S3 storage for our CI infrastructure. With this runners should be able to reuse cached compilations instead of recompiling from source all the time. The problem now is that due to how Conan stores packages internally the cache is not used in most cases:

sccache (and ccache or other such solutions) use the absolute path of the source-files to determine whether a source-file has changed. With Conan the absolute path to the sources is relying on attributes of the package: `$CONAN_HOME/data/<name>/<version>/<user>/<channel>`. Dependencies also have their path changed frequently: `$CONAN_HOME/data/bar/.5.6/otheruser/otherchannel/package/<someSHA>/`. See [this comment](https://github.com/mozilla/sccache/issues/35#issuecomment-392811282) for reference.

Especially in our case this is a hard problem, as we extend SemVer with metadata regarding the Git SHA and Build ID, so versions are changing quite a bit: `Foo/1.0.0+abcdefg.GL00137@user/channel`. Pathes are never the same between builds.

From https://github.com/mozilla/sccache/issues/35 it does not seem that sccache is interested in solving this, it's quite a complex problem for them as well.

I'd like to ask if anyone on the Conan-side has experience with this type of scenario. Perhaps there's already a solution that'd help, perhaps we can come up with an idea to enable a better usage of compile caches with Conan.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: monsdar
issue_7688: state: open
title: [question] How should `target` info be passed when building a cross-compiler `build_requires` from sources
body: I'm cross-compiling via `build_requires` using the new two-profile (build/host) approach and have been following the [example ](https://docs.conan.io/en/latest/systems_cross_building/cross_building.html#conan-v1-24-and-newer) in the docs for the compiler recipe:
```
class CrossCompiler(ConanFile):
    name = "my_compiler"
    settings = "os", "arch", "compiler", "build_type"
    options = {"target": "ANY"}
    default_options = {"shared": False, "target": None}
    def configure(self):
        settings_target = getattr(self, 'settings_target', None)
        if settings_target is None:
            # It is running in 'host', so Conan is compiling this package
            if not self.options.target:
                raise ConanInvalidConfiguration("A value for option 'target' has to be provided")
        else:
            # It is running in 'build' and it is being used as a BR, 'target' can be inferred from settings
            if self.options.target:
                raise ConanInvalidConfiguration("Value for the option 'target' will be computed from settings_target")
            self.options.target = "<target-value>"  # Use 'self.settings_target' to get this value
```

When building the compiler package I pass the default profile as the host since I want it to run on my build machine:
```conan create . --profile:host=default```

However in order to build the package I need more information.  For example, `compiler.version` is needed to tell me which which sources to fetch.  From the snippet above I understood that I need to pass this in from the command-line as an `options.target` (and if it is being used as a `build_requires` for another package then it will get this info from the `host_profile` being used to build that package).

I'm having trouble with how this `target` option should be passed.  I guess it has to contain settings such as `arch` and `compiler.version` etc. but  I don't know how to pass these as a single option.  I expect it is possible since it is in the docs.

Can you please expand on this example?  Or perhaps you can point me towards an existing recipe for such a package.

Thanks!
user: GordonJess
issue_7656: state: open
title: [feature] Create a helper class/function/object to calculate compiler flags
body: We are currently able to get the information of a depdency's `cpp_info` through `self.deps_cpp_info`.
The build helpers use the information to create targets that contain all information of all dependencies.
I think it would be useful to also have this information in the `conanfile.py` itself.

My use case is a autotools `configure` script.
I need to pass the link flags required for a dependency.
But that dependency has also some requirements, so I need to walk its requirements.
I think this should be made available through some conan api.
Using the default `autotools.libs` is not a solution, as that will contain all dependencies.
Some components are unwanted and need to be left out.

What I want is something as follows:is the following:

```python
flag_helper = FlagHelper(self)
# create a object that will contain all information about the 'comp' component of dependency 'dep'
# The 'full' argument will make the helper flatten the dependency tree
dep_comp_info = flag_helper.info(dependency="dep", component="comp", full=True)
# dep_comp_info will contain all compiler flags: cppflags/cflags/cxxflags/libs/ldflags/...
conf_args = [
    "DEP_COMP_LIBS={}".format(dep_comp_info.libs),
]
autotools = AutotoolsBuildEnvironment(self)
autotools.libs = []
autotools.configure(args=conf_args)
```


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: madebr
issue_7650: state: open
title: how to set msvc compile flag?
body: msvc support utf-8 not very well, when file was saved with utf8 and code or commentmay contain chinese character, may cause compile error, fix solution in vs studio was use /utf-8 or /source-charset:utf-8 flag, how can I set msvc compile option in conan?
user: xiedeacc
issue_7643: state: open
title: [bug] Auto-configuration of fPIC seems to be faulty with new checks for fPIC option
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10/macOSX 10.13
  * Compiler+version: VS2017/Xcode 10
  * Conan version: 1.28.1
  * Python version: Python 3.7.7

### Steps to reproduce (Include if Applicable)
We recently moved from Conan 1.24 to 1.28, and have V2 mode enabled, to watch for potential issues. And I noticed this bit of code introduced in 1.26, was raising exceptions on Windows (for fPIC present) and macOSX (for fPIC and shared present and True).

https://github.com/conan-io/conan/blob/develop/conans/client/conanfile/configure.py#L48-L67
```
def _validate_fpic(conanfile):
    v2_mode = get_env(CONAN_V2_MODE_ENVVAR, False)
    toolchain = hasattr(conanfile, "toolchain")

    if not (toolchain or v2_mode):
        return
    fpic = conanfile.options.get_safe("fPIC")
    if fpic is None:
        return
    os_ = conanfile.settings.get_safe("os")
    if os_ and "Windows" in os_:
        if v2_mode:
            raise ConanInvalidConfiguration("fPIC option defined for Windows")
        conanfile.output.error("fPIC option defined for Windows")
        return
    shared = conanfile.options.get_safe("shared")
    if shared:
        if v2_mode:
            raise ConanInvalidConfiguration("fPIC option defined for a shared library")
        conanfile.output.error("fPIC option defined for a shared library")
```

We had previously been using the behaviour in AutoToolsBuildEnvironment and the CMake utility to automatically set the fPIC relevant states on those classes when the fPIC option was available.

But we've noted that if we delete the fPIC option to satisfy when shared=True check in _validate_fpic, then 

https://github.com/conan-io/conan/blob/develop/conans/client/build/autotools_environment.py#L79-L84
```
    def _configure_fpic(self):
        if not str(self._os).startswith("Windows"):
            fpic = self._conanfile.options.get_safe("fPIC")
            if fpic is not None:
                shared = self._conanfile.options.get_safe("shared")
                return True if (fpic or shared) else None
```

and

https://github.com/conan-io/conan/blob/develop/conans/client/toolchain/cmake.py#L253-L266
```
    def _deduce_fpic(self):
        fpic = self._conanfile.options.get_safe("fPIC")
        if fpic is None:
            return None
        os_ = self._conanfile.settings.get_safe("os")
        if os_ and "Windows" in os_:
            self._conanfile.output.warn("Toolchain: Ignoring fPIC option defined for Windows")
            return None
        shared = self._conanfile.options.get_safe("shared")
        if shared:
            self._conanfile.output.warn("Toolchain: Ignoring fPIC option defined "
                                        "for a shared library")
            return None
        return fpic
```

will both early out and return None, so autotools and cmake are no longer configured as expected.

The behaviour we were expecting was that if fPIC is not available, the value of shared (if available) would be returned for use.
user: foundry-markf
issue_7636: state: open
title: [question] Problems combining Conan packages with CMake External Project
body: I'm currently trying to migrate our dependency handling to use Conan as package manager. Previously we were using CMake and external project.
My idea was to start with an already existing recipe to have a quick proof of concept. I chose [DCMTK ](https://github.com/conan-io/conan-center-index/tree/master/recipes/dcmtk/all) as a first package.
The packaging is done using [CMake Conan](https://github.com/conan-io/cmake-conan).
However, I want to test this first before I switch to Conan recipes for all dependencies. Also, I need to write some recipes on my own (and will hopefully provide them at the [Conan center](https://github.com/conan-io/conan-center-index)) but I would like to do this step by step.
The consequence is that I have a single Conan package while other dependencies are still created using CMake External Project.

For example, we are depending on [DCMQI](https://github.com/QIICR/dcmqi), which itself is dependent on DCMTK. And here is the problem that I have:
In my top-level `CMakeLists.txt`-file I use the mentioned CMake Conan wrapper to define my dependency to DCMTK and the CMake generators, which looks something like this:

```
include(${CMAKE_BINARY_DIR}/Conan/conan.cmake)

conan_cmake_run(REQUIRES dcmtk/3.6.5
				BASIC_SETUP
				CMAKE_TARGETS
				GENERATORS cmake_find_package cmake_paths
				OPTIONS ${CONAN_OPTIONS}
				BUILD missing
)
```

This installs the required package (with transitive dependency openjpeg) and creates some output files, like `conan_paths.cmake`, `conanbuildinfo.cmake`, `FindDCMTK.cmake` and some more. The result is, that I can use
```
find_package(DCMTK)
if(TARGET DCMTK::DCMTK)
  ...
endif()
```
where the condition is true.

This is done before the superbuild starts. After installing Conan packages I include my `SuperBuild.cmake`, which again includes something like `CMakeExternals/DCMQI.cmake`. This file does nothing more than calling
```
ExternalProject_Add(DCMQI
  ...
```

with `DEPENDS DCMTK::DCMTK`.

What happens now is that I get the following error message:
```
Make Error at CMakeLists.txt:271 (find_package):
Could not find a package configuration file provided by "DCMTK" with any of the following names:

    DCMTKConfig.cmake
    dcmtk-config.cmake

  Add the installation prefix of "DCMTK" to CMAKE_PREFIX_PATH or set
  "DCMTK_DIR" to a directory containing one of the above files.  If "DCMTK"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring incomplete, errors occurred!
```

The relevant file / line is [here](https://github.com/QIICR/dcmqi/blob/master/CMakeLists.txt#L271).

So I was hoping that DCMQI uses the `FindDCMTK.cmake` that was automatically created by Conan but I don't know how to point DCMQI to this file. In our current setup we have a customized `FindDCMTK.cmake` but CMake also provides a [FindDCMTK.cmake](https://github.com/Kitware/CMake/blob/master/Modules/FindDCMTK.cmake).
Here a `DCMTK_DIR` is defined.

I found `DCMTKConfig.cmake` inside `.conan/data/dcmtk/3.6.5/_/_/build/a77c0a86db5a3776d765c3fb20cfeda3833b0e78\build_subfolder` and hard-coding this path also makes the error go away.
But using fixed paths is not an option. I was trying to find a variable created by Conan (inside `FindDCMTK.cmake`) that would allow me to point DCMQI to `DCMTKConfig.cmake` but all I see is variables pointing to `.conan/data/dcmtk/3.6.5/_/_/package/a77c0a86db5a3776d765c3fb20cfeda3833b0e78/` (`package` instead of `build`).

I'm missing some insights here and would like to understand how to resolve this error and what the different package directories are used for (`build` and `package`).
Also I would like to know why `DCMTK_DIR` needs to be set and why the Conan-created `FindDCMTK.cmake` does not set the variable.

To make things more clear I will probably push the code I have so far this week and post a link to the repository here.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: akalali
issue_7618: state: open
title: [question] Add build requirement on previous version of package of same name
body: Hello!

I'm trying to package [golang/1.15](https://github.com/madebr/conan-center-index/tree/pr_golang/recipes/golang).
Golang requires a previous go version to build itself, that's why I also added golang 1.4.3.

But when adding the build requirement `golang/1.4.3` to `golang/1.15`, the following error appears:

```
ERROR: Loop detected in context host: 'golang/1.15' requires 'golang/1.4.3' which is an ancestor too
```

How can this be allowed?
user: madebr
issue_7613: state: open
title: [question] NSIS:Adding package require for target system + multiple compiler toolchains (for host and target)
body: Hello!

I'm trying to create a recipe for [nsis](https://nsis.sourceforge.io), a open source system to create Windows Installers.
But I'm having difficulties transcribing its requirements to a conanfile recipe.

- Since nsis emits code for a target os/architecture, it has to include `"os_target", "arch_target"`. So its complete settings should be `"os", "arch", "compiler", "build_type", "arch_target"`.

So far no problem

- [It uses zlib](https://nsis.sourceforge.io/Docs/AppendixG.html#build_general) to compress the packages. But when building nsis on Linux, Windows binaries are usually not available.
I don't know how to add a dependency to `zlib`, built with `os=Windows`, even when building on Linux. I don't know of a way to do
`self.requires("zlib/1.2.11", os=self.settings.os_target, arch=self.settings.arch_target)` or similar.

The second problem is the classic multiple compiler toolchain problem:

- nsis has a `installer-compiler` component and a `nsis-host` component. So it needs access to 2 compiler toolchains. On Linux, it needs a toolchain to create the linux-native `manensis` utilities and a windows cross compiler to generate binaries for Windows.


See [NSIS' build documentation](https://nsis.sourceforge.io/Docs/AppendixG.html) for more details on the build process.

I opened this issue so you guys know about this use case when designing improved cross support.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: madebr
issue_7609: state: open
title: Conan 1.28 breaking change (model/options.py/class PackageOptionValues) : Add config variable (conan.conf/environment variable) to select old/new behavior ?
body: Conan 1.28

We've existing packages in production having some code in conanfile.py which assumes that missing options have "None" value (maybe not a good practice but ...).

Since 1.28, `model/options.py/PackageOptionValues.__getattr__() `raises an exception instead of returning "None" and therefore "conan install ..." fails with some of our packages.

Is it possible to have a config variable to select the old/new behavior, like for example `general.skip_broken_symlinks_check / CONAN_SKIP_BROKEN_SYMLINKS_CHECK` => `general.skip_missing_options_check / CONAN_SKIP_MISSING_OPTIONS_CHECK`?

user: PatrickSoulardThales
issue_7607: state: open
title: [bug] injected version of root package in test_package conflicts with version of build_requires in shared config
body: Conan version 1.26.0 on Windows Server 2012 R2.

My team uses a shared `conan config install type --git` repo which is used by our dev and build infrastructure.

In a profile fragment included in all our conan profiles, we state:

```
[build_requires]
cmake/3.17.0@bloomberg/stable
```

This has provided us with some great enforcement of common build tools.  So far so good.


Today I went to try to use our build machine to build a new version 3.18.2 of cmake using (basically) this recipe for CMake: https://github.com/conan-io/conan-center-index/tree/master/recipes/cmake/3.x.x 

I got the following error:

```
[build_requires]
*: cmake/3.17.0@bloomberg/stable, strawberryperl/5.30.0.1@bloomberg/stable, cmake/3.17.0@bloomberg/stable, strawberryperl/5.30.0.1@bloomberg/stable, cmake/3.17.0@bloomberg/stable, strawberryperl/5.30.0.1@bloomberg/stable
[env]

ERROR: Conflict in :
    '' requires 'cmake/3.17.0@bloomberg/stable' while 'cmake/3.18.2@bloomberg/stable (test package)' requires 'cmake/3.18.2@bloomberg/stable'.
    To fix this conflict you need to override the package 'cmake' in your root package.
```

I get that there's a conflict because our shared build config states everyone should use `cmake/3.17.0` and I'm trying to build cmake itself ("quis custodiet ipsos custodes?") but I don't understand what the recommended fix is in this case.  This *is* the "root" package.

Is it telling me I need to mention build_requires=cmake/3.18.2@bloomberg/stable in the recipe for cmake itself?

I know I could fiddle with my profiles to temporarily remove cmake from the build_requires in our common profile fragment, but such fiddling is frowned upon on our blessed build machines.


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: michaelmaguire
issue_7582: state: open
title: [feature] extand build requirements to support more cross-compile
body: In cross-compiling cases, some package need the tools of itself. This scenario has been described in [conan docs - Build and Host contexts](https://docs.conan.io/en/latest/devtools/build_requires.html?highlight=build%20requirement#build-and-host-contexts) the  `protobuffer` package is what I said. And [Bincrafters ICU](https://github.com/bincrafters/conan-icu/blob/testing/66.1/conanfile.py) is another example for ARM building on X86 Linux building machine.

My  thought is to extend (may  be split part of current build requirement functionality) build-tools part to avoid current conflicts on settings.os/settings.os_build, settings.arch/settings.arch_build. 

For example. The   [GLib](https://github.com/conan-io/conan-center-index/tree/master/recipes/glib) is widely used as library and as GNome tool during building. When working as a compiling tool, its setting's os_build/os_arch should be should be corresponding package's  os/arch. Currently these info can be set in package_id, but now we could not handle this in one package since I don’t know whether it is used as a compilation tool or a link library (previous bincraft will create xxx_installer for building tools). Also, the current executable path information is written in package_info, which my not work well on cross-compiling.

I am not sure the thought is too big, any feedback I'd glad to discuss.

- [Y] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: Mingyiz
issue_7565: state: open
title: [bug] during crossbuild, build requirements are buit for host profile instead of build profile
body: When cross building a package and rebuilding all its dependencies,
all its dependencies, including build requirements, are built using the host profile.
It should use the build profile for the build requirements.

### Environment Details (include every applicable attribute)
  * Operating System+version: Fedora Linux  30
  * Compiler+version: gcc 9
  * Conan version: conan 1.28.1
  * Python version: 3.7.7

### Steps to reproduce (Include if Applicable)
- use autoconf recipe at https://github.com/conan-io/conan-center-index/pull/2617
- host profile, `default32`:
    ```
    [settings]
    os=Linux
    arch=x86
    compiler=gcc
    compiler.version=9
    compiler.libcxx=libstdc++11
    build_type=Release
    [options]
    [build_requires]
    [env]
    CC=gcc
    CXX=g++
    CFLAGS=-m32
    CXXFLAGS=-m32
    LDFLAGS=-m32
    ```
- build profile, `default64`:
    ```
    [settings]
    os=Linux
    arch=x86_64
    compiler=gcc
    compiler.version=9
    compiler.libcxx=libstdc++11
    build_type=Release
    [options]
    [build_requires]
    [env]
    CC=gcc
    CXX=g++
    CFLAGS=-m64
    CXXFLAGS=-m64
    LDFLAGS=-m64
    ```
- `cd conan-center-index/recipes/libcurl/all`
- Build everything:
  `conan create . libcurl/7.71.1@ -pr:h default32 -pr:b default64 --build "*"`

### Logs (Executed commands with output) (Include/Attach if Applicable)

While rebuilding m4, the log contains:
```
m4/1.4.18: Calling:
 > source_subfolder/configure '--prefix=/home/maarten/.conan/data/m4/1.4.18/_/_/package/abd3ca9581f5ec3d6672fa2ee8818b1f09dbb082' '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libexecdir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' '--datarootdir=${prefix}/share' --target=x86-linux-gnu
```
which means m4 is rebuilt for x86 (=host) instead of x86_64 (=build profile)
user: madebr
issue_7560: state: open
title: [feature] pkgconfig generator: do not generate pc files for components if not explicitly registered
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Generating pkg config files for each component might conflict pkg config files of others recipes, since:

- components names may be very generic. I think that most people expect that components can't conflict with others recipes. What would happen if pkg config name of a recipe is the same than the name of one component of another recipe, and a downtream recipe depends on both libs, use `pkg_config` generator but only care of first pkg config file?
- there might be a lot of components in a recipe (and this lib might not have official pkg config files, so it will only result in build folder cluttering with tones of useless .pc files).

Therefore, I suggest to generate "components pkg config" files only if it has been explicitly registered in upstream recipes with `self.cpp_info.components["component_name"].names["pkg_config"] = "pkgconfig_component_name"`
user: SpaceIm
issue_7539: state: open
title: [bug] Build Tool is not in PATH env variable
body: <!--
  I have followed the conan [build tool instructions ](https://docs.conan.io/en/latest/devtools/create_installer_packages.html?highlight=build%20tool).

I have included my package recipes.

When I invoke the tool, it can't be found and when I print the PATH env variable in cmake, there is no entry for my build tool.
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 16.04
  * Compiler+version: gcc 5.4
  * Conan version: 1.24.1
  * Python version: 3.7.8

### Steps to reproduce (Include if Applicable)

My cmake script calls a python script which does the following:

        conan_command = ['conan', 'install', '--build=missing', input_dir, '--profile:host', profile, '--profile:build', 'nio-linux-x86_64-gcc5-release']
    subprocess.check_call(conan_command)

The profile is the current target.  The build profile is for linux x86_64 only.

### Logs (Executed commands with output) (Include/Attach if Applicable)

My build tool is not found.  It is not in the PATH environment variable.
I have attached the two conan files in question.

[Conan bug.tar.gz](https://github.com/conan-io/conan/files/5058435/Conan.bug.tar.gz)

user: maingig
issue_7523: state: open
title: [question] Android Studio: cannot find any of the libraries built by conan.
body: Trying to use paho with ssl using Conan.

While building in Android Studio 4.0.1 I am getting error: **cannot find -lpaho-mqttpp3**, **cannot find -lpaho-mqtt3as-static**,  **cannot find -lssl**, **cannot find -lcrypto**

### conanfile.txt
```
[requires]
openssl/1.1.1g
paho-mqtt-cpp/1.1

[generators]
cmake

[options]
paho-mqtt-cpp:ssl=True
```
-------------------------------------------------------------
### android_29_x86_clang
```
include(default)
[settings]
arch=x86
build_type=Debug
compiler=clang
compiler.libcxx=libc++
compiler.version=9
os=Android
os.api_level=29
[build_requires]
android_ndk_installer/r21d@bincrafters/stable
[options]
[env]
```
------------------------------------------------------------
### CMakeLists.txt
```
cmake_minimum_required(VERSION 3.10.2)

include(${CMAKE_CURRENT_SOURCE_DIR}/conan_build/conanbuildinfo.cmake)
set(CMAKE_CXX_COMPILER_VERSION "9.0.8") # Unknown miss-detection of the compiler by CMake
conan_basic_setup(TARGETS)


add_library( # Sets the name of the library.
        native-lib
        SHARED
        native-lib.cpp)

find_library( # Sets the name of the path variable.
        log-lib
        log)

target_link_libraries( # Specifies the target library.
        native-lib
        ${log-lib}
        ${CONAN_LIBS}
        )
```
------------------------------
### build.gradle::conanInstall
```
task conanInstall {
    def buildDir = new File("app/src/main/cpp/conan_build")
    buildDir.mkdirs()

    // if you have problems running the command try to specify the absolute
    // path to conan (Known problem in MacOSX) /usr/local/bin/conan
    def cmmd = "conan install ../conanfile.txt --profile ../profiles/android_29_x86_clang --build missing "
    print(">> ${cmmd} \n")

    def sout = new StringBuilder(), serr = new StringBuilder()
    def proc = cmmd.execute(null, buildDir)
    proc.consumeProcessOutput(sout, serr)
    proc.waitFor()
    println "$sout $serr"
    if (proc.exitValue() != 0) {
        throw new Exception("out> $sout err> $serr" + "\nCommand: ${cmmd}")
    }
}
```
_in externalNativeBuild for CMake I am setting **cppFlags** "-std=c++14 -frtti -fexceptions -stdlib=libc++"_
-----------------------------------------------

I can see that Conan is able to build the libraries without any problems but as the Conan built libraries are attempted to be linked, the build breaks.

Here's an excerpt of output:
```
[0/1] Re-running CMake...
-- Conan: Adjusting output directories
-- Conan: Using cmake targets configuration
-- Library paho-mqttpp3 found /Users/in-abhijit.b/.conan/data/paho-mqtt-cpp/1.1/_/_/package/9f96d6658ee788676fb7f928ba4a36f123ade05b/lib/libpaho-mqttpp3.a
-- Library paho-mqtt3as-static found /Users/in-abhijit.b/.conan/data/paho-mqtt-c/1.3.1/_/_/package/d6dff33203c1fd032290c722770b1d08abf1de17/lib/libpaho-mqtt3as-static.a
-- Library ssl found /Users/in-abhijit.b/.conan/data/openssl/1.1.1g/_/_/package/a07e5697dec8334df38a8d6412eb8a4deab5fdfe/lib/libssl.a
-- Library crypto found /Users/in-abhijit.b/.conan/data/openssl/1.1.1g/_/_/package/a07e5697dec8334df38a8d6412eb8a4deab5fdfe/lib/libcrypto.a
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Current conanbuildinfo.cmake directory: /Users/in-abhijit.b/PlayGround/Android/Conan/MqttClientPoc/app/src/main/cpp/conan_build
-- Conan: Compiler Clang>=8, checking major version 9
-- Conan: Checking correct version: 9
-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY OPENSSL_INCLUDE_DIR) 
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/in-abhijit.b/PlayGround/Android/Conan/MqttClientPoc/app/.cxx/cmake/debug/x86
[1/2] Building CXX object CMakeFiles/native-lib.dir/native-lib.cpp.o
[2/2] Linking CXX shared library lib/libnative-lib.so
FAILED: lib/libnative-lib.so 
: && /Users/in-abhijit.b/Library/Android/sdk/ndk/21.0.6113669/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ --target=i686-none-linux-android28 --gcc-toolchain=/Users/in-abhijit.b/Library/Android/sdk/ndk/21.0.6113669/toolchains/llvm/prebuilt/darwin-x86_64 --sysroot=/Users/in-abhijit.b/Library/Android/sdk/ndk/21.0.6113669/toolchains/llvm/prebuilt/darwin-x86_64/sysroot -fPIC -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security  -std=c++14 -frtti -fexceptions  -O0 -fno-limit-debug-info  -Wl,--exclude-libs,libgcc_real.a -Wl,--exclude-libs,libatomic.a -Wl,--build-id -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments -shared -Wl,-soname,libnative-lib.so -o lib/libnative-lib.so CMakeFiles/native-lib.dir/native-lib.cpp.o  -llog -lpaho-mqttpp3 -lpaho-mqtt3as-static -lssl -lcrypto -lc -latomic -lm && :
/Users/in-abhijit.b/Library/Android/sdk/ndk/21.0.6113669/toolchains/llvm/prebuilt/darwin-x86_64/lib/gcc/i686-linux-android/4.9.x/../../../../i686-linux-android/bin/ld: error: cannot find -lpaho-mqttpp3
/Users/in-abhijit.b/Library/Android/sdk/ndk/21.0.6113669/toolchains/llvm/prebuilt/darwin-x86_64/lib/gcc/i686-linux-android/4.9.x/../../../../i686-linux-android/bin/ld: error: cannot find -lpaho-mqtt3as-static
/Users/in-abhijit.b/Library/Android/sdk/ndk/21.0.6113669/toolchains/llvm/prebuilt/darwin-x86_64/lib/gcc/i686-linux-android/4.9.x/../../../../i686-linux-android/bin/ld: error: cannot find -lssl
/Users/in-abhijit.b/Library/Android/sdk/ndk/21.0.6113669/toolchains/llvm/prebuilt/darwin-x86_64/lib/gcc/i686-linux-android/4.9.x/../../../../i686-linux-android/bin/ld: error: cannot find -lcrypto
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

FAILURE: Build failed with an exception.
```

What changes are required to make it work?

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: babhijit
issue_7505: state: open
title: [question] Forcing generators to be executed on deploy without using command-line-argument
body: Hey guys!

i'm trying to implement some packages, where I need some generator to create/edit some files/dirs within the deploy-stage. The problem is: I'd really like the generator to only be executed during the deploy on the client on which the package is installed on. So as far as I know adding a "generators = [testGenerator, <...>]" as an attribute won't do that. Which will do the trick is adding it to the install command as "conan install <...> -g testGenerator". But therefore I have to know what the generator is called like, even though I might not have looked into the recipe at that point (or do not remember the name).

So what I'd like to do is add something like this within the conanfile.py:
```
    def requirements(self):
        self.requires("testGenerator/<>@<>/<>") # make sure its in the requirements
    
    <...> # do stuff
            
    def deploy(self):
        self.generators("testGenerator") # execute generator right here
```

I couldn't find anything similiar within the docs. The particular reason for this method is: I would have e.g. 50 pkgs which are all supposed to use the generator on install/deploy. So just copying the code into deploy() for each recipe is obviously quite unhandy.

Also: The same goes for the virtualenv/virtualrunenv generators, which I need to add to my cmd. So it gets pretty long e.g. "conan install <...> -if <install-folder> -g virtualenv -g virtualrunenv -g <...>". You see where I'm going with this. I've seen things like, which I could not get to work properly:

```
from conans.client.generators.virtualenv import VirtualEnvGenerator
VirtualEnvGenerator(self.conanfile)
```

Any ideas on calling those standard-generators from inside the recipe as well?

Thank you for any tips or ideas you might have! :)
user: fredericbloch
issue_7504: state: open
title: [feature] build_system_requirements
body: <!-- What is your suggestion? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

I'm currently building a lightweight version of SDL2 in order to only use in Core Context, DX11-12 and VK. In order to achieve that I figure that it is unacceptable to have all developpers install dev dependencies like libwayland-dev and/or xord-dev when building apps which would only use SDL2 common APIs (no low-level stuff).
I request the creation of a build_system_requirements function which works the same as system_requirements but only checks when building the package.
user: Yuri6037
issue_7498: state: open
title: [bug] Conan with Artifactory fails to download large packages
body: Hello All,

Potentially related to issues: #1901 #3580 #6995

We recently migrated our Conan Server from the Conan provided server to Artifactory's Server and we are having issues downloading very large packages (~2.6Gigs).  Since we did not have this issue before, it is safe to assume that this issue comes from the change in Server (Server's fault, or Conan/Server not interfacing properly).   

When performing a conan install about 1Gig (38%) of the file gets installed, it then instantly completes the installation and errors out with the following error (repeating):
```
Downloading conanmanifest.txt completed [10.94k]                                         
Downloading conaninfo.txt completed [0.15k]                                              
Downloading conan_package.tgz completed [1067783.34k]                                    
ERROR: Download failed, check server, possibly try again
Download failed, check server, possibly try again
Error in resumed download from <server_url>
Incorrect Content-Range header 
Waiting 0 seconds to retry...
Downloading conan_package.tgz completed [1067815.34k]                                    
ERROR: Download failed, check server, possibly try again
Download failed, check server, possibly try again
Error in resumed download from <server_url>
Incorrect Content-Range header 
Waiting 0 seconds to retry...
```

### Environment Details (include every applicable attribute)
  * Operating System+version: RHEL7/Ubuntu Bionic
  * Conan version: 1.28.0
  * Python version: python3.6.8
  * Artifactory Server Type: Community
  * Artifactory Server Version: 7.5.7
  * Proxy: Network is proxied but we shouldn't be using it b/c we are all on the same subnet
  * Issue occurs with SSL: True and SSL: False

### Steps to reproduce
conan install <package greater than 2.5 gigs on a slow network: (0.800ms ping / 90Mbits/sec throughput)>

### logs:
[conan_trace.txt](https://github.com/conan-io/conan/files/5024994/conan_trace.txt)


user: szegel
issue_7487: state: open
title: overcome windows path limit on create
body: https://github.com/conan-io/conan/blob/dd258e0aec228cdc59efc46dea624519998d221d/conans/util/files.py#L250-L252

If the path length is above the Windows standard path limit of 260 or so, the rmtree call fails to remove the directory, which later raises an exception when conan tries to create it again to copy the sources into.
After some digging around I found this workaroung for python when it comes to removing long pathed directories, by using the '\\\\?\\' prefix.

So my suggestion is something like that,

```
modified_path = r'\\?\ '.strip() + path if platform.system() == "Windows" else path
shutil.rmtree(modified_path, onerror=_change_permissions) 
```

Please tell me what you think before I submit an official PR.
user: Gbd199
issue_7469: state: open
title: [bug] PKG_CONFIG_PATH from AutoToolsBuildEnvironment is not winbash compatible
body: Currently, when using the pkg_conf generator with the AutoToolsBuildEnvironment,
windows paths are used in the PKG_CONFIG_PATH environment variable.

When using the `pkg_conf` generator, this causes `PKG_CONFIG_PATH` to be defined as:
`PKG_CONFIG_PATH='C:\Users\maarten\.conan\data\libusb-compat\0.1.7\_\_\build\ec6e396fb18bc2299d9ae033be6cad9af083007d:/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'` (extracted from `config.log`)

Note the backward Windows slashes in the first path.
It should replace all backward slashes with forward slashes, or use a unix_path.

As a workaround, I currently run autotools.configure as:
```python
pkg_config_paths = [tools.unix_path(self.install_folder.replace("\\", "/"))]
self._autotools.configure(..., configure_dir=self._source_subfolder, pkg_config_paths=pkg_config_paths)
```

Code reference:

https://github.com/conan-io/conan/blob/770602e142e3fd15eb25f5eff8ba3832be7bcd44/conans/client/build/autotools_environment.py#L163:L171



### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10
  * Compiler+version: Visual Studio 2017 
  * Conan version: 1.27.1
  * Python version: 3.8.5

user: madebr
issue_7462: state: open
title: FileCopier is slow (ubuntu 18)
body: Conan `export-pkg` command is very slow.

Tested on recipe https://github.com/blockspacer/llvm_tools

NOTE: `def package` copied files fast enough (tested by extra logging via custom `def copytree`, see recipe of llvm_tools)

I suppose that slowdown in conan internals, maybe in `copier("*", symlinks=True)` https://github.com/conan-io/conan/blob/8d72743404c50f945522e77d0fce72d9ccef5a5e/conans/client/packager.py#L19

Slowdown may happen because of copy file-by-file, but it is possible to copy whole dir (OS-specific command like https://serverfault.com/questions/43014/copying-a-large-directory-tree-locally-cp-or-rsync may help to increase speed)

Log:

```bash
cd ~/llvm_tools
conan export-pkg .   conan/stable   --package-folder local_build_msan/package_dir   --settings build_type=Release   --force   --profile clang     -o llvm_tools:include_what_you_use=False     -o llvm_tools:enable_msan=True
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'url'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'license'. It is recommended to add it as attribute
Exporting package recipe
llvm_tools/master@conan/stable exports: Copied 1 '.md' file: LICENSE.md

llvm_tools/master@conan/stable exports_sources: Copied 1 '.md' file: README.md
llvm_tools/master@conan/stable: A new conanfile.py version was exported
llvm_tools/master@conan/stable: Folder: ~/.conan/data/llvm_tools/master/conan/stable/export
llvm_tools/master@conan/stable: Using the exported files summary hash as the recipe revision: 76ae683b591a57659165460a4d8130c3 
llvm_tools/master@conan/stable: Removing the local binary packages from different recipe revisions
llvm_tools/master@conan/stable: Exported revision: 76ae683b591a57659165460a4d8130c3
self.settings.compiler clang
llvm_tools/master@conan/stable: Forced build from source
Packaging to e6be9f1fb85d81638de3d41cd56bc961317378ca
llvm_tools/master@conan/stable: Exporting to cache existing package from user folder
llvm_tools/master@conan/stable: Package folder ~/.conan/data/llvm_tools/master/conan/stable/package/e6be9f1fb85d81638de3d41cd56bc961317378ca
llvm_tools/master@conan/stable: Packaged 421 files
llvm_tools/master@conan/stable: Packaged 209 '.h' files
llvm_tools/master@conan/stable: Packaged 3 '.modulemap' files: module.modulemap, module.modulemap, module.modulemap
llvm_tools/master@conan/stable: Packaged 1408 '.cmake' files
llvm_tools/master@conan/stable: Packaged 5 '.def' files
llvm_tools/master@conan/stable: Packaged 156 '.marks' files
llvm_tools/master@conan/stable: Packaged 1233 '.make' files
llvm_tools/master@conan/stable: Packaged 169 '.internal' files
llvm_tools/master@conan/stable: Packaged 188 '.inc' files
llvm_tools/master@conan/stable: Packaged 352 '.a' files
llvm_tools/master@conan/stable: Packaged 4 '.1' files: libc++abi.so.1, liblldb.so.10.0.1, libc++.so.1, libunwind.so.1
llvm_tools/master@conan/stable: Packaged 6 '.10' files
llvm_tools/master@conan/stable: Packaged 17 '.so' files
llvm_tools/master@conan/stable: Packaged 3 '.0' files: libunwind.so.1.0, libc++.so.1.0, libc++abi.so.1.0
llvm_tools/master@conan/stable: Packaged 1969 '.o' files
llvm_tools/master@conan/stable: Packaged 151 '.txt' files
llvm_tools/master@conan/stable: Packaged 147 '.includecache' files
llvm_tools/master@conan/stable: Packaged 8 '.syms' files
llvm_tools/master@conan/stable: Packaged 1 '.exports' file: LLVMHello.exports
llvm_tools/master@conan/stable: Packaged 2 '.lld' files: ld64.lld, ld.lld
llvm_tools/master@conan/stable: Package 'e6be9f1fb85d81638de3d41cd56bc961317378ca' created
llvm_tools/master@conan/stable: Created package revision 33cb5c79acc0aa0c4edf00d38db91762
```

BTW is it possible to turn off `report_files_from_manifest` ?

BTW conan `Packaged 1969 '.o' files` but  '.o'  files are in `ignore_list` (see `def copytree`). Is it bug?
user: blockspacer
issue_7458: state: open
title: [bug] Artifactory virtual repository deployment permission denied with use CLI configured password
body: ### Environment Details (include every applicable attribute)
  * Conan version: 1.27.1
  * Python version: 3.8.5
  * Artifactory version: 6.13.0 rev 61300900

### Steps to reproduce (Include if Applicable)
Create on Artifactory a Conan virtual repository (to mitigate #6743)  which consist out of one local Conan repository and one other virtual Conan repository. On the virtual repository you will set the `defaultDeploymentRepo` to one of the local repositories.

Setup single remote to the Conan virtual repository and configure the user and password for the local repository like:
`conan user -r 'my-remote' -p '<password>' 'my-user'`. Then you won't be able to upload through the Artifactory virtual repository.

Worth to note instead of using the `-p '<password>'` parameter when setting up the user, but enter it when prompted or set by using `CONAN_PASSWORD` there is no issue then.

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
Uploading to remote 'my-remote':
Uploading glm/0.9.9.0@local/testing to remote 'my-remote'
Compressing conan_export.tgz completed [2 files]
Compressing conan_sources.tgz completed [1 files]
ERROR: glm/0.9.9.0@local/testing: Upload recipe to 'my-remote' failed: Permission denied for user: 'my-user'. [Remote: my-remote]

ERROR: Errors uploading some packages
```
user: maikelvdh
issue_7450: state: open
title: [feature] Additional --build functionality for build_requires and requires
body: There are really two types of dependencies and requirements modeled in conan, `requires` and `build_requires`. As noted in the conan documentation, these are intended for different purposes, however once you include either they get added to the graph in roughly the same way meaning they are treated basically the same from the perspective of most recipes. This is great for some purposes but not others.

I would like a way to build only my `requires` and leave my `build_requires` alone when performing a full graph build using `conan install <conanfile> --build` 

An example of what to implement could look something like `conan install <conanfile> --build=requires`

This would be extremely useful because it usually doesn't make sense to recompile or re export and package `build_requires` considering they are supposed to be build "tools" such as compilers and other such executables or packages. 

As an example of my use case, I have a custom compiler I import as a build requires. The only thing this recipe does is package the compiler and its requirements. It doesn't make sense to build this and re package it as part of an install command

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: Daniel-Roberts-Bose
issue_7446: state: open
title: How to configure Squish coco codecoverage with Conan+Cmake build
body: I want to configure Squish codo codecoverage with Conan+CMake+gTest build system.

Can you please help me in finding documentation URL for right configuration to achieve it for enterprise level application.

Thanks,
Prasad
user: Prasaddiwalkar
issue_7439: state: open
title: [feature] Make checking remotes for updates an opt-in behaviour through conan.conf
body: Currently you need as an user to always declare `--update` in order to check remotes if there are any updates to a package. It would be nice to make this also a configurable option within the `conan.conf` configuration to do this check always in case you have opted-in for this behaviour.

This behavior would for example greatly help if you are relying on revisions and would like to guarantee that everyone is having the latest version installed in their cache.

user: maikelvdh
issue_7438: state: open
title: [question] import shared dlls in multi environment (Windows, VS)
body: Hello, 
I have a question regarding _[import]_ section in the _conanfile.txt_ and how it suppose to deal with the multiple environment. 

- **OS:** Windows 
- **Conan version:**  1.25.2
- **Conan generator:** cmake, visual_studio_multi, cmake-multi

**Issue**
I have next  _conanfile.txt_ file

```
[requires]
cpprestsdk/2.10.14@bincrafters/stable
zmqpp/4.2.0@bincrafters/stable

[generators]
cmake

[options]
cpprestsdk:exclude_websockets=True
cpprestsdk:shared=True
zmqpp:shared=True

[imports]
bin, *.dll -> ./bin/Release @ root_package=cpprestsdk
bin, *d.dll -> ./bin/Debug @ root_package=cpprestsdk
bin, *.dll -> ./bin/Release @ root_package=zmqpp
bin, *d.dll -> ./bin/Debug @ root_package=zmqpp
```

I install my conan dependencies like this:
One for Debug and one for Release
```
conan install . -if [build_x64] -s build_type=Debug -s arch=x86_64 --build missing -g visual_studio_multi -g cmake_multi -s compiler.version=15 -s compiler.toolset=v141
conan install . -if [build_x64] -s build_type=Release -s arch=x86_64 --build missing -g visual_studio_multi -g cmake_multi -s compiler.version=15 -s compiler.toolset=v141

```
It downloads and builds everything as needed, also VS (due to visual_studio_multi generator) has all dependencies, all locations to libraries and headers (at least haven't noticed problems at the moment)

However, the _[import]_ command seems to be working not as expected for multi config case.
with the above commands I have **build_x64** folder creates with **bin\Debug** and **bin\Release** sub folders. 

after _conan install_ command is executed the Debug and Release folder are populated with next files:
Release -> 
cpprest141_2_10.dll
cpprest141_2_10d.dll
zmqpp.dll

Debug ->
cpprest141_2_10d.dll 

Here is my first question: Why release folder has two binaries of cpprest (one debug and one release) ?

As you can see, the Debug directory doesn't have _zmqpp.dll_ . It looks like **zmqpp** doesn't add 'd' to the debug library name. So I then have changed the _[import]_ section:
from: **_bin, *d.dll -> ./bin/Debug @ root_package=zmqpp_**
to: **_bin, *.dll -> ./bin/Debug @ root_package=zmqpp_**

Now, after I re-run the _conan install_ command my Debug folder has the _zmqpp.dll_ dll. However, it seems like it is not correct library. I took a look into the size of both libraries and their sizes are the same (for Debug and Release), but when I looked in the local-cached repository, it has two different folders for zmqpp package that has two dlls, with different size. 

Since I have _cmake-multi_ and _visual_studio_multi_ generators set should I add something specific either in the _conanfile.txt_, or somewhere else, so that conan can distinguish between debug and release and can import correct libraries into correct places ? 

Thanks in advance
user: afedechko
issue_7434: state: open
title: [bug] conan search should error if both -rev and -q  are set
body: If I run a search with `-q` without `-rev` I get the expected result, which is only packages matching that query are returned. If I run it with `-rev` I get a list of all packages returned, regardless of if they match the query.

### Environment Details (include every applicable attribute)
  * Operating System+version: Mac 10.15.5
  * Compiler+version: 
  * Conan version: 1.27.1
  * Python version: 3.7.0

### Steps to reproduce (Include if Applicable)
If I run a Conan search with an invalid query (one which should return nothing), I get the expected message, saying there are no packages.  
```
conan search boost/1.70.0@conan/stable -q  'os=Macos AND arch=x86_64 AND compiler=ugabuga' -r conan-center
Existing packages for recipe boost/1.70.0@conan/stable:

Existing recipe in remote 'conan-center':

There are no packages for reference 'boost/1.70.0@conan/stable' matching the query 'os=Macos AND arch=x86_64 AND compiler=ugabuga'
```

If I run it with the `-rev` flag, I get a package erturned, which is not correct:
```
conan search boost/1.70.0@conan/stable -rev -q  'os=Macos AND arch=x86_64 AND compiler=ugabuga' -r conan-center
Revisions for 'boost/1.70.0@conan/stable' at remote 'conan-center':
0 (2019-09-10 09:56:30 UTC)
```
user: timbrown5
issue_7431: state: open
title: Distributing and using a Yocto SDK via conan
body: I am looking for guidance and feedback from others who have used conan to produce a Yocto SDK (perhaps repackage it?), distribute it, and then use it in a separate project.  I have been told that this has been done before using the old cross-build model, that it was used as as `build-require`, and that there is better experimental support for cross building now.

At the moment, I am a total newbie to conan, and don't yet even know what I don't know, except that other folks in my organization are using conan, and they want an SDK from me.  So, I'm expecting this to be a learning adventure for me.

--wpd

user: wpd
issue_7428: state: open
title: [question] Conan package for patching other conan package
body: <!-- What is your question? Please be as specific as possible! -->

Let's assume I have the following portable compiler:
- `compiler_base` (size 1 GB): This is the base version of a portable compiler
- `compiler_patch_1` (size 1 MB): This is a patch for the compiler which needs to be applied on top of the `compiler_base` (so it's just a delta)
- `compiler_patch_2` (size 1 MB): This is a patch for the compiler above which needs to be applied on top of the `compiler_patch1` which needs to be applied on top of `compiler_base` (so it does not include `compiler_patch_1`)

Now we would like to have in the conan cache 3 compiler versions which can be called by the project depending on their needs:
- A: `compiler_base`
- B: `compiler_base` + `compiler_patch_1`
- C: `compiler_base` + `compiler_patch_1` + `compiler_patch_2`

Note: For a solution A, B or C could be either different packages or different versions of the same package

The intention is to save storage on Artifactory. Therefore we would like to avoid to package the `compiler_base` with each patch, because this would add another 1 GB for each patch even if the patch itself is just 1 MB. And patches might occur quite often.

If in the conan recipe of the `compiler_patch_1` we would just copy the `compiler_base` to `compiler_patch_1` in the conan cache then I'm afraid that the conan cache would be inconsistent (checksums), or?

=> Do you have an idea how to support the use case above?

---
- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: jokram
issue_7424: state: open
title: [question] Issues packaging a C++/CMake project that internally uses Conan for its own dependencies
body: I'm trying to create a Conan package for this C++/CMake project: https://github.com/tnt-coders/cpp-dsp

The package recipe I have so far is checked in here: https://github.com/tnt-coders/cpp-dsp-conan

When I run `conan create`, it seems like it only executes a `conan install` for the top level "conanfile.py" but does not execute it for the internal "conanfile.txt" that is located inside the "cpp-dsp" project. This causes the build to fail because it can't find the "conanbuildinfo.cmake" file for the "cpp-dsp" project.

What approach am I supposed to take for packaging a project that uses Conan in itself?

I tried using `export_sources` but since the CMakeLists.txt file is at the top level and not all contained within a single "src/" folder like every example online, the project doesn't seem to lend itself cleanly to using `export_sources`... When I finally did wrestle with `export_sources` until I got it to compile, the test_package would fail because the "cpp-dsp" package requires C++17 and the PUBLIC C++17 compiler flag for the "dsp" library wasn't properly being propagated to the "CONAN_PKG::cpp-dsp" target.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: tjwrona
issue_7419: state: open
title: [bug] Setting MSBuild.build toolset argument does not change the PlatformToolset MSBuild will use.
body: I have multiple versions of Visual Studio installed on my machine, and I need to build a .dll in Visual Studio 2015.

When I call 

> msbuild.build("solutionFile.sln", None, False, "Release", "x86", True, False, None, None, "v140")`

I get an error because it tries to link against another lib that was built with an older compiler. The error message outputs:

```
conanfile.py (myDLL/0.1): Error in build() method, line 41
        msbuild.build("solutionFile.sln", None, False, "Release", "x86", True, False, None, None, False)
        ConanException: Error 1 while executing set "VSCMD_START_DIR=%CD%" && call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC/Auxiliary/Build/vcvarsall.bat" x86 && msbuild "solutionFile.sln" /p:Configuration="Release" /p:UseEnv=false /p:Platform="x86" /m:8 /p:PlatformToolset="v142" /verbosity:minimal /p:ForceImportBeforeCppTargets="path\to\conan_build.props"
```

So its using the incorrect Visual Studio version (2019), and ignoring the toolset I passed in.

This is my conaninfo.txt: 

```
[settings]
    arch=x86_64
    build_type=Release
    compiler=Visual Studio
    compiler.runtime=MD
    compiler.version=14
    compiler.toolset=v140
    os=Windows

[requires]


[options]


[full_settings]
    arch=x86_64
    build_type=Release
    compiler=Visual Studio
    compiler.runtime=MD
    compiler.version=14
    compiler.toolset=v140
    os=Windows

[full_requires]


[full_options]


[recipe_hash]


[env]
```

AFAIK I'm not intentionally indicating anywhere that I want conan to use VS 2019. I specified "v140" for the toolset because I want it to use VS 2015.
user: ajmetal
issue_7418: state: open
title: [question] How should you handle binary compatibility as a consumer?
body: The product that I work on has roughly 100 conan packages that go into its making. Most of these packages are built with general purpose compilers (namely msvc and gcc), however a handful are built with the Intel Compiler.

This is what we want -- we don't want to build things like zlib or boost with the Intel Compiler, we want to use the general purpose compilers. This leads to a problem as a consumer though: How do I (as a consumer) specify what binaries are compatible?

This is important because it is unreasonable for every individual package use the compatible_packages feature to specify binary compatibility between the Intel Compiler and gcc/msvc, when the Intel Compiler is not a mainstream compiler.

Is there something like a package_id hook that I could use?
user: ohanar
issue_7417: state: open
title: [bug] deps_cpp_info doesn't get updated for editable packages
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->
I have the same directory layout as described in #6896

On Conan 1.27.1, I'm trying to use editable packages in my recipes. For one of my recipes, I have a package that I need to copy over some of the source, so I use
```python
self.run("cp -r {} repo1".format(self.deps_cpp_info["repo1"].rootpath))
```
I put repo1 into editable mode, using a layout file that looks like
```jinja
[source_folder]
../../repo1
```
However, when my `cp` command above runs, I get
```
----Running------
> cp -r /accts/cguldner/devkit/recipes repo1
-----------------
```
but I would expect to see 
```
----Running------
> cp -r /accts/cguldner/repo1 repo1
-----------------
```

Am I doing something wrong, or is there a bug here?
user: cguldner
issue_7411: state: open
title: [question] HowTo propagate includedirs for pkg consumers
body: # How to publish include dirs in some package and consume them in another?

I'd like to know how **SPECIFICALLY** to define the attributes of `self.cpp_info.*` so that they're correctly propagated to the command line interface and correctly parsed by the compiler e.g. gcc.

We've tried to set the following as follows, with no luck:
```python
def package_info(self):
  # if cross-building, we use a sysrooted file-system with some libs
  if tools.cross_building(self):
    self.cpp_info.includedirs = [
      "/usr/include/some/path",
      "/usr/include/some/path"
    ]
```
Other tests:
```python
def package_info(self):
  # if cross-building, we use a sysrooted file-system with some libs
  if tools.cross_building(self):
    self.cpp_info.includedirs = "-I=/usr/include/some/path", "-I=/usr/include/some/path"
```
another:
```python
def package_info(self):
  # if cross-building, we use a sysrooted file-system with some libs
  if tools.cross_building(self):
    self.cpp_info.includedirs = "-I=/usr/include/some/path -I=/usr/include/some/path"
```

The problem is, that those flags go into the CLI with escaped quotes (by what I assume is the `CMake` generator) than is fed to the compiler, like:

```
gcc -foo -bar "-I=/usr/include/some/path -I=/usr/include/some/path"
```
and obviously the compiler complains about those arguments with quotes.


Related Q: what would be best, to utilize `self.cpp_info.includedirs` with a list of includes or `self.cpp_info.cxxflags` with `-I=` prefixes?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: saimusdev
issue_7402: state: open
title: [question] How to deploy conan libraries with my application using cmake install()
body: I ported my cross-platform,  modern CMake-based application to use Conan library packages with transparent integration (conan_paths.cmake). Build and tests are good.

When I run the installer (cmake --install | build INSTALL project), everything is installed into the correct location. Now I need to include the new Conan libraries.

Since imported targets cannot be directly installed via cmake install(), I use workarounds such as:
```
install(
  PROGRAMS $<TARGET_FILE:sometarget>
  DESTINATION ${CMAKE_INSTALL_BINDIR}
)
```
However, since the Conan library targets are imported as INTERFACE, those generator expressions don't work with _libname::libname_ targets defined in the generated Find_libname_ scripts. Using "$<TARGET_FILE:CONAN_LIB::_libname_libname_[d]>" does work; however, on windows I get the linker file (.lib) instead of the runtime file (.dll).

I read the following:
- https://docs.conan.io/en/latest/integrations/deployment.html
- https://docs.conan.io/en/latest/devtools/running_packages.html#deployable-deploy-generator

Short of using a python script to convert the json deployment file into a cmake include with install(), I don't see any direct/easy way to deploy the Conan libraries.

What is the most efficient way to install Conan libaries along side my application for deployment?


user: glennaycock
issue_7387: state: open
title: emscripten 1.39.13 invalid settings.arch wasm
body: I am trying to follow the [conan emscripten hello world example here](https://docs.conan.io/en/latest/integrations/cross_platform/emscripten.html) on Ubuntu.

I run
```sh
git clone --depth 1 git@github.com:conan-io/examples.git
cd examples/features/emscripten
./build.sh
```

`build.sh` runs the commands
```sh
conan remove conan-hello-emscripten/* -f
conan create . conan/testing  -pr emscripten.profile --build missing
conan install conanfile.txt  -pr emscripten.profile
```

The `emscripten.profile` file in the current directory contains in the `[build_requires]` section:
```
[build_requires]
emsdk_installer/1.38.29@bincrafters/stable
ninja_installer/1.8.2@bincrafters/stable
```

This all works fine.

If I change the emsdk to `emsdk_installer/1.39.6@bincrafters/stable` this results in an error at link time (bigger log posted at the end) with output like `wasm-ld: error: zutil_49ed71bb.o: machine type must be wasm32`.

If I change the emsdk to `emsdk_installer/1.39.13@bincrafters/stable` however, then running `build.sh` produces this output and errors:

```
...
+ conan remove 'conan-hello-emscripten/*' -f
+ conan create . conan/testing -pr emscripten.profile --build missing
Exporting package recipe
conan-hello-emscripten/1.0@conan/testing exports_sources: Copied 1 '.txt' file: CMakeLists.txt
conan-hello-emscripten/1.0@conan/testing exports_sources: Copied 1 '.cpp' file: main.cpp
conan-hello-emscripten/1.0@conan/testing: A new conanfile.py version was exported
conan-hello-emscripten/1.0@conan/testing: Folder: /home/username/.conan/data/conan-hello-emscripten/1.0/conan/testing/export
conan-hello-emscripten/1.0@conan/testing: Exported revision: f6984cac6b69e70f11f00673968702c7
Configuration:
[settings]
arch=wasm
arch_build=x86_64
build_type=Debug
compiler=clang
compiler.libcxx=libc++
compiler.version=6.0
os=Emscripten
os_build=Linux
[options]
[build_requires]
*: emsdk_installer/1.39.13@bincrafters/stable, ninja_installer/1.8.2@bincrafters/stable
[env]

ERROR: Error while initializing settings. Invalid setting 'wasm' is not a valid 'settings.arch' value.
Possible values are ['x86']
Read "http://docs.conan.io/en/latest/faq/troubleshooting.html#error-invalid-setting"
```

I am unsure whether this is a bug, or not meant to work in the first place, or exactly what this means?

However it all works with `emsdk_installer/1.38.29@bincrafters/stable`.

Ubuntu 18.10 x64, conan 1.27.1

`emsdk_installer/1.39.6@bincrafters/stable` error:
```
[1/2] Building CXX object CMakeFiles/conan-hello-emscripten.dir/main.cpp.o
[2/2] Linking CXX executable bin/conan-hello-emscripten.html
FAILED: bin/conan-hello-emscripten.html 
: && /home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/upstream/emscripten/em++    --emrun CMakeFiles/conan-hello-emscripten.dir/main.cpp.o  -o bin/conan-hello-emscripten.html -L/home/username/.conan/data/zlib/1.2.11/conan/stable/package/05f762e5c704e71da2e451fecc074bbe60ae1bfc/lib   -L/home/username/.conan/data/nodejs_installer/10.15.0/bincrafters/stable/package/44fcf6b9a7fb86b2586303e3db40189d3b511830/lib -lz && :
wasm-ld: error: zutil_49ed71bb.o: machine type must be wasm32
shared:ERROR: '/home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/upstream/bin/wasm-ld -o /tmp/emscripten_temp_k8Oie3/conan-hello-emscripten.wasm --allow-undefined --lto-O0 CMakeFiles/conan-hello-emscripten.dir/main.cpp.o -L/home/username/.conan/data/zlib/1.2.11/conan/stable/package/05f762e5c704e71da2e451fecc074bbe60ae1bfc/lib -L/home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/upstream/emscripten/system/local/lib -L/home/username/.conan/data/nodejs_installer/10.15.0/bincrafters/stable/package/44fcf6b9a7fb86b2586303e3db40189d3b511830/lib /home/username/.conan/data/zlib/1.2.11/conan/stable/package/05f762e5c704e71da2e451fecc074bbe60ae1bfc/lib/libz.a -L/home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/.emscripten_cache/wasm-obj /home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/.emscripten_cache/wasm-obj/libc.a /home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/.emscripten_cache/wasm-obj/libcompiler_rt.a /home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/.emscripten_cache/wasm-obj/libc-wasm.a /home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/.emscripten_cache/wasm-obj/libc++-noexcept.a /home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/.emscripten_cache/wasm-obj/libc++abi-noexcept.a /home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/.emscripten_cache/wasm-obj/libdlmalloc.a /home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/.emscripten_cache/wasm-obj/libpthread_stub.a /home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/.emscripten_cache/wasm-obj/libc_rt_wasm.a /home/username/.conan/data/emsdk_installer/1.39.6/bincrafters/stable/package/83753ef0acbb6f750f6b8535092aae8d58e88098/.emscripten_cache/wasm-obj/libsockets.a --import-memory --import-table -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --strip-debug --export __wasm_call_ctors --export __data_end --export main --export malloc --export free --export setThrew --export __errno_location --export fflush --export _ZSt18uncaught_exceptionv -z stack-size=5242880 --initial-memory=16777216 --no-entry --max-memory=16777216 --global-base=1024' failed (1)
ninja: build stopped: subcommand failed.
conan-hello-emscripten/1.0@conan/testing: 
conan-hello-emscripten/1.0@conan/testing: ERROR: Package '5bed01a63353e98dcb3a000b1f1089df5f3d8b83' build failed
conan-hello-emscripten/1.0@conan/testing: WARN: Build folder /home/username/.conan/data/conan-hello-emscripten/1.0/conan/testing/build/5bed01a63353e98dcb3a000b1f1089df5f3d8b83
ERROR: conan-hello-emscripten/1.0@conan/testing: Error in build() method, line 25
	cmake.build()
	ConanException: Error 1 while executing cmake --build '/home/username/.conan/data/conan-hello-emscripten/1.0/conan/testing/build/5bed01a63353e98dcb3a000b1f1089df5f3d8b83' '--' '-j8'
```
user: Arghnews
issue_7386: state: open
title: [bug] Link error with project base qmake
body:   * Operating System+version: MacOS 11
  * Compiler+version: android ndk r21
  * Conan version: Conan version 1.27.1
  * Python version: 3.8.4

the problem in function conan_basic_setup of file conanbuildinfo.pri
`
LIBS += $$CONAN_LIBS
LIBS += $$CONAN_LIBDIRS
`

After I separate config for each library. project build successful
`
LIBS += $${CONAN_LIBDIRS_COUCHBASE_LITE_CORE} $${CONAN_LIBS_COUCHBASE_LITE_CORE}
LIBS += $${CONAN_LIBDIRS_NEWMAT} $${CONAN_LIBS_NEWMAT}
LIBS += $${CONAN_LIBDIRS_ARROW} $${CONAN_LIBS_ARROW}
LIBS += $${CONAN_LIBDIRS_THRIFT} $${CONAN_LIBS_THRIFT}
LIBS += $${CONAN_LIBDIRS_DOUBLE_CONVERSION} $${CONAN_LIBS_DOUBLE_CONVERSION}
LIBS += $${CONAN_LIBDIRS_BROTLI} $${CONAN_LIBS_BROTLI}
LIBS += $${CONAN_LIBDIRS_SNAPPY} $${CONAN_LIBS_SNAPPY}
`
[compile_error.txt.zip](https://github.com/conan-io/conan/files/4946741/compile_error.txt.zip)

.
user: nguoithichkhampha
issue_7381: state: open
title: [feature] Make it possible to extend virtualenv-generator environment-variables from within a consumer
body: Let's say i have a **provider-package** that in its `package_info` defines some **environment-variables**.
I also have a **consumer-package** which uses the `virtualenv`-generator, wants to use the virtual environment created by the provider-package, 
but wants to set some environment-variables itself, so that the **union** of the environment-variables from the provider and the consumer all land in *environment.sh.env*,
and a call to `source activate.sh` is all that a lazy developer has to do to use the resulting virtual environment.

It seems to me that it is currently not possible to extend a virtualenv from within the  consumer-package.
If it is, then i am sorry to have wasted your time (a small hint at how it is possible would be very kind)

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: LeonFretter
issue_7368: state: open
title: [bug] incomplete dangerous dependency resolution in Conan
body: Conan dependancy resolution seems to be incomplete.
I configured `conanfile.txt` as follows:

[requires]
boost/1.69.0
wt/4.3.1


And `Conan` happily installed both libraries, although `Wt` was built with `boost-1.73.0` as seen at https://conan.io/center/wt/4.3.1/?user=_&channel=_&revision=&os=Linux&tab=config

The application build ended with linkage error:

``
/bin/ld: /root/.conan/data/boost/1.69.0//_/package/7068ed10403246f8331cfec6288fde7b48f7bc8a/lib/libboost_thread.a(thread.o): relocation R_X86_64_PC32 against undefined hidden symbol `_ZTCN5boost10wrapexceptINS_21thread_resource_errorEEE0_NS_16exception_detail10clone_implINS3_19error_info_injectorIS1_EEEE' can not be used when making a shared object
/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make[2]: [../../Makefile.rules:191: some.so] Error 1
``

And this was a luck the issue revealed at this stage.
In a bad case, the linkage could have passed successfully, but memory could have been corrupted at runtime in sporadic cases.

Isn't `Conan` expected to display an error message about libraries incompatibility and bail out?

I'm not a Conan expert so please forgive me if I'm missing some configuration steps.

### Environment Details
  * Operating System+version: Centos8
  * Compiler+version: gcc version 8.3.1 20191121 (Red Hat 8.3.1-5) (GCC)
  * Conan version: 1.27.0
  * Python version: 3.6.8

user: pcapdump
issue_7357: state: open
title: [feature] A minimal version range selection algorithm
body: ## The Issue

Conan's cornerstone feature is distributed caching. 

The issue is that it's extremely hard to produce reliable graphs with compatible binary hashes - such issues as transitive dependencies, package_id_modes, cppstd, Glibc, and such which we don't have a definite answer for yet. 

> Note that Lockfiles are not an answer to this issue since they work only for a very restrictive set of combinations, which is a nature of an end application rather than a library. 

It leads to a problem where we need to either always build missing or to never change the graph (including from consumers). 
Both ways indicate very inefficient use of caching in environments where updates do happen, even if in a controllable manner. If we work in a non-controllable environment (such as using binaries from conan-center) we simply can't use ranges 

There were previous discussions (eg https://github.com/conan-io/conan/issues/7348) on the topic of having a more sophisticated artifact searching algorithm in the context of range version selection. But there is no optimism regarding an implementation.

What we want is to reuse existing binaries more efficiently.

## A Solution

Conan should consider adopting [Go's version selection approach](https://research.swtch.com/vgo-mvs) of picking minimal possible constraints instead of searching for the latest possible versions. It means that if your projects had a `[^1.1.1]` version range - Conan will prefer to pick the 1.1.1 version unless there is another project in the graph that requires a project with a higher minimal version number.

### What's in it for Conan?

The paper mentions a lot of benefits (read the paper!) for the algorithm, but for Conan, specifically, the greatest benefit is that if a library used a certain version of dependencies when it was built - they will be reused on a consumer unless they require (even transitively) a higher version of dependency on their own. Even if there were releases of these dependencies on the upstream.

As a by-product, it solves the issue of "soft" lockfiles for Conan. Conan implements lockfiles as a strict configuration environment, where everything is set in stone. And it's very useful for end applications, but it doesn't work for libraries and, most importantly, for consumers. A minimal version selection algorithm will ensure that versions with which a project was tested with are used. It's a much more pleasant user experience story. And while we know about best practices related to "if a range is specified - everything in it should just work" - real life happens and we'd want incompatibility incidents to happen in a controllable manner instead of a by default. 

### How is it different from fixed versions?

Using a fixed version will produce a conflict error unless explicitly overridden. But overriding also overrides ranges, so you can override out of specified ranges, which is error-prone and requires human attention. Ranges are definitely a quality of life feature that we want to keep using to make some contracts about dependencies and making sure that Conan can operate on that to automatically resolve as much as possible producing a satisfying to end-consumers results.  

### It'll not update patches automatically, isn't it a security risk?

It's indeed a concern, papers on the topic indicate that an appropriate solution for that is to use automatic override update in consumers. Conan had issues on the topic, it could be done for now with an override feature, but in the future, we may have more automatic update commands similar to Node, Go, and Rust. 

### It's very Go

Quite not, Vcpkg is also in the process of implementing a similar model for their multi-version range selection: https://github.com/microsoft/vcpkg/pull/11758

### Compatibility

The algorithm could be enabled in the `conan.conf` with a potential default behavior candidate in some late major versions if the user-experience proves it the right fit.

## Related

https://github.com/conan-io/conan/issues/7348
https://github.com/jgsogo/conan-poc-graph/issues/5

user: Minimonium
issue_7354: state: open
title: [feature] Extending the Graph Info Template API
body: I've playing aroung the new feature provided at https://github.com/conan-io/conan/pull/7176 in https://github.com/alacasta/beautified-conan-info-dot-template and I miss some fields that can be really useful when building the dep. graph:
- Each (node) field separated (please, consider user/channel only in case they won't be deprecated soon)
  - name
  - version
  - channel
  - user
- Root node
- build require context

At least these were missing when trying to adapt https://github.com/conan-io/conan/pull/6815 to the template previously cited. and i consider them useful fields which can enrich the information provided in these kind of diagraphs. 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: alacasta
issue_7374: state: open
title: VS Code extension
body: I know that technically, this is not the right project to submit this, but VS Code is crying out for a decent Conan extension!

With the CMake extension installed, a C++ project is easy for users build and run. But when Conan is the preferred (not mandatory) way for that project to manage dependencies, it creates a significant impediment. A couple of things must be done manually and they are not necessarily obvious to the user.

Firstly, the Conan install step needs to be performed in the project *before* the CMake configuration step.

Secondly, a configuration parameter needs to be passed from Conan to CMake. For example, using the _cmake_paths_ generator, the appropriate configuration (as stored in _.vscode/settings.json_) is:

```json
{
    "cmake.configureSettings": {
        "CMAKE_PROJECT_INCLUDE": "${workspaceFolder}/build/conan_paths.cmake",
    },
}
```

Using the _cmake_find_package_ generator, a similar setting would be:

```json
{
    "cmake.configureSettings": {
        "CMAKE_MODULE_PATH": "${workspaceFolder}/build",
    },
}
```

I know this is a bit more complicated. I may even have got this wrong. And perhaps it would best be done in collaboration with the CMake extensions. But the first step, the `conan install` automation would be a huge help alone.

Thanks!
user: johnmcfarlane
issue_7348: state: open
title: [RFC] conan dependency resolution policy
body: Let's say I have the following packages:
- `subdep/1.0`, `subdep/1.1`.
-  `dep/1.0` that was built with `subdep/1.0`. Where `dep` has `requires='subdep/[>=1.0]'`.
- `pkg` with `requires='dep/[>=1.0]'`.

Now, when trying to build `pkg` there will be the following dependency resolution:
```
Requirements
    dep/1.0 from local cache - Cache
    subdep/1.1 from local cache - Cache
Packages
    dep/1.0:13d87f321c5de7f5c36592ea7338ce73e9adb226 - Missing
    subdep/1.1:3f6a4e73399b653b1e362ca7aca98ae112a41b0f - Cache
```

Which means that `pkg` can't be built without rebuilding `dep` with `subdep/1.1`.

In other words it means that the only available dependency resolution policy (DRP) for conan is `build_the_whole_dep_chain_with_the_latest_available_versions`.

There are several problems with such DRP:
- Let's say we have a super-long dep-chain `pkg`>`dep`>`subdep`>...>`(subxN)dep`.
  If a new `(subxN)dep` is published, the whole chain is invalidated, i.e. it's impossible to build `pkg` without rebuilding *every* `(subxi)dep`.
  It's much worse if we have a build environment, where each dependency is pre-built on CI. Each dependency has a lot of tests outside of `conanfile.py`, i.e. it's impossible to use `--build-missing`, since it will skip all the CI tests. Now, a new release of the dependency was published, so the whole dep-chain is invalidated. Which means that every developer working on a package that has this transitive dependency won't be able to work on that package until the whole chain is rebuilt (even if said dependency does not introduce any conflicts).
- Let's say we have a dep-chain from the example above (i.e. `pkg`>`dep`>`subdep`). We have  `dep/1.0` that was built with `subdep/1.0`. Next, `subdep/1.1` is released, but it's actually incompatible with `dep`. So, `pkg` can't be built, because it requires `subdep/1.1` (as transitive dependency), but `dep` can't be rebuilt, because it's incompatible with `subdep/1.1`.
- Let's say we have a dep-chain from the example above (i.e. `pkg`>`dep`>`subdep`) and we want to use a pre-built fixed version of `dep` in `pkg` via `requires='dep/1.0'`. This will not work (without manually specifying `subdep` version in `pkg`).

TLDR: current DRP is only usable in two scenarios:
- Hard-code ALL dependency versions in recipe, which is not really scalable and nearly impossible to maintain for big dependency chains.
- Build all dependencies from sources and upload them when building a package, which is not possible if there is a need for external tests (e.g. on CI) and/or if there is a controlled environment where packages are isolated (i.e. it's impossible to upload `subdep` as a part of the `dep` creation process).

The only proper way to solve this is to make DRP customizable. For example:
- `use-prebuilt-strict`: uses only those pre-built packages that were used during the build of the relevant package. E.g. if `pkg` depends on `dep` and there is only one pre-built `dep/1.0` that was built with `subdep/1.0`, then dep resolution of `pkg` will result in `dep/1.0` and `subdep/1.0`.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: TheQwertiest
issue_7339: state: open
title: Cross compiling from macOS to Emscripten fails because of automatically added -stdlib=libc++
body: ### Environment Details
  * Operating System+version: macOS 10.15.5
  * Compiler+version: Apple clang version 11.0.3 and Emscripten 1.39.19
  * Conan version: 1.27.0
  * Python version: 3.7.7

### Problem description

I'm not quite sure if this is a bug, a missing feature or a configuration error, but the issue is somewhat related to issue #2856. Just like Android, the Emscripten compiler does not need `-stdlib=libc++`. I could probably get around this issue by specifying `compiler.libcxx=c++_static` in the host profile in which case the `conan_set_libcxx` macro in the generated CMake file would not add the `-stdlib=libc++` flag, however this is only a valid option when setting the compiler to `clang`. On the other hand I can't set the compiler to `clang`, because the highest available version number is `10` while the latest version number of `apple-clang` is `11`. This mismatch will throw an error when installing packages, because Emscripten's toolchain file automatically sets the compiler version to that of the system clang.

Ideally I'd need a way to remove the `compiler.libcxx` setting when the host os is `Emscripten`. Is there a way to do this? 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: sascha
issue_7316: state: open
title: [feature] Load and lock direct dependencies from external files
body: Hello,

Here is my idea, can you tell me if I am wrong somewhere. I come from the Python world where we deal with the requirements and lock file from many times, and it is far from being perfect.

Today I am working on a way to use Conan on our C++ modules that does things manually, Conan is the perfect match for packaging them and made reuse of code easy for developers.

So, my needs are the following:
- we are using `conanfile.py`, not the `txt` version.
- requirements (and maybe build_requirements as well) have to be put in an easy-to-edit text file that lives aside of the conanfile.py, so it can be easily patched by an automation (I want to build something like pyup that will be able to automatically create merge requests with up-to-date versions)
- I would like some 'lock' mecanism, ie a way to freeze the dependencies but simplify updating them. In the Python world, we describe our direct dependencies: Let's have A depends on B which depends on C, so C is the direct dependency of B and B is the direct dependency of A. C is a transitive dependency of A.  What I would like is something like `Pipfile/Pipfile.lock or pyproject.toml/poetry.lock or requirements.txt/requirements.txt.in (for some that knows pip-tools):
  - as a developer, I say A depends on B on the range version `[>=1.0,<2.0]`, for instance.
  - an freeze command is executed and freeze at least all the direct dependencies in another file (`conan-frozen-requires.txt`, where it tells A depends on `B==1.2` and `C==4.0`)
  - next install will only use these versions of B and C
  - to update the dependencies, a command `conan update` or alike is provided, his job is to look in the remotes if new versions are available, that still respects the range limiters defined in the requirements

From what I understood, the conan.lock is way too specific to the current build machine and cannot be commited to ensure reproductible builds.


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: gsemet
issue_7308: state: open
title: [question] Override settings for specific dependencies in recipe
body: I am integrating libraries from a 3rd-party supplier into an app and want to share the binaries with them to support their own debugging.  To protect some sensitive IP, I want to only pull the `build_type=Release` packages for some of our internal requirements to prevent the debug symbols being visible in the final binary.

I know this is currently possible in [profiles](https://docs.conan.io/en/latest/reference/profiles.html#package-settings-and-env-vars), but I'd like to have an option for this type of package (e.g. `options = {"supplier": [True, False]}`) and so I think I need to be able to set it in the recipe.  Is there currently any way to do this?
user: GordonJess
issue_7304: state: open
title: [question] How to add a dependency package .so to the LD_LIBRARY_PATH?
body: I have a project that contains several other smaller dependencies, and some of them can be present during runtime, but they don't have to be. I'd like to append their lib dirs to the LD_LIBRARY_PATH and, during runtime, try to access them via dlopen, like the plugin. For that to work, I need to set the path of my plugin lib, but I'm not sure how to do it. I've found this in one of the man pages.

```python
def package_info(self):
      # use prepend() to override the default python path
      self.env_info.path.prepend(os.path.join(self.package_folder, "bin"))
      self.env_info.LD_LIBRARY_PATH.prepend(os.path.join(self.package_folder, "lib"))
```

But when I build that dependency and create a package from it, I don't see the path set in the LD_LIBRARY_PATH.

I'm new to Conan, and maybe I'm not getting it right. I thought that when the dependency is built, if the above code is present in its conanfile.py, it will set the env variable (LD_LIBRARY_PATH in this case) so it can be consumed by someone later (another package, executable, etc.). Can you please help me with this? Thanks!

<!-- What is your question? Please be as specific as possible! -->

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: vrafi
issue_7300: state: open
title: [bug] Conan remove --locks doesn't work
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Windows 10
  * Mingw64 gcc 9.2
  * Conan 1.27.0:
  * Python version: 3.7

### Steps to reproduce (Include if Applicable)

Tried to install ZMQ https://conan.io/center/zmq/4.3.2/  entered in password wrong (also plain text visibility on password...?? what...?) conan apparently couldn't handle it, and after an hour, nothing, ctrl-c, quit, nothing worked.  I manually closed the gitbash window and tried again, was met with 

```
$ conan install .. -s compiler=gcc
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

zmq/4.3.2@bincrafters/stable is locked by another concurrent conan process, wait...
If not the case, quit, and do 'conan remove --locks'
You pressed Ctrl+C!
ERROR: Exiting with code: 3
```

so I run

```
$ conan remove --locks
Cache locks removed
```

and try again. This time I get

```
$ conan install .. -s compiler=gcc
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

zmq/4.3.2@bincrafters/stable is locked by another concurrent conan process, wait...
If not the case, quit, and do 'conan remove --locks'
You pressed Ctrl+C!
ERROR: Exiting with code: 3
```

the same exact thing. 

I check my .conan folder, low and behold, I see stable.count.lock and stable.count both still there. 

stable.count contains a -1, I don't know if that means anything.  stable.count.lock is empty. 

So apparently removing the lock didn't remove the lock. 

So after manually removing the lock, I was able to restart the installation.  Unfortunately the install still didn't work, even after inputting the correct credentials.  Conan still sits there and doesn't give any feedback or indication that anything is happening.  I suspect this potentially has something to do with proxy permissions or something, but with out any feedback, it is impossible to tell. 
user: Cazadorro
issue_7285: state: open
title: [question] How to combine a compiler package with a CMake toolchain file?
body: Hi guys,

I'm struggling to make conan work with a compiler that also needs a CMake toolchain file to work. To fully understand the problem I'll quickly go over the setup. There are two systems:
* a **windows** based **build machine** (Windows 10, conan 1.25.1) 
* a custom **linux host** (custom kernel, gcc 4.8, does not run conan)

That means we are cross-compiling from windows to linux. We use **CMake** as the build system. CMake needs a **toolchain file** for the compiler (there is a chicken-egg problem in cmake when compilation needs a sysroot to succeed, which is the case for us).
We want the conan ecosystem to be independent from outside factors such as installed software, so naturally it makes sense to package the compiler with conan. To model the dependency between compiler and toolchain file, it would also make sense to include the CMake toolchain file in the package or model the dependency differently.

It's worth noting that the toolchain file needs to know the location of the compilers in order to configure `CMAKE_SYSROOT` and all the other paths to the compiler tools (e.g. `CMAKE_C_COMPILER`). The sysroot path is currently passed as an environment variable to the toolchain file (if there is a better way, please let me know).

From reading the documentation, it looks like the modern way is to use two profiles: **win_build** and **linux_host**. One of them should have a `build_requires` dependency on the compiler package. I tried with `linux_host` but that didn't work out.

So essentially my question is: How is conan designed to work in that scenario?
* Should the compiler package also ship the toolchain file? If not, how to model the dependency?
* Should I use `build_requires('compiler-package')` in one of the profiles? which one?

A slightly different question regarding the new experimental toolchain feature: Are there any plans to make this feature work together with "old-school" CMake toolchain files such that no modifications on the client side are required?

Thanks in advance for your help, you're doing a great job with conan!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: slietzau
issue_7283: state: open
title: [question] Availability of self.export_folder
body: Hello,

I am in the process of automatically generating dependency information for boost.
See https://github.com/conan-io/conan-center-index/pull/1925#issuecomment-651746386 for the progress.

Using [export](https://docs.conan.io/en/latest/reference/conanfile/methods.html#export), I copy the dependency information to the export folder. This has to be copied to the export folder because the information needs to be available in `package_info`, where no source_folder or build_folder exists.

But `self.export_folder` is unavailable in `package_info`.
```
AttributeError: 'BoostConan' object has no attribute 'export_folder'
```

So my question is: **How do I access the export folder in package_info?**

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: madebr
issue_7275: state: open
title: Meson in all the nodes of the CI
body: If we want to start testing some integration with Meson, we need to add the application to the CI nodes. We don't install `meson` in our release tests (https://github.com/conan-io/test), and it is not available in the venv.

**This issue should be closed only after some tests actually use Meson application.** https://github.com/conan-io/conan/pull/7273

Need for https://github.com/conan-io/conan/pull/7155
user: jgsogo
labels: component: CI: Affect ONLY to CI
issue_7269: state: open
title: [question] How to handle install of 3rd party python packages with conan?
body: What is the recommend approach of handling python modules which are needed by some C++ libraries for code generation?
E.g. I have a C++ library A which need some specific python module installed. How should the conan recipe for A should look like?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: derived-coder
issue_7256: state: open
title: [feature] Support for new OSX arm binaries
body: Thanks to @jcar87

Env:
```
DEVELOPER_DIR=/path/to/Xcode12.0.app
MACOSX_DEPLOYMENT_TARGET=11.0
CMAKE_OSX_ARCHITECTURES=arm64
SDKROOT=/path/to/Xcode12.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk
```

In settings.yml:
- add Macos version 11.0
- add apple-clang version 12.0
- Use ``armv8`` as arch

Pass ``-arch arm64`` to the compiler.
If cmake scripts evaluate CMAKE_SYSTEM_PROCESSOR, it is necessary to define it in toolchain, otherwise it thinks it is Intel.

https://gitlab.kitware.com/cmake/cmake/-/issues/20863

user: memsharded
issue_7255: state: open
title: [question] Using different versions of packages in build_requires as settings in conanfile.py
body: We use a thirdparty tool for generating code (basically an IDL compiler) that I've created a devtool conan package for.  This tool does get updated somewhat frequently.  Now in our code for pulling in the tool, I've defined something like this:

```
class FooConan(Conanfile):
   ...
   ...
   build_requires[("tool/1.2.3")]
```
But really I'd like to have that tool as one of the settings in the package, so that I can rebuild the package without changing the recipe.  Something like:

```
class FooConan(Conanfile):
   ...
   ...
   settings = "os", "compiler", "build_type", "arch", "tool_version"
   build_requires[("tool/<tool_version>")]
```

I have a lot of packages that will use this tool, and I don't want to have to bump the tool version for every package each time I update the tool.  I'd prefer to just update the build setting.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: craigaiken
issue_7249: state: open
title: [question] Export/import pre-built conan packages?
body: <!-- What is your question? Please be as specific as possible! -->
Is it possible to transfer pre-built conan packages in binary format without using conan_server?

Background: We have some conan packages with uncommon build requirements and would like to transfer them to colleagues that may not be in the same network and thus don't have access to our conan_server.

It seems to me as if the ``conan upload`` and ``download`` commands already have some of the required functionality in that they package everything together and upload/download it directly to/from a conan_server. We'd like to do the same thing but instead have direct access to the zipped packages to send them e.g. via network share or e-mail. I could imagine having a conan command to export/import a pre-built package instead (similar to how ``docker load`` and ``save`` work).

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: fschoenm
issue_7246: state: open
title: Recommendations for dealing with configuration for code ('build_requires')
body: I have several projects (e.g. projectA and projectB) which depend on a common code base (supplierCode).
This code base is configured by compiling with headers generated from config files (supplierCodeCfgA and supplierCodeCfgB).

What would be the preferred way to set these config packages as a `build_requires`?  
From what I can tell I have two options:

1. Use a dedicated `profile`:

    _.conan/profiles/supplierCodeCfgA_
```
[build_requires]
supplierCodeCfgA/[*]@user/channel
```
2. Use `options`:

   _conanfile.py_
```
name = supplierCode
options = {"config": ["A", "B"]}
   
def requirements(self):
    self.requires("supplierCodeCfg%s/[*]@user/channel" % self.options.config)
```

My concern with Option 1 is that since `build_requires` alone does not affect the `package_id`, supplierCode compiled with either of the configurations will share the same package reference and then overwrite each other on Artifactory.  But it also doesn't feel right to add it as an ordinary requirement.

Are there any advantages/disadvantages to either of these approaches that I should know about?  Or is there another option?

I'd be very grateful if you could give some feedback.
user: GordonJess
issue_7244: state: open
title: [question] Link Time Optimization
body: LTO is brought up in #2476. Is there any more guidance to give in 2 years that have passed with respect to lto? This is not an urgent matter for me, but my company does have computing libraries that we distribute internally with Conan and it would be interesting to investigate whether building them with lto in an lto enabled project gives measurable benefits.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Tridacnid
issue_7240: state: open
title: [feature] Add executables to cpp_info model
body: Coming from https://github.com/conan-io/conan-center-index/pull/1717#discussion_r441501353
Related to #5090

In order to allow a better integration with executables, cpp_info could model those with an extra field similar to the current `cpp_info.libs`. Something similar to the proposal at #5090 with `cpp_info.exes = []` that will allow adding `<NAME>_EXECUTABLE` being `<NAME>` the name of the component or similar

cc/ @madebr

user: danimtb
issue_7226: state: open
title: [feature] Toolchain lacks environment variables
body: The toolchain feature looks awesome and I was going to suggest it instead of `conan build --configure`, but it fails with 2 use-cases:
1. Profile defines compiler (e.g. `CXX=gcc-9`) and flags (`CXXFLAGS`) in environment variables. Those won't be used of CMake just runs.
2. If CMake itself is a Conan package, it won't be found.

Of course, one can use virtual(run)env generator in addition, but then configuring project will require 2 extra commands instead of one.

Besides, the command line for CMake is still complicated (toolchain, generator, path to sources - they are all known to Conan, why repeat).

I'm not sure if it's feasible to define environment variable (or compiler and flags) in the toolchain file as it addresses only the first use-case.

Another idea is to either generate an alias in virtual(run)env generator(s) (like `configure_cmake`) or conan subcommand (was also discussed iirc).

My goal is to give dead simple instructions to ones who don't want to master all details of build systems (like 90% of developers?). And avoid repetition.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: ytimenkov
issue_7212: state: open
title: [feature] Add --no-binary-packages option to conan install
body: <!-- What is your suggestion? Please be as specific as possible! -->
There may be a better place to put this, but sometimes you want all packages to be built locally. For example on linux, maybe you don't want to wait to get glibc linker errors...just force local building. You can use --build...but then if you need to call it again later, it rebuilds everything not just the new stuff. I could also imagine specifying this on a package by package basis, but the global functionality would be good to have too.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: rconde01
issue_7206: state: open
title: [workspaces] update documentation
body: My workspaces setup: https://github.com/blockspacer/flextool#for-contibutors-conan-workspace

First of all: workspaces are great! But documentation lacks some important usage instructions.

Some things that i had to change in CmakeLists.txt to make workspaces work in not-trivial setup:

* no relative `include()`. workspaces use `add_subdirectory`, so collision in names of `.cmake` files caused bugs.
* all cmake `option` names must be unique. Same reason as in `include()` section. Prefixed each `option` or `CACHE` variable name with project name.
* Need to detect somehow if conan package uses `workspaces` or installed from conan cache (as usual). Added `set(packageName_LOCAL_BUILD TRUE CACHE BOOL "packageName_LOCAL_BUILD")` in `CMakeLists.txt` created for `workspace`. **<-- can be automated, just add cmake flag if package is part of workspace**
* Not obvious that package to choose as `root`
* `CONAN_PACKAGENAME_ROOT` do not work, used `get_target_property` and hacks similar to:
```cmake
set(flexlib_LIB CONAN_PKG::flexlib)
# conan package has '/include' dir
set(flexlib_HEADER_DIR
  ${CONAN_FLEXLIB_ROOT}/include
)
if(flexlib_LOCAL_BUILD)
  # name of created target
  set(flexlib_LIB flexlib)
  # no '/include' dir on local build
  set(flexlib_HEADER_DIR
    ${CONAN_FLEXLIB_ROOT}/include
  )
else()
  # uses Config.cmake or a -config.cmake file
  # see https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/How-to-create-a-ProjectConfig.cmake-file
  # BELOW MUST BE EQUAL TO find_package(... CONFIG REQUIRED)
  # NOTE: find_package(CONFIG) not supported with EMSCRIPTEN, so use include()
  include(${CMAKE_CURRENT_LIST_DIR}/cmake/flexlib-config.cmake)
endif(flexlib_LOCAL_BUILD)
message(STATUS "flexlib_HEADER_DIR=${flexlib_HEADER_DIR}")
``` 
<- **is invalid `CONAN_PACKAGENAME_ROOT` expected?**
* Had to manually set `add_dependencies` in `CMakeLists.txt` created for `workspace`. **<-- can be automated based on dependency graph (build each package in strict order, so deps will not compile before root)**
* Prefixed each package option to avoid collisions `-o packageName:shared=True`
* Added 
```py
        # Local build
        # see https://docs.conan.io/en/latest/developing_packages/editable_packages.html
        if not self.in_local_cache:
            self.copy("conanfile.py", dst=".", keep_path=False)
```
* `add_subdirectory` changed `CMAKE_SOURCE_DIR`, `CMAKE_BINARY_DIR`. Fixed by  `CMAKE_CURRENT_SOURCE_DIR`, `CMAKE_CURRENT_BINARY_DIR`
user: blockspacer
issue_7195: state: open
title: [feature] More precise error message upon artifactory access failure
body: When trying to retrieve conan requirements from the artifactory server without the correct user access rights, it fails and the following error message is provided:

`conanreq_anon/1.0.0@anon/stable: Not found in local cache, looking in remotes...
conanreq_anon/1.0.0@anon/stable: Trying with 'conan-center'...`
`ERROR: Error loading conanfile at 'W:\repo\conan\conanfile-pc.py': Unable to find 'conanreq_anon/1.0.0@anon/stable' in remotes
`

When using the JFrog Web UI and trying to access the artifact server from a user with insufficient access rights, the user is prompted with a message indicating the insufficient access rights.

### **Feature Proposal**
Could this root cause, access rights failure, also be included/clarified in the above error message? Would make the issue more clear. The issue was solved after assigning the user to the correct access group.

### **Environment Details**
- Operating System: Windows 10
- Conan version: 1.25.2
- Python version: Python 3.8.1
- Active Directory uses Lightweight Directory Access Protocol (LDAP)
user: antonrigner
issue_7192: state: open
title: [feature] Build fails with CMake privately linking to a library with transitive dependencies
body: This falls somewhere between a bug, a feature request, and a comment for the various issues about RPATH handling.  It's also troublesome in CMake alone, where their [#19556](https://gitlab.kitware.com/cmake/cmake/-/issues/19556) and [#19707](https://gitlab.kitware.com/cmake/cmake/-/issues/19707) are similar (though involving shared and static libraries, respectively, not imported ones).

When using the cmake generator and linking an application that privately consumes a library in its build path, the library's transitive dependencies cannot be found at link time (but it's okay at runtime).  The minimal chain (where `app` and `C` are in the same project, and `B` and `A` are independent conan projects with empty `RPATH`s) is:

```
app  --(any link)-->  libraryC  --(PRIVATE link)-->  libraryB  --(any link)-->  libraryA
```

In the build tree, the app should be able to link and run.  In the install tree, `libraryB` and `libraryA` needs to be in a known location, but that's a different story.


### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 16.04.6 LTS
  * Compiler+version: gcc 5.4.0 / cmake 3.17.3
  * Conan version: 1.26.0
  * Python version: Python 3.5.2


### Steps to reproduce

[private-transitive-issue.tar.gz](https://github.com/conan-io/conan/files/4773393/private-transitive-issue.tar.gz) contains a small example.  Untar and run `./test.sh`.

This `conan create`s `proj_A` (`libprojA`), `proj_B` (`libprojB`), and `proj_C` (`libprojC` and `app`), where each calls a function in the one before it (`app:main` -> `libprojC:hello_C` -> `libprojB:hello_B` -> `libprojA:hello_A`).  It will fail during the linking of the app.  All libraries are privately linked from CMake's perspective.

```
[100%] Linking CXX executable bin/app
/usr/bin/ld: warning: libproj_A.so, needed by //home/rdesmond/.conan/data/proj_B/0.1/test/test/package/45b5368b05e5bb05d84f1dd43b93bf7b9dd52802/lib/libproj_B.so, not found (try using -rpath or -rpath-link)
//home/rdesmond/.conan/data/proj_B/0.1/test/test/package/45b5368b05e5bb05d84f1dd43b93bf7b9dd52802/lib/libproj_B.so: undefined reference to `hello_A()'
collect2: error: ld returned 1 exit status
```

If you build it with workaround 2 below, it will run in the build tree, because the `RPATH` of `libprojC` will include the paths to `libprojA` and `libprojB`.

### Workarounds
 1. Link `libprojC` to `libprojB` publicly (switch the commented line in "C/src/CMakelists.txt" from lines 9 to 8).
 2. Instruct gcc's linker to ignore the unresolved symbols with `-Wl,--unresolved-symbols=ignore-in-shared-libs` (uncomment "C/src/CMakelists.txt" line 13)
user: rddesmond
issue_7189: state: open
title: Problem with conan create command
body: Hi.

I have a problem executing the “conan create” command. I don't know where to address this question/problem but the problem is as below.

Attached a zip with a simple conan and build environment. 
[conanTest.zip](https://github.com/conan-io/conan/files/4769095/conanTest.zip)

**When doing “conan install” and after that a “conan build” works as expected.**


POstman@LANLTOFF4621 MINGW64 /c/conanTest
$ conan install . name/version@author/channel
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=12
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

conanfile.py (name/version@author/channel): Installing package
Requirements
Packages

Installing (downloading, building) binaries...
conanfile.py (name/version@author/channel): Generator txt created conanbuildinfo.txt
conanfile.py (name/version@author/channel): Generated conaninfo.txt
conanfile.py (name/version@author/channel): Generated graphinfo

POstman@LANLTOFF4621 MINGW64 /c/conanTest
$ conan build .
Using lockfile: 'C:\conanTest/conan.lock'
Using cached profile from lockfile
conanfile.py (name/version@author/channel): Calling build()

C:\conanTest>echo "Build"
"Build"


**[but when doing the same thing with “conan create” I got the following errors. Seems that conan switched directory and cannot find my “build.bat” file. What is the problem?](url)**

POstman@LANLTOFF4621 MINGW64 /c/conanTest
$ conan create . name/version@author/channel
Exporting package recipe
name/version@author/channel: A new conanfile.py version was exported
name/version@author/channel: Folder: C:\Users\POstman\.conan\data\name\version\author\channel\export
name/version@author/channel: Exported revision: 5ebab42c5561a0bcee8006613d512a46
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=12
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

name/version@author/channel: Forced build from source
Installing package: name/version@author/channel
Requirements
    name/version@author/channel from local cache - Cache
Packages
    name/version@author/channel:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Build

Installing (downloading, building) binaries...
name/version@author/channel: Configuring sources in C:\.conan\2fa4ff\1
name/version@author/channel: Copying sources to build folder
name/version@author/channel: Building your package in C:\.conan\c45a74\1
name/version@author/channel: Generator txt created conanbuildinfo.txt
name/version@author/channel: Calling build()
'build' is not recognized as an internal or external command,
operable program or batch file.
name/version@author/channel:
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'url'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'license'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'description'. It is recommended to add it as attribute
name/version@author/channel: ERROR: Package '5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9' build failed
name/version@author/channel: WARN: Build folder C:\.conan\c45a74\1
ERROR: name/version@author/channel: Error in build() method, line 24
        self.run("build")
        ConanException: Error 1 while executing build

BR
Patrik

user: paostman
issue_7188: state: open
title: [question] Date of conan_package.tgz contents 
body: I've noticed that all files within conan_package.tgz have their date set to Dec 31 1969. Is that by design?
user: w3sip
issue_7185: state: open
title: [question] Why are build requirements handled different when using --profile:host/profile:build and just --profile
body: I have a recipe _B_ that uses recipe _A_ as build requirement. 

Package _A_ exports a CMake module file _AMacros.cmake_ and _package_info()_ exports the CMake Module Path via
```self.cpp_info.builddirs = ["tools/CMake"]```

Usage in recipe _B_:
```
        ...
        build_requires = "A/x.y.z"
        ...
        def build(self):
            cmake = CMake(self)
            cmake.configure()
            cmake.build()
```

Now there is a difference if I create my package with `--profile mypropfile` or with `--profile:host myprofile --profile:build myprofile`.

In the 1st case (`--profile myprofile`) everything is good, the _CMakeLists.txt_ from package _A_ can successfully include _AMacros.cmake_.

In the 2nd case, including _AMacros.cmake_ fails as the CMAKE_MODULE_PATH is not set from build requirement _A_.

I do not understand why the behavior is different. IMHO it should do the same. Am I missing something?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: thkowa
issue_7184: state: open
title: [bug] N build_type -> 1 package cannot depends on package relying on build_type themselve 
body: Hi,

When a package C depends on a package S, and both are build in a _N build type-> 1 package_ mode:

- the _create_ command for the package C will not install the multiple build type necessary of S to compile C. It will only install the default build_type or the one specified with _-s build_type_. 
- And according to the question https://github.com/conan-io/conan/issues/5341, if the package S is not a _N build type-> 1 package_, it will also only download the package S with the default build_type or the one specified with _-s build_type_.

I am missing something or Conan is lacking a mechanism to specify which build type of S the package C will really need ?

Simon
user: Siron777
issue_7181: state: open
title: [bug] Interrupted install leaves locks in bad state
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

I am running Conan in a docker container, and while a package is installing, if I `docker stop` the container that Conan is running in, then try running the Conan container again, I get the

```
<name>/<version>@<channel> is locked by another concurrent conan process, wait...

If not the case, quit, and do 'conan remove <name>/<version>@<channel> -f
```

Even running `conan remove --locks` directly before running the command doesn't help. I have to force remove the package before it starts working again.

Continuation of #2071, since that issue was closed.

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 20.04
  * Conan version: 1.25.2
  * Python version: Python 3.5
user: cguldner
issue_7175: state: open
title: [feature] Consider using isystem for dependency header via qmake
body: I would like to have the same feature described here https://github.com/conan-io/conan/issues/2629 as well for the Qmake generator.

Unfortunately Qmake does not come with a nice build system variable to achieve this as Cmake does. But instead it has to be done via the `QMAKE_CXXFLAGS` variable.

In order to test if this would work in any way I locally modified the generated conanbuildinfo.pri file by replacing the lines
```
QMAKE_DEFAULT_INCDIRS += $$CONAN_INCLUDEPATH_DEBUG
```

with 
```
QMAKE_CXXFLAGS +=  $$join(CONAN_INCLUDEPATH, " -isystem ", "-isystem ")
```

The Qmake generator could use the already existing flag `CONAN_SYSTEM_INCLUDES` to determine if this feature should be used or not. Thus the generator would be nicely in sync with the Cmake generator.

Proposed hack (generators/qmake.py Line 106)
```
if(CONAN_SYSTEM_INCLUDES)
     output = str.replace(output,"QMAKE_DEFAULT_INCDIRS += $$CONAN_INCLUDEPATH_DEBUG",QMAKE_CXXFLAGS +=  $$join(CONAN_INCLUDEPATH, " -isystem ", "-isystem ") )
```

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: KrFe
labels: component: Build: Build helpers, build systems..
issue_7173: state: open
title: [feature] New generator which sources all virtualenv's
body: I would like to have a generator which sources under the hood all virtualev's, at least `activate.sh` and `activate_run.sh`

So I do not have to do:
```
source activate.sh
source activate_run.sh
```

I found this guide here: https://docs.conan.io/en/latest/howtos/custom_generators.html
However, I would like to avoid creating the virtualenv generators again. DRY.
So I need to derive from the existing ones or invoke them.

Is it possible that someone creates such a generator? Or give me some tip how to write it.


- [ x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: derived-coder
issue_7165: state: open
title: [feature] Environment variables for download_cache path in conan.conf
body: In case the download cache folder is not located in the same path on different CI agents (e.g. Windows vs. Linux) there should be a way to maintain a common `conan.conf` by using environment variables (e.g. `$HOME`) to specify parts of the `download_cache` path or fully override it (`CONAN_DOWNLOAD_CACHE`).

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: petermbauer
issue_7162: state: open
title: [feature] Dev tool path in Visual Studio
body: I need to use a dev tool from a conan conan package (namely, Google protobuf compiler) in a Visual Studio project. I was able to generate necessary property pages using `visual_studio_multi` generator but now hit a problem - how to inform Visual Studio of `protoc` executable location? Conan property pages modify debug environment only
```
  <PropertyGroup>
    <LocalDebuggerEnvironment>PATH=%PATH%;D:/.conan\bfef1e\1\bin;</LocalDebuggerEnvironment>
    <DebuggerFlavor>WindowsLocalDebugger</DebuggerFlavor>
  </PropertyGroup>
```
 so simple `protoc ...` in a custom build rule does not work. Seeing
```
  <PropertyGroup Label="Conan-RootDirs">
    <Conan-protobuf-Root>D:/.conan\2c89e3\1</Conan-protobuf-Root>
    <Conan-protoc_installer-Root>D:/.conan\bfef1e\1</Conan-protoc_installer-Root>
  </PropertyGroup>
```
I tried `$(Conan-protoc_installer-Root)\bin\protoc ...` but it does not work also, `$(Conan-protoc_installer-Root)` is empty.  I must be missing something?
user: db4
issue_7158: state: open
title: [workspaces] initial feedback / desired workflow
body: I've just started messing around with the `workspaces` feature.

I want to use workspaces to work on a full project (root + dependencies such as libraries, configuration, build tools, etc.) without having to always build and export to local cache - pretty much the use case stated in the docs.

So far I've found them to be a bit of a hassle to set up for sharing with other developers, particularly the need to separately check out each package and then map them to package references.  Conan can already knows what packages I need and where to find the sources of the dependencies - why can't this be done for me?  In fact, I feel like all the information needed to create workspace and layout files is already available from the root conanfile.py.

Just my initial feedback, but for me the ideal flow would be something like:

  - tell conan i want to edit all packages related to a consumer project (e.g.  `conan install . --create-workspace`).  this should also accept lockfiles to be able to investigate/patch bugs in previous versions.
  - conan checks out entire dependency graph (inc. `py_requires`)
  - edit packages as needed
  - tell conan to build the consumer project using the regular conan commands (with perhaps something like `--use-workspace` to indicate i want to take the local packages as opposed to any already in local cache), rebuilding all modified dependencies as needed
  - i can then commit and push the changes i made to my packages as needed
user: GordonJess
issue_7156: state: open
title: [bug] incorrect architecture for iOS (CMake) 
body: from https://github.com/conan-io/conan-center-index/issues/1806
given the profile:
```
Configuration for profile ios_armv7:

[settings]
os=iOS
os_build=Macos
arch=armv7
arch_build=x86_64
compiler=apple-clang
compiler.version=11.0
compiler.libcxx=libc++
build_type=Release
os.version=7.0
[options]
[build_requires]
[env]
```
and building the sqlite3 as:
```
conan create . sqlite3/3.29.0@ -pr ios_armv7 -o sqlite3:build_executable=False
```
the resulting library has incorrect architecture:
```
lipo -info /Users/sse4/.conan/data/sqlite3/3.29.0/_/_/package/a281bf9414dc8d2cef9c827e2aa0d98a10930163/lib/libsqlite3.a
Non-fat file: /Users/sse4/.conan/data/sqlite3/3.29.0/_/_/package/a281bf9414dc8d2cef9c827e2aa0d98a10930163/lib/libsqlite3.a is architecture: x86_64
```
(notice **x86_64**)
expected output:
```
lipo -info /Users/sse4/.conan/data/sqlite3/3.29.0/_/_/package/a281bf9414dc8d2cef9c827e2aa0d98a10930163/lib/libsqlite3.a
Non-fat file: /Users/sse4/.conan/data/sqlite3/3.29.0/_/_/package/a281bf9414dc8d2cef9c827e2aa0d98a10930163/lib/libsqlite3.a is architecture: armv7
```
the same applies to all CMake-based projects, e.g. BZip2 has the same problem.

<!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: macOS 10.15
  * Compiler+version: Apple Clang 11.0
  * Conan version: 1.27.0
  * Python version: 2.7.16

### Steps to reproduce (Include if Applicable)


### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SSE4
issue_7147: state: open
title: [bug] Conan can't find cmake to build sdl2_image on mac os x 10.14.6
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Mac os x 10.14.6
  * Compiler+version: Apple LLVM version 10.0.1 (clang-1001.0.46.4)
  * Conan version: 1.25.2
  * Python version: 3.8

### Steps to reproduce (Include if Applicable)
- cmake 3.17.3 and conan have installed using brew
- Used https://github.com/conan-io/cmake-conan  wrapper
- conan_cmake_run(
  REQUIRES
  sdl2_image/2.0.5@bincrafters/stable
  OPTIONS
  sdl2_image:tif=False
  BASIC_SETUP
  CMAKE_TARGETS
  BUILD
  missing)

- after conan downloaded all dependencies it can't find cmake for build the library with errors:

sdl2_image/2.0.5@bincrafters/stable: Calling build()
/bin/sh: cmake: command not found 

ERROR: sdl2_image/2.0.5@bincrafters/stable: Error in build() method, line 105
	cmake.configure(build_dir='build')
	ConanException: Error 127 while executing cd 'build' && cmake -G "Unix Makefiles"

CMake Error at build/conan.cmake:402 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  build/conan.cmake:497 (conan_cmake_install)
  cmake/Conan.cmake:16 (conan_cmake_run)
  CMakeLists.txt:76 (run_conan)


### Logs (Executed commands with output) (Include/Attach if Applicable)
Also, attach full log
[build.log](https://github.com/conan-io/conan/files/4731457/build.log)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: Kintawesar
issue_7123: state: open
title: [question] Passing cmake variables from recipe consuming tool package
body: Hi guys,
I'm trying to provide a tool for our build system using conan.

In the recipe that builds that tool, I'm adding the binary to the PATH:
```
 def package_info(self):
        self.env_info.PATH.append(os.path.join(self.package_folder, "bin"))
        self.env_info.TOOL = os.path.normpath(os.path.join(self.package_folder, "bin", tool))
```
On my consuming app we have a very basic conanfile that looks like this:
```
class Conan(ConanFile):
   name = "App"
   version = "1.0.0"
   settings = "arch"
   generators = "cmake_find_package"

   def build_requirements(self):
        self.build_requires("tool/version")

   def equirements(self):
        self.requires("libA/version")
        self.requires("libB/version")

```
And we're running `conan_cmake_run` from our base `CMakeLists.txt.

I would need to run that tool from cmake, using `add_custom_command()`. Is there a way to create a cmake variable that points to the binary from within our consuming conanfile? To clarify what I need is access to self.env_info.TOOL from cmake. 

Because if I understand correctly, the variables that I set in env_info are only available inside source(), build(), package() and imports() in the consuming conanfile.

Thanks!
- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: ericriff
issue_7121: state: open
title: [question] usability of linux binaries on conan center
body: <!-- What is your question? Please be as specific as possible! -->
I was using the xerces/3.2.2 package from conan center on redhat 7 using devtoolset-8 and getting linker errors related to ABI/GLIBC etc. After I rebuilt the binaries locally, it worked. I understand the issue here...but i'm wondering at the conan center strategy. Are the usability of conan center linux binaries a dice roll? If so, is there any plan to handle this better? If not, is there a way to set a policy to always build locally for a given platform?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: rconde01
issue_7120: state: open
title: All information about 'build' and 'host' environment in the 'host' environment
body: Reality bites. We agree that packages should contain binaries only for one architecture, so the proposed model by Conan with the [_host_ and the _build_ contexts](https://docs.conan.io/en/latest/devtools/build_requires.html#build-and-host-contexts), theoretically, would be enough for every use case. 

![image](https://user-images.githubusercontent.com/1406456/83261757-28e15100-a1bc-11ea-89b7-288af0abe256.png)

But there are out there some packages like `flex` (https://github.com/westes/flex/issues/78) or build systems like Meson where there is a common practice: to build artifacts for the _build_ context before building the artifacts for the _host_ context (in the same project, one single Meson run). Usually, we refer to them as multi-stage, or they require some bootstrapping,...

One solution would be always to divide the package, but this is not always possible/desired (?). So I'm opening this issue to discuss about this topic. cc/ @thkowa @TheQwertiest @SSE4 

 ----

### Where are we now (only new model using two profiles):

 * During the `build()` method the environment is populated with the environment variables defined in the `profile:host`, **and** the environment variables coming from the _build_ context (those defined by the packages, and those needed for tools to run: PATH, DYLD_LIBRARY_PATH,...). But in the _host_ context you cannot reproduce the context you have during while building packages in the _build_ context, even though you have access to `settings_build`, you cannot access the environment that was defined in the `profile:build` or `environment:build`.

 * The helper `self.run("....", run_environment=True)` is noop when using two profiles.

I would say that this covers most of the cross-building scenarios out there...

----

### flex, cmake, gcc (?),... 

These packages have a first stage which is a native compilation and a second stage that compiles the final product. Current Conan model is valid for this scenario, although the implementation I can imagine is not as straightforward as I'd like it to be. 

For example, if **flex** requires `stage1flex` to run in the _build_ context and the `flex` is the final library itself (for the _host_ context) something like this would work:

(pseudocode)
```python

class Recipe:
    name = "flex"

    def build_requirements(self):
        # To cross-compile we need 'stage1flex' from the build context. This conditional is also needed to break the infinite loop
        if self.settings != self.settings_build:
            self.build_requires("flex")

    def build(self):
        # First stage can only be compiled in the "build" machine:
        if self.settings == self.settings_build:
            self.run("<compile stage1flex>")

        # In the build context `stage1flex` is available as we have just compile it in the previous line
        # In the host context, `stage1flex` is available via the build_requires (it is in the PATH)
        self.run("<compile flex using stage1flex>")

    def package_info():
        self.cpp_info.libs = ["flex"]

        # Next line will add to the PATH the generated 'stage1flex' (only if native build)
        if self.settings == self.settings_build:
            self.cpp_info.bindirs = ["bin"]
```

The problem here: depending on the context the package has generated only the library `flex` or the tool `stage1flex` as well. This circumstance has to be encoded into the package ID, so we would need an option just for this:

```python

class Recipe:

    options = {"stage1flex": [None, True, False]}
    default_options = {"stage1flex": None}

    def configure():
        # The 'stage1flex' can only be generated if native building
        assert not self.options.stage1flex or self.settings == self.settings_build
        if self.options.stage1flex is None:
            self.options.stage1flex = bool(self.settings == self.settings_build)

    def package_id(self):
        # If the user requests the package with the library only, we can fallback to the package that contains both
        if self.options.stage1flex == False:
            compatible_pkg = self.info.clone()
            compatible_pkg.options.stage1flex = True
            self.compatible_packages.append(compatible_pkg)
```

**One big advantage of this approach is that `stage1flex` is generated only once if several packages require this same tool**.

### Meson

The problem with Meson is with monolithic projects where you cannot choose to build only the _cross_ part, every execution needs to compile the native stage and then the _cross_ stage.

**Question**: Is this a requirement? Can we add an `if` into the Meson project definition to choose the part to build? It's Python, it should be possible.

If we can choose the stage to compile from the project, then the same approach I presented for the `flex` recipe should work for any Meson project too: first it will run the native compilation with all the needed settings, then it will run the cross-compilation with the tools from the first stage in the PATH.

If not, 
 * is this a common practice in Meson? Is it recommended? 
 * Does it make sense to be forced to compile both stages? 
 * How should I identify these packages? It has generated binaries for two contexts! Should I add information from the build context to the package generated for the _host_ context? **This is against Conan model!**
 * Can we imagine a workaround? Should Conan add support for these scenarios?

---

I have more questions than answers, and I would need to run some POCs to prove the pseudocode presented here and other alternatives. Any feedback and opinions are more than welcome. This is something to think about, the answer is far in the future.

Thanks!
user: jgsogo
issue_7119: state: open
title: [question] how to specify a custom generator?
body: <!-- What is your question? Please be as specific as possible! -->
The default ones are registered with short names. The custom one seems always use the class fullname. Should we let the custom one registered by the name member?
```
class ABCDGenerator(Generator):
    name = 'abcd'
```

Another question is: is it possible to use custom generator with conan command line `-g=`? It seems there is no way to require/import the generator at command line without the conanfile.txt

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: braindevices
issue_7117: state: open
title: [feature] "conan --build" cache
body: As conan does not handle glibc version dependencies in a principled manner (https://github.com/conan-io/conan/issues/3972), I would like to build all my dependencies from source. However, using `conan --build` will always rebuild all dependencies and resulting builds are not cached locally.

Is there any recommendation for achieving the desired caching behavior? (Ie never download binaries; re-use previously locally built binaries)
user: leezu
issue_7110: state: open
title: [question] why there is no requires field in cpp_info?
body: <!-- What is your question? Please be as specific as possible! -->
In pc file, we can define requires field. I want to put this in pc file generated by pkg-config generator. But there is no such field. The Requires field seems only get filled by the required conan package. So far the work around is to add them to libs. But why not give user freedom to add the Requires? Some of them might from system packages.
- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: braindevices
issue_7104: state: open
title: [bug] Deploy generator messes up when you have two levels of symlinks
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Linux
  * Compiler+version: n/a
  * Conan version: 1.25.2
  * Python version: 3.6.4

### Steps to reproduce (Include if Applicable)
Deploy a package where you have symlinks in two levels:
```
a->b
b->c
```

that broke because b was written before c was written and it tries to make a hash of it for the manifest:


### Logs (Executed commands with output) (Include/Attach if Applicable)

```
ERROR: Traceback (most recent call last):
  File "/Users/tobias/.conan_plex/lib/conan-1.25.2-102-darwin-py36.pyz/conans/client/generators/__init__.py", line 106, in write_generators
    content = generator.content
  File "/Users/tobias/.conan_plex/lib/conan-1.25.2-102-darwin-py36.pyz/conans/client/generators/deploy.py", line 56, in content
    return self.deploy_manifest_content(copied_files)
  File "/Users/tobias/.conan_plex/lib/conan-1.25.2-102-darwin-py36.pyz/conans/client/generators/deploy.py", line 22, in deploy_manifest_content
    file_dict[f] = md5sum(abs_path)
  File "/Users/tobias/.conan_plex/lib/conan-1.25.2-102-darwin-py36.pyz/conans/util/files.py", line 136, in md5sum
    return _generic_algorithm_sum(file_path, "md5")
  File "/Users/tobias/.conan_plex/lib/conan-1.25.2-102-darwin-py36.pyz/conans/util/files.py", line 149, in _generic_algorithm_sum
    with open(file_path, 'rb') as fh:
FileNotFoundError: [Errno 2] No such file or directory: '/Users/tobias/Code/clang-builder/plex-llvm-toolchain/SDKs/MacOSX.sdk/usr/lib/libkrb5.tbd'
```
user: tru
issue_7100: state: open
title: [question] Getting recipe revision (scm) & package_id in build()-function
body: I would like to put the "package_id" and the "recipe revision" into my application during build. 
Is it possible to pick the values of both during build()-function? 
The idea is to put the both values to CMake to generate there a version file, which includes the "version", "recipe revision" (git hash) and the "package_id" (to know exactly, which combination of libraries where used to build the package).

I looked also into the hook section, but was not sure, if this would be the right way ("pre_build"-hook).

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: climblinne
issue_7091: state: open
title: [feature request][xbuild] Access environment variables from --profile:build and --profile:host simultaneously
body: <!-- What is your question? Please be as specific as possible! -->

Blocks https://github.com/conan-io/conan/issues/7026

Feature description: 
Ability to access env variables from both --profile:build and --profile:host during `build`/`test`/etc steps.

Reasoning:
It seems that currently the only thing that is available from `--profile:build` during `build`/`test`/etc steps is `settings_build`, which contains only `[settings]` section of the profile. Env variables from host profile are appended to current environment and env vars from build profile are lost\not accessible.

To implement the full xbuild support for build systems, information about `build` compiler is required (which is usually passed via env variables in profile).

E.g. meson uses `--native-file` and `--cross-file` for xbuild configuration (which maps to conan's `--profile:build` and `--profile:host` respectively). The native file is used as a base profile during native compilation (when no cross file is supplied) and during xbuild it's used for things like code generation or compilation of build-time utils.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: TheQwertiest
issue_7089: state: open
title: [bug] apple-clang 9.1 is not c++17 compatible (but supports the flag)
body: See https://github.com/conan-io/conan/blob/7f1ab00a39607b596146a9534ca49975000e4d4d/conans/client/build/cppstd_flags.py#L116-L119

These lines say that apple-clang 9.1 supports the c++17 compiler flags.
But the compiler does not support the underlying c++17 standard

apple-clang 9.1 missing the `variant` header, which is part of c++17.

This made [this build](https://github.com/conan-io/conan-center-index/pull/1732#issuecomment-633770165) fail.
Increasing the minimum apple-clang version to 10, fixed this problem.

### Environment Details (include every applicable attribute)
  * Operating System+version: Macos
  * Compiler+version: apple-clang 9.1
  * Conan version: 1.25.2
  * Python version: 3.7.7


user: madebr
issue_7086: state: open
title: conan graph build-order and ConanInvalidConfiguration
body: > I asked another question in #6112 but then I realized _(many thanks @memsharded)_ that I actually only asked for it because `conan graph build-order` didn't work for me.
 
I tried `conan graph build-order` before and it really sounds like this is the command I want to use. Still I could not figure out how. 

What I was looking for when I began working with Conan was a command to get the total build order of all recipes that need to be rebuilt _(or be built at all because it does not yet exist)_. 

The problem was that I just have a bunch of recipes locally - but nothing more _(i..e clean docker container, no cache or shared data)_. 

But for `conan graph build-order` I need a lockfile, if I understand correctly. So I tried to iterate over all recipes to extract the package name and version using `conan inspect` to create a master `conanfile.txt`. Something like this: 
```
echo "[requires]" > conanfile.txt
for r in $(find . -mindepth 2 -maxdepth 2  -iname conanfile.py); do 
    name=$(echo $(conan inspect -a name $r) | cut -d ':' -f2 | xargs); 
    version=$(echo $(conan inspect -a version $r) | cut -d ':' -f2 | xargs); 
    echo "$name/$version" >> conanfile.txt
done
conan graph lock -u .
conan graph build-order --build=outdated --json build.json .
```
I think `conan graph` really could work for me. But some recipes raise an `ConanInvalidConfiguration`, i.e.:
```
def configure(self):
    if self.settings.os != "Windows":
        raise ConanInvalidConfiguration("%s is only supported on Windows" % self.name)
```

How can I still get a build order _(across all platforms)_?
user: sboehmann
issue_7081: state: open
title: [question] how to return the system requirements path?
body: <!-- What is your question? Please be as specific as possible! -->
The `_handle_system_requirements()` seems save returned value from `conanfile.system_requirements()` to `system_reqs/<hash>/system_reqs.txt`. I wonder what is this file are used for. In the document it never mentioned the `system_requirements()` need return value and what kind of value it should return.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: braindevices
issue_7071: state: open
title: [question] tools.replace_in_file does not work in package()
body: During `package()` I want to replace some string in the files in package folder. But when I do `tools.replace_in_file('bin/some.sh', '@somepath@', self.package_folder)` It always said cannot find target file. But if I use `os.path.join(self.package_folder, 'bin/some.sh')` it works. From the document it seems only modify the files in source folder. However, I did not find any code actually limit the `tools.replace_in_file` to only work in source folder. What did I miss here? Should we make the replace_in_file works with relative path in most of the scenarios: source, build, package, deploy? 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: braindevices
issue_7060: state: open
title: [question] Does Conan look for the latest RREV for the latest RREV for the current profile?
body: Background:
We are trying to use Conan to support multiple OSs. Previously, we found there we had conflicts when trying to host both CentOS and Ubuntu builds of common dependencies (like boost), so we added a profile which specifies `conan.settings.os.distro=centos_x_x` and `conan.settings.os.distro=ubuntu_x_x`.
This has enabled us to have multiple builds of the same RREV (we use SCM revision mode) that target different OS/Distros.

Now we are seeing issues one package has been built, say for Ubuntu, but the build for another OS, say CentOS is stll running. In this example:
 - If we do `conan install` on Ubuntu machine, it works as expected.
 - If we do `conan install` on CentOS machine, it fails when trying to get a revision.

It seems to be looking for the RREV for the newest build (Ubuntu), but as there is no CentOS build for that RREV yet it (rightly) falls.

My question is:
 - Is the above the expected behaviour - that Conan will try and get all builds from the latest RREV, even if there is no build for this RREV for the current OS/Profile?

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: timbrown5
issue_7043: state: open
title: [bug] Error while downloading/extracting files with download_cache enabled
body: conan randomly fails when download dependency (conan packages) if properties storage.download_cache enabled and general.parallel_download set to > 1

### Environment Details (include every applicable attribute)
  * Ubuntu 18.04 inside docker container
  * GCC 7.4
  * Conan version 1.24.0
  * Python 3.7.7

### Steps to reproduce (Include if Applicable)
1. multiply docker containers (ubuntu 18.04) running with same volume  ```/conan/download_cache/data``` mounted into each container
2. inside docker container: conan configured to use download_cache and parallel download enabled
```conan config set storage.download_cache="/conan/download_cache/data"```
```conan config set general.parallel_download=8```
3. inside docker container: run ```conan create ..``` , which starts downloading dependencies (10-20 conan packages) from Artifactory
4. periodically (1 out of 10 attempts) conan fails while downloading dependency, see logs below. After re-run ```conan create ..``` most luckily dependency successfully downloaded.
5. this error never happens if storage.download_cache not enabled!

### Logs (Executed commands with output) (Include/Attach if Applicable)
```
<CONAN PACKAGE NAME>: ERROR: Exception while getting package: <CONAN PACKAGE ID>
<CONAN PACKAGE NAME>: ERROR: Exception: <class 'conans.errors.ConanException'> Error while downloading/extracting files to <LOCAL PATH TO CONAN PACKAGE> 
Compressed file ended before the end-of-stream marker was reached
Folder removed

Traceback (most recent call last):

  File "/usr/local/lib/python3.7/dist-packages/conans/client/remote_manager.py", line 292, in uncompress_file
    tar_extract(file_handler, dest_folder)
  File "/usr/local/lib/python3.7/dist-packages/conans/util/files.py", line 358, in tar_extract
    the_tar.extractall(path=destination_dir, members=safemembers(the_tar))
  File "/usr/lib/python3.7/tarfile.py", line 2000, in extractall
    numeric_owner=numeric_owner)
  File "/usr/lib/python3.7/tarfile.py", line 2042, in extract
    numeric_owner=numeric_owner)
  File "/usr/lib/python3.7/tarfile.py", line 2112, in _extract_member
    self.makefile(tarinfo, targetpath)
  File "/usr/lib/python3.7/tarfile.py", line 2161, in makefile
    copyfileobj(source, target, tarinfo.size, ReadError, bufsize)
  File "/usr/lib/python3.7/tarfile.py", line 247, in copyfileobj
    buf = src.read(bufsize)
  File "/usr/lib/python3.7/gzip.py", line 287, in read
    return self._buffer.read(size)
  File "/usr/lib/python3.7/_compression.py", line 68, in readinto
    data = self.read(len(byte_view))
  File "/usr/lib/python3.7/gzip.py", line 493, in read
    raise EOFError("Compressed file ended before the "
EOFError: Compressed file ended before the end-of-stream marker was reached
```

user: vklindukh
issue_7034: state: open
title: [question] Is there any automatic way to obtain package_info?
body: When project automatically generated the pc files, in theory, one can use the info giving by pkg-config to automatically generate the cpp_info. currently I have to glob inside the package/pkgconfig directory to find the pc file list. Then loop through it to call the tools.PkgConfig() to obtain all info. I wonder is there any built-in tools can automatically generate this info?

So far, if I do not do this in package_info(), with cmake_find_package or cmake_paths generator, it gives me empty target, which has no library/flag at all.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: braindevices
issue_7027: state: open
title: [bug] PkgConfig generator is failing for QNX
body: My Problem is that for the generated PkgConfig files from conan do not work for QNX profile.

```
/lhome/user/tools/qnx/qnx700/host/linux/x86_64/usr/bin/aarch64-unknown-nto-qnx7.0.0-ld: cannot find -ldlt
```

The `-ldlt` cannot be found, because the path is not correctly provided.

### Environment Details (include every applicable attribute)
  * Operating System+version:Ubuntu 18.04
  * Compiler+version: qcc 5.4
  * Conan version: 1.25.0
  * Python version: 3.6.9

### Steps to reproduce (Include if Applicable)

This is my example cmake script:
```
find_package(PkgConfig)

pkg_check_modules(DltDaemon REQUIRED IMPORTED_TARGET automotive-dlt)

add_executable(example example.cpp)
target_link_libraries(example PkgConfig::DltDaemon)
```

This is a conan generated PkgConfig file with a profile for gcc 7.0, which will work!
```
prefix=/lhome/user/.conan/data2/dlt-daemon/2.18.1/company/stable/package/512d6cd809d2e8836e53318a8dc977b9d61e98f7
libdir=${prefix}/lib
includedir=${prefix}/include

Name: automotive-dlt
Description: GENIVI Diagnostic Log and Trace
Version: 2.18.1
Libs: -L${libdir} -ldlt  -lpthread  -Wl,-rpath="${libdir}"
Cflags: -I${includedir}
Requires: dbus-1
```

This is a PkgConfig file with a profile for qcc 5.4 (QNX)
```
prefix=/lhome/user/.conan/data2/dlt-daemon/2.18.1/company/stable/package/2d6a3cd5a258327478b206da119f3f11e2492dfc
libdir=${prefix}/lib
includedir=${prefix}/include

Name: automotive-dlt
Description: GENIVI Diagnostic Log and Trace
Version: 2.18.1
Libs: -L${libdir} -ldlt  -lsocket 
Cflags: -I${includedir}
Requires: dbus-1
```
The big difference between these two is Libs falgs: `-Wl,-rpath="${libdir}"`
this is atteched for normal gcc build

### Logs (Executed commands with output) (Include/Attach if Applicable)
the resulting link script used by CMake for gcc 7.0
```
/usr/bin/c++  -O3 -DNDEBUG  -rdynamic -Wl,-rpath=/lhome/user/.conan/data2/dlt-daemon/2.18.1/company/stable/package/
512d6cd809d2e8836e53318a8dc977b9d61e98f7/lib -Wl,-rpath=/lhome/user/.conan/data2/dbus/1.12.16/company/stable/package/
0d4e56cc1202812ba8997cd4cf8105d6b1efabf0/lib -Wl,-rpath=/lhome/user/.conan/data2/expat/2.2.9/company/stable/package/
d50a0d523d98c15bb147b18fa7d203887c38be8b/lib CMakeFiles/example.dir/example.cpp.o  -o bin/example  -Wl,-rpath,
/lhome/user/.conan/data2/dlt-daemon/2.18.1/company/stable/package/512d6cd809d2e8836e53318a8dc977b9d61e98f7/lib:/
lhome/user/.conan/data2/dbus/1.12.16/company/stable/package/0d4e56cc1202812ba8997cd4cf8105d6b1efabf0/lib /lhome/user/
.conan/data2/dlt-daemon/2.18.1/company/stable/package/512d6cd809d2e8836e53318a8dc977b9d61e98f7/lib/libdlt.so -lpthread 
/lhome/user/.conan/data2/dbus/1.12.16/company/stable/package/0d4e56cc1202812ba8997cd4cf8105d6b1efabf0/lib/libdbus-1.so 
-lpthread /lhome/user/.conan/data2/dbus/1.12.16/company/stable/package/0d4e56cc1202812ba8997cd4cf8105d6b1efabf0/lib/libdbus-1.so 
/lhome/user/.conan/data2/expat/2.2.9/company/stable/package/d50a0d523d98c15bb147b18fa7d203887c38be8b/lib/libexpat.a 
```

The link script used by CMake for qcc 5.4
```
/lhome/user/tools/qnx/qnx700/host/linux/x86_64/usr/bin/ntoaarch64-c++  -O3 -DNDEBUG   
CMakeFiles/example.dir/example.cpp.o 
 -o bin/example  -ldlt -lsocket -ldbus-1 -lsocket -ldbus-1 -lexpat 
```
user: derived-coder
issue_7016: state: open
title: [bug] build_requires version resolution does not have override
body: We follow semver for package versioning and for requires specify minor compatibility, in our requirements we have:
libA/**1.0.0+1**
in build_requires:
libB/1.0.0+1

And libB/1.0.0+1 requires a newer build of libA/**1.0.0+2**
I am getting an error asking to override libA because my conanfile and libB are conflicting!

I was investigating the order of calls and it seems like build_requires do not participate in graph resolution and gets added later on top of already built graph.
force_host_context does not affect the result - it only affects CMake generator paths.
separating build profile from host profile also makes no difference.
I also tried with older version of Conan 1.21.1 - same effect.

To make the above error go away I had to move libB from build_requires to requires (and set compatibility for it to be unrelated, so at least it does not participate in package id calculation), but it defeats the purpose - it exposes my test tools on my consumers and they have to download irrelevant stuff.

Is it possible to make requires serve as overrides for build_requires?

### Environment Details (include every applicable attribute)
  * Operating System+version: RHEL
  * Compiler+version: gcc 4.8.3
  * Conan version: 1.24.1
  * Python version: 3.7

user: barmaglot27
issue_7014: state: open
title: [bug] How to virtual run a profile?
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 18.04
  * Compiler+version: clang8.0
  * Conan version:1.25.0
  * Python version:3.6.9

### Steps to reproduce (Include if Applicable)

my profile
```
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=clang
compiler.version=8
compiler.libcxx=libstdc++11
build_type=Release
[options]
[build_requires]
[env]
CLANG_DIR=/lhome/user/Downloads/clang+llvm-8.0.1-x86_64-linux-gnu-ubuntu-14.04
PATH=[$CLANG_DIR/bin]
LD_LIBRARY_PATH=[$CLANG_DIR/lib]
CC=$CLANG_DIR/bin/clang
CXX=$CLANG_DIR/bin/clang++
LLVM_VERSION=8.0
CMAKE_C_COMPILER=$CLANG_DIR/bin/clang
CMAKE_CXX_COMPILER=$CLANG_DIR/clang++
```

### Logs (Executed commands with output) (Include/Attach if Applicable)
after generate a `virtualbuildenv` for my recipe and doing a `source activate_build.sh`
```
which clang
```
returns an error. Because it is not in my environment....

Please make it somehow possible that the profile can be sourced too.

user: derived-coder
issue_7013: state: open
title: [question] How to consume deployable package?
body: **How can a required deployable package be automatically deployed if specified as a direct requirement?**

- **Conan version: 1.25.0**

### Sample use case

Given two packages `deployable-package` and `deploy-consumer-package` as follows:
```
├── deployable-package
|   ├── conanfile.py
|   └── resources
|       └── foo.txt
└── deploy-consumer-package
    └── conanfile.py
```
Bare in mind, it's just an example to illustrate the issue.

#### `deployable-package`

```python
#!/usr/bin/env python3
# -*- coding: utf-8 -*-

from conans import ConanFile, tools

class DeployablePackage(ConanFile):
    name = "deployable-package"
    version = "2.0.0"
    description = """Just contains some files"""
    exports_sources = "resources/*"

    @property
    def default_user(self):
        return "developer"

    @property
    def default_channel(self):
        return "testing"

    @property
    def deploy_path (self):
        return "/tmp/some/path"

    def package_id(self):
        # This package will only contain some build-agnostic files
        self.info.settings.clear()
        self.info.options.clear()

    def package(self):
        self.copy("*", src="resources", dst="", keep_path=True)

    def deploy(self):
        # Verify that exists and create if it doesn't (automatically done by tools.mkdir())
        tools.mkdir(self.deploy_path)
        self.copy("*", src="", dst=self.deploy_path, keep_path=True)
```

#### `deploy-consumer-package`

```python
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from conans import ConanFile
from os import path

class DeployConsumerPackage(ConanFile):
    name = "deploy-consumer-package"
    version = "2.1.0"  # major defined by deployable-package
    description = """Something is built"""
    exports_sources = "*"

    @property
    def default_user(self):
        return "developer"

    @property
    def default_channel(self):
        return "testing"

    @property
    def build_assets(self):
        return "/tmp/some/path"

    def requirements(self):
        self.requires("deployable-package/{}.0.0@developer/testing".format(self.version.split(".")[0]))

    # NOT IDEAL AT ALL
    # def imports(self):
    #     self.copy("*", root_package="deployable-package", dst="", keep_path=True)

    def build(self):
        # Once this is executed I'm sure, my dependency is installed in the system
        self.run("ls -l {}".format(self.build_assets))
        self.run("cat {}".format(path.join(self.build_assets, "*.txt")))
```

I want to know how to install `deploy-consumer-package`, so that tranparently and automatically, `deployable-package` is not only downloaded, but (built if necessary and) stored in the local Conan cache and also most importantly **installed into the system** (calling its `deploy()` function) **before the `consumer-package` is even built**.

I've tried with: `conan install` (with and without the `-g deploy` generator):
```
$ conan install deploy-consumer-package -g deploy

Configuration:
[settings]
[options]
[build_requires]
[env]

conanfile.py (deploy-consumer-package/2.1.0): Installing package
Requirements
    deployable-package/2.0.0@developer/testing from local cache - Cache
Packages
    deployable-package/2.0.0@developer/testing:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache

Installing (downloading, building) binaries...
deployable-package/2.0.0@developer/testing: Already installed!
conanfile.py (deploy-consumer-package/2.1.0): Generator txt created conanbuildinfo.txt
conanfile.py (deploy-consumer-package/2.1.0): Generator deploy created deploy_manifest.txt
conanfile.py (deploy-consumer-package/2.1.0): Generated conaninfo.txt
conanfile.py (deploy-consumer-package/2.1.0): Generated graphinfo
# Deploy not actually performed ?!
```

### what am I missing?


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: saimusdev
issue_7012: state: open
title: [question] What is the current state of QNX and Conan?
body: I would like to know what is the current state of support for QNX platform.

At the moment I can compile something, but I don't see any mapping of the conan arch to the QNX target arch when making a verbose build (`-V` `gcc_ntoaarch64le` option which points to the target is missing) http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.utilities/topic/q/qcc.html

This is my profile
```
QNX_BASE=/lhome/user/tools/qnx/qnx700
QNX_CONFIGURATION=/lhome/user/.qnx

[settings]
os=Neutrino
os.version=7.0
arch=armv8
compiler=qcc
compiler.version=5.4
compiler.libcxx=cxx
[options]
[build_requires]
[env]
PATH=[$QNX_BASE/host/linux/x86_64/usr/bin,$QNX_CONFIGURATION/bin,$QNX_BASE/jre/bin]
LD_LIBRARY_PATH=[$QNX_BASE/host/linux/x86_64/usr/lib]
CC=$QNX_BASE/host/linux/x86_64/usr/bin/qcc
CXX=$QNX_BASE/host/linux/x86_64/usr/bin/q++
CMAKE_C_COMPILER=$QNX_BASE/host/linux/x86_64/usr/bin/qcc
CMAKE_CXX_COMPILER=$QNX_BASE/host/linux/x86_64/usr/bin/q++
QNX_HOST=$QNX_BASE/host/linux/x86_64
QNX_TARGET=$QNX_BASE/target/qnx7
MAKEFLAGS=-I$QNX_BASE/target/qnx7/usr/include
```

I do not source anything else. I am just compiling with this profile above.
I found following issue: https://github.com/bincrafters/community/issues/1041
with a big profile. but it didn't work either.

So my current problem is, that the binaries generated are not the for the target platform.
user: derived-coder
issue_7007: state: open
title: [feature] Allow regexes when patching files (tools.replace_regex_in_file)
body: Often, when packaging external software, patching is required.
Right now the main tools we have are:
- `tools.replace_in_file` (`tools.replace_path_in_file`, `tools.replace_prefix_in_pc_file`)
- `tools.save_append`
- `tools.patch`

Having the ability to use regex'es to patch sources would be nice.

Example usage:
https://github.com/conan-io/conan-center-index/pull/1607.

This contans a for loop with 2 replaces:
```python
for e in ["MDd", "MTd", "MD", "MT"]:
    tools.replace_in_file(filename, "/%s " % e, "/%s " % self.settings.compiler.runtime, strict=False)
    tools.replace_in_file(filename, "/%s\"" % e, "/%s\"" % self.settings.compiler.runtime, strict=False)
```

A regex can replace this with:

```python
tools.replace_regex_in_file(os.path.join(filename, "/M[TD]d?([\" ])", "/{}\\1".format(self.settings.compiler.runtime))
```
Notice also how the `strict=False` can be removed which gives greater confidence that a patch is working. 

example implementation (not tested):

```python
import re


def replace_regex_in_file(file_path, pattern, repl, flags=None, strict=True, output=None, encoding=None):
    output = default_output(output, 'replace_regex_in_file')

    encoding_in = encoding or "auto"
    encoding_out = encoding or "utf-8"
    content = load(file_path, encoding=encoding_in)

    content, nb = re.subn(pattern, repl, content, flags=flags)
    if nb == 0:
        _manage_text_not_found(pattern, file_path, strict, 'replace_regex_in_file', output=output)

    content = content.encode(encoding_out)
    save(file_path, content, only_if_modified=False, encoding=encoding_out)
```



- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: madebr
issue_6985: state: open
title: Looking for recommendation on project directory structure
body: In general we try to layout our CMake projects alog the lines of : https://cliutils.gitlab.io/modern-cmake/chapters/basics/structure.html

So we have dir structure that look like:
- CMakeLists.txt
- docs
- src
  - CMakeLists.txt
  - fred.cpp
  - sue.f90    (Yes we still use FORTRAN)
- test
  - CMakeLists.txt
  - gtest_main.cpp
  - my_test.cpp

I will likely be using VSCode and Vscode-cmake-tools for interacting with the projects (both win/*nix) ... and the final builds will happen using a Jenkins CI instance.

So the questions are:

1.  I have been using the cmake-conan tools, to embed everything into the CmakeLists.txt file. Is this still a good way, or should I use the conanfile.py approach.

2. Where does the insertion of conan belong? In the top level, the leaf level .... where should it go?

Thanks and regards...
user: ShamanTcler
issue_6977: state: open
title: [bug] Failed to run in parallel `conan info` + `conan export-pkg`.
body: ```py
# conanfile.py

from conans import ConanFile
from os.path import join
from time import sleep


class TestA(ConanFile):
    name = "TestA"
    version = "1.0.0"
    description = "TestA"
    settings = "os", "compiler", "build_type", "arch"

    def config_options(self):
        self.output.info("--- TestA: 01. config_options ---")
        super().config_options()

    def configure(self):
        self.output.info("--- TestA: 02. configure ---")
        super().configure()

    def requirements(self):
        self.output.info("--- TestA: 03. requirements ---")

    def package_id(self):
        self.output.info("--- TestA: 04. package_id ---")
        super().package_id()

    def build_requirements(self):
        self.output.info("--- TestA: 05. build_requirements ---")

    def build_id(self):
        self.output.info("--- TestA: 06. build_id ---")

    def system_requirements(self):
        self.output.info("--- TestA: 07. system_requirements ---")
        super().system_requirements()

    def source(self):
        self.output.info("--- TestA: 08. source ---")
        super().source()

    def imports(self):
        self.output.info("--- TestA: 09. imports ---")

    def build(self):
        self.output.info("--- TestA: 10. build ---")
        super().build()

    def package(self):
        self.output.info("--- TestA: 11. package ---")
        super().package()
        self.copy("*.a", src=".", dst="lib")
        with open(join(self.package_folder, "config.txt"), "wt") as fh:
            self.output.info("--- sleep(10)")
            sleep(10)
            fh.write("testA\n")

    def package_info(self):
        self.output.info("--- TestA: 12. package_info ---")
        super().package_info()
        self.cpp_info.libs = ["lib1", "lib2", "lib3"]
```

```bat
rem test.cmd

set CONAN_LOGGING_LEVEL=10
set CONAN_USER_HOME=%~dp0

cls

conan remove "test*" -f
conan remote add test https://google.com -f

start "info" cmd /k conan info TestA/1.0.0@test/develop

echo/
pushd testA
start "export-pkg" cmd /k conan export-pkg . test/develop
popd
```
 The output:  `conan info`
```
DEBUG :conan_api.py   [171]: INIT: Using config 'C:\Dev\Projects\conan-test\conan_export+info\.conan\conan.conf' [2020-05-08 01:18:43,835]
DEBUG :tracer.py      [156]: CONAN_API: info(remote_name=None,settings=None,options=None,env=None,profile_names=None,profile_build=ProfileData(profiles=None, settings=None, options=None, env=None),update=False,install_folder=None,build=None,lockfile=None) [2020-05-08 01:18:43,836]
DEBUG :profile_loader.py[113]: PROFILE LOAD: C:\Dev\Projects\conan-test\conan_export+info\.conan\profiles\default [2020-05-08 01:18:43,837]
INFO  :settings_preprocessor.py[57]: Setting 'compiler.runtime' not declared, automatically adjusted to 'MD' [2020-05-08 01:18:43,858]
TestA/1.0.0@test/develop: Not found in local cache, looking in remotes...
TestA/1.0.0@test/develop: Trying with 'conan-center'...
DEBUG :rest_client_common.py[156]: REST: ping: https://conan.bintray.com/v1/ping [2020-05-08 01:18:43,864]
DEBUG :rest_client.py [58]: REST: Cached capabilities for the remote: ['complex_search', 'checksum_deploy', 'revisions'] [2020-05-08 01:18:44,584]
DEBUG :rest_client_common.py[183]: REST: get: https://conan.bintray.com/v1/conans/TestA/1.0.0/test/develop/download_urls [2020-05-08 01:18:44,585]
DEBUG :rest_client_common.py[29]: REST ERROR: <class 'conans.errors.NotFoundException'> [2020-05-08 01:18:44,779]
TestA/1.0.0@test/develop: Trying with 'test'...
DEBUG :rest_client_common.py[156]: REST: ping: https://google.com/v1/ping [2020-05-08 01:18:44,781]
DEBUG :rest_client_common.py[29]: REST ERROR: <class 'conans.errors.NotFoundException'> [2020-05-08 01:18:44,903]
ERROR: Unable to find 'TestA/1.0.0@test/develop' in remotes
```
The output: `conan export-pkg`
```
DEBUG :conan_api.py   [171]: INIT: Using config 'C:\Dev\Projects\conan-test\conan_export+info\.conan\conan.conf' [2020-05-08 01:18:43,834]
DEBUG :tracer.py      [156]: CONAN_API: export_pkg(conanfile_path=.,name=None,version=None,source_folder=None,build_folder=None,package_folder=None,install_folder=None,profile_names=None,env=None,settings=None,options=None,profile_build=ProfileData(profiles=None, settings=None, options=None, env=None),force=False,user=test,channel=develop,lockfile=None,ignore_dirty=False) [2020-05-08 01:18:43,836]
DEBUG :profile_loader.py[113]: PROFILE LOAD: C:\Dev\Projects\conan-test\conan_export+info\.conan\profiles\default [2020-05-08 01:18:43,838]
INFO  :settings_preprocessor.py[57]: Setting 'compiler.runtime' not declared, automatically adjusted to 'MD' [2020-05-08 01:18:43,859]
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'url'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'license'. It is recommended to add it as attribute
DEBUG :export.py      [110]: EXPORT: C:\Dev\Projects\conan-test\conan_export+info\testA\conanfile.py [2020-05-08 01:18:43,864]
Exporting package recipe
TestA/1.0.0@test/develop: TestA/1.0.0@test/develop is locked by another concurrent conan process, wait...
TestA/1.0.0@test/develop: If not the case, quit, and do 'conan remove --locks'
Traceback (most recent call last):
  File "c:\dev\tools\python3\lib\site-packages\conans\client\command.py", line 2002, in run
    method(args[0][1:])
  File "c:\dev\tools\python3\lib\site-packages\conans\client\command.py", line 954, in export_pkg
    info = self._conan.export_pkg(conanfile_path=args.path,
  File "c:\dev\tools\python3\lib\site-packages\conans\client\conan_api.py", line 89, in wrapper
    return f(api, *args, **kwargs)
  File "c:\dev\tools\python3\lib\site-packages\conans\client\conan_api.py", line 419, in export_pkg
    new_ref = cmd_export(self.app, conanfile_path, name, version, user, channel, True,
  File "c:\dev\tools\python3\lib\site-packages\conans\client\cmd\export.py", line 130, in cmd_export
    shutil.copy2(conanfile_path, package_layout.conanfile())
  File "c:\dev\tools\python3\lib\shutil.py", line 426, in copy2
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "c:\dev\tools\python3\lib\shutil.py", line 259, in copyfile
    with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Dev\\Projects\\conan-test\\conan_export+info\\.conan\\data\\TestA\\1.0.0\\test\\develop\\export\\conanfile.py'

ERROR: [Errno 2] No such file or directory: 'C:\\Dev\\Projects\\conan-test\\conan_export+info\\.conan\\data\\TestA\\1.0.0\\test\\develop\\export\\conanfile.py'
```
user: DmitrySokolov
issue_6919: state: open
title: [question] Access build_requirements of dependencies via conanfile.py
body: Hello Conan Devs,

**Background**

We're currently using conan to package an SDK inside our company.
This SDK includes source code, libraries, and documentation for the "core" parts of our platform including drivers, kernel, etc.

We have a waterfall approach where this core SDK is consumed by higher level developers (e.g. RF stacks) who consume the core sdk and build their products on top of it.

Currently all the dependencies necessary to build this core SDK are defined in `build_requires` of the core sdk package.
The `build_requires` includes things like toolchains, configuration tools, as well as actual packaging tools for building the SDK such as doxygen to build documentation. Currently we keep these out of requirements to avoid the diamond dependency problem.

however, we want to have a "developer install" option that will pull in the toolchains and other requirements for building, but not those related to packaging such as doxygen. I feel this is similar to the discussion that is going on [here](https://github.com/conan-io/conan/issues/5610).

**Question**

In these questions, I will assume that we have a package called `RFStack` that depends on a package `CoreSDK`.

To achieve this, we have come up with a couple proposals/questions:

1. Is it possible to access `CoreSDK`'s `build_requirements` from `RFStack`'s  `conanfile.py`? The intent is peek inside the `build_requires` of the `CoreSDK` and install the toolchains needed if we're in developer mode.

1. Assuming the above, isn't possible, we're thinking of exporting toolchain information inside user_info, which we should be able to access from downstream packages such as `RFStack` via `deps_user_info`. Is this a good idea, is there a better way?

1. If none of the above work, we're thinking of running 
`conan inspect -a build_requires CoreSdk/ref@lib/channel` as a subprocess inside `RFStack`'s conanfile.py to grab these. This seems like a last resort.


Your inputs on the best approach will be much appreciated.
Thanks for making conan!
 

- [x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: seanmlyons22
issue_6913: state: open
title: Is there a way to fetch only CMake compatible packages from the conan-center?
body: I am trying to have a strong CMake + Conan integration and would only like the CMake compatible packages. I tried to look at the `conan search` command for some help but it doesn't really have any CMake specific commands. So can you help me here?
user: KunalSharmaa
issue_6897: state: open
title: conan.exe does not observe non_interactive configuration for lock issues
body: If I run the conan executable with an install command I still get a prompt when there is a lock issue.

I shouldn't because I have set the CONAN_NON_INTERACTIVE environment variable to 1 and added non_interactive = True to the conan.conf file under the [general] section.

This is a major issue on our build server because the prompt causes the job to hang and jam up the build queue until the timeout interval of 90 minutes is reached.  I think the conan.exe should always honor the configuration.  

A better design IMHO would be to have an argument that can be passed to the executable.  The current implementation assumes that I will always want it a certain way but using an arg allows me to make that decision when I am running the conan command.  I will put in a feature request for this.

### Environment:

Windows 10 Build 19041
Conan v1.24.0
Python v3.8.2

### Steps to reproduce:

Add CONAN_NON_INTERACTIVE to your environment and value to 1 and/or set non_interactive = True in conan.conf
Do something that creates a lock issue.
Run a conan install command (e.g. conan install ".\conanfile.txt" -s arch="x86" -s build_type="Release" --build=missing)
Observe that a prompt regarding the lock issue appears.


user: gprosch
issue_6890: state: open
title: [question] A different toolchain approach
body: Hi Conan team,

as you may know, we're primarily using `cmake_paths` generator and using it (for package development, not package creation) via `cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_paths.cmake`.

However, passing a toolchain file does have some disadvantages, mainly a toolchain file is only processes during the first CMake invokation.
This means, if you run again `conan install` (because you might have added a new dependency) and rerun CMake, the regenerated `conan_paths.cmake` file will have no affect on the build.
(Unless I delete and rebuild everything).

Also you either have to manually specify all other options you need or run `conan build -c` to configure a Visual Studio Solution. 

So I thought, maybe to take a different approach and to generate a CMakeLists.txt, that has all information (Paths, and options) and then adds the actual CMakeLists.txt of the project.

```cmake
cmake_minimum_required(VERSION 3.17)
project(conan_some_protobuf_project VERSION 1.0.0)

# specify CMAKE_MODULE_PATH / CMAKE_PREFIX_PATH 
set(CMAKE_MODULE_PATH "D:/data/cmake/3.16.3/user/stable/package/60b04a80ac4dd5c23f1acffacc679e9902e636e5/"
  "D:/data/protobuf/3.5.0/user/stable/package/b5194b4327faf44131d7e797b87b8b492f1aab33/"
  "D:/data/boost/1.71.0/user/stable/package/b5194b4327faf44131d7e797b87b8b492f1aab33/"
  "D:/data/gtest/1.8.1/user/stable/package/b5194b4327faf44131d7e797b87b8b492f1aab33/" 
  ${CMAKE_MODULE_PATH})
set(CMAKE_PREFIX_PATH "D:/data/cmake/3.16.3/user/stable/package/60b04a80ac4dd5c23f1acffacc679e9902e636e5/"
  "D:/data/protobuf/3.5.0/user/stable/package/b5194b4327faf44131d7e797b87b8b492f1aab33/"
  "D:/data/boost/1.71.0/user/stable/package/b5194b4327faf44131d7e797b87b8b492f1aab33/"
  "D:/data/gtest/1.8.1/user/stable/package/b5194b4327faf44131d7e797b87b8b492f1aab33/"
  ${CMAKE_PREFIX_PATH})

# specify all options set with cmake build helper.
set(protobuf_MODULE_COMPATIBLE ON CACHE STRING "" FORCE)
set(PROTOBUF_PLUGINS_BUILD_TESTS ON CACHE STRING "" FORCE)
set(CMAKE_INSTALL_PREFIX _install)

# Add the actual project file as subdirectory 
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/.. some_protobuf_project) 
```

So far this has been just a proof of concept, handwritten, but I guess more checks could be added (e.g. cmake errors if compiler / architecture missmatch).

Have you considered a toolchain approach like this?
The real benefit here, too, is that you have no modification to the original CMake files, but induce everything from the outside, through a generated CMakeLists.txt file.

user: KerstinKeller
issue_6887: state: open
title: [feature] allow editing build_requires by conan profile update
body: invoking:
`conan profile update build_requires.autoconf=x.y.z default`
results in:
`ERROR: Edit  the profile manually to change the build_requires`

Why I need this?
I just wanted to quickly change this from console because I know this particular project wont build on machine I am on, and to follow-in with your iwki guidance i dont want to put it into the conanfile.py.

I was forced to sed the profile.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: fulara
issue_6885: state: open
title: [Question] conan info for a specific package id
body: Hello, 

I have two packages with the same version, same options, same settings but different requirements.

output of conan search command
```
>conan search  my_package/1.0.0@walid/testing
Existing packages for recipe my_package/1.0.0@walid/testing:

    Package_ID: 2d49981400eb318185d516f42e43c993c066a3ed
        [options]
            shared: True
        [settings]
            arch: x86_64
            build_type: Release
            compiler: Visual Studio
            compiler.version: 14
            os: Windows
        [requires]
            zlib/1.2.11@walid/stable:4a139a8ef383e285d40e88301506605603e78c47
        Outdated from recipe: False

    Package_ID: c627d26513e4a9db441b6cffe3ecd67ac8401c01
        [options]
            shared: True
        [settings]
            arch: x86_64
            build_type: Release
            compiler: Visual Studio
            compiler.version: 14
            os: Windows
        [requires]
            zlib/1.2.11@walid/testing:4a139a8ef383e285d40e88301506605603e78c47
        Outdated from recipe: False
```

How can I inspect the package `2d49981400eb318185d516f42e43c993c066a3ed` using `conan info` ?  


user: boussaffawalid
issue_6875: state: open
title: Can't have spaces in VENV path on Linux
body: Conan VERSION **1.22.2**

I've discovered an issue in which some users have spaces in their venv path. When this happens you can activate the venv, but you can't issue any conan commands:
![image](https://user-images.githubusercontent.com/60359120/79610687-04775c80-80c7-11ea-8d18-2b8c49e84a27.png)
Furthermore, I also cannot directly call the conan executable (without using venv). I get the same error.

I also tested this on Windows, which didn't have an issue with spaces. 

I did some searching and didn't see any existing reports of this. 

Thanks!
user: carobins
issue_6870: state: open
title: [bug] conan upload should be a transaction
body: ### Environment Details (include every applicable attribute)
  * Conan version: 1.24.0
  * Python version: 3.7

### Steps to reproduce
Have project `bar` that depends on `foo`.
Have `self.requries("foo/[~=42]@user/channel")` in `bar/conanfile.py`.

`foo` has finished building on CI and CI is running `conan upload foo/42.9000@user/channel`. It has already uploaded the recipe itself, but not the packages.
At the same time, `bar` is building on CI. `conan install` tries to resolve dependencies and it sees that `foo/42.9000` is the latest version that matches `foo/[~=42]`. It tries to fetch the package for the specific profile and fails (because the package corresponding to that profile is not yet uploaded).

### Expected result
`conan install` will only try to install `foo/42.9000@user/channel` when `conan upload` has finished uploading all packages.
user: Paultergeist
issue_6865: state: open
title: [bug] graph generation fails when manipulating `cpp_info` from both `build_requirements` and `--profile:build` 
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 14.04 x86
  * Compiler+version: gcc4.9
  * Conan version: 1.24
  * Python version: 3.5

### Steps to reproduce (Include if Applicable)
1. Have a conan profile that manipulates a recipe's `cpp_info`
2. Have a recipe that has another project as it's `build_requirement` as it is [for this dependency on ](https://github.com/saterj/conan_codependent_lib/blob/master/conanfile.py) [this header-only project](https://github.com/saterj/header_only_conan)
3. attempt to create this new project with a `--profile:build` flag.  As with the [example's profile](https://github.com/saterj/conan_codependent_lib/tree/master/toolchain), I believe it has to be manipulating your `cpp_info`: `conan create 
4. The build should fail as your build graph doesn't have the generated dependencies (mine fails out because of the missing header)

### Logs (Executed commands with output) (Include/Attach if Applicable)
```conan create conan_codependent_lib Parts_Store/test --profile:build ECU400```
generated 
[test1.txt](https://github.com/conan-io/conan/files/4483611/test1.txt)

My profile is based on this:
```[settings]                     
os=Linux                       
os_target=Linux                
os_build=Linux                 
arch=x86                       
arch_target=armv7              
arch_build=armv7               
                               
[options]                      
[build_requires]               
*: ecu_sdk/2.7.2.220@SDKS/test
[env]                          
```

with that requires resolving to [this](https://github.com/saterj/conan_codependent_lib/blob/master/toolchain/conanfile.py)


<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: saterj
issue_6864: state: open
title: [bug] 'PermissionError: [WinError 32]' during parallel execution of 'conan export-pkg'
body: Conanfiles:
```python
# testA/conanfile.py

from conans import ConanFile
from os.path import join
from time import sleep

class TestA(ConanFile):
    name = "TestA"
    version = "1.0.0"
    description = "TestA"
    exports = "*.a"

    def package(self):
        super().package()
        self.copy("*.a", src=".", dst="lib")
        with open(join(self.package_folder, "config.txt"), "wt") as fh:
            sleep(10)
            fh.write("testA\n")

    def package_info(self):
        super().package_info()
        self.cpp_info.libs = ["lib1", "lib2", "lib3"]


# testB/conanfile.py

from conans import ConanFile
from time import sleep

class TestB(ConanFile):
    name = "TestB"
    version = "1.0.0"
    description = "TestB"
    exports = "*.a"

    requires = "TestA/1.0.0@test/develop"

    def configure(self):
        super().configure()
        sleep(5)

    def package(self):
        super().package()
        self.copy("*.a", src=".", dst="lib")

    def package_info(self):
        super().package_info()
        self.cpp_info.libs = ["lib4"]
```

create.cmd
```cmd
set CONAN_LOGGING_LEVEL=10

conan remove "test*" -f
conan export testA test/develop

echo/
pushd testA
start "A" cmd /k conan export-pkg . test/develop
popd

echo/
pushd testB
start "B" cmd /k conan export-pkg . test/develop
popd
```

Output of testA
```cmd
DEBUG :conan_api.py   [163]: INIT: Using config 'C:\Users\dmitry\.conan\conan.conf' [2020-04-15 23:43:55,615]
DEBUG :tracer.py      [156]: CONAN_API: export_pkg(conanfile_path=.,name=None,version=None,source_folder=None,build_folder=None,package_folder=None,install_folder=None,profile_names=None,env=None,settings=None,options=None,force=False,user=test,channel=develop,lockfile=None,ignore_dirty=False) [2020-04-15 23:43:55,617]
DEBUG :profile_loader.py[112]: PROFILE LOAD: C:\Users\dmitry\.conan\profiles\default [2020-04-15 23:43:55,618]
INFO  :settings_preprocessor.py[58]: Setting 'compiler.runtime' not declared, automatically adjusted to 'MD' [2020-04-15 23:43:55,639]
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'url'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'license'. It is recommended to add it as attribute
DEBUG :export.py      [105]: EXPORT: C:\Dev\Projects\tests\conan_export_pkg\testA\conanfile.py [2020-04-15 23:43:55,902]
Exporting package recipe
TestA/1.0.0@test/develop exports: Copied 3 '.a' files: liblib1.a, liblib2.a, liblib3.a
TestA/1.0.0@test/develop: The stored package has not changed
TestA/1.0.0@test/develop: Exported revision: 4dbefb4080a01fd913f3844b071ac62e
DEBUG :graph_builder.py[391]: GRAPH: new_node: TestA/1.0.0@test/develop [2020-04-15 23:43:55,922]
DEBUG :graph_builder.py[66]: GRAPH: Time to load deps 0.004001140594482422 [2020-04-15 23:43:55,922]
TestA/1.0.0@test/develop: Forced build from source
Packaging to 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
TestA/1.0.0@test/develop: Generating the package
TestA/1.0.0@test/develop: Package folder C:\Users\dmitry\.conan\data\TestA\1.0.0\test\develop\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
TestA/1.0.0@test/develop: Calling package()
TestA/1.0.0@test/develop: WARN: This conanfile has no package step
DEBUG :packager.py    [120]: PACKAGE: Creating config files to C:\Users\dmitry\.conan\data\TestA\1.0.0\test\develop\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 [2020-04-15 23:44:05,928]
TestA/1.0.0@test/develop package(): Packaged 1 '.txt' file: config.txt
TestA/1.0.0@test/develop package(): Packaged 3 '.a' files: liblib1.a, liblib2.a, liblib3.a
TestA/1.0.0@test/develop: Package '5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9' created
TestA/1.0.0@test/develop: Created package revision 9c1ad6891f2902de5e6eae0d6d39da9e
```

Output of testB:
```cmd
DEBUG :conan_api.py   [163]: INIT: Using config 'C:\Users\dmitry\.conan\conan.conf' [2020-04-15 23:43:55,615]
DEBUG :tracer.py      [156]: CONAN_API: export_pkg(conanfile_path=.,name=None,version=None,source_folder=None,build_folder=None,package_folder=None,install_folder=None,profile_names=None,env=None,settings=None,options=None,force=False,user=test,channel=develop,lockfile=None,ignore_dirty=False) [2020-04-15 23:43:55,617]
DEBUG :profile_loader.py[112]: PROFILE LOAD: C:\Users\dmitry\.conan\profiles\default [2020-04-15 23:43:55,618]
INFO  :settings_preprocessor.py[58]: Setting 'compiler.runtime' not declared, automatically adjusted to 'MD' [2020-04-15 23:43:55,638]
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'url'. It is recommended to add it as attribute
[HOOK - attribute_checker.py] pre_export(): WARN: Conanfile doesn't have 'license'. It is recommended to add it as attribute
DEBUG :export.py      [105]: EXPORT: C:\Dev\Projects\tests\conan_export_pkg\testB\conanfile.py [2020-04-15 23:43:55,902]
Exporting package recipe
TestB/1.0.0@test/develop exports: Copied 1 '.a' file: liblib4.a
TestB/1.0.0@test/develop: A new conanfile.py version was exported
TestB/1.0.0@test/develop: Folder: C:\Users\dmitry\.conan\data\TestB\1.0.0\test\develop\export
TestB/1.0.0@test/develop: Exported revision: 22339369af2e86a25c2495112798a60f
DEBUG :graph_builder.py[391]: GRAPH: new_node: TestB/1.0.0@test/develop [2020-04-15 23:43:55,916]
DEBUG :graph_builder.py[391]: GRAPH: new_node: TestA/1.0.0@test/develop [2020-04-15 23:44:00,921]
DEBUG :graph_builder.py[66]: GRAPH: Time to load deps 5.00782585144043 [2020-04-15 23:44:00,921]
TestA/1.0.0@test/develop: WARN: Package is corrupted, removing folder: C:\Users\dmitry\.conan\data\TestA\1.0.0\test\develop\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
Traceback (most recent call last):
  File "c:\dev\tools\python3\lib\shutil.py", line 606, in _rmtree_unsafe
    os.unlink(fullname)
PermissionError: [WinError 32] File busy: 'C:\\Users\\dmitry\\.conan\\data\\TestA\\1.0.0\\test\\develop\\package\\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\\config.txt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\dev\tools\python3\lib\site-packages\conans\client\command.py", line 1969, in run
    method(args[0][1:])
  File "c:\dev\tools\python3\lib\site-packages\conans\client\command.py", line 939, in export_pkg
    info = self._conan.export_pkg(conanfile_path=args.path,
  File "c:\dev\tools\python3\lib\site-packages\conans\client\conan_api.py", line 81, in wrapper
    return f(api, *args, **kwargs)
  File "c:\dev\tools\python3\lib\site-packages\conans\client\conan_api.py", line 417, in export_pkg
    export_pkg(self.app, recorder, new_ref, source_folder=source_folder,
  File "c:\dev\tools\python3\lib\site-packages\conans\client\cmd\export_pkg.py", line 21, in export_pkg
    deps_graph = graph_manager.load_graph(ref, None, graph_info=graph_info, build_mode=[ref.name],
  File "c:\dev\tools\python3\lib\site-packages\conans\client\graph\graph_manager.py", line 109, in load_graph
    return self._resolve_graph(root_node, graph_info, build_mode, check_updates, update, remotes,
  File "c:\dev\tools\python3\lib\site-packages\conans\client\graph\graph_manager.py", line 230, in _resolve_graph
    deps_graph = self._load_graph(root_node, check_updates, update,
  File "c:\dev\tools\python3\lib\site-packages\conans\client\graph\graph_manager.py", line 340, in _load_graph
    self._recurse_build_requires(graph, builder, check_updates, update, build_mode,
  File "c:\dev\tools\python3\lib\site-packages\conans\client\graph\graph_manager.py", line 277, in _recurse_build_requires
    self._binary_analyzer.evaluate_graph(graph, build_mode, update, remotes, nodes_subset, root)
  File "c:\dev\tools\python3\lib\site-packages\conans\client\graph\graph_binaries.py", line 321, in evaluate_graph
    self._evaluate_node(node, build_mode, update, remotes)
  File "c:\dev\tools\python3\lib\site-packages\conans\client\graph\graph_binaries.py", line 167, in _evaluate_node
    self._process_node(node, pref, build_mode, update, remotes)
  File "c:\dev\tools\python3\lib\site-packages\conans\client\graph\graph_binaries.py", line 209, in _process_node
    metadata = self._evaluate_clean_pkg_folder_dirty(node, package_layout, package_folder, pref)
  File "c:\dev\tools\python3\lib\site-packages\conans\client\graph\graph_binaries.py", line 61, in _evaluate_clean_pkg_folder_dirty
    rmdir(package_folder)  # Do not remove if it is EDITABLE
  File "c:\dev\tools\python3\lib\site-packages\conans\util\files.py", line 248, in rmdir
    shutil.rmtree(path, onerror=_change_permissions)
  File "c:\dev\tools\python3\lib\shutil.py", line 730, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "c:\dev\tools\python3\lib\shutil.py", line 608, in _rmtree_unsafe
    onerror(os.unlink, fullname, sys.exc_info())
  File "c:\dev\tools\python3\lib\site-packages\conans\util\files.py", line 243, in _change_permissions
    raise OSError("Cannot change permissions for {}! Exception info: {}".format(path, exc_info))
OSError: Cannot change permissions for C:\Users\dmitry\.conan\data\TestA\1.0.0\test\develop\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\config.txt! Exception info: (<class 'PermissionError'>, PermissionError(13, 'File busy'), <traceback object at 0x00000216A5A91280>)

ERROR: Cannot change permissions for C:\Users\dmitry\.conan\data\TestA\1.0.0\test\develop\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\config.txt! Exception info: (<class 'PermissionError'>, PermissionError(13, 'File busy'), <traceback object at 0x00000216A5A91280>)
```

Why the folder from the package `testA` is removing during exporting the package `testB`?
```
TestA/1.0.0@test/develop: WARN: Package is corrupted, removing folder: C:\Users\dmitry\.conan\data\TestA\1.0.0\test\develop\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
Traceback (most recent call last):
```

How to completely turn off manipulations with other (required) packages during the command `export-pkg`?
user: DmitrySokolov
issue_6857: state: open
title: [bug] Searching Artifactory remote by user/channel pattern not working
body: Hi!

I'm noticing a strange behavior when trying to search an Artifactory remote by user/channel, e.g. `conan search "*@user/stable" -r artifactory`. This works as expected when searching the local cache so it may be an Artifactory bug.

/cc @Minimonium (#conan slack)

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 18.04
  * Conan version: 1.24.0
  * Python version: 3.6.9
  * Artifactory version: 7.2.1

### Steps to reproduce (Include if Applicable)

`conan search "*@user/stable" -r artifactory`

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
$ conan search "*@user/stable" -r artifactory
There are no packages matching the '*@user/stable' pattern
```

user: aleksa2808
issue_6851: state: open
title: [question] are there any plans for standard lockfile storage through conan?
body: For packages which have version ranges in the recipe, to be able to reproduce or patch historic builds , the lockfile must be available from somewhere.

Are there any plans from conan's side for having built in support for this?  If so, how might this look...?

For example, 
- would conan commands to rebuild a specific version use an existing lockfile by default?
- would lockfiles sit alongside the package in the remote repo, or have their own 'generic' repo, such as the `artifactory-build-info` repo?
- is there a rough timeline? 

Thanks!
user: GordonJess
issue_6844: state: open
title: [workspaces] Decoupled Workspaces
body: We started using conan for our own libraries more than two years ago. From the very beginning, we have often been working on multiple libraries (packages) in one visual studio solution, long before conan editables and workspaces were introduced, just using cmake's add_subdirectory and find_package. Now I tested conan workspaces for the first time. They are promising and similar to our solution, but there are still important issues that discourage me from using them. I want to share my feelings here:

# Decoupling
My main concern is the coupling between conan and source. Strictly separating the library source from all the conan stuff makes things much easier to understand and more flexible. I am not only talking about the library structure, but also about how libraries are linked in a multi library workspace, see below.

# CMake Only
I created an example https://github.com/wpalfi/conan-decoupled-workspace based on https://github.com/conan-io/examples/tree/master/features/workspace/cmake for illustration.

![image](https://user-images.githubusercontent.com/18048248/79107213-4a08f200-7d74-11ea-8133-deb5d8da38e9.png)

Let's start with the simplest cmake based solution, no conan yet. We are using only the source directories `chat/src`, `hello/src`, `say/src`. Each of the three source directories has a conan free CMakeLists.txt. It follows modern cmake's best practices and is reduced to the minimal calls to `add_library`, `find_package` and `target_link_libraries`. That's extremely important to be able to consume the library later with `add_subdirectory` in a flexible way.

```cmake
project(Hello)
add_library(hello hello.cpp)
target_include_directories(hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})

add_library(hello::hello ALIAS hello)

if(NOT TARGET say::say)
    find_package(say REQUIRED)
endif()
target_link_libraries(hello say::say)
```

Each of the three libraries has a root `CMakeLists.txt` with the required `add_subdirectory` calls to build the respective library together with its dependencies.

```cmake
project(Hello)
add_subdirectory(../say/src say) # could use e.g. cache variable for path in real world
add_subdirectory(src)
```

So the layout of each library is

- hello
  CMakeLists.txt -> add subdirectories
  - src
    CMakeLists.txt -> add, find and link targets
    hello.cpp, hello.h

It is good practice in software development to always work on the smallest possible subset of code. Therefore, using the `src` folder should be preferred over taking the indirection via the outer folder.

# Adding Conan On Top

Now we want to create conan packages of the three libraries without touching the source directories. In real world, the conan stuff could also live in separate repositories.

![image](https://user-images.githubusercontent.com/18048248/79110030-d964d400-7d79-11ea-831a-8bf2d48ad00a.png)

We add conanfiles and modify the root CMakeLists.txt of each library to

```cmake
project(Hello)

option(HELLO_WITH_CONAN "Use conan" ON)
if(HELLO_WITH_CONAN)
    include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
    conan_basic_setup(TARGETS)
else()
    add_subdirectory(../say/src say) # could use e.g. cache variable for path in real world
endif()

add_subdirectory(src)
```

In order for this to work, we need to tell CMake how to find the packaged libraries. We dont want to touch the src folder, so we need a custom find module to switch between source target and conan target:

findhello.cmake:
```cmake
if(TARGET hello::hello)
    set(hello_FOUND TRUE)
elseif(TARGET CONAN_PKG::hello)
    # create hello::hello and link to conan packet
    add_library(hello::hello INTERFACE IMPORTED)
    target_link_libraries(hello::hello INTERFACE CONAN_PKG::hello)
    set(hello_FOUND TRUE)
else()
    set(hello_FOUND FALSE)
    if(hello_FIND_REQUIRED)
        message(FATAL_ERROR "Unable to find hello")
    endif()
endif()
```

So we created a way to switch between using conan (top row in drawing below) and building from source (bottom row), for each library separately.

![image](https://user-images.githubusercontent.com/18048248/79111834-93117400-7d7d-11ea-8e4f-befc68747c3c.png)

E.g. there are three different ways to build chat.
- build all
- say from conan
- say and hello from conan

For mixed conan/source builds, an adjusted conanfile is needed. E.g. to build `chat` together with `hello`, but with `say` from conan, we would need to remove the `hello` requirement and add a `say` requirement instead. (Usually it is easier to use a conanfile.txt here.)

Building `chat` together with `say` but with `hello` from conan is trickier. (There is no connection from `hello-conan` to `say` in the drawing.) Conan editables can be used but that's a poor solution with the say library actually existing twice with all possible problems:

![image](https://user-images.githubusercontent.com/18048248/79113681-b63e2280-7d81-11ea-973f-7a12f61bde04.png)

Remember that all this was without `workspaces` and (almost) without `editables`. The main issues of this approach are

1. Need to add some lines for `add_subdirectory` to root `CMakeLists.txt` for each library that may be edited (can be a lot in real world!).
2. Need to adjust conanfile (fix requirements)
3. No (good) way to build `say` without building `hello`

# Workspaces 

Conan workspaces already solve 1 and 2 :-). 

3 could also be solved if workspaces would link directly to the cmake targets created with `add_subdirectory`. Currently they are using editables with the problems mentioned above.

![image](https://user-images.githubusercontent.com/18048248/79114290-34e78f80-7d83-11ea-88d6-d3b7ba0f41b3.png)
left: CMake tree created by conan workspace, right: this is what we want

![image](https://user-images.githubusercontent.com/18048248/79115386-fdc6ad80-7d85-11ea-85ba-9784dca47728.png)

Even with issue 3 solved, workspaces are currently not flexible enough, even for this simple example. They are designed to just put multiple conan builds together. Each of these built libraries must have its own conanfile, build folder and `conan_basic_setup`. For the common use case of having a single root application or library, it should be sufficient to have a single `conan install` and `conan_basic_setup` in the root folder. Libraries that are built from source, should be automatically added with `add_subdirectory` (using a conan free source directory) and directly linked without editables (should not even require a conanfile). There should be no need to create a separate workspace folder, as the `add_subdirectory`s should be called from the root application/library folder.

[x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: wpalfi
issue_6840: state: open
title: [question] Influence of options of dependencies on consumer's package ID.
body: As far as I understand, package_id() builds hash of a package based on settings, its own options and identifiers of dependencies (depending on package id mode, it could include name/version/user/channel/package-id/revisions).

Consider app -> lib -> sublib dependency graph. Let 'lib' be a compiled library (static or shared, doesn't matter), and 'sublib' be header-only library.

Assume sublib can work in different modes, selected by preprocessor definition. Natural (only?) way to expose it to conan would be defining an option in sublib recipe (say, sublib:mode), and use option's value to add compile flag in sublib's package_info() method.

Assume lib is built with default sublib:mode, generating package with hash L1 (calculated from lib's options, settings and some ID of sublib). Now assume app selects non-default sublib:mode. How to ensure that it would use a different package L2 for lib (since L1 uses different, potentially non-compatible, mode of sublib)?

1. Should sublib generate different packages with different hashes depending on 'mode' option? I think the expected answer is 'no': for example, standard helper ConanInfo.header_only() removes all options from structure used for package_id calculation. It is also the way many recipes in conan-center work. If we did not call this header_only helper, we would generate two different packages that would be fully identical (after all, the only difference is how package_info() would fill its structures when evaluated while building consumers).
2. If we do generate different packages for sublib, to make sure that new hash of lib is created, it would need to use at least full_package_mode. Is there any situation where compiled library would use any other package mode? Why isn't it a default option?
3. It seems that this situation wouldn't even appear if cpp_info.options included options of all dependencies, yet in the ConanInfo.create() there is an explicit options.clear_indirect() call. What is the reason?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: awgil
issue_6834: state: open
title: [bug probably] MD5 tutorial with cygwin
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 10 (cygwin)
  * Compiler+version: GCC 9.3
  * Conan version: 1.24.0
  * Python version: 2.7

### Steps to reproduce (Include if Applicable)
Do https://docs.conan.io/en/latest/getting_started.html in the cygwin terminal.

Im an absolute newbie to conan and i dont know if this error is due to CMake but it badly add **"../"** before an absolute Windows path, like **"-I../C:/path/to/something"**, so GCC throw an error.
When i suppress this "../" all compile well
Edit:
Same thing with ninja
### Logs (Executed commands with output) (Include/Attach if Applicable)

```bash
$ /usr/bin/c++.exe   -I../C:/cygwin64/home/alpin/.conan/data/poco/1.9.4/_/_/package/d4195b3735a130f46fcb153dcdcca45c5013929a/include -I../C:/cygwin64/home/alpin/.conan/data/openssl/1.0.2t/_/_/package/d140711d95cc16a85766a8fc3a551dfafe84cf63/include -I../C:/cygwin64/home/alpin/.conan/data/zlib/1.2.11/_/_/package/3fb49604f9c2f729b85ba3115852006824e72cab/include -O3 -DNDEBUG    -std=c++11 -DPOCO_STATIC=ON -DPOCO_NO_AUTOMATIC_LIBS -MD -MT CMakeFiles/md5.dir/md5.cpp.o -MF CMakeFiles/md5.dir/md5.cpp.o.d -o CMakeFiles/md5.dir/md5.cpp.o -c ../md5.cpp
../md5.cpp:1:10: erreur fatale: Poco/MD5Engine.h : No such file or directory
    1 | #include "Poco/MD5Engine.h"
      |  
```
user: log4b0at
issue_6830: state: open
title: [question] combine libraries into one
body: Let's say I'm developing library A with dependencies B, C, D which were provided by conan (cmake approach)

And I have android project on Visual Studio which will use my library A 

But I can't just link against A since it is highly tied with B, C, D. What can I do with it? 

user: NukeBird
issue_6826: state: open
title: [bug] New init() recipe method runs before name/version attributes are assigned
body: ### Environment Details
  * Operating System + version: Linux, Fedora 30
  * Conan version: 1.24.0
  * Python version: 3.7.6

When the new `init()` method runs, the recipe object is currently in a partially initialized state. I was very surprised to find that the name/version attributes from the command line are assigned only after the `init()` is executed. I did not find any documentation on what attributes are safe to access in `init()`, and which should not be accessed. But at least the name/version attributes seem like ones that should always be available.

My use case that triggered the problem was to look some information up in `self.conan_data` based on the recipe name/version passed from the command line. The data from `conandata.yml` is fully loaded at this point, but, suprisingly, name/version are still not set.

user: himikof
issue_6822: state: open
title: [feature] Specific return code for missing credentials
body: I am integrating conan into another build system (gradle).
I would like conan to return a specific error code in the case of a missing authentication.
ie. a return code distinguishable from other existing return codes:
https://docs.conan.io/en/latest/reference/commands/return_codes.html

Currently our build fails when a user forgot to give his credentials with:
```
Please log in to "myremote" to perform this action. Execute "conan user" command.
ERROR: Failed requirement '...' from 'conanfile.py (myproject/None)'
ERROR: Conan interactive mode disabled. [Remote: myremote]
```

As all of our team is new to conan it is not easy for them to know what to do with such an error msg.
With a specific error msg, I could better explain what they should do and eventually prompt for a login/password.

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: jeremy-coulon
issue_6814: state: open
title: [feature] Make the Dot Graph more readeable
body: _**As a** user, **i want to** have a clear and simple manner for reading the dependencies of a given project **to** detect misalignments in the architecture faster._

## Baground
`Conan` has two different formats for generating the output of the dependencies graph 
- `html`: providing an interactive HTML graph
- `dot`: provinging a `Graphviz-DOT` file describing the dependencies. This file is, at the same time, exportable to several formats like `png` or `svg` using `dot (graphviz`)

So far, the `dot` graph generated for conan is simple: it contains the nodes labeled as the reference package states (i.e. `pkgB/1.9.8@org/testing`). While for many use cases, the output is good enough, when the dependency graph becomes harder, the output may result also less readeable (see for instance the diagram displayed at #3267)

![image](https://user-images.githubusercontent.com/1688725/78685776-84950980-78f2-11ea-938b-8c3d4b1ab9a4.png)

There, several problems can be observed
- The graph is optimized to be as compact as possible, having 'curved' edges and many crossings at the same time
- Some edges are replicated because respecting the _real_ depndency occurency (see for instance `match` --> `concept`)

Moreover, the output can be also nicer (like the one generated in `html` for those situations where such diagram is embedded in some documentation (i.e. colorizing).

A good exampled of how i imagine the output improved was shown in the latest `1.24.0` release where _build context_ was introduced (https://docs.conan.io/en/latest/devtools/build_requires.html?highlight=build%20context#build-and-host-contexts)

![image](https://user-images.githubusercontent.com/1688725/78686748-b195ec00-78f3-11ea-943f-b46cc048f736.png)


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: alacasta
labels: component: ux: No changes to core business logic
issue_6813: state: open
title: [feature] Alert final user if include_path (and other cpp_info directories) are not directories
body: I wrote a recipe using a requires.
The required dependancy was misconfigured and the ` self.deps_cpp_info['required'].include_paths` was set to `[]`.

An alert indicating that the dependancy was misconfigured and its `include_path` was incorrect would be time saving.

More precisely, in `build_info.py` , in `_filter_path` we call `os.isdir.path(p)` and a warning here could be more than appreciated !

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: vhuber
issue_6801: state: open
title: [bug] Conan fails to download pcre package sources because of "sslv3 alert handshake failure"
body: I want to install/build the `pcre/8.41` package on a Debian system and conan seems to fail when it tries to download the source package.

`
pcre/8.41: Configuring sources in /home/knitschi/.conan/data/pcre/8.41/_/_/source
ERROR: Error downloading file https://ftp.pcre.org/pub/pcre/pcre-8.41.tar.gz: 'HTTPSConnectionPool(host='ftp.pcre.org', port=443): Max retries exceeded with url: /pub/pcre/pcre-8.41.tar.gz (Caused by SSLError(SSLError(1, '[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:720)'),))'
`

When I search the internet for the problem it mostly leads to posts that state that this is either an openssl misconfiguration or an openssl bug and in most cases it is sugested to update openssl. However, when I use execute `wget https://ftp.pcre.org/pub/pcre/pcre-8.41.tar.gz` the download works just fine. 

I think, that this is not really a conan bug, but rather a problem of my system configuration, but I am not sure, what exactly I need to upgrade or where I can change the openssl configuration that is used by conan. 

I would appriciate some hints on where to start looking for the problem.

### Environment Details
  * Operating System+version: Debian 9.8 (stretch)
  * Compiler+version: Gcc 6.3
  * Conan version: 1.24
  * Python version: 3.5.3
  * OpenSSL version: 1.1.0j-1~deb9u1

### Logs 

````
knitschi@DevDebian9:~/dev/BuildCPFAssistant$ conan install -pr Sources/CIBuildConfigurations/ConanProfile-Gcc-debug -if Conan/Gcc-debug Sources --build=missing
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=6.3
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
CC=/usr/bin/gcc
CXX=/usr/bin/gcc
pcre/8.41: WARN: Package is corrupted, removing folder: /home/knitschi/.conan/data/pcre/8.41/_/_/package/9a5ea7ba05754d0941f422940e73aa8a0713973e
conanfile.txt: Installing package
Requirements
    bzip2/1.0.8 from 'conan-center' - Cache
    pcre/8.41 from 'conan-center' - Cache
    zlib/1.2.11 from 'conan-center' - Cache
Packages
    bzip2/1.0.8:2175c272cb152e98eb888b3337a069e8687fc1e7 - Cache
    pcre/8.41:9a5ea7ba05754d0941f422940e73aa8a0713973e - Build
    zlib/1.2.11:6e4a80503669881633a370290b60a1a852920b76 - Cache

Installing (downloading, building) binaries...
bzip2/1.0.8: Already installed!
zlib/1.2.11: Already installed!
pcre/8.41: WARN: Build folder is dirty, removing it: /home/knitschi/.conan/data/pcre/8.41/_/_/build/9a5ea7ba05754d0941f422940e73aa8a0713973e
pcre/8.41: WARN: Trying to remove corrupted source folder
pcre/8.41: WARN: This can take a while for big packages
pcre/8.41: Configuring sources in /home/knitschi/.conan/data/pcre/8.41/_/_/source
ERROR: Error downloading file https://ftp.pcre.org/pub/pcre/pcre-8.41.tar.gz: 'HTTPSConnectionPool(host='ftp.pcre.org', port=443): Max retries exceeded with url: /pub/pcre/pcre-8.41.tar.gz (Caused by SSLError(SSLError(1, '[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:720)'),))'
Waiting 5 seconds to retry...
ERROR: pcre/8.41: Error in source() method, line 49
        tools.get(**self.conan_data["sources"][self.version])
        ConanException: Error downloading file https://ftp.pcre.org/pub/pcre/pcre-8.41.tar.gz: 'HTTPSConnectionPool(host='ftp.pcre.org', port=443): Max retries exceeded with url: /pub/pcre/pcre-8.41.tar.gz (Caused by SSLError(SSLError(1, '[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:720)'),))'
````
user: Knitschi
issue_6796: state: open
title: [question/bug?] Problems building anything on arch=x86 under windows
body: Hello,

i have proper builds of qt and qca using arch=x86_64 under windows, but when using arch=x86 both build fail with the same reason.

Both are build under windows10, visual-studio 2019 - you see the flags below.

Scanning bincrafters i hardly find anything build for arch x86 (as QT/QCA are not either - so my question, is that broken entirely under windows / discourage / impossible what so ever?

Thank you!

QT
```
2020-04-04T16:34:33.9455698Z ##[section]Starting: build
2020-04-04T16:34:33.9632616Z ==============================================================================
2020-04-04T16:34:33.9632987Z Task         : Bash
2020-04-04T16:34:33.9633303Z Description  : Run a Bash script on macOS, Linux, or Windows
2020-04-04T16:34:33.9633614Z Version      : 3.163.1
2020-04-04T16:34:33.9633869Z Author       : Microsoft Corporation
2020-04-04T16:34:33.9634486Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/bash
2020-04-04T16:34:33.9634928Z ==============================================================================
2020-04-04T16:34:34.8753357Z Generating script.
2020-04-04T16:34:34.8755804Z [command]"C:\Program Files\Git\bin\bash.exe" --noprofile --norc -c pwd
2020-04-04T16:34:34.8756134Z /d/a/_temp
2020-04-04T16:34:34.8756261Z 
2020-04-04T16:34:34.8757228Z ========================== Starting Command Output ===========================
2020-04-04T16:34:34.8758720Z [command]"C:\Program Files\Git\bin\bash.exe" --noprofile --norc /d/a/_temp/dbeb0ba8-01a5-4155-afe3-cf26422a20c9.sh
2020-04-04T16:34:34.8759211Z ensure MSBuild is in path
2020-04-04T16:34:34.8759427Z starting build
2020-04-04T16:34:34.8759722Z Cloning into 'C:/Users/VSSADM~1/AppData/Local/Temp/qt.GGOiMk3pt'...
2020-04-04T16:34:36.3759109Z Building Qt in '/tmp/qt.GGOiMk3pt/build'
2020-04-04T16:34:37.2719340Z Exporting package recipe
2020-04-04T16:34:37.2743525Z qt/5.14.1@kwconan/stable exports: File 'conandata.yml' found. Exporting it...
2020-04-04T16:34:37.2951068Z qt/5.14.1@kwconan/stable exports: Copied 1 '.yml' file: conandata.yml
2020-04-04T16:34:37.2951943Z qt/5.14.1@kwconan/stable exports: Copied 1 '.conf' file: qtmodules.conf
2020-04-04T16:34:37.2952391Z qt/5.14.1@kwconan/stable exports: Copied 5 '.diff' files
2020-04-04T16:34:37.3060527Z qt/5.14.1@kwconan/stable: The stored package has not changed
2020-04-04T16:34:37.3077504Z qt/5.14.1@kwconan/stable: Exported revision: 71c025e0a722b588c7db4b72539c7cdf
2020-04-04T16:34:37.3078269Z Configuration:
2020-04-04T16:34:37.3078512Z [settings]
2020-04-04T16:34:37.3078686Z arch=x86
2020-04-04T16:34:37.3078852Z arch_build=x86
2020-04-04T16:34:37.3079034Z build_type=Release
2020-04-04T16:34:37.3079257Z compiler=Visual Studio
2020-04-04T16:34:37.3079453Z compiler.runtime=MD
2020-04-04T16:34:37.3079663Z compiler.version=16
2020-04-04T16:34:37.3079839Z os=Windows
2020-04-04T16:34:37.3080025Z os_build=Windows
2020-04-04T16:34:37.3080194Z [options]
2020-04-04T16:34:37.3080377Z qca:shared=True
2020-04-04T16:34:37.3080555Z qt:opengl=no
2020-04-04T16:34:37.3080747Z qt:qttools=True
2020-04-04T16:34:37.3080925Z qt:shared=True
2020-04-04T16:34:37.3081116Z qt:with_fontconfig=True
2020-04-04T16:34:37.3081340Z qt:with_harfbuzz=False
2020-04-04T16:34:37.3081543Z qt:with_libalsa=False
2020-04-04T16:34:37.3081761Z qt:with_libjpeg=False
2020-04-04T16:34:37.3081958Z qt:with_libpng=True
2020-04-04T16:34:37.3082166Z qt:with_mysql=False
2020-04-04T16:34:37.3082358Z qt:with_odbc=False
2020-04-04T16:34:37.3082572Z qt:with_openal=False
2020-04-04T16:34:37.3082767Z qt:with_pcre2=True
2020-04-04T16:34:37.3082967Z qt:with_pq=False
2020-04-04T16:34:37.3083154Z qt:with_sdl2=False
2020-04-04T16:34:37.3083593Z qt:with_sqlite3=False
2020-04-04T16:34:37.3083788Z [build_requires]
2020-04-04T16:34:37.3083949Z [env]
2020-04-04T16:34:37.3084076Z 
2020-04-04T16:34:42.5183795Z qt/5.14.1@kwconan/stable: Forced build from source
2020-04-04T16:34:42.5212574Z msys2/20190524: Not found in local cache, looking in remotes...
2020-04-04T16:34:42.5213850Z msys2/20190524: Trying with 'conan-center'...
2020-04-04T16:34:42.7124987Z Downloading conanmanifest.txt
2020-04-04T16:34:42.9089176Z Downloading conanfile.py
2020-04-04T16:34:43.0881044Z Downloading conan_export.tgz
2020-04-04T16:34:43.2886107Z msys2/20190524: Downloaded recipe revision 0
2020-04-04T16:34:43.4979072Z 7zip/19.00: Not found in local cache, looking in remotes...
2020-04-04T16:34:43.4979976Z 7zip/19.00: Trying with 'conan-center'...
2020-04-04T16:34:43.6838750Z Downloading conanmanifest.txt
2020-04-04T16:34:43.8631622Z Downloading conanfile.py
2020-04-04T16:34:44.0410050Z Downloading conan_export.tgz
2020-04-04T16:34:44.2275732Z 7zip/19.00: Downloaded recipe revision 0
2020-04-04T16:34:44.5156373Z lzma_sdk/9.20: Not found in local cache, looking in remotes...
2020-04-04T16:34:44.5162914Z lzma_sdk/9.20: Trying with 'conan-center'...
2020-04-04T16:34:44.6907222Z Downloading conanmanifest.txt
2020-04-04T16:34:44.8768698Z Downloading conanfile.py
2020-04-04T16:34:45.0590097Z Downloading conan_export.tgz
2020-04-04T16:34:45.2575656Z lzma_sdk/9.20: Downloaded recipe revision 0
2020-04-04T16:34:45.3123753Z make/4.2.1: Not found in local cache, looking in remotes...
2020-04-04T16:34:45.3124973Z make/4.2.1: Trying with 'conan-center'...
2020-04-04T16:34:45.4901245Z Downloading conanmanifest.txt
2020-04-04T16:34:45.6774644Z Downloading conanfile.py
2020-04-04T16:34:45.8600034Z Downloading conan_export.tgz
2020-04-04T16:34:46.0742635Z make/4.2.1: Downloaded recipe revision 0
2020-04-04T16:34:46.4528625Z WARN: libxml2/2.9.9: requirement libiconv/1.15 overridden by gettext/0.20.1@bincrafters/stable to libiconv/1.16 
2020-04-04T16:34:46.4617539Z ERROR: Loop detected: 'lzma_sdk/9.20' requires 'msys2/20190524' which is an ancestor too
2020-04-04T16:34:46.5309458Z 
```

QCA

```
ensure MSBuild is in path
starting build
Cloning into 'C:/Users/VSSADM~1/AppData/Local/Temp/qca.9CytBkXAs'...
Building QCA in '/tmp/qca.9CytBkXAs/build'
Exporting package recipe
qca/2.2.1@kwconan/stable exports: Copied 2 '.patch' files: qca_relative_imported_include_path.patch, qca_target_file_for_configuration.patch
qca/2.2.1@kwconan/stable: A new conanfile.py version was exported
qca/2.2.1@kwconan/stable: Folder: D:\a\1\.conan\data\qca\2.2.1\kwconan\stable\export
qca/2.2.1@kwconan/stable: Exported revision: 49a56e0abee20e00d4a3bb96f2ccd62ddd8b8b7f
Configuration:
[settings]
arch=x86
arch_build=x86
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
qca:shared=True
qt:opengl=no
qt:qttools=True
qt:shared=True
qt:with_fontconfig=True
qt:with_harfbuzz=False
qt:with_libalsa=False
make/4.2.1: Downloaded recipe revision 0
WARN: libxml2/2.9.9: requirement libiconv/1.15 overridden by gettext/0.20.1@bincrafters/stable to libiconv/1.16 
ERROR: Loop detected: 'lzma_sdk/9.20' requires 'msys2/20190524' which is an ancestor too
```
user: EugenMayer
issue_6795: state: open
title: [bug] Layout files: Unable to use absolute path on Windows
body: ### Environment Details (include every applicable attribute)
  * Operating System Windows:
  * Compiler Visual Studio 2019:
  * Conan version 1.24
  * Python version: 3.7.3

### Steps to reproduce (Include if Applicable)

- `git clone https://github.com/conan-io/examples.git`
- run `features/editable/cmake/build.bat` => works as expected
- in features\editable\cmake\layout_vs replace `src` by `C:/examples/features/editable/cmake/say/src`
- run `build.bat` again => error Cannot open include file: 'say.h'

CONAN_INCLUDE_DIRS_SAY resolves to `C:/examples/features/editable/cmake/say/C` but it should be `C:/examples/features/editable/cmake/say/src`

user: wpalfi
issue_6789: state: open
title: conan support of "llvm" and "ClangCL" toolchains for Visual Studio  
body: Hello,

I am trying to compile one of my projects with llvm toolchain and I got blocked by conan. I was trying to pre-build missing conan dependencies with such profile:

```
[build_requires]
[settings]
    os=Windows
    os_build=Windows
    arch=x86_64
    arch_build=x86_64
    compiler=Visual Studio
    compiler.version=15
    compiler.cppstd=14
    compiler.toolset=llvm
    build_type=Debug
[options]
[env]
```

However, results are like that:
```
conan install boost/1.69.0@conan/stable --build=missing --profile=vs_llvm
ERROR: Invalid setting 'llvm' is not a valid 'settings.compiler.toolset' value.
Possible values are ['LLVM-vs2012', 'LLVM-vs2012_xp', 'LLVM-vs2013', 'LLVM-vs2013_xp', 'LLVM-vs2014', 'LLVM-vs2014_xp', 'LLVM-vs2017', 'LLVM-vs2017_xp', 'None', 'v100', 'v110', 'v110_xp', 'v120', 'v120_xp', 'v140', 'v140_clang_c2', 'v140_xp', 'v141', 'v141_clang_c2', 'v141_xp', 'v142', 'v90']
Read "http://docs.conan.io/en/latest/faq/troubleshooting.html#error-invalid-setting"
```

As I understand these valid toolchain values are pre-hardcoded somewhere in the conan and could be expanded with "llvm" and "ClangCL".

"llvm" comes from https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain and is supported in VS17.
"ClangCL" comes from official VS19 clang support.

Thanks in advance!

Best regards
user: aegis-dev
issue_6783: state: open
title: [feature] Separate build profiles for different packages
body: Suppose I have Conan packages `cmake` and `clang`. Now when building other code I want to use package `cmake` built in debug mode while using package `clang` built in release mode.

That would require using different build profiles for different `build_requires` which, looks like, is not possible as of Conan 1.24.

As a bonus feature, what about default build profiles? If package or profile `build_requires` package `foo`, check if profile `default_build_foo` exists and use it for that package. This will allow people to create profiles `default_build_cmake`, `default_build_gcc`, `default_build_clang`, etc to have global control of the configuration of their build tools.
user: ghost
issue_6777: state: open
title: [bug] 'Copying sources to build folder' fails on WSL
body: ### Environment Details
  * Operating System+version: Debian under Windows 10.0.18363.720
  * Compiler+version: gcc 8.3.0
  * Conan version: 1.24.0
  * Python version: 3.7.3

### Steps to reproduce (Include if Applicable)
conanfile.txt
```
[generators]
cmake

[requires]
cryptopp/8.2.0@bincrafters/stable

[options]

[imports]
```
`~/.local/bin/conan install . -s build_type=RelWithDebInfo -s compiler=gcc -s compiler.version=8 -s compiler.libcxx=libstdc++11 -s compiler.cppstd=17 -g=cmake --build=missing`

### Logs (Executed commands with output)

```
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=RelWithDebInfo
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

cryptopp/8.2.0@bincrafters/stable: WARN: Package is corrupted, removing folder: /mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/package/e057d6535368819b51ca06d43e536f86b92dd7f1
conanfile.txt: Installing package
Requirements
    cryptopp/8.2.0@bincrafters/stable from 'conan-center' - Cache
Packages
    cryptopp/8.2.0@bincrafters/stable:e057d6535368819b51ca06d43e536f86b92dd7f1 - Build

Installing (downloading, building) binaries...
cryptopp/8.2.0@bincrafters/stable: WARN: Build folder is dirty, removing it: /mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1
cryptopp/8.2.0@bincrafters/stable: Copying sources to build folder
ERROR: [('/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/source/source_subfolder/.github', '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder/.github', "[Errno 13] Permission denied: '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder/.github'"), ('/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/source/source_subfolder/TestData', '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder/TestData', "[Errno 13] Permission denied: '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder/TestData'"), ('/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/source/source_subfolder/TestPrograms', '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder/TestPrograms', "[Errno 13] Permission denied: '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder/TestPrograms'"), ('/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/source/source_subfolder/TestScripts', '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder/TestScripts', "[Errno 13] Permission denied: '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder/TestScripts'"), ('/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/source/source_subfolder/TestVectors', '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder/TestVectors', "[Errno 13] Permission denied: '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder/TestVectors'"), ('/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/source/source_subfolder', '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder', "[Errno 13] Permission denied: '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1/source_subfolder'"), ('/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/source', '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1', "[Errno 13] Permission denied: '/mnt/d/conan/.conan/data/cryptopp/8.2.0/bincrafters/stable/build/e057d6535368819b51ca06d43e536f86b92dd7f1'")]
Error copying sources to build folder
```

Workaround in https://bugs.python.org/issue38633 has helped locally
user: Nekto89
issue_6761: state: open
title: [feature] On-the-fly configuration for 2.0
body: Following the discussions in Slack, I'd like to propose an optional extra configuration file for conan that can be stored per-repo. 

## Rationale

As explained by @memsharded, Conan 2.0 will try to get rid of most environment variables and move all configuration to conan.conf instead. Getting rid of environment variables without an alternative would make our lives a tad more difficult. We are by no means an "enterprise", but our use-case is typically what is referred to as "the enterprise use-case" of conan:

  * We have a monorepo of recipes that we implemented ourselves
  * We have full control over the installation of conan
  * We can assume that all recipes behave well (in the sense that they don't break each other in any way)

We have a bootstrap script that installs conan into a user-level directory and creates a wrapper script in the current build directory to run this installation. Along with some environment variables that it sets. The conan version and these environment variables vary from repo-to-repo in our organization. So for us, a user level config is global. 

Technically, we could call `conan config get` to capture the current values, and then `conan config set` to apply the repo-level config (which is in the environment currently), and then once again `conan config set` to restore at the end of the conan run. But there are some problems with this approach:

  * `conan config` is really quite slow and doesn't scale well for multiple settings. The above workaround would need three `conan config` calls per setting per conan run.
  * Lots of implementation complexity in a wrapper that we would prefer to simplify instead of adding to it.

## Proposal

Add an environment variable `CONAN_EXTRA_CONFIG` which takes a filename. Apply any configuration from that file on top of the current configuration, on-the-fly, right after the configuration was loaded. These settings should not be saved, only applied at runtime. This basically mimics the above workaround, but with substantially less overhead and complexity.

## Concerns

Reflecting on the Slack discussion, I'd like to address some possible concerns as well.

### Recipe portability

Since we control all settings in the repo, we can make sure that we only set configuration on-the-fly that keeps our recipes portable. 

### Some recipe setting CONAN_EXTRA_CONFIG on its own

We control all our recipes so we can ensure that they won't do that. But I'm also proposing to only read this environment at the start of the conan run, so theoretically a recipe should not be able to cause any trouble like that. There could be an value in the configuration to opt-in to the on-the-fly configration feature, so OSS use-cases could assume it's disabled.

--- 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: sztomi
issue_6753: state: open
title: [bug] Concurrency - installing same package from multiple workers seems to generate races
body: ### Environment:
Preconditions: Conan is already installed and is happily sitting in some directory. 
Conan is packaged using pyinstaller. 
* Red Hat Enterprise Linux Server release 6.10 (Santiago)
* python 3.6.10
* conan 1.23.0
* compiler: gcc 8.2


### Steps 
What are we doing.
We are launching multiple workers that install 5 instances of the same app, so 5 workers invoke something like:
`conan install reference -if .... -g ..`
Immediatelly after `conan install` finished we are  sourcing envs and launching the apps. 

What we have observed is the following:
There are instances of the app that fail to boot with error like this:
```
app: error while loading shared libraries: libboost_wave.so.1.72.0: cannot open shared object file: No such file or directory
```
So first instance that installed and tried to start failed, however the further instances were fine.
This looks like the first worker have not properly recognized whether that  package `boost`is still being downloaded, and have not waited for the download to finish ( maybe they thought the download has succeded already )?

In the logs I can see some like these:
```
openssl/1.0.2t is locked by another concurrent conan process, wait...
If not the case, quit, and do 'conan remove --locks'
```
But there is no such entry for `boost`. (which of course can happen, but still.. )

We have seen this issue on 2 occassions out of 7 clear installs we have done so far. 
Any thoughts?
What sort of logs would you require from us?


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: fulara
issue_6747: state: open
title: [suggestion] download and unzip bundle like tools.get for exports_sources
body: <!-- What is your question? Please be as specific as possible! -->
Hi there,
I did a quick look at the code and find out there might be a little feature gap.
unlike `tools.get` which perform as a higher-level handler for `download` to perform `unzip` after downloading packages.
I think such a feature is needed with the `exports_sources` option, so after `conan install` for packages that bundled with `export_sources` option, it can be unzipped properly.
if there is an existing workaround for this, it would be great if you guide me through that, and if there is no such thing, I will be more than happy to contribute.
- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Prhmma
issue_6742: state: open
title: [question] Can the conan version used be determined from package contents?
body: Is there any place in recipe manifests or binary package info metadata where the Conan version used to build it is "stamped"?

If not, can we add something?

This would be handy when attempting to eliminate questions such as "Has there been a change in conan recently?" when trying to resolve build issues.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: michaelmaguire
issue_6732: state: open
title: [question] Performance of parallel_download
body: Hi!

I thought I'd share some performance numbers from testing out the new parallel_download feature released in 1.23.0. The below numbers were obtained on a VM running Ubuntu 18.04 with 4 virtual cores and 8GB of RAM.

The test set-up was running conan create on a conanfile.py which ends up installing 120 packages each time. The build step only takes 10-20s, so the time taken is dominated by installing packages. I cleared the local cache between each run.

```
parallel_download = OFF (commented out):
real	4m31.090s
user	0m51.465s
sys	0m10.899s

parallel_download = 2:
real	3m16.367s
user	0m54.972s
sys	0m14.303s

parallel_download = 4:
real	3m19.584s
user	0m56.525s
sys	0m19.725s

parallel_download = 8:
real	4m24.657s
user	1m5.907s
sys	0m35.089s

parallel_download = 16:
real	4m14.652s
user	1m10.295s
sys	0m40.923s
```

Some points to note:
- going higher on the parallel_download number seems to at some point make the process slower
- CPU load increases when increasing the parallel_download number but does not necessarily speed up whole process
- *It looks like* decompression speed decreases a reasonable amount per indivual package when using the parallel_download feature. I know this is quite unscientific but I don't know a good way to measure this. Happy to take suggestions to get useful numbers.

The performance increase is great but I was expecting a bit more, so I was wondering if there might be some easy gain to be had - my question is whether there be something slowing down the decompression when using the parallel_download feature and if so if there is a known method of improving this? 

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: acmeijer
issue_6726: state: open
title: msbuild build helper should support adding resource compiler include paths
body: The msbuild build helper mostly relies on environment variables to provide paths to dependency header files and libraries.  When the msbuild helper is used on a solution where the resource compiler requires header files from a dependency, the environment does not appear to be set up to provide the needed paths.  The resource compiler documentation indicates that it will look at the INCLUDE environment variable.  I was unable to determine if the msbuild helper sets this environment variable correctly during the resource compile build. It appears not since dependency paths are not found.  It also concerns me that using the INCLUDE environment variable might mix header directories with the C/C++ compiles.
As a possible alternate solution, the conan_build.props file could be modified to include:

    <ResourceCompile>
      <AdditionalIncludeDirectories>%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
    </ResourceCompile>
  </ItemDefinitionGroup>

I have attached a patch file demonstrating this change.  It has been tested with a very simple case.

[changes-patch.txt](https://github.com/conan-io/conan/files/4376169/changes-patch.txt)


user: gdray-dev
issue_6725: state: open
title: [bug] build_requires packages can't be forced to build from sources by providing a pattern
body: ### Problem Statement
When using gtest for unit tests in my library it makes sense to put it in "build_requires", since it is not needed by the clients of the lib. Everything is fine until I need to build a configuration for which gtest binaries in conan-center are not present. Adding "--build gtest" fails. It seems that the pattern matching is done only vs "requires" and not vs "build_requires". I can still force gtest to compile from sources by adding "--build=missing" or "--build" without any pattern. Probably  "--build=missing" is actually the way to go anyway, but still - I think this is a bug.

### Environment Details
  * Operating System+version: Win10
  * Compiler+version: VS2019
  * Conan version: 1.22.2
  * Python version: 3.8

### Steps to reproduce
  * Create a simple project utilizing gtest as a build_require (build_requires = "gtest/1.10.0")
  * conan create . xxx/yyy@zzz/www --build gtest

### Logs
ERROR: No package matching 'gtest' pattern
user: ghost
issue_6719: state: open
title: [bug] order of command line params now matters
body: 
![Screen Shot 2020-03-23 at 1 57 28 PM](https://user-images.githubusercontent.com/40178586/77348254-81552780-6d0f-11ea-8c02-d6e4797aac51.png)

### Environment Details (include every applicable attribute)
  * Operating System+version: Win10 latest
  * Compiler+version: visual studio 2017 latest
  * Conan version: 1.23.0
  * Python version: 3.8.2

### Steps to reproduce (Include if Applicable)

put the repo id (keysght/stable) after some other options in the command line

### Logs (Executed commands with output) (Include/Attach if Applicable)

attached
user: keysight-daryl
issue_6709: state: open
title: [question] Using `conan graph` to get the build-order of a subgraph
body: We are trying to develop a custom tool that will allow us to ease development environment setups:

* A repository is cloned 
* All its dependencies are installed via Conan
* For some well identified dependencies (other repositories from our organization), they are installed as local repositories, for developer to modify

To address this last point, we need to get the build-order for a subgraph. Let's imagine this simple complete graph:
`C -> B -> A`

We obtained the complete lockfile via: `conan graph lock -pr myprofile C/conan/`

We can obtain the complete build order with: `conan graph build-order conan.lock`

Yet, at some point we need the build-order only for the subgraph 
`B -> A`
 how can we achieve that?

----

Side note: we tried to control with the `--build` option.
In particular`conan graph build-order -b=never conan.lock`, yet it is still outputting the same complete build order (apparently because the recipes have the "missing" build policy in them)
user: Adnn
issue_6708: state: open
title: [question] Select OpenSSL version
body: Hi all, 

I' have same software that runs on several linux IoT platforms and I'm using OpenSSL to communicate over network.
As in examples I always used openssl requirement in conanfile.txt/py and all works except few things I don't like.

Apart that several software components that use openssl may have multiple static openssl (potentially of different versions) copies around increasing needed space for my software, the majoir issue is that on several of our devices we have secure element chips and the openssl that comes with the platform has beed customized/configured to use the secure element.

Our software do not care about platform it wants just to use openssl. Possibly the platform one but, if not present, the one from conan package.

This scenario may be extended to all platform libraries. 
Thinking that 99% of cases on linux platforms you're granted to have an openssl instance, telling conan to compile and link to a static version of openssl sounds like telling to compile and link to a specific libc version.

How would you manage such scenario?








user: thegwydd
issue_6687: state: open
title: [question] cppstd helper utilities
body: As per contribution guide I am first asking question, only then drafting a pull request. 

I was thinking of slightly reworking functionality in `tools/settings.py` - this file has functionalities around cppstd. 

What I would see beneficial:

1) Add mirroring function for 'max' cppstd.
2) Rework code so that deduced_cppstd is public
3) Add method like.. `deduced_cppstd_long`  which returns cppstd in form of '1998', '2011', so that comparision in recipes is easier for exampel:
if `cppstd > 11` is now tricky because you have to keep mind of '98' and also you have to remember that cppstd defaults to None if not specified in the profile.

What do you guys think?
Can I go ahead and create a pr for this?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: fulara
issue_6683: state: open
title: [bug] Enabling parallel download/upload cause majority of our build to fail.
body: Is this issue on the artifactory side rather than conan ? I dont know.
I have enabled parallel download and upload, on both of these we are getting random failures.

To provide more inforamtion, because some of the errors refers to certificates we provide a custom certificate that usually seems to be working.

### Environment Details (include every applicable attribute)
  * Operating System+version: rhel6/rh7, packag built on rh6 used on both rh6 and rh7.
  * Compiler+version: gcc 8.x - devtoolset8 - will have to check the exact version
  * Conan version 1.23.0:
  * Python version 3.6.10:
  * Artifactory version:  6.10.1

# How do we provide conan
We bundle conan using pyinstaller, on rh6 machine roughly following this procedure here: 
https://github.com/conan-io/conan/issues/6325
We then distribute that pyinstalled package across and just use it as is.

# Do we use download cache?
No, we download everything from scratch everytime
conan.conf:
```
[log]
run_to_output = True        # environment CONAN_LOG_RUN_TO_OUTPUT  
run_to_file = False         # environment CONAN_LOG_RUN_TO_FILE  
level = critical            # environment CONAN_LOGGING_LEVEL  
print_run_commands = True
[general]
default_profile = default
compression_level = 9                 # environment CONAN_COMPRESSION_LEVEL
sysrequires_sudo = True               # environment CONAN_SYSREQUIRES_SUDO
request_timeout = 60                  # environment CONAN_REQUEST_TIMEOUT (seconds)
default_package_id_mode = full_package_mode
revisions_enabled = 1
full_transitive_package_id = 1
parallel_download = 64

[storage]
path = ./data

[proxies]
no_proxy_match = *...*
http = ...
https = ....

[hooks]
attribute_checker
```

### Steps to reproduce (Include if Applicable)
Have a package with quite a few dependencies and do `conan create .` and `upload *` to force loads of uploads and downloads.

## Exact procedure we are doing.
Before each build we are downloading are bundled conan package and and initializing this from scratch, and then just build particular package.
We have provided custom `cacert.pem`

I am getting various set of errors:
### Logs (Executed commands with output) (Include/Attach if Applicable)

Error no1 ConanException - MAIL
```
error	13-Mar-2020 17:08:20	bzip2/1.0.8: ERROR: Exception while getting package: f610127d9b93ffcf379adc4fddaeeacc2308a891
error	13-Mar-2020 17:08:20	bzip2/1.0.8: ERROR: Exception: <class 'conans.errors.ConanException'> 'MAIL'. [Remote: ig]
error	13-Mar-2020 17:08:20	bzip2/1.0.8: WARN: Trying to remove package folder: /var/build/bamboo/agent-home/xml-data/build-dir/CIR-CORRBASTATS15-JOB1/.conan-standalone/bamboo/.conan/data/bzip2/1.0.8/_/_/package/f610127d9b93ffcf379adc4fddaeeacc2308a891
error	13-Mar-2020 17:08:20	ERROR: 'MAIL'. [Remote: ig]
```

Error no2 ceritificate spurious failure
```
error	13-Mar-2020 17:07:53	Unable to connect to ig=MY_URL
error	13-Mar-2020 17:07:53	1. Make sure the remote is reachable or,
error	13-Mar-2020 17:07:53	2. Disable it by using conan remote disable,
error	13-Mar-2020 17:07:53	Then try again.
error	13-Mar-2020 17:07:53	ace+tao/2.2a.p16: WARN: Trying to remove package folder: /var/build/bamboo/agent-home/xml-data/build-dir/CIR-CORRBASTATS15-CONRH7/.conan-standalone/bamboo/.conan/data/ace+tao/2.2a.p16/_/_/package/ba316f0705e1724202d82fe124ba3cec855505c8
error	13-Mar-2020 17:07:53	ERROR: HTTPSConnectionPool(host='artifacts.iggroup.local', port=443): Max retries exceeded with url: /artifactory/api/conan/ig-conan/v2/conans/ace+tao/2.2a.p16/_/_/revisions/13d05791c5df8ba20f662f9072b393a4/packages/ba316f0705e1724202d82fe124ba3cec855505c8/revisions/d1348aed34e4e8ae7e9e2e898c3b9bb5/files (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)'),))
```

Error no3 random bamboo variable?
```
error	13-Mar-2020 17:05:20	corba-stats/3.1: ERROR: Exception while getting package: bdef1eb1822b9e16f495a601d771a1a55cbe2c5e
error	13-Mar-2020 17:05:20	corba-stats/3.1: ERROR: Exception: <class 'conans.errors.ConanException'> 'bamboo_capability_os_arch'. [Remote: ig]
error	13-Mar-2020 17:05:20	corba-stats/3.1: WARN: Trying to remove package folder: /var/build/bamboo/agent-home/xml-data/build-dir/CIR-CORRBASTATS15-JOB1/.conan-standalone/bamboo/.conan/data/corba-stats/3.1/_/_/package/bdef1eb1822b9e16f495a601d771a1a55cbe2c5e
error	13-Mar-2020 17:05:20	ERROR: Error downloading file https://artifacts.iggroup.local/artifactory/api/conan/ig-conan/v2/conans/igcounters/1.3/_/_/revisions/67de2629f0a32c45ddd1ce5a9deb945f/packages/844baf09e70b1967aa243d91a3094bb6cdf5ce54/revisions/a00941a89c386d5c766881c425f73d0d/files/conanmanifest.txt: ''bamboo_capability_os_arch''
error	13-Mar-2020 17:05:20	ERROR: 'bamboo_capability_os_arch'. [Remote: ig]
```

Error no4 some npm error? 
```
ERROR: stats/3.1:f1c30f8929c64350fcc4683162cfbebc5bdf34c0: Upload package to 'ig' failed: 'NVM_NODEJS_ORG_MIRROR'. [Remote: ig]
```

I have run around 40 builds without parallel settings and this works then without issue.

references:
https://github.com/conan-io/conan/pull/6632
https://github.com/conan-io/conan/pull/5856

user: fulara
issue_6668: state: open
title: [bug] with multiple remotes, sometimes Conan uses the wrong one
body: This one is short and sweet and I hope easy to reproduce. Basically, if you have two remotes set up but you, and you are logged in to both via `conan user`, but you only have permissions to view packages on one remote, it will use the wrong remote. 

If I have two remotes set up, `remote1` and `remote2`
If you do something like `conan blah -r remote1` but you don't have correct access permissions on remote1, Conan seems to be falling back and using remote2. This behaviour would be fine if I did not specify to use a a remote but since I passed `-r` is it intended behaviour to use a different remote? 

What's actually worse about this bug is that in the log output, it shows as downloading stuff from the correct remote but that's is definitely not where it's getting stuff from in my testing. 

### Environment Details (include every applicable attribute)
  * Operating System+version: Ubuntu 16
  * Conan version: 1.20.5
  * Python version: 3.6

### Steps to reproduce (Include if Applicable)
1. Set up two remotes
2. Log in and autheticate to BOTH but ensure that one remote does not have the correct permissions to view packages. Also ensure that the same package name exists in both, but that they are actually different packages. 
3. Try running `conan install -r remote1` where the remote is the one without correct access permissions
4. Proffit

user: Daniel-Roberts-Bose
issue_6652: state: open
title: [question] conan search: non-default options
body: How can I figure out the non-default options when searching for a binary package?

E.g I want to use opencv:
```
conan search opencv/4.1.1@conan/stable -r conan-center -q "compiler.version=15 AND build_type=Release AND arch=x86_64 AND shared=False"
```
It has ~20 options. But there is no binary package with default options. So how can I know which of them I need to set manually?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: wpalfi
issue_6651: state: open
title: conan install https://... fails when proxy certificate is self-signed
body: Hello,

I am using conan 1.21.1 with proxy (proxy uses self-signed certificate) and experienced an issue while I was trying to run `conan create` for https://github.com/bincrafters/conan-folly 

(long story short: please add `--verify-ssl=False` as a parameter of the `conan install` and `conan create`)

```bash
# NOTE: --verify=False and GIT_SSL_NO_VERIFY=true 
CONAN_REVISIONS_ENABLED=1 \
    CONAN_VERBOSE_TRACEBACK=1 \
    CONAN_PRINT_RUN_COMMANDS=1 \
    CONAN_LOGGING_LEVEL=10 \
    GIT_SSL_NO_VERIFY=true \
    conan create . conan/stable -s build_type=Debug --verify=False --profile default --build missing
```

```bash
# NOTE: i can download that file in browser https://github.com/google/double-conversion/archive/v3.1.4.tar.gz or via wget --no-check-certificate

requests.exceptions.SSLError: HTTPSConnectionPool(host='github.com', port=443): 
Max retries exceeded with url: 
/google/double-conversion/archive/v3.1.4.tar.gz 
(Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] 
certificate verify failed (_ssl.c:852)'),))
```

NOTE: added self-signed certificate to the ~/.conan/cacert.pem file. 

conan install does not have currently an option to disable the verification of the certificate.
The download is performed using tools.download(). This utility has a parameter to enable/disable ssl checks.

```
def download(url, filename, verify=True, out=None, retry=2, retry_wait=5, overwrite=False,
             auth=None, headers=None)
```

NOTE: don't work either `including the ROOT (not a non-root ancestor) certificate in the Python requests package CA bundle, or create a new CA bundle that includes the root certificate and use the REQUESTS_CA_BUNDLE environment variable.` as in https://stackoverflow.com/a/56810796 and https://stackoverflow.com/a/46337779 and https://stackoverflow.com/a/42982144

As temporary fix i edited /usr/local/lib/python3.6/dist-packages/conans/client/rest/uploader_downloader.py and manually changed `self.verify = False`

I think a flag to disable ssl check would be a good solution in this use case.
What do you think about it ?
Is there currently another solution to perform the download from a server with a self-signed certificate ?

Related to https://github.com/conan-io/conan/issues/2460
user: blockspacer
issue_6645: state: open
title: Support external include directories with MSVC
body: In MSVC 2015 microsoft added support for "external include directories" these works similar to `isystem` with GCC/Clang - meaning that you can set an separate warning level on the source files in these directories.

This is done by enabling the feature:
`/experimental:external`

Then including the directories with `/external:I <path>`

Then you can set your own warning level on this with  `/external:WX`

This would be awesome if it was supported by conan. Since it's experimental and only works on 2015 and up we probably would need to make it opt-in, maybe by setting a variable like `CONAN_MSVC_EXPERIMENTAL_EXTERNAL_INCLUDES` and then also checking `CMAKE_SYSTEM_INCLUDES`.

This could all be handled in `cmake_common.py` and we could just pass these files as `INTERFACE_COMPILE_OPTIONS` instead of `INTERFACE_INCLUDE_DIRECTORIES`.

The best option I think would be if upstream CMake supported this, but this seems unlikely since there hasn't been much movement on the bug upstream: https://gitlab.kitware.com/cmake/cmake/issues/17904

Here is the microsoft blog post about it: https://devblogs.microsoft.com/cppblog/broken-warnings-theory/
user: tru
labels: component: Build: Build helpers, build systems..
issue_6640: state: open
title: [question] What level of testing is "conan test" intended to verify?
body: I am trying to design a library that I wish to create a Conan package from and I'm slightly confused as to what `conan test` is supposed to verify. Is `conan test` supposed to run all of my automated tests for the library (like my "GTest" tests that verify the full library functionality)? Or is it simply supposed to verify that the package can be installed correctly and can be consumed by another project and nothing more?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: tjwrona
labels: whiteboard: Put in common
issue_6636: state: open
title: [bug] Windows subsystem MSYS2 detection works partially
body: Hi there,

What I am trying to do
------------------------
I am building software on Windows natively (using Microsoft C++ compiler MSVC).
I am trying to compile ICU which uses primalily Makefiles. To use the default buildchain I want to use MSYS2 as environment.

The Problem
--------------
While using the ICU recipe from Conan Center Index (see [here](https://github.com/conan-io/conan-center-index/blob/91e98f9095451d3b6b050afdb5f909943c979295/recipes/icu/all/conanfile.py)) in a plain Windows command console ```cmd.exe``` it falsely detects a MSYS2 environment on my machine.

Investigation
--------------
Now as I was looking at the ICU recipe in the Conan Center Index (see [here](https://github.com/conan-io/conan-center-index/blob/91e98f9095451d3b6b050afdb5f909943c979295/recipes/icu/all/conanfile.py)) I saw that it uses ```tools.os_info.detect_windows_subsystem()``` to detect if it has to ```build_require``` ```msys2``` as dependency. See at line 42 in the [recipe](https://github.com/conan-io/conan-center-index/blob/91e98f9095451d3b6b050afdb5f909943c979295/recipes/icu/all/conanfile.py#L42):
https://github.com/conan-io/conan-center-index/blob/91e98f9095451d3b6b050afdb5f909943c979295/recipes/icu/all/conanfile.py#L42

When looking into the conan code one can see that ```bash``` and ```uname``` gets called (see [here](https://github.com/conan-io/conan/blob/fb2881e5bbdc9a5d2e45923a275781ef3d1c4f08/conans/client/tools/oss.py#L388)) to determine if it is been executed under MSYS2. But as I am executing the recipe in a plain Windows command console (cmd.exe) it is odd that it detects a MSYS2 subsystem before even processing any dependency (like MSYS2).
After investigating I found out that it actually uses the ```bash.exe``` from my environment path found in my PortableGit installation (```bin/bash.exe```) and executes ```uname``` from there. One can download this from the official [GIT homepage](https://git-scm.com/download/win).

It seems that PortableGit has been compiled under MSYS with a MinGW variant.

Results of my bash/uname tests from a plain Windows command console:
```bat
bash.exe -c "uname"
```
Results in: ```MINGW64_NT-6.1-7601```

```bat
bash.exe -c "uname -r"
```
Results in: ```3.0.7-338.x86_64```


Idea
------
The conclusion is that calling ```bash.exe -c uname``` without being in a real MSYS2 environment is not reliable (enough). I was thinking if it was suitable to specify the condition that MSYS2 is only valid if the environment variable ```MSYSTEM``` (introduction see [here](https://github.com/msys2/msys2/wiki/MSYS2-introduction)) is set as it is the base for every MSYS2 environment (MINGW32, MINGW64, MSYS2) (see [here](https://sourceforge.net/p/msys2/discussion/general/thread/dcf8f4d3/#5d86)).


Best regards

user: Johnnyxy
issue_6634: state: open
title: [feature] Provide a 'premake_multi' generator
body: <!-- What is your question? Please be as specific as possible! -->

I'm trying to use the new experimental premake generator with premake5 based on these guides:
https://docs.conan.io/en/latest/reference/generators/premake.html
https://docs.conan.io/en/latest/integrations/build_system/premake.html#premake

But I can't figure out how to hook up multiple configurations in premake.

If I use `conan install . -s built_type=Debug -if ./debug` to install Debug/Release builds into separate directories, then I end up with two `conanbuildinfo.premake.lua` files in two separate directories (debug and release).

If I then have this in premake5.lua:
```
include "debug/conanbuildinfo.premake.lua"
```

That'll include the debug configuration. But then what about the release configuration?

If I do this:

```
include "debug/conanbuildinfo.premake.lua"
include "release/conanbuildinfo.premake.lua"
```

Then I'm just loading two different tables on top of each other. Is this just not supported on premake, or am I doing something wrong?
Any help on this would be appreciated.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Zeenobit
labels: component: Build: Build helpers, build systems..
issue_6620: state: open
title: A sporadic import failure in the CI when adding a global hook
body: Prerequisite for the #6434 

When adding a hook execution into the api layer - a seemingly unrelated test started to fail with a failure to import a module stored in the `python` cache subfolder:
https://conan-ci.jfrog.info/blue/organizations/jenkins/ConanTestSuite/detail/PR-6434/1/pipeline

The test under question:
https://github.com/conan-io/conan/blob/develop/conans/test/functional/command/config_install_test.py#L187

I was able to reproduce the problem locally. Debugging shown that despite all files being identically present in both with and without the hook situations - the import is failing. Chipping the problem down shown that the problem is somehow related to the `_load_module_from_file` being present.

After some investigation, I discovered the https://docs.python.org/3/library/importlib.html#importlib.invalidate_caches - which sounds like the tool for the job since in tests we do append the `sys.path` with folders created within the same Python interpreter instance, which sounds pretty dynamic to me. 
Also, a nice write up on the problem: http://ballingt.com/import-invalidate-caches/

And it did fix the problem for the Python 3.8 interpreter. But it failed on Python 2.7 since it's not implemented in there and the Python 3.6, for some other weird reason. 

After additional investigation, I have found this Python issue: https://bugs.python.org/issue33169 

> Note that it's solved for Python 3.7+.

The most interesting to our use case note: 

> importlib.invalidate_caches() doesn't clear the negative cache in sys.path_importer_cache.

And indeed! At the moment when a sporadic import fails - the `path_import_cache` contains a `None` value for the temp folder key. Here is a description of how they have reproduced it:
https://github.com/python/mypy/pull/4811

In #6434 I copied the "fixed" cache invalidation from the 3.7+:
https://github.com/python/cpython/blob/521995205a2cb6b504fe0e39af22a81f785350a3/Lib/importlib/_bootstrap_external.py#L1180-L1186

And for Python 2.7 I've used the proposed solution from the issue above:
https://github.com/python/mypy/blob/a42ee8f0697439eac3a86644729750c472438b98/mypy/test/teststubgen.py#L147-L153

After that, we've got a green CI.

Sadly, I wasn't able to make a minimal example of the problem since the caching mechanism in Python is not known to me. So anyone interested would need to debug the #6434 (comment out the currently proposed solution for cache invalidation).

I'd welcome any helpful comments on that problem since I'm a bit out of my depth here and not a python expert, but this issue effectively blocks the global hook feature and is a potential sporadic failure for tests/python api in the future.
user: Minimonium
issue_6600: state: open
title: Removed '-l' option for libs with absolute paths in generators (issue 6598).
body: Changelog: Feature: libraries provided with absolute paths are stay unchanged (without `-l` option)
Docs: [conan-io/docs#1635](https://github.com/conan-io/docs/pull/1635)

closes https://github.com/conan-io/conan/issues/6598
user: DmitrySokolov
issue_6598: state: open
title: [question] Is there a way to use full lib path instead of `-lname`?
body: When I add
```python
self.cpp_info.libs = ["name"]
```
then on macOS it is transformed to the option `-lname`.

All works fine except when I use a dylib with non standard name scheme ("`name`.plugin" instead of "lib`name`.dylib"). Then I get the error "can not find ...".

I know that there is `-l:name` option but Apple binutils does not understand it.

CMake just generates the full lib path instead of `-lname`. So it can utilize it.

Is there a way to generate the full lib path in `conanbuildinfo.xxx` file?
user: DmitrySokolov
labels: component: Build: Build helpers, build systems..
issue_6590: state: open
title: [bug] conan upload silently fails under Jenkins+Cygwin
body: 
### Environment Details (include every applicable attribute)
  * Operating System+version: Cygwin
  * Conan version: 1.22.5
  * Python version: 3.6.4

In this case, the OS being `Cygwin` means that Conan itself is also running under cygwin (i.e. `bash.exe --login -c 'conan ...'`). 

This issue looks a lot like https://github.com/conan-io/conan/issues/6482, but I'm not sure if it's the same. We initially saw encountered this problem in 1.21. At that time, it reproduced consistently with Cygwin running under Jenkins (not sure running under Jenkins is relevant, but that was our setup). I have collected stdout and file trace logs for the same build under 1.21 and 1.20 (building the same code). 

At first, 1.22 appeared to fix the issue. I upgraded to that version and it worked for a while. But today we ran into the exact same problem: the upload never happened, and conan exited with success. Downgrading to 1.20.5 fixed it without any further changes.

The most telling difference is in the file trace. I filtered it to openssh (which is the only package we build under cygwin, plus it's few deps). 

Failing (1.21):
```
[2020-02-03T14:17:05.590Z] {"_action": "REST_API_CALL", "duration": 0.009240865707397461, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.21.0 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": "****"}, "method": "GET", "time": 1580738578.8075356, "url": "https://artifactory.plex.bz/api/conan/conan-toolchain/v1/conans/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/download_urls"}
[2020-02-03T14:17:05.591Z] {"_action": "REST_API_CALL", "duration": 0.010326862335205078, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.21.0 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": "****"}, "method": "GET", "time": 1580738579.1837754, "url": "https://artifactory.plex.bz/api/conan/groundzero-tamas/v1/conans/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/download_urls"}
[2020-02-03T14:17:05.591Z] {"_action": "REST_API_CALL", "duration": 0.010657072067260742, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.21.0 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********"}, "method": "GET", "time": 1580738579.1981165, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conanmanifest.txt"}
[2020-02-03T14:17:05.591Z] {"_action": "DOWNLOAD", "duration": 0.015249252319335938, "time": 1580738579.202694, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conanmanifest.txt"}
[2020-02-03T14:17:05.591Z] {"_action": "REST_API_CALL", "duration": 0.008887052536010742, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.21.0 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********"}, "method": "GET", "time": 1580738579.2143931, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conanfile.py"}
[2020-02-03T14:17:05.591Z] {"_action": "DOWNLOAD", "duration": 0.01274728775024414, "time": 1580738579.2182274, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conanfile.py"}
[2020-02-03T14:17:05.591Z] {"_action": "REST_API_CALL", "duration": 0.010356903076171875, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.21.0 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********"}, "method": "GET", "time": 1580738579.2314517, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conan_export.tgz"}
[2020-02-03T14:17:05.591Z] {"_action": "DOWNLOAD", "duration": 0.014285087585449219, "time": 1580738579.235362, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conan_export.tgz"}
[2020-02-03T14:17:05.591Z] {"_action": "DOWNLOADED_RECIPE", "_id": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2", "duration": 0.06731724739074707, "files": [{"md5": "f3bad2248ede8c5af390d7a00d534d12", "name": "conanmanifest.txt", "path": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conanmanifest.txt", "sha1": "3f63f6c196e32cc058df83037f33b44a9b31d83f"}, {"md5": "5c020a7c18d89a56e059741bb202c5cd", "name": "conanfile.py", "path": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conanfile.py", "sha1": "9609af2d78d9638062e0bd6b92ac3f580503ec41"}, {"md5": "7e53ba07679413603df3456c5a72a15c", "name": "conan_export.tgz", "path": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conan_export.tgz", "sha1": "42e6713cdfd9429815746ca4618e94739cbd6171"}], "remote": "groundzero_tamas", "time": 1580738579.2391472}
[2020-02-03T14:17:05.591Z] {"_action": "UNZIP", "dst": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export", "duration": 0.060858726501464844, "src": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conan_export.tgz", "time": 1580738579.3035808}
[2020-02-03T14:17:05.593Z] {"_action": "REST_API_CALL", "duration": 0.01094675064086914, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.21.0 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": "****"}, "method": "GET", "time": 1580738579.8804355, "url": "https://artifactory.plex.bz/api/conan/groundzero-tamas/v1/conans/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/packages/ef4c5aedc07cdc909328d54d6565559956d693c1/download_urls"}
[2020-02-03T14:17:05.595Z] {"_action": "REST_API_CALL", "duration": 0.07724595069885254, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.21.0 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********"}, "method": "GET", "time": 1580738963.4181142, "url": "https://artifactory.plex.bz/api/vcs/downloadCommit/github/plexinc/OpenSSH/18e041df?ext=tar.gz"}
[2020-02-03T14:17:05.595Z] {"_action": "DOWNLOAD", "duration": 0.09178543090820312, "time": 1580738963.432641, "url": "https://artifactory.plex.bz/api/vcs/downloadCommit/github/plexinc/OpenSSH/18e041df?ext=tar.gz"}
[2020-02-03T14:17:05.595Z] {"_action": "PACKAGE_BUILT_FROM_SOURCES", "_id": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2:ef4c5aedc07cdc909328d54d6565559956d693c1", "duration": 433.05545115470886, "log": null, "time": 1580739396.283095}
[2020-02-03T14:17:05.595Z] {"_action": "GOT_RECIPE_FROM_LOCAL_CACHE", "_id": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2", "time": 1580739400.0088563}
[2020-02-03T14:17:05.595Z] {"_action": "GOT_PACKAGE_FROM_LOCAL_CACHE", "_id": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2:ef4c5aedc07cdc909328d54d6565559956d693c1", "time": 1580739400.140658}
[2020-02-03T14:17:05.596Z] {"_action": "COMMAND", "name": "remove", "parameters": {"builds": [], "force": true, "outdated": false, "packages": null, "pattern": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2", "query": null, "remote_name": null, "src": true}, "time": 1580739419.7248826}
[2020-02-03T14:17:05.596Z] {"_action": "COMMAND", "name": "upload", "parameters": {"all_packages": false, "confirm": false, "integrity_check": false, "package": "ef4c5aedc07cdc909328d54d6565559956d693c1", "parallel_upload": false, "pattern": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2", "policy": null, "query": null, "remote_name": "groundzero_tamas", "retry": null, "retry_wait": null}, "time": 1580739424.9720063}
[2020-02-03T14:17:05.596Z] {"_action": "ZIP", "dst": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conan_export.tgz", "duration": 0.010573148727416992, "src": [{"md5": "85c3f00469d5511dd81d2b4734498534", "name": "001_no_default_dir_on_windows.patch", "path": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/001_no_default_dir_on_windows.patch", "sha1": "136895eb4559059a51a51459a4c34f91c308fd6a"}, {"md5": "7ee5df6e61526af733e3ccc60fc7ca43", "name": "002_sentinel_everywhere.patch", "path": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/002_sentinel_everywhere.patch", "sha1": "f0eb77089915c6a7a126ed790e37c3072ba437cb"}, {"md5": "3af9460a650c4234ba4c350beb918659", "name": "003_android_res_state.patch", "path": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/003_android_res_state.patch", "sha1": "607d7021e2f6c2a70e5024076086ef76f13d1235"}, {"md5": "5a1541b38d053aa92849899afc5e4cbd", "name": "004_android_explicit_bzero.patch", "path": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/004_android_explicit_bzero.patch", "sha1": "beaeae141dbb1142b09953e2d9ad624a790bc7e3"}, {"md5": "5f7763b8425635e084a76d56f7e6ad5a", "name": "005_cygwin_missing_base_types.patch", "path": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/005_cygwin_missing_base_types.patch", "sha1": "fc88ddee1106108965ca3e91f7b93be8399b20d6"}, {"md5": "9f6985829ca8ee35bb66a711d0916a76", "name": "res_state.h", "path": "/cygdrive/e/jenkins/conan_build/815076291/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/res_state.h", "sha1": "3a50a12c4009b9d689183b04865637b0203aab24"}], "time": 1580739425.0829282}
```

Successful (1.20):
```
[2020-02-03T14:43:59.076Z] {"_action": "REST_API_CALL", "duration": 0.005768775939941406, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": "****"}, "method": "GET", "time": 1580740507.3732202, "url": "https://artifactory.plex.bz/api/conan/conan-toolchain/v1/conans/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/download_urls"}
[2020-02-03T14:43:59.076Z] {"_action": "REST_API_CALL", "duration": 0.008071660995483398, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": "****"}, "method": "GET", "time": 1580740507.4374511, "url": "https://artifactory.plex.bz/api/conan/groundzero-tamas/v1/conans/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/download_urls"}
[2020-02-03T14:43:59.076Z] {"_action": "REST_API_CALL", "duration": 0.007833003997802734, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********"}, "method": "GET", "time": 1580740507.4486592, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conanmanifest.txt"}
[2020-02-03T14:43:59.076Z] {"_action": "DOWNLOAD", "duration": 0.011835098266601562, "time": 1580740507.452651, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conanmanifest.txt"}
[2020-02-03T14:43:59.077Z] {"_action": "REST_API_CALL", "duration": 0.010306835174560547, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********"}, "method": "GET", "time": 1580740507.4662387, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conanfile.py"}
[2020-02-03T14:43:59.077Z] {"_action": "DOWNLOAD", "duration": 0.013845682144165039, "time": 1580740507.4697607, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conanfile.py"}
[2020-02-03T14:43:59.077Z] {"_action": "REST_API_CALL", "duration": 0.008076667785644531, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********"}, "method": "GET", "time": 1580740507.4804044, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conan_export.tgz"}
[2020-02-03T14:43:59.077Z] {"_action": "DOWNLOAD", "duration": 0.012339591979980469, "time": 1580740507.4846547, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conan_export.tgz"}
[2020-02-03T14:43:59.077Z] {"_action": "DOWNLOADED_RECIPE", "_id": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2", "duration": 0.05913972854614258, "files": [{"md5": "f3bad2248ede8c5af390d7a00d534d12", "name": "conanmanifest.txt", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conanmanifest.txt", "sha1": "3f63f6c196e32cc058df83037f33b44a9b31d83f"}, {"md5": "5c020a7c18d89a56e059741bb202c5cd", "name": "conanfile.py", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conanfile.py", "sha1": "9609af2d78d9638062e0bd6b92ac3f580503ec41"}, {"md5": "7e53ba07679413603df3456c5a72a15c", "name": "conan_export.tgz", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conan_export.tgz", "sha1": "42e6713cdfd9429815746ca4618e94739cbd6171"}], "remote": "groundzero_tamas", "time": 1580740507.4883244}
[2020-02-03T14:43:59.077Z] {"_action": "UNZIP", "dst": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export", "duration": 0.01624894142150879, "src": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conan_export.tgz", "time": 1580740507.507938}
[2020-02-03T14:43:59.080Z] {"_action": "REST_API_CALL", "duration": 0.00798344612121582, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": "****"}, "method": "GET", "time": 1580740507.935169, "url": "https://artifactory.plex.bz/api/conan/groundzero-tamas/v1/conans/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/packages/ef4c5aedc07cdc909328d54d6565559956d693c1/download_urls"}
[2020-02-03T14:43:59.081Z] {"_action": "REST_API_CALL", "duration": 0.1058349609375, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********"}, "method": "GET", "time": 1580740705.1390157, "url": "https://artifactory.plex.bz/api/vcs/downloadCommit/github/plexinc/OpenSSH/18e041df?ext=tar.gz"}
[2020-02-03T14:43:59.081Z] {"_action": "DOWNLOAD", "duration": 0.14373302459716797, "time": 1580740705.1768987, "url": "https://artifactory.plex.bz/api/vcs/downloadCommit/github/plexinc/OpenSSH/18e041df?ext=tar.gz"}
[2020-02-03T14:43:59.081Z] {"_action": "PACKAGE_BUILT_FROM_SOURCES", "_id": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2:ef4c5aedc07cdc909328d54d6565559956d693c1", "duration": 306.77366495132446, "log": null, "time": 1580741011.7487624}
[2020-02-03T14:43:59.082Z] {"_action": "GOT_RECIPE_FROM_LOCAL_CACHE", "_id": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2", "time": 1580741014.5244992}
[2020-02-03T14:43:59.082Z] {"_action": "GOT_PACKAGE_FROM_LOCAL_CACHE", "_id": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2:ef4c5aedc07cdc909328d54d6565559956d693c1", "time": 1580741014.60218}
[2020-02-03T14:43:59.082Z] {"_action": "COMMAND", "name": "remove", "parameters": {"builds": [], "force": true, "outdated": false, "packages": null, "pattern": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2", "query": null, "remote_name": null, "src": true}, "time": 1580741031.4097357}
[2020-02-03T14:43:59.082Z] {"_action": "COMMAND", "name": "upload", "parameters": {"all_packages": false, "confirm": false, "integrity_check": false, "package": "ef4c5aedc07cdc909328d54d6565559956d693c1", "pattern": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2", "policy": null, "query": null, "remote_name": "groundzero_tamas", "retry": null, "retry_wait": null}, "time": 1580741036.2008681}
[2020-02-03T14:43:59.083Z] {"_action": "ZIP", "dst": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conan_export.tgz", "duration": 0.009544134140014648, "src": [{"md5": "85c3f00469d5511dd81d2b4734498534", "name": "001_no_default_dir_on_windows.patch", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/001_no_default_dir_on_windows.patch", "sha1": "136895eb4559059a51a51459a4c34f91c308fd6a"}, {"md5": "7ee5df6e61526af733e3ccc60fc7ca43", "name": "002_sentinel_everywhere.patch", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/002_sentinel_everywhere.patch", "sha1": "f0eb77089915c6a7a126ed790e37c3072ba437cb"}, {"md5": "3af9460a650c4234ba4c350beb918659", "name": "003_android_res_state.patch", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/003_android_res_state.patch", "sha1": "607d7021e2f6c2a70e5024076086ef76f13d1235"}, {"md5": "5a1541b38d053aa92849899afc5e4cbd", "name": "004_android_explicit_bzero.patch", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/004_android_explicit_bzero.patch", "sha1": "beaeae141dbb1142b09953e2d9ad624a790bc7e3"}, {"md5": "5f7763b8425635e084a76d56f7e6ad5a", "name": "005_cygwin_missing_base_types.patch", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/005_cygwin_missing_base_types.patch", "sha1": "fc88ddee1106108965ca3e91f7b93be8399b20d6"}, {"md5": "9f6985829ca8ee35bb66a711d0916a76", "name": "res_state.h", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/res_state.h", "sha1": "3a50a12c4009b9d689183b04865637b0203aab24"}], "time": 1580741036.3125594}
[2020-02-03T14:43:59.083Z] {"_action": "REST_API_CALL", "duration": 0.012722969055175781, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": "****"}, "method": "GET", "time": 1580741036.4030151, "url": "https://artifactory.plex.bz/api/conan/groundzero-tamas/v1/conans/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/digest"}
[2020-02-03T14:43:59.083Z] {"_action": "REST_API_CALL", "duration": 0.010383844375610352, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********"}, "method": "GET", "time": 1580741036.416754, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conanmanifest.txt"}
[2020-02-03T14:43:59.084Z] {"_action": "DOWNLOAD", "duration": 0.014664649963378906, "time": 1580741036.4210176, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/export/conanmanifest.txt"}
[2020-02-03T14:43:59.084Z] {"_action": "REST_API_CALL", "duration": 0.01271200180053711, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": "****"}, "method": "GET", "time": 1580741036.4562411, "url": "https://artifactory.plex.bz/api/conan/groundzero-tamas/v1/conans/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2"}
[2020-02-03T14:43:59.084Z] {"_action": "UPLOADED_RECIPE", "_id": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2", "duration": 0.16443800926208496, "files": [{"md5": "5c020a7c18d89a56e059741bb202c5cd", "name": "conanfile.py", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conanfile.py", "sha1": "9609af2d78d9638062e0bd6b92ac3f580503ec41"}, {"md5": "f3bad2248ede8c5af390d7a00d534d12", "name": "conanmanifest.txt", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conanmanifest.txt", "sha1": "3f63f6c196e32cc058df83037f33b44a9b31d83f"}, {"md5": "7e53ba07679413603df3456c5a72a15c", "name": "conan_export.tgz", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/export/conan_export.tgz", "sha1": "42e6713cdfd9429815746ca4618e94739cbd6171"}], "remote": "groundzero_tamas", "time": 1580741036.4623208}
[2020-02-03T14:43:59.086Z] {"_action": "ZIP", "dst": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/package/ef4c5aedc07cdc909328d54d6565559956d693c1/conan_package.tgz", "duration": 1.6640596389770508, "src": [{"md5": "625ed4c68e01bc6bc8733a3771325ae3", "name": "bin/cygwin1.dll", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/package/ef4c5aedc07cdc909328d54d6565559956d693c1/bin/cygwin1.dll", "sha1": "de42359df098699d318268aa3e6fe5a4021a84f2"}, {"md5": "77d2a3cdd6effdb65215291f2b13bdb7", "name": "bin/Plex Relay.exe", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/package/ef4c5aedc07cdc909328d54d6565559956d693c1/bin/Plex Relay.exe", "sha1": "bc86e7b2705c34f1a52b7e50a590895bb35f2ce3"}], "time": 1580741038.1766496}
[2020-02-03T14:43:59.086Z] {"_action": "REST_API_CALL", "duration": 0.011393070220947266, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": "****"}, "method": "GET", "time": 1580741038.2265425, "url": "https://artifactory.plex.bz/api/conan/groundzero-tamas/v1/conans/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/packages/ef4c5aedc07cdc909328d54d6565559956d693c1"}
[2020-02-03T14:43:59.086Z] {"_action": "REST_API_CALL", "duration": 0.008954524993896484, "headers": {"Accept": "application/json", "Authorization": "**********", "Content-type": "application/json", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Client-Anonymous-Id": "**********", "X-Client-Id": "****"}, "method": "POST", "time": 1580741038.2432277, "url": "https://artifactory.plex.bz/api/conan/groundzero-tamas/v1/conans/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/packages/ef4c5aedc07cdc909328d54d6565559956d693c1/upload_urls"}
[2020-02-03T14:43:59.086Z] {"_action": "REST_API_CALL", "duration": 0.009375333786010742, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Checksum-Deploy": "true", "X-Checksum-Sha1": "bf62abdf3227681bca3449c69fe3969d53ddcdc9", "X-Client-Anonymous-Id": "**********"}, "method": "PUT", "time": 1580741038.2637742, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/package/ef4c5aedc07cdc909328d54d6565559956d693c1/0/conan_package.tgz"}
[2020-02-03T14:43:59.087Z] {"_action": "REST_API_CALL", "duration": 0.2784135341644287, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Checksum-Sha1": "bf62abdf3227681bca3449c69fe3969d53ddcdc9", "X-Client-Anonymous-Id": "**********"}, "method": "PUT", "time": 1580741038.5455039, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/package/ef4c5aedc07cdc909328d54d6565559956d693c1/0/conan_package.tgz"}
[2020-02-03T14:43:59.087Z] {"_action": "REST_API_CALL", "duration": 0.010904312133789062, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Checksum-Deploy": "true", "X-Checksum-Sha1": "79034f61200ef2c850f34a27239e1605c07d342a", "X-Client-Anonymous-Id": "**********"}, "method": "PUT", "time": 1580741038.5616162, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/package/ef4c5aedc07cdc909328d54d6565559956d693c1/0/conaninfo.txt"}
[2020-02-03T14:43:59.087Z] {"_action": "REST_API_CALL", "duration": 0.09313797950744629, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Checksum-Sha1": "79034f61200ef2c850f34a27239e1605c07d342a", "X-Client-Anonymous-Id": "**********"}, "method": "PUT", "time": 1580741038.6595597, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/package/ef4c5aedc07cdc909328d54d6565559956d693c1/0/conaninfo.txt"}
[2020-02-03T14:43:59.087Z] {"_action": "REST_API_CALL", "duration": 0.008594989776611328, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Checksum-Deploy": "true", "X-Checksum-Sha1": "a030a835f8a9eeee2a05a0da34e7eda03dbaef9b", "X-Client-Anonymous-Id": "**********"}, "method": "PUT", "time": 1580741038.673023, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/package/ef4c5aedc07cdc909328d54d6565559956d693c1/0/conanmanifest.txt"}
[2020-02-03T14:43:59.087Z] {"_action": "REST_API_CALL", "duration": 0.022161006927490234, "headers": {"Authorization": "**********", "User-Agent": "Conan/1.20.3 (Python 3.6.9) python-requests/2.22.0", "X-Checksum-Sha1": "a030a835f8a9eeee2a05a0da34e7eda03dbaef9b", "X-Client-Anonymous-Id": "**********"}, "method": "PUT", "time": 1580741038.6985428, "url": "https://artifactory.plex.bz:443/artifactory/api/conan/groundzero-tamas/v1/files/tamas/openssh/8.1p1-18e041df-1/openssl_upgrade2/0/package/ef4c5aedc07cdc909328d54d6565559956d693c1/0/conanmanifest.txt"}
[2020-02-03T14:43:59.087Z] {"_action": "UPLOADED_PACKAGE", "_id": "openssh/8.1p1-18e041df-1@tamas/openssl_upgrade2:ef4c5aedc07cdc909328d54d6565559956d693c1", "duration": 2.2349183559417725, "files": [{"md5": "4983e3de3f140a9daf4a776f2a7d8e04", "name": "conan_package.tgz", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/package/ef4c5aedc07cdc909328d54d6565559956d693c1/conan_package.tgz", "sha1": "bf62abdf3227681bca3449c69fe3969d53ddcdc9"}, {"md5": "a178b469c6152dc92fefefc2aa0d7c16", "name": "conaninfo.txt", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/package/ef4c5aedc07cdc909328d54d6565559956d693c1/conaninfo.txt", "sha1": "79034f61200ef2c850f34a27239e1605c07d342a"}, {"md5": "656ad2062569fdbf0104f9764e3ec748", "name": "conanmanifest.txt", "path": "/cygdrive/e/jenkins/conan_build/815141828/conan/.conan/data/openssh/8.1p1-18e041df-1/tamas/openssl_upgrade2/package/ef4c5aedc07cdc909328d54d6565559956d693c1/conanmanifest.txt", "sha1": "a030a835f8a9eeee2a05a0da34e7eda03dbaef9b"}], "remote": "groundzero_tamas", "time": 1580741038.72245}
```

### Logs (Executed commands with output) (Include/Attach if Applicable)

[cygwin_success_trace.txt](https://github.com/conan-io/conan/files/4257019/cygwin_success_trace.txt)
[cygwin_success_stdout.txt](https://github.com/conan-io/conan/files/4257020/cygwin_success_stdout.txt)
[cygwin_failing_trace.txt](https://github.com/conan-io/conan/files/4257021/cygwin_failing_trace.txt)
[cygwin_failing_stdout.txt](https://github.com/conan-io/conan/files/4257022/cygwin_failing_stdout.txt)

We can probably still reproduce it with 1.21 at least (because nothing else changed in our environment). We are able to run arbitrary branches of conan on our CI, so if you add some extra logging around suspicious parts on a branch, we can gather more detailed logs. 
user: sztomi
issue_6589: state: open
title: [question] CI pipeline with conan and repackaging with new version
body: We are trying to come with a proper way to integrate conan in our CI pipeline. 

The current idea is something like this:
Note: using a single profile for brevity.
- Automated steps (performed on CI):
  1. Generate version number: `v1.2.3-rc.1.#build_counter` (mind the suffixes).
  1. Generate `.lock` file for the profile.
  1. Build the package using the `.lock` file and publish it to a separate conan `ci testing repo` for testing (seems to be the recommended way - https://github.com/conan-io/conan/issues/6191#issuecomment-565013853).
  1. Test the published package from `ci testing repo` (i.e. tests that are performed on CI) and copy it to conan `main repo` if successful .
- Manual steps (performed outside of CI):
  1. Perform additional testing on this published package (QA and etc).
  1. If additional testing passed successfully, promote the package to a release build by republishing package as a `v1.2.3` (without additional suffixes)

All these steps are (seemingly) doable, except for the last one.

So, the questions :)

1. Does this workflow conform to the (theoretical) canonical `conan` way?
2. Is there a way to perform the last step using `conan` (that is without manually hacking the published package)?

Thanks in advance!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: TheQwertiest
issue_6588: state: open
title: [bug] tools.unzip() doesn't preserve symlinks
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: Centos 7.4
  * Compiler+version: 
  * Conan version: 1.22.2
  * Python version: 3.6.8

### Steps to reproduce (Include if Applicable)
Create a zip file containing symlinks and attempt to extract it with the tools.unzip() method in a conan recipe.

**In recipe:**
def source(self):
    zip_name = "somezipfile.zip"
    unzip(zip_name)

**From shell**
conan source .

In doing this I observe the symlinks are broken.

user: carobins
issue_6546: state: open
title: [bug] cross compilation is not properly detected
body: I was trying to cross compile from linux x86_64 to linux arm32.
The toolchain and sysroot are conan packages. The two conanfiles setting the package_info:
```
self.env_info.path.append(os.path.join(self.package_folder, "bin"))
self.env_info.CC = os.path.join(self.package_folder, "bin", "arm-linux-gnueabihf-gcc").replace("\\", "/")
self.env_info.CXX = os.path.join(self.package_folder, "bin", "arm-linux-gnueabihf-g++").replace("\\", "/")
self.env_info.AR = os.path.join(self.package_folder, "bin", "arm-linux-gnueabihf-ar").replace("\\", "/")
self.env_info.RANLIB = os.path.join(self.package_folder, "bin", "arm-linux-gnueabihf-ranlib").replace("\\", "/")
self.env_info.STRIP = os.path.join(self.package_folder, "bin", "arm-linux-gnueabihf-strip").replace("\\", "/")
```
```
self.env_info.SYSROOT = self.package_folder
self.env_info.CMAKE_SYSROOT = self.package_folder
self.env_info.CONAN_CMAKE_FIND_ROOT_PATH = self.package_folder
self.env_info.CONAN_CMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "NEVER"
```

I expected to get the content of the CONAN_CMAKE_FIND_ROOT_PATH variable available in the cmake file. It is not the case.

My configuration is the following:
```
Configuration:
[settings]
arch=armv7hf
arch_build=x86_64
build_type=Debug
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
os_build=Linux
[options]
[build_requires]
*: armv7hf-linux-toolchain/2019.03-sqp1@tools/testing, am57xx-sysroot/06.02.00.81-sqp1@tools/testing
[env]
```


After a quick look at the conan source, I found an issue in the `client/build/cmake_flags.py`:

```
def _cmake_cross_build_defines(self):
...
        # System name and system version
        if cmake_system_name is not True:  # String not empty
            definitions["CMAKE_SYSTEM_NAME"] = cmake_system_name
        else:  # detect if we are cross building and the system name and version
            if cross_building(self._conanfile.settings):  # We are cross building
                if os_ != os_build:
                    if os_:  # the_os is the host (regular setting)
                        definitions["CMAKE_SYSTEM_NAME"] = {"iOS": "Darwin",
                                                            "tvOS": "Darwin",
                                                            "watchOS": "Darwin",
                                                            "Neutrino": "QNX"}.get(os_, os_)
                    else:
                        definitions["CMAKE_SYSTEM_NAME"] = "Generic"
...
if definitions:  # If enabled cross compile
```
In my case, `cross_building(self._conanfile.settings)` returns `True`. In the next line it detects host and target os is the same (`if os_ != os_build:`). So it is not setting the `definitions["CMAKE_SYSTEM_NAME"]`. Later in the code it detects if cross compilation is enabled, by `if definitions:`. Since it never sets a single definition above, the check if we are cross compilation fails and the definitions are empty. My sugesstion is to change the following line:
```
if os_ != os_build:
```
to something like
```
if os_ != os_build or arch_ != arch_build:
```

Currently I have a workaroung and force the cross compilation detection by setting:
`self.env_info.CONAN_CMAKE_SYSTEM_NAME = "Linux"`

### Environment Details (include every applicable attribute)
  * Operating System+version: Linux
  * Compiler+version: GCC 8.3
  * Conan version: 1.22.2
  * Python version: 3.7.3


user: sct2010
labels: component: Build: Build helpers, build systems..
issue_6530: state: open
title: [feature] Handle library loops (--start-group, --end-group)
body: It seems that going from `v1.21` to `v1.22`, the library ordering specified in `self.cpp_info.libs` is no longer maintained. Is this true or am I missing something?

The package I'm creating depends on Intel MKL, which requires a specific linking ordering as well as `-Wl,--start-group` and `-Wl,--end-group` surrounding the MKL libraries being linked to. I have the ordering specified in a [Bintray package for MKL](https://bintray.com/nheri-simcenter/simcenter/mkl-static%3Asimcenter) which was working fine for `v1.21`. When updating to `v1.22`, the ordering specified for the libraries in the `conanfile.py` for MKL is no longer maintained, so linking fails. 

Is there a way to force `conan` to maintain the ordering or what is the best way to deal with this? Seems like this issue is related to #6510. 
user: shellshocked2003
labels: component: Build: Build helpers, build systems..
issue_6510: state: open
title: [question] Build order inconsistency?
body: I'm seeing an inconsistency with `conan graph build-order`. Sometimes the package I'm obtaining the build-order for is itself included in the build order (as the last item) which is very convenient/preferred for my Jenkins code, but sometimes the package is not included.

[libA, libB, libC, appX]
vs.
[libA, libB, libC]

In fact, the reason I discovered #6482 while trying 1.22.0 for the first time is because the `conan upload` failure was happening for the final item in the build-order, "appX". Tonight, I'm seeing cases where appX is left out of the build-order and a new graph is not detecting that appX needs to be built. If I make an appY that depends on a component of appX - the build-order for appY does detect the need to rebuild appX so it feels like something is wrong.

I don't recall ever seeing this inconsistency on 1.21.x 

Was there an intentional change related to build-order sometimes excluding the package you are requesting the build-order for?

Thanks


user: radonish
issue_6493: state: open
title: [bug] workspace install fails for editable package requirement
body: Dear conan dev-team,

it seems that there is a problem with workspace install and editable package dependencies outside the workspace yml scope:

If a package is marked as editable but has not been created yet and is required by a workspace package, the workspace install fails. However, a create without the workspace succeeds and resolves the editable properly.

I'd be glad if you could have a look into this, because editable packages in combination with workspaces would be really great for our use cases. Or please tell me if I'm missing something.

Thank you for your efforts and keep up the great work!
Dieter

<!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details
  * Operating System+version: Windows 10 - 64
  * Compiler+version: VS2019 64 16.4.3
  * Conan version: 1.22.0
  * Python version: 3.7.4

### Steps to reproduce

The minimal example is:

conanws.yml:
```
editables:
  libB/0.1@user/testing:
    path: libB
root: libB/0.1@user/testing
```
conanfile.py - libB
```
from conans import ConanFile
class Pkg(ConanFile):
    name = "libB"
    version = "0.1"
    requires = "libA/0.1@user/testing"
```
conanfile.py - libA
```
from conans import ConanFile
class Pkg(ConanFile):
    name = "libA"
    version = "0.1"
```

And to reproduce one should run:
```conan editable add libA libA/0.1@user/testing```
```conan workspace install ./conanws.yml -if=build```
```conan create libB libB/0.1@user/testing```

### Logs

```
(base) D:\test\Test>conan editable add libA libA/0.1@user/testing
Reference 'libA/0.1@user/testing' in editable mode
```

```
(base) D:\test\Test>conan workspace install ./conanws.yml -if=build
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

libA/0.1@user/testing: Not found in local cache, looking in remotes...
libA/0.1@user/testing: Trying with 'stable'...
libA/0.1@user/testing: Trying with 'testing'...
ERROR: Failed requirement 'libA/0.1@user/testing' from 'libB/0.1@user/testing'
ERROR: Unable to find 'libA/0.1@user/testing' in remotes
```

```
(base) D:\test\Test>conan create libB libB/0.1@user/testing
Exporting package recipe
libB/0.1@user/testing: A new conanfile.py version was exported
libB/0.1@user/testing: Folder: D:\conan\data\libB\0.1\user\testing\export
libB/0.1@user/testing: Using the exported files summary hash as the recipe revision: 0d0fa749d5af77a2bb7fc8521f68be26
libB/0.1@user/testing: Exported revision: 0d0fa749d5af77a2bb7fc8521f68be26
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

libB/0.1@user/testing: Forced build from source
Installing package: libB/0.1@user/testing
Requirements
    libB/0.1@user/testing from local cache - Cache
    libA/0.1@user/testing from user folder - Editable
Packages
    libB/0.1@user/testing:a33d2a41fa6144f9c952fca973296c498ac6c025 - Build
    libA/0.1@user/testing:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Editable

libB/0.1@user/testing: Configuring sources in D:\conan\data\libB\0.1\user\testing\source
libB/0.1@user/testing: Copying sources to build folder
libB/0.1@user/testing: Building your package in D:\conan\data\libB\0.1\user\testing\build\a33d2a41fa6144f9c952fca973296c498ac6c025
libB/0.1@user/testing: Generator txt created conanbuildinfo.txt
libB/0.1@user/testing: Calling build()
libB/0.1@user/testing: WARN: This conanfile has no build step
libB/0.1@user/testing: Package 'a33d2a41fa6144f9c952fca973296c498ac6c025' built
libB/0.1@user/testing: Build folder D:\conan\data\libB\0.1\user\testing\build\a33d2a41fa6144f9c952fca973296c498ac6c025
libB/0.1@user/testing: Generated conaninfo.txt
libB/0.1@user/testing: Generated conanbuildinfo.txt
libB/0.1@user/testing: Generating the package
libB/0.1@user/testing: Package folder D:\conan\data\libB\0.1\user\testing\package\a33d2a41fa6144f9c952fca973296c498ac6c025
libB/0.1@user/testing: Calling package()
libB/0.1@user/testing: WARN: This conanfile has no package step
libB/0.1@user/testing package(): WARN: No files in this package!
libB/0.1@user/testing: Package 'a33d2a41fa6144f9c952fca973296c498ac6c025' created
libB/0.1@user/testing: Created package revision 1635868393f79695daa8994c30e40704
```
user: burgerkiller79
issue_6472: state: open
title: [feature] Support more advanced matching of packages/recipies in profiles
body: It would be great if the matching of packages in profiles for the settings and build_requires would be more powerful. I have the following use case in mind:

I need a relatively new compiler (gcc9) but want to support operating systems that don't have that compiler (such as older Linux distributions). I want to build the compiler with conan, especially because the compiler has some dependencies (gmp etc.).

My initial idea was to use a separate profile for building the compiler toolchain, and then another profile for the rest of the software. That does work, but conan will never be able to automatically resolve dependencies unless a pre-built version of the compiler is already in the cache or on the remote, which can make upgrading the compiler (especially across architectures) rather painful, as a different profile must explicitly be specified.

On the other hand, if I could just have the default profile to have a build_requires + the relevant settings only for all packages **except** the toolchain packages, conan could automatically do the right thing.

The workflow for setting up a new system would then be:

 - Run `conan profile new --detect system` to create a profile that uses the system compiler
 - Copy the profile with the correct settings for the toolchain to `.conan/profiles/default`
 - Add the proper conan remotes
 - Run `conan install --build=missing` and have it automatically do the right thing

I made a first draft attempt for this feature and pushed it to the following branch:
https://github.com/chris-se/conan/tree/build-requires-matchers
This adds the following new features to the profile:

 - Add a new section `[package_matchers]` where one can define groups of packages.
 - Add support for referencing these matchers with the syntax `$match{NAME}`
 - Add support for prefixing patterns in `[build_requires]` and `[settings]` with an exclamation point to invert the match (all packages that are NOT matched)

I haven't opened a pull request yet because I wanted to get feedback first on the syntax and details of it. The proof of concept works, and my `default` profile looks like the following:

    include(system)

    [settings]
    !$match{toolchain}:os=Linux
    !$match{toolchain}:os_build=Linux
    !$match{toolchain}:arch=x86_64
    !$match{toolchain}:arch_build=x86_64
    !$match{toolchain}:compiler=gcc
    !$match{toolchain}:compiler.version=9
    !$match{toolchain}:compiler.libcxx=libstdc++11
    !$match{toolchain}:build_type=Release

    [build_requires]
    !$match{toolchain}: gcc/9.2.0@user/channel

    [package_matchers]
    toolchain = gcc/*, *-for-gcc/*

I'm open to changing the syntax and/or the details of this, this is primarily just a proof of concept. I'll send a pull request (+ also one for the documentation) once this has been ironed out.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: chris-se
issue_6461: state: open
title: [bug] wrong host arch on Autotools build helper for QNX
body: Coming from https://github.com/conan-io/conan-center-index/pull/573

Seems Conan 1.21 is failing to correctly set the flags for host architecture con QNX neutrino.

user: danimtb
issue_6460: state: open
title: [bug] Top-level recipe is left out of build-order
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Debian 10
  * Conan version: develop (commit ebcfe5839b37955bd411d9122cfbfb3bc60e9a83)
  * Python version: 3.7.6

### Steps to reproduce (Include if Applicable)

The STR are in the zip file (note that installing `path.py` and `cli_ui` is an additional requirement)

### Logs (Executed commands with output) (Include/Attach if Applicable)

Note the line 876 of attached log:

>[[('2', 'sqlcipher/4.2.0#c8d883dc3485544775b48fe577fd7fed:0cb0e7660695e4448219e90b31c01821ab150113')]]

I'd expect the build-order to also contain the top-level recipe.
[log.txt](https://github.com/conan-io/conan/files/4148208/log.txt)

user: theodelrieu
issue_6440: state: open
title: [bug] PKG Config approach 5 not working
body: ### Environment Details (include every applicable attribute)
  * Ubuntu 18.04
  * gcc7.0:
  * 1.20.0:
  * 3.6:

### Steps to reproduce (Include if Applicable)
make a test package
add the `generators = "pkg_config"`
print out the enironment variable.
The PKG_CONFIG_PATH has not added the build folder of the package
see here:
https://docs.conan.io/en/latest/integrations/build_system/pkg_config_pc_files.html#approach-5-use-the-pkg-config-generator
> # When using the pkg_config generator, self.build_folder will be added to PKG_CONFIG_PATH
>         # so pkg_config will be able to locate the generated pc files from the requires (LIB_A)
Please provide a workarround.

user: derived-coder
issue_6423: state: open
title: Global Hooks: For running a hook any time a Conan command is executed.
body: We are performing a version check in our organization to ensure everyone is kept up to date on the latest version of Conan (based on our own validation of that version). We are doing this through a custom hook that checks the current Conan version once a day. Currently we can only perform that version check at the package level because hooks currently only work at this level. This means we must rely on certain triggers, like the downloading of a package in order to execute our hook.

A more global hook would be extremely helpful to keep for us and might have other use cases for us in the future. This hook could be "global()" or "pre_conan()" and execute any time a Conan command is issued.

user: carobins
labels: component: hook: Related stuff: implementation and features
issue_6419: state: open
title: [question] Conan + Artifactory + Azure DevOps
body: We are moving our CI/CD to Azure DevOps. To store our artifacts we are planning  to use Artifactory Cloud.  I've read the [Conan documentation](https://docs.conan.io/en/latest/integrations/ci/azure_devops.html)  and it seems possible. 
> To use the Conan support provided by the JFrog Artifactory Extension you must configure a **self-hosted agent** that will enable Conan builds for your Azure Pipelines  environment.

But we want to use only **Microsoft-hosted agents**.

1. Maybe is it possible to use Microsoft-hosted agents after all?
2. If not, can I upload Conan packages to Nexus or Azure artifacts generic repo?
3. If not, maybe you have other suggestions?




- [ x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: dmn-star
issue_6411: state: open
title: [feature] Add a way to not apply a build requirement to other build requirements
body: Hello,

After making some changes to a cross-build toolchain of mine, I wanted to try compiling the whole dependency graph locally, before pushing the changes upstream.

Therefore I went to the top-level directory and ran `conan install -pr myprofile --build`.
The problem is that the cross-build toolchain exposes environment flags such as `CXXFLAGS`.

It does work as expected for `requirements`, but it fails with other `build requirements`!

For instance, `boost/1.71` from CCI build requires `b2/4.0`, and passing `--build` triggers a build of `b2`, which is being built with the `CXXFLAGS` exposed in the cross-build toolchain...

After browsing the docs about build requirements declared in profiles, it seems there is no way to express the following:

> Apply this package to all consumers *BUT* other build requirements

And I think it should be added 😄 

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: theodelrieu
issue_6408: state: open
title: [question] Hardlocked options and diamonds
body: Related to https://github.com/conan-io/conan/issues/3524, https://github.com/conan-io/conan/issues/5530

It's explicitly allowed to hardcode dependencies' options [in the documentation](https://docs.conan.io/en/latest/mastering/conditional.html?highlight=default_options#conditional-settings-options-and-requirements).

Alternatively, it's encouraged to use `default_options`. But it becomes a problem comically fast as this test shows:
https://github.com/conan-io/conan/blob/develop/conans/test/unittests/model/transitive_reqs_test.py#L1063

@Morwenn has provided us in the Slack with a great minimal example of a conflict of hardlocked options in subgraphs:
```python
from conans import ConanFile

class LibFirstConan(ConanFile):
    name = "zero"
    version = "1.0.0"
    description = "Zero library"
```
```python
from conans import ConanFile

class LibFirstConan(ConanFile):
    name = "first"
    version = "1.0.0"
    description = "First library"

    options = {"with_zero": [True, False]}
    default_options = {"with_zero": True}

    def requirements(self):
        if self.options.with_zero:
            self.requires("zero/1.0.0@")
```
```python
from conans import ConanFile

class LibSecondConan(ConanFile):
    name = "second"
    version = "1.0.0"
    description = "Second library"

    options = {"with_first": [True, False]}
    default_options = {"with_first": False}

    def configure(self):
        if self.options.with_first:
            self.options["first"].with_zero = False

    def requirements(self):
        if self.options.with_first:
            self.requires("first/1.0.0@")
```
```python
from conans import ConanFile

class LibThirdConan(ConanFile):
    name = "third"
    version = "1.0.0"
    description = "Third library"

    def configure(self):
        self.options["second"].with_first = True

    def requirements(self):
        self.requires("first/1.0.0@")
        self.requires("second/1.0.0@")
```
```bash
conan export zero
conan export first
conan export second
conan create third
```
Depending on the order of requirements in the `third/1.0.0@` we get the diamond error, although in the whole graph we do have only one set of hardlocked options, which in this case was unexpected for the user.

It highlights issues with the runtime graph construction and in-recipe external configuration modifications _and_ preferences (not only settings but external options too). It's practically impossible to dynamically alter other subgraphs from a parallel subgraph and in a sequential solution, we'd have an unreliable build. 

The question is - what should we do with recommendations for that in the documentation?
user: Minimonium
issue_6405: state: open
title: [feature] --target argument for conan build
body: Following the broader discussion in #5553 i suggest the following feature mainly relevant for CI but also for local development:
For doing "non-standard" builds like generating documentation output or running a static code analysis people usually create optional build targets in the used build system, e.g. CMake.

As there is most probably no need to include the generated files in the Conan packages, the build is done with `conan install && conan build` in the userspace to easily access the files for uploading, archiving, .... To avoid having to call the underlying build system directly in the CI builds (may also be used locally by developers so they do not have to run `activate.bat` and call CMake directly with all required parameters), the actual build target could be passed directly with e.g. `conan build --target docs` to the build() method, similar to the `--configure`, `--build`, `--test` flags and the respective attributes.

This would avoid having to add dedicated options for all these "non-standard" builds in the conanfile.py which are not used for package creation anyway.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: petermbauer
issue_6391: state: open
title: [question] How to handle different versions of the same requirement
body: Hi,

  I'm facing this problem especially with Qt (but the same problem applies to other libs as well e.g. openssl).
Let's take an example to be easier to understand:
I want to create a package for [kuesa](https://github.com/KDAB/kuesa). The problem is that the **same** kuesa version can be built with multiple Qt versions (e.g. 5.12.x, 5.13.x, 5.14.x), but depending on what qt version you build it, it will enable different features (e.g. kuesa built with qt 5.14 will have more features than kuesa built with 5.12).

The problem comes when application A requires Qt 5.12 and kuesa 1.0 and application B requires Qt 5.14 and kuesa 1.0. How to tell conan to download kuesa **1.0** built with Qt 5.12 for application A and kuesa **1.0** built with qt 5.14 for application B?

What is the best solution to handle this situation?

I explored a few solutions, but all of them have some disadvantages:

1. add qt version to the package naming <PkgName>/version@user/channel:
  1.a. add qt version to the package version: kuesa/0.10.0-qt_5.12@user/channel
  1.b use different channels for each qt version: kuesa/0.10.0@user/qt_5.12

**Pro:**
- the qt version is explicit in the package name

**Con:**
- will be challenging to create and maintain `conanfile.txt` (and `conanfile.py`) as we need to change these files to specify which qt version we like to use for each package (unless there is a way to use placeholders in both `conanfile.txt` and `conanfile.py`).

2. add qt version to conan settings and to profiles

**Pro:**
- no changes are need to be done to `conanfile.txt` nor to `conanfile.py` !

**Con:**
-  local changes are needed to `settings.yml` for **each** problematic package and we need a profile for **each** combination (can be easily handled using conan config install).

3. add qt version to package options

**Pro:**
- no changes are needed to `settings.yml` nor to `profiles`
- no changes are needed to `conanfile.py` besides the followings:
```
class KuesaConan(ConanFile):
    name = "Kuesa"
# ...
    options = {"shared": [True, False], "qt":"ANY"}
    default_options = {"shared": True, "qt": "5.12"} # instead of "5.12" we can use an env var ;-)
```

**Con:**
-  same as option **1**, we need to specify for **each** package the qt version in the conanfile.txt (in the options section)
```
[requires]
kuesa/0.10.0@user/channel
[options]
kuesa:qt="5.12" # here it will be great if we can use a placeholder instead of "5.12"
```

- Even worst, I didn't find a way to specify the required packages options in the conanfile.py.
```
class OtherPackageConan(ConanFile):
    name = "OtherPackage"
# ...
   requires = "kuesa/0.10.0"    # How do I specify options for the requires packages?
```


Is there a better solution that I missed?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: bog-dan-ro
issue_6388: state: open
title: [bug] [windows] Mojibakes in msbuild output
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows 8.1 x64
  * Compiler+version: Visual Studio 2017's cl.exe ver 19.16.27034
  * Conan version: 1.21.1
  * Python version: same as in bundled installer from conan.io/download 
  * Visual Studio 2017 also uses Russian Language Pack (which affects msbuild/cl/link output);

### Steps to reproduce (Include if Applicable)
1. Try to compile any project with any warnings from MSBuild

Thank you for your project and your work!

user: leha-bot
issue_6387: state: open
title: [question] Using conan for packaging libraries with multiple configurations
body: I am working on a cross-platform C++ project, exploring if we can use Conan to manage our library dependencies. Each library is pre-built and has the following folder structure.
```
MyLib/
├── Lib
│   ├── Mac
│   │   ├── Debug
│   │   │   └── x86_64
│   │   │       └── MyLib.a
│   │   └── Release
│   │       └── x86_64
│   │           └── MyLib.a
│   └── Win
│       ├── Debug
│       │   ├── Win32
│       │   │   └── MyLib.lib
│       │   └── x86_64
│       │       └── MyLib.lib
│       └── Release
│           ├── Win32
│           │   └── MyLib.lib
│           └── x86_64
│               └── MyLib.lib
└── include
    └── *.h
```
We have multiple Xcode and Visual Studio projects (not generated using CMake) that consume these libraries. 
What is the best way to package these libraries such that I can switch between the Debug/Release or Win32/X64 configurations in Xcode/Visual Studio without having to run Conan again?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: nangalvivek
issue_6384: state: open
title: [feature] Add multiarch(any?) arch option to settings.yml
body: This feature is very useful (mostly?) for Android as it supports multiple ABIs in the same apk/aab.

Starting with Qt 5.14.0, Qt for Android provides a way to build the apps for all Android ABIs in one go, and without a `multiarch/Any/None` in arch settings it's impossible to create an Android multilib Qt package for conan.

user: bog-dan-ro
issue_6372: state: open
title: [bug] run_in_windows_bash fails to propagate exit code
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details
  * Operating System+version: Windows Server 2016 + cygwin 2.9.0
  * Compiler+version: N/A
  * Conan version: 1.21.0
  * Python version: 3.6.6

### Steps to reproduce
Create a file _build_:
```
#!/bin/bash

exit 1
```
Create a file _conanfile.py_
```
from conans import ConanFile, tools

class MyConanFile(ConanFile):
    name = 'MyProduct'
    version = '1.0'

    def build(self):
        if tools.os_info.is_windows:
            tools.run_in_windows_bash(self, './build')
        else:
            self.run('./build')
```
In Cygwin shell, execute:
```
chmod +x build
conan install .
conan build .
echo $?
```
**Expected behaviour:** the exit code is 1
**Actual behaviour:** the exit code is 0

Note: if you use the same conanfile on Linux, you do get the expected error.

user: djeverett
issue_6361: state: open
title: [question/feature suggestion] Modern C++ Component: an end-to-end process
body: We have been using Conan for a bit more than a year now, and we are convinced together with CMake they form a power-couple able to take C++ out of the dark-ages of _"dependencies are a mess, stay away"_.

This may of course still require some effort to be widely acceptable, and as trivial as in some other languages. In particular, while tackling the different problems to use such tools in production, one major issue we faced was the lack of a complete and documented process allowing to provide and then consume C++ packages.

It has been around our head for some time, so we decided to write down the process we are now using with some degree of satisfaction (and major observed benefits, compared to the manual development method that was in place before):

https://adnn.github.io/ModernCppComponent

In particular, the distribution section is trying to cover the Conan related part: https://adnn.github.io/ModernCppComponent/#_distribution_conan

_NB_: It is still looking for a good name, {Sonat} is a place holder ; )

---

It raises different points as _friction points_, where we feel a better approach could ease adoption. Notably [forwarding settings to the CMake build helper without `conan_basic_setup`](https://adnn.github.io/ModernCppComponent/#_conan_basic_setup_alternative)

* Is this document of any interest to the developer and the community? If so, we are eager to get feedbacks and update the process accordingly!
* Would you like to further discuss some of the points? If so, should the discussion take place in separate issues?
user: Adnn
issue_6344: state: open
title: [bug] #5713 allows inconsistent builds
body: Since issue #5713 has been merged, inconsistent configurations don't generate an error anymore.
Example:
App A depends on B==2.0.0 and C==1.0.3
B==1.0.3 depends on C[>=1.1.0]
This is inconsistent, because the version requirement of B on C is broken by A's request. Accepting it without throwing an error is problematic, because it can hide problems. Version ranges state strict requirements and violating them, even with exact dependencies versions, introduces possible problems. We had a case where the final app crashed because the inconsistency was not reported as error. I think this behaviour should be configurable, and the default should be to throw an error on encountering inconsistencies. This will help developers to spot problems, but still allows to ignore them if you really know what you are doing. In my experience, in the majority of the cases those inconsistencies show you real problems.

### Environment Details (include every applicable attribute)
  * This is a general issue independent of Operating system and Python version.
  * Conan version: >= 1.20.0

user: klaussnd
issue_6328: state: open
title: Test installing in cmd and activating environment in shell
body: From https://github.com/conan-io/conan/pull/6320, running everything in a shell environment in Windows should work, and that test is checking it. 

But is expected that some users will use Conan in the Windows cmd and then activate some bash and try to activate the environment.sh generated by ``virtualenv`` Conan generators.

It would be good to test this behavior, up to what point this is working or failing.
user: memsharded
issue_6257: state: open
title: [question] Using branch as channel
body: **Background:**
My team has several in-house applications and libraries. For example, let's say appX depends on  libA, libB, and libC. A monolithic repository would look like this:
repo/libA
repo/libB
repo/libC
repo/appX

We are not currently versioning each component as one ideally would. Thus, everything is version 1.0.0 from the Conan perspective. Instead, we are tying the source code to binary artifacts by the Git branch. 

My solution to migrate us to Conan has been to use Git branch as the channel in the Conan reference:
`<package>/1.0.0@company/<branch>`

This approach, combined with `package_revision_mode` has worked. Each package recipe has something like this:

```
    def requirements(self):
        branch = self.get_branch()
        self.requires("libA/1.0.0@company/{}".format(branch))
        self.requires("libB/1.0.0@company/{}".format(branch))
        self.requires("libC/1.0.0@company/{}".format(branch))
```
Where get_branch() looks like this:

```
    def get_branch(self):
        try:
            branch = self.channel
        except errors.ConanException:
            branch = tools.Git().get_branch()
        return branch
```
The very first build on a new branch incurs the cost of ultimately building everything. While not ideal, it works given our current constraint of not being able to implement proper versioning across all components.

**Problem:**
Migrating towards a GitFlow-inspired Git workflow has complicated things; the convention to use a slash '/' character in the branch name is breaking the above approach as the slash character interferes with the Conan reference syntax. Errors like this rightfully pop up:

`ERROR: The reference has too many '/'`

One obvious approach would be to remove the slash character from the Git branch when interacting with Conan: feature/JIRA-12345 would become featureJIRA-12345, for example. A CI server calling on Conan to build packages would need to do the substitution and the get_branch() function above would need to do the same.

I'm posting in hopes of getting better ideas.

Thank you

user: radonish
issue_6244: state: open
title: [feature] Add nvcc compiler to default settings.yml
body: In conan 1.21 `intel` compiler was added. Could we add `nvcc` too?
Since `nvcc` always comes tied to the notion of a `host compiler`, I suggest adding a `host_compiler` subsetting for each [supported](https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#supported-host-compilers) compiler using yaml anchors (same as intel):
```
    nvcc:
        version: ["8.0", "9.0", "9.1", "9.2", "10.0", "10.1", "10.2"]
        host_compiler:
            gcc:
                <<: *gcc
            intel:
                <<: *intel              
            clang:
                <<: *clang
            apple_clang:
                <<: *apple_clang
            Visual Studio:
                <<: *visual_studio
        cppstd: [None, 03, 11, 14]
```

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: Hopobcn
issue_6233: state: open
title: [bug] Concurrent conan config install with Git fails
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: 10.14.6
  * Compiler+version: n/a
  * Conan version: 1.21.0
  * Python version: 2.7.17

### Steps to reproduce (Include if Applicable)

Execute more than one `conan config install` concurrently. This happens in our CI builders that are currently sharing a local cache, but I simulate it with this command:

```
conan config install git@octocat.dlogics.com:datalogics/conan-config.git --args '--branch artifactory-virtual-repos' & conan config install git@octocat.dlogics.com:datalogics/conan-config.git --args '--branch artifactory-virtual-repos'
```

(substitute your favorite Git source and branch as necessary)

The two executions collide over the `tmp_config_install` directory.

- Is concurrency supported for `conan config install`?
- Should there be a lock to prevent collisions in `conan config install`?
- Should the Git support for `conan config install` not use a fixed temporary directory name?

### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

```
$ conan config install git@octocat.dlogics.com:datalogics/conan-config.git --args '--branch artifactory-virtual-repos' & conan config install git@octocat.dlogics.com:datalogics/conan-config.git --args '--branch artifactory-virtual-repos'
[1] 30719
Trying to clone repo: git@octocat.dlogics.com:datalogics/conan-config.git
Trying to clone repo: git@octocat.dlogics.com:datalogics/conan-config.git
Traceback (most recent call last):
  File "/Users/kam/.virtualenvs/conan-qr_code_generator-gGkB1lQl/lib/python2.7/site-packages/conans/client/command.py", line 1947, in run
    method(args[0][1:])
  File "/Users/kam/.virtualenvs/conan-qr_code_generator-gGkB1lQl/lib/python2.7/site-packages/conans/client/command.py", line 574, in config
    target_folder=args.target_folder)
  File "/Users/kam/.virtualenvs/conan-qr_code_generator-gGkB1lQl/lib/python2.7/site-packages/conans/client/conan_api.py", line 81, in wrapper
    return f(api, *args, **kwargs)
  File "/Users/kam/.virtualenvs/conan-qr_code_generator-gGkB1lQl/lib/python2.7/site-packages/conans/client/conan_api.py", line 596, in config_install
    source_folder=source_folder, target_folder=target_folder)
  File "/Users/kam/.virtualenvs/conan-qr_code_generator-gGkB1lQl/lib/python2.7/site-packages/conans/client/conf/config_installer.py", line 236, in configuration_install
    _process_config(config, cache, output, requester)
  File "/Users/kam/.virtualenvs/conan-qr_code_generator-gGkB1lQl/lib/python2.7/site-packages/conans/client/conf/config_installer.py", line 185, in _process_config
    _process_git_repo(config, cache, output)
  File "/Users/kam/.virtualenvs/conan-qr_code_generator-gGkB1lQl/lib/python2.7/site-packages/conans/client/conf/config_installer.py", line 50, in _process_git_repo
    with tmp_config_install_folder(cache) as tmp_folder:
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/contextlib.py", line 17, in __enter__
    return self.gen.next()
  File "/Users/kam/.virtualenvs/conan-qr_code_generator-gGkB1lQl/lib/python2.7/site-packages/conans/client/conf/config_installer.py", line 41, in tmp_config_install_folder
    mkdir(tmp_folder)
  File "/Users/kam/.virtualenvs/conan-qr_code_generator-gGkB1lQl/lib/python2.7/site-packages/conans/util/files.py", line 271, in mkdir
    os.makedirs(path)
  File "/Users/kam/.virtualenvs/conan-qr_code_generator-gGkB1lQl/bin/../lib/python2.7/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 17] File exists: '/Users/kam/.conan/tmp_config_install'

ERROR: [Errno 17] File exists: '/Users/kam/.conan/tmp_config_install'
Repo cloned!                                                                                                                                                                            
Skip README.md
Copying file .gitignore to /Users/kam/.conan/.
Copying file .gitattributes to /Users/kam/.conan/.
Copying file version.txt to /Users/kam/.conan/.
Defining remotes from remotes.txt
Installing settings.yml
Processing conan.conf
Copying file gcc-8-aix-71 to /Users/kam/.conan/profiles
Copying file apple-clang-10.0-macos-10.9 to /Users/kam/.conan/profiles
Copying file gcc-7-redhat to /Users/kam/.conan/profiles
Copying file aix-xlc16-ppc to /Users/kam/.conan/profiles
Copying file apple-clang-9.1-macos-10.7 to /Users/kam/.conan/profiles
Copying file aix-xlc13-ppc to /Users/kam/.conan/profiles
Copying file visual-studio-16 to /Users/kam/.conan/profiles
Copying file visual-studio-16-llvm to /Users/kam/.conan/profiles
Copying file apple-clang-10.0 to /Users/kam/.conan/profiles
Copying file devtoolset-7 to /Users/kam/.conan/profiles
Copying file gcc-8-intel-solaris to /Users/kam/.conan/profiles
Copying file gcc-9-aix-71 to /Users/kam/.conan/profiles
Copying file gcc-8-sparc-solaris to /Users/kam/.conan/profiles
Copying file visual-studio-15-llvm to /Users/kam/.conan/profiles
Copying file llvm-toolset-7 to /Users/kam/.conan/profiles
Copying file build_tools to /Users/kam/.conan/profiles
Copying file apple-clang-9.1 to /Users/kam/.conan/profiles
Copying file visual-studio-14 to /Users/kam/.conan/profiles
Copying file visual-studio-12 to /Users/kam/.conan/profiles
Copying file visual-studio-15 to /Users/kam/.conan/profiles

[1]  + 30719 done       conan config install git@octocat.dlogics.com:datalogics/conan-config.git
```
user: datalogics-kam
labels: Hacktoberfest: https://hacktoberfest.digitalocean.com/
issue_6215: state: open
title: valid vs invalid overrides
body: Dear contributors,

We would like to distinguish between invalid and valid overrides. We are unsure whether the feature exists, or rather what kind of features exit in that regard.

To explain the two terms, consider PkgA & PkgB, both including PkgC; where hierarchy between PkgA and PkgB shall be irrelevant; and where PkgB may require a particular version of C, respectively.

A valid override would be:
PkgA/1.0.0: requirement PkgC/[~=1 >=1.2] overridden by PkgB/1.0.0 to PkgC/1.3.0

An invalid override would be
PkgA/1.0.0: requirement PkgC/[~=1 >=1.2] overridden by PkgB/1.0.0 to PkgC/1.1.0

Now, we would like to throw errors for invalid overrides only. 
However, with the variable CONAN_ERROR_ON_OVERRIDE we would receive an error in either way.


In another regard on that subject, we understand that "Dependency Hell" is an informatics term that describes the NP-hard problem of determining within a set of N interdependent packages of at most k versions each whether a feasible N-tuple of non-conflicting versions for each tuple exists. Would Conan.io try the k^N possible tuples, in order to find a feasible installation? If not, since the problem naturally exists, which rules does Conan.io apply for determination of the particular tuple that it proposes? That information could help us for understanding of how to design requirement ranges.

user: Martin581
issue_6193: state: open
title: [bug] 403 Artifactory permission error reported as 500
body: Conan develop branch

Artifactory 6.11.3

Permissions without DELETE permission.

Upload a package with exports_sources, modify sources upload again.

Artifactory:
```
2019-12-06 21:16:18,371 [http-nio-8081-exec-9] [INFO ] (o.a.e.UploadServiceImpl:401) - Deploy to 'conan-local2:_/hello/0.1/_/0/package/2bb76c9adac7b8cd7c5e3b377ac9f06934aba606/0/conaninfo.txt' Content-Length: 432
2019-12-06 21:16:18,434 [http-nio-8081-exec-3] [INFO ] (o.a.e.UploadServiceImpl:401) - Deploy to 'conan-local2:_/hello/0.1/_/0/package/2bb76c9adac7b8cd7c5e3b377ac9f06934aba606/0/conanmanifest.txt' Content-Length: 157
2019-12-06 21:16:31,182 [http-nio-8081-exec-8] [WARN ] (o.a.r.ArtifactoryResponseBase:125) - Sending HTTP error code 403: Not enough permissions to overwrite artifact 'conan-local2:_/hello/0.1/_/0/export/conan_sources.tgz' (user 'memsharded' needs DELETE permission).
2019-12-06 21:16:36,221 [http-nio-8081-exec-1] [WARN ] (o.a.r.ArtifactoryResponseBase:125) - Sending HTTP error code 403: Not enough permissions to overwrite artifact 'conan-local2:_/hello/0.1/_/0/export/conan_sources.tgz' (user 'memsharded' needs DELETE permission).
2019-12-06 21:16:36,236 [http-nio-8081-exec-6] [INFO ] (o.a.e.UploadServiceImpl:401) - Deploy to 'conan-local2:_/hello/0.1/_/0/export/conanfile.py' Content-Length: 0
```

Client:
```
(conan37) λ conan upload * -r=local2 --all --confirm
Uploading to remote 'local2':
Uploading hello/0.1 to remote 'local2'
Compressing conan_sources.tgz completed [3 files]
Uploading conan_sources.tgz completed [0.47k]
ERROR: 500 Server Error: Internal Server Error for url: http://localhost:8081/artifactory/api/conan/conan-local2/v1/files/_/hello/0.1/_/0/export/conan_sources.tgz
Waiting 5 seconds to retry...
Uploading conan_sources.tgz completed [0.47k]
ERROR:
Error uploading file: conan_sources.tgz, '500 Server Error: Internal Server Error for url: http://localhost:8081/artifactory/api/conan/conan-local2/v1/files/_/hello/0.1/_/0/export/conan_sources.tgz'
Uploading conanmanifest.txt completed [0.24k]
ERROR: 500 Server Error: Internal Server Error for url: http://localhost:8081/artifactory/api/conan/conan-local2/v1/files/_/hello/0.1/_/0/export/conanmanifest.txt
Waiting 5 seconds to retry...
Uploading conanmanifest.txt completed [0.24k]
ERROR:
Error uploading file: conanmanifest.txt, '500 Server Error: Internal Server Error for url: http://localhost:8081/artifactory/api/conan/conan-local2/v1/files/_/hello/0.1/_/0/export/conanmanifest.txt'
ERROR: Execute upload again to retry upload the failed files: conan_sources.tgz, conanmanifest.txt. [Remote: local2]
ERROR: Errors uploading some packages
```
user: memsharded
issue_6159: state: open
title: [bug] Don't know how to make <C:\...\Hostx64\vcvarsall.bat.>
body: I am having an issue building boost_system/1.69.0@bincrafters/stable. From the logs it seems that it is searching for vcvarsall.bat in an incorrect folder: <_.../VC/Tools/MSVC/VERSION/bin/Hostx64/vcvarsall.bat>_, however, the actual location of the file in my (fresh) installation of visual studio is _<.../VC/Auxiliary/Build>_.

### Environment Details 
  * Operating System + version: Windows 10 Professional 64-bit (10.0, Build 18362)
  * Compiler+version: Visual Studio 2019 Community 16.3.10
  * Conan version: 1.20.4
  * Python version: 3.8.0

_(This environment is a completely fresh installation of windows 10 + entirely new installations of required software)_

### Steps to reproduce (Include if Applicable)
conanfile.txt:
```
[requires]
boost_system/1.69.0@bincrafters/stable

[generators]
cmake_find_package

```
project structure:
```
project\
     conanfile.txt
     CMakeLists.txt
     build\   
```


install command:
`[from build\] conan install .. --build missing`

### Logs (Executed commands with output) (Include/Attach if Applicable)

```
D:\dev\c++\rest\build>conan install .. --build missing
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

boost_system/1.69.0@bincrafters/stable: WARN: Package is corrupted, removing folder: C:\.conan\d8b70d\1
conanfile.txt: Installing package
Requirements
    boost_config/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    boost_predef/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    boost_system/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    boost_winapi/1.69.0@bincrafters/stable from 'bincrafters' - Cache
Python requires
    boost_base/1.69.0@bincrafters/stable
Packages
    boost_config/1.69.0@bincrafters/stable:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache
    boost_predef/1.69.0@bincrafters/stable:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache
    boost_system/1.69.0@bincrafters/stable:1cfc588b26e59ddc9e1094237b6c5153e7f2f0bc - Build
    boost_winapi/1.69.0@bincrafters/stable:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache
Build requirements
    boost_build/1.69.0@bincrafters/stable from 'bincrafters' - Cache
    boost_generator/1.69.0@bincrafters/stable from 'bincrafters' - Cache
Build requirements packages
    boost_build/1.69.0@bincrafters/stable:456f15897172eef340fcbac8a70811f2beb26a93 - Cache
    boost_generator/1.69.0@bincrafters/stable:6ec6439c54a97da1cfddff786d1ea15988300369 - Cache

boost_build/1.69.0@bincrafters/stable: Already installed!
boost_config/1.69.0@bincrafters/stable: Already installed!
boost_predef/1.69.0@bincrafters/stable: Already installed!
boost_generator/1.69.0@bincrafters/stable: Already installed!
boost_winapi/1.69.0@bincrafters/stable: Already installed!
boost_system/1.69.0@bincrafters/stable: Applying build-requirement: boost_generator/1.69.0@bincrafters/stable
boost_system/1.69.0@bincrafters/stable: Applying build-requirement: boost_build/1.69.0@bincrafters/stable
boost_system/1.69.0@bincrafters/stable: WARN: Build folder is dirty, removing it: C:\.conan\0d1287\1
boost_system/1.69.0@bincrafters/stable: Copying sources to build folder
boost_system/1.69.0@bincrafters/stable: Building your package in C:\.conan\0d1287\1
boost_system/1.69.0@bincrafters/stable: Generator boost created jamroot
boost_system/1.69.0@bincrafters/stable: Generator boost created boostcpp.jam
boost_system/1.69.0@bincrafters/stable: Generator boost created project-config.jam
boost_system/1.69.0@bincrafters/stable: Generator boost created short_path.cmd
boost_system/1.69.0@bincrafters/stable: Calling build()
boost_system/1.69.0@bincrafters/stable: C:\.conan\0d1287\1: b2 -j8 -d+1 -a --hash=yes --debug-configuration --layout=system    system-build
notice: found boost-build.jam at C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/boost-build.jam
notice: loading Boost.Build from C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/kernel
C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/util\os.jam:50: Unescaped special character in argument ([^.]*)$
C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/util\os.jam:204: Unescaped special character in argument os:
C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/util\os.jam:205: Unescaped special character in argument os:
notice: Searching 'C:\Users\gamer' 'C:\Users\gamer' 'C:\Users\gamer\.conan\data\boost_build\1.69.0\bincrafters\stable\package\456f15897172eef340fcbac8a70811f2beb26a93\share\boost-build\src/kernel' 'C:\Users\gamer\.conan\data\boost_build\1.69.0\bincrafters\stable\package\456f15897172eef340fcbac8a70811f2beb26a93\share\boost-build\src\kernel' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/kernel' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/util' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/build' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/tools' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/contrib' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/.' for site-config configuration file 'site-config.jam'.
notice: Configuration file 'site-config.jam' not found in 'C:\Users\gamer' 'C:\Users\gamer' 'C:\Users\gamer\.conan\data\boost_build\1.69.0\bincrafters\stable\package\456f15897172eef340fcbac8a70811f2beb26a93\share\boost-build\src/kernel' 'C:\Users\gamer\.conan\data\boost_build\1.69.0\bincrafters\stable\package\456f15897172eef340fcbac8a70811f2beb26a93\share\boost-build\src\kernel' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/kernel' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/util' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/build' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/tools' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/contrib' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/.'.
notice: Searching 'C:\Users\gamer' 'C:\Users\gamer' 'C:\Users\gamer\.conan\data\boost_build\1.69.0\bincrafters\stable\package\456f15897172eef340fcbac8a70811f2beb26a93\share\boost-build\src/kernel' 'C:\Users\gamer\.conan\data\boost_build\1.69.0\bincrafters\stable\package\456f15897172eef340fcbac8a70811f2beb26a93\share\boost-build\src\kernel' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/kernel' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/util' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/build' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/tools' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/contrib' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/.' for user-config configuration file 'user-config.jam'.
notice: Configuration file 'user-config.jam' not found in 'C:\Users\gamer' 'C:\Users\gamer' 'C:\Users\gamer\.conan\data\boost_build\1.69.0\bincrafters\stable\package\456f15897172eef340fcbac8a70811f2beb26a93\share\boost-build\src/kernel' 'C:\Users\gamer\.conan\data\boost_build\1.69.0\bincrafters\stable\package\456f15897172eef340fcbac8a70811f2beb26a93\share\boost-build\src\kernel' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/kernel' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/util' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/build' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/tools' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/contrib' 'C:/Users/gamer/.conan/data/boost_build/1.69.0/bincrafters/stable/package/456f15897172eef340fcbac8a70811f2beb26a93/share/boost-build/src/.'.
notice: Searching '.' for project-config configuration file 'project-config.jam'.
notice: Loading project-config configuration file 'project-config.jam' from '.'.
notice: will use 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/x64/cl.exe' for msvc, condition <toolset>msvc-16.0
notice: [msvc-cfg] condition: '<toolset>msvc-16.0/<architecture>/<address-model>', setup: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/vcvarsall.bat'
notice: [msvc-cfg] condition: '<toolset>msvc-16.0/<architecture>/<address-model>32', setup: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/vcvarsall.bat'
notice: [msvc-cfg] condition: '<toolset>msvc-16.0/<architecture>x86/<address-model>', setup: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/vcvarsall.bat'
notice: [msvc-cfg] condition: '<toolset>msvc-16.0/<architecture>x86/<address-model>32', setup: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/vcvarsall.bat'
notice: [msvc-cfg] condition: '<toolset>msvc-16.0/<architecture>/<address-model>64', setup: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/vcvarsall.bat'
notice: [msvc-cfg] condition: '<toolset>msvc-16.0/<architecture>x86/<address-model>64', setup: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/vcvarsall.bat'
notice: [msvc-cfg] condition: '<toolset>msvc-16.0/<architecture>ia64/<address-model>', setup: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/vcvarsall.bat'
notice: [msvc-cfg] condition: '<toolset>msvc-16.0/<architecture>ia64/<address-model>64', setup: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/vcvarsall.bat'
notice: [msvc-cfg] condition: '<toolset>msvc-16.0/<architecture>arm/<address-model>', setup: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/vcvarsall.bat'
notice: [msvc-cfg] condition: '<toolset>msvc-16.0/<architecture>arm/<address-model>32', setup: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.23.28105/bin/Hostx64/vcvarsall.bat'
===============MPI Auto-configuration===============
Found Microsoft MPI: C:\Program Files\Microsoft MPI
Found Microsoft MPI SDK: C:\Program Files (x86)\Microsoft SDKs\MPI
MPI build features:
<include>/C:/Program Files (x86)/Microsoft SDKs/MPI/Include <address-model>64:<library-path>/C:/Program Files (x86)/Microsoft SDKs/MPI/Lib/x64 <library-path>/C:/Program Files (x86)/Microsoft SDKs/MPI/Lib/x86 <find-static-library>msmpi <toolset>msvc:<define>_SECURE_SCL=0
MPI launcher: "C:\Program Files\Microsoft MPI\Bin\mpiexec.exe" -n
====================================================
don't know how to make <p/C:/.conan/0d1287/1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.23.28105\bin\Hostx64\vcvarsall.bat
...found 120 targets...
...updating 15 targets...
...can't find 1 target...
...can't make 2 targets...
...skipped <pbin\standalone\msvc\ab605d3a191801849fe1e1e55b908353>msvc-setup.read for lack of <p/C:/.conan/0d1287/1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.23.28105\bin\Hostx64\vcvarsall.bat...
...skipped <pbin\standalone\msvc\ab605d3a191801849fe1e1e55b908353>msvc-setup.bat for lack of <p/C:/.conan/0d1287/1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.23.28105\bin\Hostx64\vcvarsall.bat...
...skipped <pbin\system\build\aca5cb0fcccc3d2990e4e006ef019df6>error_code.obj for lack of <pbin\standalone\msvc\ab605d3a191801849fe1e1e55b908353>msvc-setup.nup...
...skipped <pbin\system\build\aca5cb0fcccc3d2990e4e006ef019df6>libboost_system.lib for lack of <pbin\system\build\aca5cb0fcccc3d2990e4e006ef019df6>error_code.obj...
...skipped <psystem\lib>libboost_system.lib for lack of <pbin\system\build\aca5cb0fcccc3d2990e4e006ef019df6>libboost_system.lib...
common.copy system\lib\jamroot.jam
bin\d41d8cd98f00b204e9800998ecf8427e\system-lib\jamroot.jam
        1 file(s) copied.
...skipped 5 targets...
...updated 12 targets...
boost_system/1.69.0@bincrafters/stable:
boost_system/1.69.0@bincrafters/stable: ERROR: Package '1cfc588b26e59ddc9e1094237b6c5153e7f2f0bc' build failed
boost_system/1.69.0@bincrafters/stable: WARN: Build folder C:\.conan\0d1287\1
ERROR: boost_system/1.69.0@bincrafters/stable: Error in build() method, line 147
        self._build_common()
while calling '_build_common', line 170
        self.run(" ".join(b2_command))
        ConanException: Error 1 while executing b2 -j8 -d+1 -a --hash=yes --debug-configuration --layout=system    system-build
```

user: Siech0
issue_6141: state: open
title: [bug] Sporadic FileNotFoundError during upload (conan_export.tgz.dirty)
body: 

### 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'
```

user: sztomi
issue_6112: state: open
title: [bug] Build policy outdated builds test_package ever
body: Hi!

This issues came from https://github.com/conan-io/conan-package-tools/issues/434

As we know, [Build Policies](https://docs.conan.io/en/latest/mastering/policies.html#build-policies) can influence the build action to Conan client. One of these policies is `outdate`, which is used to build ONLY a package that is outdated.

When running Conan Package Tools to build a list of packages, and using the `outdated` policy to avoid unnecessary jobs, Conan builds and run test_package, even when a package is not outdated.

### Environment Details (include every applicable attribute)
  * Operating System+version: ANY
  * Compiler+version: ANY
  * Conan version: 1.20.4
  * Python version: 3.8.0

### Steps to reproduce (Include if Applicable)

    conan new -t foo/0.1.0
    conan create . 
    conan create . --build outdated

### Actual Result

Conan build and run test_package even when a package is up-to-date and the build policy is "outdated".

### Expected Result

Conan should not build/run test package when build policy is "outdated", and the current package is up-to-date.

### Logs (Executed commands with output) (Include/Attach if Applicable)

[conan-outdated.log](https://github.com/conan-io/conan/files/3871211/conan-outdated.log)


user: uilianries
issue_6108: state: open
title: [bug] Unneeded environment variables when using MSVC can get too long and cause problems.
body: When using the `virtualbuildenv` generator and using MSVC for the compiler the `CL` and `LIB` variables are set to add the include and lib path of every library that the project depends on. This is not needed for most build systems, and is causing problems at my workplace where we have about 60 dependencies in total. On running activate_build.bat we get an error that the command line is too long for these variables, and we have seen our build scripts failing due to this error coming from `cmd.exe`. Either not having these set to include all of the libraries or at least having the ability to turn off this behaviour would be helpful.


### Environment Details (include every applicable attribute)
  * Operating System+version: Windows (all)
  * Compiler+version: MSVC
  * Conan version: 1.19.3
  * Python version: 3.7

### Steps to reproduce (Include if Applicable)
1. Create a project with a large number (60 in our case) of dependencies
2. Ensure that the conanfile specifies that the virtualbuildenv generator is created.
3. Run `conan install`
4. Attempt to run `activate.bat` and `activate_build.bat`
5. Observe that there is an error about the command line being too long


user: BumblingCoder
labels: component: Build: Build helpers, build systems..
issue_6090: state: open
title: [question] build dependency without cpp_info
body: ### Question
How can i use a package as a pure build time dependency.

### Example
4 different packages:
- Boost
- libA: a process communication library which provides some shared libs for runtime usage as well as code generators. The code generators also make use of the libraries. Depends on Boost (shared)
- libB: Uses A to create some code during build and compiles some code. Does not have any runtime dependency to A. 
- libC: Does use A for process communication.

My current approach was to use libA as a build_requirement but then libB also gets boost as a dependency. how can i only use A as a pure build time dependency?

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: Crejan
issue_6079: state: open
title: [bug] Repo advisory locks fail to release on process termination
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

I am occasionally seeing Conan get stuck trying to obtain the advisory locks on the repository or packages within the repository. I have dug through the code and I have a hard time understanding how this issue can possibly occur. Perhaps someone else can figure out what is happening, or maybe know's the next place to look? Here's what I know so far:

I have seen issue #2071, but I do not believe it to be fixed on all platforms, and I do not understand how PR #2996 could have "fixed" the issue:

- Conan, as far as I can tell, uses the "correct" system interprocess locking mechanism (not the naive method using `open` and `O_EXCL`).
- On Unix systems, this will use `fcntl()` to implement shared/exclusive locking with the support of the operating system.
- On Windows, this will use the `msvcrt.locking` Python function, which (AFAICT) is implemented in terms of Win32 `LockFileEx`.
- Regardless of platform, the operating system will guarantee that it will automatically release any open locks in case that the owning processes are terminated, regardless of termination method.
- For this reason, even if a lock owner is hard-killed with `SIGKILL` or `::TerminateProcess()`, the advisory locks will be released by the operating system. Thus I cannot see how handling `SIGTERM` could have had any effect on the locking behavior.
- What's more, I don't see how this could possibly be an issue _at all_. By my understanding of the Win32 and POSIX documentation, there should be no way that the hold on the locks can possibly outlive a Conan process!
- I'm currently debugging on Windows, although I have seen (but cannot reproduce) the issue on Linux (I wouldn't worry about Linux ATM).
- I opened ProcExp to try and see what process is holding open a handle to the package lock (`foo.count.lock`), and... nothing. No one has the file open! AFAIK, if no one has the file open, the operating system will release the lock. What gives?

I've opened the code to the MSVCRT, `locking.cpp`, upon which `msvcrt.locking` is implemented. It all looks like completely valid usage of `::LockFileEx`, and I cannot see how the locks can outlive the process.

### Environment Details (include every applicable attribute)
  * Operating System+version: Windows Server 1903 Core
  * Conan version: 1.20.2
  * Python version: Python 3.8.0

### Steps to reproduce (Include if Applicable)
1. Begin a conan operation to install/build/export a package into the local repository.
2. While an advisory lock is held, non-gracefully terminate the Python process. On Windows, there are no 'signals' quite like POSIX, although there is limited emulation of SIGINT. I cannot be certain what termination mechanism is in use, as this termination is going through "Stop build" in a Bamboo dashboard, of which the documented behavior on Windows is somewhat confusing. However, the termination mechanism should not matter (See above).
3. Attempting to re-run the process will cause Conan to deadlock when trying to re-obtain access to the same advisory locks.
user: vector-of-bool
issue_6078: state: open
title: [feature] Start using scheduled LTS releases
body: I love the speed at which Conan is being developed. Few things make me happier than seeing a project I use be actively updated, fixed, and worked on. But that inevitably means there are some "breaking" changes that get shoved in once in a while (as in, breaks my workflow, not necessarily breaks your public API.... as in, I might be relying on some part of Conan that I shouldn't be).

The last time I ran into this was the switch from remotes.txt to remotes.json... I had to change a lot of CI build configs to deal with that, and it took quite a while.

It would be _really awesome_ if the Conan team could start doing long term support (LTS) releases. The idea being that my team and I would not upgrade to any version which isn't an LTS, and the Conan team would fix bugs in the LTS long after version LTS + n came out.

The most recent reason for me asking for this is because I _just_ upgraded my team to 1.19.2 (for a bugfix in revisions support), after _just_ finishing the upgrade them to 1.16.1 (for revisions support). Now that we're all on the same version again, and I'm ready to start using lockfiles, I find out about #5499.... time to upgrade _again_ and potentially deal with more "breaking" changes.

I've read through the release notes very carefully, and it looks none of the changes between 1.19.2 and 1.20.3 will affect our workflow, so it _shouldn't_ be a big deal to do this upgrade. But I'd be a lot more confident about that if 1.19 happened to be an LTS release that was continuously getting bug fixes only, and we could just upgrade to the latest 1.19 release instead of jumping to 1.20.

Given the young age of Conan overall, and the rapid speed of development, I don't think you need or should try to do 5-year LTS's like Canonical with Ubuntu. Even 6-months would be a big step forward. I don't think there even needs to be any overlap between LTS releases (yet). But it would be really nice if the Conan team could release a version that received bug fixes for longer than a month.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: DavidZemon
issue_6062: state: open
title: [question] Binary packages and recipes in separate locations
body: We have the following situation:

We build an application with a large number of dependencies with custom options and settings. We cache the binary packages for these dependencies on a local Artifactory instance for the following reasons:

1. Speed of build. Binary packages often do not exist on conan-central for the specific options we have, and CI builds everything from scratch using a Docker image.

2. Network issues. Often when running on CI, there are network problems when downloading remote packages so we need our own package cache.

For this to work, we have our remotes set so that our local Artifactory is always searched first.

The problem we have, is that by doing this we have no way of knowing if the corresponding package on conan-central has become outdated, which often results in hard to debug errors caused by outdated recipes.

We 'solve' this problem by periodically refreshing our Artifactory cache.

The question:

*Is it possible to have a recipe and binaries on different remotes?* I think our problem would be solved by always checking conan-central for the latest recipe, but using our local remote for the binary package if the recipe has not become outdated.
user: planetmarshall
issue_6055: state: open
title: [question] mingw_installer  best practice?
body: should build_requirement of mingw_installer should be defined in profile or in component recipe?

for example, 
openssl-recipe in conan-center_index, mingw_installer is no in recipe
icu in bincrafters , mingw_installer is defined in recipe

thx

- [x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: davidtazy
issue_6051: state: open
title: [question] Using a toolchain from a build_requires declared in a custom profile
body: ### Environment Details (include every applicable attribute)
  * Operating System+version: windows
  * Conan version: 1.20.2
  * Python version: 3.7.4

### Steps to reproduce (Include if Applicable)
profile
```.ini
[settings]
os=Windows
arch=x86

[build_requires]
profile_requires/1.0@example/test
```

profile_requires/conanfile.py
```.py
from conans import ConanFile

class ProfilerequiresConan(ConanFile):
    name = "profile_requires"
    version = "1.0"
    settings = ()

    options = { 'build_requires': [False, True] }
    default_options = { 'build_requires': False }

    def requirements(self):
        if self.options.build_requires:
            self.requires('build_requires/1.0@example/test')
```

build_requires/conanfile.py
```.py
from conans import ConanFile

class BuildrequiresConan(ConanFile):
    name = "build_requires"
    version = "1.0"
    settings = "os", "arch"

    def package(self):
        # includes some utility CMake modules
        self.copy("*")

    def package_id(self):
        self.info.settings.clear()
        self.info.options.clear()

    def package_info(self):
        # uses self.settings to inject appropriate CONAN_CMAKE_TOOLCHAIN_FILE
        pass
```

consumer/conanfile.txt
```.ini
[build_requires]
build_requires/1.0@example/test

[options]
profile_requires:build_requires=True
```

### Logs (Executed commands with output) (Include/Attach if Applicable)
```sh
conan export profile_requires example/test
conan export build_requires example/test
conan install consumer --profile profile
```

> Configuration:
> [settings]
> arch=x86
> os=Windows
> [options]
> [build_requires]
> *: profile_requires/1.0
> [env]
> 
> conanfile.txt: Installing package
> Build requirements
>     profile_requires/1.0@example/test from local cache - Cache
> Build requirements packages
>     profile_requires/1.0@example/test:b0667569a18f9cc1721f72a0103ba10594bbe420 - Missing

```sh
conan editable add build_requires build_requires/1.0@example/test
conan install consumer --profile profile
```

> Configuration:
> [settings]
> arch=x86
> os=Windows
> [options]
> [build_requires]
> *: profile_requires/1.0
> [env]
> 
> ERROR: Loop detected: 'profile_requires/1.0@example/test' requires 'build_requires/1.0@example/test' which is an ancestor too

Basically, when the build_requires is in editable mode, conan appears to be acting as if the editable package itself re-declares the build_requires contained in the profile, but does so using the consumer's default_options instead of those from build_requires's recipe. This would indeed be a dependency loop build_requires -> profile_requires -> build_requires, but it's one that isn't really there (because build_requires does not set profile_requires:build_requires=True)

user: puetzk
issue_6050: state: open
title: The 'conan info' command is a little slow
body: The 'conan info' command is a little slow, just like the following, it will take about 0.6s every time
There are many modules in my project and I check the conan packages every time( if it has been built, don't build it any more). The check action takes about several minutes
In this case, 1.5 minutes.
I can't find any way to speed up. 
Why 'conan info' is a second-level action?
user: guestliu
issue_6047: state: open
title: [bug] Overriding a requires() with a build_requires() in a downstream does not work anymore
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version: Linux, but should not matter
  * Compiler+version: None
  * Conan version: 1.19.2 and 1.20.2 are affected, 1.18.1 is not
  * Python version: 3.7.3

### Steps to reproduce (Include if Applicable)
I have three packages: CA, CB and CC. CB uses CA as requires(). CC uses CB as requires() and CA as build_requires() but in a different version. When I then create the package CC, I get the following error message:

```
ERROR: Conflict in CC/3.0.0@user/testing
    Requirement CA/1.0.1@user/testing conflicts with already defined CA/1.0.0@user/testing
    To change it, override it in your base requirements
```

To reproduce, you can use the following three conanfiles:
CA/conanfile.py:
```
from conans import ConanFile

class SpecificConanfile(ConanFile):
    name = "CA"
    description = "CA test component."
    url = "http://CA.html"
    version = "1.0.0"
```
Create the package via `conan create . user/testing`. Then update the version number to 1.0.1 and create another version of this package.

Then create CB via this conanfile.py:
```
from conans import ConanFile

class SpecificConanfile(ConanFile):
    name = "CB"
    description = "CB test component."
    url = "http://CB.html"
    version = "2.0.0"

    def requirements( self):
        self.requires( "CA/1.0.0@user/testing")
```
Then create CC via this conanfile.py:
```
from conans import ConanFile

class SpecificConanfile(ConanFile):
    name = "CC"
    description = "CC test component."
    url = "http://CC.html"
    version = "3.0.0"


    def build_requirements( self):
        self.build_requires( "CA/1.0.1@user/testing")


    def requirements( self):
        self.requires( "CB/2.0.0@user/testing")
```
The creation of CC will fail with the above error message.

Yes, it is questionable, if it makes sense to use CA as requires() in one package and as build_requires() in a downstream package. But as people here are often not too familiar with conan and with the difference between requires() and build_requires() and because we used to have problems with alias packages in build_requires(), we currently have quite a good mix of both. And the above situation used to work until conan 1.18.1. So it might be some sort of regression.

We'll work around this by making the use of build_requires() consistent for all packages (i. e. if a package is build_requires() somewhere, we make it build_requires() in all of its consumers - or if it is not really a valid candidate for build_requires() we'll make it requires() everywhere). That cleanup is certainly a good idea, anyway, but I still wanted to let you know about this bug/regression/problem.

user: fourbft
issue_6045: state: open
title: [question] CI Triggering and Branch development
body: Hey,

Trying to implement an automated pipeline using conan, Jenkins, and artifactory.
I've already read a bunch of your blog posts trying to cobble something together
that works for us, but seem to be missing some triggering mechanics based on how our
repos are organized.

What I've read:
https://blog.conan.io/2017/03/14/Devops-and-Continouous-Integration-Challenges-in-C-C++-Projects.html
https://jenkins.io/blog/2017/07/07/jenkins-conan/
https://docs.conan.io/en/latest/versioning/lockfiles.html

Repo1
AppA (Dependencies: LibA, LibB)
AppB (Dependencies: LibA, LibC)
LibA (Dependencies: LibB)

- Jenkinsfile (Multi-branch pipeline, no scm trigger)

LibB

-   Jenkinsfile (Multi-branch pipeline, no scm trigger)

Jenkinsfile (Multi-branch pipeline, scm trigger)

Repo2
LibC

-    Jenkinsfile (Multi-branch pipeline, no scm trigger)


Assumptions/Desires:
1) On push to Repo1 remote, run pipeline that builds based on what changed, resulting in
   in new top level binaries AppA and AppB.
2) We specifically want one top level job that triggers all other needed builds. 
   It's important for that commit to be associated with one build for our review gate process.
3) It's common for devs to change multiple libraries on a branch and within a single commit. 
4) We will likely be using package_revision_mode. All of our libraries are internal
   so version numbers stay at 1.0.0 so we don't have to constantly update conanfiles
5) Since our work is organized by branches, we typically want the latest 
   from the branch we are on and would like a "fall back to master" behaviour 
   if that library doesn't need to be built on your current branch.
6) We want each library to have its own history for metric collection, so having
   a single parameterized pipeline that everything calls wont work. This is solved
   by creating a Multi-Branch pipeline for each library, but disabling the scm trigger
   (so we can meet assumption 2)
7) Our CM team needs to be able to recreate builds, and I assume the lockfile will
   have a role here.   
8) We are building for a couple different architectures, which we encapsulate via profiles
9) We are using branch name as the channel, e.g. LibA/1.0.0@dummy/master
   
Questions
1) We started off using the 'conan info build-order' from the 7-7-17 blog post, but I see that
   is now deprecated in favor of the graph build-order. Given assumption 3, and that your lockfile
   doc shows that you create the lockfile, build a package, then call build-order,
   there doesn't seem to be a way to know which changed library to go build first.
   If I changed LibA and LibB in a single commit and have to build one first to get
   the build order, how do I correctly pick the first to build to prevent duplicate
   builds? If I change LibA and LibB, I am going to 'conan create' both, then the
   build order for LibB will probably tell me to go build LibA again. Can I get a build order without building anything?
2) I create a new issue branch TASK-1 for development and commit. How does any dependency chain get created at all if the conan files/requires are all looking at the master channel?

Below is my Repo1 scm triggered jenkinsfile attempt, but I don't think the algorithm is right. 
I know it doesn't work, and I haven't made any attempt to pass the lockfile around to children jobs so they can update it. 

```
def data
def conf_repo_dir
def client
def changed_projects

pipeline {
    options {
        skipDefaultCheckout()
    }
    parameters {
        string(name: 'conf_repo_branch', defaultValue: 'master', description: 'Conan config repository branch')
    }
    stages {
        stage("Determine Changed Projects"){
            steps {
                checkout scm
                script {
                    def cmd = "git diff --name-only origin/master...origin/${env.BRANCH_NAME}"
                    if ( "${env.BRANCH_NAME}" == "master")
                    {
                        cmd = "git diff-tree --no-commit-id --name-only -r ${env.GIT_COMMIT}"
                    }
                    changed_projects = sh (label: "Get commit files", script: cmd + " | grep '/' | grep -v tools | cut -d'/' -f1 | sort --unique", returnStdout: true).split()
                    echo "Changed projects: ${changed_projects}"
                }
            }
        }
        stage("Configure/Get repositories"){
            steps {
                script {
                    def conan_home = "${workspace}".toString() + "/conan_home"
                    client = Artifactory.newConanClient userHome: conan_home
                    def server = Artifactory.newServer url: "<server>/artifactory", credentialsId: 'ci_account'
                    client.remote.add server: server, repo: "conan", force: true
                    client.run command: "config install <conan settings repo>.git --args \"--branch " + params.conf_repo_branch + "\""
                    data = readYaml file: "${conan_home}/.conan/conan_ci_conf.yml"
                }
            }
        }
        stage("Build") {
            steps {
                script {
                    def user = "dummy"
                    def apps = entries(data.apps)
                    withEnv(["CONAN_USERNAME=${user}", "CONAN_CHANNEL=${env.BRANCH_NAME}"]){
                        for (int i = 0; i < apps.size(); i++) {
                            def app = apps.get(i)
                            def app_name = app[0];
                            def profiles = app[1]["profiles"];
                            def app_ref = app_name + "/1.0.0@" + user + "/${env.BRANCH_NAME}"
                            def repo = data.repos.get(app_name)
                            def profiles_build_order = [:]
                            create_lockfiles(repo.dir, profiles, client)
                            for (int j = 0; j < changed_projects.size(); j++) {
                                def project_name_version = changed_projects[j] + "/1.0.0"
                                def package_ref = project_name_version + "@" + user + "/${env.BRANCH_NAME}"
                                def package_repo_url = data.repos.get(project_name_version).url
                                def package_repo_recipe_dir = data.repos.get(project_name_version).dir
                                profiles_build_order = get_build_order_for_project(profiles_build_order,
                                                                                   package_ref,
                                                                                   changed_projects[j],
                                                                                   profiles,
                                                                                   "${env.BRANCH_NAME}",
                                                                                   package_repo_url,
                                                                                   package_repo_recipe_dir,
                                                                                   repo.dir,
                                                                                   client)
                            }
                            def tasks_groups = get_tasks_groups(profiles_build_order)
                            echo "Running in parallel: ${tasks_groups}"
                            launch_task_group(tasks_groups, params.conf_repo_branch)
                        }
                    }
                }
            }
        }
    }
}

def create_lockfiles(recipe_dir, profiles, client) {
    dir(recipe_dir){
        for(profile in profiles){
            client.run(command: "graph lock ./conan_package --lockfile " + profile + ".lock")
        }
    }
}

def get_build_order_for_project(profiles_build_order, package_ref, project_name, profiles, repo_branch, repo_url, recipe_dir, lock_file_dir, client) {
    dir("_build_" + project_name + "_repo"){
        echo "Getting project recipe '${project_name}' ${repo_branch} ${repo_url}"
        git branch: repo_branch, credentialsId: 'ci_account', url: repo_url
        dir(recipe_dir){
            for(profile in profiles){
                def lock_file = "../../" + lock_file_dir + "/" + profile + ".lock"
                client.run(command: "create ./conan_package " + package_ref + " --profile " + profile + " --lockfile " + lock_file)
                client.run(command: "graph build-order " + lock_file + " --json=build_order.json --build=missing")
                def bo_json = readJSON file: "./build_order.json"
                profiles_build_order[profile].addAll(bo_json["groups"])
                echo "Build order for recipe '${package_ref}' is " + profiles_build_order
            }
        }
    }
    return profiles_build_order
}

def get_tasks_groups(profiles_bo){
    // Merge all the profiles groups to run in parallel, first group from profile1 with first group from profile2, second
    // with second and so on
    def tasks_groups = []
    def group_index = 0
    while(true){
        tasks = []
        profiles_bo = entries(profiles_bo)
        for (int i = 0; i < profiles_bo.size(); i++) {
            def profile = profiles_bo[i]
            if(profile[1].size() <= group_index){
                continue;
            }
            for(ref in profile[1][group_index]){
                string name_p = ref.split("@")[0]
                string channel = ref.split("@")[1].split("/")[1]
                string task_name = ref + "_" + profile[0]
                string prof_name = profile[0].split("/").last()
                tasks.add([build_label: ref + " (${prof_name})",
                           ref: ref,
                           name_version: name_p,
                           channel: channel,
                           profile: profile[0]])
            }
        }
        if(tasks.size() == 0){
           break
        }
        tasks_groups.add(tasks)
        group_index += 1
    }
    return tasks_groups
}

def launch_task_group(tasks_groups, conf_repo_url, conf_repo_branch){
    // Runs the tasks parallelizing
    for(int i=0; i<tasks_groups.size(); i++){
        tasks = [:]
        for(int j=0; j<tasks_groups[i].size(); j++){
            def a_build = tasks_groups[i][j]
            def label = a_build["build_label"]
            echo "BUILD: ${a_build}"
            def project = a_build["name_version"].split("/")[0]
            tasks[label] = { -> build(job: "${project}/${env.BRANCH_NAME}",
                              parameters: [
                                 string(name: "build_label", value: label),
                                 string(name: "branch", value: a_build["channel"]),
                                 string(name: "name_version", value: a_build["name_version"]),
                                 string(name: "profile", value: a_build["profile"]),
                                 string(name: "conf_repo_url", value: conf_repo_url),
                                 string(name: "conf_repo_branch", value: conf_repo_branch)
                              ]
                       )
            }
        }
        parallel(tasks)
    }
}

@NonCPS
def entries(m) {
    m.collect {k, v -> [k, v]}
}
```

user: Rogue-14
labels: component: CI: Affect ONLY to CI
issue_6016: state: open
title: [feature] Get information about rebuild-candidates
body: When building a complex component there often are multiple versions of indirect dependencies involved. Ex: Boost uses bzip2/1.0.0 while Protobuf uses bzip/1.0.1. When I want to use Boost and Protobuf within my component, Conan notices the version difference and overwrites one with the other (oftentimes recompiling the dependencies in that process).

Within a CI environment I would like to know about these inconsistencies so I could trigger a rebuild myself. Or do certain things before letting Conan rebuild everything.

Conan already prints warnings whenever dependencies get overwritten by other packages. This feature request is about providing a way to know beforehand which parts of the build-order are not fitting with the rest of the dependency tree and would need to get rebuilt.

I'm not sure about a good implementation. It could be additional info within the `conan graph lock` JSON output or an entirely new command within `conan graph`.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: monsdar
issue_5983: state: open
title: [question] how to check if remote package is up to date
body: Apologies if i have missed the info in the documentation. 

Given I have the source of the conan package locally i would like to be able to determine if the package on the remote server is up to date, obviously the only info that can be used to determine this is the conanfile.py and any inline sources, if the remote package is not up to date build it.

I've been hacking various bits together calling conan internals from python like get_recipe_manifest and get_package_manifest, which I have working, but I'm still not 100 % sure what I should be comparing against what, and that maybe I missing something and there is a sensible way to do this. especially as i'm heavily breaking hyram's law here.



- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: conradjones
issue_5980: state: open
title: [feature] Disable system proxies from Conan
body: This PR kind of solve it but it is pretty hacky and as it is commented in the PR, it could have side effects.
https://github.com/conan-io/conan/pull/5922

I don't see this done unless we have a better and clear interface from the requests library to achieve it. I think that exceeds the Conan competences.

user: lasote
issue_5939: state: open
title: [question] Shared code and workspaces
body: I have a library A that also exports some headers/cpp (mainly (google) mocks from some interfaces) files as resources for consumers. These public files are installed into resources directory _after_ building. Consumers have to import these files into their cmake binary directory (otherwise, paths tend to get too long for cmake to handle). This worked fine, until I've tried out workspaces with A and a consumer B:
1. 'conan workspace ...' calls install() on A and B. A has not yet been built, therefore, no shared files have been copied to resources directory. Then B tries to import() everything from A's empty resource directory.
2. When building, B's test suite compilation fails due to missing files.

Questions:
I'm a bit reluctant to split A into two packages A and A_mocks because then number of dependencies increase by factor of two and versions can happen to mismatch (e.g., version A gets upgraded, but not the A_mock version in test-suites dependencies). But the sharing process I've described above also seems quite complex and fragile to me. Do you know any 'conanian' way to solve this more elegantly?

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
user: jfischer1
issue_5935: state: open
title: [feature] conan config reset
body: We're using `conan config install <git-repo>` within our CI environment. For our Windows builds we do not use Docker yet, they're just VMs and work like so:
1. Developer pushes changes to a repo
1. CI connects to one of the Windows VMs
1. CI uses `conan config install` to get the latest profiles and configuration for Conan
1. CI builds and tests the repo
1. CI uploads the Conan package
1. CI disconnects. Windows VM waits for the next job.

As you can see Windows jobs are not running within a sandboxed environment. That means when we do `conan config install` and install profileA it will remain there also for future jobs. To work around this we can clear the profiles directory before doing `conan config install`, but this is not as clean as it could be.

Therefore this feature request is to implement something like `conan config reset` or `conan config uninstall`. The command should reset the Conan config to its original state. It would help to have CI mechanisms a bit cleaner and would avoid us to implement any workarounds that may or may not work as intended and with future versions.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

user: monsdar
issue_5929: state: open
title: [bug] Overriding a dependency not present in the graph, gets ignored when installing.
body: ### Bug Description

When using "override" feature with a requirement that is not part of the package's graph, the requirement is ignored, and no information related to the ignored requirement is given to the user.
The requirement is not included in the graph either.

It could be great to add a log, or include the requirement even if it's doesn't override anything.

Actual : 
*  conan install runs fine, and is simply ignoring the requirement.

Expected : 
* either a log / error indicating the requirement has been ignored and is present OR include the requirement to the graph as if override wasn't specified.

### Environment Details (include every applicable attribute)
  * Operating System+version:  N/A
  * Compiler+version:  N/A
  * Conan version: 1.19.2
  * Python version: 3.6.8

### Steps to reproduce (Include if Applicable)

* create a basic conanfile
* add a requirement like : ("Poco/1.9.2@pocoproject/stable", "override")
* run conan install 
* check generated conaninfo file and look for something related to Poco
* check logs of conan install, look for something related to Poco
* Find nothing.

user: NokiDev
labels: component: ux: No changes to core business logic
issue_5923: state: open
title: [bug] Conan install failing on cross compiling with CentOS
body: <!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

I'm trying to cross compile a C++ application on Linux to Windows in a CentOS machine. I have installed gcc, g++, mingw-gcc and mingw-g++. I have attached the log below. However, the issue does not occur when I try to run conan install command in Ubuntu 18.04 with gcc 7.3 and mingw gcc 7.3.
Any help is much appreciated.

### Environment Details (include every applicable attribute)
  * Operating System+version: CentOS 7.7.1908
  * Compiler+version: gcc 4.8.5, g++ 4.8.5, x86_64-w64-mingw32-gcc 4.9.3, x86_64-w64-mingw32-g++ 4.9.3
  * Conan version: 1.19.1
  * Python version: 3.6.8

### Steps to reproduce (Include if Applicable)
#### Contents of conanfile.txt:
[requires]
libcurl/7.66.0@bincrafters/stable
OpenSSL/1.1.1c@conan/stable
zlib/1.2.11@conan/stable

[generators]
cmake


#### Contents of linux_to_win64 profile file:
toolchain=/usr/bin/x86_64-w64-mingw32 # Adjust this path
target_host=x86_64-w64-mingw32
cc_compiler=gcc
cxx_compiler=g++

[env]
CONAN_CMAKE_FIND_ROOT_PATH=$toolchain
CHOST=$target_host
AR=$target_host-ar
AS=$target_host-as
RANLIB=$target_host-ranlib
CC=$target_host-$cc_compiler
CXX=$target_host-$cxx_compiler
STRIP=$target_host-strip
RC=$target_host-windres

[settings]
os_build=Linux
arch_build=x86_64

os=Windows
arch=x86_64
compiler=gcc

compiler.version=4.9.3
compiler.libcxx=libstdc++11
build_type=Release

#### Command to install
conan install --build="missing" ./conanfile.txt --profile ./linux_to_win64

### Logs (Executed commands with output) (Include/Attach if Applicable)
Current target is windows
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=4.9.3
os=Windows
os_build=Linux
[options]
OpenSSL:shared=False
libcurl:with_openssl=False
[build_requires]
[env]
AR=x86_64-w64-mingw32-ar
AS=x86_64-w64-mingw32-as
CC=x86_64-w64-mingw32-gcc
CHOST=x86_64-w64-mingw32
CONAN_CMAKE_FIND_ROOT_PATH=/usr/bin/x86_64-w64-mingw32 # Adjust this path
CXX=x86_64-w64-mingw32-g++
RANLIB=x86_64-w64-mingw32-ranlib
RC=x86_64-w64-mingw32-windres
STRIP=x86_64-w64-mingw32-strip
zlib/1.2.11@conan/stable: WARN: Package is corrupted, removing folder: /home/saleem/.conan/data/zlib/1.2.11/conan/stable/package/5c347208c5660a7fa0cba07a93e141caf713c3bd
conanfile.txt: Installing package
Requirements
    OpenSSL/1.1.1c@conan/stable from 'conan-center' - Cache
    libcurl/7.66.0@bincrafters/stable from 'conan-center' - Cache
    zlib/1.2.11@conan/stable from 'conan-center' - Cache
Packages
    OpenSSL/1.1.1c@conan/stable:333bcb280187ae83ca23e6c83367d9dd69098fa1 - Build
    libcurl/7.66.0@bincrafters/stable:333bcb280187ae83ca23e6c83367d9dd69098fa1 - Build
    zlib/1.2.11@conan/stable:5c347208c5660a7fa0cba07a93e141caf713c3bd - Build

Cross-build from 'Linux:x86_64' to 'Windows:x86_64'
zlib/1.2.11@conan/stable: WARN: Build folder is dirty, removing it: /home/saleem/.conan/data/zlib/1.2.11/conan/stable/build/5c347208c5660a7fa0cba07a93e141caf713c3bd
zlib/1.2.11@conan/stable: Copying sources to build folder
zlib/1.2.11@conan/stable: Building your package in /home/saleem/.conan/data/zlib/1.2.11/conan/stable/build/5c347208c5660a7fa0cba07a93e141caf713c3bd
zlib/1.2.11@conan/stable: Generator cmake created conanbuildinfo.cmake
zlib/1.2.11@conan/stable: Calling build()
-- The C compiler identification is GNU 4.9.3
-- The CXX compiler identification is GNU 4.9.3
-- Check for working C compiler: /usr/bin/x86_64-w64-mingw32-gcc
-- Check for working C compiler: /usr/bin/x86_64-w64-mingw32-gcc -- broken
CMake Error at /usr/local/share/cmake-3.13/Modules/CMakeTestCCompiler.cmake:52 (message):
  The C compiler

    "/usr/bin/x86_64-w64-mingw32-gcc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/saleem/.conan/data/zlib/1.2.11/conan/stable/build/5c347208c5660a7fa0cba07a93e141caf713c3bd/source_subfolder/_build/CMakeFiles/CMakeTmp
    
    Run Build Command:"/usr/bin/gmake" "cmTC_507ed/fast"
    /usr/bin/gmake -f CMakeFiles/cmTC_507ed.dir/build.make CMakeFiles/cmTC_507ed.dir/build
    gmake[1]: Entering directory `/home/saleem/.conan/data/zlib/1.2.11/conan/stable/build/5c347208c5660a7fa0cba07a93e141caf713c3bd/source_subfolder/_build/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_507ed.dir/testCCompiler.c.obj
    /usr/bin/x86_64-w64-mingw32-gcc --sysroot="/usr/bin/x86_64-w64-mingw32 # Adjust this path"    -o CMakeFiles/cmTC_507ed.dir/testCCompiler.c.obj   -c /home/saleem/.conan/data/zlib/1.2.11/conan/stable/build/5c347208c5660a7fa0cba07a93e141caf713c3bd/source_subfolder/_build/CMakeFiles/CMakeTmp/testCCompiler.c
    Linking C executable cmTC_507ed.exe
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_507ed.dir/link.txt --verbose=1
    /usr/local/bin/cmake -E remove -f CMakeFiles/cmTC_507ed.dir/objects.a
    /usr/bin/x86_64-w64-mingw32-ar cr CMakeFiles/cmTC_507ed.dir/objects.a @CMakeFiles/cmTC_507ed.dir/objects1.rsp
    /usr/bin/x86_64-w64-mingw32-gcc --sysroot="/usr/bin/x86_64-w64-mingw32 # Adjust this path"      -Wl,--whole-archive CMakeFiles/cmTC_507ed.dir/objects.a -Wl,--no-whole-archive  -o cmTC_507ed.exe -Wl,--out-implib,libcmTC_507ed.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/cmTC_507ed.dir/linklibs.rsp
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find crt2.o: No such file or directory
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find crtbegin.o: No such file or directory
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lkernel32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -luser32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lgdi32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lwinspool
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lshell32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lole32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -loleaut32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -luuid
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lcomdlg32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -ladvapi32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmingw32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmoldname
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmingwex
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmsvcrt
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lpthread
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -ladvapi32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lshell32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -luser32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lkernel32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmingw32
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmoldname
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmingwex
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmsvcrt
    /usr/lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld: cannot find crtend.o: No such file or directory
    collect2: error: ld returned 1 exit status
    gmake[1]: *** [cmTC_507ed.exe] Error 1
    gmake[1]: Leaving directory `/home/saleem/.conan/data/zlib/1.2.11/conan/stable/build/5c347208c5660a7fa0cba07a93e141caf713c3bd/source_subfolder/_build/CMakeFiles/CMakeTmp'
    gmake: *** [cmTC_507ed/fast] Error 2
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "/home/saleem/.conan/data/zlib/1.2.11/conan/stable/build/5c347208c5660a7fa0cba07a93e141caf713c3bd/source_subfolder/_build/CMakeFiles/CMakeOutput.log".
See also "/home/saleem/.conan/data/zlib/1.2.11/conan/stable/build/5c347208c5660a7fa0cba07a93e141caf713c3bd/source_subfolder/_build/CMakeFiles/CMakeError.log".
zlib/1.2.11@conan/stable: 
zlib/1.2.11@conan/stable: ERROR: Package '5c347208c5660a7fa0cba07a93e141caf713c3bd' build failed
zlib/1.2.11@conan/stable: WARN: Build folder /home/saleem/.conan/data/zlib/1.2.11/conan/stable/build/5c347208c5660a7fa0cba07a93e141caf713c3bd
ERROR: zlib/1.2.11@conan/stable: Error in build() method, line 59
        self._build_zlib()
while calling '_build_zlib', line 110
        self._build_zlib_cmake()
while calling '_build_zlib_cmake', line 85
        cmake.configure(build_dir=".")
        ConanException: Error 1 while executing cd '.' && cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Release" -DCMAKE_SYSTEM_NAME="Windows" -DCONAN_CMAKE_FIND_ROOT_PATH="/usr/bin/x86_64-w64-mingw32 # Adjust this path" -DCMAKE_SYSROOT="/usr/bin/x86_64-w64-mingw32 # Adjust this path" -DCONAN_EXPORTED="1" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="gcc" -DCONAN_COMPILER_VERSION="4.9.3" -DCONAN_CXX_FLAGS="-m64" -DCONAN_SHARED_LINKER_FLAGS="-m64" -DCONAN_C_FLAGS="-m64" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="/home/saleem/.conan/data/zlib/1.2.11/conan/stable/package/5c347208c5660a7fa0cba07a93e141caf713c3bd" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -Wno-dev '/home/saleem/.conan/data/zlib/1.2.11/conan/stable/build/5c347208c5660a7fa0cba07a93e141caf713c3bd'


<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: mohsalxedflix
issue_5917: state: open
title: [bug] proxy configuration doesn't work according to the docummentation
body: this issue is mainly a follow up on #4678

conan [documentation](https://docs.conan.io/en/latest/reference/config_files/conan.conf.html) says about proxy configuration:
```
[proxies]
# Empty section will try to use system proxies.
# If don't want proxy at all, remove section [proxies]
```
this is not true (as for conan 1.19.2).
first off, by system proxies, I think we mean proxies specified in Windows Registry or System Preferences:
<img width="780" alt="Screenshot 2019-10-14 at 21 06 11" src="https://user-images.githubusercontent.com/870236/66918247-983c7300-f027-11e9-8cdc-280adc1173bf.png">
![proxy_win](https://user-images.githubusercontent.com/870236/66918260-9c689080-f027-11e9-94f6-e159f51e8b73.png)

conan doc says if you remove the section, no proxies at all would be used, but an empty section will result in the usage of system proxies. it's not accurate, both things have the same behavior in conan right now. I wrote two small tests to illustrate that:
https://github.com/conan-io/conan/compare/develop...SSE4:disable_system_proxy?expand=1#diff-0a53a4e1b8896ffb5724afa52a065b22R36

in both cases, system proxies are used. also, if some environment variables are set (e.g. `HTTP_PROXY`) they are used as well in both cases, and environment variables have a priority over system proxies). such environment variables aren't listed in the [reference](https://docs.conan.io/en/latest/reference/env_vars.html).

the code reading proxies from the config:
https://github.com/conan-io/conan/blob/1.19.1/conans/client/conf/__init__.py#L432
```
        try:  # optional field, might not exist
            proxies = self.get_conf("proxies")
        except Exception:
            return None
        result = {}
        ... # parsing here
        return result
```
it may return `None` (for no section) or an `empty dict` (for the empty section), however, the actual usage of this method makes no difference between them:
https://github.com/conan-io/conan/blob/1.19.1/conans/client/rest/conan_requester.py#L33
```
self.proxies = config.proxies or {}
```

also, from the UX perspective, it doesn't look good - why an empty section and no section have to result in a different behavior? it sounds confusing.

however, below the [documentation](https://docs.conan.io/en/latest/reference/config_files/conan.conf.html#proxies) states a bit different behavior:
```
If you are not using proxies at all, or you want to use the proxies specified by the operating system, just remove the [proxies] section completely. You can run conan config rm proxies.

If you leave the [proxies] section blank, conan will copy the system configured proxies
```
the first sentence appears to be matching to the current design (of both empty section and no section behaviors). also, environment variables affecting proxy settings are mentioned briefly here.

anyway, we have to change either documentation or implementation, or both (?)

/cc @uilianries @jgsogo @czoido @memsharded @lasote @danimtb 

<!--
  Please don't forget to update the issue title.
  Include all applicable information to help us reproduce your problem.

  To help us debug your issue please explain:
-->

### Environment Details (include every applicable attribute)
  * Operating System+version:
  * Compiler+version:
  * Conan version:
  * Python version:

### Steps to reproduce (Include if Applicable)


### Logs (Executed commands with output) (Include/Attach if Applicable)

<!--
  Your log content should be related to the bug description, it can be:
  - Conan command output
  - Server output (Artifactory, conan_server)
-->

user: SSE4
issue_5914: state: open
title: Conan doesn't know how to translate it to the GNU triplet
body: To help us debug your issue please explain:

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ ] I've specified the Conan version, operating system version and any tool that can be relevant.
- [ ] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

I am trying to cross compile for aarch64le and I am getting this warning:

> libffi/3.2.1: WARN: Unknown 'aarch64le' machine, Conan doesn't know how to translate it to the GNU triplet, please report at  https://github.com/conan-io/conan/issues

My conan profile is below:

```
[settings]
arch=aarch64le
arch_build=x86_64
build_type=Debug
compiler=qcc
compiler.version=5.4
compiler.libcxx=cxx
os=Neutrino
os.version=7.0
os_build=Linux

[env]
CONAN_CMAKE_TOOLCHAIN_FILE="$PROFILE_DIR/qnx-toolchain.cmake"
```
user: AliAskari
issue_5797: state: open
title: `conan install . ` fails to build libpq while `conan install libpq...` works fine
body: To help us debug your issue please explain:

- [x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.

I've reported bug against [bincrafters/conan-libpq](https://github.com/bincrafters/community/issues/970) that building `libpq` package on `Debian 9 (stretch) amd64` with `conan 1.18.4` and `Python 3.5.3` fails, due to `error while loading shared libraries: libssl.so.1.0.0` error while `configure` of `libpq` is running.

Modifying `libpq` recipe with `with tools.environment_append(RunEnvironment(self).vars):` helps as workaround, but it is not needed if I invoke `conan install` directly, not via qmake.

To reproduce, one can use this minimal `.pro` file, and running `qmake` within same directory:
```
QT =
CONFIG -= app_bundle

#CONAN=/home/vincas/code/cpp/branches/upgrade/3rdparty/Conan/_python_3.5.3_venv_conan_1.18.4/bin/conan
CONAN=conan
system("$${CONAN} install $$quote($$shell_path($${PWD}/conanfile.txt)) --build=missing --install-folder=$$quote($${DESTDIR})")
```

with this `conanfile.txt` that I've used my project:

```
[requires]
OpenSSL/1.0.2s@conan/stable
libpq/11.4@bincrafters/stable

[options]
OpenSSL:no_zlib=True
OpenSSL:shared=True
libpq:with_openssl=True
libpq:with_zlib=False
libpq:shared=True
libpq:disable_rpath=True

[generators]
qmake

[imports]
bin, libeay32.dll -> .
bin, ssleay32.dll -> .
lib, libcrypto.so* -> .
lib, libssl.so* -> .
lib, libpq.so* -> . 
```

We get this output:
```
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=6
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

conanfile.txt: Installing package
Requirements
    OpenSSL/1.0.2s@conan/stable from 'conan-center' - Cache
    libpq/11.4@bincrafters/stable from 'conan-center' - Cache
Packages
    OpenSSL/1.0.2s@conan/stable:b2a09ca1ad3b8c8a33d398a8b1748e063194b54e - Cache
    libpq/11.4@bincrafters/stable:aababde3fc4f8890cb856271d6cfa6c61518983c - Build

OpenSSL/1.0.2s@conan/stable: Already installed!
libpq/11.4@bincrafters/stable: Copying sources to build folder
libpq/11.4@bincrafters/stable: Building your package in /home/vincas/.conan/data/libpq/11.4/bincrafters/stable/build/aababde3fc4f8890cb856271d6cfa6c61518983c
libpq/11.4@bincrafters/stable: Generator cmake created conanbuildinfo.cmake
libpq/11.4@bincrafters/stable: Calling build()
libpq/11.4@bincrafters/stable: Calling:
 > ./configure '--without-readline' '--without-zlib' '--with-openssl' '--disable-rpath' '--prefix=/home/vincas/.conan/data/libpq/11.4/bincrafters/stable/package/aababde3fc4f8890cb856271d6cfa6c61518983c' '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libexecdir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' '--datarootdir=${prefix}/share' 
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking which template to use... linux
checking whether NLS is wanted... no
checking for default port number... 5432
checking for block size... 8kB
checking for segment size... 1GB
checking for WAL block size... 8kB
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... configure: error: in `/home/vincas/.conan/data/libpq/11.4/bincrafters/stable/build/aababde3fc4f8890cb856271d6cfa6c61518983c/source_subfolder':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
libpq/11.4@bincrafters/stable: 
libpq/11.4@bincrafters/stable: WARN: Package is corrupted, removing folder: /home/vincas/.conan/data/libpq/11.4/bincrafters/stable/package/aababde3fc4f8890cb856271d6cfa6c61518983c
libpq/11.4@bincrafters/stable: WARN: Build folder is dirty, removing it: /home/vincas/.conan/data/libpq/11.4/bincrafters/stable/build/aababde3fc4f8890cb856271d6cfa6c61518983c
libpq/11.4@bincrafters/stable: ERROR: Package 'aababde3fc4f8890cb856271d6cfa6c61518983c' build failed
libpq/11.4@bincrafters/stable: WARN: Build folder /home/vincas/.conan/data/libpq/11.4/bincrafters/stable/build/aababde3fc4f8890cb856271d6cfa6c61518983c
ERROR: libpq/11.4@bincrafters/stable: Error in build() method, line 89
	autotools = self._configure_autotools()
while calling '_configure_autotools', line 74
	self._autotools.configure(args=args)
	ConanException: Error 1 while executing ./configure '--without-readline' '--without-zlib' '--with-openssl' '--disable-rpath' '--prefix=/home/vincas/.conan/data/libpq/11.4/bincrafters/stable/package/aababde3fc4f8890cb856271d6cfa6c61518983c' '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libexecdir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' '--datarootdir=${prefix}/share' 
```

And if we look at `/home/vincas/.conan/data/libpq/11.4/bincrafters/stable/build/aababde3fc4f8890cb856271d6cfa6c61518983c/source_subfolder/config.log` file, we see this error:
```
configure:4129: checking whether we are cross compiling
configure:4137: gcc -o conftest -m64 -O3 -s -fPIC -I/home/vincas/.conan/data/OpenSSL/1.0.2s/conan/stable/package/b2a09ca1ad3b8c8a33d398a8b1748e063194b54e/include -DNDEBUG -m64 -L/home/vincas/.conan/data/OpenSSL/1.0.2s/conan/stable/package/b2a09ca1ad3b8c8a33d398a8b1748e063194b54e/lib conftest.c -lssl -lcrypto -ldl -lpthread >&5
configure:4141: $? = 0
configure:4148: ./conftest
./conftest: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
configure:4152: $? = 127
configure:4159: error: in `/home/vincas/.conan/data/libpq/11.4/bincrafters/stable/build/aababde3fc4f8890cb856271d6cfa6c61518983c/source_subfolder':
configure:4161: error: cannot run C compiled programs.
```

I'm not sure what's going on, maybe `qmake` fiddles with `LD_LIBRARY_PATH` or whatever..?
user: Talkless
issue_5779: state: open
title: Promotion of big packages results on corruption in Artifactory
body: From https://github.com/conan-io/conan/issues/2415#issuecomment-532586662

From @GordonJess:

> I have moved some packages to another channel using the Artifactory UI, but the client cannot resolve them:
> 
> ```
> PS C:\my_repo> conan search -r my-repo
> Existing package recipes:
> 
> my-dependency/1.0.0@user/channel
> my-dependency/1.0.0@user/new_channel
> 
> PS C:\my_repo> conan create . user/channel
> ERROR: Error loading conanfile at 'C:\my_repo\conanfile.py': Version range '~=1.0.0' from requirement 'my-dependency/[~=1.0.0]@user/new_channel' required by 'python_require' could not be resolved
> ```
> 
> It works fine if I do `conan copy` and upload again.

> During the copy I did get error messages for some of the larger packages, about the timeout of a file lock or something (sorry I don't have a screenshot on hand). The packages looked ok after, but maybe something got corrupt..!

------------

I tested myself with small packages but it worked fine using the Artifactory UI as the user reported. We will have to test with bigger packages.
user: danimtb
issue_5773: state: open
title: settings.arch armv5te support
body: Please add support/allow armv5te as an architecture option.

Thanks
user: radonish
issue_5762: state: open
title: [workspaces] Workspaces should be Super Builds
body: These comments were relevant as of version 1.18.

We were early adopters of Workspaces and we continue to rely it for our workflow. Unfortunately, the changes introduced in 1.13, have broken our workflow and we're stuck at a previous version of Conan. I have seen and commented on issues that are components of workspaces and deal with the issues I'm going to discuss (#4840, #4004, #4803, #4751, #5291, #4802, #4800) but I feel like we need an issue to discuss the design as a whole. My main focus is workspaces, but I'll share some opinions on editables as well, since they are closely related. Here is some feedback.

TLDR: Layouts, editables, and the current CMake workspace generator feel off the mark to me. I need more of a super build that retains the features we know and love from Conan.

## Layouts
Layout files allow you to manually provide the paths Conan needs to generate conaninfo files. This is motivated by the fact that most packages in development have not had an install step and, therefore, the paths to libs, headers, and bins are somewhere in the build directory. Dependent packages need an alternate `package_info` to tell them where to find the goodies they need in the build directory.

Unfortunately, layout files are problematic for several reasons:
- **Layout files can conflict with reality**. Layout files allow you to specify externally what is happening internally, and the two can easily be in conflict. Layout files give the illusion that you can direct Conan to copy the output files to those locations, when actually you're simply telling Conan where you expect those files to end up in the build directory. In other words, layout files are presented as a remapping of output file locations, when actually they force Conan to look at particular location, whether the files are there or not.
- **It defeats the convenience of package_info**. The ability of a package to fill out its own info is a tremendous power of Conan. It allows dependent packages to automatically pick up paths and other features. This is analogous to modern CMake's use of `target_link_libraries`, which passes along include directories, library paths, and usage requirements. Using layout files, `package_info` is overridden with a manual file the consumer has to provide with some internal knowledge of the inner-workings of the package.

  Conan does provide [a way](https://docs.conan.io/en/latest/developing_packages/editable_packages.html#editable-packages-layouts) to specify this layout within `package_info`. IMHO, this is much preferred, since it is the recipe that knows where the output files live. (See above - the user shouldn't have to assume these locations externally). The issue I have with this is the reliance on the `self.in_local_cache` switch. The condition should not be whether the recipe is being consumed from the local cache (in fact a recipe shouldn't know about the cache at all). The condition should be if the consumer is consuming from the build directory or the package directory. There is a direct CMake analog for this as well: [package layout](https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#package-layout) config files. Look at the following `CMakeLists.txt`:
  
  ```cmake
  add_library(ClimbingStats climbingstats.cpp)
  target_include_directories(ClimbingStats INTERFACE
                             $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/generated>
                             $<INSTALL_INTERFACE:relative/path>
                             $<INSTALL_INTERFACE:$<INSTALL_PREFIX>/$<CONFIG>/generated>
  )
  ```

  You can see that the include directory is specified for both scenarios: if you're consuming from the build folder or if you're consuming from the install folder. CMake will generate a configuration file for each that contains all of the necessary include paths and usage requirements. (The actual config file generation is not shown in that snippet, but it involves CMake export and install functions).
  
  CMake is right to rely on the package's `CMakeLists.txt` to define how to consume the package. Similarly, Conan should do the same within the recipe. The ability to do this in `package_info` is sufficient, but we need a better condition than `in_local_cache` and a way for workspaces to trigger the in-build condition.
- **New syntax for the same mechanism**. Given that `package_info` and the full power of python is already available. Why introduce Jinja templating? Obviously this is necessary if you're going to do layout files in the ini format, but this only reinforces the notion that this logic should be in the recipe itself, not provided externally with new syntax.
- **Out-of-source builds are broken**. Layout files hardcode paths. There are some Jinja template expressions, but these are quite limited. Right now, the only way to do an out-of-source build is to blindly go up directories in relative path (ie. `../build`). Not only is this dangerous (could overwrite an existing directory), it doesn't allow the user control over where the build directory is. This is especially critical when the user wishes to build more than one configuration at the same time with multiple build folders. CMake does things relative to `CMAKE_CURRENT_BINARY_DIR` or `INSTALL_PREFIX` and Conan should follow suite.

## Editables
Editables allow you to short-circuit Conan to point to some local copy of a recipe instead of fetching it from the local cache. It does this globally for any other recipe that refers to it. As a developer who works on many things at once, this is problematic. It is too big of a hammer to globally override Conan to point to a alternate recipe for any and all dependent packages that reference it. I will happily continue to use workspaces, which explicitly states the intent for co-developed recipes and leaves the others alone. Please consider workspaces as the non-global editable and keep that functionality.

## CMake Generator
The CMake Generator creates a cmake script that will `add_subdirectory` on the source folders (defined in the layout file). The actual generated script isn't very useful.

When you're developing recipes, you rely on `conan build` to perform non-trivial build steps. It is very useful to be able to reuse the settings and options in the recipe during the build. Even for end consumers, we use `conan build` as recommended in [Mastering Conan](https://docs.conan.io/en/latest/mastering.html#mastering-conan). By using the generated cmake script, you lose this ability.

## User/Channel
Why has user and channel been added as a requirement to the workspace file? When you are specifying the local path to the package in the workspace file, user and channel (and even version number) are meaningless.

## Some Suggestions
I can see workspaces being used in two modes:
### Super Build
This is the primary use-case. I have unique packages that I own and want to develop, sometimes together, sometimes individually. I temporarily create a workspace file that indicates my intent to develop them together. When I issue a `conan workspace` command, instead of generating a script with a bunch of `add_subdirectory` calls, it would generate a script with custom commands or similar that would invoke `conan install` and `conan build`. By doing this, you would gain:
- All of the `conan build` arguments, settings, options still work
- The packages don't need to be CMake anymore - you've enabled heterogeneous package co-development through the shared language of Conan
- The generated super build (can be a CMake script) can ensure that things rebuild when upstream package source changes 
- You could potentially also call `conan package` as part of the custom command and then all of the special build folder mapping goes away
- Layout files are completely unnecessary. `conan build` already knows where and how to build the source, `package_info` already knows how to communicate paths and artifact info.
- Editables are unnecessary. Since workspaces are easier to specify without layouts, it should be preferred to make the non-global choice.

### Self-Managed Build
In some cases, the source code of multiple packages are **always** developed together and their relative source locations are deterministic. This would be the case in a monorepo or git submodule situation. (This happens to be how I am using workspaces). In this case, I have my own `CMakeLists.txt` that knows where to `add_subdirectory` and a root `conanfile.py` that builds the monorepo via `conan build`. I also have other `conanfile.py` files scattered throughout the monorepo because packages within the monorepo should declare their own dependencies and remain independent, even if they are source controlled together. Finally, I have checked in a workspace file, because these packages are necessarily developed together. The workspace is critical to building the monorepo.

In this scenario, what I need from Conan is to walk all the dependencies and install all of the third-party packages like it normally would in a `conan install`. This is something I could do prior to Conan 1.13, although there were a few warts.

I think the **Self-Managed Build** is really just a special case of the **Super Build** where I don't bother to use the generated super build script and instead use my own `CMakeLists.txt`.




To help us debug your issue please explain:

- [x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.


user: kenfred
issue_5726: state: open
title: A problem passing options to the recursively required package
body: I am trying to find a way to specify an option during  a top-level build, so it will be recursively passed to all required packages. I can do this in the ``config_options()`` method for explicitly specified packages, but these settings are not passed down the dependencies tree. To be more precise, I have the following:

In ``conanfile.py`` from package ``A``:

```
requires = ["B/1.0@user/channel"]
def config_options(self):
    self.options["B"].my_option = self.options.my_option
```
In ``conanfile.py`` from package ``B``:

```
requires = ["C/1.0@user/channel"]
def config_options(self):
    self.options["C"].my_option = self.options.my_option
```

When building package ``A``, ``my_option`` value is correctly passed to the package ``B``, but not to the package ``C``.
Is there any other way to solve the problem I have?
user: perfhunter
issue_5719: state: open
title: Collision when jointly using deactivate.sh and deactivate_run.sh
body: To help us debug your issue please explain:

- [x ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ 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.

The scripts generated with virtualenv and virtualrunenv generators have a problem:
They both use the same environment variable OLD_PS1 and hence collide with each other during deactivation.

I suggest do define a variable OLD_PS1_RUN in the virtualrunenv generator in order to avoid the collision.
user: johschmitz
issue_5706: state: open
title: Problem to upload package on Artifactory
body: Hello,

I got a problem to upload package on Artifactory.

First I compile 2 package with some commands lines -> it worked well. 
~~~
conan create . ix/stable -s build_type=Debug -s compiler.version=15
conan create . ix/stable -s build_type=Release -s compiler.version=15
~~~

Second I compile 4 package with other commands lines with the same receipe -> It failed on uploading package.
~~~
conan create . ix/stable -s compiler.version=15 -s arch=x86 -s build_type=Debug -s compiler="Visual Studio" -s compiler.runtime="MDd"
conan create . ix/stable -s compiler.version=15 -s arch=x86_64 -s build_type=Debug -s compiler="Visual Studio" -s compiler.runtime="MDd"
conan create . ix/stable -s compiler.version=15 -s arch=x86 -s build_type=Release -s compiler="Visual Studio" -s compiler.runtime="MD"
conan create . ix/stable -s compiler.version=15 -s arch=x86_64 -s build_type=Release -s compiler="Visual Studio" -s compiler.runtime="MD"
~~~

On upload it give me:

~~~
conan upload '*Minizip*' --all -r artix -c --no-overwrite all
Uploading to remote 'artix':
Uploading Minizip/1.2@ix/stable to remote 'artix'
Recipe is up to date, upload skipped
Uploading package 1/4: 009a50ddeb47afbc9361cbc63650560c127e1234 to 'artix'
Compressing package...
[==================================================]
ERROR: Local package is different from the remote package. Forbidden overwrite.
~~~

If I test without `--no-overwrite` flag.
~~~
conan upload '*Minizip*' --all -r artix -c
~~~

The error is 
~~~
Uploading to remote 'artix':
Uploading Minizip/1.2@ix/stable to remote 'artix'
Recipe is up to date, upload skipped
Uploading package 1/4: 009a50ddeb47afbc9361cbc63650560c127e1234 to 'artix'
Requesting upload urls...Done!
Uploading conan_package.tgz: 100%|##########| 125k/125k [00:00<00:00, 18.8MB/s]
ERROR: 500 Server Error: Internal Server Error for url: https://binaries.ixblue.com/artifactory/api/conan/conan-public/v1/files/ix/Minizip/1.2/stable/0/package/009a50ddeb47afbc9361cbc63650560c127e1234/0/conan_package.tgz
Waiting 5 seconds to retry...
~~~

On artifactory server, the user don't have any rights to DELETE packages.

The "conanfile.py" is the same as the first time executed, but the commands to compile the package are not the sames.

It always fail on the first package and never upload the missing packages.


~~~
Conan: version 1.8.2
Operating System: Windows 7 SP1
Compiler: Visual Studio 2017

Artifactory Internal Server: Version 6.10.0
~~~

They seems to be related to :
https://github.com/conan-io/conan/issues/3473
https://github.com/conan-io/conan/issues/3732

But these issues are fixed (and seems to be inside the version of conan used)

----

To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.


user: Ti-R
issue_5664: state: open
title: provide means to make packages relocatable
body: - [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ ] 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.

In my eyes relocation is one of the biggest hurdles to using package managers with C/C++ binaries. I have a humble request that conan should help to make packages relocatable. Specifically, conan should integrate methods that help when a package install path is different on the target host from the path on the source host, and the package contains hard coded path references.

This problem appears for a significant number of libraries on most Un*x and sometimes on Windows platforms. While at first it may seem better to solve the issue at the root (upstream libraries) in practice this is virtually impossible due to the sheer number of affected build systems and libraries.

The user story is: Many C++ libraries contain references to their install path. For example, high impact libraries Qt and HDF5 have binary and text configs with hard coded install paths. Installing these packages into a different path breaks the libraries. The same is true for a major number of pkg-config-enabled libraries as well as many autotools-built libraries. Furthermore, on Un*x, many libraries feature a fixed `RPATH` or `RUNPATH` that points to the install location. This effectively makes it very challenging for users for build libraries with path `X` and later install into path `Y`. However in multi-user environments or distributed build environments exactly this is often required, that install machines can not mimic the paths of CI machines.

In my humble opinion this issue can be best solved in conan. In practice the issue can *not* easily be solved at the source. Solving this in conan will have many benefits to the larger community:
 - Relocatable binary packages allow for much more flexibility in the build system and install system because paths do not need to match.
 - I.e. in cloud-based builds there can be tight constraints about paths that can be cumbersome to match on the target host
 - Relocatable binary packages will make conan significantly more useful because it enables new user groups.
 - Resolving this issue *without* the help of a package manager is cumbersome because it affects the gros of C/C++ libraries and it can be challenging because it may require knowledge of the install path on the target machine (that is often unknown at build time).

conan has all required information to aid in relocating packages:
- conan knows the package path at build time and can store it in the package
- conan knows the package install path on the target machine and can put it in place of the build time path
- conan already supports the concept of post-package- and post-install-hooks where this functionality can be integrated.

Therefore I'd like to suggest a "best effort" approach. The responsibility of creating actual post-package- and post-install-scripts that fixup paths should be with the package maintainer. Community will need to ensure packages are relocatable as required. conan should provide high-level methods that help in making paths relocatable. The two predominant types of paths are:
 - shared library `RPATH`/`RUNPATH` on platforms that support this concept
   - These can be modified using tools like `chrpath`
 - text path strings in configuration files
   - These can be modified by textual search-and-replace

To help in the process, the path handling methods may need to provide means to ensure that all types of paths are treated correctly. I.e. the path `/a/b/c` may or may not be the same as `//a\b\\\\c`.
user: emmenlau
issue_5618: state: open
title: [suggestion] Creation date should be considered when multiple compatible pkgs are available on artifactory
body: As far as I could see in `range_resolver.py`, the creation date of the package is not considered when matching requirements if multiple compatible packages are available on artifactory. 

Say we have the following versions on artifactory:
1.0.0+meta1 (created 01:00)
1.0.0+meta2 (created 02:00)
1.0.0+meta3 (created 03:00)

and a semver expression to request a simple range version:
\>1.0.0

Since we are 'max_satisfying', I would expect the newest available version (1.0.0+meta3) to be returned as the result, but it seems this is not the case.
user: GordonJess
issue_5566: state: open
title: Lightweight workspaces aka Temporary editables
body: To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.

Documentation states, that workspaces are similar to editables, just not system-wide ones. Unfortunately, it is not exactly correct: current workspaces do require a lot of additional parameters like roots etc, which are not like non-system-wide editables, and prevents such a workflow (for example, by demanding relative path between sources and build directory, which is not always possible - say, C: and D: drives on Windows).

We are suggesting new simple feature: optional argument for _conan install_ command - filename of the workspace file, that contains ONLY list of editables (or other fields are ignored, whatever, you choose best). If this parameter is set, Conan performs "editable add" for each element of list in-memory, without changing global configuration, and then performs _conan install_ action, as usual (works perfecly with custom generators). 

One can see, we are suggesting literally "editables, just not system-wide ones", for us that would be ideal (also I believe I saw other teams mentioned in issues it will be good for their workflow too). 

This feature is finite (no need to iterate syntax etc as long as performs same as "editable add" but in memory), and simple to implement (we prototyped it in local fork in few hours, and we are not experts in Conan sources at all).

Please consider implementing "lightweight workspaces/temporary editables" in nearest releases, if possible.
user: ezaiakinsc
issue_5554: state: open
title: [suggestion] Buildroot integration
body: To help us debug your issue please explain:

Hi!

Some time ago I used [buildroot](https://buildroot.org/) to build embedded Linux images. It's like Yocto, but much simpler and feature limited. It does not contains meta-layers, but a Makefile for each package. As any other build system you need to spend some time at first build, so I introduced Conan. The idea is: install pre-built packages rather than building from sources. I remember that my first build took ~45min, using Conan it was reduced to ~2min.

I would like to shared this idea, as Yocto is ready and working with Conan.

To integrate Conan with Buildroot, I think we need to follow some steps:

- [ ] Add a Conan generator for buildroot
- [ ] Update Conan docs with Build root generator
- [ ] Update Conan docs: How to use buildroot with Conan
- [ ] Write a blog post ONLY about buildroot (introduction)
- [ ] Write a blog post about Conan integration with Buildroot (one week interval)

![conan-buildroot](https://user-images.githubusercontent.com/4870173/62071206-6975e400-b212-11e9-934a-24398d3690ad.png)

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ ] I've specified the Conan version, operating system version and any tool that can be relevant.
- [ ] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.


user: uilianries
issue_5528: state: open
title: [question] Virtual environment with activate.sh under Windows
body: To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.

## Environment
OS: Windows 7 Enterprise
Conan version: 1.15.1 (installed via pip)
Python: 3.7.2

## Problem
We encountered a problem when launching virtual environment with activate.sh under Windows.
We launch it from Git bash:
"`source activate.sh`"
But the PATH seems not to be appended correctly (the slashes are wrongly set)
(`PATH="C:\Users\uid95125\.conan\data\Tool1\2.0.0\conti_gen_dev1\stable\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\bin"${PATH+:$PATH}`)
When we try to launch our bash script in the virtual environment it cannot be found (due to the wrongly created PATH)
After we manually change the path (slashes) in "activate.sh" and activate again the virtual env ("`source activate.sh`"), the tool (bash script) can be called. 
(`PATH="/C/Users/uid95125/.conan/data/Tool1/2.0.0/conti_gen_dev1/stable/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/bin"${PATH+:$PATH}`)

## Detailed use case
Here is the detailed use case (under Windows):
- one of our teams has a tool with a bash script stored in Artifactory
- we have a conanfile.txt for the consumer:
```
[requires]
Tool1/2.0.0@conti_gen_dev1/stable
[generators]
virtualenv
```
- the consumer runs `conan install .`
- the package is retrieved in local cache and the scripts for activating/deactivating the virtual env are generated (activate.sh/bat/ps1)
=>activate.sh:
```
OLD_PS1="$PS1"
export OLD_PS1
PS1="(conanenv) $PS1"
export PS1
PATH="C:\Users\uid95125\.conan\data\Tool1\2.0.0\conti_gen_dev1\stable\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\bin"${PATH+:$PATH}
export PATH
```
- the consumer runs from bash `source activate.sh`
- consumer runs the tool: 
`source first_sh.sh`
=> tool can not be run as the path is wrongly built
- we modified manually the activate.sh and changed the slashes in the PATH
=> activate.sh
```
OLD_PS1="$PS1"
export OLD_PS1
PS1="(conanenv) $PS1"
export PS1
PATH="/C/Users/uid95125/.conan/data/Tool1/2.0.0/conti_gen_dev1/stable/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/bin"${PATH+:$PATH}
export PATH
```
- after launching  the changed activate.sh 
	- the path is set correctly
	- the tool could be run properly `source first.sh`
	
I have attached also the output when the virtual environment sets the path wrong and when it is set correctly:
[RunNOK.txt](https://github.com/conan-io/conan/files/3421555/RunNOK.txt)
[RunOK.txt](https://github.com/conan-io/conan/files/3421556/RunOK.txt)

## Questions
Can you help us with this? Are we doing the things wrong? 
If someone has a tool which is a bash script how shall this be found?
Is this the expected behavior of activate.sh under Windows (or is a bug)?
Do you propose a workaround for our use case?
user: CristinaBa
issue_5526: state: open
title: [question] Cygwin and include paths
body: Hi,

I want to build the gtest package using cygwin with the following comand:

conan install -s arch=x86_64 -s os.subsystem=cygwin -s compiler=gcc -s compiler.libcxx=libstdc++11 -s compiler.version=7 "../.." --build missing

I get the following error
****source_subfolder/src/gtest-all.cc:39:10: fatal error: gtest/gtest.h: No such file or directory****

I believe the include paths are were not set correctly. Excerpt from flags.make:

CXX_INCLUDES = -IC:/cygwin64/home/User/.conan/data/gtest/1.7.0/bincrafters/stable/build/0d5c2358ea4208b7cb217c633ff8e47b2a094256/source_subfolder/C:/cygwin64/home/User/.conan/data/gtest/1.7.0/bincrafters/stable/build/0d5c2358ea4208b7cb217c633ff8e47b2a094256/source_subfolder/include -IC:/cygwin64/home/User/

When I build the package manually(using the downloaded gtest CMakefiles.txt) the include paths are set correctly:

CXX_INCLUDES = -I/home/User/.conan/data/gtest/1.7.0/bincrafters/stable/build/0d5c2358ea4208b7cb217c633ff8e47b2a094256/source_subfolder/include -I/home/User/.conan/data/gtest/1.7.0/bincrafters/stable/build/0d5c2358ea4208b7cb217c633ff8e47b2a094256/source_subfolder 

Am I missing some option in the install command? I'm using conan  1.12 + cmake  3.6.2 on cygwin

user: selassje
issue_5513: state: open
title: [feature request] add support for simultaneous multiple conan caches
body: This idea was first discussed in issue #5498 in [this comment](https://github.com/conan-io/conan/issues/5498#issuecomment-512525224).

The idea is to enable conan to support multiple conan data folders simultaneously. The packages that are dependencies of the package being installed would be installed into the default cache folder and the current package could be exported into the ephemeral local cache required just for testing.

The motivation for this comes from the following example: let's say that my repository contains two packages `A` and `B`. `B` depends on `A` and they always need to be developed together (think of an example with `OcrEngine` and `OcrEngineModelBuilder` from the description of issue #4753). So, in order to ensure that package `B` can be tested with `conan test`, it also needs the same version of package `A`, which is still not exported. If multiple conan cache folders were supported, the Jenkins executor could export both `A` and `B` into its temporary folder to perform the `conan test`, while still using the default conan cache for other dependencies of `A` and `B`.

If the same package is found in multiple cache folders, an error could be raised which could be corrected by specifying from which cache the package should be consumed.
user: DoDoENT
issue_5505: state: open
title: Race condition while multiple conan processes are installing the same package
body: This happens for as long as I've been using conan - since version 1.4.0 and also happens with recent versions of conan (1.16.1 and 1.17.0). Basically, what happens is the following:

- two different packages `A` and `B` are being installed in parallel on CI server, like Jenkins, where all executors share the same conan cache
- both packages have, either direct or transitive, dependency to the same package `Pkg` and the same package ID (for example, this could be a header-only package, like Eigen or Boost, but the problem also happens with non-header-only packages as long as two concurrent processes are attempting to install the same package ID of the same package).
- package `Pkg` does not exist in the shared cache, so it needs to be installed from the Artifactory server
- both installation processes observe that and start the installation process
- the first process (installation for package `A`) creates a cache lock file and proceeds to download the package `Pkg` from the server, optionally building it from the recipe.
- the second process (installation for package `B`) observes the lock file and waits for it to be cleared
- the first process finishes the package installation, removes the lock file and proceeds with building the package `A`
- the second process observes that lock file has been removed, **does not check again whether the specific ID of the `Pkg` now exists** and proceeds to the installation of the `Pkg`. During installation, it first deletes the contents of the `Pkg` package, then downloads the package from the server and optionally builds it from the recipe.
- in the meantime, package `A` is already being built in the first process while the second process cleared the package that was installed before. This causes the build failure for `A` which usually manifests itself with one of the following three symptoms:
    - (very often) cmake configuration fails due to conan targets pointing to non-existing folders within the package folder cleared by the second process
    - (often) compilation failure due to the missing headers that should be found in the folder cleared by the second process
    - (very rare) link error due to the missing library that should be located in the folder cleared by the second process

I think this could be avoided if the package installation should re-check for the existence of the package after it passes the lock, instead of blindly delete the folder and start the installation again.

Furthermore, I would argue that cache lock files could be more fine-grained. Currently, the entire package is locked, although it is perfectly safe to install debug and release version of the same package concurrently (different package IDs).

user: DoDoENT
issue_5483: state: open
title: bash completion for conan
body: Hello, 
I'm a regular user of conan for both personal and professional projects.
Conan is an awesome tool. I want to thank the conan community for all the hard work you have done.

Since I'm typing a lot of conan commands I wrote a bash completion script of conan commands to increase UX experience. I don't think this feature exists so I cleaned my script and published it to my gitlab.
You can check it there and test it if you want to.
https://gitlab.com/akim.saidani/conan-bashcompletion

At work we are using it, I hope it will enhance your conan experience too and feel free to give me some feedbacks.


user: akanegally
labels: component: ux: No changes to core business logic
issue_5463: state: open
title: [enhancement] QNX support for targets and standard library settings
body: hi there,
as Conan now starts to support QNX Neutrino, I would like to specify a more correct behaviour of Conan regarding compiler flags, etc.

architecture selection
----------------------
As of now Conan does not seem to support selecting the correct architecture for QNX targets.
The QCC command line needs the correct _QNX named target_ to load the correct configuration for the later GCC invocation. This means one has to provide the parameter ```-V```.
I did not find any traces of such thing (by searching the repo for "-V" or "aarch64").

What Conan has to do is a mapping between Conan's ```arch``` setting and the correct QNX target:

| Conan  (arch) | QNX (arch) | QCC target (-V)  | Comment (confirmed)                                                                                                                                                                   |
|---------------|------------|------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| armv7         | armv7le    | gcc_ntoarmv7le   | QNX SDP 7.0 or later                                                                                                                                                                  |
| armv8         | aarch64le  | gcc_ntoaarch64le | QNX SDP 7.0 or later                                                                                                                                                                  |
| x86_64        | x86_64     | gcc_ntox86_64    | QNX SDP 7.0 or later                                                                                                                                                                  |
| x86           | x86        | gcc_ntox86       | QNX SDP 6.5 or later                                                                                                                                                                  |
| arm           | armle      | gcc_ntoarmle     | QNX SDP 6.5 - using [ARMv4 instructions](http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_technotes/QNX_for_ARMv7_Cortex_Processors.html?cp=13_10_13#MIG_Overview) |
| sh4le         | shle       | gcc_ntoshle      | QNX SDP 6.5                                                                                                                                                                           |

The table shows only mappings to ```little endian``` targets (like ```armv7le```). As the default QNX SDP (version 6.5 or later) does not provide support via the standard installation for any other targets which differentiate between endianess and ```little endian``` is a kinda standard for *nix/*BSD systems this could be the default for now. Anyway one could always introduce additional archs in the ```settings.yml```.

runtime library
----------------
In the Conan code Conan sets compiler flags according to the ```libcxx``` setting.
All compilers before QNX 7 (QNX 6.6 and lower) support selecting the library only by their setting ```-Y gpp``` or by directly choosing the exact target e.g. ```-Vgcc_ntox86_gpp``` (those can be a combination -> -Vgcc_ntox86 -Y_gpp).
QNX SDP 6.5 compiler -> [docs](http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2Fcom.qnx.doc.neutrino_utilities%2Fq%2Fqcc.html)
QNX SDP 6.6 compiler -> [docs](http://www.qnx.com/developers/docs/6.6.0_anm11_wf10/#com.qnx.doc.neutrino.utilities/topic/q/qcc.html)
QNX SDP 7.0 compiler -> [docs](http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.utilities/topic/q/qcc.html)

The current implementation would be fine until (including) QNX SDP 6.6.
https://github.com/conan-io/conan/blob/64adf71cc691ef9c53aaf1331b8a9db0a89abe84/conans/client/build/compiler_flags.py#L77

Now since QNX SDP 7 (QCC 5.4) the QCC learned the parameter ```stdlib``` analog to the common GCC parameter.
This would mean Conan could use the normal GCC settings for QCC 5.4 or higher.
The following code is adapted from code I would write in a recipe. As this is a Conan internal function (see code link above) this should be considered as **pseudo-code**.

-stdlib= | -Y | Library
-- | -- | --
libc++ | _cxx | LLVM C++
libstdc++ | _gpp | GNU C++

```python
    elif str(compiler) == "qcc":
        if (tools.Version(str(compiler.version)) < "5.4"):
            return "-Y _%s" % str(libcxx)
        else:
            # libc++ = _cxx = LLVM C++
            # libstdc++ = _gpp = GNU C++
            return "-stdlib=%s" % str(libcxx)
```
Tthe ```settings.yml``` has to be extended to support the more common setting in the future for ```libc++``` and ```libstdc++```.

standard C/C++ dialect
------------------------
QNX SDP 7.0 (QCC 5.4) learned another common setting from GCC ([docs](https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/C-Dialect-Options.html#C-Dialect-Options)): ```std=language```
This means Conan can introduce the common setting ```cppstd``` in the ```settings.yml``` and provide that to the normal build-flow.

| standard       | GCC                                                                                                   | comment                                                                                                                                                              |
|----------------|-------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| c++98  gnu++98 | >= [3.3.6](https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/C-Dialect-Options.html#C%20Dialect%20Options) | supported at least since QNX SDP 6.4 with [QCC/GCC 4.2.4](http://www.qnx.com/products/index_sdp_640.html) |
| c++11  gnu++11 | >= [5.1.0](https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/C-Dialect-Options.html#C-Dialect-Options)     | supported since QNX SDP 7.0 with [QCC/GCC 5.4](http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.utilities/topic/q/qcc.html)                            |
| c++14  gnu++14 | >= [5.1.0](https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/C-Dialect-Options.html#C-Dialect-Options)     | supported since QNX SDP 7.0 with [QCC/GCC 5.4](http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.utilities/topic/q/qcc.html)                            |

For GCC ```-std=language``` parameter Conan has a function here: https://github.com/conan-io/conan/blob/a050ed94034b27ae3d394b5abaeb815fac20f1b8/conans/client/build/cppstd_flags.py#L164

This means that Conan could introduce another function for QCC like ```_cppstd_qcc``` (what I think should be preferred and just call the GCC function then) or directly use the GCC function variant.
```python
def _cppstd_qcc(qcc_version, cppstd):
    return _cppstd_gcc(qcc_version, cppstd)
```

Additionally the following line has to be added to the ```settings.yml``` to the ```compiler.qcc```-section:
```yml
        cppstd: [None, 98, gnu98, 11, gnu11, 14, gnu14]
```
user: Johnnyxy
issue_5439: state: open
title: Add -e argument to commands other than create/install/info
body: I am trying to build generic recipes that can build multiple different repositories that follow the same guidelines/build system.  When the recipe for a particular library is exported, I need to be able to save some additional information, which I am currently passing as environment variables (not finding a better alternative).

Being able to pass those through the command line rather than actually setting them in the environment would be useful.

Conan version 1.16.0
OS: currently testing macos, but I want this cross-platform linux/macos/windows

user: dribeas
issue_5434: state: open
title: Can't upload a package to artifactory using CONAN_LOGIN_USERNAME and CONAN_PASSWORD
body: - [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.

### Issue
We're unable to upload a package into a artifactory hosted conan server using the CONAN_LOGIN_USERNAME and CONAN_PASSWORD method of authentication. Rather than authenticating and uploading, the conan command errors with `ERROR: 404: Not Found. [Remote: conan_remote]` 

### Environment
Current Conan Version:  1.16.1 
Previous Working Conan Version: 1.12.3
Artifactory Version: 6.10.2 

### Expected Behavior
The conan upload command should see the CONAN_LOGIN_USERNAME and CONAN_PASSWORD environment variables on the command line and use these to authenticate

### Releated Issues
I believe a similar issue was briefly explored in #4930 however the fact that the environment variables weren't respected was not addressed and it focused on the 404 status

### Command and output with logging level 10
```
$ CONAN_LOGGING_LEVEL=10 CONAN_LOGIN_USERNAME=conan_username CONAN_PASSWORD=conan_password conan upload -r conan_remote --all boost-python36/1.59.0@build/prod
DEBUG :conan_api.py   [160]: INIT: Using config '/home/user/tholzer/.conan/conan.conf' [2019-07-02 11:33:53,934]
DEBUG :tracer.py      [152]: CONAN_API: upload(confirm=False,package=None,remote_name=conan_remote,pattern=boost-python36/1.59.0@build/prod,policy=None,retry_wait=None,all_packages=True,integrity_check=False,query=None,retry=None) [2019-07-02 11:33:53,966]
Uploading to remote 'conan_remote':
Uploading boost-python36/1.59.0@build/prod to remote 'conan_remote'
DEBUG :rest_client_common.py[110]: REST: ping: http://artifactory.company.com/artifactory/api/conan/conan-repo/v1/ping [2019-07-02 11:34:03,342]
DEBUG :rest_client_common.py[136]: REST: get: http://artifactory.company.com/artifactory/api/conan/conan-repo/v1/conans/boost-python36/1.59.0/build/prod/digest [2019-07-02 11:34:03,364]
DEBUG :rest_client_common.py[38]: REST ERROR: <class 'conans.errors.NotFoundException'> [2019-07-02 11:34:03,376]
DEBUG :rest_client_common.py[102]: REST: Check credentials: http://artifactory.company.com/artifactory/api/conan/conan-repo/v1/users/check_credentials [2019-07-02 11:34:03,427]
DEBUG :rest_client_common.py[136]: REST: get: http://artifactory.company.com/artifactory/api/conan/conan-repo/v1/conans/boost-python36/1.59.0/build/prod [2019-07-02 11:34:03,491]
DEBUG :rest_client_common.py[38]: REST ERROR: <class 'conans.errors.NotFoundException'> [2019-07-02 11:34:03,504]
DEBUG :rest_client_common.py[130]: REST: post: http://artifactory.company.com/artifactory/api/conan/conan-repo/v1/conans/boost-python36/1.59.0/build/prod/upload_urls [2019-07-02 11:34:03,556]
DEBUG :rest_client_common.py[38]: REST ERROR: <class 'conans.errors.NotFoundException'> [2019-07-02 11:34:03,568]
ERROR: 404: Not Found. [Remote: conan_remote]
```
user: tylerholzer
issue_5396: state: open
title: Strange behavior of Artifactory remote repos
body: Trying to find an interim solution for #5175 I set up remote Artifactory repos for conan-center (https://conan.bintray.com) and bincrafters (https://api.bintray.com/conan/bincrafters/public-conan) conan repos and used them for CI jobs. I expected Artifactory to get packages from its local cache when they are available and don't waste precious time requesting the remote for anything, but Artifactory logs show quite different behavior. Why?

```
...
2019-06-25 10:57:52,284 [http-nio-8081-exec-4] [INFO ] (o.a.r.HttpRepo      :432) - bincrafters downloading https://api.bintray.com/conan/bincrafters/public-conan/v2/conans/boost_iterator/1.66.0/bincrafters/stable/revisions/0/packages/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/revisions 192 bytes 
2019-06-25 10:57:52,288 [http-nio-8081-exec-4] [INFO ] (o.a.r.HttpRepo      :445) - bincrafters downloaded  https://api.bintray.com/conan/bincrafters/public-conan/v2/conans/boost_iterator/1.66.0/bincrafters/stable/revisions/0/packages/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/revisions 192 bytes at 62.18 KB/sec
2019-06-25 10:57:56,774 [http-nio-8081-exec-4] [INFO ] (o.a.r.HttpRepo      :432) - conan-center downloading https://conan.bintray.com/v2/conans/boost_level5group/1.66.0/bincrafters/stable/revisions 98 bytes 
2019-06-25 10:57:56,778 [http-nio-8081-exec-4] [INFO ] (o.a.r.HttpRepo      :445) - conan-center downloaded  https://conan.bintray.com/v2/conans/boost_level5group/1.66.0/bincrafters/stable/revisions 98 bytes at 33.21 KB/sec
2019-06-25 10:57:56,973 [http-nio-8081-exec-4] [ERROR] (o.a.a.c.r.ConanV2RemoteRepoHandler:261) - Unable to fetch latest revision from 'https://conan.bintray.com/v2/conans/boost_level5group/1.66.0/bincrafters/stable/latest': HTTP/1.1 404 Not Found
2019-06-25 10:57:58,405 [http-nio-8081-exec-3] [INFO ] (o.a.r.HttpRepo      :432) - bincrafters downloading https://api.bintray.com/conan/bincrafters/public-conan/v2/conans/boost_mpl/1.66.0/bincrafters/stable/revisions/0/packages/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/revisions 187 bytes 
2019-06-25 10:57:58,421 [http-nio-8081-exec-3] [INFO ] (o.a.r.HttpRepo      :445) - bincrafters downloaded  https://api.bintray.com/conan/bincrafters/public-conan/v2/conans/boost_mpl/1.66.0/bincrafters/stable/revisions/0/packages/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/revisions 187 bytes at 11.66 KB/sec
2019-06-25 10:58:00,790 [http-nio-8081-exec-8] [INFO ] (o.a.r.HttpRepo      :432) - bincrafters downloading https://api.bintray.com/conan/bincrafters/public-conan/v2/conans/boost_level5group/1.66.0/bincrafters/stable/revisions 152 bytes 
2019-06-25 10:58:00,812 [http-nio-8081-exec-8] [INFO ] (o.a.r.HttpRepo      :445) - bincrafters downloaded  https://api.bintray.com/conan/bincrafters/public-conan/v2/conans/boost_level5group/1.66.0/bincrafters/stable/revisions 152 bytes at 9.33 KB/sec
2019-06-25 10:58:04,681 [http-nio-8081-exec-5] [INFO ] (o.a.r.HttpRepo      :432) - bincrafters downloading https://api.bintray.com/conan/bincrafters/public-conan/v2/conans/boost_optional/1.66.0/bincrafters/stable/revisions/0/packages/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/revisions 192 bytes 
2019-06-25 10:58:04,684 [http-nio-8081-exec-5] [INFO ] (o.a.r.HttpRepo      :445) - bincrafters downloaded  https://api.bintray.com/conan/bincrafters/public-conan/v2/conans/boost_optional/1.66.0/bincrafters/stable/revisions/0/packages/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/revisions 192 bytes at 72.42 KB/sec
2019-06-25 10:58:05,600 [http-nio-8081-exec-4] [INFO ] (o.a.r.HttpRepo      :432) - conan-center downloading https://conan.bintray.com/v2/conans/boost_integer/1.66.0/bincrafters/stable/revisions 94 bytes 
2019-06-25 10:58:05,604 [http-nio-8081-exec-4] [INFO ] (o.a.r.HttpRepo      :445) - conan-center downloaded  https://conan.bintray.com/v2/conans/boost_integer/1.66.0/bincrafters/stable/revisions 94 bytes at 30.85 KB/sec
2019-06-25 10:58:05,796 [http-nio-8081-exec-4] [ERROR] (o.a.a.c.r.ConanV2RemoteRepoHandler:261) - Unable to fetch latest revision from 'https://conan.bintray.com/v2/conans/boost_integer/1.66.0/bincrafters/stable/latest': HTTP/1.1 404 Not Found
2019-06-25 10:58:10,205 [http-nio-8081-exec-1] [INFO ] (o.a.r.HttpRepo      :432) - bincrafters downloading https://api.bintray.com/conan/bincrafters/public-conan/v2/conans/boost_integer/1.66.0/bincrafters/stable/revisions 148 bytes 
2019-06-25 10:58:10,208 [http-nio-8081-exec-1] [INFO ] (o.a.r.HttpRepo      :445) - bincrafters downloaded  https://api.bintray.com/conan/bincrafters/public-conan/v2/conans/boost_integer/1.66.0/bincrafters/stable/revisions 148 bytes at 53.81 KB/sec
...
```
user: db4
issue_5341: state: open
title: Question N configs -> 1 package
body: To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.

I'm not getting this example
```
$ git clone https://github.com/memsharded/hello_multi_config
$ cd hello_multi_config
$ conan create . user/channel -s build_type=Release
$ conan create . user/channel -s build_type=Debug --build=missing
```

```
class Pkg(ConanFile):
    # build_type has been omitted. It is not an input setting.
    settings = "os", "compiler", "arch"

    def configure(self):
        # it is also necessary to remove the VS runtime
        if self.settings.compiler == "Visual Studio":
            del self.settings.compiler.runtime

    def build(self):
        cmake = CMake(self)
        if cmake.is_multi_configuration:
            cmmd = 'cmake "%s" %s' % (self.source_folder, cmake.command_line)
            self.run(cmmd)
            self.run("cmake --build . --config Debug")
            self.run("cmake --build . --config Release")
        else:
            for config in ("Debug", "Release"):
                self.output.info("Building %s" % config)
                self.run('cmake "%s" %s -DCMAKE_BUILD_TYPE=%s'
                        % (self.source_folder, cmake.command_line, config))
                self.run("cmake --build .")
                shutil.rmtree("CMakeFiles")
                os.remove("CMakeCache.txt")
```

Why do I've to call `conan create` twice in `Debug` and `Release` ? Isn't the conan file taking care of build both types?
And when i'm trying to apply this example on my own code the dependencies are missing for one build type. If I call `-s build_type=Release` first the Debug libs are missing and also the other way around. Do my dependencies also have to be multi config pkgs? Or am I missing something?

In the end I want all my libs to be available in release and debug in one pkg.
user: mietzen
issue_5287: state: open
title: [system-package-tools] Add support for Brew cask
body: To help us debug your issue please explain:

Brew has the argument `cask`, which works like `-no-install-recommends`. It would be nice adding a new parameter to enable, or solving automatically when necessary.

XQuartz is a good example:

```
Running: brew update
Already up-to-date.
Running: brew install xquartz
Error: No available formula with the name "xquartz" 
Found a cask named "xquartz" instead.
freeglut/3.0.0@bincrafters/testing: ERROR: while executing system_requirements(): Command 'brew install xquartz' failed
```

As you can see, Brew warned about cask. Maybe SystemPackageTool could solve it, re-running the install command, but using cask.

- [ ] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ ] I've specified the Conan version, operating system version and any tool that can be relevant.
- [ ] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.


user: uilianries
issue_5271: state: open
title: [Artifactory] User must have deploy access to remote repository
body: I sure hope you can agree that this is buggy behavior and not expected. I can understand why it _does_ work this way, but it shouldn't.

I've set up four repositories in Artifactory: a local one (for our homegrown code), a remote mirroring `conan-center`, a remote mirroring `conan-transit`, and a virtual one that aggregates the other three.

If I try to `conan install` zlib, I get a 403 error:

```
david@balrog:~/.conan$ conan install zlib/1.2.11@conan/stable
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
os_build=Linux
platform=x86_64
[options]
[build_requires]
[env]

zlib/1.2.11@conan/stable: Not found in local cache, looking in remotes...
zlib/1.2.11@conan/stable: Trying with 'rlc'...
Downloading conanmanifest.txt
ERROR: Error 403 downloading file https://artifactory.redlion.net/artifactory/api/conan/conan-rlc-virtual/v2/conans/zlib/1.2.11/conan/stable/revisions/0/files/conanmanifest.txt
Waiting 0 seconds to retry...
ERROR: Error 403 downloading file https://artifactory.redlion.net/artifactory/api/conan/conan-rlc-virtual/v2/conans/zlib/1.2.11/conan/stable/revisions/0/files/conanmanifest.txt
Waiting 0 seconds to retry...
ERROR: Error 403 downloading file https://artifactory.redlion.net/artifactory/api/conan/conan-rlc-virtual/v2/conans/zlib/1.2.11/conan/stable/revisions/0/files/conanmanifest.txt. [Remote: rlc]
```

If I then look at the Artifactory log, I see that it is expecting my user to have deploy permissions for zlib to the `conan-center` remote repo:

```
2019-05-31 13:07:49,051 [http-nio-8040-exec-5] [ERROR] (o.a.a.c.r.ConanV2RemoteRepoHandler:348) - Couldn't read index file in remote repository conan-center-mirror : User davidzemon is not permitted to deploy 'conan/zlib/1.2.11/stable/index.json' into 'conan-center-mirror-cache:conan/zlib/1.2.11/stable/index.json'.
2019-05-31 13:07:49,312 [http-nio-8040-exec-5] [ERROR] (o.a.a.c.r.ConanV2RemoteRepoHandler:348) - Couldn't read index file in remote repository conan-transit-mirror : User davidzemon is not permitted to deploy 'conan/zlib/1.2.11/stable/index.json' into 'conan-transit-mirror-cache:conan/zlib/1.2.11/stable/index.json'.
2019-05-31 13:07:49,373 [http-nio-8040-exec-5] [ERROR] (o.a.a.c.r.ConanV2RemoteRepoHandler:261) - Unable to fetch latest revision from 'https://conan-transit.bintray.com/v2/conans/zlib/1.2.11/conan/stable/latest': HTTP/1.1 404 Not Found
2019-05-31 13:07:50,022 [http-nio-8040-exec-6] [WARN ] (o.a.r.ArtifactoryResponseBase:125) - Sending HTTP error code 403: Rejected artifact download request: User davidzemon is not permitted to deploy 'conan/zlib/1.2.11/stable/0/export/conanmanifest.txt' into 'conan-center-mirror-cache:conan/zlib/1.2.11/stable/0/export/conanmanifest.txt'.
2019-05-31 13:07:50,426 [http-nio-8040-exec-10] [WARN ] (o.a.r.ArtifactoryResponseBase:125) - Sending HTTP error code 403: Rejected artifact download request: User davidzemon is not permitted to deploy 'conan/zlib/1.2.11/stable/0/export/conanmanifest.txt' into 'conan-center-mirror-cache:conan/zlib/1.2.11/stable/0/export/conanmanifest.txt'.
2019-05-31 13:07:50,845 [http-nio-8040-exec-13] [WARN ] (o.a.r.ArtifactoryResponseBase:125) - Sending HTTP error code 403: Rejected artifact download request: User davidzemon is not permitted to deploy 'conan/zlib/1.2.11/stable/0/export/conanmanifest.txt' into 'conan-center-mirror-cache:conan/zlib/1.2.11/stable/0/export/conanmanifest.txt'.
```
user: DavidZemon
issue_5251: state: open
title: [question] Multiple architecture package aggregation with dependency resolution 
body: To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.

```
Conan version v1.15
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.5 LTS
Release:	16.04
```

Hello Conan team,

In our current package model, the majority of our packages are either libraries with a set of headers or executables which consume the libraries. All libraries support both 32bit and 64bit architectures, however, some executables support only one architecture (either 32bit or 64bit).

At the highest tier of our package structure, we have a "package aggregator" which collects multiple exectuables in order to create a single deploy-able package. The catch is, the package aggregation step could/will result in pulling in packages of different architectures (some 32 and others 64). What is the best way to accomplish this with conan?

We are trying to maintain the ability to do dependency overriding/down stream dependency resolution at the highest level if possible. For example, if in the package aggregation level I want all executables to be built against some particular version of a library, both 32bit and 64bit exectuables will build against the proper version with the appropriate architecture. It is worth mentioning that we are also using full package mode for both executables and library packages at this point in time. 

Is the usecase/workflow above supported in Conan? If not, what is the _best_ Conan can do?

Thanks for the help!
user: Liam-Bowler-Bose
issue_5209: state: open
title: Improve Conan untar speed
body: To help us debug your issue please explain:

Using Conan 1.15.1 on Ubuntu 18.04, it seems untar-ing conan packages downloaded from a repository is a rather slow process. Digging into it more, I think this is because Conan uses the build in python tarfile module for doing the tar decompression. We have some packages that have grown into 100 of MBs, and this can take quite a long time. From what I've read, the tarfile module is single threaded, and we are working on servers with several cores that we'd like to take advantage of. 

I understand though it is nice to have a good cross-platform solution using the python tarfile module and perhaps that should be the default.

It would be ideal if the user could tell Conan to use the tar on the path if it exists. Some ideas:

1. Add a `extract_tool` variable to the config file that takes in `/path/to/tarball` and `extract_dir` as the only two parameters. Users need to write their own tool that conan will call if this variable is set. This could be a little shell script wrapper for their environment that could call tar, pigz, etc... using the two parameters passed in.
1. Add a `tar_location` variable to the config file/environment variable. User could set this to `/usr/bin/tar` (or wherever tar is). Conan would only use this if it was set and then launch a subprocess doing something like `tar -xf conan_package.tar.gz`
1. Automatically search the user's ${PATH} to see if tar exists. Use that instead of the built in python module.


- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.


user: zlalanne
issue_5183: state: open
title: Cannot override conflicting subdependency options specified in dependencies' conanfiles
body: Lets suppose that we have Conan-based project depending on packages PkgA and PkgB.

PkgA and PkgB both depend on Boost and both specify options for their dependencies. For example, skip_lib_rename for Boost.

In PkgA/conanfile.py:

    def configure(self):
        self.options["boost"].skip_lib_rename = True

In PkgB/conanfile.py:

    def configure(self):
        self.options["boost"].skip_lib_rename = True

In this case Conan rightfully reports conflict:

    ERROR: boost/1.67.0@conan/stable: PkgB/1.0@test/stable tried to change boost/1.67.0@conan/stable option skip_lib_rename to False
    but it was already assigned to True by PkgA/1.0@test/stable

We then try to override this option in root conanfile as `self.options["boost"].skip_lib_rename = True`, but we still get the same error message!

The full example can be seen in the following gist: https://gist.github.com/happy-monk/351a078d7026fdca577aa0bdd4e5d09d

Tested on Conan 1.15.1

P.S. If PkgA and PkgB both declare options through `default_options`, this seem to resolve problem, but it is not always possible to enforce that. Also the issue behaves erratically: sometimes it can be solved just by rearranging the requirements list, but not in every case.
user: happy-monk
issue_5152: state: open
title: reproducible builds (on linux)
body: # Abstract

I will outlined a couple points that, in my ideal world, could be solved by conan. Concerns are:

-   Allow dropping produced binaries to a target (under the `/usr` prefix). Currently the random prefix could cause issues
-   Support easy setup for debugging (known paths for packages with a common root). Again the random prefixes make it hard redirecting.
-   Allowing [ReproducibleBuilds](https://wiki.debian.org/ReproducibleBuilds), that is if all sources and tools are identical (#2750 solved), then the binaries should be bit-identical no matter the source/build folder location and date of build.
    This would help for impact analysis

## Prefix paths

These paths might end up in the binaries or accompaning scripts in various ways. setting this to the build directory is not a good idea IMHO.

This directory will not exist on other machines, so it does only serve to to `install` for the package directory.

The common idiom is to use the normal prefix `/usr`, which is supported by all popular build systems (on linux) and "stage" the install. Most of the time this is to the effect of `DESTDIR=<packagedir> make install`.

Using this idiom in conan would result in libraries you could drop into the target directories (think cross-builds), and not encode the build directory in the binary.

## Debuginfo

This is pretty much similar in concept to the prefix path, but the effect is limited to debuggers.

Problem is, that the paths to the source will not match unless the package is compiled locally.
With gcc/clang you can remap the paths with `-fdebug-prefix-map=<path-to-source>=<something-known>`. All include paths from the dependencies would have to be similarly remapped.

`<something-known>` could be just `.` so the build directory path will not end up in the binary, or something like `/usr/src/conan-pkg/<pkgname>`, the latter would allow to prepare distributed sources for debugging.
ie. conan can prepare a directory `$HOME/.conan/conan-pkg-src/<pkgname>` for each package and you tell the debugger to map  `/usr/src/conan-pkg` -> `$HOME/.conan/conan-pkg-src`. The rest will magically just work.

## more Reproducible builds

Having the same sources and same tools could produce identical binaries. Several issues prevent that, particularly timestamps.

Several tools and build-systems nowadays understand the env-variable `SOURCE_DATE_EPOCH` to use not the actual date but the one defined in this variable.

conan could set this variable based on the most recent file in the source-archive for example.

# Version info

conan is v1.15.0
OS is debian "buster" x64
user: nolange
issue_5141: state: open
title: Profiles composition is calculated incorrectly (chaotic/incomplete settings calculation)
body: It looks like problem does not depend on conan version, both 1.14 and 1.15 misbehaving same way here. Sorry for long example: I had shorter ones days ago, but deleted them, since conan failed with such a profile composition, and I was in a hurry.

Conan breaks settings in case of non-trivial profile composition with include(), for example, let's imagine such a (working) layout of profiles:
profile: droid32 (one we are using as "leaf element", so fully usable profile)
```
include(android/ndk-r18b)
include(android/gradle/arch_selector_armeabi-v7a)
```
profile: android/ndk-r18b (infrastructure one)
```
# ndk r18b profile
include(default)
include(android/settings-only-ndk-r18b)

[build_requires]
nlo-android-toolchain/r18b@xxx/stable
```
profile: android/settings-only-ndk-r18b  (infrastructure one)
```
[settings]
os=Android
os.link_libcxx=static
compiler=clang
compiler.version=7.0
compiler.libcxx=libc++
```
profile: android/gradle/arch_selector_armeabi-v7a  (infrastructure one)
```
[settings]
os.api_level=19
arch=armv7
```
This example still works as expected: when using profile "droid32", default profile seems to be applied first, then "android/ndk-r18b" includes "android/settings-only-ndk-r18b" and switches target os to Android. Finally "android/gradle/arch_selector_armeabi-v7a" is able to set os.api_level, since conan knows, os is already Android.

Now, lets make a minor change: let's include "default" profile directly in "droid32" profile:
```
include(default)
include(android/ndk-r18b)
include(android/gradle/arch_selector_armeabi-v7a)
```
and remove that line from "android/ndk-r18b" profile
```
include(android/settings-only-ndk-r18b)

[build_requires]
nlo-android-toolchain/r18b@xxx/stable
```
Note: we have not changed order: we expect default profile to be applied first (because it is 1st line in droid32 profile, then we expected "android/settings-only-ndk-r18b" to switch platform to Android and so on. Unfortunately, conan goes crazy:
```
ERROR: 'settings.os.api_level' doesn't exist for 'Macos'
'settings.os' possible configurations are ['version']
```
So, apparently conan's settings calculation order depends on some chaotic factors. We've seen even more weird results with inlcluded profiles, for example, sometime arch_build becomes undefined etc.

Overall settings application order seems to be unreliable right now. I also found no unit-tests checking complex profiles compositions using inlcude(), so cannot even validate if we did something wrong to get chaotic results.

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.


user: ezaiakinsc
issue_5120: state: open
title: Artifactory concurrent uploads errors
body: From https://github.com/conan-io/conan/issues/4907. 
The PR attached to that issue, that will probably close it, will address the Conan client side.

I am opening this issue to track the Artifactory side. It should not return a 500 error for concurrent uploads, it should either block and wait, or return any other meaningful error code. 

The task to be done here is to reproduce the issue, with a script or something that uses an Artifactory server. Then create an Artifactory JIRA ticket with the report and the reproducing steps.
user: memsharded
issue_5113: state: open
title: Multiple remotes parallel search
body: Due to overall management of all our (upcoming) packages we need to split content into multiple repositories (Artifactory). Over the time the amount of repositories will be hundreds.

Is there any limit to conan client how many remotes it can handle?

`conan search -r all`

Does it search packages from each repository one by one? Is there a way to make it query servers in parallel, e.g. thread_count=16 or something similar?


user: iiknd
labels: component: ux: No changes to core business logic
issue_5084: state: open
title: Pipenv Generator
body: Hello, I'd like to use [pipenv](https://pipenv.readthedocs.io/en/latest/install/) as a generator [like this](https://docs.conan.io/en/latest/devtools/create_installer_packages.html#using-the-tool-packages-in-your-system), so that instead of...
```
[requires]
mingw_installer/1.0@conan/stable
cmake_installer/3.10.0@conan/stable

[generators]
virtualenv
```

... I could do this...
```
[requires]
mingw_installer/1.0@conan/stable
cmake_installer/3.10.0@conan/stable

[generators]
pipenv
```

Conan version: 1.14.4
OS: Ubuntu 16.04

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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. 

user: MBetters
issue_5081: state: open
title: [Question] Packaging many libraries / recipe cache
body: Hi,

in our corporate environment we need to provide all dependencies internally, hence we're not reusing any of the bincrafters recipes.
Starting from scratch, we wrote a bunch of recipes for a bunch of libraries, which do of course have dependencies among each other.
We want to host all recipes in one repository, to be able to build all libraries on demand for a given profile.

```
packages
  <library>
    <mayor>.<minor>.<patch>
      conanfile.py
build.py
```

When I want to build everything from scratch (to start out), I have the script `build.py`, that uses the conan API to build packages. I will iterate over all recipes and try to build them piece by piece.
However, the first time I build, the conan cache will be empty. If I try to build `foo` which depends on `bar`, before building `bar`, then conan will error out.

This means I somehow have to create a dependency graph, to define a build order for my packages in build.py.

Is there some way to avoid this? Can I somehow specify other directories for conan to find recipes? All required recipes are in this one repository, but Conan does not know about them.
user: KerstinKeller
issue_5036: state: open
title: [question] Suggested workflow to call dev tools from CMake
body: Hello!
I'm starting to migrate my codebases and have stumbled upon question. What is the recommended workflow to be able to call dev-tools, installed by conan, from within cmake?

I am usually building from within IDEs, i.e. VS with CMake or CLion. Without conan, I am currently executing the protobuf compiler (protoc) from within CMake, i.e. with `FindProtobuf` and the `protobuf_generate_cpp` function. 
I am trying to migrate that to conan (protoc_installer from bincrafters). [The documentation](https://docs.conan.io/en/latest/devtools/create_installer_packages.html?highlight=tools#using-the-tool-packages-in-your-system) hints that the way to use installed tools is to use python venvs, but it does not seem practical to activate from within CMake.
It seems that the parent folder to protoc is exposed via `CONAN_BIN_DIRS_PROTOC_INSTALLER` in `conanbuildinfo.cmake`. The actual executable is referenced in the conanbuildinfo.txt via `PROTOC_BIN`, under the` ENV_protoc_installer` section - but I do not know how to access that via the generator.

I hope this does not sound too confusing - I am just starting out with conan.

user: ltjax
issue_5015: state: open
title: Got an error "dyld: Library not loaded:" when consuming framework by xcode generator
body: I followed the [document](https://docs.conan.io/en/latest/howtos/link_apple_framework.html#how-to-package-apple-frameworks) to export the framework library in my local cache, then consumed it by Xcode generator. It can build success but launch failed. Following is an error tip:

```
'dyld: Library not loaded: @rpath/PubNub.framework/PubNub
  Referenced from: /Users/admin/Library/Developer/CoreSimulator/Devices/9D56419B-F7CB-44D5-A69D-BB9723E6E092/data/Containers/Bundle/Application/61B9D82E-F016-4935-9C19-2B3CCFF4A433/DemoApp.app/DemoApp
  Reason: image not found'
```

It seams Xcode doesn't copy the image into app bundle. How to solve such problem?

[DemoApp.zip](https://github.com/conan-io/conan/files/3105496/DemoApp.zip)


user: kinglezhuang
issue_5013: state: open
title: Tar file in package is corrupted when copied into local repository.
body: Conan Version 1.14.3

While working on POC for the Conan Artifactory integration I encountered a bug with tars in the local cache.

I initialized a minimal conanfile.py using new --bare. Its designed to copy a single tar file into the package:

`
    from conans import ConanFile, tools

    class PocConan(ConanFile):
        name = "POC"
        version = "0.0.1"
        settings = "os", "build_type", "arch"
        description = "<Description of POC here>"
        url = "None"
        license = "None"
        author = "None"
        topics = None

        def package(self):
            self.copy("poc.tar")
    
        def package_info(self):
            self.cpp_info.libs = tools.collect_libs(self)
`
when I "conan export-pkg . POC/0.0.1" and then check the tar copied into the conan cache ~/.conan/data it has a different check sum from the original tar file.


- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.


user: ciferkey
issue_4968: state: open
title: Overriding the version in conanfile.py when putting a package into editable mode
body: To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.

Conan version >=1.13.1
When putting a package into editable mode we have to specify the version which is fine. However the version in [conanfile.py](https://github.com/includeos/IncludeOS/blob/dev/conanfile.py#L11 ) doesn't match. 

This caused us to do the following workaround:
` conan editable add . includeos/$(conan inspect -a version . | cut -d " " -f 2)@includeos/latest --layout=etc/layout.txt`

However this results in a different issue. 
When we want to get some new tooling or a newer dependency downloaded,  The developers use conan install with -u to get the latest. which in effect will download a newer version of the package in editable sometimes.

Having thought about these two issues and still wanting to use "semver" to resolve "dependencies" we came up with the following.. By setting the editable to a high enough version. Problem 2 will never happen. however problem 1 is the root cause of this. 

So the idea we had was what if we could add -f or --force when doing 
conan editable add to ignore the version in conanfile.py ?

'conan editable add mypackage/forcedversion@user/channel --force`
(warning version x.y.z in conanfile.py is ignored)
 


user: KristianJerpetjon
issue_4962: state: open
title: [Question] What is the best way to handle multiple feature branches for multiple packages with Conan?
body: Hi @lasote and @memsharded,

We have a big discussion within the team what is the best solution to handle feature branches for packages which depends on each other. We hope that you can suggest the best way to handle it with Conan.

### Starting point

Let's take your "say"-"hello"-"chat" example from https://github.com/conan-io/examples.git workspace feature. "chat" -requires-> "hello" -requires-> "say".

#### developer task
The implementation has to be refactored for all packages (e.g. in your example the name of the chatting person has to be shown). This will be done in feature branches. 

#### infrastructure
Not sure, but I think it doesn't matter if it is a single mono-repo or three different repos. Let's say there are three git repos.
Additionally there are three CI jobs which depends on each other and which creates each package.
Job_say --> creates "say" --> triggers Job_hello
Job_hello --> creates "hello" --> triggers Job_chat
Job_chat --> creates "chat"

Probably not the best solution to have that dependency defined in CI but that is not necessarily important. The only important thing is, that there are three jobs, one for each package to be more flexible.

### Requirements
Before merging the feature branches into develop branch the features have to be completely tested in combination. Just unit testing "say" is not enough for merge, also "hello" and "chat" have to be build and tested completely.

There has to be a reproducible and safe way to define that special "feature branch" graph for build and testing.
CI and development workflow have to be the same (otherwise one will get something like "locally it works, don't now why CI fails" ;)

### Current approaches
#### Approach 1: Adding branch information to "version" or "channel"
For develop and release builds the "normal" version and channel (testing or stable) will be used.
The CI get's the branch information from current scm, checks branch name and calls `conan create <scm_dir> user/testing_feature_xyz` for "say". This will create "say/0.1@user/testing_feature_xyz". Having the branch information within the "version" is nearly the same approach, so further description is just for channel.

After upload to server there will be a recipe and all packages (build with different settings) with the new reference.

#####  Problems
"hello" has to know the custom channel when building the feature branch. Could be done by "hard-coding" it into the "hello" recipe, but that seems not to be the best solution, especially for merging into develop branch. And "chat" has to know the custom channel of "hello" too.
```python
...
    name = "hello"
    requires = "say/0.1.@user/testing_feature_1"
...
```
and 
```python
...
    name = "chat"
    requires = "hello/0.1.@user/testing_feature_1"
...
```

Patching the scm versioned recipes locally may IMHO not be a solution (e.g. with "find&replace") for CI. But it would be feasible with a lot of scripting.
For development workflow it could work but is very error prone (create "say" with custom channel --> patch "hello" recipe --> create "hello" with custom channel --> patch "chat" recipe --> create "chat" with custom channel).

#### Approach 2: Like approach 1 but with additional Alias package
See description of approach 1. Additionally an alias package would be created which points to the required feature_branch package.

Question 1: How should the alias package be named especially when there are more than just one feature branch plus develop branch which points to `<package>/<version>@<user>/testing`?
Question 2: Which job should create the alias and should it be uploaded too?
Question 3: How to get rid of old packages/cleanup? Having a weekly cron job which checks the current existing branches?

##### Problems
Assuming alias package points to "normal" testing channel which is referenced in recipe `<package>/<version>@<user>/testing` there will be naming clashes / differences between local alias and uploaded "develop branch" package. Also error prone for development workflow, conaninfo.txt may contain different information and not sure about recipe hash. And last but not least, it sounds false.

Assuming alias package is something like `<package>/<version>@user/testing_alias` or something else, one will get the same problems as described in approach 1.

#### Approach 3: define an "auto-set"-option for scm_reference within the recipe
Adding an "scm_reference" option in the following (or probably better) way:
```python 
    name = "say" # same for "hello" and "chat"
    options = { "scm_reference": "ANY"}
    default_options = "scm_reference=develop" # should point to an always existing branch (develop)
    default_channel = "testing" # required for dev mode an do avoid Conan exception when calling self.channel
    
    def configure(self):
        if not self.channel == "testing":
            # another channel is used so we delete scm_reference
            del self.options.scm_reference
        elif self.develop:
            # channel is testing and recipe is in development or create mode
            from conans.tools import Git
            try:
                # try to get the branch name (fails with "conan create <path_to_conan_file> user/testing")
                self.options.scm_reference = Git().get_branch()
            except:
                try:
                    # fallback if no branch is checked out. Use the commit (fails with "conan create <path_to_conan_file> user/testing")
                    self.options.scm_reference = Git().get_commit()
                except:
                    self.options.scm_reference = tools.get_env("BRNACH_NAME", "develop") # get BRNACH_NAME from CI
        else:
            # channel testing used and recipe is consumed
            pass
```

This would end in one recipe and conan reference which can address multiple feature branch packages for testing channel. The recipes do not have to be changed locally (neither CI nor development workflow) and it seems to be more the Conan way of defining "variants" of packages.

##### Problems
If there is a recipe change in a feature branch, all other packages will be outdated.
Changing / updating requirements in a branch will end in undefined behavior (assuming the outdated packages could be downloaded, [not sure if that works with conan]).

#### Approach 4: Something like Conan package/recipe revisions
Looking at the documentation at https://docs.conan.io/en/latest/mastering/revisions.html?highlight=revision it might not fit to the described use case and the requirements because if I got it right the full reference like "lib/1.0@conan/stable#RREV:PACKAGE_ID" has to be given in the recipe.

### Question
What do you think is the best way to handle that?

Thanks.
Best Aalmann

Edit: We use the scm-auto feature which will always outdate the recipe because of different revisions.
user: Aalmann
issue_4935: state: open
title: Artifactory - Enable uploading packages via Web/REST interface
body: With Artifactory it is possible to upload package bundles via Web and REST interface as described [in the docs](https://www.jfrog.com/confluence/display/RTF/Deploying+Artifacts#DeployingArtifacts-DeployinganArtifactBundle)

This would be easier, faster and less error-prone than the current approach described in the [conan docs](https://docs.conan.io/en/latest/uploading_packages/artifactory_ce.html#migrating-from-other-servers). The Conan approach depends on the locally installed Conan client, as it processes all conanfiles. If there's a feature that isn't supported anymore, the package won't get migrated. Could be something simple like having a recipe that uses Python 2 `print "foo"` and the script running with Python 3.

It could work like so:
* Go to the `data` directory of your conan-server
* Zip every package up
* Run a custom script that uses the [Artifactory REST interface](https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API#ArtifactoryRESTAPI-DeployArtifactsfromArchive) to upload all zipped packages
user: monsdar
issue_4928: state: open
title: linking problems with start-group and end-group
body: Hello,

Take a look a the abseil's conanfile.py here:
https://github.com/abseil/abseil-cpp/blob/master/conanfile.py

Its package info looks like this:
```py
        if self.settings.os == "Linux":
            self.cpp_info.libs = ["-Wl,--start-group"]
        self.cpp_info.libs.extend(tools.collect_libs(self))
        if self.settings.os == "Linux":
            self.cpp_info.libs.extend(["-Wl,--end-group", "pthread"])
```

Now, I am packaging my codebase with conan as well and rely on start-group/end-group to remove circular dependencies amongst my libs. My package info looks like this:

```
            self.cpp_info.libs = ["-Wl,--start-group"]
            self.cpp_info.libs.extend(['foo', 'bar'])
            self.cpp_info.libs.extend(["-Wl,--end-group"])
```

Now here is the surprising bit. The final linker command removes start-group/end-group from my libraries if I also depend on abseil! (If I do not depend on abseil, then everything works fine). 

linker command looks like this:

```
... foo.a bar.a -Wl,--start-group absl.a -Wl,--end-group -lpthread -Wl,--start-group -Wl,--end-group
```

As you can see, it created an empty start/end group at the end, and didn't encapsulate my libs in it. My suspicion is that since everything is a list of strings, GNU Linker (or cmake) changes the ordering since it thinks that start-group/end-group are just few more libs.  Not sure what is the best course of action here, but any help is appreciated. Thanks!
user: skgbanga
issue_4784: state: open
title: [bug] dependency options not applied to current recipe (ConanFile)
body: Hi there,

I am using Boost as dependency in a recipe. I have to switch with between ```boost:header_only=True``` and ```boost:header_only=False```.

While working on my code suddenly the ```options``` of build_dependencies specifically from boost are not applied to the ```options``` of my recipe.

I found out that if I do a ```conan install``` and ```conan build``` everything works.
But using ```conan create``` does not.

conan create: ```self.options["boost"].header_only``` ->does not exist
conan install/build: ```self.options["boost"].header_only``` ->exists

Have a look at the minimal example in the attachment. It shows with two seperate calls [create, (install, build)] that the ```build(self)``` cannot detect the boost options anymore.

Hopefully I did nothing wrong. :)

Best regards...

[conan_hello_world.zip](https://github.com/conan-io/conan/files/2988338/conan_hello_world.zip)

user: Johnnyxy
issue_4753: state: open
title: Unable to resolve conflicts between requires and build_requires graphs
body: Conan v1.13 introduced reporting conflicts between requires and build_requires graphs. This is very good, as it solves many problems, but sometimes you need to be able to resolve reported conflicts and this seems not being possible at the moment (using conan v1.13.1).

[Here](https://github.com/conan-io/conan/files/2971874/conan-v1.13.1-problem.zip) is a simple project that demonstrates the issue.

Basically, we have a package `Aaa` with three versions: v1.0.0, v1.1.0 and v1.2.0. Package `Bbb` requires `Aaa/1.0.0`, package `Ccc` requires both `Aaa/1.1.0` and `Bbb/1.1.0` (thus overriding `Bbb's` dependency on `Aaa` and package `Ddd` build_requires both `Aaa/1.2.0`, `Bbb/1.0.0` and `Ccc/1.0.0`. However, instead of overriding both `Bbb's` and `Ccc's` requirements on `Aaa` with version `1.2.0`, conan reports a conflict:

```
ERROR: Conflict in Bbb/1.0.0@user/testing
    Requirement Aaa/1.0.0@user/testing conflicts with already defined Aaa/1.2.0@user/testing
    To change it, override it in your base requirements
```

However, if I change `Ddd's` build_requires expression from 

```python
    build_requires = (
        'Aaa/1.2.0@user/testing',
        'Bbb/1.0.0@user/testing',
        'Ccc/1.0.0@user/testing',
    )
```

to 

```python
    build_requires = (
        'Bbb/1.0.0@user/testing',
        'Ccc/1.0.0@user/testing',
        'Aaa/1.2.0@user/testing',
    )
```

I get **different** conflict:

```
ERROR: Conflict in Ccc/1.0.0@user/testing
    Requirement Aaa/1.1.0@user/testing conflicts with already defined Aaa/1.0.0@user/testing
    To change it, override it in your base requirements
```

Also, other permutations of build_requires order also give different conflicts.

My questions are:

- why does conan report conflict here? Why it doesn't override `Bbb's` and `Ccc's` dependency to `Aaa/1.2.0`?
- how can I solve this conflict? Build_requires expression does not support `override` keyword (a solution I would use if `Ddd` required `Aaa`, `Bbb` and `Ccc` instead of only build_required it).
- if I replace `build_requires` with `requires` in `Ddd's` conanfile, then no conflict is reported, but I don't want `Ddd` to carry `Aaa`, `Bbb` and `Ccc` as dependencies to downstream and I don't want to them to affect `Ddd's` package_id. (Image that `Ddd` is a package that contains only executable built against `Aaa`, `Bbb` and `Ccc` static libraries and consumers of the `Ddd` package do not need executable rebuilt if they themselves use different versions of those static libraries (you can think of them as utility libraries)).
- why does the order of packages in `build_requires` matter? Why can't I simply sort all my dependencies alphabetically? (we noticed the similar problem also for `requires` clause, although in more complex examples).
user: DoDoENT
issue_4740: state: open
title: [suggestion]: adding capacities for dependency graph
body: The `conan info --graph ` is a very useful tool to analyze or expose dependencies.
For me there is a lack of infos that i need:

when using html output:
- the channel in the package name is missing
- the user is missing (for my needs, all users are the same but in a more general use of conan, it may be helpful)

**These information are displayed when using dot output.**

The other thing is that the generated graph is the result of the resolving processus of conan for choosing the good packages. With this graph, we do not have the info of what are the true requirements in terms of constraints (exact value, >= value, [valueMin, valueMax],...)

I suggest adding this constraints info on the arrow itself (I know the used framework has got this facility) and maybe some decorations on node attributes may be cool:
for exemple:
```
digraph {
    node [shape=folder]
    "FakeProject/2.0.5@None/None" [style=filled, fillcolor=yellow]
    "TechnicalFramework/1.0.0@rcs/testing" -> "POCO/1.9.0-M0@rcs/stable" [label="constraint1"];
    "PubSubConnector/1.0.0@rcs/testing" -> "POCO/1.9.0-M0@rcs/stable" [label="constraint2"];
    "PubSubConnector/1.0.0@rcs/testing" -> "TechnicalFramework/1.0.0@rcs/testing" [label="constraint3"];
    "PubSubConnector/1.0.0@rcs/testing" -> "mosquitto/1.4.14-M0@rcs/stable" [label="constraint4"];
    "FakeProject/2.0.5@None/None" -> "PubSubConnector/1.0.0@rcs/testing" [label="constraint5"];
}

```

![image](https://user-images.githubusercontent.com/48549124/54350044-c77fa180-464c-11e9-8423-b86879205d59.png)

**to**

![image](https://user-images.githubusercontent.com/48549124/54350085-de25f880-464c-11e9-93db-cf4cc6844024.png)




user: ChristopheDoublier
issue_4736: state: open
title: Pointing Debug Build Packages to Sources
body: May be related to: Command that fetches sources for debugging #4289

To help us debug your issue please explain:

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).

Conan v1.13, Centos 7, Qt and qmake, GDB

- [X] I've specified the Conan version, operating system version and any tool that can be relevant.

Our workflow consists of pulling down our source from GitHub, building our libraries, and exporting the headers, sources, and binaries as a Conan package.  We package the binaries to reduce our teams build times (some libraries take over 30 minutes to build) then we share them with the rest of the team.  The problem we are running into is related to packaging debug builds and how GDB ties out source paths.  See: [Source Path](http://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html).

When we create and upload our package, GDB doesn't know how to tie out our source files meaning we cannot use GDB to step through.  Even if we used Conan to build our library once and then uploaded the package with the binaries, the source file probably will not tie out (due to different users as part of the /home/user/.conan/... path or a custom Conan user directory.).  From my research, rpm uses a tool called debugedit to modify the debug info to point the binary files to the correct sources.  

What would be really nice is that when a Conan debug package is pulled from the remote repository, somehow, someway we can tie out the binary file debug info to the sources in the package, wherever the package may reside.  

My current thought is using debugedit to change the DW_AT compilation directory on package export and either preserving the previous package location in cache and making that part of the package or using a placeholder upon upload and replacing it on install.

Further reading: [How to Point GDB to your Sources](https://alex.dzyoba.com/blog/gdb-source-path/)

- [X] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.


user: jandrewmc
issue_4694: state: open
title: [question] How to handle quality artefacts?
body: Short: 
When creating Conan packages for own components, do you have best practices how to handle (=store, distribute, trace) quality artefacts, like Test Reports or compiled doxygen Pages?

More details:
I want to release my C components via Conan packages. I see how I can achieve traceability between a Conan package and the sources in git.
But I also have to ship Quality Artefacts like Test Reports or Doxygen HTML Pages together with my release. 

So my initial idea was:
Wouldn't it be cool, to add these artefacts to the Conan package, similar as for pre-compiled binaries? But just using the package method does not 'feel' right (mixing up compiler artifacts with quality artifacts).
What do you think about this? Or do you even have better ideas or approaches?

I could not find information about this topic in the docs of Conan 1.12

To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.


user: mjb6
issue_4692: state: open
title: Thumbs up on Protocol Buffers
body: This is the only way I know to comment on blog posts.


I have been a **big supporter** of Protocol Buffers with my co-workers... even though I have not actively used it for about a year and a half.

The only issues we have faced were in migrating from 2 -> 3.  If I recall, going from 2->3 meant we lost knowing if a parameter was used in a specific message.

A really nice feature is the ability to read/write the message in ASCII, then flip some switches and back to binary. This feature made debugging easier



user: ShamanTcler
issue_4648: state: open
title: export-pkg lacks synchronization
body: - [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.

```
>conan --version
Conan version 1.13.0-dev
```

`export-pkg` lacks proper synchronization for concurrently running instances. This may result in random failures when `conan export-pkg` is simultaneously executed by several processes that share the same conan cache.

The issue is easily reproducible with the following sample export recipe. Just create `interface` folder near the recipe and put some files (that will take some time to copy) into it.
```
# coding: utf-8

from conans import ConanFile


class FoobarConan(ConanFile):
    name = "Foobar"
    description = "Foobar"

    def package(self):
        self.copy("*", dst="include/foobar", src="%s/interface" % self.source_folder)

    def package_info(self):
        self.cpp_info.includedirs = ["include/foobar"]

    def package_id(self):
        self.info.header_only()
```

Then simultaneously run two instances of `export-pkg`:
```
conan export-pkg export.py 1.0@conan/local -bf C:\tmp\build\one --force
```
```
conan export-pkg export.py 1.0@conan/local -bf C:\tmp\build\two --force
```

Chances are one will crash with an error like:
```
Exporting package recipe
Foobar/1.0@conan/local: The stored package has not changed
Packaging to 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
Traceback (most recent call last):
  File "c:\python\python36\lib\shutil.py", line 387, in _rmtree_unsafe
    os.unlink(fullname)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\<snip>\\.conan\\data\\Foobar\\1.0\\conan\\local\\package\\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\\include\\foobar\\<snip>'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\python\python36\lib\site-packages\conans\client\command.py", line 1495, in run
    method(args[0][1:])
  File "c:\python\python36\lib\site-packages\conans\client\command.py", line 797, in export_pkg
    channel=channel)
  File "c:\python\python36\lib\site-packages\conans\client\conan_api.py", line 88, in wrapper
    return f(*args, **kwargs)
  File "c:\python\python36\lib\site-packages\conans\client\conan_api.py", line 430, in export_pkg
    graph_info=graph_info, force=force)
  File "c:\python\python36\lib\site-packages\conans\client\cmd\export_pkg.py", line 34, in export_pkg
    rmdir(dest_package_folder)
  File "c:\python\python36\lib\site-packages\conans\util\files.py", line 208, in rmdir
    shutil.rmtree(path, onerror=_change_permissions)
  File "c:\python\python36\lib\shutil.py", line 494, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "c:\python\python36\lib\shutil.py", line 384, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "c:\python\python36\lib\shutil.py", line 384, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "c:\python\python36\lib\shutil.py", line 389, in _rmtree_unsafe
    onerror(os.unlink, fullname, sys.exc_info())
  File "c:\python\python36\lib\site-packages\conans\util\files.py", line 203, in _change_permissions
    raise OSError("Cannot change permissions for {}! Exception info: {}".format(path, exc_info))
OSError: Cannot change permissions for C:\Users\<snip>\.conan\data\Foobar\1.0\conan\local\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\include\foobar\<snip>! Exception info: (<class 'PermissionError'>, PermissionError(13, 'The process cannot access the file because it is being used by another process'), <traceback object at 0x0000007B39DB4588>)

ERROR: Cannot change permissions for C:\Users\<snip>\.conan\data\Foobar\1.0\conan\local\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\include\foobar\<snip>! Exception info: (<class 'PermissionError'>, PermissionError(13, 'The process cannot access the file because it is being used by another process'), <traceback object at 0x0000007B39DB4588>)
```
or:
```
Exporting package recipe
Foobar/1.0@conan/local: The stored package has not changed
Foobar/1.0@conan/local: WARN: Forced build from source
Packaging to 5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
Foobar/1.0@conan/local: Generating the package
Foobar/1.0@conan/local: Package folder C:\Users\<snip>\.conan\data\Foobar\1.0\conan\local\package\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
Foobar/1.0@conan/local: Calling package()
ERROR: Foobar/1.0@conan/local: Error in package() method, line 11
        self.copy("*", dst="include/foobar", src="%s/interface" % self.source_folder)
        FileNotFoundError: [WinError 2] The system cannot find the file specified: 'C:\\Users\\<snip>\\.conan\\data\\Foobar\\1.0\\conan\\local\\package\\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9\\include\\foobar\\<snip>'
```
user: dstftw
issue_4619: state: open
title: After tools.unzip() Windows file attribute R (read-only) is gone
body: Hi, i'm currently running into an issue probably related to issue #936. As requested there by @memsharded  i'm opening this as a new issue. So this is the same text as i posted there:

I have a conan package for a simulation tool. The package is like a tool installer.
The problem i'm having is that the tool needs a config file to be read-only.
And i need that behaviour on Windows and Linux.

The first step is to make sure that the permissions are set correctly in my sources (these are a source.zip or a source.tgz file) and this is true. That means:

* when i unzip my source.zip under Windows i get file attributes RA (= read-only, archived) on the config.ini.
* when i untar my source.tgz under Linux i get chmod = 0444 on the config.ini.

So, according to #936 i changed my conanfile and in the build method i use `tools.get(..., keep_permissions=True)`. The results are not promising, because the config.ini file, after the build step, has only the attribute A on Windows, missing the R.

As far as I can see it works on Linux as intended, so i guess the issue is only present for Windows file attributes.

I have attached a `conanfile.py` which will download the `sources.zip` from my google drive or you can alternatively use the attached `sources.zip` directly to reproduce the issue.

Let me know if you need further information.

[sources.zip](https://github.com/conan-io/conan/files/2909384/sources.zip)
[conanfile.zip](https://github.com/conan-io/conan/files/2909386/conanfile.zip)

user: nussbrot
issue_4617: state: open
title: Consider defining the existence of package binaries
body: Coming from https://github.com/conan-io/conan/pull/4615, it is not clear what defines the existence of package binaries:

- ``cache.conan_packages()`` does a ``os.listdir()`` to collect package_ids folders. They could be invalid, empty (case of short_paths after a ``conan info``)
- Metadata uses a ``self.packages = defaultdict(_BinaryMetadata)`` for binary packages, which silently continues even if a package does not exist and you request some data as its revision. Maybe it should fail, and another interface to define new packages binaries in the metadata is necessary.


user: memsharded
issue_4601: state: open
title: [question/feature] conanfile environment include/exclude env settings from certain dependencies
body: Hi there,
I have build dependencies that I need at certain points in the build process.

prerequisites
---------------
I have a build dependency (code generator; dep_a) which has env-values that interfere with env-values of another build dependency (dep_b). At conan-build I am executing CMake (with build helper). 

workflow
----------
At CMake's build execution I need to build a target with the env-values of the specific dependency (dep_a) and after that I need to build a CMake target completely without this dependency.
```python
def build(self):
    cmake = CMake(self)
    cmake.configure()
    cmake.build(target="target_with_dep_a")    
    cmake.build(target="target_without_dep_a")
```

question
----------
Is it possible to exclude the env-values of a specific build dependency?

workaround
-------------
I was digging in the conan code and I think it would be possible to do it the following way.
The code is taken and modified from docs [apply_env (step 1)](https://docs.conan.io/en/latest/reference/conanfile/attributes.html#apply-env
) and conan code [env (step 2)](https://github.com/conan-io/conan/blob/68ced146342b04e56cd66fce729c86982198f471/conans/model/conan_file.py#L164):
```python
def build(self):
    cmake = CMake(self)
    cmake.configure()
    # ----------- step 1 -----------
    # apply normal deps_env_info
    with tools.environment_append(self.env):
        cmake.build(target="target_with_dep_a")
    
    # ----------- step 2 -----------
    # create a copy from normal deps_env_info
    # remove "dep_a" env_info and apply
    my_deps_env_info = copy.deepcopy(self.deps_env_info)
    del my_deps_env_info["dep_a"]

    tmp_env_values = self._conan_env_values.copy()
    tmp_env_values.update(my_deps_env_info)
    ret, multiple = tmp_env_values.env_dicts(self.name)
    ret.update(multiple)
    with tools.environment_append(ret):
        cmake.build(target="target_without_dep_a")
```

I did not actually test this as I am in the weekend at the moment :). I am going to test this tomorrow.

Best regards
user: Johnnyxy
issue_4587: state: open
title: Conan fails to generate package when mentioned full folder path which contains conanfile.py for export-pkg 
body: call conan export-pkg %SRC_PATH%\build\conan\foundation foundation/tc12.1.0@admin/release -f
Exporting package recipe
foundation/tc12.1.0@admin/release: The stored package has not changed Packaging to 15af85373a5688417675aa1e5065700263bf257e
foundation/tc12.1.0@admin/release: Generating the package
foundation/tc12.1.0@admin/release: Package folder C:\Users\user\.conan\data\foundation\tc12.1.0\admin\release\packag
e\15af85373a5688417675aa1e5065700263bf257e
foundation/tc12.1.0@admin/release: Calling package()
foundation/tc12.1.0@admin/release package(): Copied 150 '.h' files:
foundation/tc12.1.0@admin/release package(): Copied 2893 '.hxx' files:
foundation/tc12.1.0@admin/release package(): Copied 86 '.lib' files:
ERROR: foundation/tc12.1.0@admin/release: Error in package() method, line 25
        self.copy( "abc.lib", src=tc_library,     dst="lib",  keep_path=True )
        PermissionError: [Errno 13] Permission denied: 'C:\\Users\\user\\.conan\\data\\foundation\\tc12.1.0\\admin\\
release\\package\\15af85373a5688417675aa1e5065700263bf257e\\lib\\abc.lib'

same command passes when run from the folder where conanfile.py resides
cd %SRC_PATH%\build\conan\foundation
call conan export-pkg . foundation/tc12.1.0@admin/release -f
user: Prasaddiwalkar
labels: inactive: No comments for a long time
issue_4557: state: open
title: [feature] Custom virtualenv name
body: Hi!

This request comes from [stack overflow](https://stackoverflow.com/questions/54642935/how-to-change-the-name-of-virtual-environment-in-conan).

Since we use hard-coded names, like "conanenv", no one is able generate multiple virtualenvs at same place.

We could customize the name by env var, since we don't have extended options for generators.

Regards!

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [ ] I've specified the Conan version, operating system version and any tool that can be relevant.
- [ ] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.


user: uilianries
issue_4501: state: open
title: Modular packages/libraries: Optimizing number of package builds (boost, Qt, LLVM,...)
body: When developing multiple projects all requiring similar packages, I find the number of package builds too high. There seems to be potential to optimize. However, I'm not sure about the solution and wanted to discuss this here.

# Example

I'll use the `Qt/5.11.2@bincrafters/stable` package for this example. The package provides a lot of options allowing to enable/disable different Qt modules. The example could also use other libraries like `boost/1.68.0@conan/stable`.

* AppA requires `Qt/5.11.2@bincrafters/stable` with two modules enabled (e.g. `self.options["Qt"].qttools = True` and `self.options["Qt"].qtsvg = True`)
* running `conan install` will produce a full Qt build with the selected modules
* AppB requires `Qt/5.11.2@bincrafters/stable` with one module enabled (e.g. `self.options["Qt"].qttools = True`)
* running `conan install` will produce a full Qt build with the selected module, **though the Qt build above could easily be reused**
* AppC requires `Qt/5.11.2@bincrafters/stable` without any additional module
* running `conan install` will produce a full Qt build without any module, **though the Qt builds above could easily be reused**

# Possible solution

In addition to providing the hard set of options required, also allow to say that your app "doesn't care" about other options. The conanfile for AppB above for example could include `self.options["Qt"].qtsvg = Any` (or maybe the `default_options` of the Qt package should set this to Any already). This would allow the second `conan install` command above to reuse the existing package of AppA.
user: RobertHabrich
labels: whiteboard: Put in common
issue_4480: state: open
title: [question] Whole archive linking
body: Good afternoon!

Conan is an awesome tool, and I'm trying to wrangle it to help build a machine learning project.  One of the design goals is to use [Caffe](https://github.com/NVIDIA/caffe) statically in the final binary.  This software package has runtime registration of "layers", so the whole archive must be linked for it to work.  In GCC, this translates to:
```
-Wl,--whole-archive -lcaffe-nv -lproto -Wl,--no-whole-archive
```

My first cut in conan was to translate put this into the `cpp_info.libs`, without the `-l`s so that the libraries could be resolved to absolute paths.
```
self.cpp_info.libs = [
    "-Wl,--whole-archive",
    "caffe-nv",
    "proto",
    "-Wl,--no-whole-archive",
]
```
The problem is that this causes the caffe and all it's dependencies to be placed between the `whole-archive` block. 

This lead me to option 2:
```
self.cpp_info.libs = [
    "-Wl,--whole-archive",
    "-L" + os.path.join(self.package_folder, 'lib'),
    "-lcaffe-nv",
    "-lproto",
    "-Wl,--no-whole-archive",
    "caffe-nv",
    "proto",
]
```
To force the libraries to be used without dependency resolution in the `whole-archive` block and then again outside with dependency resolution.

Do you have any thoughts on this approach?

---

To help us debug your issue please explain:

- [X] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [X] I've specified the Conan version, operating system version and any tool that can be relevant.

Ubuntu 16.04.5 LTS
Conan version 1.12.0
cmake version 3.12.1
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
Caffe: nvidia 0.17.2

- [X] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.


user: rddesmond
issue_4382: state: open
title: [suggestion] Ability to declare that you need the dependency source, not binary
body: Very similar to #719, but the solution of go-style packages is not sufficient. Consider the following...

For embedded systems (think small microcontrollers with 32kB of RAM, not Raspberry Pi level of "embedded systems"), things get compiled very "special" compared to the non-embedded world. To get the smallest possible code size, the developer might want to play around with a variety of different compiler flags - most commonly, `-ffunction-sections` and `-fdata-sections`. This _could_ be accomplished by providing a CMake toolchain file with those flags, but they're really not the kind of flags that belong in a toolchain file (they're not CPU-specific, like `-march=...`, for instance). What would be better, and more common for embedded systems, would be to just include the source of the dependency in the main project and build it with all the same flags as the rest of the project. A git submodule, for instance, would do the trick nicely. But I like Conan... and I'm already using Conan... do I really need _both_ submodules _and_ Conan? Can't I have an all-in-one tool?

Okay, so far, creating a Conan package that copies from source to package folder _would_, in fact, be sufficient. Until I throw in one extra requirement: I also want to use this library for non-embedded development. In the non-embedded world, I expect to be able to use `find_package(linenoise REQUIRED)` and `target_link_libraries(foobar PUBLIC linenoise)` _just like every other package and library_ in my project. I want library binaries when building for Linux, and I want source when building for embedded systems.

Right now, solving this problem requires a Conan option that chooses between compiling and installing binaries or just copying source. But that requires the library author thinking ahead enough to write the correct recipe (or me creating a custom recipe). It would be _awesome_ if I could add `source_requires = linenoise/3.0.3@foo/bar` and Conan would provide my CMake build system with a variable that points to the project's _source_ root. No one's recipe would need to be changed to enable this feature because _of course_ Conan already knows how to acquire the source (if someone were to be stupid enough to do this on a package that had neither `scm`, `exports_sources`, or `def source()`, Conan would of course just provide a path to an empty directory, or maybe throw an exception.. probably empty directory).

Understood? Clear as mud?

Simple example library where I'd like to be able to use it both from Linux and embedded system: https://github.com/antirez/linenoise
user: DavidZemon
issue_4266: state: open
title: [Question] How to use two factor authentication (2FA) like Google Authenticator with Conan?
body: Hi @memsharded and @lasote ,

I have a question concerning 2FA with conan.
Especially in enterprise environments a 2 factor authentication is often used to secure the access to various applications (like JIRA, Artifactory, etc.).
I didn't find any information about 2FA@conan.

Are there any experiences with Google Authenticator or similar applications (Microsoft Authenticator, FreeOTP, Keepass/KeyOTP, etc.) and how to use them with conan? 
If not, is there any feature planned?

Thanks in advance.
Best Aalmann


user: Aalmann
issue_4245: state: open
title: Remove `host_name` , `public_port` and `ssl_enabled` from server.conf
body: Since Conan 1.1 these parameters are not recommended. So we should definitely remove them in Conan 2.0. Now the server/client communication uses relative URLs so they are not needed anymore.

https://docs.conan.io/en/latest/uploading_packages/running_your_server.html?highlight=host_name
user: lasote
issue_4221: state: open
title: Best practices for mixing and matching Release with RelWithDebInfo packages
body: We build many open sources packages from scratch and publish internally using Conan, then build our own internal libraries against those with Conan.

In https://github.com/conan-io/conan/issues/1564 "Add RelWithDebInfo as a supported build_type" @memsharded stated:

> And linking RelWithDebInfo from consumer packages/projects, with Release packages seems to work well.

This is a use case that appeals to us.  How should this work in practice?

If package `Current` depends on package `Base`, and Base was built with ```build_type=Release```, if I try to build `Current` with ```build_type=RelWithDebInfo``` it's usually not going to consider the Base libraries of ```build_type=Release``` as satisifying dependencies.

What should be our practice here?

Conan version 1.10.1 Windows

To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://github.com/conan-io/conan/blob/develop/.github/CONTRIBUTING.md).
- [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.


user: michaelmaguire
issue_4196: state: open
title: Compatibility with keyring (libsecret) for user login credentials
body: It would be nice if I could store my credentials for a remote into a keychain such as `libsecret` like I can do with `git`.
user: Lawrencemm
labels: whiteboard: Put in common
component: ux: No changes to core business logic
issue_4136: state: open
title: inconsistent behavior related to symlinks
body: To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.

i believe this applies to any conan version on any os supporting symlinks. when i build recent `zlib/1.2.11@conan/stable` from sources, it uses `self.copy(symlinks=True)` in `package` method. (btw, afaict it is breaking change without bumping package version number, i still have older recipe (without `symlinks` parameter) in cache). so far, so good, it creates `libz.so.1.2.11` file and `libz.so.1` symlink to it. when i `import libz.so.1*` in dependent package, i get file and symlink as expected. same steps work as  well when i download binary `zlib/1.2.11@conan/stable` from `conan-center`. but if i `upload zlib/1.2.11@conan/stable` to internal server, it will upload tgz with unlinked files. this is first inconsistency - tgz content is different from `conan-center` when i just do download/upload. if i then `install zlib/1.2.11@conan/stable` from internal server, and import `libz.so.1*` from dependent package, i get two copies instead of file and symlink, which is wasted space. if i try to import `libz.so.1` instead, it will work, but only when `zlib/1.2.11@conan/stable` is downloaded from internal server. when it was downloaded from `conan-cener` or built from sources, `import` will copy dangling symlink. this is another inconsistency. it can be solved by adding parameter to `import`'s `self.copy` to turn on following symlinks, or by exporting tgz with symlinks from local cache (there should be some way since `conan-center` has binary package with symlinks, but i can't find it in docs)
user: spavlovskyi
issue_4135: state: open
title: Profile build_requires for a specific package is ignored when installing package from a file
body: Conan version: 1.10.1 (however I noticed this issue when I first time tried profiles)

I have a profile for cross-compilation which declares gcc-toolchain requirement for certain packages. Here I give a synthetic test for simplicity. Two files:

issue_test.profile
```ini
[settings]
os = Linux
arch = x86_64
compiler = gcc
compiler.version = 5.4

[build_requires]
issuetest*: zlib/1.2.11@conan/stable
#zlib/1.2.11@conan/stable
```

conanfile.py
```python
from conans import ConanFile

class IssueTestConan(ConanFile):
    name = "issuetest"
    version = "0.1"
```

Now if I invoke `conan install . -if build -pr issue_test.profile` I get:
```
...
PROJECT: Installing /home/kds/issue_test/conanfile.py
Requirements
Packages

PROJECT: Generator txt created conanbuildinfo.txt
PROJECT: Generated conaninfo.txt
```
Zlib is not picked up.
If I uncomment the last line in the profile:
```
...
ROJECT: Installing /home/kds/issue_test/conanfile.py
Requirements
Packages
Build requirements
    zlib/1.2.11@conan/stable from 'conan-center' - Cache
Build requirements packages
    zlib/1.2.11@conan/stable:0248d205af41d3c67dabf79bc96d0a3bf8f6d076 - Build
...
```
However if I instead export the package (comment the last line again) and then install it by name, everything works:
```
$ conan export . kds/test
$ conan install issuetest/0.1@kds/test -pr issue_test.profile --build=missing
...
issuetest/0.1@kds/test: Installing package
Requirements
    issuetest/0.1@kds/test from local cache - Cache
Packages
    issuetest/0.1@kds/test:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Build
Build requirements
    zlib/1.2.11@conan/stable from 'conan-center' - Cache
Build requirements packages
    zlib/1.2.11@conan/stable:0248d205af41d3c67dabf79bc96d0a3bf8f6d076 - Build
...
```
user: kdsx
issue_4086: state: open
title: Minimal ENV var template support in conan config install
body: I'm sharing a common config for users in my team.

However our Windows shared dev machines are setup with the big available storage on E: drive, and we follow the convention that each developer gets a directory under E:\Develop\<username>.

I'd like to be able to let people ```conan config install``` some templatized conan.conf such as e.g.:

```
[storage]
path = E:\DevelopBp\${env.USERNAME}\.conan
```

Can we do something to resolve basic ENV templates like this at ```conan config install``` time?


To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [1.9.2] 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.


user: michaelmaguire
issue_4056: state: open
title: Support Linux stripped symbol debugging
body: Split out from https://github.com/conan-io/conan/issues/4047#issuecomment-443949770 "Support Microsoft Symbol Server integration with Artifactory for Conan packages containing .pdb" which covers Windows specifically.

We would like to ensure that developers can debug production Linux software published internally using Conan.

Can we please request a Conan/Artifactory integration enhancement that would allow .pdb files published within Conan packages to be transparently available as if it were a Linux symbol server

Looks like a way of doing this is covered here:  https://youtu.be/xTmAknUbpB0?t=1913




To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.


user: michaelmaguire
issue_4047: state: open
title: Support Microsoft Symbol Server integration with Artifactory for Conan packages containing .pdb
body: We would like to ensure that developers can debug production Windows software published internally using Conan.

We understand how we could publish libraries used in building our executable up to Conan and our pdb files separately to a symbol server accessible to VisualStudio.

However, given space constraints, we must manage the garbage collection of old library builds once we become certain they are no longer needed.

If we store .pdb files to a separate symbol server, then whatever lifecycle and deprecation management we decide on for Conan packages must be duplicated for the management of the symbol server pdbs.

If instead we could simply publish the pdb and lib files in the same Conan package, publish them to Artifactory and aim Visual Studio at the artifactory conan repo as a Symbol Server, we could manage those artifacts together.

Can we please request a Conan/Artifactory integration enhancement that would allow .pdb files published within Conan packages to be transparently available as if it were a Symbol Server, using the usual hash query mechanism implemented by Symbol Servers https://stackoverflow.com/questions/1419347/microsoft-symbol-server-local-cache-hash-algorithm ?





I have raised: https://www.jfrog.com/jira/browse/RTFACT-18260 in the Artifactory JIRA.

To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.


user: michaelmaguire
issue_4029: state: open
title: Increase no_proxy_match debugging
body: Print some messages when an URL is being excluded from the proxy. `conan_requester.py` file at line 45.
user: lasote
labels: component: ux: No changes to core business logic
issue_3972: state: open
title: [Discussion] how to model GLIBC version for conan packages
body: To help us debug your issue please explain:

- [ ] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [ ] I've specified the Conan version, operating system version and any tool that can be relevant.
- [ ] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

/cc @rdeterre @bc-lee @elizagamedev 

this is more generic version of https://github.com/conan-io/conan/issues/3963
related issues:
https://github.com/bincrafters/community/issues/296
https://github.com/bincrafters/community/issues/267

historically, conan didn't model glibc version, relying only on compiler version for binary compatibility checks.
this causes some issues in the past, as binaries compiled with the same compiler weren't compatible across various linux distributions.
for instance, if we compiled libraries or executables via GCC 4.8 on Ubuntu 12.04, these executables and libraries fail to run/link on CentOS 7 machines. same situation with other popular Linux distributions, like  RHEL, Fedora, etc.
user: SSE4
labels: component: Build: Build helpers, build systems..
issue_3931: state: open
title: cpp_info should contain relative path to individual libraries
body: Right now, lib_paths and libs are quite decoupled. It should be more deterministic to express which library belongs to which path. This would also be aligned with @vector-of-bool ``libman`` proposal at https://github.com/vector-of-bool/libman


user: memsharded
issue_3927: state: open
title: package_id and binaries built against different versions of a dependency due to requires and (transitive) build_requires selecting different versions
body: A discussion started in slack with :
> Am I wrong to expect that package versions I list in requires would be the initial values (and thus override transitive dependencies) for package I list in build_requires? Or is it not doing so a bug?
> basically I require liba/1.1@..., and build_depend on a libb that also requires liba, except (being a little older) it depends on liba/1.0. But it would be compatible with 1.1 (and would even be the same package_id due to semver_mode), so it uses the existing binaries in the cache
> However, conan ends up selection liba/1.1 for the requires and liba/1.0 for the build_requires, and including both in conanbuildinfo.txt
> But in conanbuildinfo.cmake CONAN_LIBA_ROOT points to liba/1.0 (probably just that the build_requires came second and overwrote the requires)? and the combined variables like CONAN_CMAKE_MODULE_PATH lists them both
> I didn't think conan was ever supposed to use multiple versions of a package for a ConanFile's requirements (obviously build_requires for different packages that all need to be built can vary, as can the subtrees beneath different ConanFile instances if you use private=True)
> <sub>[View in Slack](https://cpplang.slack.com/archives/C41CWV9HA/p1541800355824400)</sub>

@memsharded replied with
>  I need to go to sleep now, but quick summary; `build_requires` are independent and isolated from other requirements. As they are private by definition to the package, they are an independent graph, not affected by normal requirements at all
In fact that part of the graph is only computed when it is necessary to build from sources, otherwise, it doesn't exist at all
They can be overriden from the `profile` build-requires, but not affected by other packages build-requires
> <sub>[View in Slack](https://cpplang.slack.com/archives/C41CWV9HA/p1541806161845200/)</sub>

I've put together a little toy example at https://gist.github.com/puetzk/a6f2e77eb6dd048e7a6859e2cbb015fa. 

It creates two versions (1.0 and 1.1) of the package `required`, a package `build_required` that requires  `required/1.0` but uses the default semver_mode (so the resulting package is also usable with 1.1), then packages a consumer that requires `required/1.1` (in full_package_mode) and build_requires `build_required/1.0` (no effect on package_id). Unlike my the real use-case where I hit this, for simplicity none of these packages have any other settings/options/etc or actually compile anything.

The resulting package folder for `consumer\1.0\bug\example\{package,build}\bc8a3d667adf8e711799cf7f90fc07ce754dab64` seems quite confused: 

The conanbuildinfo.txt shows the transitive build_requires from overwrite the direct requires from `consumer` (though a few lines show *both* versions in listed)

```
[builddirs]
C:/Users/xxxxx/.conan/data/build_required/1.0/bug/example/package/9b0c6ba4d3e4e40842c29eeb745a61dff36964a0/
C:/Users/xxxxx/.conan/data/required/1.1/bug/example/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/
C:/Users/xxxxx/.conan/data/required/1.0/bug/example/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/
...
[rootpath_required]
C:/Users/xxxxx/.conan/data/required/1.0/bug/example/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
[builddirs_required]
C:/Users/xxxxx/.conan/data/required/1.0/bug/example/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/
```

conanbuildinfo.cmake is similar

conaninfo.txt shows that the package_id was computed based on the requires as expected, and this binary claims to correspond (only) to `required/1.1`

```
[requires]
    required/1.1@bug/example:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9
```

Yet the required.cpp_info.txt I generated in consumer's build method (serializing deps_cpp_info['required'] to show what it would have actually been compiled against) is `required/1.0` as in the conanbuildinfo.txt

    "rootpath": "C:\\Users\\xxxxx\\.conan\\data\\required\\1.0\\bug\\example\\package\\5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9",

So this package is **not** what it claims to be; dependencies within `build_required` that `consumer` might not even have been aware existed overwrote the consumer.

It really seems here like the build_requires should start as a copy of the requires and add to that, to mirror the way self.deps_*_info will combine the two. Private requirements can be added that are not public, but I can't envision where you'd want to claim one requirement publically and actually build against use something completely different. 

The colliding definitions in deps_cpp_info (and thus generators) is similar to #3295, though that issue didn't mention the complication where this results in binaries that don't match their package_id.

conan 1.9.1, python 3.7.0, Windows 7 x64

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.


user: puetzk
issue_3859: state: open
title: [build system][MSBuild] Investigate Microsoft.Cpp.Default.props
body: https://msdn.microsoft.com/en-us/library/669zx6zc.aspx

This file is automatically loaded by the IDE, so might be a good mechanism to define conan dependencies properties.

user: memsharded
labels: component: Build: Build helpers, build systems..
issue_3840: state: open
title: [bug] Windows: conan create fails if recipe is inside a symlinked folder
body: **Environment**
- Conan 1.8.4
- Python [3.6, 3.7]
- Windows [10, 2016 server]

**How to reproduce**
I'm using `conan-bzip2` as a "simple" example but the same goes for `conan-zlib` for instance and most likely any other.

- clone the repo: `git clone https://github.com/conan-community/conan-bzip2.git`
- create a symlink to the directory: `mklink /D conan-bzip2-link conan-bzip2`
- run conan create on the symlink: `conan create conan-bzip2-link test/link`

The result is an error:
`bzip2/1.0.6@test/link: ERROR: Package 'ce1f8ff23addde793223a2a82ed7fe355c57a589' build failed
bzip2/1.0.6@test/link: WARN: Build folder C:\Users\vagrant\.conan\data\bzip2\1.0.6\test\link\build\ce1f8ff23addde793223a2a82ed7fe355c57a589
ERROR: bzip2/1.0.6@test/link: Error in build() method, line 41
        shutil.move("CMakeLists.txt", "%s/CMakeLists.txt" % self.zip_folder_name)
        FileNotFoundError: [Errno 2] No such file or directory: 'CMakeLists.txt'`

The process fails because Conan does not correctly copy the source in the $HOME\\.conan\data\bzip2\1.0.6\test\link\export directory (notably `conan_export.tgz` and `CMakeLists.txt` are missing).

**For the curious**
I've stumbled upon this bug in my team CI that is using Concourse.
Concourse, on Windows workers, creates symlinked directory for the git repository toward volumes that are copied among the workers.

user: aledegano
issue_3721: state: open
title: Unable to find some shared libraries of executable
body: To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.

conan: v1.8.1
os: ubuntu16.04 / ubuntu18.04
I've read: https://docs.conan.io/en/latest/howtos/manage_shared_libraries.html

Hi, I am trying to build an executable that has some shared libraries as dependencies. On ubuntu 16.04 (gcc 5) everything works as expected. I can build and run them with no problems. However on ubuntu 18.04 (gcc 7) the artifact is built with no problem, although when trying to run the executable the linker cant find some of the libraries. When inspecting the output of ldd I see that part of the packages are found but the other part is not.

```
libopencv_core.so.3.4 => /home/hodor/.conan/data/opencv/3.4.2/is/stable/package/.../libopencv_core.so.3.4 (0x00007f9b70922000)
libtbbmalloc_proxy.so.2 => /home/hodor/.conan/data/TBB/4.4.4/conan/stable/package/.../libtbbmalloc_proxy.so.2 (0x00007f9b7071f000)
libboost_filesystem.so.1.66.0 => /home/hodor/.conan/data/boost/1.66.0/conan/stable/package/.../libboost_filesystem.so.1.66.0 (0x00007f9b70065000)
... [The libraries below are also built with conan and located in /home/hodor/.conan/data/...]
libprometheus-cpp.so => not found      
libSimpleAmqpClient.so.2 => not found
libzipkin.so.0 => not found
```

Any idea on what could be happening? Why only part of the libraries are found on ubuntu1804 (gcc7)? 
user: rodolfo-picoreti
issue_3682: state: open
title: Cannot (easily) override CONAN_LIBS to limit linked libraries with qmake
body: Hi,

Using Conan 1.7.4 on Debian Stretch amd64.

I have tried to modify https://github.com/memsharded/qmake_example to make it link only to Poco Foundation. This is modified `conanfile.txt`:

```
[requires]
Poco/1.7.8p3@pocoproject/stable
OpenSSL/1.0.2p@conan/stable
zlib/1.2.11@conan/stable

[options]
Poco:shared=True
OpenSSL:shared=True
zlib:shared=True

[generators]
qmake
```

Please ignore specific Poco/openssl/zlib versions and options, just wanted to avoid compiling another set of packages.

Modified `main.cpp`:
```
#include <Poco/UUID.h>
#include <Poco/UUIDGenerator.h>

#include <iostream>

int main(){
    Poco::UUIDGenerator generator;
    const auto uuid = generator.create();
    std::cout << uuid.toString() << '\n';
}
```

Now, when I build `qmake_examle`, it is linked with bunch of Poco libraries by default:
```
g++  -o helloworld main.o   -lPocoUtil -lPocoMongoDB -lPocoNet -lPocoNetSSL -lPocoCrypto -lPocoData -lPocoDataSQLite -lPocoZip -lPocoXML -lPocoJSON -lPocoFoundation...
```
I've tried to (naively?) change `.pro` to override `CONAN_LIBS` variable like this, to use only PocoFoundation library:

```
include(conanbuildinfo.pri)
CONAN_LIBS= -lPocoFoundation
CONFIG += conan_basic_setup
```
But I get compile time error:
```
../qmake_example/main.cpp:1:23: fatal error: Poco/UUID.h: No such file or directory
```
So basically, `conna_basic_setup` has no effect if applied *after* `include(conanbuildinfo.pri)`. It seems that `CONFUG +=...` expression is not applied as a function call would (as CMake macro does?).

I could do this:
```
LIBS -= lPocoNet -lPocoUtil -l...
```
But maybe there's better solution?

One thing I've tried, is to modify `conanbuildinfo.pri`, so that `CONAN_LIBS` would look like this:
```
isEmpty(CONAN_LIBS){
  CONAN_LIBS += -lPocoUtil -lPocoMongoDB -lPocoNet -lPocoNetSSL -lPocoCrypto -lPocoData -lPocoDataSQLite -lPocoZip -lPocoXML -lPocoJSON -lPocoFoundation -lpthread -lrt -lssl -lcrypto -ldl -lz
}
```
Now this allows to pre-define `CONAN_LIBS`, and now application is linked against only one of the libs:
```
CONFIG += conan_basic_setup
CONAN_LIBS= -lPocoFoundation #works!
include(conanbuildinfo.pri)
```
```
g++  -o helloworld main.o   -lPocoFoundation -L/home/...
```

Another way would be to not use `CONFIG += conan..` and paste all that `conan_basic_setup` conents... but that's really too much :) .

Could `isEmpty()` usage be implemented by default, so we could pre-define and so override `CONAN_X` qmake variables? Or are there other options?

Thanks!




user: Talkless
issue_3660: state: open
title: proposal for new generator: qmake_subdirs
body: Using qmake, TEMPLATE=subdirs permit to build several components (applications or libraries).
Each componants have not the sames dependencies:
for example: 
``` 
my_big_app
|--my_big_app.pro       <-- subdirs template
|--.qmake.conf
|--my_app 
|  `--my_app.pro          <-- depends on libexpat and {fmt}
|--my_lib
|  `--my_lib.pro            <-- depends on  {fmt}
`--tests
   `--tests.pro              <-- depends on gtest
```

big apps tends to use this model like [QtAV](https://github.com/wang-bin/QtAV) (1.7k stars)

I think qmake generator cannot deal simply with this model ( or please tell me if i'm wrong)

my proposition:
in each componant .pro file,  declare dependancies.

for example 

- in unit_test_app.pro:  CONFIG +=gtest
- in my_lib.pro: CONFIG += fmt
- in my_app.pro: CONFIG += fmt libexpat
- in conanfile.txt, the 3 dependancies are in [requires] section and "qmake_subdirs" in [generators] section

if your interested to see how it works, I writed a proof of concept [(https://github.com/davidtazy/qmake-feature-conan-generator](https://github.com/davidtazy/qmake-feature-conan-generator) 

waiting for your feedback.

Regards.















user: davidtazy
issue_3590: state: open
title: [feature request]  Enhanced support for copying *.so file groups
body: There are some libraries (e.g. gstreamer) where the *.so files are really published in groups.  For example, one group might look like this:

```
libwhatever.so    [symlink --> libwhatever.so.0]
libwhatever.so.0  [symlink --> libwhatever.so.0.1234.0]
libwhatever.so.0.1234.0
libwhatever.so.1  [symlink --> libwhatever.so.1.4321.0]
libwhatever.so.1.4321.0
```

When I tried taking just the `*.so` file, some dependent libraries failed to load because they would only take the `*.so.0` file.  So I had to write a bunch of special code for finding and copying the entire group.

You can find it in this file:  https://github.com/Panopto/gst-conan/blob/52989505e26a77e1840f83515de0338e870511fa/gst_conan/base.py

```
def copyOneSharedObjectFileGroup(pattern:str, srcFolder:str, destFolder:str, keepPath:bool=True) -> list

def copySharedObjectFileGroups(pattern:str, srcFolder:str, destFolder:str, keepPath:bool=True) -> list

def findSharedObjectGroups(pattern:str, folder:str, recursive:bool=True, prefix=None) -> list:

def groupSoFiles(sortedList:list) -> list
```

Feel free to take the code and refactor it however you see fit.
user: adaviding
issue_3571: state: open
title: Questions to Gerrit integration, package revisions & override requirements
body: To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.

Hello,

I discovered your package manager and think, that it could be the solution for our CI system.
Thanks for this really nice package manager. Now the first time I think we can go and use a package manager and get a huge benefit.
I use the conan 1.7.3 with included path for SVN support (#3192). Running on Windows 10 & Python 3.7. 

But still I have some question in my head, how to realize the system.

Let's start with our current situation:
* We got subversion repositories
* We use CMake to build our product on different embedded system (dsp & arm processors) and Windows (only for testing). Total 4 different targets.
* Until now we used subversion with svn:externals (in the beginning of development pointing to the `trunk`, towards delivery we are used `fixed svn:externals). With this we were able to build every application with it's used libraries from source.
* As an build server Jenkins with several slaves are used. Individual unittest for the library, integration tests and the application itself were build and tested.
* From time to time we tagged some libraries and build specific binaries packages for them. Unluckily this was more or less a manual process. The binaries were linked into the project instead of the source code variant by using svn:externals.

This is the step we are currently working on:
* Git repositories for new products
* Use `Gerrit` for code review and testing before committing to `master` branch
* For Git projects, the submodule feature is used to include specific revision of one or multiple libraries. When a review on Gerrit is accepted, the submodules revision are automatically updated to the last reviewed revision of the library (Superproject subscription to submodules updates).

And now Conan joins the game: 
* Take `Conan` as a package manager. Here put every library with "Recipe and sources in the same repo" by using the `scm attribute` (for Git & SVN)

That we want to solve:
* Test projects can fetch automatically the dependencies and run their unittests.
* Jenkins automatically build the binary packages
* Reduce the building of project dependencies that have been used already in another project. This would save plenty of time on the build server. Also it reduce the process time, when the developer build & debug code.
* The developer must be able to use either the source code (for development & debugging) or the binary package (reduces build time). Here the `workspace` feature seem to work fine.
* Gerrit support the testing of change-set, that are not already put into `master` branch. Because we want to quickly build dependent libraries/unittests/products process and running all tests, Conan need to build binary packages from the temporary change-set.

## This is my first idea for an solution:
* For every revision of a library I generate a conan package with the following nomenclature:
  `foolib/"branch"_"revision"` (e.g. foolib/master_23ed34abd)
* The I set an alias with the following reference:
  foolib/"version" (e.g. foolib/1.0.0)
* This would bring all projects to follow the libraries like pointing to an `branch`.
* I can override the requirement (foolib/1.0.0) inside the project with the `foolib/"branch"_"revision"` version. This would fix the requirement to a specific revision instead of a branch.
* But how to get it running with Gerrit, when a change-set need to be builded/tested? 
  * Ask conan (conan info) to get the list of needed dependencies. Decide which packages have no changes (also no indirect change from another library) and use their binary packages directly.
  * The other libraries must either generate a special binary package (will be used by override requirements) or checkout the changed sources into the workspace and use the `workspace` feature.

This would substitute our current subversion solution.


## My next idea:

Try to imitate the "Superproject subscription to submodules updates" feature with Conan.
* Build for every library each revision committed a binary package. Following this scheme:
  `foolib/"branch"_"revision"` (e.g. foolib/master_23ed34abd) or may be
  `foolib/"version"-"branch/tag"_"revision"` (e.g. foolib/1.2.0-master_23ed34abd)
* In every project or test, which use libraries, set the requirements override to the specific library revision.
* When a commit happens in a library, a post commit script is executed which updates all projects and tests to the new revision of the library. It automatically checks in the updated "requirement override"

## My question

1. I read about the `package revisions` (#798) feature, you are planning. Could this help me?
2. When using Gerrit, I fetch for the changed libraries in review the following reference (e.g. `refs/changes/00/10000/1`). Should I use it as a channel description: e.g. `foolib/1.2.0-master_23ed34abd@user/refs_changes_00_10000_1`?
3. I can use `conan info` to get the list of needed packages. When I use an alias reference, it automatically replaces it with the target reference. Is there a chance to get both? Because then I would know, if the reference is fixed to a specific revision or it runs with an branch 
4. It would be nice to get a list from `conan info` with the used references. Save this to an file and use this (or a modified version) for the `conan install` (and other commands) as an optional argument to override requirements.
5. May be it would be also nice to override requirements with a wildcard. Let's say replace `foolib/1.2.0@user/testing` with `foolib/*@*/refs_changes_00_10000_1` would use `foolib/1.2.0@user/refs_changes_00_10000_1`?
6. I have `proj`, require `libA/1.2`. `libA` requires `libB/2.0`. What will happen, when I override in `proj` the requirement `lib/1.0`? Do I get an error?
7. I am still unsure which naming scheme for the version and the channel name I should use. May be someone has a good idea? I think about `SemVer` and/or `git describe`.

## My final idea
At the moment I think the best way to go is the following idea (#3798). I will update this ticket, when I have some results.
user: climblinne
issue_3570: state: open
title: [feature request] Better control of pkg-config would be nice
body: I am using Conan 1.7.2 (Linux Mint 19)

I am trying to build Conan packages of Gstreamer (multiple packages).  Gstreamer makes heavy use of pkgconfig.  It turns out that I needed some fine grain control over the `*.pc` files, better than what you offered with `tools.replace_prefix_in_pc_file`.  So I built a python class for that.

https://github.com/Panopto/gst-conan/blob/92085f9d5cae699c01ce46f92bb41332d977aa83/gst_conan/build/PkgConfigFile.py

Feel free to take the code and put it into your `tools` package.  You are welcome to refactor it or whatever.

user: adaviding
issue_3504: state: open
title: [enhancement] support for multiple compiler' options in default profile
body: Hello,

Consider the below default profile
```
[settings]
os=Linux
arch=x86_64
compiler=gcc
compiler.version=7.1
compiler.libcxx=libstdc++
compiler.sanitize=None
build_type=Release
[options]
[build_requires]
[env]
```

In a multiple compilers environment, it would be nice to specify something like:
```
[settings]
os=Linux
arch=x86_64
compiler=gcc
build_type=Release
[options]
[build_requires]
[env]

[compiler.gcc]
compiler.version=7.1
compiler.libcxx=libstdc++

[compiler.newgcc]
compiler.version=7.5
compiler.sanitize=address
```

We can see that the `gcc` compiler has an option **libcxx** which is not present for `newgcc` compiler.
This way, we could avoid passing two different profiles.

The main reason to suggest this is because the `conan create` workflow breaks while removing compiler settings using `configure()` method (as indicated at: https://github.com/conan-io/conan-package-tools/issues/258)

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.


user: sunj1
issue_3343: state: open
title: [question] Is there a (IDE agnostic) way to use Conan to satisfy build dependencies in a development environment
body: (AS: sorry, adding a lot here lately, because a lot of enthusiasm for Conan! Please let me know if I should use a different channel for those suggestions/broad questions)

We are successfully using Conan in an automation context, to:

* Check the build status
* Produce artifacts (note: statically linked against its dependencies)

We feel there is a way to rely on Conan to satisfy dependencies on developers machines. Currently (without Conan), what we do when we want to work on a project is that we _deploy_ all dependencies inside a folder under the user home (getting them by compiling them, or OS package managers, or downloading prebuilt binaries). Then, we instruct CMake where to find the dependencies for the current build, and let it generate the project for the current environment (can be one of several IDEs)

A tedious part when starting work in a new environment is to _deploy_ the dependencies: finding the list, finding the preferred way to obtain each dependency, and follow the steps to obtain them.

Conan naturally adresses those issues: its recipes explicitly list all dependencies, enforcing their versions, and provide a unified way to obtain them (in a single command line).
Working on project `downstream`, here is how we could deploy:

      git clone downstream.git
      cd downstream
      conan install conan/conanfile.py -if build/ #note: we host the recipe in this subfolder

--- 

Now, a complication arises when the developer wants to run one of the executable targets defined in downstream as he usually does: directly from within his favorite IDE.
Conan _default_ behaviour seems to be to generate install names without `@rpath` in OSX (RPATH mechanism is not available on Windows anyway).

The [proposed approach](https://docs.conan.io/en/latest/howtos/manage_shared_libraries/rpaths.html#default-conan-approach) is to copy the files in the executable directories, with the helps of [`imports()`](https://docs.conan.io/en/latest/reference/conanfile/methods.html#imports). It seems there are still a few drawbacks with this approach:
* The import mechanism seems to be non-recursive (thus, will not transitively copy the shared libraries on which the dependencies depend). So it becomes a no-solution for any non-trivial project.
* `downstream` project may contain many executable targets. Not all targets will require all libraries (inducing unnecessary copies). And more importantly, hardcoding the path to those many executable targets into the recipe seems to introduce a lot of unnecessary duplication between the CMake files (actually responsible for managing the targets in `downstream`) and the recipe (which should not care about those details). Also, the path to those targets directories is non-trivial and system dependent, due to the interaction between CMake and the IDEs (eg. IDE creating `Debug` and `Release` subfolders, etc...)
* Linux systems do not search the executable directory for dynamic libraries

What would seem ideal would be to use the `virtualrunenv` generated scripts to prepare the environment for runtime. This is works great for running from the terminal, sadly it does not seem that IDEs propose a "pre-run source script" step, and CMake made no provision for it either.

--- 

This seems like a vast question, and the documentation already discuss some approaches. Yet it feels like none are really offering the same level of _developer ease_ than for example the _standard_ `RPATH` mechanism on OSX that we are currently using on development environments.
user: Adnn
issue_3298: state: open
title: [question] Switching Between Debug and Release Install in Same Folder
body: I am having trouble creating and installing a debug vs. release version of a package.  In brief, whichever package I export last (conan export-pkg) is what is used when running conan install, regardless of whether debug or release is specified.  

In detail -- 

I have created two packages for a 3rd party library set.  The library sets are very large, so I have created a separate package for debug and release.  The command line I have used to do this is:

conan export-pkg . <..Package Name..>/<..Version..>@matt.hunt/testing -s arch=x86 -s compiler="Visual Studio" -s compiler.version=15 -s build_type=Release (package name and version omitted for brevity).  

When building for Debug, I simply change build_type to =Debug, and I update the files/folders in the package.  (The library folder for this 3rd party package is split between Debug and Release, so the self.cpp_info.libdirs is different for Debug vs Release).  

This seems to correctly create two packages with two different hashes.  The contents of the packages under "...matt.hunt/Testing/Package" look correct.  The manifests and conanfile.py entries in each folder are correct.

But, locally, if I try to install the Debug vs Release package, conan somehow only uses the conanfile.py from whatever was last exported (in "...matt.hunt/Testing/export").  The command line I am using to install is:

conan install . -s arch=x86 -s os=Windows -s compiler="Visual Studio" -s compiler.version=15 -s build_type=Debug

If I change build_type=Debug to build_type=Release, leaving the rest unchanged, it uses the conanfile.py found in the exports folder, and due to the different folder layout between debug and release, this fails.  The resulting .props file has no library exports.  If I manually swap the conanfile.py in the export folder, the error is resolved, although obviously that isn't supposed to be necessary.

Do I misunderstand how to create and install packages, or is there a bug?  

Conan info:
Metadata-Version: 1.1
Name: conan
Version: 1.6.0
Summary: Conan C/C++ package manager
Home-page: https://conan.io
Author: JFrog LTD
Author-email: luism@jfrog.com
License: MIT
Location: c:\python27\lib\site-packages
Requires: PyJWT, requests, colorama, PyYAML, patch, fasteners, six, node-semver, distro, pylint, future, pygments, astroid, deprecation, bottle, pluginbase
Classifiers:
  Development Status :: 5 - Production/Stable
  Intended Audience :: Developers
  Topic :: Software Development :: Build Tools
  License :: OSI Approved :: MIT License
  Programming Language :: Python :: 2
  Programming Language :: Python :: 2.7
  Programming Language :: Python :: 3
  Programming Language :: Python :: 3.6
Entry-points:
  [console_scripts]
  conan = conans.conan:run
  conan_build_info = conans.build_info.command:run
  conan_server = conans.conan_server:run

PC info:
Windows 10
Python 2.7 (due to other tools required for development)

user: matthewdhunt
issue_3295: state: open
title: Transitive requirenment is not overriding between build_requires and requires sections of conanfile.py
body: There is a problem with overriding dependencies. Looks like a bug.
Let us have 3 projects `Lib1`, `Lib2` and `App`. 
`Lib2` requires `Lib1`
`App` requires both libs, but `Lib1` requirement is transitive and `Lib2` requirement is not transitive.

`Lib1 conanfile.py`:
```
from conans import ConanFile, CMake, tools
import os

class Lib1Conan(ConanFile):
    name = "Lib1"
    version = "1.0"
    
    def package_info(self):
        self.cpp_info.libs = ["Lib1"]
```
`Lib2 conanfile.py`:
```
from conans import ConanFile, CMake, tools
import os

class Lib2Conan(ConanFile):
    name = "Lib2"
    version = "1.0"
    
    requires="Lib1/1.0@someuser/stable"
        
    def package_info(self):
        self.cpp_info.libs = ["Lib2"]
```
`App conanfile.py`:
```
from conans import ConanFile, CMake, tools
import os

class AppConan(ConanFile):
    name = "App"
    version = "1.0"
    generators = "qmake"
    
    build_requires = "Lib2/1.0@someuser/stable"
    requires = "Lib1/1.0@someuser/test"
    
    def package_info(self):
        self.cpp_info.libs = ["App"]
```
Now if I do `conan install . -if some_foder` in App directory I get `conanbuildinfo.pri` with this:
```
...
CONAN_RESDIRS += 
CONAN_BUILDDIRS += "C:/Users/Igor/.conan/data/Lib2/1.0/someuser/stable/package/fe652b9f0a4d77e47ceab2b8a170403bf36c95a4/" \
    "C:/Users/Igor/.conan/data/Lib1/1.0/someuser/test/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/" \
    "C:/Users/Igor/.conan/data/Lib1/1.0/someuser/stable/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/"
CONAN_DEFINES += 
...
CONAN_LIB1_ROOT = "C:/Users/Igor/.conan/data/Lib1/1.0/someuser/stable/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9"
...
```
But it should be only `Lib1/test` package as `Lib1/test` package should override `Lib1/stable` package.
And now if I change contents of `App conanfile.py` and move both packages to `requires` section or to `build_requires` section, the result `conanbuildinfo.pri` will contain only `Lib1/test` package and no `Lib1/stable`, so all dependencies from `Lib1` will be overriden.

New  `App conanfile.py`:
```
...
class AppConan(ConanFile):
...    
    build_requires = "Lib2/1.0@someuser/stable", "Lib1/[>=0.0.1]@someuser/test"
    #requires = "Lib1/1.0@someuser/test"
...
```

Conan 1.6.1
Windows 10 x64
Python 3.6.2
user: Ujifman
issue_3147: state: open
title: Add ability to generate and manage source packages
body: It would be nice to have the ability to automatically generate and upload source packages for a given Conan package.

Having this would bring several benefits
- builds then have a more consistent set of services they depend on (at the moment, sometimes when you want to use a package you just depend on your Conan server, other times, when there is no pre-built package you depend on other source hosting services and you may not notice problems with these until later)
- old packages are more likely to work (changes in the upstream repos such as moving can't break building)
- it solves the left-pad problem (otherwise we have to create local clones of all dependencies which is extra work, doesn't get done consistently etc)
user: drussel
issue_3146: state: open
title: [workspaces] Explain the "in-source-build" use case better
body: I was trying to follow the section about workspace "in-source-builds" (https://docs.conan.io/en/latest/developing_packages/workspaces.html#in-source-builds) with conan 1.5.0 and the example repository (https://github.com/memsharded/conan-workspace-example) on Linux.

Unfortunately it did not work as expected. I tried the following commands:
```bash
conan install .
(cd C && cmake src && make)
(cd B && cmake src && make)
(cd A && cmake src && make)
```
the last command fails with the error:
```
Scanning dependencies of target app
[ 75%] Building CXX object CMakeFiles/app.dir/main.cpp.o
[100%] Linking CXX executable app
/usr/bin/ld: cannot find -lhelloB
/usr/bin/ld: cannot find -lhelloC
```

The problem can be fixed by adding the following lines to the conanws.yml:
```yaml
HelloB:
     [...]
     libdirs: .
HelloC:
    [...]
    libdirs: .
```
Is that the intended behavior? Then I would suggest to use that in the example as well.

Also the following sentence is not true with the current example:

> Each local package will have their own build folder, and the generated conanbuildinfo.cmake will be located in it.

For that, conanws.yml would need these additional lines:

```yaml
HelloB:
     [...]
     build: build
HelloC:
    [...]
    build: build
```
However, this seems to change the behavior for the out-of-build use case. 

-- 
To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.


user: jokoala
issue_3106: state: open
title: [feature] Generate multiple packages from single compilation
body: It's quite a common task for distros' package managers to compile once and split binaries into multiple packages. But such a common and extremely useful feature for some reason is not supported by Conan.

So when it's required to generate multiple packages real magic has to be applied like changes in upstream sources to be more compatible with Conan, maintaining multiple conanfiles.py in different directories duplicating most of information. some trickery to make all of this working on 3rdparty CI like appveyor and others. Recompilation of some common part of sources for each next subproject. It becomes even harder when a project depends on a set of other libraries each of them having a little different dependencies.

So I'm looking forward you guys can handle this somehow. So I basically see two major tasks:

1. A conanfile should indicate it generates multiple binary packages with specific names, so install and package_info should do this per name.
2. build method should have a way to get **subset** of current project dependencies and generated from them compiler flags, libs list etc to be used per subpackage. (example: a proiect compiles core library and a set of plugins. each plugin has its own dependencies and each plugin will be packed into separate Conan binary package. So single list of all possible dependencies not always can be used when we need to modify project sources from Conan file. For example when we patch Visual Studio project files on the fly)
user: Ri0n
issue_3079: state: open
title: Consider the "conan open" command
body: $ conan open mypkg Pkg/version@user/channel

It will create a folder in user space ``mypkg`` folder:
- Cloning the sources if there is SCM data in the recipe
- Copying the sources from the exports_sources folder (that might not be the best practice, but doable)

Useful for Workspaces too.
 cc/ @thorsten-klein

user: memsharded
labels: component: ux: No changes to core business logic
issue_3003: state: open
title: [scm][revisions] Thoughts and questions on how to properly handle gitflow and Continuous Integration/Delivery with Conan recipes
body: - [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.

Hello,
  Progressing with the integration of Conan in our organization, we are getting close to make our life better thanks to Conan!

# The prologue

  Here is a brief description of our status and the ideal of what we plan to achieve:
* We develop C++ software through a modular approach. Modularity is achieved by defining many CMake targets, that can live in separate or common git repositories.
* We rely on external dependencies, that we may compile ourselves, or use prebuilt-binaries
* We adhere to [Gitflow](https://nvie.com/posts/a-successful-git-branching-model/), and ideally want to continuously build and test our develop branches of the different repositories, and continuously deliver the master branches [which may mean update an hosted web service, or build an archive to distribute to customers that will deploy our application/library on their environment]

# Continous Integration of the develop branches
On our CI/CD machine: ideally, each time a new commit appears on develop, the machine pulls it, then builds it with `conan install ${path_to_repo_recipe}`

With that, we know for sure the recipe of the package is up to date (it is not fetched from any Conan server, but taken directly within the source tree).

A difficulty arises with the dependencies on other internal projects listed in this recipe (those other internal projects also following Gitflow):
Assuming `App` depends on `Lib`, we may see something like that in `App` recipe:

```
class AppConan(ConanFile):
    name = "App"
    requires = (("lib/0.0.0@com/develop"),
               )
    ...
```

Yet, `Lib` should probably be taken at a specific commit, in order for it's interface to match the expectations of `App`.

We thought of two ways of getting there:

## A) Making the commit hash a recipe option

This option would be used in the `build()` function of the recipe, something like that:

```
def build(self):
    ...
    self.run("git checkout {commit_id}".format(commit_id=self.options.gitcommit))
    ...
```

As options are hashed into the package_id, we know a new `Lib` binary is built each time the `gitcommit` value is changed for `Lib` requirement in the `App` recipe.

### Drawback
The problem we can foresee here is: how to handle changes in `Lib` recipe itself?

There is a single recipe: **lib/0.0.0@com/develop** built with different commit options. If a new version of the recipe is uploaded, it would overwrite the previous one, and one could builld a "recipe1" commit with the new "recipe2", potentially breaking.

## B) Adding the commit hash in the recipe version

This way, we upload a new recipe to the Conan server for each commit of `Lib`. The recipe name could be something like **lib/0.0.0-7ae81b1@com/develop**

This solution addresses the problem of solution A), since each commit has its recipe published, the commit is always built with the corresponding recipe.

### Drawback
A potential complication here is polluting the Conan server with many recipes for a single repository, as there are many commits on `develop` branch of `Lib`. This could make browsing packages in Artifactory UI complicated.
Also, most of the recipes will be identical, except for a hardcoded commit id to checkout, since it is expected that the recipe will change, but not change often compared to the frequency of commits on `develop`.

## The actual question

Are there recommendations, or best practices, to address this aspect of development?



user: Adnn
issue_2970: state: open
title: Add support to RTOS to default settings.yml
body: Support new os_targets in settings.tml to cross compile for RTOS:
- VxWorks
- Integrity
- LynxOS
- QNX

To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.


user: jpovedano
labels: inactive: No comments for a long time
issue_2817: state: open
title: Conan running inside a windows subsystem
body: This is a general issue to investigate and try how it works.
Some work is already done like #2798

Some more work can be done, for example, the `os_info.uname` and `os_info.detect_windows_subsystem()` are searching for a `bash` to run and detect the system, but if you are running Conan inside the subsystem it makes no much sense. Probably a tool to detect if we are under a subsystem make sense. 

Also the `conanfile.run` should avoid calling the `run_in_windows_bash` if we are inside the subsystem? Check and try recipes using. The idea is to have better recipe compatibility avoiding changes.  

**Important**: Probably WSL should be excluded from the above mentioned improvements, because, probably it could be considered a native Linux.?

user: lasote
issue_2760: state: open
title: MinGW(GCC) 
body: I am using clion with MinGW compiler.Conan is detecting that i am using Visual Studio compiler

```
Auto detecting your dev setup to initialize the default profile (C:\Users\Name\.conan\profiles\default)

Found Visual Studio 14`

Default settings
        os=Windows
        os_build=Windows
        arch=x86_64
        arch_build=x86_64
        compiler=Visual Studio
        compiler.version=14
        build_type=Release


```
Indeed now cmake detects a wrong compiler.

```
CMake Error at .conan/conanbuildinfo.cmake:448 (message):
 Incorrect 'Visual Studio'.  Toolset specifies compiler as 'MSVC' but CMake   detected 'GNU'
```
Clion details
https://i.gyazo.com/47693754c3a0d7d80abb23ccd5d40c09.png

How can i fix the compiler issue ?

user: khavishbhundoo
issue_2625: state: open
title: Conan/CMake script for WT fails to resolve libraries on windows [help wanted]
body: **Issue**
I am currently attempting to create conan package for WT, C++ web framework (https://www.webtoolkit.eu/wt)

I'm using conan-package-tools to build binary packages for the OS/compiler/Release-Debug combinations we use. On OS X (clang )and Ubuntu (gcc 7) this works fine. 

On Windows 10, using Visual Studio 2017, CMake fails to resolve libraries for boost and libpng, it seems like the XXX_PREFIX variables passed from conanfile.py is completely ignored. 
I have attempted to add BOOST_ROOT, BOOST_PREFIX and BOOST_ADDITIONAL_VERSIONS without any success.

**Versions:**
Conan version 1.1.1
Cmake version 3.10.3
Visual Studio Pro version 15.6.2

**Setup**
Content of conan default user profile:
[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
compiler=Visual Studio
compiler.version=15
build_type=Release
[options]
[build_requires]
[env]

Conan environment variables defined (for use with conan-package-tools)
CONAN_ARCHS=x86_64
CONAN_CHANNEL=stable
CONAN_USERNAME=awion
CONAN_VISUAL_VERSIONS=15

**Output from attempt to build**
Also, it does seem that it "finds boost and yet not find it" - except from output as follows:
 [ C:/Program Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:1767 ] Boost_FOUND = 1 
CMake Error at C:/Program Files/CMake/share/cmake-3.10/Modules/FindBoost.cmake:1928 (message):
  Unable to find the requested Boost libraries.

  Boost version: 1.66.0

  Boost include path: C:/.conan/6bqn3qx4/1/include

  Could not find the following static Boost libraries:

          boost_program_options
          boost_system
          boost_filesystem
          boost_thread_

**Steps to reproduce:**
checkout https://github.com/SverreEplov/conan-wt.git
execute "conan create . awion/stable -k"

[output.txt](https://github.com/conan-io/conan/files/1821560/output.txt)

user: SverreEplov
issue_2543: state: open
title: Same build_requirement on multiple architectures.
body: To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.

Hello!

I have a conan project that generates an installer with CMake and CPack. In the windows version (x86_64) we include in the package a dynamic library generated in another project (myDriver). I put it as build_requirements, however we have to include this driver in the x86 and x86_64 versions.

For the driver in x86_64 version we get trivial.

In conanfile.py
```
     def build_requirements self):
         self.build_requires.add("myDriver/1.0.0@user/stable") # get x86_64 version, OK.
         if self.settings.arch == "x86_64":
         	# self.build_requires.add("myDriver/1.0.0@user/stable") # Same build_requires, but in the x86 version. How do I do?
```
In CMakeList.txt using CPACK
```
INSTALL (FILES ${CONAN_BIN_DIRS_MYDRIVER}/myDriver.dll COMPONENT drivers DESTINATION lib64) 
INSTALL (FILES ${CONAN_BIN_DIRS_?????}/myDriver.dll COMPONENT drivers DESTINATION lib32) 
```
But how can I get the reference of myDriver in both x86 and x86_64 versions?
user: gustavokretzer88
issue_2437: state: open
title: How to detect compiler flag changes?
body: Hello,

I'm using Conan 1.0.4.

I've built a lot of dependencies with my `darwin-toolchain` as a build_requirement.

I had to add Bitcode support, so I've added the corresponding compiler flags `-fembed-bitcode`.

However, that had no impact on the package ID, and running `conan install` still installed the `non-Bitcode` binaries.

I thought about adding an option to my `darwin-toolchain`, but since this is a build_requirement it would have been discarded as soon as binary packages would have been created.

Is there a good way to prevent this issue? Apart from adding the option in every recipe I got?

Should the package ID depend on other things? Having a Gentoo-like flag handling might not be appropriate for Conan.

I did not dig a lot on that, but that seems like a tough problem!

EDIT: In this specific case, maybe bitcode should become a conan setting, it is specific to iOS (maybe watchOS and tvOS as well) but from my understanding it's becoming widely used by iOS apps.

To help us debug your issue please explain:

- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.


user: theodelrieu
issue_2317: state: open
title: "Getting started" tutorial fails to build on Msys2
body: The tutorial from http://docs.conan.io/en/latest/getting_started.html fails to build on Msys2 on the step `conan install .. --build missing` with the following error:

```
CMake Error at cmake/PocoMacros.cmake:45 (message):
  message compiler not found: required to build
```

**Steps:**
git clone https://github.com/memsharded/example-poco-timer.git mytimer
cd mytimer
mkdir build && cd build
conan install .. --build missing

**Environment:**
Conan 1.0.2rc2 from pip3
pip3 9.0.1
Python 3.6.4
CMake 3.10.1
GCC 7.2.0
Msys2 MinGW
Windows 10
everything above is 64-bit and apps are from Msys2

**Full log:**

```
Fazer@fazer-laptop MINGW64 /d/dev/project/test/conan-example-test/mytimer/build
$ conan install .. --build missing
PROJECT: Installing D:/dev/project/test/conan-example-test/mytimer/conanfile.txt
Requirements
    OpenSSL/1.0.2l@conan/stable from conan-center
    Poco/1.8.0.1@pocoproject/stable from conan-center
    zlib/1.2.11@conan/stable from conan-center
Packages
    OpenSSL/1.0.2l@conan/stable:63307e240b41ef8839dcfb74542a850772ef7dc9
    Poco/1.8.0.1@pocoproject/stable:98d9d2f7b6cf65f5975eb8f4fbaa62c654edb3ae
    zlib/1.2.11@conan/stable:42951bc9791ea38175dc6d678bd77956f88c4796

zlib/1.2.11@conan/stable: Already installed!
OpenSSL/1.0.2l@conan/stable: Already installed!
Poco/1.8.0.1@pocoproject/stable: Building your package in C:/Users/Fazer/.conan/data/Poco/1.8.0.1/pocoproject/stable/build/98d9d2f7b6cf65f5975eb8f4fbaa62c654edb3ae
Poco/1.8.0.1@pocoproject/stable: Copying sources to build folder
Poco/1.8.0.1@pocoproject/stable: Generator cmake created conanbuildinfo.cmake
Poco/1.8.0.1@pocoproject/stable: Generator txt created conanbuildinfo.txt
Poco/1.8.0.1@pocoproject/stable: Calling build()
Poco/1.8.0.1@pocoproject/stable: OrderedDict([('CMAKE_BUILD_TYPE', 'Release'), ('CONAN_EXPORTED', '1'), ('CONAN_COMPILER', 'gcc'), ('CONAN_COMPILER_VERSION', '7'), ('CONAN_LIBCXX', 'libstdc++'), ('BUILD_SHARED_LIBS', 'OFF'), ('CMAKE_INSTALL_PREFIX', 'C:/Users/Fazer/.conan/data/Poco/1.8.0.1/pocoproject/stable/package/98d9d2f7b6cf65f5975eb8f4fbaa62c654edb3ae'), ('CXX_14', 'OFF'), ('ENABLE_APACHECONNECTOR', 'OFF'), ('ENABLE_CPPPARSER', 'OFF'), ('ENABLE_CRYPTO', 'ON'), ('ENABLE_DATA', 'ON'), ('ENABLE_DATA_MYSQL', 'OFF'), ('ENABLE_DATA_ODBC', 'OFF'), ('ENABLE_DATA_SQLITE', 'ON'), ('ENABLE_JSON', 'ON'), ('ENABLE_MONGODB', 'ON'), ('ENABLE_NET', 'ON'), ('ENABLE_NETSSL', 'ON'), ('ENABLE_NETSSL_WIN', 'ON'), ('ENABLE_PAGECOMPILER', 'OFF'), ('ENABLE_PAGECOMPILER_FILE2PAGE', 'OFF'), ('ENABLE_PDF', 'OFF'), ('ENABLE_POCODOC', 'OFF'), ('ENABLE_SEVENZIP', 'OFF'), ('ENABLE_TESTS', 'OFF'), ('ENABLE_UTIL', 'ON'), ('ENABLE_XML', 'ON'), ('ENABLE_ZIP', 'ON'), ('FORCE_OPENSSL', 'ON'), ('POCO_UNBUNDLED', 'OFF'), ('POCO_STATIC', 'ON')])
-- The C compiler identification is GNU 7.2.0
-- The CXX compiler identification is GNU 7.2.0
-- Check for working C compiler: D:/app/msys64/mingw64/bin/gcc.exe
-- Check for working C compiler: D:/app/msys64/mingw64/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: D:/app/msys64/mingw64/bin/g++.exe
-- Check for working CXX compiler: D:/app/msys64/mingw64/bin/g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: Compiler GCC>=5, checking major version 7
-- Conan: Checking correct version: 7
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: C++ stdlib: libstdc++
Not activating CXX_STANDARD 14
Activating CXX_STANDARD 11
-- Poco package version: 1.8.0.1
-- Checking for C++11 compiler
-- Checking for C++11 compiler - available
-- Checking for C++14 compiler
-- Checking for C++14 compiler - available
-- Setting Poco build type - Release
CMake Error at cmake/PocoMacros.cmake:45 (message):
  message compiler not found: required to build
Call Stack (most recent call first):
  CMakeListsOriginal.cmake:86 (include)
  CMakeLists.txt:27 (include)


-- Configuring incomplete, errors occurred!
See also "C:/Users/Fazer/.conan/data/Poco/1.8.0.1/pocoproject/stable/build/98d9d2f7b6cf65f5975eb8f4fbaa62c654edb3ae/build/CMakeFiles/CMakeOutput.log".
Poco/1.8.0.1@pocoproject/stable:
Poco/1.8.0.1@pocoproject/stable: ERROR: Package '98d9d2f7b6cf65f5975eb8f4fbaa62c654edb3ae' build failed
Poco/1.8.0.1@pocoproject/stable: WARN: Build folder C:/Users/Fazer/.conan/data/Poco/1.8.0.1/pocoproject/stable/build/98d9d2f7b6cf65f5975eb8f4fbaa62c654edb3ae
ERROR: Poco/1.8.0.1@pocoproject/stable: Error in build() method, line 118
        cmake.configure(source_dir="../poco", build_dir="build")
        ConanException: Error 1 while executing cd build && cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE="Release" -DCONAN_EXPORTED="1" -DCONAN_COMPILER="gcc" -DCONAN_COMPILER_VERSION="7" -DCONAN_LIBCXX="libstdc++" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="C:/Users/Fazer/.conan/data/Poco/1.8.0.1/pocoproject/stable/package/98d9d2f7b6cf65f5975eb8f4fbaa62c654edb3ae" -DCXX_14="OFF" -DENABLE_APACHECONNECTOR="OFF" -DENABLE_CPPPARSER="OFF" -DENABLE_CRYPTO="ON" -DENABLE_DATA="ON" -DENABLE_DATA_MYSQL="OFF" -DENABLE_DATA_ODBC="OFF" -DENABLE_DATA_SQLITE="ON" -DENABLE_JSON="ON" -DENABLE_MONGODB="ON" -DENABLE_NET="ON" -DENABLE_NETSSL="ON" -DENABLE_NETSSL_WIN="ON" -DENABLE_PAGECOMPILER="OFF" -DENABLE_PAGECOMPILER_FILE2PAGE="OFF" -DENABLE_PDF="OFF" -DENABLE_POCODOC="OFF" -DENABLE_SEVENZIP="OFF" -DENABLE_TESTS="OFF" -DENABLE_UTIL="ON" -DENABLE_XML="ON" -DENABLE_ZIP="ON" -DFORCE_OPENSSL="ON" -DPOCO_UNBUNDLED="OFF" -DPOCO_STATIC="ON" -Wno-dev ../poco

```


- [x] I've read the [CONTRIBUTING guide](https://raw.githubusercontent.com/conan-io/conan/develop/.github/CONTRIBUTING.md).
- [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.


user: ArekPiekarz
issue_1891: state: open
title: launch `conan install ../` from existing visual studio project msbuild chain?
body: the documentation suggest the following  3 step approach for integration of into an existing Visual Studio project

1. add conanfile.txt to project
2. manually install dependencies
```mkdir debug32 && cd debug32
$ conan install .. -s compiler="Visual Studio" -s compiler.version=15 -s arch=x86 -s build_type=Debug
$ cd ..
$ mkdir debug64 && cd debug64
$ conan install .. -s compiler="Visual Studio" -s compiler.version=15 -s arch=x86_64 -s build_type=Debug
$ cd ..
$ mkdir release32 && cd release32
$ conan install .. -s compiler="Visual Studio" -s compiler.version=15 -s arch=x86 -s build_type=Release
$ cd ..
$ mkdir release64 && cd release64
$ conan install .. -s compiler="Visual Studio" -s compiler.version=15 -s arch=x86_64 -s build_type=Release
```
3. include property files in project for each configuration


Step 1&3 needs to be done once and the changes to the *.vcxproj file can then be committed to the VCS. My question is how can I configure the visual studio project to *automatically* execute the commands of step 2 as part of the build process? 

The goal is to be able to do a clean checkout open the solution file and press F5. At which point I would expect to see the following:
1. the various conan install -s .... commands  are invoked to download the deps if they are not yet installed on the system
1. build the project
1. run the project.

if I set the code from step 2 as a pre-build step command then the build fails however because it seems like it does not reparse the project file for the newly 'conan install ../'  generated property files. rebuilding a second time succeeds because the conanbuildinfo.props exist at that point. Having to build twice is not really acceptable though.
user: jeroendv
issue_1346: state: open
title: Consider adding gcc/clang sanitizers to the model
body: There are different sanitizers in gcc/clang that affect the final binary.
When you build with one sanitizer, it is typical that the whole project must use it. Then it sounds, that it should be a children of the ``gcc`` and ``clang`` compilers.

A possible proposal could be:

```
gcc:
    thread_sanitizer: None, True
    memory_sanitizer: None, True
     ....
```
It will use: ``self.compiler.thread_sanitizer=True`` syntax

user: memsharded
issue_1252: state: open
title: Support gnustl for Android
body: https://developer.android.com/ndk/guides/cpp-support.html
user: KindDragon
issue_1012: state: open
title: Add option to download packages in parallel
body: When running `conan install` on a file that depends on a lot of packages those packages should be able to be downloaded in parallel. This should speed up that process a lot. Especially if unpacking would be done in parallel as well. This should of course be an option of some sorts I think. But it would be a huge win for some CI deployments.
user: tru
labels: component: ux: No changes to core business logic
issue_922: state: open
title: Optimize conan install --update
body: Running `conan install -u` on my conanfile that links in 10 different packages takes almost 30 seconds when nothing gets updated. My guess is that it does something like:

```py
for p in package:
  hash(p)
  check_local(p)
  check_remote(p)
```

I think this can probably be optimized so that if it's the hashes that take time: do them in parallel, if it's the calls to remote we probably should extend the API to do fewer calls to check more info.

Why is this needed?

For a release build I wipe my conan dir on the CI to make sure I have the latest and greatest even if the version number hasn't changed. But for local developers I also want to make sure that it's fast to check for updates on all binary packages so that they don't sit and spend a lot of time debugging something already fixed.

Ideally our cmake run could execute `conan install -u` everytime - that requires the execution to go down from 30 seconds to around 1-2 seconds though.

Let me know if I can do some local profiling.

user: tru
issue_871: state: open
title: Add possibility to upload "transactional"
body: Hi,

I would like a feature where all binary packages and the receipt are make available on the server only if all uploads have succeeded and are finished. If one upload fails, nothing should be available on the server.
Maybe a feature line `--all --as_transaction`.

We are currently building a lot of different configurations of one package on our CI System. When all builds  are finished (currently 4, Release/Debug and x64/x86, this will get more when more compilers need to be supported), I upload them to our conan server using the `--all` flag.

The problem is that the receipt is publish first, and then the binary packages are uploaded. This currently takes up to 2 minutes, and sometimes an upload fails. Then, other CI builds are using the newly uploaded component and building them "on the fly", because the binary package is not available on the server. This is not desired, as some of the base components take some time to build.

Best,
Claas
user: claasd
issue_847: state: open
title: Pivoting on target-cpu/arch
body: We have a couple common generations of CPU above the baseline x86_64 instruction - namely sandybridge and haswell, with AVX and AVX2/BMI/BMI2 respectively.

LLVM-backed languages and GGC 4.9+ all support "x86-64, sandybridge, haswell, native" for the -march/--target-cpu parameters. GCC 4.8 uses alternate identifiers `corei7-avx` and `core-avx2` for those platforms.

These map nicely to MSVC /arch:AVX and /arch:AVX2, which is as granular as MSVC goes.

For now I'm using an extra field in `.conan/settings.yml`: `target_cpu: [x86, x86-64, nehalem, sandybridge, haswell, native]`, but I need to move this down into the packages I consume as well, if I want to pivot on sandybridge/haswell support. 

Has this come up before? Any convention to adopt?

user: lilith