Alire builds crate that is not available on current OS

[onox]

My orka_egl crate's alire.toml file contains:

[available.'case(os)']
linux = true
'...' = false

Yet, it happily runs alr build on windows-latest (with ce2021 compiler) during GitHub Actions. It compiles with no errors, but then fails with ld.exe: cannot find -lEGL (which is why the crate is not available on windows).

Shouldn't alr just do nothing if available.'case(os)' says it's not available?

[mosteo]

Hi onox. Crates are usually properly skipped when they're unavailable in a OS. Do you have a GHA run where I can check more details?

[onox]

This is the GHA run with the problem: https://github.com/onox/orka/runs/2975156460?check_suite_focus=true

[mosteo]

Alright, I understand. I was for some reason thinking that this was happening in our crate tests for the index.

Indeed you're right that we should at least show a warning or recoverable error in this case. Although the crate is unavailable, since the user is commanding the build I guess we should do something and not merely silently succeed doing nothing. It is counterintuitive to me that a build is commanded (even if by mistake) and we silently return success while not attempting the build.

So what about:

• By default fail with exit code and warning about the unavailability.
• Allow building with --force (for experimentation, porting...)
• Have something like --skip-unavailable to explicitly acknowledge the situation, in which case no build is attempted and return code is 0. I guess this can be useful in automated tests to simplify the logic there.

[onox]

--skip-unavailable would work for me.

Would it help to only allow it to be used for the current crate and not for any dependencies that happen to be unavailable? If you command crate A to build, but it has a dependency B that is unavailable for some reason, crate A's alire.toml file should simply not depend on B in that case.

[mosteo]

I was thinking only about the root crate, for the reason you state.