search

conan-io / conan-package-tools

Conan Package Tools. Helps with massive package creation and CI integration (Travis CI, Appveyor...)
MIT License
165 stars 70 forks source link

CONAN_BASE_PROFILE_BUILD is not correctly passed to Docker #595

Closed db4 closed 2 years ago

db4 commented 2 years ago

Description of Problem, Request, or Question

ConanMultiPackager(use_docker=True) doesn't correctly handle build profile settings. If I set CONAN_BASE_PROFILE_BUILD=my_build_profile, CPT adds

-e CPT_PROFILE_BUILD="@@include(my_build_profile)@@@@[settings]@@@@[options]@@@@[env]@@@@[build_requires]@@@@"

to Docker command line, but the build fails inside Docker because my_build_profile does not exist there:

 File "c:\python39\lib\site-packages\conans\client\profile_loader.py", line 132, in read_profile
    return _load_profile(text, profile_path, default_folder)
  File "c:\python39\lib\site-packages\conans\client\profile_loader.py", line 151, in _load_profile
    profile, included_vars = read_profile(include, cwd, default_folder)
  File "c:\python39\lib\site-packages\conans\client\profile_loader.py", line 119, in read_profile
    profile_path = get_profile_path(profile_name, default_folder, cwd)
  File "c:\python39\lib\site-packages\conans\client\profile_loader.py", line 107, in get_profile_path
    raise ConanException("Profile not found: %s" % profile_name)
conans.errors.ConanException: Profile not found: my_build_profile

Another problem is that in the absence of CONAN_BASE_PROFILE_BUILD CPT passes empty settings for the build profile:

-e CPT_PROFILE="@@include(default)@@@@[settings]@@arch=x86_64@@build_type=Release@@compiler=Visual Studio@@compiler.runtime=MD@@compiler.version=15@@os=Windows@@[options]@@@@[env]@@@@[build_requires]@@@@"
-e CPT_PROFILE_BUILD="@@include(default)@@@@[settings]@@@@[options]@@@@[env]@@@@[build_requires]@@@@"

That breaks my build that worked before with CPT 0.35.0. Why not pass the same settings in CPT_PROFILE_BUILD as in CPT_PROFILE if CONAN_BASE_PROFILE_BUILD is not set?

Environment Details

jmarrec commented 2 years ago

I'm having a similar issue. I'm trying to force docker to use a build profile that would force build_requirements to be in Release mode even if the recipe itself is built in Debug mode (for 1) performance reasons, and 2) working around an issue I have with m4 that throws debug asserts https://github.com/conan-io/conan-center-index/issues/8920)

The idea to pass a build profile like so

include(default)
[settings]
build_type=Release

I've been uselessly trying to patch conan-package-tools to correctly pass CONAN_BASE_PROFILE_BUILD to docker but I haven't managed to make it work. I have opened a draft PR with my failed attempts at https://github.com/conan-io/conan-package-tools/pull/596 in the hope that it'll spark a conversation. #596 will be either cleaned if possible, or just closed if not.

My print-debugging isn't even showed in the build logs (eg: A failing example of an actual run that uses this patched cpt can be found here: https://github.com/jmarrec/conan-openstudio-ruby/runs/4852398264?check_suite_focus=true), and I do not understand why that is...

sbannier commented 2 years ago

I also have encountered some problems with the changes introduced in commit 830e84a79c2c32b57824a227bc88b95406c3944d. It forces Conan to always be called with a build profile. This changes some of the internal behavior of Conan and prevents the imports() method from copying files of private requirements of my top-level package (I am not sure if this might be a bug in Conan or if it is desired behavior, haven't looked into it, yet)

I have a implemented a workaround that removes the "default" base profile when creating the Docker runner. This should now behave like the non-Docker path (pull request #604)

uilianries commented 2 years ago

The Release 0.38.1 includes the hotfix the PR #604. Please, update your local copy: https://pypi.org/project/conan-package-tools/0.38.1/