Docs about 'profile:host' and 'profile:build' #1629
Conversation
| self.copy("license*", dst="", src=self.nasm_folder_name, keep_path=False, ignore_case=True) | ||
|
|
||
| def package_info(self): | ||
| self.output.info("Using %s version" % self.nasm_folder_name) | ||
| self.env_info.path.append(os.path.join(self.package_folder, self.nasm_folder_name)) | ||
| self.env_info.PATH.append(os.path.join(self.package_folder, "bin")) |
There was a problem hiding this comment.
@jgsogo it should be cpp_info.bindir, no?
There was a problem hiding this comment.
I mean Iirc all helpers should use run_environment or virtualrunenv, so having bindirs should be enough. Did this change?
There was a problem hiding this comment.
Depending on where you use this recipe. If you use it with the new model with the two profiles, you just need to set cpp_info.bindirs to the bin directory (it is added by default). But if you want to use this same recipe using only one profile in the command line, you need to add the bin folder to the PATH.
My intention here was to write an example that works with the two scenarios, even if this is talking about the two profiles... do you think it is misleading? I can imagine people copy/pasting an example and IMO it is better if it works for the two scenarios (if it requires almost no extra code)
There was a problem hiding this comment.
I mean Conan handled well ld_library_path on Linux, path on windows (for dynamic libraries) as well as macos wieredness with environment jamming in some cases.
And it felt that use of environment variables for path/dll path was discouraged or obsolete, things just worked (with run_environment though).
And I see no reason for 2 contexts should interfere with this.
There was a problem hiding this comment.
RunEnvironment is already adding bin directories to PATH, so it works with one profile (this is what run_envrionment=True does) and with two profiles (logic that propagates environment from build to host does it already).
So this line is useless.
There was a problem hiding this comment.
Needed for the virtualenv generator (using one profile)
There was a problem hiding this comment.
Yes, that's why I merged them into one (in our company): as soon as you want to run a tool you need runenv. And this is 100% times since we have compiler and python as Conan packages.
There was a problem hiding this comment.
I thinkrun_environment=True could be a default for Conan 2.0. and virtualenv should behave as if running from recipe (thus all virtual* merged).
I don't see why it is a harmful default. And we get defaults wrong: explicit, const, noexcept?
There was a problem hiding this comment.
Yes, Conan 2.0 will reconsiders the defaults for the self.run(...) and the environment that is populated before entering recipe functions like build(). We are also aware that all virtualxxxenv generators might be merged into one.
It's been many years of 1.x and our commitment to stability, we really are looking forward for the next major version and break some of the conventions/defaults.
Docs for conan-io/conan#5594
Closes #1586