Fix wrong compiler path on windows when using andrdoid ndk and MesonToolchain

[elvisdukaj]

Changelog: Bugfix: Fix cross-compilation to Android from Windows when using MesonToolchain.
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.
• 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, and I am proposing a fix here.

Note

I accidentaly close #15760 and I had to create a new one here. I am sorry for the inconvinience!

[memsharded]

Thanks very much for your contribution

[elvisdukaj]

Ok I've no idea why is failing again... I can reduce the scope of the tests to windows only, for armv8... The point is that toolchain path can be very different based on the arch, but maybe this is tested somewhere else.

[memsharded]

Ok I've no idea why is failing again... I can reduce the scope of the tests to windows only, for armv8... The point is that toolchain path can be very different based on the arch, but maybe this is tested somewhere else.

I think we don't have AndroidNDK in the Windows CI agent, @czoido?

[elvisdukaj]

It would be nice to have it! Since I started to test conan on windows with android ndk, I’m hitting so many issues… I’ve created so many PR in the last days! It seems not a common thing

[memsharded]

As we don't have Android in Windows at the moment, I was suggesting:

• Have the test exclusively for OSX-Darwin, as this is the one we have now in CI
• We can run the test locally on Linux and Windows to manually validate
• We can move the PR forward if it passes CI with OSX and we test it locally too

I'll discuss with the team the possibility to have the AndroidNDK at least on Windows or Linux to improve the coverage. I think Windows might be easier.

[memsharded]

I am doing some simplifications in #15808 in order to prepare for having Android testing in other platforms

[elvisdukaj]

Should I comment the tests on Windows for now?

[memsharded]

Not commenting out, but enabling it only for Darwin/OSX. That should pass, we already have other tests using AndroidNDK in OSX without issues.

Then, we can just comment out the skipif line in the code and run it locally to verify.

I have tried to contribute to your PR, but you have contributions from maintainers blocked apparently.

[elvisdukaj]

Ok interesting, you should be able to contribute:

Not commenting out, but enabling it only for Darwin/OSX. That should pass, we already have other tests using AndroidNDK in OSX without issues.
Then, we can just comment out the skipif line in the code and run it locally to verify.

Okay I'll do as you suggested :)

[elvisdukaj]

I also tested with MacOS on intel, with meson and android-ndk installed from homebrew end tests are green.

tools_locations = {
    'meson': {
        "disabled": False,
        "platform": "Darwin",
        "default": "1.3.2",
        "1.3.2": {
            'path': {
                "Darwin": "/usr/local/bin"
            }
        }
    },
    'android_ndk': {
        "disabled": False,
        "platform": "Darwin",
        "default": "26c",
        "26c": {
            "path": {
                "Darwin": "/usr/local/share/android-ndk"
            }
        },
        "exe": "ndk-build",
    }
}

tools_environments = {
    'android_ndk': {'Darwin': {'TEST_CONAN_ANDROID_NDK': '/usr/local/share/android-ndk'}}
}

I cannot explain why the CI is still red, can you share the log?

[memsharded]

Ok interesting, you should be able to contribute:

Ok, the reason was that you named the repo conan-io instead of conan, and that was failing

[elvisdukaj]

So that means I need to close this MR and create a new one? I renamed the branch, let's hope is enough 🙈🙈🙈

[memsharded]

So that means I need to close this MR and create a new one? I renamed the branch, let's hope is enough 🙈🙈🙈

No, no no need to do that. It was just that I added the remote with a wrong name. Changing the remote name to conan-io works

[memsharded]

The fix is correct, I have validated it in Windows.

The tests might still fail on CI but that is on our side, so don't worry about it, I'll take care it to be merged for next 2.2.

Thanks for your contribution!

[elvisdukaj]

@memsharded great news! Looking forward to get rid off my fix branch and use the upstream version. I have also some projects that is using conan v1, I will need to check if the fix should be back ported as well in my case.

[alexandermarinissen]

Hi! I'm experiencing the same issue, but in Conan 1.65.0. Has the fix been backported? I don't see the changes when I look at conan/tools/meson/toolchain.py in my local site-packages.

[memsharded]

Hi @alexandermarinissen

Thanks for your question.

No, this fix has not been backported, this kind of thing is not being backported anymore to Conan 1.X by default by the maintainers. We have accepted some contributions to backport some, but also as an exception (reviewing, releasing, etc also takes time and resources, and Conan 2.0 is now more than 18 months old).

[alexandermarinissen]

Hi @memsharded, luckily the fix is quite small and I was able to apply it locally to my installation, so I'm no longer stuck :) Thanks for the quick reply!

[memsharded]

Sounds good, thanks for the feedback @alexandermarinissen
Please just recall to try to prioritize moving to Conan 2, for example ConanCenter packages will stop getting updates for Conan 1 in the following months.