[bug] incomplete adaptation on subsytem install request

[herve0026]

Describe the bug

Hello,

I use conan 2.12.1 to install prebuild binaries package. Under windows I work in a git-bash console. Then I am interesting in the msys2 subsystem possibilities.

When I download a package with the following command:
conan install ./conanfile.txt --update --output scripts/conan -c=tools.microsoft.bash:subsystem=msys2 -c=tools.microsoft.bash:active=True

I do have shell scripts, which is good:

But I have the following observations:

PATH variable is correctly adapted but it is not the case of ELIXT_CONFIGURATION_PROPERTIES and script_folder.

Furthermore, deactivate_conanrunenv-release-x86_64.sh is not created whereas the bat file is correctly created if I simply use: conan install ./conanfile.txt --update --output scripts/conan

Same behavioir with wsl or cygwin subsystems.

Did I do something wrong ?

How to reproduce it

systematic using subsystem configurations

[memsharded]

Hi @herve0026

Thanks for your question.

I use conan 2.12.1 to install prebuild binaries package. Under windows I work in a git-bash console. Then I am interesting in the msys2 subsystem possibilities.

This is not strictly necessary, and possibly not recommended, please let me explain:

• If you are using recipes from ConanCenter, at the moment they are only built (and tested) in Windows with MSVC compilers. Consequently, the support for other compilers such as mingw or cygwin might vary, some recipes might work, but others might fail. It is quite recommended to use msvc compilers in Windows, at least if getting started and using ConanCenter.
• There are nasty interactions between git-bash and Python, see for example [question] ffmpeg/6.1.1 dependancies and PKG_CONFIG #16963 (comment). This makes some things fail, and it is very outside of Conan scope, so we are not able to fix or workaround it.

Can you clarify which compiler do you intent to use, is it mingw? If you are using it, why not using the msys2 bash in the first place, as it integrates the mingw compiler (still similar issues to run into it)? Any specific reason not to use msvc compiler? Are you using recipes from ConanCenter?

I use WSL in Windows, just as a native Linux system I install conan in it, etc, and everything works great. Also in docker containers, I'd like to understand better what is the challenge there.

[herve0026]

Hello and first of all thank you for your quick feedback.

My development environment can be either Windows or Linux. I manage a C project using cmake, which is OS agnostic.
My compiler is gcc (a professional distribution, not a community one).

I do not specifically need git-bash on windows, but I use it because it is easy to use as it can be called from the contextual menu. To be transparent, I mainly work with vscode and open a git-bash terminal from there.

But the main idea is that I manage my project dependencies from a bash/sh terminal when I'm on windows or linux, not from a cmd or powershell when I'm on windows and a bash/sh when I'm on linux.

Currently I only have tool dependencies that do not need to be built, but I do need the tools exe to be present in the path and possibly an environment variable associated with the tool.

So it is very nice for me that conan allows to have conanrun.sh under windows thanks to the capacity of the windows subsystem. This way I have a set of scripts that work fine and are exactly the same whether I'm developing under Windows (under msys, under cygwin or under wsl) or under Linux.

I have found that deactivate_conanrunenv-release-x86_64.sh is created correctly when I run conan install conanfile.txt with a new version of the tool, for example. So the question on this particular point is closed.

For the the fact that only path and note define takes advantage of the automatic conversion, I have managed this on my side by implementing a "setenv.sh" associated with the tool.

So I have removed the define from my recipe:

    def package_info(self):
        # On package Consumer side : add this package to local PATH environment variable
        self.runenv_info.append_path(
            "PATH", os.path.abspath(self.package_folder))
        # On package Consumer side : set environment variable for location of the configuration file!
        # self.runenv_info.define("ELIXT_CONFIGURATION_PROPERTIES", os.path.abspath(
        #    os.path.join(self.package_folder, os.path.join("conf", "esg_packer_tool.properties"))))

[memsharded]

Many thanks for the feedback.

Currently I only have tool dependencies that do not need to be built, but I do need the tools exe to be present in the path and possibly an environment variable associated with the tool.

A perfectly valid scenario is to have a "build" profile with compiler=msvc, and a "host" profile with a certain compiler=gcc. That basically mean that if Conan has to build some tool_requires from source, lets say, CMake executable if it was a tool_requires("cmake/...") and the cmake recipe allowed to build it from source, then it could build cmake with MSVC compiler, which is more likely to be easier and less problematic that building with a subsystem. Then, that cmake.exe from Conan package can be perfectly applied to build or cross build a binary using a gcc compiler. If you haven't yet, this is a nice introduction to the "build" and "host" contexts: https://docs.conan.io/2/tutorial/consuming_packages/cross_building_with_conan.html

I think the initial issue with the ELIXT_CONFIGURATION_PROPERTIES not being adapted is that it was not defined as a path, but as a regular variable, did you try to define it with self.runenv_info.define_path() instead? If not, you might want to give that a try.

[herve0026]

yes, that was the trick :-)

thanks a lot !

I close the ticket