Based on the description of the PR, I think you just need to switch between fail-fast and fail-safe. Correct me if I'm wrong! So, can we define an assert function that can switch between the fail-fast and fail-safe to make sure the condition of if is exactly the same as the condition of assertion? It will also help you avoid redundant if-else all over this PR.

So, can we define an assert function that can switch between the fail-fast and fail-safe to make sure the condition of if is exactly the same as the condition of assertion?

If you look closer, these patterns are not the same in every case. The assert is not always the first thing in else directly. Sometimes it's much deeper down. So the helper can't extract the assert itself.

The only thing that's similar is if !config.allowAliases && !condition then null else. But I can't use config.allowAliases in lib/.. and now the benefit of writing up a helper in lib/diminishes a lot..

they are not the same! that's my point! why are they different?

your other PR today makes more sense, since you moved the assertion so they will be run lazily, but the changes here feels wrong!

I assume you mean #426642. There is a difference for that: These packages have an unfree license and are filtered out by CI that way. Thus, the lazy throw will never happen.

To achieve the same here, we'd need to mark these packages as meta.broken. But that defeats the point of having these throws in the first place: They are a mechanism to work around the fact that meta.broken is boolean only and doesn't allow to communicate a reason for this brokenness.

The solution to this is meta.problems as mentioned above.

So no, the lazy throw approach will not work here.

they are not the same! that's my point! why are they different?

I looked into this a bit. At first glance it seems possible to move the throw in androidndk-pkgs to the top, right after the else, too. But it becomes more complicated: There are two different error messages thrown, depending on the specific case. We can't unify these without losing information. I played this through: These multiple throws won't work well with a helper function like this (which I assume you roughly have in mind):

lib.assertIf config.allowAliases
  bothAssert compatibilityMsg
    stdenv.mkDerivation {
    ...

At this stage, I'd rather defer the implementation of helper functions to later. That's because #426629 lists many similar problems for other platforms - and I assume there are other special cases to deal with. So it would probably be better to implement this ad-hoc if-else pattern a bit more often and then see which other cases come up, before simplifying. Although, it's arguably also a good idea to implement meta.problems first, before spending more time on this - maybe a lot of these cases already go away that way.

Thank you for explanation. The assertIf is exactly what I was referring to, but in the end it makes sense. Even though it would be better if we had a trace of this deferring implementation in code directly by commenting a TODO, but I approved this PR.

There is a problem with returning null here. gccWithoutTargetLibc is an input to gccCrossLibcStdenv. By returning null the build of the latter is not blocked anymore. This is why we get "1 rebuild" here - a "new" package gccCrossLibcStdenv. where targetPlatform == hostPlatform.

Ofc, this doesn't make sense to build...

The other packages in this PR are fine, in principle, but just by accident - because they are not dependencies of other attributes listed for CI.

I changed this case to start overriding meta.badPlatforms for gccWithoutTargetLibc. This is not super-nice, because we're losing the better stack-trace of the assert, but I don't see a better way. meta.problems would help here, too, being able to provide a better message about it...

I also tried to just do the same null handling for gccCrossLibcStdenv - but this just makes the problem worse, because then this is passed around as null and causes further eval and build failures.